Implementasi Penyebaran Terus-terusan ing platform pelanggan

Kita ing True Engineering wis nyiyapake proses kanggo ngirim nganyari terus menyang server pelanggan lan pengin nuduhake pengalaman iki.

Kanggo miwiti, kita ngembangake sistem online kanggo pelanggan lan nyebarake ing kluster Kubernetes dhewe. Saiki solusi beban dhuwur wis dipindhah menyang platform pelanggan, sing wis nyiyapake proses Penyebaran Terus-terusan kanthi otomatis. Thanks kanggo iki, kita nyepetake wektu-kanggo-pasar - pangiriman owah-owahan ing lingkungan produk.

В этой статье мы расскажем обо всех этапах процесса Continuous Deployment (CD) или доставки обновлений на платформу заказчика:

1. Kepiye proses iki diwiwiti?
2. sinkronisasi karo repositori Git pelanggan,
3. perakitan backend lan frontend,
4. panyebaran aplikasi otomatis ing lingkungan tes,
5. penyebaran otomatis menyang Prod.

Kita bakal nuduhake rincian persiyapan ing dalan.

1. Miwiti CD

Continuous Deployment начинается с того, что разработчик выкладывает изменения в релизную ветку нашего Git-репозитория.

Aplikasi kita nganggo arsitektur layanan mikro lan kabeh komponen disimpen ing siji gudang. Thanks kanggo iki, kabeh layanan mikro diklumpukake lan diinstal, sanajan salah sijine wis diganti.

Kita ngatur karya liwat siji repositori amarga sawetara alasan:

• Gampang pangembangan - aplikasi kasebut aktif berkembang, supaya sampeyan bisa nggarap kabeh kode bebarengan.
• Единый пайплайн CI/CD, который гарантирует, что приложение как единая система проходит все тесты и доставляется в prod-окружение заказчика.
• Kita ngilangi kebingungan ing versi - kita ora kudu nyimpen peta versi microservice lan njlèntrèhaké konfigurasi kanggo saben microservice ing skrip Helm.

2. Sinkronisasi karo repositori Git kode sumber pelanggan

Сделанные изменения автоматически синхронизируются с Git-репозиторием заказчика. Там настроена сборка приложения, которая запускается после обновления ветки, и деплоймент в прод. Оба процесса происходят в их окружении из Git-репозитория.

Kita ora bisa nggarap gudang pelanggan kanthi langsung amarga kita butuh lingkungan dhewe kanggo pangembangan lan tes. Kita nggunakake repositori Git kanggo tujuan kasebut - disinkronake karo repositori Git. Sanalika pangembang ngirim owah-owahan menyang cabang repositori sing cocog, GitLab langsung nyurung owah-owahan kasebut menyang pelanggan.

Sawise iki sampeyan kudu nindakake perakitan. Iku kasusun saka sawetara orane tumrap sekolah: backend lan frontend perakitan, testing lan pangiriman kanggo produksi.

3. Ngrakit backend lan frontend

Mbangun backend lan frontend minangka rong tugas paralel sing ditindakake ing sistem GitLab Runner. Konfigurasi perakitan asli dumunung ing repositori sing padha.

Tutorial nulis skrip YAML kanggo mbangun ing GitLab.

GitLab Runner забирает код из нужного репозитория, командой сборки Java-приложения собрает и отправляет его в Docker registry. Здесь мы собираем бекенд и фронтенд, получаем Docker-образы, которые складываем в репозиторий на стороне заказчика. Для управления Doker-образами используем Plugin Gradle.

Kita nyinkronake versi gambar kita karo versi rilis sing bakal diterbitake ing Docker. Kanggo operasi lancar, kita wis nggawe sawetara pangaturan:

1. Wadhah ora dibangun maneh antarane lingkungan test lan lingkungan produksi. Kita nggawe parametrizasi supaya wadhah sing padha bisa digunakake karo kabeh setelan, variabel lingkungan lan layanan ing lingkungan tes lan ing produksi tanpa mbangun maneh.

2. Kanggo nganyari aplikasi liwat Helm, sampeyan kudu nemtokake versi. Kita mbangun backend, frontend lan nganyari aplikasi - iki telung tugas sing beda-beda, dadi penting kanggo nggunakake versi aplikasi sing padha ing endi wae. Kanggo tugas iki, kita nggunakake data saka riwayat Git, amarga konfigurasi kluster K8S lan aplikasi ana ing gudang Git sing padha.

Версию приложения мы получаем из результатов выполнения команды
git describe --tags --abbrev=7.

4. Penyebaran otomatis kabeh owah-owahan ing lingkungan tes (UAT)

Langkah sabanjure ing skrip mbangun iki yaiku nganyari kluster K8S kanthi otomatis. Iki kedadeyan yen kabeh aplikasi wis dibangun lan kabeh artefak wis diterbitake menyang Docker Registry. Sawise iki, nganyari lingkungan test diwiwiti.

Nganyari kluster wiwit digunakake Update Helm. Если в результате что-то пошло не по плану, то Helm автоматически и самостоятельно откатит все свои изменения. Его работу не нужно контролировать.

Kita nyedhiyakake konfigurasi kluster K8S bebarengan karo perakitan. Mula, langkah sabanjure yaiku nganyari: configMaps, penyebaran, layanan, rahasia lan konfigurasi K8S liyane sing wis diganti.

После этого Helm запускает RollOut обновление самого приложения в тестовой среде. До того как приложение будет развернуто на проде. Это сделано для того, чтобы пользователи вручную проверили бизнес-фичи, которые мы выложили в тестовое окружение.

5. Penyebaran otomatis kabeh owah-owahan menyang Prod

Kanggo nyebarake nganyari menyang lingkungan produksi, sampeyan mung kudu ngeklik tombol siji ing GitLab - lan wadhah kasebut langsung dikirim menyang lingkungan produksi.

Aplikasi sing padha bisa digunakake ing macem-macem lingkungan-tes lan produksi-tanpa mbangun maneh. Kita nggunakake artefak padha tanpa ngganti apa-apa ing aplikasi, lan kita nyetel paramèter externally.

Parameterisasi fleksibel setelan aplikasi gumantung ing lingkungan ing ngendi aplikasi bakal dieksekusi. Kita wis mindhah kabeh setelan lingkungan externally: kabeh wis parameterized liwat konfigurasi K8S lan paramèter Helm. Nalika Helm nyebarake perakitan menyang lingkungan tes, setelan tes ditrapake, lan setelan produk ditrapake ing lingkungan produksi.

Wangsulan: Bab ingkang paling angel ana parameterize kabeh layanan digunakake lan variabel sing gumantung ing lingkungan, lan nerjemahake menyang variabel lingkungan lan gambaran-konfigurasi paramèter lingkungan kanggo Helm.

Setelan aplikasi nggunakake variabel lingkungan. Nilai kasebut disetel ing kontaner nggunakake configmap K8S, sing digawe template nggunakake template Go. Contone, nyetel variabel lingkungan menyang jeneng domain bisa ditindakake kaya iki:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env – variabel iki nyimpen jeneng lingkungan (prod, panggung, UAT).
.Values.app.properties.app_external_domain – ing variabel iki kita nyetel domain sing dikarepake ing file .Values.yaml

При обновлении приложения Helm выполняет создание из шаблонов файла configmap.yaml и заполняет значение APP_EXTERNAL_DOMAIN нужным значением в зависимости от окружения, в котором стартует обновление приложения. Эта переменная проставляется уже в контейнере. Доступ к ней есть из приложения, соответственно, в каждом окружении приложения будет разное значение этой переменной.

Relatif bubar, dhukungan K8S muncul ing Spring Cloud, kalebu nggarap configMaps: Spring Cloud Kubernetes. Nalika proyek kasebut aktif berkembang lan ganti kanthi radikal, kita ora bisa nggunakake ing produksi. Nanging kita aktif ngawasi kondisi kasebut lan digunakake ing konfigurasi DEV. Sanalika stabil, kita bakal ngalih saka nggunakake variabel lingkungan.

Total

Dadi, Penyebaran Terus-terusan dikonfigurasi lan digunakake. Kabeh nganyari dumadi kanthi siji keystroke. Pangiriman owah-owahan menyang lingkungan produk kanthi otomatis. Lan, sing penting, nganyari ora mandhegake sistem kasebut.

Rencana mangsa ngarep: migrasi database otomatis

Kita mikir babagan nganyarke database lan kemungkinan nggulung maneh owah-owahan kasebut. Sawise kabeh, rong versi aplikasi sing beda-beda mlaku bebarengan: sing lawas mlaku, lan sing anyar munggah. Lan kita bakal mateni sing lawas mung yen kita yakin manawa versi anyar bisa digunakake. Migrasi basis data kudu ngidini sampeyan nggarap versi loro aplikasi kasebut.

Mulane, kita ora bisa mung ngganti jeneng kolom utawa data liyane. Nanging kita bisa nggawe kolom anyar, nyalin data saka kolom lawas menyang lan nulis pemicu sing, nalika nganyari data, bakal bebarengan nyalin lan nganyari ing kolom liyane. Lan sawise panyebaran sukses versi aplikasi anyar, sawise periode dhukungan pasca peluncuran, kita bakal bisa mbusak kolom lawas lan pemicu sing ora perlu.

Yen versi anyar saka aplikasi ora bisa digunakake kanthi bener, kita bisa muter maneh menyang versi sadurungé, kalebu versi sadurungé saka database. Ing cendhak, owah-owahan kita bakal ngidini sampeyan bisa bebarengan karo sawetara versi aplikasi.

Kita rencana kanggo ngotomatisasi migrasi database liwat proyek K8S, nggabungake menyang proses CD. Lan kita mesthi bakal nuduhake pengalaman iki ing Habré.

Source: www.habr.com