GitLab ve DigitalOcean Yönetilen Kubernetes ile CI/CD Hattı Oluşturma

GitLab ve DigitalOcean Yönetilen Kubernetes ile CI/CD Hattı Oluşturma

Giriş

Günümüzün hızla değişen yazılım geliştirme dünyasında, uygulamaları hızlı, güvenilir ve tekrarlanabilir bir şekilde dağıtabilmek kritik bir başarı faktörüdür. Sürekli Entegrasyon (CI) ve Sürekli Dağıtım (CD) pratikleri, bu hedefe ulaşmanın temelini oluşturur. Bu makalede, açık kaynaklı ve güçlü bir DevOps platformu olan GitLab’ı kullanarak, bulut tabanlı ve yönetilen bir Kubernetes hizmeti olan DigitalOcean Managed Kubernetes (DOKS) üzerinde otomatik bir CI/CD hattı nasıl oluşturulacağını adım adım inceleyeceğiz. Bu entegrasyon, geliştiricilere kodlarını hızlı bir şekilde test etme, konteynerleştirme ve üretim ortamına dağıtma yeteneği sunarak, geliştirme süreçlerini büyük ölçüde hızlandırır ve operasyonel yükü azaltır.

CI/CD Nedir?

Sürekli Entegrasyon (Continuous Integration – CI), geliştiricilerin kod değişikliklerini düzenli olarak merkezi bir depoya entegre etmelerini gerektiren bir yazılım geliştirme uygulamasıdır. Her entegrasyon, otomatik bir derleme ve test süreci tarafından doğrulanır. Bu, hataların erken tespit edilmesini sağlar, entegrasyon sorunlarını azaltır ve daha tutarlı bir kod tabanı oluşturur.

Sürekli Dağıtım (Continuous Deployment – CD), CI’nın bir uzantısıdır ve tüm testleri başarıyla geçen kod değişikliklerinin otomatik olarak üretim ortamına dağıtılmasını sağlar. Bu, manuel müdahaleyi ortadan kaldırır ve yazılımın müşterilere çok daha hızlı ulaşmasını sağlar. Sürekli Teslimat (Continuous Delivery) ise, üretim ortamına otomatik dağıtım yerine, insan onayına tabi tutularak dağıtıma hazır hale getirilmesi anlamına gelir; CD, Sürekli Teslimat’ın tam otomasyonlu halidir.

GitLab ve DigitalOcean Kubernetes’in Gücü

GitLab, kod depolama, sürüm kontrolü, proje yönetimi, CI/CD, güvenlik taraması ve daha fazlasını tek bir platformda sunan kapsamlı bir DevOps aracıdır. Entegre CI/CD motoru sayesinde, .gitlab-ci.yml dosyası aracılığıyla esnek ve güçlü otomasyon hatları oluşturmak mümkündür.

DigitalOcean Managed Kubernetes (DOKS), DigitalOcean’ın sunduğu, Kubernetes kümelerini yönetmeyi kolaylaştıran bir hizmettir. DOKS ile altyapı yönetimi yükünü DigitalOcean’a bırakarak, uygulamalarınızı ölçeklenebilir ve yüksek erişilebilir bir ortamda çalıştırmaya odaklanabilirsiniz. Otomatik yükseltmeler, yedeklemeler ve kolay ölçekleme gibi özellikler, DOKS’u geliştiriciler için cazip bir seçenek haline getirir.

Bu makalede, bir örnek uygulamayı Docker kullanarak konteynerleştirecek, GitLab Container Registry’ye itecek ve ardından Kubernetes manifestleri aracılığıyla DOKS kümesinde dağıtmak için bir GitLab CI/CD hattı oluşturacağız.

Ön Koşullar

Bu makaledeki adımları takip edebilmek için aşağıdaki ön koşullara sahip olmanız gerekmektedir:

* GitLab Hesabı: Bir GitLab hesabına sahip olmanız ve yeni bir proje oluşturma yetkiniz olması.
* DigitalOcean Hesabı: Bir DigitalOcean hesabına sahip olmanız ve Kubernetes kümesi oluşturma yetkiniz olması.
* Temel Docker Bilgisi: Dockerfile oluşturma ve Docker imajları ile çalışma konusunda temel bilgi.
* Temel Kubernetes Bilgisi: Kubernetes kavramları (Pod, Deployment, Service, Namespace) hakkında temel bilgi.
* kubectl Yüklü Olması: Kubernetes kümeleriyle etkileşim kurmak için komut satırı aracı.
* doctl Yüklü Olması (İsteğe Bağlı ama Önerilir): DigitalOcean API ile etkileşim kurmak için komut satırı aracı.
* Yerel Geliştirme Ortamı: Uygulamanızı geliştirmek ve Docker imajlarını yerel olarak test etmek için uygun bir ortam (Node.js, Python, Go vb. kurulu).

DigitalOcean Kubernetes (DOKS) Kümesi Oluşturma

Uygulamamızı dağıtacağımız temel altyapı, DigitalOcean Kubernetes kümesidir. Bu bölüm, bir DOKS kümesi oluşturma ve kubectl aracılığıyla ona bağlanma adımlarını kapsar.

DigitalOcean Hesap Oluşturma ve API Anahtarı

Eğer bir DigitalOcean hesabınız yoksa, öncelikle bir hesap oluşturmanız gerekmektedir. CI/CD hattımızın DigitalOcean kaynaklarıyla etkileşim kurabilmesi için bir API anahtarı oluşturmamız gerekecek.
1. DigitalOcean kontrol paneline giriş yapın.
2. Sol menüden “API” bölümüne gidin.
3. “Tokens/Keys” sekmesinde “Generate New Token” butonuna tıklayın.
4. Token’a bir isim verin (örn. gitlab-ci-token) ve “Read” ile “Write” izinlerini verin.
5. Oluşturulan token’ı kopyalayın. Bu token’ı daha sonra GitLab CI/CD ortam değişkenlerinde kullanacağız. Bu token’ı güvende tutun ve kimseyle paylaşmayın.

DOKS Kümesi Kurulumu

DOKS kümenizi DigitalOcean kontrol paneli veya doctl komut satırı aracı aracılığıyla oluşturabilirsiniz. Kontrol panelini kullanmak daha görsel ve kolaydır.

Kontrol Paneli Üzerinden:
1. DigitalOcean kontrol paneline giriş yapın.
2. Sol menüden “Kubernetes” seçeneğine tıklayın.
3. “Create Kubernetes Cluster” butonuna tıklayın.
4. Kümenizin özelliklerini yapılandırın:
* Kubernetes Version: En son stabil sürümü seçmeniz önerilir.
* Region: Uygulamanızın kullanıcılarına en yakın bölgeyi seçin.
* Node Pool: Kümenizin düğümlerinin boyutunu ve sayısını belirleyin. Geliştirme veya küçük projeler için daha küçük ve az sayıda düğümle başlayabilirsiniz (örn. 2 vCPU, 4 GB RAM, 2 düğüm).
* Cluster Name: Kümenize anlamlı bir isim verin (örn. gitlab-ci-cd-cluster).
5. “Create Cluster” butonuna tıklayarak kümenizi oluşturun. Kümenin oluşturulması birkaç dakika sürebilir.

doctl Komut Satırı Üzerinden (API anahtarınızı yapılandırdıktan sonra):

doctl auth init # Bu komutla API anahtarınızı yapılandırın
doctl kubernetes cluster create gitlab-ci-cd-cluster \
  --region nyc1 \
  --version 1.28.2-do.0 \
  --node-pool name=worker-pool,size=s-2vcpu-4gb,count=2

Bu komut, nyc1 bölgesinde gitlab-ci-cd-cluster adında, 1.28.2 Kubernetes sürümüne sahip ve s-2vcpu-4gb boyutunda iki adet düğüm içeren bir küme oluşturur.

kubectl ile Kümenize Bağlanma

Kümeniz oluşturulduktan sonra, yerel makinenizden kubectl aracını kullanarak kümenize bağlanmanız gerekir.
1. DigitalOcean kontrol panelinde, oluşturduğunuz Kubernetes kümesinin detay sayfasına gidin.
2. “Actions” menüsünden “Download Config File” seçeneğine tıklayın. Bu, kubeconfig.yaml dosyasını indirecektir.
3. İndirdiğiniz dosyayı ~/.kube/config dosyasıyla birleştirin veya ayrı bir dosya olarak kaydedip KUBECONFIG ortam değişkenini ayarlayın:

mkdir -p ~/.kube
    mv path/to/your/kubeconfig.yaml ~/.kube/config-gitlab-ci-cd
    export KUBECONFIG=~/.kube/config-gitlab-ci-cd:$KUBECONFIG # Mevcut config'lerinizle birleştirin

4. Bağlantıyı test etmek için aşağıdaki komutu çalıştırın:

kubectl get nodes

Bu komut, kümenizdeki düğümleri listelemelidir. Eğer düğümleri görüyorsanız, kubectl başarıyla yapılandırılmıştır.

ÖNEMLİ: Bu kubeconfig dosyası, kümenize tam erişim sağlar. Bu dosyayı güvende tutmanız ve daha sonra GitLab CI/CD ortam değişkenlerinde kullanmak üzere base64 ile kodlanmış halini almanız gerekecektir.

Uygulamayı Konteynerleştirme (Docker)

CI/CD hattımızın ilk adımı, uygulamamızı bir Docker imajı haline getirmektir. Bu, uygulamanın tüm bağımlılıklarıyla birlikte taşınabilir ve izole bir ortamda çalışmasını sağlar. Örnek olarak, basit bir Node.js uygulamasını konteynerleştirelim.

Dockerfile Oluşturma

Uygulama dizininizin kök dizininde Dockerfile adında bir dosya oluşturun:

# Node.js için resmi bir temel imaj kullan
FROM node:18-alpine

Çalışma dizinini ayarla
WORKDIR /app

package.json ve package-lock.json dosyalarını kopyala
Bağımlılıkları önbelleğe almak için bu adımı ayrı yapın
COPY package*.json ./

Bağımlılıkları yükle
RUN npm install

Uygulama kaynak kodunu kopyala
COPY . .

Uygulamanın dinleyeceği portu açığa çıkar
EXPOSE 3000

Uygulamayı başlatma komutu
CMD [ "node", "server.js" ]

Örnek server.js dosyası:

const http = require('http');

const hostname = '0.0.0.0';
const port = 3000;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Merhaba Dunya! Bu benim GitLab CI/CD uygulamam.\n');
});

server.listen(port, hostname, () => {
  console.log(Sunucu http://${hostname}:${port}/ adresinde calisiyor);
});

Örnek package.json dosyası:

{
  "name": "my-node-app",
  "version": "1.0.0",
  "description": "A simple Node.js app for GitLab CI/CD",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.2"
  },
  "author": "",
  "license": "ISC"
}

Yerel Olarak Docker İmajını Test Etme

Dockerfile’ınızı oluşturduktan sonra, yerel makinenizde imajı derleyip çalıştırarak uygulamanızın konteyner içinde doğru çalıştığından emin olun.

1. Uygulama dizininizde terminali açın.
2. Docker imajını derleyin:

docker build -t my-node-app:latest .

3. Derlenen imajı çalıştırın:

docker run -p 8080:3000 my-node-app:latest

4. Tarayıcınızda http://localhost:8080 adresine giderek uygulamanın çalıştığını doğrulayın.

GitLab Projesi Kurulumu

Uygulama kodumuzu ve CI/CD yapılandırmamızı GitLab’da barındıracağız.

Yeni Bir GitLab Projesi Oluşturma

1. GitLab hesabınıza giriş yapın.
2. Sol menüden “Projects” > “Your projects” yolunu izleyin veya doğrudan sağ üstteki “New project” butonuna tıklayın.
3. “Create blank project” seçeneğini seçin.
4. Projenize bir isim verin (örn. gitlab-doks-ci-cd).
5. Görünürlük seviyesini (Public, Internal, Private) seçin.
6. “Create project” butonuna tıklayın.

Uygulama Kodunu GitLab’a Yükleme

Yerel uygulama kodunuzu yeni oluşturduğunuz GitLab projesine push edin.

# Yerel Git deposu başlatma (eğer henüz yapmadıysanız)
git init

Dosyaları ekle
git add .

İlk commit'i yap
git commit -m "Initial commit of Node.js app"

GitLab projenizin URL'sini uzak depo olarak ekle
git remote add origin https://gitlab.com/your-username/gitlab-doks-ci-cd.git # Kendi URL'nizle değiştirin

Kodu GitLab'a push et
git push -u origin master

Artık uygulama kodunuz GitLab’da barındırılıyor.

GitLab Container Registry Kullanımı

GitLab, her projeye entegre bir Container Registry (Docker Registry) sunar. Bu, Docker imajlarınızı depolamak ve yönetmek için harici bir hizmete ihtiyaç duymadan GitLab içinde kalmanızı sağlar.

Container Registry’nin Önemi

CI/CD hattımızda Docker imajları oluşturduktan sonra, bu imajları Kubernetes kümemizin erişebileceği bir yere depolamamız gerekir. GitLab Container Registry, bu amaç için idealdir. İmajları burada depolayarak, Kubernetes Deployment manifestlerimizde doğrudan GitLab Registry’den çekebiliriz. Bu, güvenlik ve entegrasyon açısından büyük avantaj sağlar.

Kimlik Doğrulama ve İmaj Yükleme

GitLab CI/CD hattımız, GitLab Container Registry’ye kimlik doğrulaması yaparak imajları yükleyecektir. CI/CD işleri, varsayılan olarak CI_REGISTRY_USER (genellikle gitlab-ci-token) ve CI_REGISTRY_PASSWORD (işe özel token) ortam değişkenleri aracılığıyla Registry’ye erişim sağlar.

Bir imajı GitLab Container Registry’ye yüklemek için, önce docker login komutuyla kimlik doğrulaması yapmanız ve ardından docker push komutunu kullanmanız gerekir. CI/CD hattımızda bu adımlar otomatik olarak gerçekleştirilecektir.

GitLab Container Registry adresi genellikle registry.gitlab.com/your-username/your-project-name şeklindedir. GitLab CI/CD içinde bu adres CI_REGISTRY ve CI_REGISTRY_IMAGE değişkenleriyle otomatik olarak sağlanır.

Kubernetes Dağıtım Manifestleri Oluşturma

Uygulamamızı Kubernetes kümesinde dağıtmak için Kubernetes manifest dosyaları (YAML) oluşturmamız gerekir. Bu dosyalar, uygulamanızın nasıl çalıştırılacağını, nasıl erişileceğini ve nasıl ölçekleneceğini tanımlar. Uygulama kodunuzun kök dizininde .k8s adında bir dizin oluşturup manifest dosyalarını buraya yerleştirebilirsiniz.

Namespace Tanımlama (İsteğe Bağlı ama Önerilir)

Uygulamalarınızı izole etmek ve kaynakları daha iyi yönetmek için bir Namespace oluşturmak iyi bir pratiktir.
.k8s/namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: my-app-namespace

Deployment Manifesti

Deployment, uygulamanızın Pod’larını yönetir ve bunların kümenizde istenen durumda çalışmasını sağlar.
.k8s/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-node-app-deployment
  namespace: my-app-namespace # Namespace belirtin
  labels:
    app: my-node-app
spec:
  replicas: 2 # Uygulamanızın 2 kopyasını çalıştırın
  selector:
    matchLabels:
      app: my-node-app
  template:
    metadata:
      labels:
        app: my-node-app
    spec:
      containers:
      - name: my-node-app
        image: registry.gitlab.com/your-username/gitlab-doks-ci-cd:latest # CI/CD ile güncellenecek
        ports:
        - containerPort: 3000
        resources: # Kaynak limitleri ve istekleri tanımlayın (iyi bir pratik)
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "200m"

ÖNEMLİ: image alanını kendi GitLab Container Registry adresinizle güncelleyin. CI/CD hattı bu latest etiketi yerine commit SHA veya dinamik bir etiket kullanacaktır.

Service Manifesti

Service, Pod’larınıza ağ erişimi sağlar. Dışarıdan erişim için NodePort veya LoadBalancer tipi bir Service kullanabiliriz. DOKS üzerinde LoadBalancer tipi kullanmak, DigitalOcean’ın otomatik olarak bir Load Balancer sağlamasını ve uygulamanıza dışarıdan bir IP adresi atamasını sağlar.
.k8s/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-node-app-service
  namespace: my-app-namespace
  labels:
    app: my-node-app
spec:
  selector:
    app: my-node-app
  type: LoadBalancer # Dışarıdan erişim için DigitalOcean Load Balancer sağlar
  ports:
    - protocol: TCP
      port: 80 # Servisin dinleyeceği port
      targetPort: 3000 # Pod'un dinlediği port

Ingress Manifesti (İsteğe Bağlı)

Daha gelişmiş yönlendirme, SSL sonlandırma ve birden fazla servisi tek bir alan adı altında yönetmek için Ingress kullanabilirsiniz. Ingress kullanabilmek için kümenizde bir Ingress Controller (örn. Nginx Ingress Controller) kurulu olması gerekir. Bu kurulum DigitalOcean’da genellikle tek tıkla yapılabilir veya manuel olarak eklenebilir. Bu makalede LoadBalancer Service kullanacağımız için Ingress’i atlayabiliriz, ancak üretim ortamları için Ingress daha esnek bir çözümdür.

GitLab CI/CD Pipeline (.gitlab-ci.yml) Yapılandırması

Bu bölüm, projemizin kök dizininde .gitlab-ci.yml dosyasını oluşturarak CI/CD hattımızı tanımlayacağımız en kritik kısımdır. Bu dosya, GitLab Runner’ların hangi adımları hangi sırada gerçekleştireceğini belirler.

Pipeline Aşamaları (Stages)

CI/CD hattımızı mantıksal aşamalara ayırmak, süreci daha anlaşılır ve yönetilebilir kılar. Genellikle build, test ve deploy aşamaları kullanılır.

stages:
  - build
  - deploy

Build Aşaması: Docker İmajı Oluşturma ve Yükleme

Bu aşamada, uygulama kodumuzdan bir Docker imajı oluşturacak ve bunu GitLab Container Registry’ye yükleyeceğiz. docker:dind (Docker-in-Docker) hizmetini kullanarak bir Docker ortamı sağlarız.

build-image:
  stage: build
  image: docker:latest # Bu iş için Docker CLI içeren bir imaj kullan
  services:
    - docker:dind # Docker-in-Docker hizmetini etkinleştir
  variables:
    DOCKER_HOST: tcp://docker:2375 # DIND servisine bağlanmak için
    DOCKER_TLS_CERTDIR: "" # TLS'i devre dışı bırak (güvenli değil, sadece örnek için)
    # Production ortamında TLS kullanmalı ve DOCKER_TLS_CERTDIR'i yapılandırmalısınız
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA $CI_REGISTRY_IMAGE:latest # latest etiketini de güncelleyin
    - docker push $CI_REGISTRY_IMAGE:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "master" # Sadece master branch'ine yapılan push'larda çalıştır

Açıklama:
* image: docker:latest: Bu işin çalışacağı Docker imajını belirtir.
* services: - docker:dind: İş içinde Docker komutlarını çalıştırabilmek için bir Docker daemon’ı sağlar.
* variables: DOCKER_HOST ve DOCKER_TLS_CERTDIR DIND servisiyle iletişim kurmak için ayarlanır.
* before_script: GitLab Container Registry’ye kimlik doğrulaması yapar. $CI_REGISTRY_USER ve $CI_REGISTRY_PASSWORD GitLab tarafından otomatik olarak sağlanan gizli değişkenlerdir.
* script:
* docker build: Uygulamamızın Dockerfile’ından bir imaj derler. $CI_REGISTRY_IMAGE değişkeni GitLab Registry’deki projemizin imaj yolunu içerir (örn. registry.gitlab.com/your-username/your-project). $CI_COMMIT_SHORT_SHA ise mevcut commit’in kısa SHA değeridir ve imajı benzersiz bir şekilde etiketlemek için kullanılır.
* docker push: Derlenen imajı GitLab Container Registry’ye yükler.
* docker tag: latest etiketini de mevcut imaja işaret edecek şekilde günceller.
* docker push: latest etiketli imajı da yükler.
* rules: Bu işin ne zaman çalışacağını belirler. Burada sadece master (veya main) dalına yapılan commit’lerde çalışması sağlanmıştır.

Deploy Aşaması: Kubernetes’e Dağıtım

Bu aşamada, oluşturduğumuz Docker imajını Kubernetes kümemize dağıtacağız. Bunun için kubectl komutlarını kullanacağız.

deploy-to-kubernetes:
  stage: deploy
  image: bitnami/kubectl:latest # kubectl aracı içeren bir imaj kullan
  before_script:
    # Kubeconfig dosyasını base64'ten çözerek geçici bir dosyaya yaz
    - echo $KUBECONFIG_BASE64 | base64 -d > kubeconfig.yaml
    - export KUBECONFIG=$(pwd)/kubeconfig.yaml # kubectl'in bu dosyayı kullanmasını sağla
    - kubectl config use-context $(kubectl config get-contexts -o name | grep -E 'gitlab-ci-cd-cluster|do-nyc1-gitlab-ci-cd-cluster' | head -n 1) # Kümenizin context adını dinamik olarak bulmaya çalışır
    - kubectl get nodes # Bağlantıyı test etmek için
  script:
    # Namespace oluştur (eğer yoksa)
    - kubectl apply -f .k8s/namespace.yaml || true # Hata verirse devam et
    # Deployment manifestindeki imaj etiketini güncelle
    - sed -i "s|image: registry.gitlab.com/your-username/gitlab-doks-ci-cd:latest|image: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA|g" .k8s/deployment.yaml
    # Kubernetes manifestlerini uygula
    - kubectl apply -f .k8s/
  rules:
    - if: $CI_COMMIT_BRANCH == "master"
  environment:
    name: production
    url: http://my-node-app-service.my-app-namespace.svc.cluster.local # Bu URL küme içi erişim için, dışarıdan erişim için LoadBalancer IP'sini kullanın

Açıklama:
* image: bitnami/kubectl:latest: kubectl aracını içeren bir Docker imajı kullanır.
* before_script:
* KUBECONFIG_BASE64 adında bir GitLab CI/CD ortam değişkeni tanımlayacağız. Bu değişken, base64 ile kodlanmış Kubernetes kubeconfig dosyamızı içerecek. Burada bu değişkeni çözüp geçici bir dosyaya yazarız.
* export KUBECONFIG: kubectl‘in bu geçici dosyayı kullanmasını sağlar.
* kubectl config use-context: Kümenizin doğru context’ini seçer. DigitalOcean’da context adı genellikle do-bölge-kümeadı formatındadır.
* kubectl get nodes: Küme bağlantısının başarılı olup olmadığını kontrol eder.
* script:
* kubectl apply -f .k8s/namespace.yaml || true: Namespace’i oluşturur. Eğer zaten varsa hata vermesini engellemek için || true eklenmiştir.
* sed -i "s|...|...|g" .k8s/deployment.yaml: Bu komut, deployment.yaml dosyasındaki Docker imaj etiketini dinamik olarak, build aşamasında oluşturduğumuz ve $CI_COMMIT_SHORT_SHA ile etiketlediğimiz imajla günceller. your-username/gitlab-doks-ci-cd kısmını kendi projenizin yoluyla güncellemeyi unutmayın!
* kubectl apply -f .k8s/: .k8s dizinindeki tüm manifest dosyalarını Kubernetes kümesine uygular. Bu, Deployment ve Service’i oluşturur veya günceller.
* rules: Sadece master dalına yapılan push’larda çalışır.
* environment: GitLab UI’da dağıtımın hangi ortama yapıldığını ve ilgili URL’yi gösterir.

GitLab CI/CD Ortam Değişkenleri ve Gizlilik Yönetimi

CI/CD hattımızın güvenli bir şekilde çalışabilmesi için hassas bilgileri (kubeconfig, Docker kimlik bilgileri vb.) ortam değişkenleri olarak saklamamız gerekir. GitLab, bunu “Settings” > “CI/CD” > “Variables” altında yönetmenize olanak tanır.

Gerekli Değişkenler:

1. KUBECONFIG_BASE64:
* Değer: DigitalOcean kümenizden indirdiğiniz kubeconfig.yaml dosyasının base64 ile kodlanmış hali.

base64 -w 0 ~/.kube/config-gitlab-ci-cd # macOS/Linux için
        # veya PowerShell'de: [System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes("C:\path\to\kubeconfig.yaml"))

* Tip: File (önerilir) veya Variable
* Masked: Evet (gizli tutmak için)
* Protected: Evet (sadece korumalı dallar ve etiketler için)

2. DOCKER_USERNAME ve DOCKER_PASSWORD: GitLab Container Registry’ye manuel olarak login olmanız gerekirse kullanabilirsiniz, ancak $CI_REGISTRY_USER ve $CI_REGISTRY_PASSWORD genellikle yeterlidir. Eğer harici bir registry kullanıyorsanız bu değişkenleri tanımlamanız gerekir.

Bu değişkenleri GitLab projenizin “Settings” > “CI/CD” > “Variables” bölümüne eklemeyi unutmayın. KUBECONFIG_BASE64 değişkenini kesinlikle Masked olarak işaretleyin.

CI/CD Pipeline’ı Test Etme

Tüm yapılandırmaları tamamladıktan sonra, CI/CD hattımızın beklendiği gibi çalışıp çalışmadığını test etme zamanı.

Değişiklikleri Push Etme

.gitlab-ci.yml ve .k8s dizinindeki manifest dosyalarını GitLab projenize push edin:

git add .gitlab-ci.yml .k8s/
git commit -m "Add GitLab CI/CD pipeline and Kubernetes manifests"
git push origin master # Veya hangi dalı kullanıyorsanız

Bu push işlemi, GitLab’da otomatik olarak bir pipeline tetikleyecektir.

Pipeline Çalışmasını İzleme

1. GitLab projenize gidin.
2. Sol menüden “CI/CD” > “Pipelines” seçeneğine tıklayın.
3. Yeni tetiklenen pipeline’ı göreceksiniz. Üzerine tıklayarak detaylarına gidin.
4. Pipeline’daki her bir işin (build-image, deploy-to-kubernetes) durumunu ve günlüklerini (logs) izleyebilirsiniz. Herhangi bir hata durumunda, günlükler sorunu tespit etmenize yardımcı olacaktır.

Uygulamanın Doğrulanması

Pipeline başarıyla tamamlandığında, uygulamanız DigitalOcean Kubernetes kümenize dağıtılmış olmalıdır.

1. Kubernetes Pod’larını kontrol edin:

kubectl get pods -n my-app-namespace

İki adet my-node-app-deployment Pod’unun Running durumda olduğunu görmelisiniz.

2. Kubernetes Service’i kontrol edin:

kubectl get svc -n my-app-namespace

my-node-app-service adında bir Service göreceksiniz. EXTERNAL-IP sütununda bir IP adresi atanmış olmalıdır. Bu IP adresi, DigitalOcean Load Balancer tarafından sağlanan genel IP’dir. IP’nin atanması birkaç dakika sürebilir.

3. Uygulamaya Tarayıcıdan Erişin:
kubectl get svc komutundan aldığınız EXTERNAL-IP adresini tarayıcınızda açın. Uygulamanızın “Merhaba Dunya! Bu benim GitLab CI/CD uygulamam.” mesajını göstermesi gerekir.

Tebrikler! GitLab ve DigitalOcean Kubernetes kullanarak tam otomatik bir CI/CD hattı oluşturdunuz. Artık master dalına yaptığınız her kod değişikliği otomatik olarak derlenecek, konteynerleştirilecek ve Kubernetes kümenize dağıtılacaktır.

İleri Seviye Konular ve En İyi Uygulamalar

Kurduğumuz temel CI/CD hattı harika bir başlangıç noktasıdır, ancak gerçek dünya uygulamaları için dikkate alınması gereken birçok ileri seviye konu ve en iyi uygulama bulunmaktadır.

Ortam Bazlı Dağıtımlar (Staging, Production)

Genellikle uygulamaları doğrudan üretim ortamına dağıtmadan önce bir hazırlık (staging) ortamında test etmek istenir. GitLab CI/CD, farklı dallara (örn. develop için staging, master için production) veya manuel tetiklemelere dayalı olarak farklı dağıtım işleri tanımlamanıza olanak tanır.

* rules veya only/except anahtar kelimeleri: Farklı dallar için farklı dağıtım işleri tanımlayın.
* GitLab Environments: GitLab, dağıtımlarınızı ortamlara göre düzenlemenizi sağlar. Bu, hangi sürümün hangi ortamda çalıştığını takip etmeyi kolaylaştırır.
* Kubernetes Namespaces: Her ortam için ayrı Kubernetes Namespace’leri kullanmak, kaynak izolasyonu ve yönetimi sağlar.

Geri Alma (Rollback) Stratejileri

Yeni bir dağıtımın sorunlara yol açması durumunda, hızlı bir şekilde önceki stabil sürüme geri dönebilmek kritik öneme sahiptir. Kubernetes Deployment’ları, yerleşik geri alma yeteneklerine sahiptir:

kubectl rollout undo deployment/my-node-app-deployment -n my-app-namespace

CI/CD hattınıza manuel veya otomatik bir geri alma adımı ekleyebilirsiniz.

Helm Charts ile Dağıtımı Yönetme

Uygulamalarınız büyüdükçe ve Kubernetes manifestleriniz karmaşıklaştıkça, Helm Charts kullanmak dağıtımı basitleştirir. Helm, Kubernetes uygulamaları için bir paket yöneticisidir.

* Şablonlama: Helm, manifest dosyalarınızı şablonlamanıza olanak tanır, böylece farklı ortamlar için değerleri kolayca değiştirebilirsiniz.
* Sürümleme: Uygulamanızın dağıtımlarını sürümleyebilir ve kolayca geri alabilirsiniz.
* Bağımlılık Yönetimi: Birden fazla Kubernetes kaynağını tek bir paket olarak yönetmenizi sağlar.

Helm kullanmak için CI/CD hattınızdaki kubectl apply adımlarını helm upgrade --install komutlarıyla değiştirmeniz gerekir.

İzleme ve Günlükleme (Monitoring & Logging)

Dağıtılan uygulamalarınızın sağlığını ve performansını sürekli izlemek önemlidir.

* DigitalOcean Monitoring: DOKS, düğüm metrikleri ve bazı temel Pod metrikleri için DigitalOcean izlemesiyle entegredir.
* Prometheus ve Grafana: Kubernetes için endüstri standardı izleme araçlarıdır. Kümenize kurularak detaylı metrikler toplayabilir ve görselleştirebilirsiniz.
* Elastic Stack (ELK) veya Loki: Uygulama günlüklerini toplamak, depolamak ve analiz etmek için kullanılabilir.

Otomatik Ölçekleme (Autoscaling)

Uygulamanızın trafiği değiştikçe, kaynakları otomatik olarak ayarlamak maliyetleri optimize eder ve performansı artırır.

* Horizontal Pod Autoscaler (HPA): Pod’larınızın CPU veya bellek kullanımına göre otomatik olarak ölçeklenmesini sağlar.
* Cluster Autoscaler: Düğüm kaynakları yetersiz kaldığında kümenize otomatik olarak yeni düğümler ekler (DOKS bunu otomatik olarak yönetir, ancak yapılandırma gerekebilir).

Sonuç

Bu makalede, GitLab ve DigitalOcean Managed Kubernetes’i bir araya getirerek güçlü ve otomatik bir CI/CD hattı oluşturmayı adım adım öğrendik. Uygulamamızı konteynerleştirdik, GitLab Container Registry’ye ittik ve Kubernetes manifestleri aracılığıyla DOKS kümemize dağıttık. Bu süreç, geliştirme hızını artırır, insan hatasını azaltır ve uygulamaların daha hızlı ve güvenilir bir şekilde müşterilere ulaşmasını sağlar.

Kurduğumuz bu temel hattı, ileri seviye konuları ve en iyi uygulamaları (ortam bazlı dağıtımlar, Helm, izleme, otomatik ölçekleme) entegre ederek daha da geliştirebilirsiniz. DevOps yolculuğunuzda bu entegrasyon, modern bulut tabanlı uygulama dağıtımının temel taşlarından birini oluşturacaktır. Bu altyapı ile, kodunuzu yazmaya ve yenilik yapmaya odaklanırken, dağıtım süreçlerinizin sorunsuz ve otomatik bir şekilde ilerlediğinden emin olabilirsiniz.