GitLab CI/CD && Kubernetes Üzerine Uygulamaları
Merhabalar bugün Gitlab üzerinde CI/CD süreçlerini bir pipeline mekanizması ile nasıl otomatize edilmiş bir biçimde development yapabiliceğimiz hakkında konuşacağız.
Öncelikler CI/CD süreçlerinden bahsedecek olursak ;
Continuous Integration(Sürekli Entegrasyon) ve Continuous Delivery (Sürekli Teslimat) geliştirilen yazılımımızın bazı süreçlerden geçmesi anlamına gelmektedir. Yani geliştirilen yazılımın derlenmesi, test aşamaları, versiyonlanması, deploy edilmesi gibi süreçlerden geçerek tıpkı bir yaşam döngüsünü tamamlanması ve bunun sürekliliği ile ilgilidir.
Pipeline ?
Pipeline ile devam edelim. Pipeline geliştirdiğimiz yazılımın bu döngüden daha hatasız daha kolay ve otomatize edilmiş bir şekilde geçmesi için uygulanan bir yöntem diye nitelendirebiliriz. Bir tuşa basarak bu döngüyü sağlayabiliriz.
GitLab Pipeline ?
Bahsettiğimiz pipeline yönteminin birçok sağlayıcısı olduğu gibi GitLab da versiyon kontrol sistemi olmasının yanında bu hizmetide kullanıcılarına sunmaktadır.
GitLab Pipeline CI/CD süreçlerini gitlab-runner adı verilen bir araçla sağlamaktadır. GitLab Runner kendi localinizde, herhangi fiziksel server vaya cloud üzerinde ve bir kubernetes cluster üzerinde bu hizmeti kullanabilirsiniz. Ayrıca Gitlab kendiside shared runnerlar kullanmanıza olanak sağlamaktadır.Gitlabın CI/CD yönetimi ile yazımıza devam edip ilk olarak Gitlab Runnerların çalışma şekli ve akabinde pipeline döngüsünden bahsedeceğiz.
GitLab Runner ?
GitLab runner gitlab üzerinde pipeline yönetebilmek için kullanılması gerekli bir araçtır. GitLab ile iletişimi GitLab API üzerinden yapar ve böylece pipeline üzerinde yapılacak bütün işlemleri runnerlara iletmiş oluyor.
Gelen commit runnerlar ve gitlabın iletişimi ile çeşitli süreçlere göre bir pipeline gerçekleştirmemize olanak sağlar.
Runnerlarımız ayakta şimdi bir pipeline yaratmalıyız;
Gitlab üzerinde pipeline oluşturmak için yaml formatında bir dosya oluşturmalıyız.Bu dosya gitlab pipeline ayarlarında .gitlab-ci.yml olarak tanımlıdır ve isteğe göre değiştirilebilir.Bu dosyada runnerın pipelinemızı hangi işletim sisteminde çalıştıracağı ve pipelinemızı çeşitli ortamlara (staging, dev, test, prod vb.) bölebiliriz.
DEMO
Teknik anlamdaki bilgimizi edindik şimdi bir örnek yapalım ve daha iyi anlayalım 😉 👇
Öncelikle bir runnera ihtiyacımız var. Bu örnek için runnerları kubernetes üzerinde host edeceğiz.
Yukarıda gitlab, kubernetes üzerindeki service tokenlarını kullanarak kubernetes cluster ile arasında bir kimlik doğrulama sağlamış olur. Bu doğrulamadan sonra clusterımızı gitlab üzerinde operations/kubernetes sekmesi altına var olan clusterımız eklemeliyiz
Clusterımızı eklememiz için gerekli olan bilgilerimizi;
- CLUSTER NAME;
kubectl cluster-info
- API URL; (kubernetes API’ye erişmek için gereken url)
kubectl cluster-info | grep ‘Kubernetes master’ | awk ‘/http/ {print $NF}’
- CA Certificate; (kubernetes clustera erişmek için gereken kubernetes certificate)
kubectl get secret <default-secret-name> -o jsonpath=”{[‘data’][‘ca\.crt’]}” | base64 — decode
- Service Token;(gitlab admin service account token)
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab-admin | awk ‘{print $1}’)
gerekli yerleri cluster üzerinde bu komutları çalıştırarak karşılıklarını bulabilirsiniz.
Clusterımızı ekledikten sonra helm charts üzerinden gitlab-runnerı clusterımıza kurabiliriz.
helm chartda values.yaml üzerinde registration token ve gitlab url parametrelerini girerek aşağıdaki komutu çalıştırabiliriz.
helm install — namespace “gitlab-runner” — name “gitlab-runner” -f values.yml gitlab/gitlab-runner
Gitlab runner podumuz running durumada iken uygulamamız için kuracağımız pipelinedaki bütün joblar bu gitlab-runner podu üzerinde çalışacaktır.
Şimdi bir python uygulamasının CI/CD süreçlerini gösteren bir örnek yapacağız. Developerlarımız uygulamamızı çalışır hala getirdi ve bundan sonraki süreç içerisinde kolay ve hatasız deploylar için sıra bize geldi.
İlk olarak gitlab üzerinde bir pipeline koşulabilmesi için ihtiyacımız olan .gitlab-ci.yml dosyası , bu dosyada pipeline stageler, joblar ve pipeline için çeşitli kuralları burada belirtebiliriz.
image: kloiadocker/docker-compose:v1 services:
- docker:dind stages:
- prepare
- install
- push
- deploy before_script:
- export DOCKER_HOST=127.0.0.1:2375
- apk add --no-cache make bash
- mkdir -p ~/.aws /root/.aws
- echo -e "[<profile-name>]\nregion=eu-central-1" > ~/.aws/credentials
- export COMMIT_TIME=$(git show -s --format=%ct $CI_COMMIT_SHA)
- eval $(aws ecr get-login --profile=<profile-name> --no-include-email)
- export CI_REGISTRY_IMAGE="<account-id>.dkr.ecr.eu-central-1.amazonaws.com/deneme"
prepare:
stage: prepare
script:
- docker-compose stop
- docker-compose rm -v
tags:
- run
install:
stage: install
script:
- docker build -t deneme .
- docker tag deneme <account-id>.dkr.ecr.eu-central-1.amazonaws.com/deneme:<tag>
tags:
- run
push:
stage: push
script:
- docker push <account-id>.dkr.ecr.eu-central-1.amazonaws.com/deneme:<tag>
allow_failure: true
tags:
- run
deploy:
stage: deploy
script:
- docker-compose up only:
- master tags:
- run when: manual tags:
- run
push:
stage: push
script:
- docker push <account-id>.dkr.ecr.eu-central-1.amazonaws.com/deneme:<tag>
tags:
- run
deploy:
stage: deploy
script:
- docker-compose up only:
- master tags:
- run when: manual
Yukarıdaki .gitlab-ci.yaml üzerinde bir docker compose ile python app deploy edeceğiz. Bu pipeline üzerinde dind(docker in docker) mantığı ile kloiadocker/docker-compose imajı üzerinde kendi uygulamamızı deploy edeceğiz. Burada gerçekleştireceğimiz pipeline 4 aşamadan(stages) oluşuyor;
- Prepare
- Install
- Push
- Deploy
Pipeline üzerinde gerçekleştireceğimiz aşamalar hakkında biraz konuşalım. Öncelelikle before_script tüm aşamalar için gerekli olacak bağımlılıkların tanımlandığı kısımdır. Prepare aşaması ile var olan composeları durdurup siliyoruz. Bunu daha sonra yapacağımız deployment tarafında herhangi bir çakışma locklanma yaşamamak için yapıyoruz. Install aşamasında build ve imajın taglanması işlemlerini gerçekleştiriyoruz. Push ve Deploy işlemlerinde imajın before_script tarafında login olunan repoya pushluyoruz ve daha sonra deployment işlemini gerçekleştiriyoruz.
GitLab sunduğu arayüzde bize pipelineları takip edebileceğimiz bir ortam sunmaktadır.Ayrıntı olarak .gitlab-ci.yaml 'da verdiğimiz allow_failure parametresi ile Push aşamasının başarısız olması halinde bile pipelinenın sürdürülebilir olmasını sağlamaktadır. Deploy aşamasında verdiğimiz when:manual parametresi ile deployment’ın manual olarak yapılmasını sağlamaktadır. Pipeline tarafında daha bir çok parametrelerle çeşitli işler yapabiliriz.
SONUÇ
Sonuç olarak var olan uygulamalarımız bir çok aşamadan geçmektedir ve bu aşamaların insan gücü ile manual bir şekilde yapılması bir çok hatalar ve paralel olarak çözümleri için harcanan vakiteleride beraberinde getirmektedir. Bu sebeple bu tür aşamaların otomatize edilmiş bir şekilde gerçekleştirilmesi hataların azalmasından ve zamandan ciddi oranda iyileşme sağlamaktadır. Son olarak artık gitlab üzerinde bulunan uygulamamızın CI/CD süreçlerini atılan her comitte tetiklenecek ve otomatize edilecek şekilde yönetebilmekteyiz.
