Бұл біліммен қайда бару керек, жобада не істеу керек және қанша табуға болады, сұхбатта не айту керек және не сұрау керек - дейді Экспресс 42 басқарушы серіктесі және авторы Александр Титов .
Сәлеметсіз бе! DevOps термині 2009 жылдан бері бар болса да, орыс қауымдастығында әлі күнге дейін консенсус жоқ. Кейбіреулер DevOps-ті мамандық, басқалары оны философия, ал басқалары терминді технологиялар жиынтығы деп санайтынын байқаған боларсыз. Мен бірнеше рет өнер көрсеттім осы бағыттың дамуы туралы, сондықтан мен бұл мақалада егжей-тегжейлі тоқталмаймын. Айта кетейін, Express 42-де біз оған мыналарды қосамыз:
DevOps - бұл командадағы барлық мамандар өндіріске қатысқан кездегі нақты әдістеме, цифрлық өнімді жасау мәдениеті.
Классикалық корпоративтік дамуда бәрі дәйекті түрде жүреді: бағдарламалау, тестілеу және содан кейін ғана операция, және бұл процестің идеядан өндіріске дейінгі жылдамдығы 3 ай. Бұл цифрлық өнімдер үшін жаһандық мәселе, себебі тұтынушылардан кері пікірді жылдам алу мүмкін емес.
DevOps жүйесінде құралдар мен тәсілдер әзірлеу, тестілеу және операциялық процестердің бір уақытта орындалуын қамтамасыз ету үшін жасалған.
Бұл тәсілден не шығады?
- Өндірістің барлық мәселелерін шешетін кейбір «инженерді» жалдай алмайсыз. Бүкіл команда техниканы қолдануы керек.
- DevOps жүйесі жаңартылатын келесі жүйе басқару формасы ЕМЕС. «DevOps инженері» шамамен «Agile әзірлеуші » сияқты естіледі.
- Егер команда Kubernetes, Ansible, Prometheus, Mesosphere және Docker қолданбаларын пайдаланса, бұл DevOps тәжірибелері сонда іске асырылды дегенді білдірмейді.
DevOps-тен кейінгі өмір ешқашан бұрынғыдай болмайды
DevOps тәсілі - бұл, ең алдымен, ойлаудың басқа тәсілі, дамуды тұтастай қабылдау және процестегі адамның орны. Біз онлайн курсымызды 2 блокқа бөлдік:
1. Өзін-өзі анықтау
Біріншіден, біз DevOps әдісінің мәнін егжей-тегжейлі қарастырамыз және студенттер топтағы жаңа рөлдерді тауып, қайсысы көбірек жауап беретінін көреді және қай бағытты дамыту керектігін өздері анықтайды.
2. Құралдар мен тәжірибелер
Студенттер нақты технологияларды DevOps әдісі тұрғысынан игереді.
DevOps құралдарын DevOps әдісінде де, классикалық әзірлеуде де пайдалануға болады. Ең айқын мысал Ansible конфигурациясын басқару құралын пайдалану болады. Ол DevOps «Инфрақұрылым код ретінде» тәжірибесін жүзеге асыру үшін жасалған және ойластырылған, яғни операциялық жүйе параметрлерінен қолданбалы бағдарламалық құралға дейін жүйенің әртүрлі күйлері сипатталған. Сипаттама қабаттарға бөлінген және күрделі, үнемі өзгеретін конфигурацияны басқаруға мүмкіндік береді. Бірақ инженерлер Ansible бағдарламасын бірнеше машиналарда bash сценарийлерін іске қосу әдісі ретінде жиі пайдаланады. Бұл жаман да, жақсы да емес, бірақ Ansible-дің болуы компанияда DevOps-тің болуына кепілдік бермейтінін түсінуіңіз керек.
Біз процесте жатырмыз Сіз атақты Reddit-ке ұқсас қосымшаны әзірлеу процесіне еніп кетесіз, оның монолитті нұсқасынан бастап, микросервистерге біртіндеп көшу. Біртіндеп біз жаңа құралдарды игереміз: Git, Ansible, Gitlab және Кубернетес пен Прометеймен аяқтаймыз.
Тәжірибе тұрғысынан біз DevOps анықтамалығында сипатталған үш жолдың тактикасын ұстанамыз - үздіксіз жеткізу тәжірибесі, кері байланыс тәжірибесі және бүкіл курстың мәні сіздің жүйеңізбен бірге үздіксіз оқу тәжірибесі болып табылады.
Бұл білім мамандардың әрқайсысына не береді?
Жүйе әкімшілері үшін
Тәжірибе сізге әкімшіліктен үзіліссіз жеткізу құбырын және бағдарламалық қамтамасыз етуді жеткізуге арналған инфрақұрылымдық платформаны құруға көшуге мүмкіндік береді. Мәселе мынада, ол өнімді жасайды - әзірлеушілерге олардың өзгерістерін өндіріске тез итермелеуге көмектесетін инфрақұрылымдық платформа.
Бұрын жүйелік әкімшілер соңғы бастион болды, содан кейін барлығы өндіріске енеді. Негізінен олар үздіксіз өрт сөндірумен айналысты - осыған байланысты бизнестің қажеттіліктерін білу, өнім мен пайдаланушы үшін артықшылықтар туралы ойлау өте қиын.
DevOps әдісінің арқасында ойлау өзгереді. Жүйе әкімшісі конфигурацияны кодқа қалай аудару керектігін, бұл үшін қандай тәжірибелер бар екенін түсінеді.
Бұл өте маңызды, өйткені компаниялар барлығын автоматтандырудың қажеті жоқ екенін көбірек түсінеді, яғни. Бұрынғы жүйе әкімшілері не істеуге үйренген, олар бұл туралы аз хабардар етті және командаға енгізілген барлық өзгерістер туралы хабардар етпеді. Қазір командалар ішкі инфрақұрылым өнімін өндіруші болатын және бөлінген процестерді бір жүйеге біріктіруге көмектесетіндерді іздеуде.
Әзірлеушілер
Әзірлеуші тек алгоритмдерде ойлауды тоқтатады. Ол инфрақұрылыммен жұмыс істеу дағдысын, ландшафтты сәулеттік сезіну дағдысын меңгереді. Мұндай әзірлеуші қолданбаның қалай жұмыс істейтінін, оның үздіксіз жеткізу құбырынан қалай өтетінін, оны бақылауды, клиентке пайда әкелетіндей оны қалай тіркеу керектігін түсінеді. Нәтижесінде бұл білімнің барлығы сәйкес кодты жазуға мүмкіндік береді.
Сынақшыларға арналған
Тестілеу көптен бері автоматты режимге өтіп жатыр, біз бәріміз көптеген сынақтар жасалмауы керек деп айтамыз, бірақ жазбаша :) Тестілеу сіздің өніміңізді жеткізудің барлық бөлігі болып табылады. Тестілеушіге кодты жазуды үйрену ғана емес, сонымен қатар оны үздіксіз жеткізу жүйелеріне қалай біріктіру керектігін, жеткізудің барлық кезеңдерінде кодтан кері байланыс алуды және қателерді анықтау үшін тестілеуді үнемі жақсартуды түсіну керек. мүмкіндігінше ертерек.
Демек, солай болып шығады барлық үш кезең бір уақытта орын алады. Мысалы, ол келесідей болуы мүмкін:
Әзірлеуші кодты жазады, ол үшін сынақтарды дереу жазады және іске қосылуы керек код үшін докер контейнерін сипаттайды. Сондай-ақ өндірісте осы қызметтің жұмысын қадағалайтын мониторингті бірден сипаттайды және осының бәрін міндеттейді.
Үздіксіз интеграция басталғанда, процестер бір уақытта орындалады. Қызмет басталады және конфигурацияланады. Бұл кезде докер контейнері іске қосылады және оның жұмыс істеп тұрғаны тексеріледі. Бұл ретте барлық ақпарат каротаж жүйесіне түседі. Және т.б. дамудың әрбір кезеңінде - бұл жүйелік әкімшілер, әзірлеушілер және тестілеушілердің нақты командалық жұмысы болып шығады.
Мен DevOps-ты оқыдым, әрі қарай не істеу керек?
Өздеріңіз білетіндей, даладағы біреуі жауынгер емес. Егер сіздің компанияңыз бұл әдісті қолданбаса, алынған дағдылар бос қалады. DevOps тәсілдерімен танысқаннан кейін, сіз корпоративтік дамуда тісті болғыңыз келмейтін шығар. Бір ерекшелік болуы мүмкін: сіз команданың жүйелік әкімшісісіз және барлық процестерді жаңа жолмен қайта құра аласыз. Бұл тәсілді қолданатын көптеген компаниялар бар екенін және олар құлыптан зардап шекпей, мамандар іздейтінін айта кеткен жөн. Өйткені DevOps онлайн өнімдерді жасау туралы.
Ал енді жақсы нәрселер туралы: DevOps тәжірибелері мен құралдарын меңгеру еңбек нарығындағы құндылығыңызға шамамен +30% құрайды. Жалақы 140 мың рубльден басталады, бірақ, әрине, сіздің негізгі мамандығыңыз бен функционалдылығыңызға байланысты анықталады.
Сіз «инфрақұрылымға бағытталған» деп белгіленген бос жұмыс орындарын көре аласыз, мұнда тестілеуді автоматтандыру, бұлттық технологияларды пайдалана отырып микросервис қосымшаларын әзірлеу, инфрақұрылым инженерлеріне арналған бос орындар және DevOps-қа барлық сілтемелер бар. Әр компанияның бұл анықтамасы басқа нәрсені білдіретінін есте сақтаңыз - сипаттаманы мұқият оқып шығыңыз.
Курсымызды іске қосу кезінде маған түсінік келді - курстан кейін көптеген адамдар DevOps инженерінің тұзағына түседі. Олар жоғарыда аталған атаумен бос орынды тауып, жақсы ұсыныс алады, содан кейін жұмысқа келіп, Дженкинсте үш беттік bash сценарийін сақтау керек екенін түсінеді. Kubernetes, ChatOps, канарейлар және басқалары қайда? Бірақ ештеңе жоқ, өйткені компанияға әдістеме ретінде DevOps қажет емес, жеке инновацияларды пайдаланады.
Бұл компаниядан бағдарламалық қамтамасыз етуді жеткізу процесі қалай жұмыс істейтінін, технология стегін және сіз қандай жауапкершіліктерді орындайтыныңызды білуге себеп.
Егер жұмыс беруші сіздің сұрақтарыңызға кітаптағыдай дерексіз жауап берсе, онда компанияда DevOps процесі әлі жоқ, бірақ бұл бас тартуға, компанияны және оның өнімдерін, онлайн бар-жоғын зерттеуге себеп емес. компания өзі әзірлейтін қызметтер, мобильді қосымшалар, өнім идеялары.
Егер иә болса, онда сізге осы жүйелермен тікелей жұмыс істеу керек пе немесе DevOps тәжірибесінде жақсы нәтижелер көрсете отырып, осы қызметтердің топтарына көлденең жылжу мүмкіндігі бар ма екенін түсіндіріңіз. Егер солай болса, онда белсенді және пайдалы болуға тұрарлық, ал егер сіз біздің курсты аяқтасаңыз, соңғысына кепілдік беріледі.
Devops практиктері әзірлеу/басқару/тестілеу тәжірибесімен ғана шынайы құндылыққа ие болатындығын атап өту маңызды. Сонда ғана білім абстрактілі емес, маманды (барлық мағынада) байытады. Сондықтан, «DevOps-ті нөлден үйрену» идеясы, егер сіз ешқашан қолыңызда камера ұстамаған болсаңыз немесе түсірілім жүргізбеген болсаңыз, «линзаларды нөлден пайдалануды» үйренумен бірдей. Курс сізге сәйкес келетінін анықтауға көмектесу үшін біз сіздің жеткілікті білім деңгейіңізді тексеретін қабылдау тестін жасадық.
Менің ойымша, амалдардың бірі — оқыту барысында әрбір студент қай бағытта дамытқысы келетінін өзі анықтайды. Әзірлеуші инфрақұрылым инженері болған кезде біз жиі ауысуларды көреміз, ал әкімші оның код жазуға мүдделі екенін түсінеді - содан кейін ол тілді әрі қарай зерттейді және оны DevOps алған дағдыларымен толықтырады. Сондықтан, біз мансап жол айрығында тұрып қалғанын сезетіндерді ерекше қарсы аламыз. Курс 28 мамырда басталады, бірақ сабақ басталғаннан кейін 2 аптадан кейін қосыла аласыз. Бағдарламаны қарап, сынақтан өтуге болады . OTUS-да кездескенше!
Ақпарат көзі: www.habr.com