Di True Engineering, kami telah menyiapkan proses pengiriman pembaruan berkelanjutan ke server pelanggan dan ingin berbagi pengalaman ini.
Pertama, kami mengembangkan sistem online untuk pelanggan dan menempatkannya di kluster Kubernet kami sendiri. Sekarang solusi kami yang sangat bermuatan telah pindah ke platform pelanggan, dan kami telah menyiapkan proses Penerapan Berkelanjutan yang sepenuhnya otomatis. Berkat ini, kami telah mempercepat waktu ke pasar - pengiriman perubahan ke lingkungan produk.
Dalam artikel ini, kami akan berbicara tentang semua tahapan proses Penerapan Berkelanjutan (CD) atau memberikan pembaruan ke platform pelanggan:
- bagaimana proses ini dimulai?
- sinkronisasi dengan repositori Git pelanggan,
- perakitan backend dan frontend
- penyebaran aplikasi secara otomatis dalam lingkungan pengujian,
- penyebaran otomatis di Prod.
Dalam prosesnya kami akan membagikan detail pengaturan.
1. Mulai CD
Penerapan Berkelanjutan dimulai dengan fakta bahwa pengembang memposting perubahan ke cabang rilis repositori Git kami.
Aplikasi kami bekerja berdasarkan arsitektur microservice dan semua komponennya disimpan dalam satu repositori. Berkat ini, semua layanan microsoft dirakit dan diinstal, bahkan jika salah satu dari mereka telah berubah.
Kami mengorganisir pekerjaan melalui satu repositori karena beberapa alasan:
- Kemudahan pengembangan - aplikasi sedang aktif dikembangkan, sehingga Anda dapat segera bekerja dengan semua kode.
- Saluran pipa CI / CD tunggal yang memastikan bahwa aplikasi sebagai sistem tunggal melewati semua pengujian dan dikirimkan ke lingkungan produk pelanggan.
- Kami mengecualikan kebingungan dalam versi - kami tidak harus menyimpan peta versi layanan-mikro dan menjelaskan konfigurasi kami untuk setiap layanan-mikro di skrip Helm.
2. Sinkronisasi dengan repositori Git dari kode sumber pelanggan
Perubahan yang dilakukan secara otomatis disinkronkan dengan repositori Git pelanggan. Di sana, perakitan aplikasi dikonfigurasi, yang dimulai setelah memperbarui cabang, dan penyebaran ke prod. Kedua proses terjadi di lingkungannya dari repositori Git.
Kami tidak dapat bekerja dengan repositori pelanggan secara langsung, karena kami membutuhkan pengembangan dan lingkungan pengujian kami sendiri. Kami menggunakan repositori Git kami untuk tujuan ini - disinkronkan dengan repositori Git mereka. Segera setelah pengembang memposting perubahan ke cabang yang sesuai dari repositori kami, GitLab segera mengirimkan perubahan ini kepada pelanggan.
Setelah itu, Anda perlu membuat pertemuan. Ini terdiri dari beberapa tahap: merakit backend dan frontend, pengujian dan pengiriman ke prod.
3. Bangun backend dan frontend
Perakitan backend dan frontend adalah dua tugas paralel yang dilakukan dalam sistem Runner GitLab. Konfigurasi rakitan aslinya terletak di repositori yang sama.
Tutorial untuk menulis skrip YAML untuk dibuat di GitLab .
GitLab Runner mengambil kode dari repositori yang diinginkan, mengumpulkan perintah Java application build dan mengirimkannya ke registri Docker. Di sini kami mengumpulkan backend dan frontend, mendapatkan gambar Docker, yang kami tempatkan di repositori di sisi pelanggan. Untuk mengelola gambar Doker, gunakan
plugin Gradle .
Kami menyinkronkan versi gambar kami dengan versi rilis, yang akan diposting di Docker. Untuk kelancaran operasi, kami membuat beberapa pengaturan:
1. Antara lingkungan pengujian dan wadah grosir tidak dipasang kembali. Kami melakukan parameterisasi sehingga wadah yang sama dapat bekerja tanpa membangun kembali dengan semua pengaturan, variabel lingkungan dan layanan baik di lingkungan pengujian dan di prod.
2. Untuk memperbarui aplikasi melalui Helm, Anda harus menentukan versinya. Kami memiliki perakitan backend, antarmuka dan pembaruan aplikasi - ini adalah tiga tugas yang berbeda, jadi penting untuk menggunakan versi aplikasi yang sama di mana-mana. Untuk tugas ini, kami menggunakan data dari sejarah Git, karena kami memiliki konfigurasi cluster K8S dan aplikasi berada dalam repositori Git yang sama.
Kami mendapatkan versi aplikasi dari hasil perintah
git describe --tags --abbrev=7 .
4. Penerapan otomatis semua perubahan dalam lingkungan pengujian (UAT)
Langkah selanjutnya dalam skrip build ini adalah memperbarui kluster K8S secara otomatis. Ini terjadi asalkan seluruh aplikasi dirakit dan semua artefak diterbitkan ke Docker Registry. Setelah itu, pembaruan lingkungan pengujian dimulai.
Pembaruan cluster diluncurkan menggunakan
Pembaruan Helm . Jika, sebagai akibatnya, terjadi kesalahan, Helm akan secara otomatis dan independen mengembalikan semua perubahannya. Karyanya tidak perlu dikontrol.
Bersama dengan perakitan, kami memberikan konfigurasi cluster K8S. Oleh karena itu, langkah selanjutnya adalah memperbaruinya: configMaps, penyebaran, layanan, rahasia, dan konfigurasi K8S lainnya yang kami ubah.
Setelah itu, Helm meluncurkan RollOut untuk memperbarui aplikasi itu sendiri dalam lingkungan uji. Sebelum aplikasi dikerahkan ke prod. Ini dilakukan agar pengguna secara manual memeriksa fitur bisnis yang telah kami posting di lingkungan pengujian.
5. Secara otomatis menyebarkan semua perubahan ke Prod
Untuk menyebarkan pembaruan ke lingkungan produk, yang tersisa hanyalah mengklik satu tombol di GitLab - dan kontainer segera dikirim ke lingkungan produk.
Satu dan aplikasi yang sama dapat bekerja tanpa membangun kembali di lingkungan yang berbeda - pengujian dan produksi. Kami menggunakan artefak yang sama tanpa mengubah apa pun dalam aplikasi, dan kami menetapkan parameter dari luar.
Parameterisasi yang fleksibel dari pengaturan aplikasi tergantung pada lingkungan di mana aplikasi ini akan dijalankan. Kami mengeluarkan semua pengaturan lingkungan: semuanya diparameterisasi melalui konfigurasi K8S dan parameter Helm. Ketika Helm menyebarkan unit ke lingkungan pengujian, parameter uji berlaku untuknya, dan parameter produk berlaku untuk lingkungan produk.
Hal yang paling sulit adalah membuat parameter semua layanan dan variabel yang digunakan, yang bergantung pada lingkungan, dan menerjemahkannya ke dalam variabel lingkungan dan deskripsi-konfigurasi parameter lingkungan untuk Helm.
Parameter aplikasi menggunakan variabel lingkungan. Nilai-nilainya diatur dalam wadah menggunakan configmap K8S, yang templated menggunakan Go templates. Misalnya, mengatur variabel lingkungan ke nama domain dapat dilakukan seperti ini:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env - nama lingkungan (prod, stage, UAT) disimpan dalam variabel ini.
.Values.app.properties.app_external_domain - dalam variabel ini kita di file .Values.yaml mengatur domain yang diinginkan
Saat memperbarui aplikasi, Helm menciptakan file configmap.yaml dari templat dan mengisi nilai APP_EXTERNAL_DOMAIN dengan nilai yang diperlukan tergantung pada lingkungan di mana pembaruan aplikasi dimulai. Variabel ini sudah diatur dalam wadah. Akses ke sana adalah dari aplikasi, masing-masing, di setiap lingkungan aplikasi akan ada nilai yang berbeda dari variabel ini.
Yang relatif baru, Spring Cloud memperkenalkan dukungan K8S, termasuk bekerja dengan configMaps:
Spring Cloud Kubernetes . Sementara proyek ini aktif berkembang dan berubah secara dramatis, kami tidak dapat menggunakannya dalam produksi. Tetapi kami secara aktif memantau kondisinya dan menggunakannya dalam konfigurasi DEV. Begitu stabil, kami akan beralih dari menggunakan variabel lingkungan ke sana.
Total
Jadi, Penerapan Berkelanjutan sudah berjalan dan berjalan. Semua pembaruan terjadi dengan mengklik tombol. Pengiriman perubahan ke lingkungan makanan bersifat otomatis. Dan, yang terpenting, pembaruan tidak menghentikan sistem.
Paket mendatang: migrasi basis otomatis
Kami berpikir untuk meningkatkan basis data dan kemampuan untuk mengembalikan perubahan ini. Lagi pula, dua versi aplikasi yang berbeda bekerja secara bersamaan: yang lama berfungsi, dan yang baru naik. Dan kami akan mematikan yang lama hanya ketika kami yakin bahwa versi yang baru berfungsi. Migrasi basis data harus memungkinkan bekerja dengan kedua versi aplikasi.
Karena itu, kami tidak bisa hanya mengubah nama kolom atau data lainnya. Tetapi kita dapat membuat kolom baru, menyalin data dari kolom lama ke dalamnya dan menulis pemicu bahwa, ketika data diperbarui, secara bersamaan akan menyalin dan memperbaruinya di kolom lain. Dan setelah keberhasilan penerapan versi baru aplikasi, setelah periode dukungan pasca peluncuran, kita dapat menghapus kolom lama dan pemicu yang telah menjadi tidak perlu.
Jika versi baru aplikasi tidak berfungsi dengan benar, kita dapat memutar kembali ke versi sebelumnya, termasuk versi database sebelumnya. Singkatnya, perubahan kami akan memungkinkan bekerja secara bersamaan dengan beberapa versi aplikasi.
Kami berencana untuk mengotomatisasi migrasi basis data melalui pekerjaan K8S dengan menyematkannya dalam proses CD. Dan kami pasti akan membagikan pengalaman ini pada Habré.