🥇Pengenalan kepada GitOps untuk OpenShift

Hari ini kita akan bercakap tentang prinsip dan model GitOps, serta cara model ini dilaksanakan pada platform OpenShift. Panduan interaktif mengenai topik ini tersedia по ссылке.

Secara ringkasnya, GitOps ialah satu set amalan untuk menggunakan permintaan tarik Git untuk mengurus infrastruktur dan konfigurasi aplikasi. Repositori Git dalam GitOps dianggap sebagai satu sumber maklumat tentang keadaan sistem dan sebarang perubahan pada keadaan ini boleh dikesan dan diaudit sepenuhnya.

Idea penjejakan perubahan dalam GitOps bukanlah baru; pendekatan ini telah lama digunakan hampir secara universal apabila bekerja dengan kod sumber aplikasi. GitOps hanya melaksanakan ciri serupa (semakan, permintaan tarik, teg, dsb.) dalam pengurusan infrastruktur dan konfigurasi aplikasi dan memberikan faedah yang serupa seperti dalam kes pengurusan kod sumber.

Tiada definisi akademik atau set peraturan yang diluluskan untuk GitOps, hanya satu set prinsip di mana amalan ini dibina:

Penerangan deklaratif sistem disimpan dalam repositori Git (konfigurasi, pemantauan, dll.).
Perubahan negeri dibuat melalui permintaan tarik.
Keadaan sistem berjalan dibawa selaras dengan data dalam repositori menggunakan permintaan tolak Git.

Prinsip GitOps

Takrifan sistem diterangkan sebagai kod sumber

Konfigurasi sistem dianggap sebagai kod supaya ia boleh disimpan dan diversi secara automatik dalam repositori Git, yang berfungsi sebagai satu sumber kebenaran. Pendekatan ini memudahkan untuk melancarkan dan melancarkan semula perubahan dalam sistem.

Keadaan dan konfigurasi sistem yang dikehendaki ditetapkan dan versi dalam Git

Dengan menyimpan dan membuat versi keadaan sistem yang diingini dalam Git, kami dapat melancarkan dan melancarkan semula perubahan pada sistem dan aplikasi dengan mudah. Kami juga boleh menggunakan mekanisme keselamatan Git untuk mengawal pemilikan kod dan mengesahkan kesahihannya.

Perubahan konfigurasi boleh digunakan secara automatik melalui permintaan tarik

Menggunakan permintaan tarik Git, kita boleh mengawal dengan mudah cara perubahan digunakan pada konfigurasi dalam repositori. Contohnya, mereka boleh diberikan kepada ahli pasukan lain untuk semakan atau dijalankan melalui ujian CI, dsb.

Dan pada masa yang sama, tidak perlu mengagihkan kuasa admin kiri dan kanan. Untuk melakukan perubahan konfigurasi, pengguna hanya memerlukan kebenaran yang sesuai dalam repositori Git tempat konfigurasi tersebut disimpan.

Menyelesaikan masalah hanyut konfigurasi yang tidak terkawal

Setelah keadaan sistem yang diingini disimpan dalam repositori Git, yang perlu kita lakukan ialah mencari perisian yang akan memastikan keadaan semasa sistem sepadan dengan keadaan yang dikehendakinya. Jika ini tidak berlaku, maka perisian ini harus - bergantung pada tetapan - sama ada menghapuskan percanggahan itu sendiri atau memberitahu kami tentang hanyut konfigurasi.

Model GitOps untuk OpenShift

Penyesuai Sumber Dalam Kluster

Menurut model ini, kluster mempunyai pengawal yang bertanggungjawab untuk membandingkan sumber Kubernetes (fail YAML) dalam repositori Git dengan sumber sebenar kluster. Jika percanggahan dikesan, pengawal menghantar pemberitahuan dan mungkin mengambil tindakan untuk membetulkan percanggahan tersebut. Model GitOps ini digunakan dalam Anthos Config Management dan Weaveworks Flux.

Penyesuai Sumber Luaran (Tolak)

Model ini boleh dianggap sebagai variasi daripada yang sebelumnya, apabila kami mempunyai satu atau lebih pengawal yang bertanggungjawab untuk menyegerakkan sumber dalam pasangan "Repositori Git - gugusan Kubernetes". Perbezaan di sini ialah setiap kluster terurus tidak semestinya mempunyai pengawal tersendiri. Git - pasangan kluster k8s sering ditakrifkan sebagai CRD (definisi sumber tersuai), yang boleh menerangkan cara pengawal harus melakukan penyegerakan. Dalam model ini, pengawal membandingkan repositori Git yang dinyatakan dalam CRD dengan sumber kluster Kubernetes, yang juga dinyatakan dalam CRD dan melakukan tindakan yang sesuai berdasarkan hasil perbandingan. Khususnya, model GitOps ini digunakan dalam ArgoCD.

GitOps pada platform OpenShift

Pentadbiran infrastruktur Kubernetes berbilang kelompok

Dengan penyebaran Kubernetes dan peningkatan populariti strategi berbilang awan dan pengkomputeran tepi, purata bilangan kluster OpenShift bagi setiap pelanggan juga meningkat.

Sebagai contoh, apabila menggunakan pengkomputeran tepi, satu kluster pelanggan boleh digunakan dalam ratusan atau bahkan ribuan. Akibatnya, dia terpaksa mengurus beberapa kluster OpenShift bebas atau diselaraskan dalam awan awam dan di premis.

Dalam kes ini, banyak masalah perlu diselesaikan, khususnya:

Kawal bahawa kluster berada dalam keadaan yang sama (konfigurasi, pemantauan, storan, dsb.)
Buat semula (atau pulihkan) kelompok berdasarkan keadaan yang diketahui.
Buat kelompok baharu berdasarkan keadaan yang diketahui.
Melancarkan perubahan kepada berbilang kluster OpenShift.
Balikkan perubahan merentas berbilang kluster OpenShift.
Pautkan konfigurasi templat ke persekitaran yang berbeza.

Konfigurasi Aplikasi

Semasa kitaran hayatnya, aplikasi sering melalui rangkaian kluster (dev, stage, dsb.) sebelum berakhir dalam kluster pengeluaran. Selain itu, disebabkan keperluan ketersediaan dan kebolehskalaan, pelanggan sering menggunakan aplikasi merentas berbilang kluster di premis atau berbilang wilayah platform awan awam.

Dalam kes ini, tugas berikut perlu diselesaikan:

Pastikan pergerakan aplikasi (perduaan, konfigurasi, dsb.) antara kluster (dev, peringkat, dsb.).
Melancarkan perubahan pada aplikasi (perduaan, konfigurasi, dll.) dalam beberapa kluster OpenShift.
Kembalikan perubahan pada aplikasi kepada keadaan yang diketahui sebelumnya.

Kes Penggunaan OpenShift GitOps

1. Menggunakan perubahan daripada repositori Git

Pentadbir kluster boleh menyimpan konfigurasi kluster OpenShift dalam repositori Git dan menggunakannya secara automatik untuk mencipta kluster baharu dengan mudah dan membawanya ke dalam keadaan yang sama dengan keadaan diketahui yang disimpan dalam repositori Git.

2. Penyegerakan dengan Pengurus Rahsia

Pentadbir juga akan mendapat manfaat daripada keupayaan untuk menyegerakkan objek rahsia OpenShift dengan perisian yang sesuai seperti Vault untuk mengurusnya menggunakan alat yang dicipta khas untuk ini.

3. Kawalan konfigurasi drift

Pentadbir hanya akan memihak jika OpenShift GitOps sendiri mengenal pasti dan memberi amaran tentang percanggahan antara konfigurasi sebenar dan yang dinyatakan dalam repositori, supaya mereka boleh bertindak balas dengan cepat terhadap drift.

4. Pemberitahuan tentang hanyut konfigurasi

Mereka berguna dalam kes apabila pentadbir ingin mengetahui dengan cepat tentang kes-kes hanyut konfigurasi untuk mengambil langkah-langkah yang sesuai dengan cepat sendiri.

5. Penyegerakan manual konfigurasi apabila hanyut

Membenarkan pentadbir menyegerakkan kluster OpenShift dengan repositori Git sekiranya hanyut konfigurasi, untuk mengembalikan kluster ke keadaan yang diketahui sebelumnya dengan cepat.

6.Auto-penyegerakan konfigurasi apabila hanyut

Pentadbir juga boleh mengkonfigurasi kluster OpenShift untuk menyegerakkan secara automatik dengan repositori apabila drift dikesan, supaya konfigurasi kluster sentiasa sepadan dengan konfigurasi dalam Git.

7. Beberapa kluster - satu repositori

Pentadbir boleh menyimpan konfigurasi beberapa kluster OpenShift yang berbeza dalam satu repositori Git dan menggunakannya secara selektif mengikut keperluan.

8. Hierarki konfigurasi kelompok (warisan)

Pentadbir boleh menetapkan hierarki konfigurasi kluster dalam repositori (peringkat, prod, portfolio aplikasi, dll. dengan warisan). Dalam erti kata lain, ia boleh menentukan sama ada konfigurasi harus digunakan pada satu atau lebih kelompok.

Sebagai contoh, jika pentadbir menetapkan hierarki "Kluster pengeluaran (produk) → Kluster Sistem X → Kluster pengeluaran sistem X" dalam repositori Git, maka gabungan konfigurasi berikut digunakan pada kluster pengeluaran sistem X:

Konfigurasi biasa kepada semua kelompok pengeluaran.
Konfigurasi untuk kelompok Sistem X.
Konfigurasi untuk kelompok pengeluaran sistem X.

9. Templat dan penggantian konfigurasi

Pentadbir boleh mengatasi set konfigurasi yang diwarisi dan nilainya, sebagai contoh, untuk memperhalusi konfigurasi bagi kelompok tertentu yang akan digunakan.

10. Selektif termasuk dan tidak termasuk untuk konfigurasi, konfigurasi aplikasi

Pentadbir boleh menetapkan syarat untuk aplikasi atau bukan aplikasi konfigurasi tertentu kepada kelompok dengan ciri tertentu.

11. Sokongan templat

Pembangun akan mendapat manfaat daripada keupayaan untuk memilih cara sumber aplikasi akan ditakrifkan (Carta Helm, yaml Kubernetes tulen, dll.) untuk menggunakan format yang paling sesuai untuk setiap aplikasi tertentu.

Alat GitOps pada platform OpenShift

ArgoCD

ArgoCD melaksanakan model Penyesuaian Sumber Luaran dan menawarkan UI terpusat untuk mengatur hubungan satu-ke-banyak antara kluster dan repositori Git. Kelemahan program ini termasuk ketidakupayaan untuk mengurus aplikasi apabila ArgoCD tidak berfungsi.

Laman web rasmi

Fluks

Flux melaksanakan model Penyesuaian Sumber Pada Kluster dan, akibatnya, tiada pengurusan terpusat bagi repositori definisi, yang merupakan titik lemah. Sebaliknya, tepat kerana kekurangan pemusatan, keupayaan untuk mengurus aplikasi kekal walaupun satu kluster gagal.

Laman web rasmi

Memasang ArgoCD pada OpenShift

ArgoCD menawarkan antara muka baris arahan dan konsol web yang sangat baik, jadi kami tidak akan membincangkan Flux dan alternatif lain di sini.

Untuk menggunakan ArgoCD pada platform OpenShift 4, ikuti langkah ini sebagai pentadbir kluster:

Menggunakan 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}')

Penambahbaikan Pelayan ArgoCD supaya dapat dilihat oleh Laluan OpenShift

# 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

Menggunakan Alat Cli ArgoCD

# 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

Menukar kata laluan pentadbir Pelayan 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

Selepas melengkapkan langkah ini, anda boleh bekerja dengan Pelayan ArgoCD melalui konsol web ArgoCD WebUI atau alat baris arahan ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Tidak Pernah Terlewat

"Kereta api telah pergi" - inilah yang mereka katakan tentang situasi apabila peluang untuk melakukan sesuatu terlepas. Dalam kes OpenShift, keinginan untuk segera mula menggunakan platform baharu yang hebat ini selalunya mewujudkan situasi ini dengan pengurusan dan penyelenggaraan laluan, penempatan dan objek OpenShift yang lain. Tetapi adakah peluang itu sentiasa terlepas sepenuhnya?

Meneruskan siri artikel tentang GitOps, hari ini kami akan menunjukkan kepada anda cara mengubah aplikasi buatan tangan dan sumbernya kepada proses di mana segala-galanya diuruskan oleh alatan GitOps. Untuk melakukan ini, kami akan menggunakan aplikasi httpd secara manual terlebih dahulu. Tangkapan skrin di bawah menunjukkan cara kami mencipta ruang nama, penempatan dan perkhidmatan, kemudian mendedahkan perkhidmatan ini untuk membuat laluan.

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 mempunyai aplikasi buatan tangan. Kini ia perlu dipindahkan di bawah pengurusan GitOps tanpa kehilangan ketersediaan. Ringkasnya, ia melakukan ini:

Buat repositori Git untuk kod.
Kami mengeksport objek semasa kami dan memuat naiknya ke repositori Git.
Memilih dan menggunakan alatan GitOps.
Kami menambah repositori kami ke kit alat ini.
Kami mentakrifkan aplikasi dalam kit alat GitOps kami.
Kami menjalankan ujian aplikasi menggunakan kit alat GitOps.
Kami menyegerakkan objek menggunakan kit alat GitOps.
Dayakan pemangkasan dan penyegerakan automatik objek.

Seperti yang dinyatakan dalam sebelum ini artikel, dalam GitOps terdapat satu dan hanya satu sumber maklumat tentang semua objek dalam gugusan Kubernetes - repositori Git. Seterusnya, kami meneruskan dari premis bahawa organisasi anda sudah menggunakan repositori Git. Ia boleh menjadi awam atau peribadi, tetapi ia mesti boleh diakses oleh kluster Kubernetes. Ini boleh menjadi repositori yang sama seperti untuk kod aplikasi, atau repositori berasingan yang dibuat khusus untuk penempatan. Adalah disyorkan untuk mempunyai kebenaran yang ketat dalam repositori kerana rahsia, laluan dan perkara sensitif keselamatan lain akan disimpan di sana.

Dalam contoh kami, kami akan mencipta repositori awam baharu pada GitHub. Anda boleh memanggilnya apa sahaja yang anda suka, kami menggunakan nama blogpost.

Jika fail objek YAML tidak disimpan secara setempat atau dalam Git, maka anda perlu menggunakan binari oc atau kubectl. Dalam tangkapan skrin di bawah kami meminta YAML untuk ruang nama, penempatan, perkhidmatan dan laluan kami. Sebelum ini, kami mengklonkan repositori yang baru dibuat dan 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 edit fail deployment.yaml untuk mengalih keluar medan yang Argo CD tidak boleh segerakkan.

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

Di samping itu, laluan perlu diubah. Mula-mula kami akan menetapkan pembolehubah berbilang baris dan kemudian menggantikan ingress: null dengan kandungan pembolehubah itu.

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

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

Jadi, kami telah menyusun fail, yang tinggal hanyalah menyimpannya ke repositori Git. Selepas itu repositori ini menjadi satu-satunya sumber maklumat, dan sebarang perubahan manual pada objek hendaklah dilarang sama sekali.

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

Selanjutnya kami meneruskan dari fakta bahawa anda telah menggunakan ArgoCD (bagaimana untuk melakukan ini - lihat sebelumnya jawatan). Oleh itu, kami akan menambah pada CD Argo repositori yang kami buat, yang mengandungi kod aplikasi daripada contoh kami. Cuma pastikan anda menyatakan repositori tepat yang anda buat sebelum ini.

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

Sekarang mari buat aplikasi. Aplikasi ini menetapkan nilai supaya kit alat GitOps memahami repositori dan laluan mana yang hendak digunakan, OpenShift yang diperlukan untuk mengurus objek, cawangan repositori tertentu mana yang diperlukan, dan sama ada sumber harus disegerakkan secara automatik.

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

Sebaik sahaja aplikasi ditentukan dalam CD Argo, kit alat mula menyemak objek yang telah digunakan terhadap definisi dalam repositori. Dalam contoh kami, penyegerakan automatik dan pembersihan dilumpuhkan, jadi elemen tidak berubah lagi. Sila ambil perhatian bahawa dalam antara muka CD Argo aplikasi kami akan mempunyai status "Out of Sync" kerana tiada label yang disediakan oleh ArgoCD.
Inilah sebabnya apabila kita memulakan penyegerakan sedikit kemudian, objek tidak akan digunakan semula.

Sekarang mari kita lakukan ujian untuk memastikan tiada ralat dalam fail kami.

argocd app sync simple-app --dry-run

Jika tiada ralat, maka anda boleh meneruskan ke penyegerakan.

argocd app sync simple-app

Selepas menjalankan arahan argocd get pada aplikasi kami, kami harus melihat bahawa status aplikasi telah berubah kepada Sihat atau Disegerakkan. Ini bermakna semua sumber dalam repositori Git kini sepadan dengan sumber tersebut yang telah 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
...

Kini anda boleh mendayakan penyegerakan automatik dan pembersihan untuk memastikan tiada apa yang dibuat secara manual dan setiap kali objek dibuat atau dikemas kini ke repositori, penggunaan akan berlaku.

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

Jadi, kami telah berjaya membawa aplikasi di bawah kawalan GitOps yang pada mulanya tidak menggunakan GitOps dalam apa jua cara.

Sumber: www.habr.com

Pengenalan kepada GitOps untuk OpenShift