Біз блогымызды техникалық директорымыздың соңғы сөздеріне негізделген жарияланымдардан бастаймыз (Дмитрий Столяров). Олардың барлығы 2016 жылы әртүрлі кәсіби іс-шараларда өтті және DevOps және Docker тақырыбына арналды. Badoo кеңсесіндегі Docker Мәскеу кездесуінен бір бейне, бізде қазірдің өзінде бар сайтта. Жаңалары баяндамалардың мәнін жеткізетін мақалалармен қоса беріледі. Сонымен…
31 мамырда конференцияда , «Russian Internet Technologies» (RIT++ 2016) фестивалі аясында өткен «Үздіксіз орналастыру және орналастыру» бөлімі «Docker көмегімен үздіксіз жеткізудің үздік тәжірибелері» баяндамасымен ашылды. Ол Docker және басқа да ашық бастапқы өнімдерді пайдалана отырып, үздіксіз жеткізу (CD) процесін құрудың ең жақсы тәжірибелерін жинақтап, жүйеледі. Біз өндірісте осы шешімдермен жұмыс істейміз, бұл практикалық тәжірибеге сүйенуге мүмкіндік береді.
Бір сағатты өткізуге мүмкіндігіңіз болса , толық қарауды ұсынамыз. Әйтпесе, төменде мәтін түріндегі негізгі түйіндеме берілген.
Docker көмегімен үздіксіз жеткізу
By Үздіксіз жеткізу біз оқиғалар тізбегін түсінеміз, соның нәтижесінде Git репозиторийіндегі қолданба коды алдымен өндіріске келеді, содан кейін мұрағатта аяқталады. Бұл келесідей көрінеді: Git → Құру → Сынақ → Шығару → Жұмыс істеу.
Есептің көп бөлігі құрастыру кезеңіне (қолданба құрастыру) арналған және шығарылатын және жұмыс істейтін тақырыптар қысқаша қозғалады. Біз оларды шешуге мүмкіндік беретін проблемалар мен үлгілер туралы айтатын боламыз және бұл үлгілердің нақты іске асырылуы әртүрлі болуы мүмкін.
Неліктен Docker мұнда қажет? Осы Open Source құралының контекстінде Үздіксіз жеткізу тәжірибесі туралы айтуды бекер емес деп шештік. Бүкіл есеп оны пайдалануға арналған болса да, қолданба кодын шығарудың негізгі үлгісін қарастырған кезде көптеген себептер анықталады.
Негізгі шығару үлгісі
Сонымен, біз қосымшаның жаңа нұсқаларын шығарған кезде, біз міндетті түрде тап боламыз тоқтап қалу мәселесі, өндірістік серверді ауыстыру кезінде жасалған. Қолданбаның ескі нұсқасынан жаңасына трафик бірден ауыса алмайды: алдымен жаңа нұсқа сәтті жүктеліп қана қоймай, сонымен қатар «жылытылған» (яғни, сұрауларға қызмет көрсетуге толығымен дайын) болуы керек.
Осылайша, біраз уақыт қосымшаның екі нұсқасы да (ескі және жаңа) бір уақытта жұмыс істейді. Бұл автоматты түрде әкеледі ортақ ресурстар қақтығысы: желі, файлдық жүйе, IPC және т.б. Docker көмегімен бұл мәселе бөлек контейнерлерде қолданбаның әртүрлі нұсқаларын іске қосу арқылы оңай шешіледі, ол үшін бір хост (сервер/виртуалды машина) ішінде ресурстарды оқшаулауға кепілдік беріледі. Әрине, сіз оқшаулаусыз кейбір трюктармен өте аласыз, бірақ егер дайын және ыңғайлы құрал болса, онда қарама-қарсы себеп бар - оны елемеуге болмайды.
Контейнеризация орналастыру кезінде басқа да көптеген артықшылықтарды береді. Кез келген қолданба байланысты нақты нұсқасы (немесе нұсқа ауқымы) аудармашы, модульдердің/кеңейтімдердің болуы және т.б., сондай-ақ олардың нұсқалары. Және бұл тек тікелей орындалатын ортаға ғана емес, сонымен қатар бүкіл ортаға, соның ішінде жүйелік бағдарламалық қамтамасыз ету және оның нұсқасы (пайдаланылатын Linux дистрибутивіне дейін). Контейнерлер тек қолданбалы кодты ғана емес, сонымен қатар алдын ала орнатылған жүйелік және қажетті нұсқалардың қолданбалы бағдарламалық жасақтамасын қамтитындықтан, тәуелділік мәселелерін ұмытуға болады.
Жалпыланған негізгі шығару үлгісі келесі факторларды ескере отырып, жаңа нұсқалар:
- Алдымен қолданбаның ескі нұсқасы бірінші контейнерде жұмыс істейді.
- Содан кейін жаңа нұсқа жайылып, екінші контейнерге «жылытылады». Бір қызығы, бұл жаңа нұсқаның өзі тек жаңартылған қолданба кодын ғана емес, сонымен қатар оның кез келген тәуелділіктерін, сондай-ақ жүйелік құрамдастарды (мысалы, OpenSSL жаңа нұсқасы немесе бүкіл тарату) қамтуы мүмкін.
- Жаңа нұсқа сұрауларға қызмет көрсетуге толығымен дайын болғанда, трафик бірінші контейнерден екіншісіне ауысады.
- Ескі нұсқаны енді тоқтатуға болады.
Қолданбаның әртүрлі нұсқаларын бөлек контейнерлерде орналастырудың бұл тәсілі тағы бір ыңғайлылықты қамтамасыз етеді - жылдам кері қайтару ескі нұсқаға (ақыр соңында, трафикті қажетті контейнерге ауыстыру жеткілікті).
Соңғы бірінші ұсыныс тіпті капитанның кінәсін таба алмайтын нәрсеге ұқсайды: «[Docker көмегімен үздіксіз жеткізуді ұйымдастыру кезінде] Docker пайдаланыңыз [және оның не беретінін түсіну]" Есіңізде болсын, бұл кез келген мәселені шешетін күміс оқ емес, керемет негіз беретін құрал.
Қайта шығару мүмкіндігі
«Жаңғыртылатындық» деп біз қолданбаларды пайдалану кезінде кездесетін мәселелердің жалпыланған жиынтығын түсінеміз. Біз мұндай жағдайлар туралы айтып отырмыз:
- Сапа бөлімі сахналау үшін тексерген сценарийлер өндірісте дәл қайталануы керек.
- Қолданбалар әртүрлі репозиторий айналарынан пакеттерді қабылдай алатын серверлерде жарияланады (уақыт өте келе олар жаңартылады және олармен орнатылған қолданбалардың нұсқалары).
- «Мен үшін жергілікті жерде бәрі жұмыс істейді!» (...және әзірлеушілерге өндіріске рұқсат етілмейді.)
- Ескі (мұрағатталған) нұсқада бір нәрсені тексеру керек.
- ...
Олардың жалпы мәні пайдаланылатын ортаның толық сәйкестігі (сонымен қатар адам факторының болмауы) қажет екендігіне байланысты. Қайта шығаруға қалай кепілдік бере аламыз? Docker кескіндерін жасаңыз Git кодына негізделген, содан кейін оларды кез келген тапсырма үшін пайдаланыңыз: сынақ алаңдарында, өндірісте, бағдарламашылардың жергілікті машиналарында ... Бұл ретте орындалатын әрекеттерді барынша азайту маңызды. после кескінді құрастыру: ол неғұрлым қарапайым болса, қателер болуы ықтимал.
Инфрақұрылым - бұл код
Инфрақұрылым талаптары (серверлік бағдарламалық құралдың қолжетімділігі, оның нұсқасы және т.б.) ресімделмеген және «бағдарламаланбаған» болса, кез келген қолданба жаңартуын шығару апатты салдарға әкелуі мүмкін. Мысалы, сахналау кезінде сіз PHP 7.0-ге ауыстыңыз және кодты сәйкесінше қайта жаздыңыз - онда оның кейбір ескі PHP (5.5) көмегімен өндірістегі көрінісі біреуді таң қалдыратыны сөзсіз. Аудармашы нұсқасындағы үлкен өзгерісті ұмытпауыңыз мүмкін, бірақ «шайтан егжей-тегжейлі»: тосынсый кез келген тәуелділіктің шағын жаңартуында болуы мүмкін.
Бұл мәселені шешу тәсілі белгілі IaC (Инфрақұрылым код ретінде, «инфрақұрылым код ретінде») және қолданбалы кодпен бірге инфрақұрылым талаптарын сақтауды қамтиды. Оны пайдалана отырып, әзірлеушілер мен DevOps мамандары бір Git қолданбасының репозиторийімен жұмыс істей алады, бірақ оның әртүрлі бөліктерінде. Бұл кодтан Git-те Docker кескіні жасалады, онда қосымша инфрақұрылымның барлық ерекшеліктерін ескере отырып орналастырылады. Қарапайым тілмен айтқанда, кескіндерді құрастыруға арналған сценарийлер (ережелер) бастапқы кодпен бір репозиторийде болуы және біріктірілуі керек.
Көп деңгейлі қолданба архитектурасы жағдайында - мысалы, Docker контейнерінде жұмыс істеп тұрған қолданбаның алдында тұрған nginx бар - Docker кескіндері әр қабат үшін Git кодынан жасалуы керек. Содан кейін бірінші суретте аудармашы және басқа «жақын» тәуелділіктері бар қолданба болады, ал екінші суретте жоғарғы nginx болады.
Докер кескіндері, Git-пен байланыс
Біз Git-тен жиналған барлық Docker кескіндерін екі санатқа бөлеміз: уақытша және босату. Уақытша суреттер Git-тегі филиал атымен тегтелген, келесі тапсырма арқылы қайта жазылуы мүмкін және тек алдын ала қарау үшін шығарылады (өндіріс үшін емес). Бұл олардың шығарылымдардан негізгі айырмашылығы: оларда қандай нақты міндеттеме бар екенін ешқашан білмейсіз.
Уақытша кескіндерге жинақтау мағынасы бар: негізгі бөлім (бастың ағымдағы нұсқасын үнемі көру үшін оны автоматты түрде бөлек сайтқа шығаруға болады), шығарылымдары бар филиалдар, нақты инновациялардың тармақтары.
Уақытша кескіндерді алдын ала қарау өндіріске аудару қажеттілігіне келгеннен кейін әзірлеушілер белгілі бір тегті қояды. Тег бойынша автоматты түрде жиналады суретті шығару (оның тегі Git тегіне сәйкес келеді) және сахнаға шығарылады. Сапа бөлімінен сәтті тексерілсе, өндіріске кетеді.
Dapper
Сипатталғандардың барлығын (шығарылым, кескінді құрастыру, кейінгі техникалық қызмет көрсету) Bash сценарийлерін және басқа «импровизацияланған» құралдарды пайдаланып дербес жүзеге асыруға болады. Бірақ егер сіз мұны жасасаңыз, онда бір сәтте іске асыру үлкен күрделілікке және нашар бақылауға әкеледі. Осыны түсіне отырып, біз CI/CD құруға арналған мамандандырылған Workflow утилитасын жасауға келдік - Dapper.
Оның бастапқы коды Ruby тілінде жазылған, ашық бастапқы код және жарияланады . Өкінішке орай, құжаттама қазіргі уақытта құралдың ең әлсіз жері болып табылады, бірақ біз онымен жұмыс істеп жатырмыз. Ал біз дап туралы бірнеше рет жазып, сөйлесетін боламыз, өйткені... Біз оның мүмкіндіктерін бүкіл мүдделі қауымдастықпен бөлісуді шын жүректен күте алмаймыз, бірақ әзірше мәселелеріңізді жіберіңіз және сұрауларыңызды алыңыз және/немесе GitHub-та жобаның дамуын қадағалаңыз.
13 жылғы 2019 тамызда жаңартылды: қазіргі уақытта жоба Dapper деп өзгертілді , оның коды Go бағдарламасында толығымен қайта жазылды және оның құжаттамасы айтарлықтай жетілдірілді.
Kubernetes
Кәсіби ортада айтарлықтай мойындалған тағы бір дайын Open Source құралы Kubernetes, Docker басқару кластері. Докерде құрастырылған жобалардың жұмысында оны пайдалану тақырыбы есептің ауқымынан тыс, сондықтан презентация кейбір қызықты мүмкіндіктерді шолумен шектеледі.
Шығарылым үшін Kubernetes ұсынады:
- дайындық зонды — қосымшаның жаңа нұсқасының дайындығын тексеру (оған трафикті ауыстыру үшін);
- жылжымалы жаңарту – контейнерлер кластеріндегі кескінді дәйекті жаңарту (өшіру, жаңарту, іске қосуға дайындық, трафикті ауыстыру);
- синхронды жаңарту - кластердегі суретті басқа тәсілмен жаңарту: алдымен контейнерлердің жартысында, содан кейін қалғандарында;
- canary релиздері - ауытқуларды бақылау үшін контейнерлердің шектеулі (шағын) санына жаңа кескінді іске қосу.
Үздіксіз жеткізу тек жаңа нұсқаның шығарылымы ғана емес болғандықтан, Kubernetes-те инфрақұрылымға кейінгі техникалық қызмет көрсету үшін бірқатар мүмкіндіктер бар: барлық контейнерлер үшін кірістірілген бақылау және журнал жүргізу, автоматты масштабтау, т.б.. Мұның бәрі қазірдің өзінде жұмыс істеп тұр және тек дұрыс жұмысты күтуде. процестеріңізге енгізу.
Қорытынды ұсыныстар
- Docker пайдаланыңыз.
- Барлық қажеттіліктеріңізге арналған қолданбалардың Docker кескіндерін жасаңыз.
- «Инфрақұрылым - бұл код» принципін ұстаныңыз.
- Git-ті Docker-ге байланыстырыңыз.
- Шығарылу тәртібін реттеңіз.
- Дайын платформаны пайдаланыңыз (Кубернетес немесе басқа).
Бейнелер мен слайдтар
Спектакльден бейне (шамамен бір сағат) (есептің өзі 5-ші минуттан басталады - осы сәттен бастап ойнау үшін сілтемеге өтіңіз).
Баяндаманы көрсету:
PS
Біздің блогтағы тақырып бойынша басқа есептер:
- «» (Дмитрий Столяров; 27 жылғы 2019 мамырда DevOpsConf-те);
- «» (Дмитрий Столяров; 8 жылғы 2018 қарашада HighLoad++);
- «» (Дмитрий Столяров; 7 жылғы 2017 қарашада HighLoad++);
- «» (Дмитрий Столяров; 6 жылғы 2017 маусымда RootConf сайтында).
Ақпарат көзі: www.habr.com