Geekly articles weekly

Pengantar GitOps untuk OpenShift

Hari ini kita akan berbicara tentang prinsip dan model GitOps, serta bagaimana model ini diimplementasikan pada platform OpenShift. Panduan online untuk topik ini tersedia di sini .



Singkatnya, GitOps adalah serangkaian metode praktis untuk menggunakan permintaan tarikan Git untuk mengelola infrastruktur dan konfigurasi aplikasi. Repositori Git dalam GitOps dianggap sebagai satu sumber tunggal informasi tentang status sistem, dan setiap perubahan dalam status ini dipantau dan diaudit sepenuhnya.

Gagasan pelacakan perubahan di GitOps sama sekali tidak baru, pendekatan ini telah lama digunakan hampir di mana-mana ketika bekerja dengan kode sumber aplikasi. GitOps hanya mengimplementasikan fungsi yang serupa (memeriksa pemeriksaan, menarik permintaan, tag, dll.) Ketika mengelola infrastruktur dan konfigurasi aplikasi dan memberikan keuntungan yang sama seperti dalam hal pengelolaan kode sumber.

Untuk GitOps, tidak ada definisi akademis atau seperangkat aturan yang disetujui, hanya seperangkat prinsip yang menjadi dasar praktik ini:

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

Prinsip GitOps


  • Definisi sistem digambarkan sebagai kode sumber.

Konfigurasi sistem dianggap sebagai kode, sehingga dapat disimpan dan secara otomatis diversi dalam repositori Git, yang berfungsi sebagai satu-satunya sumber kebenaran. Pendekatan ini memudahkan untuk meluncurkan dan mengembalikan perubahan ke sistem.

  • Keadaan yang diinginkan dan konfigurasi sistem diatur dan diversi dalam Git

Dengan menyimpan dan membuat versi dalam Git keadaan sistem yang diinginkan, kami mendapatkan kemampuan untuk dengan mudah menggulung dan mengembalikan perubahan ke sistem dan aplikasi. Kami juga dapat menggunakan mekanisme keamanan Git untuk mengontrol kepemilikan kode dan memverifikasi keasliannya.

  • Perubahan konfigurasi dapat diterapkan secara otomatis menggunakan permintaan tarik.

Menggunakan permintaan Git pull, kita dapat dengan mudah mengontrol bagaimana perubahan diterapkan pada konfigurasi dalam repositori. Misalnya, mereka dapat dikirim untuk verifikasi ke anggota tim lain atau dijalankan melalui tes CI, dll.

Dan pada saat yang sama Anda tidak perlu memberikan otoritas admin ke kanan dan kiri. Untuk melakukan perubahan konfigurasi, pengguna memiliki izin yang cukup di repositori Git tempat konfigurasi ini disimpan.

  • Perbaiki Konfigurasi Drift yang Tidak Terkontrol

Ketika keadaan yang diinginkan dari sistem disimpan dalam repositori Git, kita hanya dapat menemukan perangkat lunak yang akan mengontrol bahwa keadaan sistem saat ini sesuai dengan keadaan yang diinginkan. Jika tidak, maka perangkat lunak ini harus - tergantung pada pengaturan - baik memperbaiki perbedaan sendiri atau memberi tahu kami tentang penyimpangan konfigurasi.

Model GitOps untuk OpenShift


Rekonsiliasi Sumber Daya On-Cluster


Menurut model ini, cluster memiliki pengontrol yang bertanggung jawab untuk membandingkan sumber daya Kubernetes (file YAML) di repositori Git dengan sumber daya cluster nyata. Dalam hal perbedaan, pengontrol mengirimkan pemberitahuan dan, mungkin, mengambil tindakan untuk menghilangkan ketidakkonsistenan. Model GitOps ini digunakan oleh Anthos Config Management dan Weaveworks Flux.



Rekonsiliasi Sumber Daya Eksternal (Push)


Model ini dapat dianggap sebagai variasi dari yang sebelumnya, ketika kami memiliki satu atau lebih pengontrol yang bertanggung jawab untuk menyinkronkan sumber daya berpasangan "Git repository - Kubernetes cluster". Perbedaannya di sini adalah bahwa setiap cluster yang dikelola tidak harus memiliki pengontrol terpisah. Pasangan kluster Git - k8s sering didefinisikan sebagai CRD definisi sumber daya khusus, yang menggambarkan bagaimana pengontrol harus melakukan sinkronisasi. Dalam model ini, pengontrol membandingkan repositori Git yang ditentukan dalam CRD dengan sumber daya dari cluster Kubernetes, yang juga didefinisikan dalam CRD, dan melakukan tindakan yang sesuai berdasarkan hasil perbandingan. Secara khusus, model GitOps digunakan dalam ArgoCD.



GitOps pada Platform OpenShift


Administrasi Infrastruktur Multicluster Kubernetes


Dengan penyebaran Kubernetes dan semakin populernya strategi multi-cloud dan komputasi tepi, jumlah rata-rata cluster OpenShift per pelanggan juga meningkat.

Misalnya, saat menggunakan komputasi periferal, kelompok pelanggan tunggal dapat digunakan dalam ratusan atau bahkan ribuan. Akibatnya, ia dipaksa untuk mengelola beberapa cluster OpenShift yang independen atau terkoordinasi di cloud publik dan di lokasi.

Pada saat yang sama, banyak masalah yang harus diselesaikan, khususnya:

  • Untuk mengontrol bahwa cluster berada dalam kondisi yang identik (konfigurasi, pemantauan, penyimpanan, dll.)
  • Menciptakan kembali (atau mengembalikan) cluster sesuai dengan kondisi yang diketahui.
  • Buat cluster baru sesuai dengan kondisi yang diketahui.
  • Tarik perubahan pada beberapa cluster OpenShift.
  • Kembalikan perubahan ke beberapa kluster OpenShift.
  • Tautan konfigurasi berpola dengan lingkungan yang berbeda.

Konfigurasi aplikasi


Selama siklus hidup mereka, aplikasi sering melewati rantai cluster (dev, stage, dll) sebelum mereka masuk ke cluster produksi. Selain itu, karena persyaratan ketersediaan dan skalabilitas, pelanggan sering menggunakan aplikasi pada beberapa kluster di lokasi atau di beberapa wilayah platform cloud publik.

Dalam hal ini, tugas-tugas berikut harus diselesaikan:
  • Pastikan perpindahan aplikasi (binari, konfigurasi, dll.) Antar kluster (dev, stage, dll.).
  • Gabungkan perubahan dalam aplikasi (binari, konfigurasi, dll.) Di beberapa cluster OpenShift.
  • Kembalikan perubahan dalam aplikasi ke tingkat kondisi yang diketahui sebelumnya.

Skenario Penggunaan OpenShift GitOps


1. Terapkan perubahan dari repositori Git


Administrator cluster dapat menyimpan konfigurasi cluster OpenShift di repositori Git dan secara otomatis menerapkannya untuk membuat cluster baru tanpa usaha ekstra dan membawanya ke kondisi yang identik dengan kondisi yang diketahui yang tersimpan dalam repositori Git.

2. Sinkronkan dengan Manajer Rahasia


Administrator juga akan merasa berguna untuk menyinkronkan objek rahasia OpenShift dengan perangkat lunak yang sesuai seperti Vault untuk mengelolanya menggunakan alat yang dibuat khusus untuk ini.

3. Kontrol konfigurasi drift


Admin hanya akan mendukung jika OpenShift GitOps akan mendeteksi dan memperingatkan tentang perbedaan antara konfigurasi nyata dan yang ditentukan dalam repositori, sehingga Anda dapat dengan cepat menanggapi penyimpangan.

4. Notifikasi Drift Konfigurasi


Ini akan sangat berguna ketika admin ingin mencari tahu tentang konfigurasi drift dengan cepat untuk mengambil tindakan yang tepat sendiri.

5. Sinkronisasi manual konfigurasi saat melayang


Mengizinkan administrator untuk menyinkronkan klaster OpenShift dengan repositori Git jika terjadi konfigurasi melayang untuk mengembalikan kluster dengan cepat ke kondisi yang diketahui sebelumnya.

6. Sinkronisasi otomatis dari konfigurasi drift


Administrator juga dapat mengonfigurasi OpenShift cluster untuk secara otomatis menyinkronkan dengan repositori ketika drift terdeteksi, sehingga konfigurasi cluster selalu cocok dengan konfigurasi di Git.

7. Beberapa Cluster - Satu Repositori


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

8. Hierarki konfigurasi cluster (pewarisan)


Admin dapat mengatur hierarki konfigurasi cluster di repositori (stage, prod, portofolio aplikasi, dll. Dengan pewarisan). Dengan kata lain, ini dapat menentukan bagaimana konfigurasi harus diterapkan - ke satu atau beberapa cluster.

Misalnya, jika administrator menetapkan hierarki "Cluster Produksi (prod) → Cluster Sistem X → Cluster Produksi Sistem X" di repositori Git, maka konfigurasi berikut diterapkan pada kluster produksi System X:

  • Konfigurasi umum untuk semua kluster produksi.
  • Konfigurasi untuk sistem cluster X.
  • Konfigurasi untuk kluster produksi sistem X.

9. Pola dan konfigurasi menimpa


Administrator dapat mengesampingkan set konfigurasi yang diwariskan dan nilainya, misalnya, untuk menyempurnakan konfigurasi untuk kluster tertentu yang akan diterapkan.

10. Termasuk secara selektif dan pengecualian untuk konfigurasi, konfigurasi aplikasi


Administrator dapat mengatur kondisi untuk menerapkan atau tidak menerapkan konfigurasi tertentu untuk kluster dengan karakteristik tertentu.

11. Dukungan pola


Pengembang akan merasa berguna untuk memilih bagaimana sumber daya aplikasi akan ditentukan (Helm Chart, murni Kubernetes yaml, dll.) Untuk menggunakan format yang paling cocok untuk setiap aplikasi spesifik.

Alat GitOps pada platform OpenShift


Argocd


ArgoCD mengimplementasikan model Rekonsiliasi Sumber Daya Eksternal dan menawarkan UI terpusat untuk mengatur hubungan antara cluster dan repositori Git dengan cara satu-ke-banyak. Kerugian dari program ini termasuk ketidakmampuan untuk mengelola aplikasi sementara ArgoCD tidak berfungsi.

Situs web resmi

Fluks


Flux mengimplementasikan model On-Cluster Resource Reconcile, dan sebagai hasilnya, tidak ada manajemen terpusat dari repositori definisi, yang merupakan titik lemah. Di sisi lain, justru karena kurangnya sentralisasi, kemampuan untuk mengelola aplikasi dipertahankan bahkan ketika satu cluster gagal.

Situs web resmi

Instal ArgoCD pada OpenShift


ArgoCD menawarkan antarmuka baris perintah dan konsol web yang sangat baik, jadi kami tidak akan mempertimbangkan Flux dan alternatif lain di sini.

Untuk menggunakan ArgoCD pada platform OpenShift 4, ikuti langkah-langkah ini sebagai administrator cluster:

Menyebarkan 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 dilihat oleh 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

Menyebarkan ArgoCD Cli Tool


 # 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

Ubah kata sandi admin, ArgoCD Server


 # 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 ArgoCD Server melalui konsol web ArgoCD WebUI atau alat baris perintah ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Tidak Pernah Terlambat


“Kereta telah pergi” - inilah yang mereka katakan tentang situasi ketika kesempatan untuk melakukan sesuatu terlewatkan. Dalam kasus OpenShift, keinginan untuk segera mulai menggunakan platform keren baru ini sering kali menciptakan situasi seperti itu dengan pengelolaan dan pemeliharaan rute, penyebaran, dan objek OpenShift lainnya. Tetapi apakah peluang selalu benar-benar terlewatkan?

Melanjutkan serangkaian artikel tentang GitOps , hari ini kami akan menunjukkan cara mengubah aplikasi yang dibuat secara manual dan sumber dayanya menjadi proses tertentu di mana GitOps toolkit mengontrol semuanya. Untuk melakukan ini, pertama-tama kita menggunakan aplikasi httpd dengan tangan kita. Tangkapan layar di bawah ini menunjukkan bagaimana kami membuat namespace, penyebaran, dan layanan, dan kemudian 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 yang dibuat secara manual. Sekarang itu harus ditransfer di bawah kendali GitOps tanpa kehilangan ketersediaan. Singkatnya, ia melakukan ini:

  • Buat repositori Git untuk kode tersebut.
  • Kami mengekspor objek kami saat ini dan memuatnya ke repositori Git.
  • Pilih dan gunakan toolkit GitOps.
  • Tambahkan repositori kami ke toolkit ini.
  • Kami mendefinisikan aplikasi di toolkit GitOps kami.
  • Lakukan uji coba aplikasi menggunakan GitOps toolkit.
  • Kami menyinkronkan objek menggunakan toolkit GitOps.
  • Kami mengaktifkan pemangkasan dan sinkronisasi otomatis objek.

Seperti yang disebutkan dalam artikel sebelumnya, GitOps memiliki satu dan hanya satu sumber informasi tentang semua objek di kluster Kubernet (s) - repositori Git. Selanjutnya, kami melanjutkan dari premis bahwa organisasi Anda sudah menggunakan repositori Git. Ini bisa publik atau pribadi, tetapi harus tersedia untuk cluster Kubernetes. Ini bisa menjadi repositori yang sama dengan kode aplikasi, atau repositori terpisah yang dibuat khusus untuk penyebaran. Disarankan agar Anda memiliki izin ketat di repositori, karena objek rahasia, rute, dan hal-hal sensitif keamanan lainnya akan disimpan di sana.

Dalam contoh kita, kita akan membuat repositori publik baru di GitHub. Anda dapat memberi nama apa pun yang Anda suka, kami menggunakan nama blogpost.

Jika file YAML objek tidak disimpan secara lokal atau di Git, Anda harus menggunakan binari oc atau kubectl. Pada tangkapan layar di bawah, kami meminta YAML untuk namespace, penyebaran, layanan, dan rute kami. Sebelum itu, kami mengkloning repositori yang baru dibuat dan pindah ke sana dengan perintah cd.

 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 perbaiki file deployment.yaml untuk menghapus bidang yang tidak dapat disinkronkan oleh Argo CD.

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

Selain itu, Anda perlu mengubah rute. Kami pertama-tama akan mengatur variabel multiline, dan kemudian mengganti masuknya: null dengan isi dari variabel ini.

 export ROUTE=" ingress:\\ - conditions:\\ - status: 'True'\\ type: Admitted" sed -i "s/ ingress: null/$ROUTE/g" route.yaml

Jadi, dengan file yang diurutkan, masih menyimpannya di 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 ArgoCD sudah digunakan untuk Anda (bagaimana melakukan ini, lihat posting sebelumnya). Oleh karena itu, kami menambah CD Argo repositori yang kami buat yang berisi kode aplikasi dari contoh kami. Pastikan Anda menentukan repositori yang Anda buat sebelumnya.

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

Sekarang buat aplikasinya. Aplikasi menetapkan nilai sehingga GitOps toolkit memahami repositori dan jalur mana yang harus digunakan, yang OpenShift diperlukan untuk mengelola objek, serta cabang repositori tertentu 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 ini mulai memeriksa objek yang sudah dikerahkan untuk kepatuhan dengan definisi dalam repositori. Dalam contoh kami, sinkronisasi otomatis dan pembersihan dinonaktifkan, sehingga elemen-elemennya belum berubah. Harap dicatat bahwa di antarmuka Argo CD, aplikasi kami akan memiliki status "Tidak Sinkron" (Tidak disinkronkan), karena tidak ada label label yang ditempelkan ArgoCD.
Itulah sebabnya, ketika kami memulai sinkronisasi beberapa saat kemudian, penempatan kembali objek tidak akan dilakukan.

Sekarang jalankan uji coba untuk memastikan bahwa tidak ada kesalahan dalam file kami.

 argocd app sync simple-app --dry-run

Jika tidak ada kesalahan, maka Anda dapat melanjutkan ke sinkronisasi.

 argocd app sync simple-app

Setelah menjalankan perintah get argocd pada aplikasi kita, kita akan melihat bahwa status aplikasi telah berubah menjadi Healthy or Synced. Ini berarti bahwa semua sumber daya di repositori Git sekarang sesuai dengan sumber daya yang sudah digunakan.

 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 ...

Tetapi sekarang Anda dapat mengaktifkan sinkronisasi dan pembersihan otomatis untuk memastikan bahwa tidak ada yang akan dibuat secara manual dan bahwa setiap kali objek dibuat atau diperbarui dalam repositori, penyebaran akan dilakukan.

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

Jadi, kami berhasil mentransfer ke aplikasi GitOps yang awalnya tidak menggunakan GitOps.

Source: https://habr.com/ru/post/id478852/

More articles:


All Articles