DEV Community: Suleyman

Helm Nedir

Suleyman — Tue, 30 Dec 2025 19:51:33 +0000

Helm Nedir
Kubernetes kullanan herkesin mutlaka öğreneceği bir yazılım olan helm için kubernetesin paket yöneticisi diyebiliriz. İşletim sistemlerinde ki apt,dnf gibi hızlı bir şekilde uygulamalarımızı kurmamızı sağlamaktadır.

Örneğin; wordpress altyapısı için bir wordpress yazılımı ve arka tarafında mysql veritabanı çalışması gerekmektedir. Biz bu yapıyı manuel olarak deploymentlar, statefulset ve servisler ile ayağa kaldırabiliriz. Ama helm ile bu yapıyı tek bir komutla ayağa kaldırabiliriz.

Wordpress iki bileşenden oluşuyor ama uygulamamız için deploymentlar, statefulset, servisler, persistencevolume, serviceaccount, rolebinding gibi fazla sayıda objemiz var ise bu yapıyı farklı clusterlarda ayağa kaldırmak iş yükü çıkartacaktır. Helm ile bu yapıyı bir paket haline getirip tek komut ile ayağa kaldırabiliriz.

Bir güzel özelliği daha ortama bağlı olarak dinamik değerlerin kullanılabilmesidir. Örneğin; dev veya prod ortamları için farklı kaynak limitleri, pod replika sayıları vb. oluşturabiliriz.

Helm Chart Olusturma

helm create suleyman-helm-project

Yukarıda ki komut ile helm chart oluşturuyoruz. Bu komut ile bize helm dosya yapısını oluşturacak

charts
Chart.yaml > Helm chart ile ilgili temel bilgilerin yazıldığı dosyadır. Chart ismi, versiyonu v.
templates > Kubernetes manifest dosyalarımızın yazıldığı klasördür.
values.yaml > Helm chart için varsayılan değerlerin yazıldığı klasördür.

Aşağıdaki gibi bir python uygulamam ve bağlandığı veritabanı ve bunların servisleri var. Bunları templates klasörüne içine atıyorum.

Artık suleyman-helm-project klasörünün içerisinde helm install suleyman-uygulama . aşağıdaki gibi bir sonuç verecektir.

root@master:~/helm/suleyman-project# helm install suleyman-uygulama .

NAME: suleyman-uygulama
LAST DEPLOYED: Tue Dec 30 19:45:29 2025
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

Kaldırmak için de helm uninstall suleyman-uygulama komutu kullanılabilir.

Helm ile önceki versiyonlar arasında geçiş yapabiliriz. Bu şekilde kullanmak çok kullanışlı değil çünkü parametreler dinamik olarak güncellenmiyor. Ama production ortamlarda bazı istenilen değerler values.yaml dosyası ile dinamik olarak değiştirilebilmektedir.

Helm ile ilgili daha fazla örneğini aşağıdaki github repository içerisinde bulabilirsiniz.

https://github.com/suleymanakturk/Helm.git

Bir sonraki makalede görüşmek üzere, iyi günler.

Sonarqube Nedir

Suleyman — Sat, 13 Dec 2025 12:18:28 +0000

Merhaba,

Bu makalede yazılımcıların ve Devops mühendislerinin en çok kullandığı uygulamalardan biri olan sonarqube uygulamasını inceleyeceğiz.

Sonarqube, yazılım geliştirme sürecinde kullanılan bir açık kaynaklı platformdur. Kod kalitesini analiz etmek, hataları ve kötü uygulama uygulamalarını belirlemek için kullanılır. Hem community hem de enterprise sürümleri bulunmaktadır.

Sonarqube uygulamasını ister direk sunucu üzerine istersek docker veya kubernetes üzerine veya sonarcloud üzerinde çalıştırabiliriz.

Sonarqube Özellikler

Statik Kod Analizi: SonarQube kaynak kodunu çalıştırmadan analiz eder. Hatalar, güvenlik açıkları, kod çoğaltma ve daha fazlası gibi sorunları kontrol eder.

Kalite Kapıları: SonarQube, analizi geçmek için kodunuzun karşılaması gereken standartları tanımlamak için kalite kapılarını kullanır. Yeni kod değişikliklerinin yeni kalite sorunları yaratmamasını sağlamaya yardımcı olur.

CI/CD ile entegrasyon: SonarQube, Jenkins, GitLab CI ve Travis CI gibi sürekli entegrasyon (CI) araçlarıyla iyi bir şekilde entegre olur. Bu, ekiplerin CI/CD hattının bir parçası olarak kod analizini otomatikleştirmesine olanak tanır.

Birden Çok Dil Desteği: SonarQube, 27'den fazla programlama dilini destekleyerek birden fazla teknolojiyle çalışan ekipler için mükemmel bir uyum sağlar.

Sonarqube Neyi Analiz Eder

Sonarqube bir yazılımı test ederken aşağıdaki noktaları ele alır ve analiz eder.

Bugs: Kod içerisinde problem meydana getilebilecek hatalardır.
Vulnerability: Güvenlik açıklarını tespit eder.
Code Smell: Gereksiz yere yazılmış olan kodları tespit eder. Daha temiz ve anlaşılabilir kod yazılmasını belirtir. Çünkü bu kodlar ileride bakım zorlaştırabilir ve problem meydana getirebilir.
Duplicated Code: Aynı veya benzer kod bloklarını analiz eder.

Sonarqube Bileşenleri

Sonar Scanner: Asıl kod analizini yapan araçtır.
Sonarqube GUI: Sonar scanner tarafından analiz edilen kodu GUI aracılığıyla kullanıcıya sunar.
Veritabanı: Analiz edilen kodun saklandığı bileşendir.
Kurallar: Sonarqube bir kodu analiz ederken daha önce sağlayıcı ve topluluklar tarafından belirlenen kurallarla karşılaştırarak analiz eder.

Qaulity Profiles

Kuralları içeren profillerdir. Sonarqube tarafından varsayılan olarak desteklediği diller için profiller mevcuttur. Örneğin; C# dili için yazılmış kurallar C# için oluşturulmuş profilin içerisinde bulunur. İstenirse kendi profilimizi yazıp istenilen kuralları atayabilir ve oluşturulan projede bu profili kullan diyebiliriz.

Quality Gates
Bir projenin uyması gereken kurallar bütünü ya da bir güvenlik kapısı diyebiliriz. Örneğin; bir proje de en fazla 3 tane bugs , en fazla 2 vulnerability ya da coverage oranı %75 üzerinde ise kod geçerli olsun diyebiliyoruz. Bu değerle uymayanlar failed duruma düşmektedir.

New Code ve Overall Code Nedir ?

Sonarqube geliştiricilerin yoluna temiz kod ile ilerleyin (Clean as You Code ) felsefisini ele alır. Bundan dolayı New Code ve Overall Code kavramları bulunmaktadır.

New Code: Bir referans noktasından sonra yazılan kodlardır. Referans noktaları önceki sürüm, belirli bir tarih, belirli bir analiz ya da branch olabilir. Amaç geliştiricilerin bundan sonra ki işlemlerinde bugs, vulnerability, code smell'in ortaya çıkmamasını sağlamaktadır.

Overall Code: Eski kod + yeni code ' nın birleşimi ile oluşur ve projeye genel bir bakış yapar. Aslında overall code projenin tamamıdır. Tabi ki sadece new code ' ye bakmak yeterli değil overall code içerisinde bulunan bugs, vulnerability ... zamanla iyileştirmek gerekir.

Qaulity Gates New Code'ye bakarak analiz yapar ve kodu değerlendirir. Bu yüzden bir proje oluştururken ilk analizin passed geçecektir. Çünkü ilk analiz bir referans noktası olur. Bu analizden sonra yazılan kodlar new code olur ve eğer quality gates'e takılırsa failed olur.

Eğer sonarqube new code yaklaşımı ile çalışmasaydı eski projeler sürekli failed verirdi ve bunları düzeltmek aylar sürebilirdi. Sonarqube eski koda bakmaz yeni kodlara odaklan felsefesi ile çalışır.

Sonarqube ile Python Kodu Analiz Etmek

İstesek projemizi git repositorylerinden alabiliriz fakat ben burada test amaçlı local kullanacağım.

Burada istersek CI/CD tooluna entegre edebiliriz ama yine test olduğu için local olarak ilerliyorum.

Bundan sonra Continue diyoruz ve bizden hangi yazılım dili için işlem yapacağımızı soruyor.

Ardından bize aşağıdaki gibi bir komut verecektir.

pip install pysonar, ile uygulamayı kuracağız ve komutu çalıştırdıktan sonra GUI de sonuçları gösterecek.

pysonar \
  --sonar-host-url=http://172.35.28.154:9000 \
  --sonar-token=sqp_3adb3f55fe5d9239d5a2adb5cc53b8915d8754a7 \
  --sonar-project-key=python-project

Tabi bu şekilde kullanmak yerine Jenkins, Gitlab CI vb. uygulamalara entegre edilerek kullanılıyor. Bir sonra ki makalede Gitlab CI ile entegre etme işlemini göreceğiz.

İyi günler.

HashiCorp Vault Nedir

Suleyman — Sat, 29 Nov 2025 18:27:08 +0000

HashiCorp Vault, temel olarak erişim bilgilerimizin (username-password, API token, SSL/TLS sertifikaları ) güvenli ve merkezi bir noktadan saklayıp yönetmemizi sağlayan bir uygulamadır.

Avantajları:

Merkezi noktadan yönetim: Birden fazla uygulama aynı vault sunucuna erişim sağlayıp istenilen bilgiye erişebilir.
Erişim ve Yetkilendirme: HashiCorp vault, birçok erişim metodunu destekler(token, username-password, güvenlik sertifikaları, LDAP) ve erişim sağlayan kişinin hangi bilgiye, hangi yetkilerle(read-write) sahip olacağını tanımlayabiliriz.
Şifreleme: HashiCorp Vault, client ile vault arasında ki veri akışını güvenli bir şifreleme ile yapar.
Restful API: Vault, RestAPI protokolünü desteklediği için secret oluşturma, silme, güncelleme gibi işlemleri HTTP/HTTPS protokolü üzerinden gerçekleştirebilir.
Dinamik Secret: Static bilgi saklayabileceğimiz gibi istersek periyodik olarak güncellenen dinamil secretlarda oluşturabiliriz. Bu durum güvenlik riskini de artırmaktadır.
Günlük ve İzleme: Vault kimin hangi bilgiye eriştiğini izler ve yazar bu sayede herhangi bir veri sızıntısında hangi kaynaktan gerçekleştiğini öğrenebiliriz.
Geniş Destek: Vault dünya genelinde birçok uygulamada ile entegrede çalışabilmektedir. Kubernetes, Ansible, Terraform, RabbitMQ ... Bu durum vault'un kullanımını da arttırmaktadır.

Vault Bileşenleri

Secret Engines: Vault'un gizli bilgileri (secrets) nasıl oluşturacağını, saklayacağını veya dinamik olarak üreteceğini tanımlayan modüllerdir.

1. Statik Gizemler: K/V (Key/Value) motoru, kullanıcı tarafından girilen statik şifreleri, API anahtarlarını veya TLS sertifikalarını depolar.
2. Dinamik Gizemler: Veritabanı (Database) veya AWS motorları, bir uygulama talep ettiğinde sadece o an için geçerli, kısa ömürlü (TTL) kimlik bilgileri (dinamik şifreler, geçici AWS anahtarları vb.) oluşturur.

Auth Methods: İstemcilerin vaulta erişimlerini denetler. Örneğin; token, username-password, güvenlik sertifikaları...

Politikalar: Auth Methods ile giriş yapabilen istemcinin hangi kaynaklara ve hangi yetkilerle erişeceğini belirler.

Audit Devices: Bilgilere erişim sağlayan kişilerin günlük kayıtlarının tutulduğu bileşendir.

Depolama Arka Ucu: Gizli verilerin, yapılandırma ayarlarının, politikaların ve kimlik doğrulama verilerinin kalıcı olarak depolanmasını sağlar. Veriler burada şifreli bir şekilde saklanmaktadır.

Vault Nasıl Çalışır

Master Key: Asıl amacı verileri şifreleyen "Data Encryption Key(DEK)" şifrelemektedir. Bu key sunucu ilk kurulduğunda veya başlatıldığında oluşturulur ve memory tutulur.

Data Encryption Key(DEK): Amacı vault üzerinde oluşturulan verileri şifrelemek ve çözmektir. Depolama arka ucunda tutulur. Ama master key olmadan bir anlamı yoktur çünkü verilere sadece bu key ile erişim sağlananamaktadır.

Seal ve Unseal Kavramları Nedir

Seal: Vault'un şifreli ve erişilemez olduğu durumdur. Bu durumda herhangi bir işlem yapılamaz. Vault ilk çalıştırıldığında ve restart olduğunda bu durumdadır(Auto-unseal yok ise)

Unseal: Vault'un kilidinin açılmasıdır. Bu işlem sırasında Master Key "Shamir’s Secret Sharing" isminde bir algoritma ile birkaç parçaya bölünür. key-shares = 5, key-threshold = 3 şeklinde bir tanım 5 tane unseal key'in oluşması ama 3 tanesinin yeterli olacağını belirtir. Bu key girildikten sonra master key oluşur ve vault'un kilidir açılır.

Auto-unseal, vault sunucu her yeniden başlatıldığında seal durumuna geçeceğini için production ortamda sıkıntı çıkarabilir. Bu durumda unseal işlemi otomotik gerçekleştilir. Bu işlem HSM cihazları ile yapılabilmektedir. Yaygın kullanılan servisler AWS KMS, Azure Key Vault, Google Cloud KMS

Vault Çalışma Modları
Vault 2 farklı çalışma modu ile çalıştırabiliriz.
1- Developer Mode
2- Production Mode

1- Developer Mode: Test/Dev ortamları için kullanılabilen ve verilerin memory üzerinde tutulduğu modtur. Auto-unseal özelliği bulunmaktadır. Amaç vaultu test etmek ve öğrenmek için tasarlanmıştır.

2- Production Mode: Amacı production ortamda kullanmaktır. Veriler arka depoloma sunucunda saklanır ve her başlatıldığında veriler silinmez ve sunucu her başlatıldığında seal(mühürlenmiş) olur. Standby node olarak kurulabileceği yüksek erişilebilirlik için birkaç node kurulabilir.

Docker ile Vault Kurulumu ve Kullanımı

Ben test etmek amaçlı docker üzerinde hızlıca bir vault contaıneri ayağa kaldıracağım ve kullanacağım. Bizim ki production mode çalışacak.

version: '3.7'

services:
  vault:
    image: hashicorp/vault:latest
    container_name: vault
    ports:
      - "8200:8200" 
    volumes:
      - ./config/vault.hcl:/vault/config/config.hcl:ro 
      - vault_data:/vault/file # 
    environment:   
      VAULT_CONFIG_FILE: /vault/config/config.hcl
      VAULT_ADDR: 'http://0.0.0.0:8200'
      VAULT_SKIP_CHOWN: true
    cap_add:
    command: "server"
volumes:
  vault_data:

./config/vault.hcl

ui = true
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1 # Test/Geliştirme için TLS devre dışı
}
storage "file" {
  path = "/vault/file" # Veri kalıcı volume'e yazılacak
}

Aşağıdaki komutla ayağa kaldırabiliriz.

docker compose up -d

Temel Vault Komutları

vault --help, Kullanabileceğimiz komutları görüntüleyebiliriz.
vault login, Vault'a login olmamızı sağlar. Bizden token isteyecektir.

vault status, Vault'un durumunu öğrenebiliriz.

vault operator unseal
vault operator unseal
vault operator unseal , vault kilidini açmamızı sağlar

vault operator seal, vault'u kilitlemizi sağlar.

vault secrets enable -path=secret kv-v2, kv tipinde secret engine enable eder.

vault kv put secret/mysql username="root" password="12345", secret oluşturmamızı sağlar. kv put secret/mysql altındaki tüm verileri silip yeni verileri yazar yani override eder.

vault kv patch secret/mysql username="root" password="12345", bu üzerine yazar.

vault kv get secret/mysql, secret okumamızı sağlar.

vault kv get --format=json secret/mysql, secretlerı json formatında görüntülememizi sağlar.

Komut,İşlem Türü,Geri Alınabilir mi?,GUI Durumu
vault kv delete secret/mysql, Soft Delete , Veriler geri alınabilir.
vault kv destroy --versions=1 secret/mysql, Soft Delete (Version),Veri gider, metadata kalır.)
vault kv metadata delete secret/mysql ,Hard Delete, Veriler silinir.

Policy Olusturma

path "secret/data/mysql {
  capabilities = ["read", "list"]
}

Bu policy ile kullanıcı sadece bu pathe erişim sağlayabilir ve
Eğer mysql path'nin altında da secretlar var ise "secret/data/mysql/*" şeklinde tanımlama yapılabilir. Bu policy admin-policy.hcl dosyasına yazıp aşağıdaki komutla oluşturabiliriz.

vault policy write mysql-policy admin-policy.hcl

Oluşturulan policy ' yi aşağıdaki komutla bir token ile eşleştiririz. Bu komuttan sonra bize bir token verecektir not almayı unutmayalım.

vault token create -policy=mysql-policy

vault write auth/userpass/users/ahmet \
    password="cok-gizli-sifre" \
    policies="admin-policy"

Kubernetes ExternalSecret olarak Vault Kullanımı

Şimdi de yaygın olarak kullanılan kubernetes ve vaultu beraber kullanacağız. Burada kubernetes secretlarını vault üzerinden alacaktır.

Öncelikle externalSecrets operatörünü kurmamız gerekiyor. ExternalSecret, hassas verilerinizi Kubernetes'in kendi iç Secret nesnesinde depolamak yerine, bunları harici bir sır yönetim sisteminde (Secret Store) saklamanıza olanak tanır ve bu harici sırları otomatik olarak Kubernetes Secret nesnelerine senkronize eder.

helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets --namespace external-secrets --create-namespace

Şimdi aşağıdaki şekilde bir policy oluşturalım. Bu policy'nin aşağıdaki şekilde sadece read yetkisi olsun.

path "secret/data/mysql {
  capabilities = ["read"]
}

Bir token oluşturalım ve bu policy ile ilişkilendirelim

vault token create -policy=k8s-read

Aşağdaki şekilde bir secret oluşturalım ve bir önceki komutta aldığımız tokenı yapıştıralım. Bu token bizim vaulta login olmamızı sağlayacak.

kubectl create secret generic vault-token-secret \
    --from-literal=token=<TOKEN> \
    -n vault-ns

Aşağıdaki YAML ile bir SecretStore oluşturuyoruz. SecretStore bizim hangi sisteme bağlanacağımı ve hangi verilere ulaşacağımızı belirler.

cat <<EOF | kubectl apply -f -
apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: vault-backend
  namespace: vault-ns
spec:
  provider:
    vault:
      server: "http://172.35.28.80:8200" # Vault IP Adresi
      path: "secret"  # Bu policy de belirttiğim secret engine ismidir.
      version: v2
      auth:
        tokenSecretRef:
          name: vault-token-secret #Bir önceki adımda oluşturulan secret 
          key: token              #Secret içindeki key adı
EOF

Aşağıdaki komutla kontrol ettiğimizde STATUS=Valid ise erişim sağlanmıştır.

root@master:~/vault# kubectl get secretstore -n vault-ns
NAME            AGE   STATUS   CAPABILITIES   READY
vault-backend   35s   Valid    ReadWrite      True

Sıra artık bu secretları kullanmakta. Aşağıdaki YAML manifesti ile ExternalSecret oluşturuyoruz ve hangi değerleri kullanacaksak belirliyoruz.

cat <<EOF | kubectl apply -f -
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: mysql-secret-vault
  namespace: vault-ns
spec:
  refreshInterval: 1m
  secretStoreRef:
    name: vault-backend #SecretStore ismi
    kind: SecretStore
  target:
    name: mysql-secret # Kubernetes'te oluşacak secret adı
  data:
  - secretKey: MYSQL_ROOT_PASSWORD
    remoteRef:
      key: secret/data/mysql # Vault'taki tam yol
      property: mysql_root_pass  #Bu değerler vault üzerinde tanımlı olanlar
  - secretKey: MYSQL_USERNAME
    remoteRef:
      key: secret/data/mysql
      property: mysql_user
  - secretKey: MYSQL_PASSWORD
    remoteRef:
      key: secret/data/mysql 
      property: mysql_pass
  - secretKey: MYSQL_DATABASE
    remoteRef:
      key: secret/data/mysql
      property: mysql_db
EOF

Aşağıdaki komutlarla doğrulama işlemlerini yaptığımızda secretların oluştuğunu görüntüleyebiliriz.

root@master:~/vault# kubectl get externalsecret -n vault-ns
NAME                 STORETYPE     STORE           REFRESH INTERVAL   STATUS         READY
mysql-secret-vault   SecretStore   vault-backend   1m0s               SecretSynced   True
root@master:~/vault# kubectl get secret -n vault-ns
NAME                 TYPE     DATA   AGE
mysql-secret         Opaque   4      14s
vault-token-secret   Opaque   1      10m
root@master:~/vault# kubectl get secret mysql-secret -n vault-ns -oyaml
apiVersion: v1
data:
  MYSQL_DATABASE: c3VsZXltYW5EYXRhYmFzZQ==
  MYSQL_PASSWORD: YWhtZXQ=
  MYSQL_ROOT_PASSWORD: U3VsZXltYW4yMDI1ISE=
  MYSQL_USERNAME: c3VsZXltYW4=

Bir sonraki makalede görüşmek üzere iyi günler.

AzureDevOps Pipeline

Suleyman — Sat, 08 Nov 2025 15:24:49 +0000

Merhaba , bu makalemizde önceki makalemizin devamı niteliğindedir.

Bu makalede Azure DevOps üzerinde Pipeline kullanımına değineceğiz ve basit bir örnek gerçekleştireceğiz. Azure pipeline CI/CD (Continues Integration ve Continues Deployment) süreçlerimizi oluşturmamızı sağlayan Azure DevOps öğesidir. Hem agile hem de scrum metedolojilerini destekler. Alternatifleri Jenkins, Gitlab CI, Github Actions vb. uygulamaladır.

Azure Pipeline CI/CD süreçlerini yapabilmek için agentlara ihtiyaç duyar. Jenkins'te slave, gitlab CI ' da ise runner mantığında çalışır. Bu agentlar hem microsoft tarafından sağlanabilirken istersek kendi sunucularımızda bu agentları kurabiliriz.

Azure pipeline azure araçlarına entegre olduğu için oldukça kullanışlı ve işlerimizi kolaylaştırmaktadır. Bununla birkaç dakika da uygulamalarımızı Azure üzerinde deploy edebilmemiz mümkündür. Aşağıdaki pipeline ile yapılabilecek bir örnek görebiliriz.

Bir pipeline oluşturduğumuzda , repository branch içerisinde "azure-pipelines.yml" isminde bir dosya oluşturulur ve pipeline içeriği bu dosyaya yazılır. Gitlab CI da bu mantıkla çalışmaktadır.

Azure DevOps pipeline içerisinde kullanabileceğimiz hiyerarşi aşağıdaki gibidir.

Stages > Stage > Jobs > Job > Steps
Stepslerin içerisinde de scriptler, tasklar kullanılır. Aşağıda bununla ilgili bir örneği görebiliriz.

trigger:
- main

pool:
  name: Self-Hosted Agent Pool


stages:
- stage: BirinciStage
  jobs:
  - job: BirinciStageBirinciJob
    steps:
    - script: echo "BirinciStageBirinciJob Steps Script"
      displayName: BirinciStageBirinciJob

  - job: BirinciStageIkinciJob
    steps:
    - script: echo "BirinciStageIkınciJob Steps Script"
      displayName: BirinciStageBirinciJob


- stage: IkinciStage
  jobs:
  - job: IkinciStageBirinciJob
    steps:
    - script: echo "IkinciStageBirinciJob Steps Script"
      displayName: IkinciStageBirinciJob

  - job: IkinciStageIkinciJob
    steps:
    - script: echo "IkinciStageIkinciJob Steps Script" 
      displayName: IkinciStageIkinciJob

Bu pipeline çalıştırdığımızda aşağıdaki şekilde bir sonuç alacağız.

Tabiki bu hiyerarşiyi kullanmadan da oluşturulan pipeline çalışır. Örneğin; sadece steps adımını kullanılarakta pipeline yazılabilir. Bu kullanım tamamen yapınıza göre değişkenlik göstermektedir. Büyük yapılarda hiyerarşiye uymak pipeline nin okumasını kolaylaştıracaktır.
Ya da hiyerarşiyi jobs kısmından da başlatarak yazabiliriz.

jobs:
- job: BirinciJob
  steps:
  - script: echo "BirincJob Steps Script"
    displayName: BirincJob


- job: IkinciJob
  steps:
  - script: echo "IkinciJob Steps Script"
    displayName: IkinciJob

Şimdi bir Dockerfile üzerinden image oluşturup bunu DockerHub'a push eden bir pipeline yazalım ve bunu Azure Web Apps üzerinde deploy eden pipeline yazacağız.

Öncelikle agent'ı kendi sunucuma kuracağım.
Bu işlemlerden önce bir personel access token oluşturalım çünkü agentı konfigure ederken isteyecektir.

Sağ üst köşede bulunan User Settings > Personel Access Token > New Token ile oluşturuyoz ve bir isim veriyoruz. Yetki olarakta Agents Pool > Read and Manage seçmemiz yeterlidir.

Vereceği tokenı bir yere not alınız.

Agent kurulumuna geçebiliriz.

Project Settings > Agent Pools > New Pool diyerek bir pool oluşturuyorum. Bu pool birden fazla agentı barındırabilir. Ayarları aşağıdaki şekilde yaptıktan sonra oluşturuyoruz.

Ardından oluşturduğumuz poola tıklayıp agent sekmesine geliyoruz ve "New Agent"'a tıklıyoruz. Burada microsoft bize agentın indirme linkini ve hangi işletim sisteminde nasıl kurulacağını açıklamış. Ben linux seçtim ve microsoftunda belirttiği aşağıdaki komutları çalıştırdım.

wget https://download.agent.dev.azure.com/agent/4.264.2/vsts-agent-linux-x64-4.264.2.tar.gz
tar xvfz vsts-agent-linux-x64-4.264.2.tar.gz
./config.sh

config.sh scriptini çalıştırdıktan sonra bizim hangi organizasyona ve oluşturduğumuz agent pool'un ismini ve bu agent için bir isim girmemiz gerekmektedir.

Server URL: https://dev.azure.com/organizasyon_ismi

Enter (Y/N) Accept the Team Explorer Everywhere license agreement now? (press enter for N) > Y

>> Connect:

Enter server URL > https://dev.azure.com/akturkbilisim
Enter authentication type (press enter for PAT) > PAT
Enter personal access token > ************************************************************************************
Connecting to server ...

>> Register Agent:

Enter agent pool (press enter for default) > MySelfHostedAgent
Enter agent name (press enter for ceph-node) > pipeline-agent
Scanning for tool capabilities.
Connecting to the server.
Successfully added the agent
Testing agent connection.
Enter work folder (press enter for _work) >
2025-11-08 18:08:18Z: Settings Saved.

Bu işlemlerden sonra AzureDevOps üzerinde "Agent Pools > Agent" sekmesinden kontrol ettiğimizde durumun offline olduğunu görebiliriz. Bunun için

./run.sh scriptini çalıştırıyoruz ama bu bize script ön planda çalışmaktadır yani terminal session kapandığında agent servisi duracaktır. İstersek bu agent servisini bir systemd servisine dönüştürebiliriz. Microsoft bunun içinde svc.sh isminde bir script oluşturmuş.

./svc.sh install, ile systemd servisi haline gelecektir ve aşağıdaki komutla servisi başlatıyoruz. Bu işlemden sonra agent online durumua gelecektir.

systemctl restart vsts.agent.akturkbilisim.MySelfHostedAgent.pipeline\x2dagent.service

Benim kodlarım Github üzerinde olduğu için Github hesabımı da entegre edeceğim. "Project Settings > Github Connection > New Connection" sekmesinden hesabımı bağlayacağım. Ben github hesabımıda "Personel Access Token" ile bağlayacağım için github üzerinde de oluşturmam ve yetkilendirmem gerekiyor. Bunu burada anlatmayacağım.

Artık pipeline yazma aşamasına gelebiliriz.

Pipeline sekmesinden New Pipeline diyerek oluşturuyoruz bize bu pipelinenin neresi ile entegre olacağını söylüyor ben Github ile ilerleyip repository'imi seçiyorum .

Ardından bize hazır olarak kullanabileceğimiz şablonlar sunuyor , ilk kez olacağı için "Stater Pipeline" seçebiliriz eğer pipeline dosyamız repositoryimizde var ise "Select an existing YAML file" seçeneğini seçebiliriz. Zaten bu templateleri daha sonradan da seçebiliriz.

trigger:
- main

pool:
  name: MySelfHostedAgent

variables:
 image: suleymanakturk/azurepipeline
 imageTag: $(build.buildID)

jobs:
- job: BuildImage
  steps:
  - task: Docker@2
    inputs:
      command: 'build'
      Dockerfile: '**/Dockerfile'
      repository: $(image)
      tags: |
        latest
        $(imageTag)
  displayName: Image Build 

- job:  PushImage
  steps:
  - task: Docker@2
    inputs:
      containerRegistry: 'DockerHubService'
      repository: $(image)
      command: 'push'
      tags: |
        latest
        $(imageTag)
  dependsOn: BuildImage
  displayName: Image Push Registry

- job: DeployAzureAppsServices
  steps:
  - task: AzureWebAppContainer@1
    inputs:
      azureSubscription: 'Azure subscription 1'
      appName:  azurePipelineWebApp
      containers: $(image):latest
  displayName: Deploy Web Apps
  dependsOn: PushImage

Trigger: Pipeline nın ne ile tetikleneceğini belirtir. Burada main branche commit geldiğinde tetiklenecektir.

Pool: Bu pipelinenin üzerinde çalışacağı agent pooldur. Biz oluşturduğumuz poolu verdik.

Ben hem build hem de push için ayrı job oluşturdum istersek ikisini aynı job içerisinde de gerçekleştirebiliriz.

containerRegistry: Container registryi Project Settings > Service Connection > Docker Registry diyerek oluşturuyoruz ve pipeline içerisinde kullanıyoruz.

DisplayName: Pipeline adımlarının istediğimiz gibi isimlendirmemizi sağlar. Aşağıdaki gibi görünecektir.

**WebApps **kısmı için öncelikle "Webapp for Container" oluşturmamız gerekiyor. Bir kere oluşturup her pipeline de image güncellenecektir. Bu yüzden manuel oluşturacağız.

Azure GUI üzerinden "App Services" servisine tıklayıp create "Web App" dedikten sonra publish metodu container seçiyoruz ve container sekmesinden image aşağıdaki görselde göründüğü gibi yapıyoruz. Burada örnek olduğu için image public ama production da private ise size username/password soracaktır.

Burada image tag'ini latest yaptık çünkü pipeline her çalıştığında yeni imageyi latest tag'i ile etiketleyecektir.

Wepapp oluşturduğumuzda erişim sağlayabilmemiz için bir URL verecektir. Bu URL üzerinden erişim sağlayabiliriz. Bizim webapp paketimiz basic olduğu için kendimize ait domain ekleyemiyoruz. Ama daha üst paketlerde kişisel domain ve SSL sertifikamızı kullanabiliriz. Aşağıdaki gibi appname + rastgele bir değer + region şeklinde bir URL oluşmaktadır.

azurepipelinewebapp-dpe0a7vxh9f1dub6.italynorth-01.azurewebsites.net

Azure Pipeline ' nin en güzel yanlarından bir tanesi kullanmak istediğimiz ürün ile ilgili hazır şablonlar vermesi ve bizim bu alanları tamamladıktan sonra pipeline içerisine kendisinin eklemesidir.

Örneğin; Bir uygulamayı kubernetes üzerine deploy etmek istediğimizde önceden hazırlanmış "Deploy to Kubernetes" templateyi kullanarak ve gerekli alanları doldurup Add dedikten sonra pipeline içerisine eklenecektir.

depl

Bir sonraki makalede görüşmek üzere...

Azure DevOps Nedir ?

Suleyman — Sat, 08 Nov 2025 15:03:26 +0000

Azure Devops Microsoft firmasının sağlamış olduğu ve DevOps süreçlerini yönetmemizi sağlayan bir hizmettir. Azure DevOps, sürekli teslimatı etkinleştirmek için kaynak kontrolü, oluşturma, test etme ve yayınlama süreçlerini optimize eder.

Azure DevOps kendi içerisinde aşağıdaki kaynakları barındırmaktadır.

Boards: İş planlama ve takip sistemidir. Ekiplerin görevlerini oluşturma, planlama ve raporlama işlemlerininin yapılmasını sağlar.

Repos: Git veya Team Foundation Version Control (TFVC) tabanlı kaynak kod yönetim sistemidir. Kod depolarını ve versiyon kontrolünü sağlar. Alternatifleri Github , Gitlab, Bitbucket ' tır.

Pipeline: CI/CD (Continuous Integration / Continuous Delivery) süreçlerini yönetir. Kodun otomatik olarak derlenip test edilmesini ve hedef ortama dağıtılmasını sağlar. Alternatifleri Jenkins, Gitlab CI, Github Actions vb. araçlardır.

Test Plans: Manuel ve otomatik testlerin planlanması, yürütülmesi ve raporlanması için kullanılır.

Azure Artifacts: Paketlerin depolanmasını ve paylaşılmasını sağlar. Dahili paket yönetimi yapabilirsin.

Azure DevOps hem bulut üzerinde hem de on-prem sunucularınıza kurararak kullanmaya başlayabilirsiniz. Azure DevOps kullanırken önce bir organizasyon , organizasyon içerisine de bir veya birden fazla proje oluşturulabilmektedir. Bu projeler içerisinde de kullanıcılar veya takımlar bulunmaktadır. Her proje kendi Boards, Repos, Pipeline, Test Plan ve Artifacts ' sahiptir.

Organization: AkturkBilisim
├── Project: E-Ticaret Platformu
│ ├── Team: Frontend Ekibi
│ ├── Team: Backend Ekibi
│ └── Team: QA Ekibi
└── Project: Mobil Uygulama
├── Team: iOS Ekibi
└── Team: Android Ekibi

AzureDevOps üzerinde kendi git repository ' i kullanabileceğimiz gibi Github, Bitbucket uygulamalarını da entegre ederek çalışabilmemiz mümkündür.

Sonraki makalelerimizde Boards ve Pipeline konularına değineceğim.

İyi günler.

Prometheus ve Grafana İle NGINX Ingress Monitoring

Suleyman — Sun, 31 Aug 2025 12:39:06 +0000

Merhaba bu makalede kubernetes üzerinde yaygın olarak kullanılan prometheus stack ve nginx ingress controller üzerinde monitoring işleminin nasıl yapılacağını göreceğiz.

Öncelikle aşağıdaki komutla prometheus-stack kurulumunu gerçekleştirelim.

Kubernetes Üzerinde RBAC ile Kullanıcı Olusturma ve Yetkilendirme

Suleyman — Sat, 30 Aug 2025 17:47:36 +0000

Kubernetes'te RBAC nedir?

Rol Tabanlı Erişim Kontrolü (RBAC) in Kubernetes, kümenizdeki kaynaklara erişimi düzenlemek için kullanılan bir yöntemdir. RBAC, rolleri belirli izinlerle tanımlayarak ve bu rolleri kullanıcılara atayarak, kullanıcıların en az ayrıcalık ilkesine bağlı kalarak yalnızca ihtiyaç duydukları kaynaklara erişmelerini sağlar.

RBAC için 3 önemli bileşeni vardır;

Subject: Kullanıcılar, gruplar veya service accountları temsil eder.

Resource: Üzerinde yetkilendirme yapılacak kubernetes api objelerini temsil eder. (Pods, services, configMap etc)

Verbs: Yapılacak işlemi temsil eder.

Bu işlemler için aşağıdaki 2 kavramı birbirinden ayırmamız gerekmektedir.

Authentication: Kubernetes clusterımız üzerinde kimlik doğrulama yapabilmeyi sağlar.
Authorization: Kimlik doğrulama işlemi yapıldıktan sonra cluster üzerinde hangi işlemleri yapabileceğini belirler.

Kubernetes üzerinde bir kullanıcı oluşturursak varsayılan olarak hiçbir işlem yapamaz. Kullanıcı oluşturduktan sonra RBAC ile yetkilendirme işlemlerini gerçekleştirmemiz gerekir.

Kuberneteste kullanıcı oluşturma işlemini x509 SSL Sertifikası ile yapacağız.

Kullanıcı Oluşturma İşlemleri

mkdir RBAC && cd RBAC

Aşağıdaki komutla bir private key oluşturacağız.

openssl genrsa -out suleymanakturk.key 2048

Aşağıdaki komutla SSL sertifikamızı talep edebilmek için CSR dosyası oluşturacağız. Benim kullanıcım suleymanakturk isminde olacak. Organizasyon olarak Developer isminde bir organizasyon oluşturdum

openssl req -new -key suleymanakturk.key -out suleymanakturk.csr -subj /CN=suleymanakturk/O=Developer

Bu işlemlerden sonra CSR dosyamızı kubernetes API ya göndermemiz gerekiyor. Aşağıdaki komutla CSR dosyamızı base64 formatına çevirip içeriğini alıyoruz.

cat suleymanakturk.csr | base64 | tr -d '\n'

Çıkan sonucu aşağıdaki bulunan request yerine yazıyoruz ve komutu çalıştırıyoruz.

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: suleymanakturk
spec:
  groups:
  - system:authenticated
  request:  "CSR"
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
EOF

Bu işlemlerden sonra aşağıdaki komutla csr dosyamızın oluşup oluşmadığını ve durumunu görüntüleyeceğiz.

Karşımıza çıkan sonuca baktığımızda en sağ tarafta CONDITION ile bu CSR dosyamızın durumunu görüntülüyoruz ve bu CSR dosyamızının kubernetes tarafından onaylanmadığı görülmektedir.

kubectl get csr

Aşağıdaki komutla sertifikamızı onaylıyoruz ve artık durumunun "Pending" değil "Approved,Issued" olduğunu görebiliriz.

kubectl certificate approve suleymanakturk

Bu işlemlerden sonra sertifikamızı dışarıya alacağız

kubectl get csr suleymanakturk -o jsonpath='{.status.certificate}' | base64 --decode > suleymanakturk.crt

Bu işlemlerden sonra kullanıcı oluşturma (Authentication) işlemleri tamamlanmıştır.

Oluşturmuş olduğumuz crt ve key dosyası ile kubernetes clusterımızın ca dosyasını yeni kullanıcımıza vereceğiz. Kubernetes ca dosyası varsayılan olarak aşağıdaki konumda bulunmaktadır.

/etc/kubernetes/pki/ca.cert

Yeni kullanıcımız bu dosyaları aldıktan sonra aşağıdaki komutla kubeconfig dosyası oluşturacaktır. Burada kullanıcının kubeconfig dosyası oluşturacağı sunucu üzerinde kubectl toolu ve kubernetes clusterına 6443 portu üzerinden erişmesi yeterlidir.

kubectl config set-credentials suleymanakturk \
  --client-certificate=suleymanakturk.crt \
  --client-key=suleymanakturk.key \
  --kubeconfig=suleymanakturk.kubeconfig

kubectl config set-cluster my-cluster \
  --server=https://172.35.28.10:6443 \
  --certificate-authority=/root/ca.crt \
  --embed-certs=true \
  --kubeconfig=suleymanakturk.kubeconfig

kubectl config set-context suleymanakturk@my-cluster \
  --cluster=my-cluster \
  --user=suleymanakturk \
  --kubeconfig=suleymanakturk.kubeconfig

kubectl config use-context suleymanakturk@my-cluster \
  --kubeconfig=suleymanakturk.kubeconfig

Kullanıcı aşağıdaki komutla , Kubernetes API ya istek attığında 403 hatası alacaktır çünkü herhangi bir authorization işlemi yapmadık.

kubectl --kubeconfig=suleymanakturk.kubeconfig get pods

Kubernetes Authorization işlemi aşağıdaki 4 obje ile yapılabilmektedir.

Role,
RoleBinding
ClusterRole
ClusterRoleBinding

Role namespace bazlı erişim izni verirken, ClusterRole ise tüm cluster bazında verir. RoleBindg ve ClusterRoleBinding ise oluşturulan Role ve ClusterRole objelerinin istenilen user, group, serviceaccount vb. objelere atanmasını sağlamaktadır.

Öncelikle bir Role ve RoleBinding oluşturalım. Bu role default namespacesinde verbs ile belirtilen işlemleri yapabilecektir.

ApiGroups: Hangi kubernetes API ile iletişime geçebileceğini belirtir. Boş bırakılırsa v1 API geçerli olur. Örneğin; deployment objeleri apps/v1 API grubunda olduğu için resource kısmında yazılırsa bile çalışmayacaktır.

Resources: Hangi kubernetes objeleri üzerinde işlem yapılacağını belirtir.

Verbs: Objeler üzerinde hangi işlemlerin yapılabileceğini belirtir.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: developers-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "create"]

RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-role-binding
  namespace: default
subjects:
- kind: User
  name: suleymanakturk
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developers-role
  apiGroup: rbac.authorization.k8s.io

ClusterRole

apiVersion: v1
kind: ClusterRole
metadata:
  name: my-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create"]

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-clusterrole-binding
subjects:
- kind: User
  name: suleymanakturk 
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: my-clusterrole
  apiGroup: rbac.authorization.k8s.io

ClusterRole ile aşağıdaki komutla istediğimiz namespace tanımlanan yetkilerle işlem yapabiliriz.

kubectl --kubeconfig=suleymanakturk.kubeconfig run testpod --image=nginx -n test-ns
Her komut çalıştırdığımızda --kubeconfig=suleymanakturk.kubeconfig şeklinde parametre eklemek istemiyorsak bu dosyayı varsayılan config yaparsak bu sorunu çözebiliriz.

Aşağıdaki komutla kubeconfig dosyamızı varsayılan config dosyayı yapıyoruz.

cp /root/suleymanakturk.kubeconfig ~/.kube/config

Bir sonraki makalede görüşmek üzere...

Jenkins ve ArgoCD CI/CD Uygulaması

Suleyman — Thu, 07 Aug 2025 21:55:31 +0000

Merhaba,

Bu makalede aşağıdaki adımları ve toolları kullanarak bir CI/CD projesi gerçekleştireceğiz. Dosyalara aşağıdaki Github adresimden ulaşabilirsiniz.

Burada 2 tane git repository kullanacağım.

Repo: Developerın değişiklikleri push ettiği repository
Repo: ArgoCD ile sync olacak repository.

Proje şu şekilde çalışacak. Developer commit yaptığında build edilen image kubernetes manifest file üzerinde değişecek ve bu manifest file yi 2. repoya pushlayacak ve ArgoCD güncel olan 2. repository ile sync olacaktır.

 1- Kubernetes Üzerine Jenkins Kurulumu
 2. Ngrok ile webhook servisini dışarı açma
 3- Jenkins Konfigurasyonu ve Github ile Webhook Konfigurasyonu
 4. Jenkins Üzerinde Gerekli Credentials Bilgilerinin Tanımlanması
 5- Jenkins Pipeline Yazılacak. Pipeline üzerinde aşağıdaki adımlar gerçekleştirilecektir.
    a. Docker ile build et ve Docker Huba push et
    c. Kubernetes üzerinde çalıştır
 6- Projeyi Githuba Push Et
 7- ArgoCD ile Gitops

Gerekli Toollar
Docker
Kubernetes
Jenkins
Github
ArgoCD
Ngrok
``

Kubernetes Üzerinde Jenkins Kurulumu

Jenkins in resmi sitesinden gerekli adımları izleyerek kurulum sağlayabilir ve arayüze erişim sağlayabiliriz.

https://www.jenkins.io/doc/book/installing/kubernetes/

Kurulum adımından sonra aşağıdaki pluginleri yükleyelim.

Github
Github API
Docker Plugin
Docker Pipeline
Kubernetes
Kubernetes CLI Plugin
Kubernetes Credentials

Ngrook ile Jenkins Üzerinde Webhook Servisini Dışarıya Açma

Ngrok, localde çalışan uygulamaları tünelleyerek dış erişime açmamızı sağlayan bir reverse proxy'dir. Bunun aşağıdaki linkten ngrok kurulum dosyamızı indiriyoruz ve siteye kayıt oluyoruz.

Sol taraftan "Your Authtoken" sekmesinden yeni bir token oluşturuyoruz. Ardından bu jenkins arayüzüne erişebilen bir sunucudan bu servisi açacağız. Benim ortamında bir windows var ve ben bu sunucu üzerinden açacağım.

İndirmiş olduğumuz exe dosyası çalıştırıp aşağıdaki komutları çalıştırıyoruz.

ngrok config add-authtoken $YOUR_AUTHTOKEN ngrok http http://172.35.28.152:8080 ,
Bu işlemden sonra karşımıza aşağıdaki şekilde bir ekran çıkması gerekmektedir. Burada 172.35.28.152 benim jenkinse eriştiğim URL ve porttur.

https://ngrok.com/downloads/windows

Jenkins Konfigurasyonu ve Github ile Webhook Konfigurasyonu

Webhook ile repositorye commit attığımızda pipelinenin otomotik olarak çalışmasını sağlayacağız. Bunun için 3. adımda jenkins sunucumuzun webhook servisini dış erişime açmamız gerekmektedir.

Şimdi developerın değişiklikleri push ettiği repositorye geliyorum ve yukarıdan setting gelip sol taraftan webhook sekmesine tıklıyorum.

Bu işlemlerden sonra ngrok ' un bize verdiği URL'i ve sonuna /github-webhook/ şeklinde URL'i tamamlıyoruz. Diğer ayarlamaları aşağıdaki gibi düzenledikten sonra buradan işimiz bitiyor.

4. Jenkins Üzerinde Gerekli Credentials Bilgilerinin Tanımlanması

Pipeline içerisinde kullacağımız aşağıdaki credentials bilgilerini tanımlayacağız.

a. Docker HUB
b. Repository'e push edebilmesi için Github Credentials
c. Kubernetes config dosyasının credentials
d. Docker yüklü node'nin credentials bilgileri

a. *Docker HUB Credentials Bilgilerinin Eklenmesi

Docker HUB hesabımıza giriş yaptıktan sonra aşağıdaki linkten bir personel access token oluşturuyoruz ve read&write yetkisi veriyoruz. Güvenlik için expire date belirleyebiliriz.

Ardından Jenkins üzerinde Manage Jenkins > Credentials > System(global) > Global Credentials > Add Credentials ile credentials bilgilerimizi giriyoruz. Password yerine verilen tokenı girdikten sonra ID yerine pipeline üzerinde kullanacağımız ismi giriyoruz.

b. Repository'e push edebilmesi için Github Credentials

Github üzerinde sağ üst tarafta bulunan profile tıkladıktan sonra Setting > Developer Settings > Personel Access Token > Fine-grained token > Create New Token ile yeni bir token oluşturuyoruz. Test ortamında tüm repositoryler ve yetkiler olabilir ama production ortamda sadece belirli repository ve minimum yetkiler ile tanımlamalıyız.

Bu tokenı kopyalıyoruz ve DockerHUB credentials tanımı ile aynı şekilde tanımlıyoruz.

c. Kubernetes config dosyasının credentials

Kubernetes clusterımızın config dosyasını kaydediyoruz ve Jenkins > Credentials > System(global) > Global Credentials > Add Credentials sekmesinden bu sefer credentials tipini secret file olarak tanımlıyoruz ve kaydettiğimiz dosyayı import ediyoruz. Bu dosya genel olarak /root./kube/ altında config ismindedir.

d. Docker yüklü node'nin credentials bilgileri

a ve b adımında olduğu gibi "Username ve Password" tipinde docker sunucumuzun erişim bilgilerini tanımlıyoruz. Bu adımdan sonra Manage Jenkins > Nodes > New Node ardından isim ve Type değerini "Permanent Agent" seçip ilerliyoruz ve ben aşağıdaki gibi docker sunucumun bilgileri tanımlıyorum. Önemli olaran host ve tanımladığımız credentials bilgilerini doğru seçmemiz yeterlidir. Bu işlemden sonra node üzerine tıklayıp launch agent diyoruz.

Düzeltme: Biz node ye kullanıcı adı ve parola ile bağlandığımız için "Host Key Verification Strategy" seçeneğini "Non Verifying Verification Strategy" yapacağız. Ama daha güvenli olması açısından key ile bağlantısı sağlanabilir.

5. Jenkins Üzerinde Pipeline Yazılması

Jenkins anasayfasında sol taraftan New Item diyoruz ve isim verdikten sonra tipini pipeline seçiyoruz. Ardından commit attığımızda çalışabilmesi için aşağıdaki seçeneği seçiyoruz ve aşağıdaki pipeline yi yapıştıyoruz. Repo, credentials, node vb. bunları kendinize göre düzenleyebilirsiniz. Ben bu pipeline üzerinde kubernetese deploy etmesi için stage yazdım ama aslında o işi ArgoCD ye bırakmamız gerekmektedir.

` pipeline { agent { label 'docker-nodes' } environment { image_name="suleymanakturk:v${BUILD_NUMBER}" } stages { stage('Checkout From Git') { steps { git branch: 'main', credentialsId: 'Github', url: 'https://github.com/suleymanakturk/Developer-Push-Repo.git' } } stage('Build Docker Image') { steps { sh "docker build -t ${image_name} ." } } stage('Push Image to DockerHub') { steps { script { withDockerRegistry(credentialsId: 'Dockerhub', toolName: 'docker') { sh "docker tag ${image_name} suleymanakturk/${image_name}" sh "docker push suleymanakturk/${image_name}" } } } } stage('Update Deployment File') { steps { sh """ mv ./kubernetes_file/* . yq -i '.spec.template.spec.containers[0].image = "suleymanakturk/"+env(image_name)' deployment.yaml find . -mindepth 1 -path ./.git -prune -o ! -name '*.yaml' -exec rm -rf {} + """ } } stage('Commit & Push Deployment YAML to Repo2') { steps { script { sh """ git config --global user.email "akturksuleyman47@gmail.com" git config --global user.name "Suleyman AKTURK" git add . git diff --cached --quiet || git commit -m "Jenkins Pipeline Update Deployment File | image: ${image_name}" """ withCredentials([usernamePassword(credentialsId: 'Github', usernameVariable: 'GIT_USERNAME', passwordVariable: 'GIT_PASSWORD')]) { sh "git push --force https://${GIT_USERNAME}:${GIT_PASSWORD}@github.com/suleymanakturk/ArgoCD-Repo.git main" } } } } stage('Deploy to Kubernetes Cluster') { steps { withKubeConfig( caCertificate: '', clusterName: '', contextName: '', credentialsId: 'kubernetes-credentals', namespace: '', restrictKubeConfigAccess: false, serverUrl: 'https://172.35.28.10:6443' ) { sh "kubectl apply -f deployment.yaml" } } } } } `

Githuba Push Edilmesi

index.html isimli bir dosyam var ve developer bunu repository e push ettiğinde tüm adımlar sırasıyla çalışacak.

ArgOCD ile Gitops

Eğer repository public değilse öncelikle github bilgilerimizi argocd üzerinde tanımlamamız gerekmektedir. Ama public olduğunu varsayaraktan ilerliyorum, sonraki makalelerde argocd ile ilgili daha detaylı bilgi verebilirim.

Eğer private ise Setting > Repository > üzerinden github bilgilerimizi tanımlıyoruz.

Applications > New App ile yeni bir applications oluşturuyoruz , basit olarak aşağıdaki şekilde tanımlanabilir.

ArgoCD ile Github Repomuz SYNC olduğunda aşağıdaki gibi bir görüntü karşımıza çıkacaktır.

Tabi burada ArgoCD üzerinde application oluşturmayı manuel yaptık, istersek bu applications için bir kubernetes manifest dosyası yazıp pipeline üzerinde onu da deploy edebiliriz.

Bir sonraki makalede görüşmek üzere, kendinize iyi bakın.

Terraform Local Values and Output

Suleyman — Tue, 27 May 2025 20:31:21 +0000

Merhaba,

Bu makalede terraform üzerinde local value ve output kullanımını ve ne işe yaradığını göreceğiz.

Local value'ler bir terraform dosyası içerisindeki bir değerin birden fazla yerde kullanılması gerektiğinde tanımlanan ve kullanılmaktadır.

Output ise oluşturmuş olduğumuz bir nesne hakkında bilgi almak istediğimizde kullanılmaktadır. Output diğer yazılım dillerinde ki ekrana yazdırma görevi görür. Python'daki printf, C# 'ta Console.WriteLine() gibi.

Terraform dosyamızın içerisine aşağıdaki gibi 2 adet local değişkeni tanımlıyoruz.

locals {
   appName = "testapps"
   namespace = "testnamespace"
}

Kubernetes üzerinde bir service ve bir pod oluşturacağım ve bunların isimlerini ve namespace lerini bu değişkenler üzerinden alacağım. Kullanım şekli "local.degiskenismi" kullanılmaktadır. Bu sayede sadece local değişkenlerinin değerini değiştirerek farklı bir isimde ve namespace üzerinde bu objeleri oluşturabilirim.

locals {
   appName = "testapps"
   namespace = "testnamespace"
}
resource "kubernetes_service" "example" {
  metadata {
    name = "terraform-example"
    namespace = local.namespace

  }
  spec {
    selector = {
      app = local.appName
    }
    session_affinity = "ClientIP"
    port {
      port        = 8080
      target_port = 80
    }
    type = "LoadBalancer"
  }
}

resource "kubernetes_pod" "example" {
  metadata {
    name = "terraform-example"
    namespace = local.namespace
    labels = {
      app = local.appName
    }
  }

  spec {
    container {
      image = "nginx"
      name  = local.appName
    }
  }

Örneğin; farklı bir örnekte sunucunun oluşturulacağı lokasyonu local değişkenlerden alabiliriz. Bu sayede bu değişkenin değerini değiştirerek farklı bir lokasyonda oluşturabiliriz. Burada bir noktada kullanıldığı görülmekte fakat bunu belki 5-6 yerde kullanabiliriz. Böyle olunca bize kolaylık sağlamaktadır.

locals {
  location = "australiaeast"
}

resource "azurerm_resource_group" "this" {
  name     = "rg-mom-spells"
  location = local.location
}

Aşağıdaki şekilde de bir kullanım sağlayabiliriz. Bir terraform resourcenin değerini farklı bir resource'den alabiliriz. Örneğin; aşağıdaki service nin selector değerini pod üzerinde tanımlanan label değerinden almışız. Bu kullanım da yaygın bir kullanımdır.

resource "kubernetes_service" "example" {
  metadata {
    name = "terraform-example"
  }
  spec {
    selector = {
      app = kubernetes_pod.example.metadata.0.labels.app
    }
    session_affinity = "ClientIP"
    port {
      port        = 8080
      target_port = 80
    }

    type = "LoadBalancer"
  }
}

resource "kubernetes_pod" "example" {
  metadata {
    name = "terraform-example"
    labels = {
      app = "MyApp"
    }
  }

  spec {
    container {
      image = "nginx:1.21.6"
      name  = "test"
    }
  }
}

Şimdi output'a bakalım. Örneğin; load balancer tipinde bir servis oluşturduk ve bu load balancerın değerini bu objeler oluştuktan sonra görmek istiyoruz. Kullanım şekli "terraform_resource.resource_name.parametreler" şeklindedir. kubernetes_service ve example yukarıda ki örnekte oluşturduğumuz servis objesidir. Ondan sonra parametrelerde objeye göre değişmektedir.

kubernetes_service.example.status[0].load_balancer[0].ingress[0].ip

Output objesi aşağıdaki şekilde oluşturulmaktadır.


output "LoadBalancer_IP" {
    value = "Bu servisin Load Balancer IP Adresi =  {kubernetes_service.example.status[0].load_balancer[0].ingress[0].ip}"
}

Bu şekilde kullanım bize aşağıdaki şekilde bir çıktı vermektedir.

Bu servisin Load Balancer IP Adresi = 192.168.1.163

Mesela istersek oluşturulan pod'un hangi node üzerinde oluştuğunuda bu output ile görebiliriz. Bu değerler terraform providerlara göre değişmektedir.

kubernetes_pod.example.spec[0].node_name

Daha fazla bilgi için terraformun resmi sitesinden ulaşabilirsiniz.

Locals : https://developer.hashicorp.com/terraform/language/values/locals
Output : https://developer.hashicorp.com/terraform/language/values/outputs

Herkese iyi günler.

Terraform Variables

Suleyman — Sun, 15 Dec 2024 14:42:18 +0000

Merhaba,

Bu makalede en yaygın Infrastructure as code (IaC) uygulamalarından olan terraform üzerinde değişkenkler (variables) kullanımını göreceğiz. Değişkenler yapılandırmalarınızı daha dinamik ve yeniden kullanılabilir hale getirmek için kullanabileceğiniz değerler için yer tutuculardır.

Örneğin; aşağıdaki image'mizi manuel olarak vermişiz. Ama istersek bunu çalıştırdığımızda değişkenden alabiliriz. Bu sayede statik değilde dinamik olarak istenilen image'yi kullanabiliriz. Main.tf dosyamızın içine aşağıdaki resource yi yazıyoruz.

resource "kubernetes_pod" "firstpod" {
  metadata {
    name = "terraform-web"
  }

  spec {
    container {
      image = nginx
      name  = "web"
    }
   }
}

Şimdi variables.tf isminde bir dosya oluşturuyoruz ve içine aşağıdaki şekilde dolduruyoruz.

variable  "container_image" {
    type = string    

}

Ardından ilk örnekte statik olan değeri aşağıdaki şekilde dinamik yapıyoruz.

  spec {
    container {
      image = var.container_image
      name  = "web"
    }
   }
}

Terraform apply yaptığımızda bu sefer bize kullanacağımız image yi soracaktır. Bu sayede daha dinamik bir yapı oluşturabiliriz. Bu değişkenlerin en basit kullanım örnektedir.

Variables.tf içerisindeki değişkenin içerisine "default" parametresini ekleyerek, eğer biz farklı bir değişken kullanmayacaksak belirtilen değer ile çalıştıracaktır ama istenilirse farklı bir değer belirtilebilir.

variable  "container_image" {
    type = string    
    default = nginx
}

Aşağıdaki şekilde çalıştırdığımızda image olarak httpd yi kullanacaktır ama "terraform apply" şeklinde kullanırsak varsayılan nginx imagesini kullanacaktır.

terraform apply -var=container_image=httpd

Basit kullanımı bu şekilde fakat birden fazla ortam ortaya çıkmaya başladığında daha yönetilebilir bir şekilde değişkenleri kullanmamız gerekiyor. tfvars dosyaları ile bunu gerçekleştirebiliriz. variables.tf dosyasında içinde değişkenleri tanımlarken .tfvars dosyaları içerisinde de bu değişkenlerin tanımı gerçekleştiriyoruz.

Örneğin; stage ve prod ortamlarınız var ve bu iki ortam için aynı değişkenler kullanılıyor fakat farklı tanımlar kullanabiliriz. Mesela bu ortamlarda ki podların CPU ve RAM limiti birbirinden farklı olabilir. Bu şekilde bir örnek vereceğiz.

Öncelikle main.tf dosyamızın içerisine tanımlamalarımızı yapmamız gerekmektedir.

  spec {
    container {
      image = var.container_image
      name  = "web"
      resources {
        limits = {
          cpu    = var.cpu_resource
          memory = var.ram_resource
       }
     }
   }
 }
}

Ardından variables.tf dosyamızın içerisine tanımlamak istediğimiz değişkenleri yazıyoruz.

variable "cpu_resource" {
}

variable "ram_resource" {
}

Şimdi stage.tfvars içerisine aşağıdaki değerleri yazıyoruz.

cpu_resource = "0.3"
ram_resource = "250Mi"

prod.tfvarsa içerisine de aşağıdaki değerleri yazıyoruz.

cpu_resource = "0.75"
ram_resourece = "1024Mi"

Bu sayede tek bir farklı ortamlar için podlarımıza farklı resourcelar tanımladık. Stage için kullanmak istiyorsak aşağıdaki şekilde kullanmamız gerekmektedir. plan ve apply komutlarını çalıştırırken kullanılacak .tfvars dosyasını belirtmeliyiz.

terraform plan -var-file=stage.tfvars
terraform apply -var-file=stage.tfvars

Basit olarak variables.tf ve .tfvars dosyalarının kullanımı bu şekildeydi. Bir sonraki makalede terraform output kullanımına değineceğiz.

Herkese iyi günler.

Ansible Nedir ? Kurulum İşlemleri

Suleyman — Wed, 20 Mar 2024 19:58:54 +0000

Merhaba, bu makalede sektörde yaygın olarak kullanılan Ansible uygulamasına değineceğiz.

Ansible temel olarak tek noktadan sunucuları yönetmenizi sağlayan bir otomasyon aracıdır. Redhat tarafından piyasa sürülmüş olup ve geliştirilmektedir.

Ansible control-node bulunmakta ve diğer sunucular ve network cihazları bu node üzerinden yönetilmektedir. Ansible agent dediğimiz işlem yapacağımız cihazlara SSH bağlantısı üzerinden işlemleri gerçekleştirmektedir. Şimdi deAnsible'nin temel bilenlerini inceleyelim.

Inventory

İsminden de anlaşılacağı üzere yönetmek istediğimiz sistemlerin içeren dosyadır. Aşağıdaki örnek bir inventory dosyasını görüntüleyebilirsiniz. Sizler yapınıza göre bunları daha karmaşık hale getirebilirsiniz.

[Webserver]
192.168.1.131
192.168.1.132

[Database]
192.168.1.133

Playbooks

Uzak bilgisayarda hangi görevlerin yerine getirileciğini söyleyen dosyadır. YAML formatı şeklinde yazılmaktadır.


`---
- name: Apache Kurulum Playbook
  hosts: Webserver

  tasks:
  - name: Apache Kurulumu 
    yum:   
      name=httpd  
      state=latest

 - name: Apache Servis Restart
    service:   
      name=httpd  
      state=started

Modul:

Modules, belirli görevleri gerçekleştirmek için kullanılan Ansible’ın bireysel bileşenleridir. Örneğin; yukarıda yum modulu ile httpd servisini kurduk, service modulu ile servisi restart ettik.

Şimdi master node üzerinden agentlara SSH-key ile bağlantısı gerçekleştirip bağlantının gerçekleştirilmediğini görelim.

Master node üzerinde

ssh-keygen -t rsa
ssh-copy-id suleyman@192.168.1.131
ssh-copy-id suleyman@192.168.1.132
ssh-copy-id suleyman@192.168.1.133

Şimdi bunu tüm agentlara yaptıktan sonra aşağıdaki komutla erişimi test edebiliriz.

 ansible all -m ping -u suleyman

Aşağıdaki gibi bir çıktı ile karşılaştıysanız işlemler başarılı demektedir. Sonraki makalelerde görüşmek üzere...

Kubernetes Nginx Ingress Controller Kurulumu

Suleyman — Wed, 07 Feb 2024 19:59:06 +0000

Merhaba, bu makalemizde kubernetes yaygın olarak kullanılan nginx ingress controller kurulumunu gerçekleştireceğiz.

Normal şartlarda sizler her bulut sağlayıcısında (AWS,Azure,GCP) LoadBalancer türünde bir servis açtığınızda bir Public IP adresi alır. Servislerinizde çoğaldığında maddi açıdan problem olmaya başlar. Ingress tam olarak bu servislerin önünde durarak domain ve path'lere göre yönlendirme yapmaktadır. Siz artık tüm alan adlarını ingress'in sahip olduğu bir tek Public IP adresine yönlendirirsiniz.

Nginx ingress controller helm ile deploy edeceğiz.

kubectl create namespace nginx-ingress
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install my-ingress-nginx ingress-nginx/ingress-nginx --namespace nginx-ingress