AWS'de GitOps'u Uygulamak İçin Flux Kullanımı

  • 399 görüntüleme
  • 18 dakikalık okuma
Hadi Bahadori
  • 8 Nisan 2024
0 Hisse senetleri
0
0
0
0
0
Hisse senetleri
0
0
0
0

giriiş

Birçok kurumsal şirket üretim süreçlerinde Kubernetes'i benimsemiş olsa da, sürekli dağıtım, yüksek güvenlik, izin izolasyonu ve denetim gibi özelliklerin yanı sıra, farklı aşamalarda aynı anda çalışan birden fazla Kubernetes kümesiyle iş çevikliğini nasıl sağlayacakları konusunda genellikle kafaları karışmaktadır. GitOps kullanımı, güvenlik ve izin izolasyonu gibi kurumsal düzeydeki gereksinimleri karşılarken, Kubernetes kümelerine dayalı bu tür sürekli dağıtımları mümkün kılabilir.

Bu blog yazısında, AWS CodeCommit, AWS CodePipeline ve Flux kullanarak bir Amazon EKS ortamında GitOps'u uygulayacağız. Bu Amazon EKS ortamında üretim gereksinimlerini karşılayan bir GitOps iş akışının nasıl kurulacağını ayrıntılı olarak gösterecek ve mikro hizmet uygulamalarının GitOps tarzı bir CI/CD işlem hattında sürekli entegrasyon ve sürekli teslimatı nasıl sağladığını göstereceğiz.

Ön koşullar
  • AWS Deneyimi
  • AWS hesabı

GitOps nedir?

GitOps, bulut uygulamaları için sürekli dağıtım sağlamanın bir yoludur. Geliştirici odaklı bir deneyime odaklanırken, geliştiricilerin zaten aşina olduğu Git ve Sürekli Dağıtım araçları gibi araçları kullanarak altyapıdan yararlanır.

GitOps'un temel fikri, üretimdeki altyapının açıklayıcı bir tanımını ve üretim ortamını depoda açıklanan duruma uygun hale getirmek için otomatik bir süreç içeren bir Git deposuna sahip olmaktır. Yeni bir uygulama dağıtmak veya mevcut bir uygulamayı güncellemek istiyorsanız, deponuzu güncellemeniz yeterlidir. Otomatik süreç her şeyi halleder. Bu, üretimdeki uygulamalarınızı yönetmek için bir hız kontrol sistemine sahip olmak gibidir.

GitOps neden kullanılır?

Git, sistem için tek gerçek durum kaynağıdır. Tekrarlanabilir ve otomatik dağıtım, küme yönetimi ve izlemeyi destekler. Geliştiriciler, kuruluşta yerleşik Git iş akışlarını derleme, test etme, tarama ve diğer sürekli entegrasyon adımları için yeniden kullanırlar. En son sistem durumu ana Git deposuna işlendikten sonra, dağıtımı doğrulamak, uyarıları görüntülemek ve işlemleri düzeltmek için GitOps araç zinciri kullanılır. Temel GitOps ilkelerine dayanarak, GitOps'un Kubernetes kümelerini sürekli olarak dağıtmanın en iyi yolu olduğuna inanıyoruz. Süreç şu şekildedir:


GitOps için Amazon EKS tabanlı en iyi uygulamalar

En iyi uygulamalara göre genel CI/CD boru hattı aşağıdaki şekilde gösterilmiştir.


AWS CodeCommit deposunun altında üç kod deposu bulunmaktadır. Bir flux-repo yapılandırma deposudur Akı CD'si, ilgili kaynakları tanımlamak için kullanılır Akı Diğeri, mikro hizmet uygulama yapılandırmalarını ve dağıtım dosyalarını depolayan microservices-repo'dur. Üçüncüsü ise, iş hizmetleri için kaynak deposu uygulamasıdır. Bu gönderide örnek olarak bir ön uç projesi kullanılmıştır. Boru hattında sürekli entegrasyon için AWS CodePipeline kullanıyoruz. CI/CD Docker imajını kullandık Amazon ECR Flux CD motorunu kaydettik, sakladık ve Amazon EKS ortamında bir pod olarak konuşlandırdık.

Temel iş akışı şu şekildedir:
  • Kodlama mühendisleri kod yazar ve son kodu uygulama deposuna gönderir.
  • Uygulama deposundaki kod değişiklikleri AWS CodePipeline'ı tetikler.
  • AWS CodePipeline kodu düzenler ve paketler, kapsayıcı görüntüleri oluşturur ve bunları kapsayıcı görüntü deposuna/Amazon ECR'ye gönderir.
  • EKS ortamında çalışan Flux CD motoru, ECR konteyner görüntü deposunu düzenli olarak tarar ve uygulamalar için konteyner görüntü meta verilerini çeker.
  • Yeni bir konteyner görüntüsü sürümü algılandığında, yeni konteyner görüntüsünün URL'si otomatik olarak git commit/push aracılığıyla microservices-repo'da saklanan uygulama dağıtım dosyasıyla senkronize edilir.
  • Flux, uygulama yapılandırmalarını ve dağıtım dosyalarını düzenli olarak Flux deposundan çeker. Flux deposu, mikroservis deposuna referans verdiğinden, Flux küme iş yükü yürütme durumunun mikroservis deposu dosyalarında açıklanan beklentilerle tutarlılığını kontrol eder. Herhangi bir fark varsa, Flux, iş yüklerinin beklenen durumda çalışmasını sağlamak için EKS kümesinin farklılıkları senkronize etmesini otomatik olarak etkinleştirir.

GitOps kavramını ve CI/CD işlem hattı mimarisini açıkladığımızdan, bu alıştırmayı tamamlamak için aşağıdaki dört modülü inceleyen bir vaka kullanacağız:

  • Altyapı Kodunu (IaC) kullanarak bulut altyapısının dağıtımı
  • AWS EKS kümesinde Flux CD'yi dağıtın
  • Flux CD kullanarak GitOps iş akışlarını uygulayın
  • GitOps iş akışlarını kullanarak görüntülere dayalı otomatik dağıtım

1- IaC ile bulut altyapısının dağıtımı

DevOps'un temel ilkelerinden biri, altyapının koda eşit olduğudur. Kod Olarak Altyapı (IaC), bulut altyapısı dağıtımını ve bulut ortamı yönetimini etkinleştirmek için kod kullanır. Kodlama mühendisleri, altyapıyı tanımlamak ve tutarlılık ve tekrarlanabilirlik sağlamak için yapılandırma dosyalarını veya kodu kullanır. IaC ile kodlama mühendisleri, altyapı tanımlarını sürüm kontrol depolarında barındırmak ve IaC tanımını değiştirmek için programlamayla tutarlı sürekli entegrasyon/dağıtım (CI/CD) kullanmak, ortamları (örneğin geliştirme, test, üretim) IaC kod değişiklikleriyle koordine etmek gibi kaynak yaşam döngüsünü de yönetir. Ayrıca, bir arıza durumunda otomatik geri alma mümkündür ve sapma tespiti, beklenen durumdan sapmaları belirlemeye yardımcı olur.

Bulutta, yazılım mühendisleri altyapı modellerini Python, Java ve TypeScript ile oluşturmak için AWS Bulut Geliştirme Kiti'ni (CDK) kullanabilirler. CDK, bulut kaynaklarını geçerli varsayılan değerlerle önceden yapılandıran Yapılar adı verilen gelişmiş bileşenler sağlar. Ayrıca, mühendislerin kuruluşlarının ihtiyaçlarına uygun kendi özel yapılarını yazıp paylaşmalarına olanak tanır. Tüm bunlar projeleri hızlandırır.

1.1 CDK CLI ile bir proje oluşturun

TypeScript CDK projesi cdk başlatma TypeScript CDK projesinin ihtiyaç duyduğu klasör yapısını oluşturan ve modülleri yükleyen Create.

cdk init --language typescript

1.2 EKS Blueprints ile bir EKS kümesi oluşturun

EKS Blueprints, iş yüklerini dağıtmak ve çalıştırmak için gereken operasyonel yazılımlarla tamamen entegre edilmiş eksiksiz EKS kümeleri oluşturmanıza yardımcı olur. EKS Blueprints ile, kontrol paneli, çalışan düğümler ve Kubernetes eklentileri gibi EKS ortamınızın istenen durumu için yapılandırmayı bir IaC planı olarak tanımlarsınız. Bir planı yapılandırdıktan sonra, sürekli otomasyon kullanarak birden fazla AWS hesabı ve bölgesinde tutarlı ortamlar dağıtmak için kullanabilirsiniz.

Amazon EKS eklentilerinin yanı sıra Prometheus, Karpenter, Nginx, Traefik, AWS Load Balancer Controller, Fluent Bit, Keda, ArgoCD ve daha fazlası dahil olmak üzere çok çeşitli popüler açık kaynaklı eklentilerle bir EKS kümesini kolayca kurmak için EKS Blueprints'i kullanabilirsiniz. EKS Blueprints ayrıca, bir kümedeki birden fazla ekipten gelen iş yüklerini çalıştırmak için gereken ilgili güvenlik kontrollerini uygulamanıza da yardımcı olur.

Dizin Hızlı Başlangıç Proje bağımlılıklarını yüklemek için aşağıdaki kodları oluşturup çalıştırın.

mkdir quickstart
cd quickstart
npm install @aws-quickstart/eks-blueprints

lib/quickstart-stack.ts Açın ve kodu girin. EKS Planları Aşağıdakileri ekleyin.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as blueprints from '@aws-quickstart/eks-blueprints';
import { KubernetesVersion } from 'aws-cdk-lib/aws-eks';
export class QuickstartStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const account = props?.env?.account!;
const region = props?.env?.region!;
const clusterProvider = new blueprints.GenericClusterProvider({
version: KubernetesVersion.V1_23,
managedNodeGroups: [
{
id: "default-ng",
desiredSize: 2,
minSize: 1,
maxSize: 2,
}
]
});
const cluster = blueprints.EksBlueprint.builder()
.clusterProvider(clusterProvider)
.account(account)
.region(region)
.addOns(
new blueprints.AwsLoadBalancerControllerAddOn,
)
.teams();
}
}

Önceki adımda bir EKS kümesi oluşturduk, NodeGroup'unu tanımladık ve AwsLoadBalancerController eklentisini ekledik.


Bir yığını CDK komut satırı aracıyla dağıtmak kolay olsa da, EKS altyapınızı dağıtmak ve güncellemek için otomatik bir işlem hattı kurmanızı öneririz. Bu, bölgeler arasında geliştirme, test ve üretim dağıtımını kolaylaştırır.

CodePipelineStack, AWS CDK uygulamalarının sürekli dağıtımı için bir çerçevedir. Bir AWS CDK uygulamasının kaynak kodu Git'e yüklendiğinde, yığın otomatik olarak yeni sürümler oluşturur, test eder ve çalıştırır. Uygulamanın her aşaması veya yığını eklendiğinde, bu yeni aşamaları veya yığınları dağıtacak şekilde kendini otomatik olarak yeniden yapılandırır.

Daha sonra yığını dağıtmak için cdk deploy komutunu çalıştırıyoruz.

Son olarak, uygulama yük dengeleyicisinin başarıyla kurulduğunu doğrulamak için bir komut kullandık.

$ kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
aws-load-balancer-controller-6bd49cfb7-2cvlk 1/1 Running 0 5m31s
aws-load-balancer-controller-6bd49cfb7-7lcwd 1/1 Running 0 5m31s
aws-node-9hsvz 1/1 Running 0 99m
coredns-66cb55d4f4-gdcqg 1/1 Running 0 106m
coredns-66cb55d4f4-gmzjt 1/1 Running 0 106m
kube-proxy-wr5jn 1/1 Running 0 99m

1.3 Özet

Bu bölümde, IaC kavramını tanıttık ve AWS Application Load Balancer eklentisini yüklerken CDK ile özel bir EKS kümesi oluşturduk. Bu, gelecekte mikro hizmet web sayfalarına erişim için bir ön koşul sağlar. Aşağıda bu bölümün bir özeti bulunmaktadır:

  • cdk init kullanarak bir CDK projesi başlattım.
  • AWS Application Load Balancer eklentisini ekleyerek EKS Blueprint ile hızlı bir şekilde bir EKS kümesi tanımladım.

2. Fluxcd'yi Amazon EKS Kümesine Dağıtın

Flux CD, Weaveworks tarafından geliştirilen ve CNCF için açık kaynaklı bir sürekli dağıtım aracıdır. Kolay kurulumu ve Kubernetes değişikliklerini anlama yeteneği sayesinde günümüzde yaygın olarak kullanılmaktadır. Önemli özelliklerinden biri, ekiplerin Kubernetes dağıtımlarını bildirimsel bir şekilde yönetmelerine olanak sağlamasıdır. Flux CD, kaynak deposunda depolanan Kubernetes bildirim dosyalarını, depoyu düzenli olarak sorgulayarak Kubernetes kümesiyle senkronize eder. Flux CD, Kubernetes kümesinin kaynak deposunda tanımlanan yapılandırmayla her zaman senkronize olmasını sağlar; böylece Kubernetes CTL'nin operasyonel durumu veya ek araç ve hizmetlerle iş yüklerinin izlenmesi konusunda endişelenmenize gerek kalmaz. Öyleyse Flux'ı kuralım.

2.1 Flux CLI'yi Yükleme

Flux CLI, GitHub sürüm sayfasından indirebileceğiniz tüm platformlar için ikili bir çalıştırılabilir dosyadır.

curl -s https://fluxcd.io/install.sh | sudo bash

2.2 AWS CodeCommit kimlik bilgilerini hazırlayın

Bir kullanıcı oluşturmamız ve Git kaynağı olarak CodeCommit'i kullanmamız ve HTTPS Git kimlik bilgileri aracılığıyla AWS CodeCommit tarafından gereken erişimi sağlamamız gerekiyor.

2.3 Flux'ı Kümeye Kurun

Hazırlanan GitOps kodunu kopyalayın. Proje yapısı aşağıdaki gibidir:

.
├── apps // Define Application
│ ├── base // Application Infrastructure Layer
│ └── overlays // Application Overlays Layer
├── clusters // Cluster configuration portal
│ └── dev-cluster
├── infrastructure // Infrastructure Shared Components
│ ├── base // Infrastructure Infrastructure layer
│ └── overlays // Infrastructure Overlays layer
└── README.md

Kubernetes kümenize Flux'ı yükleyin ve Flux önyüklemesi ile bir Git deposundan yönetilecek şekilde yapılandırın. Kümede Flux bileşenleri mevcutsa, önyükleme komutu gerektiği gibi yükseltmeleri gerçekleştirir. Önyükleme etkisizdir ve komut güvenli bir şekilde birden çok kez çalıştırılabilir. Aşağıdaki komuttaki kullanıcı adı ve parolayı AWS CodeCommit için HTTPS Git kimlik bilgilerinizle değiştirin.

flux bootstrap git \ 
--url=https://git-codecommit.us-west-2.amazonaws.com/v1/repos/gitops \ 
--username=__replace_with_your_Git_credential_username__ \ 
--password=__replace_with_your_Git_credential_password__ \ 
--token-auth=true \ 
--path="./clusters/dev-cluster" \ 
--components-extra=image-reflector-controller,image-automation-controller

Önyükleyicinin yaptığı güncellemeleri kontrol etmek için git pull komutunu kullanın. Git deposunun clusters/dev-cluster/flux-system dizininde üç yeni dosya görünecektir:

  • gotk-components.yaml: Altı Flux denetleyicisini tanımlar: helm, Kustomize, kaynak, bildirim, görüntü otomasyonu ve görüntü yansıtıcı.
  • gotk-sync.yaml: Git Flux kaynak kodu, Kaynak Denetleyicisi'ndeki GitOps deposundaki küme izleme kodundaki değişiklikleri yapar ve ilgili değişiklikleri işler.
  • kustomization.yaml: Çoklu küme yapılandırması.

Flux'un başarıyla kurulup kurulmadığını flux get kustomizations --watch komutuyla kontrol edin. Çıktı şuna benzer:

$ flux get kustomizations --watch
NAME REVISION SUSPENDED READY MESSAGE 
flux-system master/83b7e66 False True Applied revision: master/83b7e66
infrastructure master/83b7e66 False True Applied revision: master/83b7e66

flux-system tarafından dağıtılan bileşenleri kubectl -n flux-system get pod,services komutuyla kontrol edin. Çıktı aşağıdaki gibi olacaktır:

$ kubectl -n flux-system get pod,services
NAME READY STATUS RESTARTS AGE
pod/helm-controller-88f6889c6-sblvd 1/1 Running 0 11m
pod/image-automation-controller-6c5f7bbbd9-8xskk 1/1 Running 0 11m
pod/image-reflector-controller-78949bb4b4-bqn4m 1/1 Running 0 11m
pod/kustomize-controller-784bd54978-s82dq 1/1 Running 0 11m
pod/notification-controller-648bbb9db7-627zs 1/1 Running 0 11m
pod/source-controller-79f7866bc7-gdt95 1/1 Running 0 11m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/notification-controller ClusterIP 172.20.60.72 <none> 80/TCP 11m
service/source-controller ClusterIP 172.20.133.44 <none> 80/TCP 11m
service/webhook-receiver ClusterIP 172.20.196.178 <none> 80/TCP 11m

2.4 Özet

Bu bölümde, Flux'ı bir Kubernetes kümesine kurmak için Flux önyükleme komutunu kullandık ve üç önemli yapılandırma dosyasını tanıttık: gotk-components.yaml, gotk-sync.yaml ve kustomization.yaml. Aşağıda bu bölümün bir özeti bulunmaktadır:

  • Flux istemcisinin kurulumu
  • Bir IAM kullanıcısı ve CodeCommit kimlik bilgileri oluşturma
  • Flux'u bir Amazon EKS kümesine yükleyin ve otomatik görüntü güncelleme özelliğini etkinleştirin

3. Flux CD ile GitOps iş akışlarını uygulayın

GitOps CI/CD işlem hatları için, yapılandırma değişiklikleri ve EKS kümelerindeki ve bunlar üzerinde çalışan iş yüklerindeki durum değişiklikleri, Git'teki kod değişiklikleri (git push veya çekme istekleriyle oluşturulur. GitOps çekme isteklerini önerir) tarafından yönlendirilir. Geleneksel CI/CD işlem hattı, CI motoruyla çalışır ve kümeyi dağıtmak için create/apply veya install/upgrade kubectl komutunu tetikler. Böylece GitOps, daha verimli ve özlü bir CI/CD işlem hattı oluşturur.

Belirli bir uygulama olan “Çorap Dükkanı”nı göstereceğiz ve GitOps CI/CD hattında sürekli entegrasyon ve teslimatın nasıl sağlanacağını gösteren pratik alıştırmalar yapacağız.

3.1 Çorap Mağazası Hakkında

Örnek olarak, çevrimiçi bir çorap mağazasının kullanıcıya yönelik kısmını kullanacağız. Spring Boot, Go Kit ve Node ile oluşturulmuş ve Docker kapsayıcılarında paketlenmiştir. "Mikroservis Standart Demosu"nda görüldüğü gibi:

  • Mikro hizmetlerin dağıtımına ilişkin en iyi uygulamalar (hata örnekleri dahil)
  • Platformlar arası dağıtım yetenekleri
  • Sürekli Entegrasyon/Dağıtımın Faydaları
  • DevOps ve mikro hizmetlerin tamamlayıcı doğası
  • Farklı orkestrasyon platformları için test edilebilir "gerçek" bir uygulama

Socks Store projesi, NodeJS ile oluşturulmuş bir web sayfasının ön yüzü olan 8 ön uç ve arka uç mikro servisinden oluşur. Projenin adı: front-end here. Ayrıca, http istekleri aracılığıyla sipariş, ödeme, kullanıcı yönetimi, ürün yönetimi ve alışveriş sepeti gibi çeşitli arka uç servislerine erişir. Arka uç servislerinin verileri MongoDB ve MySQL'de saklanır.

Referans mimarisi şu şekildedir:


3.2 Kustomize Hakkında

GitOps iş akışlarını kurmanın yanı sıra, Kubernetes'i nasıl yapılandıracağımızı da bilmemiz gerekir. Sistem ve ortam karmaşıklığı arttıkça, geleneksel kaynak envanteri (YAML) tabanlı yönetimi sürdürmek giderek zorlaşır. Karmaşık iş kullanım örnekleri, birden fazla ortam (geliştirme, test, ön sürüm, üretim) ve çok sayıda YAML kaynak envanterinin yönetilmesi ve sürdürülmesi gerekir. Helm, dağınık kaynak dosyalarının birleşik yönetimi, uygulama dağıtımı, yükseltme, geri alma vb. gibi bazı sorunları çözebilse de, ortamlar arasındaki küçük farklılıklarla başa çıkmayı daha zor hale getirir. Ayrıca, giriş için yüksek bir engel olan karmaşık DSL (Şablon Sözdizimi) sözdizimine hakim olmayı gerektirir. Böylece bildirimsel yapılandırma yönetim aracı Kustomize doğmuştur. Kustomize, ekiplerin farklı ortamlar ve ekipler arasında büyük miktarda YAML Kubernetes kaynağını yönetmesine yardımcı olur. Bu, ekiplerin ortamlardaki küçük farklılıkları kolay bir şekilde yönetmelerine, kaynak yapılandırmalarını yeniden kullanılabilir hale getirmelerine, kopyalama ve değişiklik çabalarını azaltmalarına ve yapılandırma hatalarını büyük ölçüde azaltmalarına yardımcı olur. Tüm uygulama yapılandırma süreci şablon sözdiziminin ek olarak öğrenilmesini gerektirmez.

Kustomize yukarıdaki sorunları şu şekilde çözer:
  • Kustomize, Base & Overlays aracılığıyla farklı ortamlarda uygulama yapılandırmasını korur.
  • Kustomize, temel yapılandırmayı ve uygulamayı yeniden kullanmak için Patch'i kullanır ve kaynak yeniden kullanımı, Overlay açıklaması ile temel uygulama yapılandırması arasındaki fark bölümü aracılığıyla sağlanır.
  • Kustomize, DSL sözdizimini öğrenmeye gerek kalmadan yerel Kubernetes YAML dosyalarını yönetir.

Resmi web sitesine göre Kustomize, kullanıcıların şablon kullanmadan uygulama ayarlarını özelleştirmelerine olanak tanıyan, Kubernetes için yerel bir yapılandırma yönetim aracı haline geldi. Kustomize, kaynak yapılandırmaları (YAML) oluşturmaya ve yeniden kullanmaya yardımcı olmak için yerel K8s kavramlarını kullanarak kullanıcıların bir uygulama açıklama dosyasını (YAML) temel olarak kullanmalarına (Base YAML) ve ardından Kaplamalar aracılığıyla nihai dağıtılan uygulama için gerekli açıklama dosyasını oluşturmalarına olanak tanır.


3.3 Çoklu küme yapılandırması

Kustomize yapılandırma yönetim aracını anlayarak, çok kümeli dağıtım dönüşümünü etkinleştirmek için Kustomization'ı (taban, katmanlar) kullanıyoruz.

Mikroservis projesinde iki dizin oluşturduk: tam kaynak yapılandırma dosyalarını (YAML) depolamak için temel dizin ve farklı ortamları veya farklı küme yapılandırmalarını depolamak için üst dizin.

Örneğin bu durumda mikroservis için tam yapılandırma dosyası full-demo.yaml'dir ve bunu ana klasöre kopyalarız.

cp deploy/kubernetes/complete-demo.yaml deploy/kubernetes/base/complete-demo.yaml

Daha sonra kustomization.yaml aracılığıyla dosyaya başvuruyoruz:

# deploy/kubernetes/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./complete-demo.yaml

Geliştirme ortamı için, servis portlarının ve kopyalarının sayısını değiştirmek gibi farklı gereksinimler varsa, mevcut full-demo.yaml dosyasını kopyalayıp değiştirmeden, overlays/development/kustomization.yaml dosyasındaki farklı ayarları yapılandırmanız yeterlidir.

3.4 GitOps İş Akışı ile Mikro Hizmetleri Dağıtma

Mikroservisler için çoklu küme desteği tamamlandıktan sonra Flux'un mikroservis yapılandırmasının değiştiğini bilmesi gerekiyor, bu nedenle mikroservis deposunun (microservices-repo) CodeCommit URL'sini Flux deposuna (flux-repo) kaydediyoruz.

3.4.1 Mikro Hizmetler Deposu Adresinin Eklenmesi

Uygulama katmanı/uygulamalar klasörü altındaki Flux deposuna geri dönüyoruz:

.
├── base
│ ├── kustomization.yaml
│ └── sock-shop
│ ├── kustomization.yaml
│ ├── namespace.yaml
│ ├── rbac.yaml
│ └── tenant.yaml
└── overlays
└── development
├── kustomization.yaml
└── sock-shop
└── kustomization.yaml

apps/base/sock-shop/ dizinindeki tenant.yaml dosyasını açın ve MICRO_SERVICES_REPO'yu mikroservis URL'siyle değiştirin: https://git-codecommit.xxx.amazonaws.com/v1/repos/microservices-repo.

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
name: sock-shop-tenant
namespace: sock-shop
spec:
interval: 1m
url: __MICRO_SERVICES_REPO__
ref:
branch: main
secretRef:
name: microservices-basic-access-auth
......

3.4.2 CodeCommit Kimlik Bilgilerinin Eklenmesi

"AWS CodeCommit kimlik bilgilerini hazırla" hesabı ve parolasını bulun. Komutu çalıştırmadan önce veri değerini base64 kodlamasına dönüştürün.

Daha sonra base/sock-shop/basic-access-auth.yaml dosyasını açın ve BASE64_USERNAME ve BASE64_PASSWORD değerlerini oluşturulan base64 kodlamasıyla değiştirin:

---
apiVersion: v1
kind: Secret
metadata:
name: microservices-basic-access-auth
namespace: sock-shop
type: Opaque
data:
username: __BASE64_USERNAME__
password: __BASE64_PASSWORD__

3.4.3 Dağıtım

Flux, mikro servis Git URL'sini Flux yapılandırma deposuna ekleyerek yapılandırma değişikliklerini otomatik olarak tarar. Kod işlendikten sonra, Flux kümeye dağıtılmış herhangi bir mikro servis olup olmadığını ve Git deposu tanımıyla eşleşip eşleşmediğini kontrol eder; aksi takdirde, Flux mikro servisleri otomatik olarak kümeye dağıtır.

Kodu çalıştırdıktan sonra flux get kustomizations -watch komutunu çalıştırın ve Flux'ın güncellenmesini bekleyin. Tüm özelleştirmelerin HAZIR durumu True olduğunda dağıtım tamamlanmış olur.

Aşağıda gösterilen çorap mağazası ad alanında pod'ları ve hizmetleri arayın:

$ kubectl get pod,service -n sock-shop
NAME READY STATUS RESTARTS AGE
pod/carts-b4d4ffb5c-z4jrj 1/1 Running 0 5m28s
pod/carts-db-6c6c68b747-jl5pd 1/1 Running 0 5m28s
pod/catalogue-759cc6b86-qdmvc 1/1 Running 0 5m28s
pod/catalogue-db-96f6f6b4c-zgp5z 1/1 Running 0 5m28s
pod/front-end-5c89db9f57-cvbdl 1/1 Running 0 5m28s
pod/orders-7664c64d75-lqwbm 1/1 Running 0 5m28s
pod/orders-db-659949975f-qv7pl 1/1 Running 0 5m28s
pod/payment-7bcdbf45c9-szrfq 1/1 Running 0 5m28s
pod/queue-master-5f6d6d4796-nkktx 1/1 Running 0 5m28s
pod/rabbitmq-5bcbb547d7-gzhn4 2/2 Running 0 5m28s
pod/session-db-7cf97f8d4f-9mz6v 1/1 Running 0 5m28s
pod/shipping-7f7999ffb7-95rlc 1/1 Running 0 5m27s
pod/user-68df64db9c-kh247 1/1 Running 0 5m27s
pod/user-db-6df7444fc-jlkp9 1/1 Running 0 5m27s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/carts ClusterIP 172.20.33.124 <none> 80/TCP 5m29s
service/carts-db ClusterIP 172.20.75.163 <none> 27017/TCP 5m29s
service/catalogue ClusterIP 172.20.92.254 <none> 80/TCP 5m29s
service/catalogue-db ClusterIP 172.20.242.255 <none> 3306/TCP 5m29s
service/front-end LoadBalancer 172.20.55.188 k8s-sockshop-frontend-12345678910-012345678910abc.elb.us-east-1.amazonaws.com 80:30001/TCP 5m29s
service/orders ClusterIP 172.20.8.252 <none> 80/TCP 5m29s
service/orders-db ClusterIP 172.20.40.212 <none> 27017/TCP 5m29s
service/payment ClusterIP 172.20.6.218 <none> 80/TCP 5m29s
service/queue-master ClusterIP 172.20.153.80 <none> 80/TCP 5m29s
service/rabbitmq ClusterIP 172.20.99.37 <none> 5672/TCP,9090/TCP 5m29s
service/session-db ClusterIP 172.20.37.111 <none> 6379/TCP 5m29s
service/shipping ClusterIP 172.20.43.252 <none> 80/TCP 5m29s
service/user ClusterIP 172.20.220.174 <none> 80/TCP 5m29s
service/user-db ClusterIP 172.20.70.57 <none> 27017/TCP 5m29s

AWS Yük Dengeleyici DNS adına erişin.


3.5 Özet

Bu bölümde, bir mikro servis iş uygulaması olan Sock Shop online mağazasını tanıttık ve çok kümeli yapılandırmasını tamamladık. Ayrıca, hedef kümeyi yapılandırma dosyalarındaki değişikliklerle otomatik olarak senkronize ederek mikro servisin EKS kümesine dağıtımını tamamlayan Flux tabanlı standart bir GitOps iş akışı oluşturduk. Bu arada, pratik bir yapılandırma yönetim aracı olan K8s-Kustomize'ı tanıttık ve uygulama kaynak dosyalarının nasıl yönetileceğini anlattık. Bu bölümün özeti aşağıdadır:

  • Çorap mağazasını tanıtıyoruz
  • Bir yapılandırma yönetim aracı olan Kustomize'ı (temel, katmanlar) ve çok kümeli mikro hizmet dağıtımlarını nasıl değiştireceğinizi öğrenin.
  • Bir GitOps iş akışı oluşturun ve mikro hizmetleri dağıtın

4. GitOps iş akışlarıyla otomatik görüntü tabanlı dağıtım

Kod değişikliklerinin, imaj oluşturmanın ve GitOps iş akışıyla özel sürümün ayrıntılı sürecini göstermek için örnek olarak Sock Shop ön uç mikro servisini seçtik.

4.1 CodePipeline CI'nin Tanımı

Ön uç, Docker görüntü paketlemesini desteklemek için saf bir Node.js ön uç hizmetidir (ayrıntılar için Bölüm 3.1'deki Sock Shop Architect'e bakın). CodePipeline'da yürütülen CI sürecini tanımlamak için ön uç proje kaynak koduna bir buildspec.yml dosyası ekleyin:

version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws --version
- AWS_ACCOUNT_ID=`echo $REPOSITORY_URI|cut -d"." -f1`
- AWS_DEFAULT_REGION=`echo $REPOSITORY_URI|cut -d"." -f4`
- echo $AWS_ACCOUNT_ID $AWS_DEFAULT_REGION
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $REPOSITORY_HOST
- COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
- IMAGE_TAG=main-$COMMIT_HASH-$CODEBUILD_BUILD_NUMBER
- echo $IMAGE_TAG
build:
commands:
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $REPOSITORY_URI:latest .
- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker images...
- docker push $REPOSITORY_URI:latest
- docker push $REPOSITORY_URI:$IMAGE_TAG

Bu CI süreci, ön uç kodu değiştiğinde otomatik olarak bir görüntü oluşturur ve bunu ECR weaveworksdemos/front-end deposuna yükler. Görüntü etiketi biçimi [dal]-[işlem]-[yapı numarası] şeklindedir.

4.2 Otomatik görüntü güncellemesi

Sürekli entegrasyona sahip çevik bir ortamda çalışırken, örneğin geliştirmeyi test ederken, GitOps deponuzu güncellemek veya yeni servis imajlarını yönetmek için betikler kullanmak gerçekten can sıkıcı olabilir. Neyse ki Flux, bu işi sizin için halleden harika bir otomatik imaj güncelleme özelliğine sahip. Kullanmak için tek yapmanız gereken, yapılandırmanızda imaj güncelleme bileşenini etkinleştirmek. Henüz yapmadıysanız endişelenmeyin, etkinleştirmek için Flux önyüklemesinde yineleme yaparken –components-extra=image-reflector-controller,image-automation-controller parametrelerini eklemeniz yeterli.

Görüntü tabanlı otomatik güncellemeleri gerçekleştirmek için aşağıdaki adımları gerçekleştirmemiz gerekiyor:

  • Flux'un ön uç projesinde ECR görüntü deposu muhabirini periyodik olarak taramasına olanak sağlamak için ön uç mikro servis görüntü deposunu kaydedin.
  • Görüntü deposuna erişmek için kimlik bilgilerini yapılandırın. Flux, görüntü bilgilerini okumak için ECR görüntü deposuna erişmek üzere kimlik bilgilerine ihtiyaç duyar.
  • Görüntü güncelleme politikasını ayarlayın. Çoğu durumda, görüntü sürümlerindeki tüm değişikliklerin her seferinde CD'yi tetiklemesini istemeyiz. Bunun yerine, yalnızca belirtilen dal (kök) kodunun CD'yi tetiklemesini isteriz. Bu gereksinimi karşılamak için özel bir güncelleme politikasına ihtiyaç vardır.

Daha sonra yukarıdaki işlemleri teker teker tamamlayalım.

4.2.1 Git deposunun ön yüzüne bir görüntü politikası ekleme

Microservices-repo projesinde, mikroservis ön ucunu özelleştirilmiş ve güncellenmiş bir sürümle değiştirmek için DEV ortamında Kustomization katmanlarını kullanacağız. deploy/kubernetes/overlays/development/kustomization.yaml dosyasını değiştirin. (Not: ACCOUNT_ID değerini kendi ACCOUNT_ID değeriniz ile değiştirin).

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
images:
- name: weaveworksdemos/front-end
newName: __ACCOUNT_ID__.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end # {"$imagepolicy": "sock-shop:sock-shop-front-end:name"}
newTag: latest # {"$imagepolicy": "sock-shop:sock-shop-front-end:tag"}

4.2.2 Flux-repo Altında Bir Mikroservisin Ön Ucunu Kaydetme

flux-repo projesinde yeni bir apps/overlays/development/sock-shop/registry.yaml dosyası oluşturun ve ACCOUNT_ID'yi kendi ACCOUNT_ID'nizle değiştirin.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
name: sock-shop-front-end
namespace: sock-shop
spec:
image: __ACCOUNT_ID__.dkr.ecr.xxxx.amazonaws.com/weaveworksdemos/front-end
interval: 1m0s

4.2.3 Amazon ECR için Erişim Kimlik Bilgilerini Yapılandırma

Flux'ta Amazon ECR kimlik bilgileri için iki yöntem vardır.

  • Otomatik kimlik doğrulama mekanizması (Görüntü Yansıtıcı Denetleyicisi kimlik bilgilerini kendi başına alır, yalnızca şunlar için: Amazon ECR, GCP GCR, Azure ACR)
  • CronJob ile kimlik bilgilerini (Secret aracılığıyla kümede depolanan) düzenli olarak alın
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- gotk-components.yaml
- gotk-sync.yaml
patches:
- patch: |-
- op: add
path: /spec/template/spec/containers/0/args/-
value: --aws-autologin-for-ecr
target:
version: v1
group: apps
kind: Deployment
name: image-reflector-controller
namespace: flux-system

4.2.4 Görüntü güncelleme politikasının ayarlanması

gitops/apps/overlays/development/sock-shop/policy.yaml dosyasını ekleyin. Aşağıdaki kurallar, master-d480788-1, master-d480788-2 ve master-d480788-3 gibi görüntü sürümlerine karşılık gelir.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
name: sock-shop-front-end
spec:
imageRepositoryRef:
name: sock-shop-front-end
filterTags:
pattern: '^main-[a-fA-F0-9]+-(?P<buidnumber>.*)'
extract: '$buidnumber'
policy:
numerical:
order: asc

gitops/apps/overlays/development/sock-shop/image-automation.yaml dosyasını ekleyin. Flux Image Automation, uygulama yapılandırması için bir Git deposu belirtir; buna dal, yol ve diğer bilgiler dahildir.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
name: sock-shop-front-end
spec:
git:
checkout:
ref:
branch: main
commit:
author:
email: [email protected]
name: fluxcdbot
messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}'
push:
branch: main
interval: 5m0s
sourceRef:
kind: GitRepository
name: sock-shop-tenant
namespace: sock-shop
update:
path: ./deploy/kubernetes/overlays/development
strategy: Setters

4.3 Yayınlama ve onay

Otomatik görüntü güncelleme sürecinin tamamını ön uç kaynak kodunu değiştirerek doğruluyoruz.

4.3.1 Ön uç kodunu güncelleyin

Ön uç altbilgisini değiştirin ve şu dosyayı düzenleyin: front-end/public/footer.html.


4.3.2 CodePipeline'ı Kontrol Edin

Ön uçtaki kod değişiklikleri otomatik olarak CodePipeline yürütülmesini tetikler.


4.3.3 ECR görüntü sürümü değişikliğinin onaylanması

CodePipeline tamamlandıktan sonra, weaveworksdemos/front-end görüntü sürümünü kontrol etmek için Amazon ECR konsoluna giriş yapın:


4.3.4 Akı görüntü bilgilerinin kontrol edilmesi

Flux CLI aracılığıyla ImageRepository ve ImagePolicy'nin en son sürümü başarıyla alıp almadığını kontrol edin.

$ flux get images all --all-namespaces
NAMESPACE NAME LAST SCAN SUSPENDED READY MESSAGE 
sock-shop imagerepository/sock-shop-front-end 2022-09-18T14:46:45Z False True successful scan, found 20 tags
NAMESPACE NAME LATEST IMAGE READYMESSAGE 
sock-shop imagepolicy/sock-shop-front-end 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24 True Latest image tag for '267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end' resolved to: master-1f49071-24
NAMESPACE NAME LAST RUN SUSPENDED READY MESSAGE 
sock-shop imageupdateautomation/sock-shop-front-end 2022-09-18T14:43:51Z False True no updates made; last commit 1ff6d91 at 2022-09-18T14:34:40Z

4.3.5 Mikroservis kaynak kodu otomatik olarak güncellenir

Flux, ön uç görüntü sürümünü otomatik olarak güncelledi. Son commit fluxcdbot tarafından yapıldı ve görüntü etiketi başarıyla en son sürüme değiştirildi: master-1f49071-24.


4.3.6 Pod Görüntü Sürümünün Doğrulanması

Pod adını kubectl get pod -n sock-shop | grep front-end komutuyla doğrulayın. Pod ayrıntılarını kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep komutuyla kontrol edin. Görüntü: Görüntü sürüm güncellemesini doğrulamak için. Aşağıdaki gibi görünecektir:

$ kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image:
Image: 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24

4.3.7 Statik sayfanın güncel olduğunu doğrulayın


4.4 Özet

Bu bölümde, imajlara dayalı tüm otomatik dağıtım sürecini ayrıntılı olarak açıkladık. Kısacası, Flux'ın imaj depoları için sürekli izleme özelliğini kullanıyoruz. İmaj sürümünde bir değişiklik tespit edildiğinde, Git deposundaki imaj yapılandırmasını otomatik olarak değiştirir ve önceki bölümdeki standart GitOps iş akışına bağlanarak otomatik dağıtımı tamamlar. Bu bölümü özetlemek gerekirse:

  • Ön uç kodunun sürekli entegrasyonunu sağlamak için CI sürecini CodePipeline üzerinden çalıştırın.
  • Flux açıklamalarıyla iş yapılandırma dosyasını bulun ve değiştirin.
  • Flux'un belirli görüntü sürümlerini izlemesini ve dağıtımı tamamen otomatikleştirmesini sağlamak için Flux görüntü güncelleme politikasını yapılandırın.

Sonuç

Bu makale, buluttaki bir Amazon EKS kümesine mikro hizmetlerin dağıtımını otomatikleştirmek için FluxCD'nin nasıl kullanılacağına ve GitOps işlem hatları için en iyi uygulamalara odaklanmaktadır. GitOps, bir dizi en iyi uygulamayı kapsayan sürekli bir dağıtım metodolojisidir. GitOps temellerine bağlı kaldıkları sürece, CI/CD araçları oluşturmanın kesin sınırları yoktur.

Bu makalede:
,
Gönderiyi yazan:
Takip etmek
Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Önceki Makale
Sonraki Makale
Ayrıca Şunları da Beğenebilirsiniz