🥇Pengenalan GitOps untuk OpenShift

Hari ini kita akan membahas tentang prinsip dan model GitOps, serta bagaimana model ini diimplementasikan pada platform OpenShift. Panduan interaktif tentang topik ini tersedia по ссылке.

Singkatnya, GitOps adalah serangkaian praktik untuk menggunakan permintaan Git pull untuk mengelola infrastruktur dan konfigurasi aplikasi. Repositori Git di GitOps diperlakukan sebagai satu sumber informasi tentang status sistem, dan setiap perubahan pada status ini dapat dilacak dan diaudit sepenuhnya.

Ide pelacakan perubahan di GitOps bukanlah hal baru; pendekatan ini telah lama digunakan hampir secara universal saat bekerja dengan kode sumber aplikasi. GitOps hanya mengimplementasikan fitur serupa (ulasan, permintaan tarik, tag, dll.) dalam manajemen konfigurasi infrastruktur dan aplikasi dan memberikan manfaat serupa seperti dalam kasus manajemen kode sumber.

Tidak ada definisi akademis atau seperangkat aturan yang disetujui untuk GitOps, yang ada hanyalah seperangkat prinsip yang mendasari praktik ini:

Deskripsi deklaratif sistem disimpan di repositori Git (konfigurasi, pemantauan, dll.).
Perubahan status dilakukan melalui permintaan tarik.
Keadaan sistem yang berjalan disesuaikan dengan data di repositori menggunakan permintaan push Git.

Prinsip GitOps

Definisi sistem digambarkan sebagai kode sumber

Konfigurasi sistem diperlakukan sebagai kode sehingga dapat disimpan dan secara otomatis dibuat versinya di repositori Git, yang berfungsi sebagai satu sumber kebenaran. Pendekatan ini memudahkan peluncuran dan pengembalian perubahan dalam sistem.

Status dan konfigurasi sistem yang diinginkan diatur dan dibuat versinya di Git

Dengan menyimpan dan membuat versi status sistem yang diinginkan di Git, kami dapat dengan mudah menerapkan dan mengembalikan perubahan pada sistem dan aplikasi. Kita juga dapat menggunakan mekanisme keamanan Git untuk mengontrol kepemilikan kode dan memverifikasi keasliannya.

Perubahan konfigurasi dapat diterapkan secara otomatis melalui permintaan tarik

Dengan menggunakan permintaan Git pull, kita dapat dengan mudah mengontrol bagaimana perubahan diterapkan pada konfigurasi di repositori. Misalnya, data tersebut dapat diberikan kepada anggota tim lain untuk ditinjau atau dijalankan melalui tes CI, dll.

Dan pada saat yang sama, tidak perlu membagi kekuasaan admin ke kiri dan ke kanan. Untuk melakukan perubahan konfigurasi, pengguna hanya memerlukan izin yang sesuai di repositori Git tempat konfigurasi tersebut disimpan.

Memperbaiki masalah penyimpangan konfigurasi yang tidak terkendali

Setelah keadaan sistem yang diinginkan disimpan dalam repositori Git, yang harus kita lakukan adalah menemukan perangkat lunak yang akan memastikan bahwa keadaan sistem saat ini sesuai dengan keadaan yang diinginkan. Jika tidak demikian, maka perangkat lunak ini harus - tergantung pada pengaturannya - menghilangkan perbedaan itu sendiri, atau memberi tahu kami tentang penyimpangan konfigurasi.

Model GitOps untuk OpenShift

Rekonsiliasi Sumber Daya Dalam Klaster

Menurut model ini, cluster memiliki pengontrol yang bertanggung jawab untuk membandingkan sumber daya Kubernetes (file YAML) di repositori Git dengan sumber daya cluster yang sebenarnya. Jika perbedaan terdeteksi, pengontrol mengirimkan pemberitahuan dan mungkin mengambil tindakan untuk memperbaiki perbedaan tersebut. Model GitOps ini digunakan di Anthos Config Management dan Weaveworks Flux.

Rekonsiliasi Sumber Daya Eksternal (Dorong)

Model ini dapat dianggap sebagai variasi dari model sebelumnya, ketika kita memiliki satu atau lebih pengontrol yang bertanggung jawab untuk menyinkronkan sumber daya dalam pasangan “repositori Git - cluster Kubernetes”. Perbedaannya di sini adalah setiap cluster yang dikelola belum tentu memiliki pengontrolnya sendiri-sendiri. Pasangan cluster Git - k8s sering didefinisikan sebagai CRD (definisi sumber daya khusus), yang dapat menjelaskan bagaimana pengontrol harus melakukan sinkronisasi. Dalam model ini, pengontrol membandingkan repositori Git yang ditentukan dalam CRD dengan sumber daya cluster Kubernetes, yang juga ditentukan dalam CRD, dan melakukan tindakan yang sesuai berdasarkan hasil perbandingan tersebut. Secara khusus, model GitOps ini digunakan di ArgoCD.

GitOps di platform OpenShift

Administrasi infrastruktur multi-cluster Kubernetes

Dengan tersebarnya Kubernetes dan semakin populernya strategi multi-cloud dan edge computing, jumlah rata-rata cluster OpenShift per pelanggan juga meningkat.

Misalnya, saat menggunakan komputasi tepi, satu cluster pelanggan dapat disebarkan ke ratusan atau bahkan ribuan cluster. Akibatnya, ia terpaksa mengelola beberapa cluster OpenShift yang independen atau terkoordinasi di cloud publik dan on-premise.

Dalam hal ini, banyak masalah yang harus diselesaikan, khususnya:

Kontrol bahwa cluster berada dalam keadaan yang identik (konfigurasi, pemantauan, penyimpanan, dll.)
Membuat ulang (atau memulihkan) klaster berdasarkan keadaan yang diketahui.
Buat klaster baru berdasarkan status yang diketahui.
Meluncurkan perubahan pada beberapa klaster OpenShift.
Mengembalikan perubahan di beberapa klaster OpenShift.
Tautkan konfigurasi templat ke lingkungan berbeda.

Konfigurasi Aplikasi

Selama siklus hidupnya, aplikasi sering kali melewati rantai cluster (dev, stage, dll.) sebelum berakhir di cluster produksi. Selain itu, karena persyaratan ketersediaan dan skalabilitas, pelanggan sering kali menerapkan aplikasi di beberapa klaster lokal atau beberapa wilayah pada platform cloud publik.

Dalam hal ini, tugas-tugas berikut harus diselesaikan:

Memastikan pergerakan aplikasi (biner, konfigurasi, dll.) antar cluster (dev, stage, dll.).
Meluncurkan perubahan pada aplikasi (biner, konfigurasi, dll.) di beberapa cluster OpenShift.
Mengembalikan perubahan pada aplikasi ke keadaan yang diketahui sebelumnya.

Kasus Penggunaan OpenShift GitOps

1. Menerapkan perubahan dari repositori Git

Administrator klaster dapat menyimpan konfigurasi klaster OpenShift di repositori Git dan secara otomatis menerapkannya untuk membuat klaster baru dengan mudah dan membawanya ke status yang identik dengan status yang diketahui yang disimpan di repositori Git.

2. Sinkronisasi dengan Secret Manager

Administrator juga akan mendapatkan keuntungan dari kemampuan untuk menyinkronkan objek rahasia OpenShift dengan perangkat lunak yang sesuai seperti Vault untuk mengelolanya menggunakan alat yang dibuat khusus untuk ini.

3. Pengendalian konfigurasi drift

Admin hanya akan mendukung jika OpenShift GitOps sendiri mengidentifikasi dan memperingatkan tentang perbedaan antara konfigurasi sebenarnya dan yang ditentukan dalam repositori, sehingga mereka dapat dengan cepat merespons penyimpangan.

4. Pemberitahuan tentang penyimpangan konfigurasi

Mereka berguna jika administrator ingin segera mempelajari kasus penyimpangan konfigurasi agar dapat segera mengambil tindakan yang tepat.

5. Sinkronisasi konfigurasi manual saat drifting

Mengizinkan admin menyinkronkan klaster OpenShift dengan repositori Git jika terjadi penyimpangan konfigurasi, untuk segera mengembalikan klaster ke keadaan yang diketahui sebelumnya.

6. Sinkronisasi otomatis konfigurasi saat melayang

Administrator juga dapat mengonfigurasi klaster OpenShift agar secara otomatis melakukan sinkronisasi dengan repositori ketika penyimpangan terdeteksi, sehingga konfigurasi klaster selalu cocok dengan konfigurasi di Git.

7. Beberapa cluster - satu repositori

Administrator dapat menyimpan konfigurasi beberapa cluster OpenShift yang berbeda dalam satu repositori Git dan menerapkannya secara selektif sesuai kebutuhan.

8. Hierarki konfigurasi cluster (warisan)

Admin dapat mengatur hierarki konfigurasi cluster di repositori (tahap, produksi, portofolio aplikasi, dll. dengan warisan). Dengan kata lain, ini dapat menentukan apakah konfigurasi harus diterapkan pada satu atau lebih cluster.

Misalnya, jika administrator menetapkan hierarki “Kluster produksi (prod) → Kluster Sistem X → Kluster produksi sistem X” di repositori Git, maka kombinasi konfigurasi berikut diterapkan ke kluster produksi sistem X:

Konfigurasi umum untuk semua kluster produksi.
Konfigurasi untuk kluster Sistem X.
Konfigurasi untuk kluster produksi sistem X.

9. Template dan konfigurasi override

Administrator dapat mengganti sekumpulan konfigurasi yang diwariskan dan nilainya, misalnya, untuk menyempurnakan konfigurasi untuk klaster tertentu yang akan menerapkan konfigurasi tersebut.

10. Penyertaan dan pengecualian selektif untuk konfigurasi, konfigurasi aplikasi

Administrator dapat mengatur kondisi penerapan atau non penerapan konfigurasi tertentu pada cluster dengan karakteristik tertentu.

11. Dukungan templat

Pengembang akan mendapatkan keuntungan dari kemampuan untuk memilih bagaimana sumber daya aplikasi akan ditentukan (Helm Chart, yaml Kubernetes murni, dll.) untuk menggunakan format yang paling sesuai untuk setiap aplikasi spesifik.

Alat GitOps pada platform OpenShift

ArgoCD

ArgoCD mengimplementasikan model Rekonsiliasi Sumber Daya Eksternal dan menawarkan UI terpusat untuk mengatur hubungan satu-ke-banyak antara klaster dan repositori Git. Kekurangan dari program ini antara lain ketidakmampuan mengelola aplikasi saat ArgoCD tidak berfungsi.

Website resmi

Aliran

Flux mengimplementasikan model Rekonsiliasi Sumber Daya On-Cluster dan, sebagai hasilnya, tidak ada manajemen terpusat dari repositori definisi, yang merupakan titik lemahnya. Di sisi lain, justru karena kurangnya sentralisasi, kemampuan mengelola aplikasi tetap ada meskipun satu cluster gagal.

Website resmi

Menginstal ArgoCD di OpenShift

ArgoCD menawarkan antarmuka baris perintah dan konsol web yang luar biasa, jadi kami tidak akan membahas Flux dan alternatif lain di sini.

Untuk menyebarkan ArgoCD pada platform OpenShift 4, ikuti langkah-langkah berikut sebagai administrator klaster:

Menerapkan komponen ArgoCD pada platform OpenShift

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

Perbaikan Server ArgoCD agar dapat dilihat melalui OpenShift Route

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

Menerapkan Alat ArgoCD Cli

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

Mengubah kata sandi admin Server ArgoCD

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

Setelah menyelesaikan langkah-langkah ini, Anda dapat bekerja dengan Server ArgoCD melalui konsol web ArgoCD WebUI atau alat baris perintah ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Tidak Ada Kata Terlambat

“Kereta telah berangkat” - inilah yang mereka katakan tentang situasi ketika kesempatan untuk melakukan sesuatu terlewatkan. Dalam kasus OpenShift, keinginan untuk segera mulai menggunakan platform baru yang keren ini sering kali menciptakan situasi yang persis sama dengan pengelolaan dan pemeliharaan rute, penerapan, dan objek OpenShift lainnya. Namun apakah peluang selalu hilang sepenuhnya?

Melanjutkan rangkaian artikel tentang GitOps, hari ini kami akan menunjukkan kepada Anda cara mengubah aplikasi buatan tangan dan sumber dayanya menjadi proses yang semuanya dikelola oleh alat GitOps. Untuk melakukan ini, pertama-tama kita akan menerapkan aplikasi httpd secara manual. Tangkapan layar di bawah menunjukkan cara kita membuat namespace, penerapan, dan layanan, lalu mengekspos layanan ini untuk membuat rute.

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

Jadi kami memiliki aplikasi buatan tangan. Sekarang perlu ditransfer di bawah manajemen GitOps tanpa kehilangan ketersediaan. Singkatnya, ia melakukan ini:

Buat repositori Git untuk kode tersebut.
Kami mengekspor objek kami saat ini dan mengunggahnya ke repositori Git.
Memilih dan menerapkan alat GitOps.
Kami menambahkan repositori kami ke toolkit ini.
Kami mendefinisikan aplikasi di toolkit GitOps kami.
Kami melakukan uji coba aplikasi menggunakan toolkit GitOps.
Kami menyinkronkan objek menggunakan toolkit GitOps.
Aktifkan pemangkasan dan sinkronisasi otomatis objek.

Seperti yang sudah disebutkan sebelumnya Artikel, di GitOps hanya ada satu sumber informasi tentang semua objek di cluster Kubernetes - repositori Git. Selanjutnya, kami melanjutkan dari premis bahwa organisasi Anda sudah menggunakan repositori Git. Ini bisa bersifat publik atau pribadi, tetapi harus dapat diakses oleh cluster Kubernetes. Ini bisa berupa repositori yang sama dengan kode aplikasi, atau repositori terpisah yang dibuat khusus untuk penerapan. Disarankan untuk memiliki izin yang ketat di repositori karena rahasia, rute, dan hal sensitif keamanan lainnya akan disimpan di sana.

Dalam contoh kita, kita akan membuat repositori publik baru di GitHub. Anda bisa menyebutnya sesuka Anda, kami menggunakan nama blogpost.

Jika file objek YAML tidak disimpan secara lokal atau di Git, Anda harus menggunakan binari oc atau kubectl. Pada tangkapan layar di bawah ini kami meminta YAML untuk namespace, penerapan, layanan, dan rute kami. Sebelum ini, kami mengkloning repositori yang baru dibuat dan melakukan cd ke dalamnya.

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

Sekarang mari kita edit file deployment.yaml untuk menghapus kolom yang tidak dapat disinkronkan oleh CD Argo.

sed -i '/sgeneration: .*/d' deployment.yaml

Selain itu, rutenya perlu diubah. Pertama-tama kita akan menetapkan variabel multiline dan kemudian mengganti ingress: null dengan konten variabel tersebut.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

Jadi, kami telah memilah file-file tersebut, yang tersisa hanyalah menyimpannya ke repositori Git. Setelah itu repositori ini menjadi satu-satunya sumber informasi, dan segala perubahan manual pada objek harus dilarang keras.

git commit -am ‘initial commit of objects’
git push origin master

Selanjutnya kami melanjutkan dari fakta bahwa Anda telah menerapkan ArgoCD (cara melakukan ini - lihat sebelumnya pos). Oleh karena itu, kami akan menambahkan ke CD Argo repositori yang kami buat, yang berisi kode aplikasi dari contoh kami. Pastikan Anda menentukan repositori persis seperti yang Anda buat sebelumnya.

argocd repo add https://github.com/cooktheryan/blogpost

Sekarang mari kita buat aplikasinya. Aplikasi menetapkan nilai sehingga toolkit GitOps memahami repositori dan jalur mana yang akan digunakan, OpenShift mana yang diperlukan untuk mengelola objek, cabang repositori spesifik mana yang diperlukan, dan apakah sumber daya harus disinkronkan secara otomatis.

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

Setelah aplikasi ditentukan dalam CD Argo, toolkit mulai memeriksa objek yang sudah diterapkan berdasarkan definisi di repositori. Dalam contoh kita, sinkronisasi otomatis dan pembersihan dinonaktifkan, sehingga elemennya belum berubah. Perlu diketahui bahwa pada interface Argo CD aplikasi kita akan berstatus “Out of Sync” karena tidak ada label yang disediakan ArgoCD.
Inilah sebabnya ketika kita memulai sinkronisasi nanti, objek tidak akan di-deploy ulang.

Sekarang mari kita lakukan uji coba untuk memastikan tidak ada kesalahan pada file kita.

argocd app sync simple-app --dry-run

Jika tidak ada kesalahan, Anda dapat melanjutkan ke sinkronisasi.

argocd app sync simple-app

Setelah menjalankan perintah argocd get pada aplikasi kita, kita akan melihat bahwa status aplikasi telah berubah menjadi Sehat atau Tersinkronisasi. Ini berarti bahwa semua sumber daya di repositori Git sekarang sesuai dengan sumber daya yang telah disebarkan.

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...

Sekarang Anda dapat mengaktifkan sinkronisasi dan pembersihan otomatis untuk memastikan tidak ada yang dibuat secara manual dan bahwa setiap kali objek dibuat atau diperbarui ke repositori, penerapan akan terjadi.

argocd app set simple-app --sync-policy automated --auto-prune

Jadi, kami telah berhasil membawa aplikasi di bawah kendali GitOps yang awalnya tidak menggunakan GitOps dengan cara apa pun.

Sumber: www.habr.com

Pengantar GitOps untuk OpenShift