Panduan ini menjelaskan serangkaian praktik terbaik untuk continuous integration dan continuous delivery (CI/CD) ke Google Kubernetes Engine (GKE). Praktik ini mencakup berbagai topik, mulai dari kontrol sumber hingga strategi deployment. Praktik terbaik ini spesifik untuk GKE dan praktik terbaik CI/CD umum tetap berlaku. Untuk informasi selengkapnya, lihat Teknologi DevOps: Continuous integration dan Teknologi DevOps: Continuous delivery.
Continuous integration
Continuous integration (CI) adalah praktik di mana developer mengintegrasikan semua perubahan kode mereka kembali ke cabang utama sesering mungkin. Hal ini dimaksudkan agar kegagalan berlangsung lebih cepat dengan mengekspos masalah dalam proses sedini mungkin. Pipeline CI biasanya dipicu oleh developer yang mengirim perubahan kode. Pipeline ini melibatkan langkah-langkah untuk memvalidasi perubahan tersebut, seperti analisis lint, pengujian, dan pembuatan build. Pipeline CI biasanya menghasilkan artefak yang dapat Anda deploy pada tahap selanjutnya dalam proses deployment.
Membuat pipeline yang memungkinkan iterasi cepat
Waktu antara saat developer membuat perubahan kode dan saat Anda mendapatkan versi aplikasi yang aktif haruslah sesingkat mungkin. Kecepatan ini sangat penting selama pengembangan di cabang fitur yang melibatkan iterasi cepat oleh developer. Idealnya, pipeline CI Anda harus berjalan kurang dari 10 menit. Jika tidak memungkinkan, buat dua jenis pipeline CI:
Pipeline cepat: Pipeline ini biasanya berjalan dalam waktu 10 menit atau kurang. Pipeline ini ditujukan untuk cabang fitur dan tidak komprehensif. Pipeline cepat berpotensi menghasilkan artefak yang tidak stabil.
Pipeline lengkap: Pipeline ini dapat berjalan dalam waktu lebih dari 10 menit, serta menjalankan pengujian dan pemeriksaan yang lebih komprehensif. Pipeline lengkap berjalan pada permintaan merge atau pull, dan di-commit ke cabang utama.
Menguji image container
Sebagai bagian dari pipeline CI, pastikan Anda menjalankan semua pengujian yang diperlukan pada artefak build dan kode. Pengujian ini harus mencakup pengujian unit, fungsi, integrasi, dan beban atau performa.
Penting juga untuk menguji struktur image container yang Anda bangun. Menguji struktur akan memastikan bahwa semua perintah berjalan seperti yang Anda harapkan di dalam container. Pengujian juga memungkinkan Anda memeriksa apakah file tertentu berada di lokasi yang tepat dan memiliki isi yang benar.
Untuk menguji image container, Anda dapat menggunakan framework Pengujian Struktur Container.
Membangun keamanan sejak awal di pipeline
Lakukan pemeriksaan dan keseimbangan keamanan sedini mungkin dalam siklus proses pengembangan. Dengan menemukan risiko keamanan sebelum membangun artefak atau men-deploy, Anda dapat mengurangi waktu dan biaya yang dihabiskan untuk mengatasi risiko ini.
Untuk membantu mewujudkan deteksi dini, Anda dapat menerapkan langkah-langkah keamanan berikut di pipeline Anda:
Wajibkan pakar materi pokok meninjau kode apa pun yang diintegrasikan ke dalam repositori produksi Anda.
Terapkan analisis kode statis dan lint sejak awal di pipeline Anda. Pengujian ini membantu Anda menemukan kelemahan seperti tidak meng-escape input, menerima data input mentah untuk kueri SQL, atau kerentanan dalam kode Anda.
Pindai image container yang Anda bangun untuk menemukan kerentanan dengan pemindaian kerentanan.
Cegah image yang memiliki kerentanan di-deploy ke cluster Anda dengan memberlakukan Otorisasi Biner. Otorisasi Biner memerlukan langganan GKE Enterprise. Agar Anda lebih yakin pada image yang dihasilkan, Otorisasi Biner juga memungkinkan Anda mewajibkan pengesahan oleh entity atau sistem yang berbeda. Misalnya, pengesahan dapat mencakup berikut ini:
- Lulus pemindaian kerentanan
- Lulus pengujian QA
- Persetujuan dari pemilik produk
Continuous delivery
Continuous delivery (CD) memungkinkan Anda merilis kode kapan saja. CD beroperasi pada artefak yang dihasilkan oleh pipeline CI. Pipeline CD dapat berjalan lebih lama daripada pipeline CI, terutama jika Anda menggunakan strategi deployment yang lebih rumit seperti blue-green deployment.
Menggunakan metodologi GitOps
GitOps adalah konsep infrastruktur deklaratif yang disimpan di repositori Git dan alat CI/CD untuk men-deploy infrastruktur tersebut ke lingkungan Anda. Saat menggunakan metodologi GitOps, Anda memastikan bahwa semua perubahan pada aplikasi dan cluster disimpan di repositori sumber dan selalu dapat diakses.
Penggunaan metodologi GitOps memberi Anda keuntungan berikut:
- Anda dapat meninjau perubahan sebelum di-deploy melalui permintaan merge atau pull.
- Anda memiliki satu lokasi yang dapat digunakan untuk merujuk kembali ke status aplikasi dan cluster Anda kapan saja.
- Snapshot cluster dan aplikasi Anda memudahkan pemulihan jika terjadi kegagalan.
Untuk mempelajari lebih lanjut metodologi GitOps dan berbagai pola yang dapat Anda gunakan di repositori sumber, lihat Konsep GitOps.
Beberapa alat umum yang digunakan untuk infrastruktur deklaratif adalah Terraform dari Hashicorp dan Config Connector dari Google Cloud. Untuk praktik langsung dalam mengelola infrastruktur dengan GitOps dan alat lainnya, cobalah tutorial Mengelola infrastruktur sebagai kode dengan Terraform, Cloud Build, dan GitOps. Untuk mempelajari cara mengelola aplikasi dengan gaya GitOps, coba Continuous delivery bergaya GitOps dengan Cloud Build.
Mempromosikan, bukan membangun ulang, image container
Image container tidak boleh dibangun ulang karena harus melalui berbagai tahap pipeline CI/CD. Membangun ulang dapat menimbulkan perbedaan kecil antara berbagai cabang kode. Perbedaan ini dapat menyebabkan aplikasi Anda gagal dalam produksi atau menyebabkan penambahan kode yang belum teruji secara tidak sengaja dalam image container produksi. Untuk memastikan bahwa image container yang Anda uji adalah image container yang Anda deploy, sebaiknya bangun image satu kali dan promosikan di sepanjang lingkungan Anda. Saran ini mengasumsikan bahwa Anda memisahkan konfigurasi khusus lingkungan dari paket.
Mempertimbangkan penggunaan pola deployment dan pengujian yang lebih canggih
GKE menawarkan fleksibilitas untuk men-deploy dan menguji aplikasi melalui beberapa pola. Pola deployment yang Anda pilih sangat bergantung pada tujuan bisnis. Misalnya, Anda mungkin perlu men-deploy perubahan tanpa periode nonaktif atau men-deploy perubahan ke suatu lingkungan atau subset pengguna sebelum Anda menjadikan fitur tersedia secara umum.
Beberapa pola deployment yang tersedia untuk Anda meliputi:
Membuat ulang deployment: Anda dapat sepenuhnya menurunkan skala versi aplikasi yang ada sebelum meningkatkan skala versi aplikasi yang baru.
Deployment update berkelanjutan: Anda mengupdate sebagian instance aplikasi yang sedang berjalan, bukan semua instance aplikasi yang sedang berjalan sekaligus. Selanjutnya, Anda secara progresif mengupdate lebih banyak instance aplikasi yang sedang berjalan sampai semuanya diupdate.
Blue-green deployment: Anda men-deploy serangkaian instance paralel tambahan ke instance produksi yang ada dengan versi aplikasi yang telah diupgrade. Anda mengalihkan traffic ke instance baru saat sudah siap melakukan deployment.
Memisahkan cluster untuk lingkungan yang berbeda
Pemisahan lingkungan merupakan pertimbangan penting untuk target deployment apa pun. Idealnya, Anda memiliki cluster terpisah untuk setiap lingkungan berikut:
Lingkungan pengembangan: Lingkungan ini adalah tempat developer men-deploy aplikasi untuk pengujian dan eksperimen. Deployment ini memerlukan integrasi dengan bagian-bagian lain aplikasi atau sistem (misalnya database). Cluster untuk lingkungan ini biasanya memiliki lebih sedikit gate, dan developer memiliki kontrol lebih besar atas konfigurasi cluster mereka.
Lingkungan praproduksi (Staging atau QA): Lingkungan ini harus semirip mungkin dengan lingkungan produksi. Lingkungan praproduksi digunakan untuk menjalankan pengujian perubahan berskala besar seperti pengujian integrasi, beban, performa, atau regresi.
Lingkungan produksi: Lingkungan ini adalah tempat workload produksi serta aplikasi dan layanan yang ditampilkan kepada pengguna berjalan.
Untuk mempelajari lingkungan ini lebih lanjut, baca bagian Lingkungan dalam Kubernetes dan tantangan continuous software delivery.
Mendekatkan lingkungan praproduksi dengan lingkungan produksi
Idealnya, cluster praproduksi identik dengan cluster produksi, tetapi karena pertimbangan biaya, cluster praproduksi dapat berupa replika yang diperkecil skalanya. Menjaga cluster tetap mirip akan memastikan bahwa setiap pengujian dilakukan pada kondisi yang sama atau mirip dengan yang ada di lingkungan produksi. Paritas antara cluster praproduksi dan produksi juga mengurangi kemungkinan kegagalan tak terduga karena perbedaan lingkungan saat Anda melakukan deployment ke produksi.
Infrastruktur deklaratif dan GitOps membantu Anda mencapai paritas yang lebih dekat dengan lingkungan Anda karena Anda dapat menduplikasi konfigurasi cluster pokok dengan lebih mudah. Guna memastikan lingkungan Anda memiliki kondisi serupa untuk kebijakan dan konfigurasi, Anda juga dapat menggunakan alat seperti Config Sync.
Bersiap menghadapi kegagalan dalam produksi
Tidak ada pengujian yang dapat menjamin perilaku yang tepat dari aplikasi Anda dalam produksi. Kegagalan dapat disebabkan oleh kasus ekstrem dengan data yang tidak dipertimbangkan sebelumnya atau pola akses oleh pengguna yang tidak diuji. Penting untuk memantau aplikasi Anda dalam produksi dan memiliki mekanisme deployment serta rollback otomatis agar Anda dapat merespons dan memperbaiki bug atau pemadaman layanan dengan cepat. Dengan strategi deployment yang lebih tangguh, Anda dapat mengurangi dampak masalah dan memengaruhi lebih sedikit pengguna akhir jika masalah terjadi di lingkungan produksi.
Ringkasan checklist
Tabel berikut merangkum tugas-tugas yang kami rekomendasikan saat Anda menggunakan pipeline CI/CD di GKE:
| Area | Tugas |
|---|---|
| Continuous integration |
|
| Continuous delivery |
|
Langkah selanjutnya
- Pelajari Praktik terbaik untuk multi-tenancy perusahaan.
- Pelajari lebih lanjut CI/CD di Google Cloud.