Біз True Engineering компаниясында тұтынушы серверлеріне жаңартуларды үздіксіз жеткізу процесін орнаттық және осы тәжірибемен бөліскіміз келеді.
Алдымен біз тұтынушыға арналған онлайн жүйені әзірледік және оны жеке Kubernetes кластерінде орналастырдық. Енді біздің жоғары жүктемелі шешіміміз тұтынушының платформасына көшті, ол үшін біз толық автоматты Үздіксіз орналастыру процесін орнаттық. Осының арқасында біз нарыққа шығу уақытын - өнімнің ортасына өзгерістерді жеткізуді жылдамдаттық.
Бұл мақалада біз үздіксіз орналастыру (CD) процесінің барлық кезеңдері немесе тұтынушы платформасына жаңартуларды жеткізу туралы айтатын боламыз:
- Бұл процесс қалай басталады?
- тұтынушының Git репозиторийімен синхрондау,
- backend және frontend құрастыру,
- сынақ ортасында қолданбаны автоматты түрде орналастыру,
- өнімге автоматты түрде орналастыру.
Орнату мәліметтерін жолда бөлісеміз.
1. Ықшам дискіні іске қосыңыз
Үздіксіз орналастыру әзірлеушінің Git репозиторийінің шығарылым тармағына өзгерістер енгізуінен басталады.
Біздің қолданба микросервис архитектурасында жұмыс істейді және оның барлық құрамдастары бір репозиторийде сақталады. Осының арқасында олардың біреуі өзгерсе де, барлық микросервистер жиналады және орнатылады.
Біз бірнеше себептерге байланысты бір репозиторий арқылы жұмыс ұйымдастырдық:
- Әзірлеудің қарапайымдылығы - қолданба белсенді дамып келеді, сондықтан сіз бірден барлық кодпен жұмыс істей аласыз.
- Қолданбаның бір жүйе ретінде барлық сынақтардан өтетініне және тұтынушының өндірістік ортасына жеткізілетініне кепілдік беретін жалғыз CI/CD құбыры.
- Біз нұсқалардағы шатасуларды жоямыз - микросервис нұсқаларының картасын сақтаудың және Helm сценарийлеріндегі әрбір микросервис үшін оның конфигурациясын сипаттаудың қажеті жоқ.
2. Тұтынушының бастапқы кодының Git репозиторийімен синхрондау
Жасалған өзгертулер тұтынушының Git репозиторийімен автоматты түрде синхрондалады. Онда қолданба жинағы конфигурацияланады, ол тармақты жаңартқаннан кейін іске қосылады және жалғастыру үшін орналастыру. Екі процесс өз ортасында Git репозиторийінен басталады.
Біз тұтынушының репозиторийімен тікелей жұмыс істей алмаймыз, өйткені бізге әзірлеу және сынақтан өткізу үшін өз орталарымыз қажет. Біз Git репозиторийін осы мақсаттар үшін пайдаланамыз - ол олардың Git репозиторийімен синхрондалады. Әзірлеуші біздің репозиторийдің сәйкес тармағына өзгерістерді жариялағаннан кейін, GitLab бұл өзгерістерді тұтынушыға дереу жібереді.
Осыдан кейін сіз құрастыруды орындауыңыз керек. Ол бірнеше кезеңнен тұрады: серверлік және фронталды құрастыру, сынау және өндіріске жеткізу.
3. Бэк және фронтенді құрастыру
Backend және frontend құру - GitLab Runner жүйесінде орындалатын екі параллель тапсырма. Оның бастапқы құрастыру конфигурациясы сол репозиторийде орналасқан.
.
GitLab Runner қажетті репозиторийден кодты алады, оны Java қолданбасын құрастыру пәрменімен жинайды және оны Docker тізіліміне жібереді. Мұнда біз сервер мен фронталды жинаймыз, Docker кескіндерін аламыз, оларды тұтынушы жағындағы репозиторийге орналастырамыз. Docker кескіндерін басқару үшін біз қолданамыз .
Біз кескіндеріміздің нұсқаларын Docker-те жарияланатын шығарылым нұсқасымен синхрондаймыз. Бірқалыпты жұмыс істеу үшін біз бірнеше түзетулер жасадық:
1. Контейнерлер сынақ ортасы мен өндірістік орта арасында қайта салынбайды. Бір контейнер барлық параметрлермен, орта айнымалыларымен және қызметтермен сынақ ортасында да, өндірісте де қайта құрусыз жұмыс істей алатындай етіп параметрлеулер жасадық.
2. Helm арқылы қолданбаны жаңарту үшін оның нұсқасын көрсету керек. Біз серверді, фронтендті құрастырамыз және қолданбаны жаңартамыз - бұл үш түрлі тапсырма, сондықтан қолданбаның бір нұсқасын барлық жерде пайдалану маңызды. Бұл тапсырма үшін біз Git тарихынан деректерді пайдаланамыз, өйткені біздің K8S кластер конфигурациясы мен қолданбалары бір Git репозиторийінде.
Қолданба нұсқасын команданың орындалу нәтижелерінен аламыз
git describe --tags --abbrev=7.
4. Сынақ ортасына барлық өзгерістерді автоматты түрде енгізу (UAT)
Бұл құрастыру сценарийіндегі келесі қадам K8S кластерін автоматты түрде жаңарту болып табылады. Бұл бүкіл қолданба құрастырылған және барлық артефактілер Docker тізіліміне жарияланған жағдайда орын алады. Осыдан кейін сынақ ортасын жаңарту басталады.
Кластерді жаңарту қолданыла бастады . Егер нәтижесінде бірдеңе жоспарға сай болмаса, Helm автоматты түрде және өз бетінше барлық өзгерістерін кері қайтарады. Оның жұмысын бақылаудың қажеті жоқ.
Біз K8S кластерінің конфигурациясын жинақпен бірге жеткіземіз. Сондықтан келесі қадам оны жаңарту болып табылады: configMaps, орналастырулар, қызметтер, құпиялар және біз өзгерткен кез келген басқа K8S конфигурациялары.
Содан кейін Helm сынақ ортасында қолданбаның RollOut жаңартуын іске қосады. Қолданба өндіріске енгізілмес бұрын. Бұл пайдаланушылар сынақ ортасына енгізген бизнес мүмкіндіктерін қолмен тексере алатындай етіп жасалады.
5. Өнімге барлық өзгерістерді автоматты түрде енгізу
Өндіріс ортасына жаңартуды енгізу үшін сізге GitLab жүйесінде бір түймені басу жеткілікті - және контейнерлер бірден өндіріс ортасына жеткізіледі.
Бір қолданба әртүрлі орталарда (сынау және өндіріс) қайта құрусыз жұмыс істей алады. Біз бірдей артефактілерді қолданбада ештеңені өзгертпей қолданамыз және параметрлерді сырттан орнатамыз.
Қолданба параметрлерінің икемді параметрленуі қолданба орындалатын ортаға байланысты. Біз барлық орта параметрлерін сыртқа жылжыттық: барлығы K8S конфигурациясы және Helm параметрлері арқылы параметрленген. Helm жинақты сынақ ортасына орналастырғанда, сынақ параметрлері оған қолданылады, ал өнім параметрлері өндіріс ортасына қолданылады.
Ең қиыны қоршаған ортаға тәуелді барлық пайдаланылған қызметтер мен айнымалыларды параметрлеу және оларды орта айнымалыларына және Helm үшін орта параметрлерінің сипаттама-конфигурацияларына аудару болды.
Қолданба параметрлері орта айнымалыларын пайдаланады. Олардың мәндері Go үлгілері арқылы үлгіленген K8S конфигмациясы арқылы контейнерлерде орнатылады. Мысалы, домен атына орта айнымалы мәнін орнату келесідей орындалуы мүмкін:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – бұл айнымалы ортаның атын сақтайды (өнім, кезең, UAT).
.Values.app.properties.app_external_domain – бұл айнымалыда .Values.yaml файлында қалаған доменді орнатамыз
Қолданбаны жаңарту кезінде Helm шаблондардан configmap.yaml файлын жасайды және қолданба жаңартуы басталатын ортаға байланысты APP_EXTERNAL_DOMAIN мәнін қажетті мәнмен толтырады. Бұл айнымалы мән контейнерде орнатылған. Оған қолданбадан қол жеткізуге болады, сондықтан әрбір қолданба ортасы осы айнымалы үшін басқа мәнге ие болады.
Салыстырмалы түрде жақында Spring Cloud-та K8S қолдауы пайда болды, соның ішінде configMaps-пен жұмыс істеу: . Жоба белсенді дамып, түбегейлі өзгеріп жатқанда, біз оны өндірісте пайдалана алмаймыз. Бірақ біз оның жағдайын белсенді түрде бақылап, оны DEV конфигурацияларында қолданамыз. Ол тұрақтана салысымен, біз қоршаған ортаның айнымалы мәндерін пайдаланудан оған ауысамыз.
Барлығы
Осылайша, Үздіксіз орналастыру конфигурацияланған және жұмыс істейді. Барлық жаңартулар бір пернені басу арқылы орындалады. Өнімнің ортасына өзгерістерді жеткізу автоматты түрде жүзеге асырылады. Және, ең бастысы, жаңартулар жүйені тоқтатпайды.
Болашақ жоспарлар: мәліметтер базасын автоматты көшіру
Біз дерекқорды жаңарту және бұл өзгерістерді кері қайтару мүмкіндігі туралы ойладық. Өйткені, қосымшаның екі түрлі нұсқасы бір уақытта жұмыс істейді: ескісі жұмыс істейді, ал жаңасы жұмыс істейді. Ал жаңа нұсқаның жұмыс істейтініне сенімді болған кезде ғана ескісін өшіреміз. Дерекқорды тасымалдау қолданбаның екі нұсқасымен де жұмыс істеуге мүмкіндік беруі керек.
Сондықтан біз жай ғана баған атауын немесе басқа деректерді өзгерте алмаймыз. Бірақ біз жаңа баған жасай аламыз, оған ескі бағандағы деректерді көшіре аламыз және деректерді жаңартқан кезде оны бір уақытта басқа бағанға көшіріп, жаңартатын триггерлерді жаза аламыз. Қолданбаның жаңа нұсқасы сәтті орналастырылғаннан кейін, іске қосудан кейінгі қолдау кезеңінен кейін біз ескі бағанды және қажетсіз болып қалған триггерді жоя аламыз.
Қолданбаның жаңа нұсқасы дұрыс жұмыс істемесе, біз алдыңғы нұсқаға, соның ішінде дерекқордың алдыңғы нұсқасына орала аламыз. Қысқасы, біздің өзгертулер қосымшаның бірнеше нұсқасымен бір уақытта жұмыс істеуге мүмкіндік береді.
Біз K8S тапсырмасы арқылы дерекқорды тасымалдауды автоматтандыруды жоспарлап отырмыз, оны CD процесіне біріктіреміз. Біз бұл тәжірибені Хабреде міндетті түрде бөлісеміз.
Ақпарат көзі: www.habr.com