1. Definisi GitOps dan Single Source of Truth (SSOT)
Pertama, mari kita pahami definisi Sistem GitOps. Seperti yang telah dijelaskan sebelumnya mengenai karakteristik Kubernetes yang berbasis deklaratif dan proses instalasinya, semua sumber daya dalam Kubernetes dapat dikonfigurasi menggunakan kode. Sistem GitOps adalah konsep di mana konfigurasi tersebut disimpan dalam repositori Git, dan sistem memastikan bahwa kondisi operasional saat ini (Ops) selalu selaras dengan kode yang tersimpan di Git.
Dalam lingkungan kerja, Sistem GitOps sering digunakan untuk mencegah perubahan langsung pada sistem produksi tanpa melalui proses commit dan push ke Git. Tanpa GitOps, seseorang bisa saja mengubah konfigurasi langsung dari sumber lokalnya atau melalui perintah manual, yang dapat menyulitkan pelacakan riwayat perubahan. Salah satu skenario umum yang sering terjadi adalah ketika hanya sebagian cluster mengalami masalah, dan setelah diperiksa, ternyata ada perubahan yang dilakukan secara manual tanpa terdokumentasi dengan baik. Selain itu, dalam proses membangun sistem baru, tanpa pendekatan GitOps, sering kali diperlukan upaya tambahan untuk mencari dan menerapkan konfigurasi yang benar.Sistem GitOps
Sistem GitOps mengadopsi konsep Single Source of Truth (SSOT), yang juga perlu dipahami dengan baik. SSOT adalah prinsip dalam manajemen data yang menyatakan bahwa hanya ada satu versi data yang akurat dan terpercaya yang digunakan di seluruh sistem. Konsep ini berperan penting dalam meningkatkan konsistensi, akurasi, dan efisiensi dalam pengelolaan sistem.
- Konsistensi: Semua komponen sistem mengacu pada sumber data yang sama, sehingga memastikan bahwa tidak ada perbedaan dalam informasi yang digunakan.
- Akurasi: Mengurangi kemungkinan duplikasi atau inkonsistensi, sehingga meningkatkan keakuratan data.
- Efisiensi: Dengan adanya satu lokasi utama untuk penyimpanan dan pemeliharaan data, proses pembaruan dan manajemen menjadi lebih efisien.
Dengan menerapkan Sistem GitOps dan konsep SSOT, organisasi dapat menjaga stabilitas sistem, meningkatkan keandalan operasional, dan mempermudah manajemen infrastruktur berbasis Kubernetes.
Dalam Sistem GitOps, repositori Git berperan sebagai Single Source of Truth (SSOT) untuk konfigurasi dan status sistem. Dengan menyimpan serta membuat versi dari seluruh kondisi kode dan infrastruktur di dalam repositori Git, sistem dapat dikelola dan diotomatisasi menggunakan pendekatan deklaratif. Ini berarti bahwa perubahan terhadap kondisi operasional tidak dilakukan secara manual oleh individu melalui perintah langsung atau sumber lokal yang belum dikomit, melainkan hanya melalui repositori Git yang terpusat.
Salah satu keuntungan terbesar dari Sistem GitOps, menurut saya, adalah kemampuannya untuk menjaga konsistensi sistem, yang pada akhirnya meningkatkan produktivitas kolaborasi tim. Karena semua sistem dan pengguna mengacu pada satu sumber data yang sama, kemungkinan terjadinya inkonsistensi informasi berkurang, dan upaya serta biaya yang diperlukan untuk mengelola serta menyinkronkan data yang duplikat juga menurun. Selain itu, fitur pencarian untuk melihat kembali status sistem pada titik waktu tertentu juga sering dimanfaatkan.
Namun, menerapkan prinsip ini sering kali tidak mudah. Dalam kesibukan pekerjaan sehari-hari, ada banyak godaan untuk mengabaikan prinsip GitOps dan melakukan perubahan langsung tanpa melalui repositori Git. Oleh karena itu, penting untuk menggunakan alat GitOps yang dapat menegakkan kebijakan serta memastikan adanya arsitektur data, proses, dan alat manajemen yang tepat.
Untuk mengimplementasikan Sistem GitOps, terdapat berbagai alat yang dapat digunakan. Dalam hal Continuous Deployment (CD), ArgoCD adalah salah satu alat yang paling banyak digunakan karena beberapa alasan:
- Menyediakan antarmuka pengguna (UI) yang mudah digunakan.
- Mudah diintegrasikan dengan alat lain.
- Memiliki banyak pengguna, sehingga dokumentasi dan contoh kasusnya melimpah.
Dengan menggunakan ArgoCD, organisasi dapat menerapkan GitOps secara lebih efektif, menjaga konsistensi sistem, dan meningkatkan efisiensi operasional.
ArgoCD: Pemantauan dan Sinkronisasi Otomatis
ArgoCD secara terus-menerus memantau repositori Git yang ditentukan dan klaster Kubernetes. Jika terdeteksi perubahan dalam repositori, ArgoCD secara otomatis menyinkronkan status klaster agar sesuai dengan status di repositori. Selain mode otomatis, ArgoCD juga menyediakan opsi sinkronisasi manual, yang berguna dalam situasi tertentu. Jika terjadi masalah, sistem dapat dengan mudah dikembalikan ke keadaan sebelumnya (rollback). Berkat fitur manajemen versi Git, semua riwayat perubahan dapat dilacak, sehingga pemulihan ke kondisi yang stabil menjadi lebih mudah.
BACA JUGA : Cara Instalasi EKS di AWS Menggunakan Terraform
ArgoCD juga menyediakan dasbor visual yang memungkinkan pengguna untuk memantau status aplikasi secara real-time, melihat sinkronisasi, serta mengevaluasi kesehatan (Health) aplikasi. Saat aplikasi dikelola menggunakan Helm, sering kali sulit untuk memahami keseluruhan sumber daya yang digunakan. Namun, dengan dasbor ArgoCD, pengguna dapat dengan mudah melihat struktur aplikasi mereka, menjadikannya fitur yang sangat disukai. Selain itu, ArgoCD memungkinkan pengaturan kontrol akses berbasis proyek dan pengguna, sehingga anggota tim hanya mendapatkan akses sesuai dengan peran mereka.
ArgoCD menggunakan repositori Git sebagai Single Source of Truth (SSOT) untuk memastikan bahwa status klaster Kubernetes selalu tersinkronisasi dan termonitor secara berkelanjutan. Dengan pendekatan ini, kolaborasi antara tim pengembang dan operasi (DevOps) menjadi lebih efektif, serta proses deployment menjadi lebih stabil dan cepat.
Praktik Langsung ArgoCD
Berikut adalah langkah-langkah praktikum yang akan kita lakukan:
- Instalasi ArgoCD
- Mendeploy Helm Chart NGINX menggunakan ArgoCD
- Eksperimen GitOps – Validasi Perubahan Manual di Lingkungan Lokal
Mari kita mulai dengan langkah pertama!
2. Instalasi Argo-CD
Instalasi Aplikasi di Kubernetes dengan Helm Dalam lingkungan Kubernetes, aplikasi biasanya diinstal menggunakan Helm. Helm adalah manajer paket untuk Kubernetes, mirip dengan APT atau YUM pada sistem operasi berbasis Linux. Dengan Helm, berbagai sumber daya Kubernetes dapat dikemas menjadi satu unit yang disebut chart, sehingga proses instalasi, pembaruan, dan penghapusan aplikasi menjadi lebih sederhana. Pembahasan lebih detail mengenai Helm akan dijelaskan pada Bab 11.
Sekarang, mari kita instal ArgoCD menggunakan Helm.
- Pengguna Windows WSL dengan Homebrew dan pengguna macOS dapat menginstal Helm di PC lokal mereka menggunakan brew.
Sistem GitOps
Selanjutnya, unduh Helm Chart ArgoCD dari situs resmi ArgoCD.
Daftarkan repositori Helm ArgoCD yang ada di remote menggunakan perintah helm repo add
, lalu unduh Helm Chart ke lokal dengan perintah helm pull
.
Setelah itu, untuk menyesuaikan file konfigurasi Helm (Values.yaml) sesuai dengan lingkungan yang digunakan, salin file Values.yaml bawaan dan ubah namanya menjadi jerry-test-values.yaml.
Penjelasan lebih lanjut mengenai perintah Helm dapat ditemukan pada Bab 11.
Berikut adalah modifikasi dari Helm Values resmi (lihat referensi di GitHub penulis).
.configs.credentialTemplates.ssh-creds
Daftarkan informasi repositori GitHub yang akan digunakan dalam ArgoCD. Masukkan informasi kunci SSH yang telah terdaftar di GitHub Anda (biasanya terletak di ~/.ssh/id_rsa
). Karena ini adalah informasi kunci pribadi, untuk alasan keamanan, informasi ini telah dimasking (xxxxx).
Informasi repositori dapat didaftarkan setelah instalasi ArgoCD selesai, dan juga bisa dilakukan melalui antarmuka grafis (GUI). Namun, disarankan untuk mengikuti filosofi GitOps dengan memasukkan informasi repositori Git ke dalam kode sumber. Meskipun mungkin terasa merepotkan di awal, menghindari penggunaan GUI akan lebih baik dalam hal keberlanjutan dan kemampuan untuk digunakan kembali di masa depan.
.repositories.k8s-class.name/url
Daftarkan nama dan URL repositori Git Anda.
Saat ini, pengaturan terkait Ingress belum dilakukan, sehingga pengaturan Helm Values yang berkaitan dengan Ingress masih belum ada. Setelah pengaturan Ingress di Bab 5 selesai, Anda dapat menambahkan konfigurasi Ingress untuk memudahkan akses menggunakan alamat Ingress.
Gunakan file Helm Values tersebut (jerry-test-values.yaml) untuk menginstal ArgoCD.
Setelah instalasi selesai, Anda dapat memeriksa pod yang terkait dengan ArgoCD.
3. Akses Pod Argo-CD Menggunakan Port-Forward
Mari kita akses pod ArgoCD yang telah diinstal menggunakan Port-forward. Untuk mengakses pod yang berjalan di dalam kluster dari luar kluster, kita umumnya menggunakan sumber daya Ingress Kubernetes. Penjelasan lebih lanjut mengenai hal ini akan disampaikan di Bab 5. Saat ini, kita akan menggunakan Port-forward agar administrator dapat dengan mudah mengakses pod tanpa melakukan pengaturan Ingress tambahan. Dalam praktiknya, pod yang tidak dikonfigurasi dengan Ingress karena alasan keamanan juga diakses menggunakan Port-forward.
Port-forward menggunakan perintah kubectl port-forward
. Meskipun perintah port-forward agak panjang, perintah ini mendukung penyelesaian otomatis, sehingga tidak terlalu sulit untuk digunakan. Perintah port-forward memberikan kemampuan untuk meneruskan (port-forward) lalu lintas dari pod tertentu dalam kluster ke port tertentu di sistem lokal Anda. Dengan cara ini, Anda dapat mengakses sumber daya internal kluster secara langsung dari lingkungan pengembangan lokal. Karena port API server telah terhubung untuk menjalankan perintah kubectl, Anda hanya perlu melakukan pengaturan sederhana untuk terhubung ke port internal kluster.
Lalu lintas yang masuk ke port tertentu di sistem lokal akan diteruskan melalui API server ke port tertentu dari pod yang dipilih.
API server Kubernetes bertindak sebagai perantara dalam proses ini, sementara kubelet bertanggung jawab atas pengiriman lalu lintas yang sebenarnya. Sekarang, mari kita gunakan perintah di bawah ini untuk mengakses pod ArgoCD.
Kubernetes mengontrol lalu lintas pod melalui objek service. Menggunakan port-forward dengan service juga lebih nyaman. Penjelasan lebih rinci tentang service akan dibahas di bab berikutnya.
Port 8080 di depan perintah 8080:80
mengacu pada port di localhost, sedangkan port 80 di belakangnya mengacu pada port yang digunakan oleh service di kluster. Dengan kata lain, perintah ini berarti menghubungkan port 8080 di localhost saya ke port 80 di service kluster. Sekarang, jika Anda memasukkan localhost:8080
di browser seperti di bawah ini, Anda akan dapat melihat tampilan ArgoCD.
Kata sandi pengguna 'admin' awal dapat dilihat melalui Secret. Secret adalah objek Kubernetes yang digunakan untuk menyimpan informasi sensitif, seperti kata sandi. Penjelasan lebih lanjut akan dibahas di bagian berikutnya, tetapi saat ini, kita akan mendekode Secret di bawah ini untuk melihat kata sandi dalam bentuk teks biasa.
Masukkan Username sebagai admin dan masukkan hasil output dari perintah di atas ke dalam Password di jendela login. Setelah login, pilih menu ‘Settings’ di sebelah kiri layar, lalu pilih ‘Repositories’, dan Anda akan melihat bahwa repositori GitHub yang telah Anda daftarkan di file Helm Values terdaftar dengan normal.
ArgoCD telah berhasil diinstal dengan normal.
4. Mendeploy NGINX dengan Argo-CD
Sekarang, kita akan mendeploy aplikasi menggunakan ArgoCD yang telah diinstal. Aplikasi yang akan kita deploy adalah Nginx, yang sering digunakan sebagai server web.
Nginx juga akan dideploy menggunakan Helm Chart.
Proses instalasi Helm ini sama seperti sebelumnya. Anda dapat menggunakan versi terbaru dari Nginx web server, tetapi jika Anda ingin konfigurasi yang sama seperti penulis, silakan tentukan versi (15.1.0).
Berikut adalah modifikasi sederhana dari file Helm Values.yaml. File tersebut dapat Anda temukan di GitHub penulis.
Ini adalah perubahan sederhana, seperti mengubah jumlah pod Nginx web server dari pengaturan default menjadi 2. Berdasarkan file Helm Values tersebut, kita akan mendeploy web server Nginx. ArgoCD memungkinkan Anda untuk melakukan pekerjaan ini melalui GUI web untuk mendeploy aplikasi ke lingkungan Kubernetes. Namun, untuk memudahkan penggunaan kembali dan agar sesuai dengan filosofi GitOps, disarankan untuk juga melakukan pengaturan mendeploy aplikasi dalam bentuk kode.
ArgoCD menggunakan Custom Resource Definition (CRD) yang disebut ‘Application’ agar dapat mendeploy melalui kode. CRD adalah fitur yang memungkinkan pengguna untuk mendefinisikan sumber daya khusus di Kubernetes. Secara default, Kubernetes menyediakan sumber daya inti seperti pod, service, dan deployment, tetapi pengguna juga dapat mendefinisikan dan menggunakan jenis sumber daya mereka sendiri.
Dengan menggunakan CRD, pengguna dapat mendefinisikan jenis sumber daya mereka sendiri dan menggunakannya di kluster seolah-olah itu adalah sumber daya bawaan. ArgoCD juga menyediakan sumber daya khusus yang disebut ‘Application’ untuk memudahkan mendeploy aplikasi.
Mari kita buat ArgoCD Application untuk mendeploy Nginx web server. (Lihat di GitHub penulis)
.metadata.finalizers
Opsi ini memungkinkan penghapusan sumber daya ‘Application’ untuk secara bersamaan menghapus sumber daya Kubernetes terkait (seperti pod, dll).
.spec.destination.server
Di sini, Anda menentukan tujuan tempat ArgoCD akan mendeploy aplikasi. Anda dapat menentukan kluster Kubernetes jarak jauh atau Kubernetes tempat ArgoCD diinstal. Jika Anda menetapkan alamat sebagai ‘https://kubernetes.default.svc’, maka itu akan merujuk pada Kubernetes tempat ArgoCD diinstal.
.spec.source.helm
ArgoCD mendukung berbagai bentuk instalasi aplikasi, seperti Helm dan manifest. Dalam praktik ini, karena kita akan menginstal Nginx menggunakan Helm, kita menetapkannya sebagai ‘helm’.
.spec.source.path, repoURL
Menentukan URL repositori GitHub tempat Helm Chart berada dan jalur Helm Chart tersebut.
.spec.syncPolicy.automated.prune/selfHeal
Opsi ini menentukan apakah ArgoCD akan secara otomatis mendeploy aplikasi. Jika Anda ingin Kubernetes secara otomatis mendeploy Helm saat kode sumber diunggah ke Git, Anda dapat menetapkan opsi ‘automated’.
Di lingkungan nyata, di lingkungan Dev dan Stage, opsi ‘automated’ sering digunakan, tetapi di lingkungan produksi, banyak yang tidak menggunakan opsi ‘automated’ untuk memeriksa riwayat perubahan (‘Diff’) secara manual sebelum mendeploy.
Prune adalah opsi yang menghapus sumber daya yang sudah tidak ada di Git, sedangkan opsi selfHeal secara otomatis memulihkan tugas yang gagal.
.spec.syncOptions.CreateNamespace
Opsi ini digunakan untuk secara otomatis membuat namespace.
Karena Application CRD juga merupakan sumber daya Kubernetes, Anda dapat membuat sumber daya tersebut menggunakan perintah ‘kubectl apply’.
Sebuah objek Kubernetes terpisah yang disebut ‘Application’ telah dibuat di ArgoCD. Application di ArgoCD bukanlah aplikasi program pada umumnya, melainkan salah satu jenis objek Kubernetes yang dibuat oleh ArgoCD itu sendiri.
Jika Anda memeriksa menu di sebelah kiri layar di web ArgoCD, Anda akan melihat bahwa argocd/nginx yang baru telah dibuat.
Dengan mengklik menu tersebut, Anda dapat memeriksa sumber daya Kubernetes yang diinstal menggunakan Helm Chart NGINX. Service dan Deployment telah diinstal.
Anda dapat memeriksa pod web server Nginx yang telah diinstal menggunakan perintah.
Dengan demikian, Anda dapat mendistribusikan pod aplikasi menggunakan ArgoCD.
Pada saat pertama kali melakukan distribusi ArgoCD, aplikasi diinstal menggunakan perintah ‘helm install’ di PC lokal. Setelah itu, NGINX tidak diinstal menggunakan perintah ‘helm install’, melainkan didistribusikan menggunakan ArgoCD.
Aplikasi yang diinstal menggunakan perintah di PC lokal tidak dapat disimpan di Git, sehingga sulit untuk dikelola di masa mendatang. Namun, dengan menggunakan ArgoCD, Anda dapat memaksa penyimpanan dan distribusi sumber kode di Git, sehingga lebih mudah untuk menerapkan kebijakan GitOps. Disarankan agar semua aplikasi yang diinstal di Kubernetes didistribusikan menggunakan ArgoCD.
ArgoCD mendukung antarmuka pengguna (UI) yang memudahkan Anda untuk memeriksa sumber daya apa yang telah diinstal menggunakan Helm.
5. Praktik GitOps
Mari kita lihat bagaimana ArgoCD mengimplementasikan GitOps dengan membuat status yang sedang berjalan (Ops) berbeda dari status di Git.
Alih-alih menggunakan kode sumber, kita akan mengubah jumlah pod NGINX dari 2 menjadi 5 menggunakan perintah. Bagi konsol lokal menjadi dua jendela; di bagian atas, kita akan mengubah jumlah pod, dan di bagian bawah, kita akan memantau perubahan secara real-time.
Jendela di bawah akan memantau perubahan pod secara real-time menggunakan perintah ‘k get pod -w (watch)’.
Di jendela atas, kita akan mengubah jumlah pod. Perubahan jumlah pod dilakukan dengan menggunakan perintah scale.
Meskipun kita telah menetapkan jumlah pod menjadi 5 dengan perintah, pod tersebut tidak bertambah. Statusnya menunjukkan 'ContainerCreating' dan pada saat yang sama juga 'Terminating'.
Jumlah pod masih tetap 2. Mengapa hal ini bisa terjadi?
Karena jumlah pod tidak diubah di sumber Git, ArgoCD secara otomatis mempertahankan jumlah pod tetap 2 untuk mencocokkan keadaan kluster saat ini dengan keadaan sumber yang disinkronkan di Git.
Sekarang, untuk memeriksa perbedaan, saya akan menghapus opsi 'automated' di ArgoCD. Opsi 'automated' adalah opsi yang secara otomatis mencocokkan keadaan saat ini dengan keadaan di Git. Dengan menghapus opsi tersebut, ArgoCD tidak akan secara otomatis memperbaiki keadaan saat ini.
Setelah itu, jalankan kembali perintah 'k scale deployment nginx --replicas 5' dan periksa di web ArgoCD; statusnya akan menunjukkan 'OutOfSync'. Seperti yang terlihat dari pesan tersebut, dapat dipastikan bahwa keadaan sumber yang disimpan di Git tidak sinkron dengan keadaan kluster yang sedang berjalan saat ini.
Dengan memeriksa menu 'APP DIFF', Anda dapat melihat pesan yang lebih rinci.
Anda dapat melihat bahwa angka replika pod, yaitu 5 dan 2, saling berbeda.
Dalam lingkungan operasi praktis, sering kali opsi 'automated' dinonaktifkan seperti di atas. Pengguna selalu memeriksa 'Diff' secara manual untuk memastikan adanya masalah dan mengikuti proses penerapan ke cluster yang sebenarnya.
Dengan demikian, jika pengguna mengubah jumlah pod secara manual menggunakan perintah, tetapi opsi 'Automated' diaktifkan, ArgoCD akan secara otomatis menyinkronkan status saat ini dengan sumber Git, sehingga jumlah pod tetap 2.
Sekarang, mari kita ubah jumlah pod dari 2 menjadi 1 di sumber Git. Kita akan mengubah opsi 'replicaCount' dalam file nilai Helm NGINX.
Setelah melakukan commit Git, lakukan push untuk menggabungkan ke main Git. Berikut adalah contoh tampilan layar Git Commit di VSCode yang saya gunakan.
Dengan mengklik ‘REFRESH’ di menu ArgoCD, jumlah pod otomatis berkurang menjadi 1.
Dengan perintah kubectl
, jumlah pod juga berkurang menjadi 1.
Dengan cara ini, ArgoCD menyinkronkan status yang tercermin dalam sumber Git dengan status Kubernetes yang sebenarnya. Semua perubahan dilakukan tidak melalui perintah atau sumber lokal secara sembarangan, tetapi hanya dilakukan di repositori Git terpusat.
Demikian pula, pekerjaan infrastruktur yang menggunakan Terraform juga diterapkan ke status aktual setelah melalui tinjauan PR Git.
Screenshot di atas adalah pesan tinjauan PR yang saya gunakan saat melakukan upgrade EKS. Ini adalah contoh di mana saya telah meminta rekan untuk memverifikasi pekerjaan kode Terraform untuk upgrade EKS melalui tinjauan. Dengan memverifikasi kode yang terkait dengan pekerjaan sebelumnya, saya dapat mengurangi kemungkinan terjadinya masalah selama proses. Kode yang sudah diverifikasi kemudian digabungkan ke dalam branch utama untuk diterapkan ke status yang sebenarnya.
Selain kode Terraform, kode Python untuk pekerjaan lainnya juga disimpan di Git dan diperiksa melalui proses tinjauan.
Contoh di atas adalah kode Python yang mencetak daftar seluruh AWS MSK Cluster berdasarkan setiap region.
Tentu saja, dalam operasional nyata, sulit untuk mendapatkan tinjauan kode untuk setiap pekerjaan karena keterbatasan waktu. Namun, sangat efektif untuk mengadopsi proses di mana semua pekerjaan dilakukan dengan menulis kode terlebih dahulu dan membuat dokumentasi berdasarkan kode tersebut untuk mendapatkan tinjauan dari rekan kerja. Selain itu, setidaknya semua catatan pekerjaan harus disimpan dalam bentuk kode, karena ini akan sangat membantu saat melakukan pekerjaan yang sama di masa mendatang.
Sampai saat ini, saya telah berbagi contoh GitOps dengan ArgoCD. GitOps adalah kebijakan, jadi niat untuk mematuhi kebijakan tersebut sangat penting. Penting untuk melakukan tinjauan kode dengan cermat dan menjaga prosedur kerja, meskipun terasa merepotkan, setiap usaha sehari-hari diperlukan untuk menjaga stabilitas sistem.