Եթե դուք նոր եք DevOps-ում, դիտեք ձեր առաջին խողովակաշարը ստեղծելու այս հինգ քայլանոց ուղեցույցը:
DevOps-ը դարձել է ստանդարտ լուծում՝ ծրագրային ապահովման մշակման դանդաղ, տարանջատված կամ կոտրված գործընթացները շտկելու համար: Խնդիրն այն է, որ եթե դուք նոր եք DevOps-ում և չգիտեք, թե որտեղից սկսել, կարող եք չհասկանալ այս տեխնիկան: Այս հոդվածը կքննարկի DevOps խողովակաշարի սահմանումը, ինչպես նաև կտրամադրի հինգ քայլից բաղկացած հրահանգներ՝ մեկը ստեղծելու համար: Թեև այս ձեռնարկը սպառիչ չէ, այն պետք է ձեզ հիմք տա՝ սկսելու ձեր ճանապարհորդությունը և ընդլայնելու ձեր գիտելիքները ապագայում: Բայց եկեք սկսենք պատմությունից:
Իմ DevOps ճանապարհորդությունը
Ես նախկինում աշխատել եմ Citi Group-ի ամպային թիմում, որը մշակում էր Infrastructure-as-a-Service (IaaS) վեբ հավելված՝ Citi-ի ամպային ենթակառուցվածքը կառավարելու համար, բայց ինձ միշտ հետաքրքրում էր, թե ինչպես զարգացնելու գործընթացն ավելի արդյունավետ դարձնել և դրական մշակութային փոփոխություններ բերել: զարգացման թիմ: Ես գտա պատասխանը մի գրքում, որն առաջարկել էր Գրեգ Լավանդերը, CTO Cloud Architecture and Infrastructure Citi-ում: Գիրքը կոչվում էր The Phoenix Project (), և այն բացատրում է DevOps-ի սկզբունքները, բայց այն կարդում է վեպի պես։
Գրքի հետևի աղյուսակը ցույց է տալիս, թե որքան հաճախ են տարբեր ընկերություններ տեղադրում իրենց համակարգերը թողարկման միջավայրում.
Amazon՝ օրական 23
Google՝ օրական 5
Netflix՝ օրական 500
Ֆեյսբուք. Օրը մեկ անգամ
Twitter՝ շաբաթական 3 անգամ
Տիպիկ ընկերություն՝ 9 ամիսը մեկ անգամ
Ինչպե՞ս են նույնիսկ հնարավոր Amazon-ի, Google-ի և Netflix-ի հաճախականությունները: Դա պայմանավորված է նրանով, որ այս ընկերությունները պարզել են, թե ինչպես ստեղծել գրեթե կատարյալ DevOps խողովակաշար:
Մենք հեռու էինք դրանից մինչև Citi-ում ներդրեցինք DevOps-ը: Այն ժամանակ իմ թիմն ուներ տարբեր միջավայրեր, բայց մշակման սերվերի վրա տեղակայումը ամբողջովին ձեռքով էր: Բոլոր ծրագրավորողներն ուներ մուտք գործելու միայն մեկ սերվեր, որը հիմնված է IBM WebSphere Application Server Community Edition-ի վրա: Խնդիրն այն էր, որ սերվերը կփակվեր ամեն անգամ, երբ մի քանի օգտատերեր փորձեին տեղակայել միաժամանակ, ուստի մշակողները ստիպված էին միմյանց փոխանցել իրենց մտադրությունները, ինչը բավականին ցավալի էր: Բացի այդ, խնդիրներ կային ցածր մակարդակի թեստային կոդի ծածկույթի, ձեռքով տեղակայման դժվարին գործընթացների և կոնկրետ առաջադրանքի կամ օգտագործողի պատմության հետ կապված կոդի տեղակայմանը հետևելու անկարողության հետ:
Ես հասկացա, որ ինչ-որ բան պետք է անել, և գտա համախոհ գործընկերոջ: Մենք որոշեցինք համագործակցել նախնական DevOps խողովակաշարի կառուցման վրա. նա ստեղծեց Tomcat վիրտուալ մեքենա և հավելվածի սերվեր, մինչ ես աշխատում էի Jenkins-ում, ինտեգրում էի Atlassian Jira-ն և BitBucket-ը և աշխատում էի թեստային ծածկույթի վրա: Այս կողմնակի նախագիծը շատ հաջող էր. մենք գրեթե ամբողջությամբ ավտոմատացրեցինք բազմաթիվ գործընթացներ, հասանք մեր զարգացման սերվերի գրեթե 100% գործարկման, ապահովեցինք կոդի հետևում և բարելավված թեստային ծածկույթ և ավելացրինք Git-ի մասնաճյուղերը Jira-ի խնդիրներին կամ տեղակայմանը կապելու հնարավորությունը: Գործիքների մեծ մասը, որոնք մենք օգտագործել ենք մեր DevOps խողովակաշարը կառուցելու համար, բաց կոդով էին:
Այժմ ես հասկանում եմ, թե որքան պարզ էր մեր DevOps խողովակաշարը. մենք չենք օգտագործել այնպիսի ընդլայնումներ, ինչպիսիք են Jenkins ֆայլերը կամ Ansible-ը: Այնուամենայնիվ, այս պարզ խողովակաշարը լավ աշխատեց, հավանաբար շնորհիվ Պարետոյի սկզբունքի (նաև հայտնի է որպես 80/20 կանոն):
DevOps-ի և CI/CD խողովակաշարի համառոտ ներածություն
Եթե մի քանի մարդկանց հարցնեք՝ «Ի՞նչ է DevOps»-ը, հավանաբար կստանաք մի քանի տարբեր պատասխաններ: DevOps-ը, ինչպես Agile-ը, զարգացել է և ընդգրկում է բազմաթիվ տարբեր առարկաներ, բայց շատերը կհամաձայնեն մի քանի բանի շուրջ. մշակողները գոյություն ունեն այնպիսի միջավայրում, որտեղ.
Գործողությունները, որոնք նախկինում կատարվել են ձեռքով, ավտոմատացվել են.
Յուրաքանչյուրն անում է այն, ինչ անում է լավագույնս;
Որոշակի ժամանակահատվածում իրականացումների քանակը մեծանում է. թողունակությունը մեծանում է;
Զարգացման ճկունության բարձրացում:
Թեև ճիշտ ծրագրային գործիքներ ունենալը միակ բանը չէ, որ անհրաժեշտ է DevOps միջավայր ստեղծելու համար, որոշ գործիքներ կարևոր են: Հիմնական գործիքը շարունակական ինտեգրումն է և շարունակական տեղակայումը (CI/CD): Այս խողովակաշարում միջավայրերն ունեն տարբեր փուլեր (օրինակ՝ DEV, INT, TST, QA, UAT, STG, PROD), շատ գործողություններ ավտոմատացված են, և մշակողները կարող են գրել բարձրորակ կոդ, հասնել զարգացման շարժունության և տեղակայման բարձր տեմպերի:
Այս հոդվածը նկարագրում է հինգ քայլից բաղկացած մոտեցում՝ DevOps խողովակաշար ստեղծելու համար, ինչպես ցույց է տրված հետևյալ դիագրամում՝ բաց կոդով գործիքների միջոցով:
Քայլ 1. CI/CD մեթոդներ
Առաջին բանը, որ ձեզ անհրաժեշտ է, CI/CD գործիքն է: Jenkins-ը՝ Java-ի վրա հիմնված բաց կոդով գործիք և լիցենզավորված MIT լիցենզիայի ներքո, այն գործիքն է, որը հանրաճանաչեց DevOps-ը և դարձավ դե ֆակտո ստանդարտ:
Այսպիսով, ինչ է Ջենքինսը: Մտածեք դա որպես կախարդական ունիվերսալ հեռակառավարման մի տեսակ, որը կարող է խոսել և կազմակերպել տարբեր ծառայություններ և գործիքներ: Ինքնուրույն, Jenkins-ի նման CI/CD գործիքն անօգուտ է, բայց այն դառնում է ավելի հզոր, քանի որ միանում է տարբեր գործիքներին և ծառայություններին:
Jenkins-ը բաց կոդով բազմաթիվ CI/CD գործիքներից մեկն է, որը կարող եք օգտագործել ձեր DevOps խողովակաշարը կառուցելու համար:
Ջենկինս. Creative Commons և MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot՝ GPL
Apache Gump: Apache 2.0
Կաբինետ՝ GNU
Ահա թե ինչպիսի տեսք ունեն DevOps գործընթացները CI/CD գործիքի միջոցով.
Դուք ունեք CI/CD գործիք, որն աշխատում է ձեր localhost-ի վրա, բայց այս պահին շատ բան չեք կարող անել: Եկեք անցնենք DevOps-ի ճանապարհորդության հաջորդ փուլին:
Քայլ 2. Կառավարեք աղբյուրի կառավարման համակարգերը
Լավագույն (և գուցե ամենահեշտ) միջոցը ստուգելու, որ ձեր CI/CD գործիքը կարող է կատարել իր կախարդանքը, ինտեգրվելն է աղբյուրի կոդերի վերահսկման (SCM) գործիքի հետ: Ինչու՞ է ձեզ անհրաժեշտ աղբյուրի վերահսկողությունը: Ենթադրենք, դուք հավելված եք մշակում։ Ամեն անգամ, երբ դուք ստեղծում եք հավելված, դուք ծրագրավորում եք, և կարևոր չէ՝ օգտվում եք Java, Python, C++, Go, Ruby, JavaScript կամ ծրագրավորման հազարավոր լեզուներից: Ձեր գրած կոդը կոչվում է սկզբնական կոդ: Սկզբում, հատկապես երբ մենակ եք աշխատում, ամեն ինչ տեղային գրացուցակում դնելը հավանաբար լավ է: Բայց քանի որ նախագիծն ավելի մեծանում է, և դուք հրավիրում եք այլ մարդկանց համագործակցության, ձեզ անհրաժեշտ է միջոց՝ կանխելու կոնֆլիկտները՝ միաժամանակ արդյունավետ կերպով կիսելով փոփոխությունները: Ձեզ անհրաժեշտ է նաև նախորդ տարբերակները վերականգնելու միջոց, քանի որ կրկնօրինակների ստեղծումը և դրանց մեջ պատճենելը/փակցնելը դառնում է հնացած։ Ձեզ (և ձեր թիմակիցներին) ավելի լավ բան է պետք:
Այստեղ է, որ սկզբնական կոդի վերահսկումը դառնում է գրեթե անհրաժեշտություն: Այս գործիքը պահում է ձեր կոդը պահեստներում, հետևում է տարբերակներին և համակարգում է ծրագրի մասնակիցների աշխատանքը:
Թեև կան բազմաթիվ աղբյուրների վերահսկման գործիքներ, Git-ը ստանդարտ է, և դա ճիշտ է: Ես բարձր խորհուրդ եմ տալիս օգտագործել Git-ը, չնայած, եթե նախընտրում եք, կան բաց կոդով այլ տարբերակներ:
Git՝ GPLv2 և LGPL v2.1
Դիվերսիա՝ Apache 2.0
Համաժամանակյա տարբերակների համակարգ (CVS)՝ GNU
Vesta: LGPL
Mercurial՝ GNU GPL v2+
Ահա թե ինչպիսի տեսք ունի DevOps խողովակաշարը՝ սկզբնաղբյուրի կոդերի հսկիչների ավելացմամբ:
CI/CD գործիքը կարող է ավտոմատացնել վերանայման, սկզբնական կոդի ձեռքբերման և անդամների միջև համագործակցության գործընթացները: Վատ չի? Բայց ինչպե՞ս այն վերածել աշխատանքային հավելվածի, որպեսզի միլիարդավոր մարդիկ կարողանան օգտագործել և գնահատել այն:
Քայլ 3. Ստեղծեք Build Automation Tool
Հիանալի Դուք կարող եք վերանայել կոդը և փոփոխություններ կատարել սկզբնաղբյուրի կառավարման մեջ և հրավիրել ձեր ընկերներին համագործակցելու զարգացման համար: Բայց դուք դեռ հավելված չեք ստեղծել։ Վեբ հավելված ստեղծելու համար այն պետք է կազմվի և փաթեթավորվի տեղակայվող խմբաքանակի ձևաչափով կամ գործարկվի որպես գործարկվող ֆայլ: (Նկատի ունեցեք, որ մեկնաբանված ծրագրավորման լեզուն, ինչպիսին է JavaScript-ը կամ PHP-ն, կարիք չունի կազմման):
Օգտագործեք կառուցման ավտոմատացման գործիք: Անկախ նրանից, թե որ շինարարության ավտոմատացման գործիք եք որոշել օգտագործել, դրանք բոլորն ունեն նույն նպատակը. ստեղծել սկզբնաղբյուրը ցանկալի ձևաչափով և ավտոմատացնել մաքրման, կազմման, փորձարկման և որոշակի միջավայրում տեղակայելու առաջադրանքը: Կառուցման գործիքները կտարբերվեն՝ կախված ձեր ծրագրավորման լեզվից, բայց ահա մի քանի ընդհանուր բաց կոդով տարբերակներ:
Անվանում
Լիցենզիա
Ծրագրավորման լեզու
Maven
Apache 2.0
Java
Մրջյուն
Apache 2.0
Java
Դասարան
Apache 2.0
Java
Բազել
Apache 2.0
Java
Անել
GNU
N / A
փնթփնթոց
MIT
JavaScript
Գուլպ
MIT
JavaScript
Շինարար
Apache
սուտակ
Փոցխ
MIT
սուտակ
ԱԱՊ
GNU
Python
SCons
MIT
Python
BitBake
GPLv2
Python
Թխվածք
MIT
C#
ASDF
Արտագաղթ (MIT)
LISP
Կաբալ
BSD
Haskell- ը
Հիանալի Դուք կարող եք տեղադրել կառուցման ավտոմատացման գործիքի կազմաձևման ֆայլերը ձեր աղբյուրի կառավարման համակարգում և թույլ տալ, որ ձեր CI/CD գործիքը միավորի ամեն ինչ:
Ամեն ինչ լավ է, այնպես չէ՞: Բայց որտեղ տեղակայել ձեր դիմումը:
Քայլ 4. Վեբ հավելվածի սերվեր
Առայժմ դուք ունեք փաթեթավորված ֆայլ, որը կարող է լինել կամ գործարկվող կամ տեղադրել: Որպեսզի ցանկացած հավելված իսկապես օգտակար լինի, այն պետք է տրամադրի ինչ-որ ծառայություն կամ ինտերֆեյս, սակայն ձեզ անհրաժեշտ է կոնտեյներ՝ ձեր հավելվածը տեղադրելու համար:
Վեբ հավելվածի սերվերը հենց այդպիսի կոնտեյներ է: Սերվերը ապահովում է միջավայր, որտեղ կարող է սահմանվել տեղակայվող փաթեթի տրամաբանությունը: Սերվերը նաև տրամադրում է ինտերֆեյս և առաջարկում է վեբ ծառայություններ՝ արտաքին աշխարհին բացելով վարդակները: Այն տեղադրելու համար ձեզ հարկավոր է HTTP սերվեր, ինչպես նաև որոշակի միջավայր (օրինակ՝ վիրտուալ մեքենա): Առայժմ, ենթադրենք, դուք ավելին կիմանաք այս մասին (չնայած ես ներքևում կներկայացնեմ տարաները):
Կան մի քանի բաց կոդով վեբ հավելվածների սերվերներ:
Անվանում
Լիցենզիա
Ծրագրավորման լեզու
Արու կատու
Apache 2.0
Java
Ջեթի
Apache 2.0
Java
WildFly
GNU Lesser Public
Java
Ապակե ձուկ
CDDL & GNU Less Public
Java
Ջանգո
3-Կետ BSD
Python
Տարափ
Apache 2.0
Python
Արքայուղ
MIT
Python
Python
MIT
Python
Rails
MIT
սուտակ
Node.js
MIT
Javascript
Ձեր DevOps խողովակաշարը գրեթե պատրաստ է օգտագործման: Լավ աշխատանք!
Թեև դուք կարող եք կանգ առնել այնտեղ և ինքներդ կարգավորել ինտեգրումը, կոդի որակը կարևոր բան է, որ հավելված մշակողը անհանգստանա:
Քայլ 5. Կոդի փորձարկման ծածկույթ
Թեստերի իրականացումը կարող է լինել ևս մեկ ծանր պահանջ, սակայն ծրագրավորողները պետք է շուտ հայտնաբերեն հավելվածում առկա սխալները և բարելավեն կոդի որակը, որպեսզի վերջնական օգտագործողները բավարարված լինեն: Բարեբախտաբար, կան բազմաթիվ բաց կոդով գործիքներ՝ ձեր կոդը փորձարկելու և դրա որակը բարելավելու համար առաջարկություններ անելու համար: Ավելի լավն այն է, որ CI/CD գործիքների մեծ մասը կարող է միանալ այս գործիքներին և ավտոմատացնել գործընթացը:
Կոդի փորձարկումը բաղկացած է երկու մասից՝ կոդերի փորձարկման շրջանակներ, որոնք օգնում են ձեզ գրել և գործարկել թեստերը, և առաջարկների գործիքներ, որոնք օգնում են բարելավել ձեր կոդի որակը:
Կոդի փորձարկման համակարգեր
Անվանում
Լիցենզիա
Ծրագրավորման լեզու
Յունիտ
Eclipse հանրային լիցենզիա
Java
EasyMock
Apache
Java
mockito
MIT
Java
PowerMock
Apache 2.0
Java
Pytest
MIT
Python
Հիպոթեզ
Mozilla
Python
Տոքսիկ
MIT
Python
Կոդի բարելավման առաջարկությունների համակարգեր
Անվանում
Լիցենզիա
Ծրագրավորման լեզու
Ծածկույթ
GNU
Java
CodeCover
Eclipse Public (EPL)
Java
Coverage.py
Apache 2.0
Python
Emma
Ընդհանուր հանրային լիցենզիա
Java
JaCoCo
Eclipse հանրային լիցենզիա
Java
Հիպոթեզ
Mozilla
Python
Տոքսիկ
MIT
Python
հասմիկ
MIT
JavaScript
Կարման
MIT
JavaScript
Մոխա
MIT
JavaScript
Ջեսթ
MIT
JavaScript
Նկատի ունեցեք, որ վերը նշված գործիքների և շրջանակների մեծ մասը գրված է Java-ի, Python-ի և JavaScript-ի համար, քանի որ C++-ը և C#-ը ծրագրավորման սեփական լեզուներ են (չնայած GCC-ն բաց կոդ է):
Այժմ, երբ դուք ներդրել եք թեստային ծածկույթի գործիքներ, ձեր DevOps խողովակաշարը պետք է նման լինի այս ձեռնարկի սկզբում ցուցադրված դիագրամին:
Լրացուցիչ քայլեր
Բեռնարկղեր
Ինչպես ասացի, դուք կարող եք ձեր սերվերը հյուրընկալել վիրտուալ մեքենայի կամ սերվերի վրա, բայց կոնտեյներները հանրաճանաչ լուծում են:
Ինչ են բեռնարկղերը: Կարճ բացատրությունն այն է, որ վիրտուալ մեքենային անհրաժեշտ է օպերացիոն համակարգի հիշողության հսկայական քանակություն, որը գերազանցում է հավելվածի չափը, մինչդեռ կոնտեյներին անհրաժեշտ են ընդամենը մի քանի գրադարաններ և կոնֆիգուրացիաներ՝ հավելվածը գործարկելու համար: Ակնհայտ է, որ վիրտուալ մեքենայի համար դեռևս կան կարևոր կիրառումներ, բայց կոնտեյները թեթև լուծում է հավելվածը, ներառյալ հավելվածի սերվերը, հոսթինգի համար:
Թեև կան բեռնարկղերի այլ տարբերակներ, ամենատարածվածներն են Docker-ը և Kubernetes-ը:
Docker: Apache 2.0
Kubernetes: Apache 2.0
Միջանկյալ ավտոմատացման գործիքներ
Մեր DevOps խողովակաշարը հիմնականում կենտրոնացած է համատեղ հավելվածների ստեղծման և տեղակայման վրա, բայց կան շատ այլ բաներ, որոնք կարելի է անել DevOps գործիքների միջոցով: Դրանցից մեկը Infrastructure as Code (IaC) գործիքների օգտագործումն է, որոնք հայտնի են նաև որպես միջին ծրագրերի ավտոմատացման գործիքներ։ Այս գործիքներն օգնում են ավտոմատացնել միջին ծրագրակազմի տեղադրումը, կառավարումը և այլ առաջադրանքները: Այսպիսով, օրինակ, ավտոմատացման գործիքը կարող է դուրս հանել այնպիսի ծրագրեր, ինչպիսիք են վեբ հավելվածի սերվերը, տվյալների բազան և մոնիտորինգի գործիքը ճիշտ կոնֆիգուրացիաներով և տեղակայել դրանք հավելվածի սերվերում:
Ահա մի քանի բաց կոդով միջին ծրագրակազմի ավտոմատացման գործիքներ.
Պատասխան՝ GNU Public
SaltStack՝ Apache 2.0
Խոհարար՝ Apache 2.0
Տիկնիկ՝ Apache կամ GPL
Իմացեք մանրամասներ այն մասին, թե ինչպես զրոյից ստանալ պահանջված մասնագիտություն կամ Level Up՝ հմտությունների և աշխատավարձի առումով՝ անցնելով SkillFactory-ից վճարովի առցանց դասընթացներ.
- (12 ամիս)
ավելի շատ դասընթացներ
- (12 շաբաթ)
- (12 ամիս)
- (9 ամիս)
- (9 ամիս)
Օգտակար
Source: www.habr.com