Kami di True Engineering telah menyiapkan proses untuk pengiriman pembaruan berkelanjutan ke server pelanggan dan ingin berbagi pengalaman ini.
Untuk memulainya, kami mengembangkan sistem online untuk pelanggan dan menerapkannya di cluster Kubernetes kami sendiri. Kini solusi beban tinggi kami telah dipindahkan ke platform pelanggan, dan untuk itu kami telah menyiapkan proses Penerapan Berkelanjutan yang sepenuhnya otomatis. Berkat ini, kami mempercepat waktu pemasaran - penyampaian perubahan pada lingkungan produk.
Pada artikel ini kita akan membahas semua tahapan proses Continuous Deployment (CD) atau pengiriman pembaruan ke platform pelanggan:
- Bagaimana proses ini dimulai?
- sinkronisasi dengan repositori Git pelanggan,
- perakitan backend dan frontend,
- penyebaran aplikasi otomatis di lingkungan pengujian,
- penerapan otomatis ke Prod.
Kami akan membagikan detail pengaturannya selama prosesnya.
1. Mulai CD
Penerapan Berkelanjutan dimulai dengan pengembang mendorong perubahan pada cabang rilis repositori Git kami.
Aplikasi kita berjalan pada arsitektur layanan mikro dan semua komponennya disimpan dalam satu repositori. Berkat ini, semua layanan mikro dikumpulkan dan diinstal, meskipun salah satunya telah berubah.
Kami mengatur pekerjaan melalui satu repositori karena beberapa alasan:
- Kemudahan pengembangan - aplikasi berkembang secara aktif, sehingga Anda dapat bekerja dengan semua kode sekaligus.
- Pipeline CI/CD tunggal yang menjamin bahwa aplikasi sebagai sistem tunggal lulus semua pengujian dan dikirimkan ke lingkungan produksi pelanggan.
- Kami menghilangkan kebingungan dalam versi - kami tidak perlu menyimpan peta versi layanan mikro dan menjelaskan konfigurasinya 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 diluncurkan setelah memperbarui cabang, dan penerapan hingga kelanjutannya. Kedua proses tersebut berasal dari lingkungannya dari repositori Git.
Kami tidak dapat bekerja dengan repositori pelanggan secara langsung karena kami memerlukan lingkungan kami sendiri untuk pengembangan dan pengujian. Kami menggunakan repositori Git kami untuk tujuan ini - repositori ini disinkronkan dengan repositori Git mereka. Segera setelah pengembang memposting perubahan ke cabang repositori kami yang sesuai, GitLab segera mengirimkan perubahan ini ke pelanggan.
Setelah itu, Anda perlu melakukan perakitan. Ini terdiri dari beberapa tahap: perakitan backend dan frontend, pengujian dan pengiriman ke produksi.
3. Merakit backend dan frontend
Membangun backend dan frontend adalah dua tugas paralel yang dilakukan di sistem GitLab Runner. Konfigurasi perakitan aslinya terletak di repositori yang sama.
.
GitLab Runner mengambil kode dari repositori yang diperlukan, merakitnya dengan perintah pembuatan aplikasi Java dan mengirimkannya ke registri Docker. Di sini kami merakit backend dan frontend, mendapatkan image Docker, yang kami masukkan ke dalam repositori di sisi pelanggan. Untuk mengelola gambar Docker yang kami gunakan .
Kami menyinkronkan versi gambar kami dengan versi rilis yang akan dipublikasikan di Docker. Untuk kelancaran pengoperasian kami telah melakukan beberapa penyesuaian:
1. Kontainer tidak dibangun kembali antara lingkungan pengujian dan lingkungan produksi. Kami membuat parameterisasi sehingga wadah yang sama dapat bekerja dengan semua pengaturan, variabel lingkungan, dan layanan baik di lingkungan pengujian maupun produksi tanpa membangun kembali.
2. Untuk mengupdate aplikasi melalui Helm, Anda harus menentukan versinya. Kami membangun backend, frontend, dan memperbarui aplikasi - ini adalah tiga tugas berbeda, jadi penting untuk menggunakan versi aplikasi yang sama di mana pun. Untuk tugas ini, kami menggunakan data dari riwayat Git, karena konfigurasi cluster K8S dan aplikasi kami berada dalam repositori Git yang sama.
Versi aplikasi kita dapatkan dari hasil eksekusi perintah
git describe --tags --abbrev=7.
4. Penerapan otomatis semua perubahan pada lingkungan pengujian (UAT)
Langkah selanjutnya dalam skrip build ini adalah memperbarui cluster K8S secara otomatis. Hal ini terjadi asalkan seluruh aplikasi telah dibangun dan semua artefak telah dipublikasikan ke Docker Registry. Setelah ini, pembaruan lingkungan pengujian dimulai.
Pembaruan cluster dimulai menggunakan . Jika akibatnya ada sesuatu yang tidak berjalan sesuai rencana, Helm akan secara otomatis dan mandiri membatalkan semua perubahannya. Pekerjaannya tidak perlu dikontrol.
Kami menyediakan konfigurasi cluster K8S beserta perakitannya. Oleh karena itu, langkah selanjutnya adalah memperbaruinya: configMaps, penerapan, layanan, rahasia, dan konfigurasi K8S lainnya yang telah kami ubah.
Helm kemudian menjalankan pembaruan RollOut aplikasi itu sendiri di lingkungan pengujian. Sebelum aplikasi diterapkan ke produksi. Hal ini dilakukan agar pengguna dapat menguji secara manual fitur bisnis yang kami masukkan ke dalam lingkungan pengujian.
5. Penerapan otomatis semua perubahan pada Prod
Untuk menerapkan pembaruan ke lingkungan produksi, Anda hanya perlu mengklik satu tombol di GitLab - dan kontainer akan segera dikirimkan ke lingkungan produksi.
Aplikasi yang sama dapat bekerja di lingkungan yang berbedaβpengujian dan produksiβtanpa perlu melakukan pembangunan kembali. Kami menggunakan artefak yang sama tanpa mengubah apa pun dalam aplikasi, dan kami mengatur parameter secara eksternal.
Parameterisasi pengaturan aplikasi yang fleksibel bergantung pada lingkungan di mana aplikasi akan dijalankan. Kami telah memindahkan semua pengaturan lingkungan secara eksternal: semuanya diparameterisasi melalui konfigurasi K8S dan parameter Helm. Saat Helm menyebarkan rakitan ke lingkungan pengujian, pengaturan pengujian diterapkan padanya, dan pengaturan produk diterapkan ke lingkungan produksi.
Hal tersulit 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.
Pengaturan aplikasi menggunakan variabel lingkungan. Nilai-nilainya ditetapkan dalam wadah menggunakan configmap K8S, yang dibuat templatnya menggunakan templat Go. Misalnya, menyetel variabel lingkungan ke nama domain dapat dilakukan seperti ini:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Nilai.global.env β variabel ini menyimpan nama lingkungan (prod, stage, UAT).
.Values.app.properties.app_external_domain β pada variabel ini kita setting domain yang diinginkan pada file .Values.yaml
Saat memperbarui aplikasi, Helm membuat file configmap.yaml dari templat dan mengisi nilai APP_EXTERNAL_DOMAIN dengan nilai yang diinginkan bergantung pada lingkungan tempat pembaruan aplikasi dimulai. Variabel ini sudah disetel di penampung. Variabel ini dapat diakses dari aplikasi, sehingga setiap lingkungan aplikasi akan memiliki nilai berbeda untuk variabel ini.
Relatif baru-baru ini, dukungan K8S muncul di Spring Cloud, termasuk bekerja dengan configMaps: . Meskipun proyek ini secara aktif berkembang dan berubah secara radikal, kami tidak dapat menggunakannya dalam produksi. Namun kami secara aktif memantau kondisinya dan menggunakannya dalam konfigurasi DEV. Segera setelah stabil, kami akan beralih dari penggunaan variabel lingkungan ke variabel tersebut.
Total
Jadi, Penerapan Berkelanjutan telah dikonfigurasi dan berfungsi. Semua pembaruan terjadi dengan satu penekanan tombol. Pengiriman perubahan pada lingkungan produk dilakukan secara otomatis. Dan yang terpenting, pembaruan tidak menghentikan sistem.
Rencana masa depan: migrasi database otomatis
Kami memikirkan untuk memutakhirkan database dan kemungkinan mengembalikan perubahan ini. Lagi pula, dua versi aplikasi berbeda berjalan pada saat yang sama: versi lama sedang berjalan, dan versi baru sudah aktif. Dan kami akan mematikan yang lama hanya jika kami yakin versi baru berfungsi. Migrasi basis data akan memungkinkan Anda bekerja dengan kedua versi aplikasi.
Oleh karena itu, kita tidak bisa begitu saja mengubah nama kolom atau data lainnya. Tapi kita bisa membuat kolom baru, menyalin data dari kolom lama ke dalamnya dan menulis pemicu yang, ketika data diperbarui, secara bersamaan akan menyalin dan memperbaruinya di kolom lain. Dan setelah penerapan versi baru aplikasi berhasil, setelah periode dukungan pasca peluncuran, kami akan dapat menghapus kolom lama dan pemicu yang tidak diperlukan lagi.
Jika aplikasi versi baru tidak berfungsi dengan benar, kita dapat memutar kembali ke versi sebelumnya, termasuk versi database sebelumnya. Singkatnya, perubahan kami akan memungkinkan Anda bekerja dengan beberapa versi aplikasi secara bersamaan.
Kami berencana untuk mengotomatisasi migrasi database melalui pekerjaan K8S, mengintegrasikannya ke dalam proses CD. Dan kami pasti akan membagikan pengalaman ini di HabrΓ©.
Sumber: www.habr.com