🥇OpenShift için GitOps'a Giriş

Bugün GitOps'un prensiplerinden, modellerinden ve bu modellerin OpenShift platformunda nasıl uygulandığından bahsedeceğiz. Bu konuyla ilgili etkileşimli bir kılavuz mevcuttur по ссылке.

Özetle GitOps, altyapı ve uygulama yapılandırmalarını yönetmek için Git çekme isteklerini kullanmaya yönelik bir dizi uygulamadır. GitOps'taki Git deposu, sistemin durumu hakkında tek bir bilgi kaynağı olarak kabul edilir ve bu durumdaki herhangi bir değişiklik tamamen izlenebilir ve denetlenebilir.

GitOps'ta değişiklik izleme fikri kesinlikle yeni değildir; bu yaklaşım, uygulama kaynak koduyla çalışırken neredeyse evrensel olarak uzun süredir kullanılmaktadır. GitOps, altyapı ve uygulama konfigürasyon yönetiminde benzer özellikleri (incelemeler, çekme istekleri, etiketler vb.) basitçe uygular ve kaynak kodu yönetiminde olduğu gibi benzer faydalar sağlar.

GitOps için akademik bir tanım veya onaylanmış kurallar dizisi yoktur; yalnızca bu uygulamanın üzerine inşa edildiği bir dizi ilke vardır:

Sistemin bildirimsel açıklaması Git deposunda saklanır (yapılandırmalar, izleme vb.).
Durum değişiklikleri çekme istekleri yoluyla yapılır.
Çalışan sistemlerin durumu, Git push istekleri kullanılarak depodaki verilerle uyumlu hale getirilir.

GitOps İlkeleri

Sistem tanımları kaynak kodu olarak tanımlanır

Sistem yapılandırması kod olarak ele alınır, böylece tek bir gerçek kaynak olarak hizmet veren Git deposunda saklanabilir ve otomatik olarak sürümü oluşturulabilir. Bu yaklaşım, sistemlerdeki değişikliklerin kullanıma sunulmasını ve geri alınmasını kolaylaştırır.

Sistemlerin istenen durumu ve konfigürasyonu Git'te ayarlanır ve versiyonlanır

Sistemlerin istenen durumunu Git'te depolayıp sürümlendirerek, sistemlerde ve uygulamalarda yapılan değişiklikleri kolayca kullanıma sunabiliyor ve geri alabiliyoruz. Kod sahipliğini kontrol etmek ve orijinalliğini doğrulamak için Git'in güvenlik mekanizmalarını da kullanabiliriz.

Yapılandırma değişiklikleri çekme istekleri aracılığıyla otomatik olarak uygulanabilir

Git çekme isteklerini kullanarak değişikliklerin depodaki konfigürasyonlara nasıl uygulandığını kolayca kontrol edebiliriz. Örneğin, gözden geçirilmeleri veya CI testlerinden geçmeleri vb. için diğer ekip üyelerine verilebilirler.

Aynı zamanda yönetici yetkilerini sola ve sağa dağıtmaya gerek yoktur. Yapılandırma değişikliklerini gerçekleştirmek için kullanıcıların yalnızca bu yapılandırmaların depolandığı Git deposunda uygun izinlere ihtiyacı vardır.

Konfigürasyonların kontrolsüz kayması sorununun düzeltilmesi

Sistemin istenen durumu Git deposunda saklandıktan sonra tek yapmamız gereken, sistemin mevcut durumunun istenen durumla eşleşmesini sağlayacak yazılımı bulmaktır. Durum böyle değilse, bu yazılımın - ayarlara bağlı olarak - ya tutarsızlığı kendi başına ortadan kaldırması ya da konfigürasyon sapması hakkında bizi bilgilendirmesi gerekir.

OpenShift için GitOps Modelleri

Küme İçi Kaynak Uzlaştırıcıları

Bu modele göre küme, Git deposundaki Kubernetes kaynaklarını (YAML dosyaları) kümenin gerçek kaynaklarıyla karşılaştırmaktan sorumlu bir denetleyiciye sahiptir. Tutarsızlıklar tespit edilirse kontrolör bildirimler gönderir ve muhtemelen tutarsızlıkları düzeltmek için harekete geçer. Bu GitOps modeli Anthos Config Management ve Weaveworks Flux'ta kullanılır.

Dış Kaynak Uzlaştırıcısı (Push)

Bu model, “Git deposu - Kubernetes kümesi” çiftlerinde kaynakların senkronizasyonundan sorumlu bir veya daha fazla denetleyiciye sahip olduğumuzda, önceki modelin bir varyasyonu olarak düşünülebilir. Buradaki fark, yönetilen her kümenin mutlaka kendi ayrı denetleyicisine sahip olmamasıdır. Git - k8s küme çiftleri genellikle denetleyicinin senkronizasyonu nasıl gerçekleştirmesi gerektiğini tanımlayabilen CRD'ler (özel kaynak tanımları) olarak tanımlanır. Bu modelde denetleyiciler, CRD'de belirtilen Git deposunu yine CRD'de belirtilen Kubernetes küme kaynaklarıyla karşılaştırır ve karşılaştırma sonuçlarına göre uygun eylemleri gerçekleştirir. Özellikle ArgoCD'de bu GitOps modeli kullanılmaktadır.

OpenShift platformunda GitOps

Çok kümeli Kubernetes altyapısının yönetimi

Kubernetes'in yaygınlaşması ve çoklu bulut stratejileri ile uç bilişimin popülerliğinin artmasıyla birlikte müşteri başına ortalama OpenShift kümesi sayısı da artıyor.

Örneğin, uç bilişimi kullanırken, bir müşterinin kümeleri yüzlerce, hatta binlerce olarak dağıtılabilir. Sonuç olarak, genel bulutta ve şirket içinde birçok bağımsız veya koordineli OpenShift kümesini yönetmek zorunda kalıyor.

Bu durumda, özellikle birçok sorunun çözülmesi gerekir:

Kümelerin aynı durumda olup olmadığını kontrol edin (yapılandırmalar, izleme, depolama vb.)
Bilinen bir duruma göre kümeleri yeniden oluşturun (veya geri yükleyin).
Bilinen bir duruma göre yeni kümeler oluşturun.
Değişiklikleri birden çok OpenShift kümesinde kullanıma sunun.
Birden çok OpenShift kümesindeki değişiklikleri geri alın.
Şablonlu konfigürasyonları farklı ortamlara bağlayın.

Uygulama Yapılandırmaları

Uygulamalar, yaşam döngüleri boyunca genellikle bir üretim kümesine ulaşmadan önce bir kümeler zincirinden (geliştirme, aşama vb.) geçer. Ayrıca, kullanılabilirlik ve ölçeklenebilirlik gereksinimleri nedeniyle müşteriler genellikle uygulamaları birden fazla şirket içi kümeye veya genel bulut platformunun birden çok bölgesine dağıtır.

Bu durumda aşağıdaki görevlerin çözülmesi gerekir:

Uygulamaların (ikili dosyalar, yapılandırmalar vb.) kümeler (geliştirme, aşama vb.) arasında taşınmasını sağlayın.
Çeşitli OpenShift kümelerinde uygulamalarda (ikili dosyalar, yapılandırmalar vb.) değişiklikler yapın.
Uygulamalardaki değişiklikleri bilinen önceki bir duruma geri alın.

OpenShift GitOps Kullanım Durumları

1. Git deposundaki değişiklikleri uygulama

Bir küme yöneticisi, OpenShift küme yapılandırmalarını bir Git deposunda saklayabilir ve bunları zahmetsizce yeni kümeler oluşturmak ve bunları Git deposunda depolanan bilinen duruma benzer bir duruma getirmek için otomatik olarak uygulayabilir.

2. Secret Manager ile senkronizasyon

Yönetici aynı zamanda OpenShift gizli nesnelerini bunun için özel olarak oluşturulmuş araçları kullanarak yönetmek amacıyla Vault gibi uygun yazılımlarla senkronize etme yeteneğinden de yararlanacaktır.

3. Drift konfigürasyonlarının kontrolü

Yönetici, yalnızca OpenShift GitOps'un gerçek yapılandırmalar ile depoda belirtilenler arasındaki tutarsızlıkları kendisi belirlemesi ve uyarması durumunda lehte olacaktır, böylece sürüklenmeye hızlı bir şekilde yanıt verebilirler.

4. Yapılandırma sapması ile ilgili bildirimler

Yöneticinin kendi başına hızlı bir şekilde uygun önlemleri almak için yapılandırma sapması durumları hakkında hızlı bir şekilde bilgi edinmek istediği durumlarda faydalıdırlar.

5. Sürüklenirken konfigürasyonların manuel senkronizasyonu

Yöneticinin, yapılandırmada değişiklik olması durumunda OpenShift kümesini Git deposuyla senkronize etmesine ve kümeyi hızlı bir şekilde bilinen önceki bir duruma döndürmesine olanak tanır.

6.Sürüklenirken konfigürasyonların otomatik senkronizasyonu

Yönetici ayrıca OpenShift kümesini bir sapma algılandığında depoyla otomatik olarak senkronize olacak şekilde yapılandırabilir, böylece küme yapılandırması her zaman Git'teki yapılandırmalarla eşleşir.

7. Birkaç küme - bir depo

Yönetici, birkaç farklı OpenShift kümesinin yapılandırmalarını tek bir Git deposunda saklayabilir ve gerektiğinde bunları seçerek uygulayabilir.

8. Küme yapılandırmalarının hiyerarşisi (devralma)

Yönetici, depodaki küme yapılandırmalarının hiyerarşisini ayarlayabilir (kalıtımla aşama, üretim, uygulama portföyü vb.). Başka bir deyişle, konfigürasyonların bir veya daha fazla kümeye uygulanması gerekip gerekmediğini belirleyebilir.

Örneğin, bir yönetici Git deposunda "Üretim kümeleri (üretim) → Sistem X kümeleri → Sistem X'in üretim kümeleri" hiyerarşisini ayarlarsa, sistem X'in üretim kümelerine aşağıdaki yapılandırmaların bir kombinasyonu uygulanır:

Tüm üretim kümeleri için ortak olan yapılandırmalar.
System X kümesi için yapılandırmalar.
X sistemi üretim kümesine ilişkin yapılandırmalar.

9. Şablonlar ve yapılandırma geçersiz kılmaları

Yönetici, örneğin, bunların uygulanacağı belirli kümeler için yapılandırmaya ince ayar yapmak amacıyla, devralınan bir dizi yapılandırmayı ve bunların değerlerini geçersiz kılabilir.

10. Yapılandırmalar ve uygulama yapılandırmaları için seçmeli dahil etme ve hariç tutma

Yönetici, belirli konfigürasyonların belirli özelliklere sahip kümelere uygulanması veya uygulanmaması için koşulları ayarlayabilir.

11. Şablon desteği

Geliştiriciler, her bir uygulama için en uygun formatı kullanmak amacıyla uygulama kaynaklarının nasıl tanımlanacağını (Helm Chart, saf Kubernetes yaml, vb.) seçebilme olanağından yararlanacak.

OpenShift platformundaki GitOps araçları

Argo CD'si

ArgoCD, Harici Kaynak Uzlaştırma modelini uygular ve kümeler ile Git depoları arasındaki bire çok ilişkilerin düzenlenmesi için merkezi bir kullanıcı arayüzü sunar. Bu programın dezavantajları arasında ArgoCD çalışmadığında uygulamaların yönetilememesi yer almaktadır.

Resmi web sitesi

Akı

Flux, Küme İçi Kaynak Uzlaştırma modelini uygular ve sonuç olarak, zayıf bir nokta olan tanım deposunun merkezi yönetimi yoktur. Öte yandan, tam da merkezileşme eksikliği nedeniyle, bir küme başarısız olsa bile uygulamaları yönetme yeteneği devam ediyor.

Resmi web sitesi

ArgoCD'nin OpenShift'e kurulması

ArgoCD mükemmel bir komut satırı arayüzü ve web konsolu sunar, bu nedenle Flux ve diğer alternatifleri burada ele almayacağız.

ArgoCD'yi OpenShift 4 platformunda dağıtmak için küme yöneticisi olarak şu adımları izleyin:

ArgoCD bileşenlerini OpenShift platformunda dağıtma

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

ArgoCD Sunucusunun OpenShift Route tarafından görülebilecek şekilde iyileştirilmesi

# 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

ArgoCD Cli Aracını Dağıtma

# 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

ArgoCD Sunucusu yönetici şifresini değiştirme

# 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

Bu adımları tamamladıktan sonra ArgoCD WebUI web konsolu veya ArgoCD Cli komut satırı aracı aracılığıyla ArgoCD Sunucusu ile çalışabilirsiniz.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Asla Çok Geç Değil

"Tren gitti" - bir şeyler yapma fırsatının kaçırıldığı bir durum hakkında söyledikleri budur. OpenShift söz konusu olduğunda, bu harika yeni platformu hemen kullanmaya başlama arzusu, rotaların, dağıtımların ve diğer OpenShift nesnelerinin yönetimi ve bakımında genellikle tam olarak bu durumu yaratır. Ama şans her zaman tamamen kaybedilir mi?

Konuyla ilgili yazı serimize devam ediyoruz GitOps, bugün size el yapımı bir uygulamayı ve kaynaklarını, her şeyin GitOps araçları tarafından yönetildiği bir sürece nasıl dönüştüreceğinizi göstereceğiz. Bunu yapmak için öncelikle httpd uygulamasını manuel olarak dağıtacağız. Aşağıdaki ekran görüntüsünde nasıl bir ad alanı, dağıtım ve hizmet oluşturduğumuz ve ardından bu hizmeti bir rota oluşturmak için nasıl kullanıma sunduğumuz gösterilmektedir.

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

Yani el yapımı bir uygulamamız var. Artık kullanılabilirlik kaybı olmadan GitOps yönetimi altında aktarılması gerekiyor. Kısaca şunu yapıyor:

Kod için bir Git deposu oluşturun.
Mevcut nesnelerimizi dışa aktarıp Git deposuna yüklüyoruz.
GitOps araçlarını seçme ve dağıtma.
Depomuzu bu araç setine ekliyoruz.
Uygulamayı GitOps araç setimizde tanımlıyoruz.
GitOps araç setini kullanarak uygulamanın bir test çalıştırmasını gerçekleştiriyoruz.
GitOps araç setini kullanarak nesneleri senkronize ediyoruz.
Nesnelerin budanmasını ve otomatik senkronizasyonunu etkinleştirin.

Önceki de belirtildiği gibi MakaleGitOps'ta Kubernetes kümesindeki/kümelerindeki tüm nesneler hakkında tek bir bilgi kaynağı vardır: Git deposu. Daha sonra, kuruluşunuzun zaten bir Git deposu kullandığı varsayımından yola çıkıyoruz. Herkese açık veya özel olabilir ancak Kubernetes kümeleri tarafından erişilebilir olması gerekir. Bu, uygulama koduyla aynı depo veya özellikle dağıtımlar için oluşturulmuş ayrı bir depo olabilir. Sırlar, rotalar ve diğer güvenlik açısından hassas şeyler orada saklanacağından, depoda sıkı izinlere sahip olmanız önerilir.

Örneğimizde GitHub üzerinde yeni bir genel depo oluşturacağız. İstediğiniz gibi adlandırabilirsiniz, biz blogpost adını kullanıyoruz.

YAML nesne dosyaları yerel olarak veya Git'te saklanmadıysa oc veya kubectl ikili dosyalarını kullanmanız gerekecektir. Aşağıdaki ekran görüntüsünde ad alanımız, dağıtımımız, hizmetimiz ve rotamız için YAML istiyoruz. Bundan önce yeni oluşturulan depoyu ve cd'yi buraya kopyaladık.

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

Şimdi Argo CD'sinin senkronize edemediği alanı kaldırmak için Distribution.yaml dosyasını düzenleyelim.

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

Ayrıca güzergahın da değişmesi gerekiyor. Önce çok satırlı bir değişken belirleyeceğiz ve ardından ingress: null değerini bu değişkenin içeriğiyle değiştireceğiz.

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

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

Böylece dosyaları sıraladık, geriye kalan tek şey onları Git deposuna kaydetmek. Bundan sonra bu depo tek bilgi kaynağı haline gelir ve nesnelerde herhangi bir manuel değişiklik yapılması kesinlikle yasaklanmalıdır.

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

Ayrıca ArgoCD'yi zaten dağıtmış olduğunuz gerçeğinden yola çıkıyoruz (bunun nasıl yapılacağı - önceki bölüme bakın) postalamak). Bu nedenle örneğimizdeki uygulama kodunu içeren oluşturduğumuz repository'yi Argo CD'sine ekleyeceğiz. Daha önce oluşturduğunuz depoyu tam olarak belirttiğinizden emin olun.

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

Şimdi uygulamayı oluşturalım. Uygulama, GitOps araç setinin hangi depoyu ve yolları kullanacağını, nesneleri yönetmek için hangi OpenShift'e ihtiyaç duyulduğunu, deponun hangi belirli dalına ihtiyaç duyulduğunu ve kaynakların otomatik olarak senkronize edilmesi gerekip gerekmediğini anlaması için değerleri ayarlar.

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

Argo CD'sinde bir uygulama belirtildiğinde, araç seti halihazırda konuşlandırılmış nesneleri depodaki tanımlara göre kontrol etmeye başlar. Örneğimizde otomatik senkronizasyon ve temizleme devre dışı olduğundan öğeler henüz değişmedi. Lütfen Argo CD arayüzünde ArgoCD'nin sağladığı bir etiket olmadığından uygulamamızın “Senkronizasyon Dışı” durumuna sahip olacağını unutmayın.
Bu nedenle senkronizasyona biraz sonra başladığımızda nesneler yeniden konuşlandırılmayacaktır.

Şimdi dosyalarımızda hata olmadığından emin olmak için bir test çalıştırması yapalım.

argocd app sync simple-app --dry-run

Hata yoksa senkronizasyona devam edebilirsiniz.

argocd app sync simple-app

Uygulamamız üzerinde argocd get komutunu çalıştırdıktan sonra uygulama durumunun Sağlıklı veya Senkronize olarak değiştiğini görmeliyiz. Bu, Git deposundaki tüm kaynakların artık halihazırda dağıtılmış olan kaynaklara karşılık geldiği anlamına gelecektir.

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

Artık hiçbir şeyin manuel olarak oluşturulmadığından ve depoda bir nesne oluşturulduğunda veya güncellendiğinde bir dağıtımın gerçekleşeceğinden emin olmak için otomatik senkronizasyonu ve temizlemeyi etkinleştirebilirsiniz.

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

Böylece başlangıçta hiçbir şekilde GitOps kullanmayan bir uygulamayı GitOps kontrolü altına başarıyla aldık.

Kaynak: habr.com

OpenShift için GitOps'a Giriş