GitOps adalah serangkaian prinsip untuk mengoperasikan dan mengelola sistem perangkat lunak. Artikel ini menjelaskan teknik untuk menggunakan prinsip GitOps untuk mengoperasikan dan mengelola kluster Azure Kubernetes Services (AKS).
Logo Flux, Argo CD, OPA Gatekeeper, Kubernetes, dan git adalah merek dagang dari perusahaan masing-masing. Tidak ada dukungan yang tersirat oleh penggunaan tanda-tanda ini.
Sistem
Dua operator GitOps yang dapat Anda gunakan dengan AKS adalah Flux dan Argo CD. Keduanya lulus proyek Cloud Native Computing Foundation (CNCF) dan banyak digunakan. Skenario berikut menunjukkan cara untuk menggunakannya.
Skenario 1: GitOps dengan Fluks dan AKS
Unduh file Visio arsitektur ini.
Aliran data untuk skenario 1
Flux adalah ekstensi kluster asli untuk AKS. Ekstensi kluster menyediakan platform untuk menginstal dan mengelola solusi pada kluster AKS. Anda dapat menggunakan skrip portal Azure, Azure CLI, atau infrastruktur sebagai kode (IaC), seperti skrip Terraform atau Bicep, untuk mengaktifkan Flux sebagai ekstensi ke AKS. Anda juga dapat menggunakan Azure Policy untuk menerapkan konfigurasi Flux v2 dalam skala besar pada kluster AKS. Untuk informasi selengkapnya, lihat Menyebarkan aplikasi secara konsisten dalam skala besar menggunakan konfigurasi Flux v2 dan Azure Policy.
Fluks dapat menyebarkan manifes Kubernetes, bagan Helm, dan file Kustomisasi ke AKS. Fluks adalah proses berbasis polling, sehingga dapat mendeteksi, menarik, dan mendamaikan perubahan konfigurasi tanpa mengekspos titik akhir kluster ke agen build Anda.
Dalam skenario ini, administrator Kubernetes dapat mengubah objek konfigurasi Kubernetes, seperti rahasia dan Konfigurasi Peta, dan menerapkan perubahan langsung ke repositori GitHub.
Aliran data untuk skenario ini adalah:
- Pengembang menerapkan perubahan konfigurasi pada repositori GitHub.
- Flux mendeteksi penyimpangan konfigurasi di repositori Git, dan menarik perubahan konfigurasi.
- Fluks merekonsiliasi status di kluster Kubernetes.
Alternatif untuk skenario 1
- Anda dapat menggunakan Flux dengan repositori Git lainnya seperti Azure DevOps, GitLab, dan BitBucket.
- Alih-alih repositori Git, Flux Bucket API mendefinisikan sumber untuk menghasilkan artefak untuk objek dari solusi penyimpanan seperti wadah Amazon S3 dan Google Cloud Storage. Anda juga dapat menggunakan solusi yang memiliki API yang kompatibel dengan S3. Dua contohnya adalah MINIO dan Alibaba Cloud OSS, tetapi ada yang lain.
- Anda juga dapat mengonfigurasi Flux terhadap kontainer Azure Blob Storage sebagai sumber untuk menghasilkan artefak. Untuk informasi selengkapnya, lihat Konfigurasi GitOps Flux v2 dengan AKS dan Kubernetes dengan dukungan Azure Arc.
Skenario 2: Gunakan GitOps dengan Flux, GitHub, dan AKS untuk mengimplementasikan CI/CD
Unduh file Visio arsitektur ini.
Aliran data untuk skenario 2
Skenario ini adalah alur DevOps berbasis tarik untuk aplikasi web biasa. Alur menggunakan GitHub Actions untuk build. Untuk penyebaran, ia menggunakan Flux sebagai operator GitOps untuk menarik dan menyinkronkan aplikasi. Data mengalir melalui skenario sebagai berikut:
- Kode aplikasi dikembangkan dengan menggunakan IDE seperti Visual Studio Code.
- Kode aplikasi diterapkan ke repositori GitHub.
- GitHub Actions membangun gambar kontainer dari kode aplikasi dan mendorong gambar kontainer ke Azure Container Registry.
- GitHub Actions memperbarui file penyebaran manifes Kubernetes dengan versi gambar saat ini yang didasarkan pada nomor versi gambar kontainer di Azure Container Registry.
- Operator Flux mendeteksi penyimpangan konfigurasi di repositori Git dan menarik perubahan konfigurasi.
- Flux menggunakan file manifes untuk menyebarkan aplikasi ke kluster AKS.
Skenario 3: GitOps dengan ARGO CD, repositori GitHub, dan AKS
Unduh file Visio arsitektur ini.
Aliran data untuk skenario 3
Dalam skenario ini, administrator Kubernetes dapat mengubah objek konfigurasi Kubernetes, seperti rahasia dan Konfigurasi Peta, dan menerapkan perubahan langsung ke repositori GitHub.
Aliran data untuk skenario ini adalah:
- Administrator Kubernetes membuat perubahan konfigurasi dalam file YAML dan menerapkan perubahan pada repositori GitHub.
- Argo CD menarik perubahan dari repositori Git.
- Argo CD menyesuaikan perubahan konfigurasi pada kluster AKS.
Argo CD tidak harus secara otomatis menyinkronkan status target yang diinginkan ke kluster AKS. Ini diimplementasikan sebagai pengontrol Kubernetes yang terus memantau aplikasi yang sedang berjalan. Ini membandingkan status langsung kluster AKS saat ini dengan status target yang diinginkan yang ditentukan dalam repositori Git. ARGO CD melaporkan dan memvisualisasikan perbedaan, sambil menyediakan fasilitas untuk secara otomatis atau manual menyinkronkan status langsung kembali ke status target yang diinginkan.
Argo CD menyediakan antarmuka pengguna berbasis browser. Anda dapat menggunakannya untuk menambahkan konfigurasi aplikasi, mengamati status sinkronisasi sehubungan dengan kluster, dan memulai sinkronisasi terhadap kluster. Anda juga dapat menggunakan baris perintah CD Argo untuk melakukan hal-hal ini. Antarmuka pengguna dan antarmuka baris perintah menyediakan fitur untuk melihat riwayat perubahan konfigurasi dan untuk mengembalikan ke versi sebelumnya.
Secara default, antarmuka pengguna CD Argo dan server API tidak terekspos. Untuk mengaksesnya, kami sarankan Anda membuat pengontrol ingress yang memiliki alamat IP internal. Atau, Anda dapat menggunakan load balancer internal untuk mengeksposnya.
Alternatif untuk skenario 3
Repositori apa pun yang kompatibel dengan Git, termasuk Azure DevOps, dapat berfungsi sebagai repositori sumber konfigurasi.
Skenario 4: Gunakan GitOps dengan ARGO CD, GitHub Actions, dan AKS untuk Mengimplementasikan CI/CD
Unduh file Visio arsitektur ini.
Aliran data untuk skenario 4
Skenario ini adalah alur DevOps berbasis tarik untuk aplikasi web biasa. Alur menggunakan GitHub Actions untuk build. Untuk penyebaran, ia menggunakan ARGO CD sebagai operator GitOps untuk menarik dan menyinkronkan aplikasi. Data mengalir melalui skenario sebagai berikut:
- Kode aplikasi dikembangkan dengan menggunakan IDE seperti Visual Studio Code.
- Kode aplikasi diterapkan ke repositori GitHub.
- GitHub Actions membangun gambar kontainer dari kode aplikasi dan mendorong gambar kontainer ke Azure Container Registry.
- GitHub Actions memperbarui file penyebaran manifes Kubernetes dengan versi gambar saat ini yang didasarkan pada nomor versi gambar kontainer di Azure Container Registry.
- Argo CD menarik dari repositori Git.
- Argo CD menyebarkan aplikasi ke kluster AKS.
Alternatif untuk skenario 4
Repositori apa pun yang kompatibel dengan Git, termasuk Azure DevOps, dapat berfungsi sebagai repositori sumber konfigurasi.
Detail skenario
GitOps adalah serangkaian prinsip untuk mengoperasikan dan mengelola sistem perangkat lunak.
- Ini menggunakan kontrol sumber sebagai sumber tunggal kebenaran untuk sistem.
- Ini menerapkan praktik pengembangan seperti kontrol versi, kolaborasi, kepatuhan, dan integrasi berkelanjutan/penyebaran berkelanjutan (CI/CD) ke otomatisasi infrastruktur.
- Anda dapat menerapkannya ke sistem perangkat lunak apa pun.
GitOps sering digunakan untuk manajemen kluster Kubernetes dan pengiriman aplikasi. Artikel ini menjelaskan beberapa opsi umum untuk menggunakan GitOps bersama dengan kluster AKS.
Menurut prinsip GitOps, status yang diinginkan dari sistem yang dikelola GitOps harus:
- Deklaratif: Sistem yang dikelola GitOps harus memiliki status yang diinginkan yang dinyatakan secara deklaratif. Deklarasi biasanya disimpan dalam repositori Git.
- Versi dan tidak dapat diubah: Status yang diinginkan disimpan dengan cara yang memberlakukan kekekalan dan penerapan versi, dan mempertahankan riwayat versi lengkap.
- Ditarik secara otomatis: Agen perangkat lunak secara otomatis menarik deklarasi status yang diinginkan dari sumbernya.
- Terus direkonsiliasi: Agen perangkat lunak terus mengamati status sistem aktual dan mencoba menerapkan status yang diinginkan.
Di GitOps, infrastruktur sebagai kode (IaC) menggunakan kode untuk mendeklarasikan status komponen infrastruktur yang diinginkan seperti komputer virtual (VM), jaringan, dan firewall. Kode ini dikendalikan versi dan dapat diaudit.
Kubernetes menjelaskan semuanya mulai dari status kluster hingga penyebaran aplikasi secara deklaratif dengan manifes. GitOps untuk Kubernetes menempatkan infrastruktur kluster status yang diinginkan di bawah kontrol versi. Komponen dalam kluster, biasanya disebut operator, terus menyinkronkan status deklaratif. Pendekatan ini memungkinkan untuk meninjau dan mengaudit perubahan kode yang memengaruhi kluster. Ini meningkatkan keamanan dengan mendukung prinsip hak istimewa paling sedikit.
Agen GitOps terus mendamaikan status sistem dengan status yang diinginkan yang disimpan di repositori kode Anda. Beberapa agen GitOps dapat mengembalikan operasi yang dilakukan di luar kluster, seperti pembuatan manual objek Kubernetes. Pengontrol penerimaan, misalnya, menerapkan kebijakan pada objek selama operasi buat, perbarui, dan hapus. Anda dapat menggunakannya untuk memastikan bahwa penyebaran berubah hanya jika kode penyebaran di repositori sumber berubah.
Anda dapat menggabungkan alat manajemen dan penegakan kebijakan dengan GitOps untuk memberlakukan kebijakan dan memberikan umpan balik untuk perubahan kebijakan yang diusulkan. Anda dapat mengonfigurasi pemberitahuan untuk berbagai tim untuk memberi mereka status GitOps terbaru. Misalnya, Anda dapat mengirim pemberitahuan keberhasilan penyebaran dan kegagalan rekonsiliasi.
GitOps sebagai sumber kebenaran tunggal
GitOps memberikan konsistensi dan standardisasi status kluster, dan dapat membantu meningkatkan keamanan. Anda juga dapat menggunakan GitOps untuk memastikan status konsisten di beberapa kluster. Misalnya, GitOps dapat menerapkan konfigurasi yang sama di seluruh kluster primer dan pemulihan bencana (DR), atau di seluruh farm kluster.
Jika Anda ingin memberlakukan bahwa hanya GitOps yang dapat mengubah status kluster, Anda dapat membatasi akses langsung ke kluster. Ada berbagai cara untuk melakukan ini, termasuk kontrol akses berbasis peran Azure (RBAC), pengontrol penerimaan, dan alat lainnya.
Menggunakan GitOps untuk bootstrap konfigurasi awal
Anda dapat memiliki kebutuhan untuk menyebarkan kluster AKS sebagai bagian dari konfigurasi garis besar. Contohnya adalah Anda harus menyebarkan sekumpulan layanan bersama atau konfigurasi sebelum menyebarkan beban kerja. Layanan bersama ini dapat mengonfigurasi add-on AKS seperti:
- ID Beban Kerja Microsoft Entra.
- Penyedia Azure Key Vault untuk Driver Secrets Store CSI.
- Alat mitra seperti:
- Alat sumber terbuka seperti:
Anda dapat mengaktifkan Flux sebagai ekstensi yang diterapkan saat membuat kluster AKS. Fluks kemudian dapat melakukan bootstrap konfigurasi garis besar ke kluster. Arsitektur Garis Besar untuk kluster AKS menyarankan penggunaan GitOps untuk bootstrapping. Jika Anda menggunakan ekstensi Flux, Anda dapat bootstrap kluster segera setelah Anda menyebarkan.
Alat dan add-on GitOps lainnya
Anda dapat memperluas skenario yang dijelaskan ke alat GitOps lainnya. Jenkins X adalah alat GitOps lain yang menyediakan instruksi untuk diintegrasikan ke Azure. Anda dapat menggunakan alat pengiriman progresif seperti Flagger untuk pergeseran beban kerja produksi secara bertahap yang disebarkan melalui GitOps.
Kemungkinan kasus penggunaan
Solusi ini menguntungkan setiap organisasi yang menginginkan keuntungan dari penerapan aplikasi dan infrastruktur sebagai kode, dengan jejak audit dari setiap perubahan.
GitOps melindungi pengembang dari kompleksitas pengelolaan lingkungan kontainer. Pengembang dapat terus bekerja dengan alat yang sudah dikenal seperti Git untuk mengelola pembaruan dan fitur baru. Dengan cara ini, GitOps meningkatkan produktivitas pengembang.
Pertimbangan
Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.
Keandalan
Keandalan memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keandalan.
Salah satu pilar utama keandalan adalah ketahanan. Tujuan ketahanan adalah untuk mengembalikan aplikasi ke keadaan berfungsi penuh setelah kegagalan terjadi. Jika kluster menjadi tidak tersedia, GitOps dapat membuat yang baru dengan cepat. Ini menggunakan repositori Git sebagai sumber tunggal kebenaran untuk konfigurasi Kubernetes dan logika aplikasi. Ini dapat membuat dan menerapkan konfigurasi kluster dan penyebaran aplikasi sebagai unit skala dan dapat menetapkan pola stempel penyebaran.
Keamanan
Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.
Dengan pendekatan GitOps, masing-masing pengembang atau administrator tidak langsung mengakses kluster Kubernetes untuk menerapkan perubahan atau pembaruan. Sebagai gantinya, pengguna mendorong perubahan ke repositori Git dan operator GitOps (Flux atau Argo CD) membaca perubahan dan menerapkannya ke kluster. Pendekatan ini mengikuti praktik terbaik keamanan dengan hak istimewa minimal dengan tidak memberikan izin tulis kepada tim DevOps ke API Kubernetes. Dalam skenario diagnostik atau pemecahan masalah, Anda dapat memberikan izin kluster untuk waktu yang terbatas berdasarkan kasus.
Terlepas dari tugas menyiapkan izin repositori, pertimbangkan untuk menerapkan langkah-langkah keamanan berikut di repositori Git yang disinkronkan ke klaster AKS:
- Perlindungan cabang: Lindungi cabang yang mewakili status kluster Kubernetes agar perubahan tidak diterapkan ke mereka secara langsung. Gunakan PR untuk membuat perubahan, dan memiliki setidaknya satu orang lain meninjau setiap PR. Selain itu, gunakan PR untuk melakukan pemeriksaan otomatis.
- Tinjauan PR: Mewajibkan PR untuk memiliki setidaknya satu peninjau, untuk menegakkan prinsip empat mata. Anda juga dapat menggunakan fitur pemilik kode GitHub untuk menentukan individu atau tim yang bertanggung jawab untuk meninjau file tertentu dalam repositori.
- Riwayat yang tidak dapat diubah: Hanya izinkan penerapan baru di atas perubahan yang ada. Riwayat yang tidak dapat diubah sangat penting untuk tujuan audit.
- Langkah-langkah keamanan lebih lanjut: Mengharuskan pengguna GitHub Anda untuk mengaktifkan autentikasi dua faktor. Selain itu, izinkan hanya penerapan yang ditandatangani, untuk mencegah perubahan.
Pengoptimalan biaya
Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.
- Pada tingkat gratis, AKS menawarkan manajemen kluster gratis. Biaya terbatas pada sumber daya komputasi, penyimpanan, dan jaringan yang digunakan AKS untuk menghosting simpul.
- GitHub menawarkan layanan gratis, tetapi untuk menggunakan fitur terkait keamanan canggih seperti pemilik kode atau peninjau yang diperlukan, Anda memerlukan paket Tim. Untuk informasi selengkapnya, lihat halaman harga GitHub.
- Azure DevOps menawarkan tingkat gratis yang dapat Anda gunakan untuk beberapa skenario.
- Gunakan kalkulator harga Azure untuk memperkirakan biaya.
Keunggulan operasional
Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Gambaran umum pilar keunggulan operasional.
GitOps dapat meningkatkan produktivitas DevOps. Salah satu fitur yang paling berguna adalah kemampuan untuk memutar kembali perubahan yang berperilaku tak terduga dengan cepat, hanya dengan melakukan operasi Git. Grafik penerapan masih berisi semua penerapan, sehingga dapat membantu dengan analisis post-mortem.
Tim GitOps sering mengelola beberapa lingkungan untuk aplikasi yang sama. Biasanya memiliki beberapa tahap aplikasi yang disebarkan ke kluster atau namespace Layanan Kubernetes yang berbeda. Repositori Git, yang merupakan sumber tunggal, menunjukkan versi aplikasi mana yang saat ini digunakan ke kluster.
Menyebarkan skenario
Daftar berikut ini menyediakan referensi untuk informasi tentang penyebaran lima skenario:
- Skenario 1: Untuk panduan tentang menggunakan GitOps dengan Flux v2 untuk menyebarkan aplikasi ke AKS, lihat Tutorial: Menyebarkan aplikasi menggunakan GitOps dengan Flux v2. Untuk contoh cara menggunakan ekstensi Flux untuk bootstrap penyebaran kluster AKS, lihat implementasi referensi untuk garis besar AKS.
- Skenario 2: Untuk panduan tentang menggunakan GitOps dengan Flux v2 di AKS untuk menyebarkan aplikasi dan untuk menerapkan CI/CD, lihat: Tutorial: Menerapkan CI/CD dengan GitOps (Flux v2).
- Skenario 3 dan 4: Untuk panduan langkah demi langkah tentang menyebarkan beban kerja sampel dengan Argo CD dan AKS, lihat skenario CI/CD berbasis pull di AKS Baseline Automation.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Francis Simy Nazareth | Arsitek Solusi Cloud Utama
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.
Langkah berikutnya
- Dokumentasi CD Argo
- Dokumentasi FLUX CD
- GitOps dengan Jenkins X
- Apa yang dimaksud dengan kontrol akses berbasis peran Azure (Azure RBAC)?
Sumber daya terkait
- Arsitektur dasar untuk klaster Azure Kubernetes Service (AKS)
- Garis besar AKS untuk kluster multiregion
- Membangun dan menyebarkan aplikasi di AKS menggunakan DevOps dan GitOps
- DevSecOps di Azure Kubernetes Service (AKS)
- DevSecOps untuk infrastruktur sebagai kode (IaC)
- Infrastruktur perusahaan sebagai kode menggunakan Bicep dan Azure Container Registry
- Mengotomatiskan konfigurasi ulang infrastruktur dengan menggunakan Azure