GitLab CI/CD Pipeline Kurulumu ve En İyi Uygulamalar: Üretim Ortamında Kesintisiz Entegrasyon

 · 

GitLab CI/CD Pipeline Kurulumu ve En İyi Uygulamalar: Üretim Ortamında Kesintisiz Entegrasyon

GitLab CI/CD Pipeline Kurulumu ve En İyi Uygulamalar: Üretim Ortamında Kesintisiz Entegrasyon

Yazılım teslim süreçlerini hızlandırmak ve tekrarlanabilirliği sağlamak, modern DevOps pratiklerinin temelini oluşturur. GitLab CI/CD, bu hedeflere ulaşmak için güçlü ve entegre bir çözüm sunar. Bir AWS Cloud Architect olarak, karmaşık üretim ortamlarında sürdürülebilir ve güvenli pipeline'lar inşa etmenin kritik adımlarını ve en iyi uygulamalarını ele alacağım.

GitLab CI/CD Temelleri: .gitlab-ci.yml ile Pipeline Yapılandırması

GitLab CI/CD'nin kalbinde, projenizin kök dizininde yer alan .gitlab-ci.yml dosyası bulunur. Bu YAML dosyası, pipeline'ınızın aşamalarını (stages), işlerini (jobs) ve bağımlılıklarını tanımlar. Her iş, belirli bir aşamada çalışır ve bir veya daha fazla komut kümesini yürütür. İşte basit bir yapılandırma örneği:

stages: "build", "test", "deploy"variables:DOCKER_IMAGE: "my-app"build_job:stage: buildscript:- echo "Building the application..."- docker build -t $DOCKER_IMAGE:latest .artifacts:paths:- build/output/binaries/expire_in: 1 weektest_job:stage: testscript:- echo "Running unit tests..."- npm testonly:- masterdeploy_to_staging:stage: deployscript:- echo "Deploying to staging environment..."- aws s3 sync ./build/output/ s3://my-staging-bucket/only:- master

Yukarıdaki örnekte, build, test ve deploy olmak üzere üç aşama tanımlanmıştır. build_job, Docker imajı oluşturur ve derlenmiş çıktıları sonraki aşamalara aktarmak üzere artifact olarak saklar. test_job, birim testlerini çalıştırır. deploy_to_staging ise yalnızca master branch'ine yapılan push'larda tetiklenerek uygulamayı bir AWS S3 bucket'ına dağıtır. artifacts anahtar kelimesi, bir işin çıktılarının sonraki işler tarafından kullanılmasını sağlar; bu, özellikle derleme ve dağıtım işlerinde kritik öneme sahiptir.

Gelişmiş Pipeline Yapıları: Dinamik Child Pipelines ve Matrix Stratejileri

Büyük projelerde veya monorepo yapılarında tek bir .gitlab-ci.yml dosyası yönetilemez hale gelebilir. Bu senaryolarda Dynamic Child Pipelines ve Matrix Jobs devreye girer. Dynamic Child Pipelines, ana pipeline içinde başka bir .gitlab-ci.yml dosyası oluşturup çalıştırarak pipeline'ı dinamik olarak genişletmenizi sağlar. Bu, mikroservis tabanlı mimarilerde her servisin kendi pipeline'ını tetiklemesi için idealdir.

generate_child_pipeline:stage: buildscript:- ./scripts/generate_pipeline.sh > generated-ci.ymlartifacts:paths:- generated-ci.ymltrigger:include:- artifact: generated-ci.ymlparent_pipeline_job:job: generate_child_pipeline

Burada generate_child_pipeline işi, bir betik çalıştırarak dinamik bir generated-ci.yml dosyası üretir ve bu dosyayı bir child pipeline olarak tetikler. Bu yaklaşım, sadece değişen bileşenler için pipeline çalıştırma veya farklı konfigürasyonlarla testler yürütme esnekliği sunar. Matrix Jobs ise, belirli değişken kombinasyonları için aynı işi birden fazla kez çalıştırmanızı sağlar, örneğin farklı işletim sistemleri ve Python versiyonları üzerinde test yapmak gibi.

Üretim Ortamı Entegrasyonu ve Güvenlik: AWS ile GitLab CI/CD

Üretim ortamına dağıtım yaparken güvenlik ve yetkilendirme hayati öneme sahiptir. GitLab CI/CD'nin AWS ile güvenli entegrasyonu için OpenID Connect (OIDC) ve IAM Rolleri kullanımı en iyi pratiktir. GitLab, OIDC Identity Provider olarak davranarak AWS'ye geçici kimlik bilgileri sağlamak için kullanılabilir.

# .gitlab-ci.yml içinde bir AWS CLI komutu örneğiAWSCredentials:stage: deployid_tokens:AWS_ID_TOKEN:script:- export $(printf "AWS_ACCESS_KEY_ID=%s
AWS_SECRET_ACCESS_KEY=%s
AWS_SESSION_TOKEN=%s" \$(aws sts assume-role-with-web-identity \--role-arn "arn:aws:iam::123456789012:role/GitLabCI-DeploymentRole" \--role-session-name "GitLabCISession" \--web-identity-token $AWS_ID_TOKEN \--duration-seconds 900 \--query "Credentials.[AccessKeyId,SecretAccessKey,SessionToken]" \--output text))"- aws s3 sync ./dist s3://production-bucket/"

Bu yapılandırma, GitLab runner'ının AWS IAM'de tanımlanmış bir rolü üstlenmesine olanak tanır. IAM rolü, sts:AssumeRoleWithWebIdentity eylemine izin veren bir güven ilişkisine sahip olmalıdır. Bu, sabit AWS kimlik bilgilerini GitLab'de saklama ihtiyacını ortadan kaldırır ve en az ayrıcalık (least privilege) prensibini uygulamayı kolaylaştırır. Her iş için özel, kısa ömürlü kimlik bilgileri kullanılır.

Gerçek Senaryo: Çok Katmanlı Uygulama Dağıtımı ve Mimarisi

Bir e-ticaret uygulamasını düşünelim: bir React frontend, bir Node.js backend API'si ve PostgreSQL veritabanı. Bu uygulamanın AWS ECS üzerinde Docker kapsayıcıları olarak dağıtılması hedefleniyor. Pipeline şu adımları içerebilir:

  1. Frontend (React): Kod derleme, test etme, Docker imajı oluşturma, AWS ECR'ye gönderme, S3'ye statik dosyaları yükleme (CDN arkasına).
  2. Backend (Node.js): Bağımlılıkları kurma, test etme, Docker imajı oluşturma, AWS ECR'ye gönderme.
  3. Veritabanı Migrasyonları: Backend deploy'undan önce veritabanı şema değişikliklerini güvenli bir şekilde uygulama.
  4. ECS Servis Güncelleme: Hem frontend hem de backend için yeni Docker imajları ile ECS servislerini güncelleme.

Bu senaryoda, bağımlılıkların yönetimi kritik önem taşır. Örneğin, backend yeni bir veritabanı şemasına ihtiyaç duyuyorsa, migrasyon işi backend deploy'undan önce tamamlanmalıdır. Rollback stratejileri de benzer şekilde planlanmalıdır; bir dağıtım başarısız olursa, önceki çalışan versiyona hızlıca geri dönülebilmelidir. GitLab'in dependencies ve needs anahtar kelimeleri bu tür bağımlılıkları yönetmek için kullanılır. Mavi/Yeşil (Blue/Green) veya Kanarya (Canary) dağıtım stratejileri, üretimdeki kesinti süresini en aza indirmek için pipeline'a entegre edilebilir.

deploy_backend_ecs:stage: deployimage: python:3.9script:- pip install awscli boto3- python deploy_ecs.py --service backend-api --image $BACKEND_IMAGE --cluster my-ecommerce-clusterneeds:- build_backendartifacts:paths:- deployment_status.txtexpire_in: 1 hour

Yukarıdaki örnek, özel bir Python betiği kullanarak ECS servisini güncellemeyi gösterir. Bu betik, yeni Docker imajını alır ve ECS servisini kademeli olarak güncelleyerek potansiyel sorunlarda geri dönüş imkanı sunar. needs anahtar kelimesi, deploy_backend_ecs işinin ancak build_backend işi başarıyla tamamlandığında çalışacağını belirtir.

Pipeline Optimizasyonu ve Gözetim

Verimli bir CI/CD pipeline'ı sadece çalışmakla kalmaz, aynı zamanda hızlı ve güvenilir olmalıdır. Optimizasyon için şu stratejiler uygulanabilir:

  • Önbellekleme (Caching): Bağımlılıkların veya derlenmiş modüllerin tekrar tekrar indirilmesini önlemek için cache anahtar kelimesini kullanın. Özellikle Node.js (node_modules) veya Python (venv) projelerinde bu önemlidir.
  • Artifact Yönetimi: Sadece gerekli artifact'ları saklayın ve kısa süreli depolama için expire_in kullanın. Büyük artifact'lar pipeline hızını düşürebilir.
  • rules Anahtar Kelimesi: İşlerin ne zaman çalışacağını daha hassas kontrol etmek için only/except yerine rules kullanın. Bu, belirli branch'lerde, etiketlerde veya dosya değişikliklerinde işleri tetiklemeye olanak tanır.
  • Paralel Çalışma: Bağımsız işleri aynı anda çalıştırmak için birden fazla runner kullanın.
  • Runners Optimizasyonu: Doğru donanıma sahip, ölçeklenebilir runner'lar (özellikle Auto-scaling Group üzerindeki EC2 instance'ları) pipeline süresini kısaltır.

Pipeline sağlığını izlemek de önemlidir. GitLab'in yerleşik metrikleri ve entegrasyonları sayesinde Prometheus ve Grafana gibi araçlarla pipeline çalışma sürelerini, başarı/başarısızlık oranlarını ve kaynak kullanımını takip edebilirsiniz. Bu veriler, darboğazları tespit etmek ve pipeline'ı sürekli iyileştirmek için temel oluşturur.

Sonuç

GitLab CI/CD, basit bir projeden karmaşık bir mikroservis mimarisine kadar her ölçekteki yazılım geliştirme ekibi için güçlü bir otomasyon platformu sunar. Doğru yapılandırma, güvenlik odaklı entegrasyonlar (özellikle AWS OIDC ile), dinamik pipeline yaklaşımları ve sürekli optimizasyon ile kesintisiz, güvenilir ve verimli bir yazılım teslim süreci inşa edilebilir. Unutmayın, bir pipeline'ın değeri, sadece işleri otomatikleştirmesi değil, aynı zamanda hataları erken yakalaması ve üretim ortamına güvenli dağıtımlar sağlamasıdır.

← Blog Listesine Dön