Kami di True Engineering telah menyediakan proses untuk penghantaran kemas kini yang berterusan kepada pelayan pelanggan dan ingin berkongsi pengalaman ini.
Sebagai permulaan, kami membangunkan sistem dalam talian untuk pelanggan dan menggunakannya dalam kelompok Kubernetes kami sendiri. Kini penyelesaian beban tinggi kami telah berpindah ke platform pelanggan, yang mana kami telah menyediakan proses Penerapan Berterusan automatik sepenuhnya. Terima kasih kepada ini, kami mempercepatkan masa ke pasaran - penghantaran perubahan kepada persekitaran produk.
Dalam artikel ini kita akan bercakap tentang semua peringkat proses Penggunaan Berterusan (CD) atau penghantaran kemas kini kepada platform pelanggan:
- Bagaimanakah proses ini bermula?
- penyegerakan dengan repositori Git pelanggan,
- pemasangan bahagian belakang dan bahagian hadapan,
- penggunaan aplikasi automatik dalam persekitaran ujian,
- penempatan automatik kepada Prod.
Kami akan berkongsi butiran persediaan sepanjang perjalanan.
1. Mulakan CD
Penerapan Berterusan bermula dengan pembangun menolak perubahan pada cawangan keluaran repositori Git kami.
Aplikasi kami berjalan pada seni bina perkhidmatan mikro dan semua komponennya disimpan dalam satu repositori. Terima kasih kepada ini, semua perkhidmatan mikro dikumpul dan dipasang, walaupun salah satu daripadanya telah berubah.
Kami mengatur kerja melalui satu repositori atas beberapa sebab:
- Kemudahan pembangunan - aplikasi sedang dibangunkan secara aktif, jadi anda boleh bekerja dengan semua kod sekaligus.
- Saluran paip CI/CD tunggal yang menjamin bahawa aplikasi sebagai satu sistem lulus semua ujian dan dihantar ke persekitaran pengeluaran pelanggan.
- Kami menghapuskan kekeliruan dalam versi - kami tidak perlu menyimpan peta versi perkhidmatan mikro dan menerangkan konfigurasinya untuk setiap perkhidmatan mikro dalam skrip Helm.
2. Penyegerakan dengan repositori Git kod sumber pelanggan
Perubahan yang dibuat disegerakkan secara automatik dengan repositori Git pelanggan. Di sana pemasangan aplikasi dikonfigurasikan, yang dilancarkan selepas mengemas kini cawangan, dan penempatan ke sambungan. Kedua-dua proses berasal dari persekitaran mereka daripada repositori Git.
Kami tidak boleh bekerja dengan repositori pelanggan secara langsung kerana kami memerlukan persekitaran kami sendiri untuk pembangunan dan ujian. Kami menggunakan repositori Git kami untuk tujuan ini - ia disegerakkan dengan repositori Git mereka. Sebaik sahaja pembangun menyiarkan perubahan pada cawangan repositori kami yang sesuai, GitLab segera menolak perubahan ini kepada pelanggan.
Selepas ini anda perlu melakukan pemasangan. Ia terdiri daripada beberapa peringkat: pemasangan bahagian belakang dan bahagian hadapan, ujian dan penghantaran kepada pengeluaran.
3. Memasang bahagian belakang dan bahagian hadapan
Membina bahagian belakang dan bahagian hadapan ialah dua tugas selari yang dilakukan dalam sistem GitLab Runner. Konfigurasi pemasangan asalnya terletak dalam repositori yang sama.
.
GitLab Runner mengambil kod dari repositori yang diperlukan, memasangnya dengan arahan binaan aplikasi Java dan menghantarnya ke pendaftaran Docker. Di sini kami memasang bahagian belakang dan bahagian hadapan, dapatkan imej Docker, yang kami masukkan ke dalam repositori di sebelah pelanggan. Untuk menguruskan imej Docker yang kami gunakan .
Kami menyegerakkan versi imej kami dengan versi keluaran yang akan diterbitkan dalam Docker. Untuk kelancaran operasi kami telah membuat beberapa pelarasan:
1. Bekas tidak dibina semula antara persekitaran ujian dan persekitaran pengeluaran. Kami membuat parametrizasi supaya bekas yang sama boleh berfungsi dengan semua tetapan, pembolehubah persekitaran dan perkhidmatan dalam persekitaran ujian dan dalam pengeluaran tanpa membina semula.
2. Untuk mengemas kini aplikasi melalui Helm, anda mesti menentukan versinya. Kami membina bahagian belakang, bahagian hadapan dan mengemas kini aplikasi - ini adalah tiga tugas yang berbeza, jadi adalah penting untuk menggunakan versi aplikasi yang sama di mana-mana sahaja. Untuk tugasan ini, kami menggunakan data daripada sejarah Git, memandangkan konfigurasi dan aplikasi kluster K8S kami berada dalam repositori Git yang sama.
Kami mendapat versi aplikasi daripada hasil pelaksanaan arahan
git describe --tags --abbrev=7.
4. Penggunaan automatik semua perubahan kepada persekitaran ujian (UAT)
Langkah seterusnya dalam skrip binaan ini ialah mengemas kini kelompok K8S secara automatik. Ini berlaku dengan syarat keseluruhan aplikasi telah dibina dan semua artifak telah diterbitkan ke Docker Registry. Selepas ini, kemas kini persekitaran ujian bermula.
Kemas kini kluster mula digunakan . Jika, akibatnya, sesuatu tidak berjalan mengikut rancangan, Helm akan secara automatik dan bebas melancarkan semua perubahannya. Kerjanya tidak perlu dikawal.
Kami membekalkan konfigurasi kluster K8S bersama pemasangan. Oleh itu, langkah seterusnya ialah mengemas kininya: configMaps, penempatan, perkhidmatan, rahsia dan sebarang konfigurasi K8S lain yang telah kami ubah.
Helm kemudian menjalankan kemas kini RollOut aplikasi itu sendiri dalam persekitaran ujian. Sebelum aplikasi digunakan untuk pengeluaran. Ini dilakukan supaya pengguna boleh menguji secara manual ciri perniagaan yang kami masukkan ke dalam persekitaran ujian.
5. Penggunaan automatik semua perubahan kepada Prod
Untuk menggunakan kemas kini kepada persekitaran pengeluaran, anda hanya perlu mengklik satu butang dalam GitLab - dan bekas dihantar dengan serta-merta ke persekitaran pengeluaran.
Aplikasi yang sama boleh berfungsi dalam persekitaran yang berbeza—ujian dan pengeluaran—tanpa membina semula. Kami menggunakan artifak yang sama tanpa mengubah apa-apa dalam aplikasi, dan kami menetapkan parameter secara luaran.
Parameteran fleksibel tetapan aplikasi bergantung pada persekitaran di mana aplikasi akan dilaksanakan. Kami telah mengalihkan semua tetapan persekitaran secara luaran: semuanya diparameterkan melalui konfigurasi K8S dan parameter Helm. Apabila Helm menggunakan pemasangan pada persekitaran ujian, tetapan ujian digunakan padanya dan tetapan produk digunakan pada persekitaran pengeluaran.
Perkara yang paling sukar ialah untuk membuat parameter semua perkhidmatan dan pembolehubah yang digunakan yang bergantung pada persekitaran, dan menterjemahkannya ke dalam pembolehubah persekitaran dan konfigurasi perihalan parameter persekitaran untuk Helm.
Tetapan aplikasi menggunakan pembolehubah persekitaran. Nilai mereka ditetapkan dalam bekas menggunakan peta konfigurasi K8S, yang templat menggunakan templat Go. Sebagai contoh, menetapkan pembolehubah persekitaran kepada nama domain boleh dilakukan seperti ini:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Nilai.global.env – pembolehubah ini menyimpan nama persekitaran (prod, stage, UAT).
.Values.app.properties.app_external_domain – dalam pembolehubah ini kita tetapkan domain yang dikehendaki dalam fail .Values.yaml
Apabila mengemas kini aplikasi, Helm mencipta fail configmap.yaml daripada templat dan mengisi nilai APP_EXTERNAL_DOMAIN dengan nilai yang dikehendaki bergantung pada persekitaran di mana kemas kini aplikasi bermula. Pembolehubah ini telah ditetapkan dalam bekas. Ia boleh diakses daripada aplikasi, jadi setiap persekitaran aplikasi akan mempunyai nilai yang berbeza untuk pembolehubah ini.
Baru-baru ini, sokongan K8S muncul dalam Spring Cloud, termasuk bekerja dengan configMaps: . Walaupun projek itu sedang giat membangun dan berubah secara radikal, kami tidak boleh menggunakannya dalam pengeluaran. Tetapi kami memantau keadaannya secara aktif dan menggunakannya dalam konfigurasi DEV. Sebaik sahaja ia stabil, kami akan beralih daripada menggunakan pembolehubah persekitaran kepadanya.
Dalam jumlah
Jadi, Penerapan Berterusan dikonfigurasikan dan berfungsi. Semua kemas kini berlaku dengan satu ketukan kekunci. Penghantaran perubahan kepada persekitaran produk adalah automatik. Dan, yang penting, kemas kini tidak menghalang sistem.
Pelan masa depan: penghijrahan pangkalan data automatik
Kami memikirkan tentang menaik taraf pangkalan data dan kemungkinan melancarkan semula perubahan ini. Lagipun, dua versi aplikasi yang berbeza berjalan pada masa yang sama: yang lama sedang berjalan, dan yang baharu sudah siap. Dan kami akan mematikan yang lama hanya apabila kami yakin bahawa versi baharu berfungsi. Penghijrahan pangkalan data sepatutnya membolehkan anda bekerja dengan kedua-dua versi aplikasi.
Oleh itu, kita tidak boleh hanya menukar nama lajur atau data lain. Tetapi kita boleh mencipta lajur baharu, menyalin data daripada lajur lama ke dalamnya dan menulis pencetus yang, apabila mengemas kini data, akan menyalin dan mengemas kininya secara serentak dalam lajur lain. Dan selepas penggunaan versi baharu aplikasi berjaya, selepas tempoh sokongan selepas pelancaran, kami akan dapat memadamkan lajur lama dan pencetus yang telah menjadi tidak perlu.
Jika versi baharu aplikasi tidak berfungsi dengan betul, kami boleh melancarkan semula ke versi sebelumnya, termasuk versi pangkalan data sebelumnya. Ringkasnya, perubahan kami akan membolehkan anda bekerja serentak dengan beberapa versi aplikasi.
Kami merancang untuk mengautomasikan pemindahan pangkalan data melalui kerja K8S, menyepadukannya ke dalam proses CD. Dan kami pasti akan berkongsi pengalaman ini di Habré.
Sumber: www.habr.com