Blog Projeler Dokümanlar Araçlar Hizmetler Dosyalar Linkler Hakkımda İletişim
.NET, API, veritabanı ve kullanıcı arayüzü bileşenlerinden oluşan yazılım mimarisi

Docker Image İmzalama, SBOM ve Provenance Zinciri

Docker Image İmzalama, SBOM ve Provenance Zinciri için gerçek komutlar, yapılandırma örnekleri, beklenen çıktılar, güvenlik kontrolleri, yedekleme ve geri dönüş adımları içeren uygulamalı rehber. Amaç; varsayılan ayarları körlemesine kullanmadan ihtiyaca uygun, doğrulanabilir ve geri alınabilir bir yapılandırma oluşturmak.

Docker Image İmzalama, SBOM ve Provenance Zinciri

Docker Image İmzalama, SBOM ve Provenance Zinciri, yalnızca birkaç komutu arka arkaya çalıştırmakla tamamlanacak bir işlem değildir. Bu rehberde Docker Engine için yapılandırma süreci, DigitalOcean Community öğreticilerindeki gibi önce önkoşullar belirlenerek, sonra her adımın komutu ve doğrulaması gösterilerek ele alınır. Kullanılan alan adları ve IP adresleri örnektir; example.com, 192.0.2.0/24 ve 198.51.100.0/24 dokümantasyon için ayrılmış değerlerdir.

Bu çalışmanın temel amacı varsayılan ayarları körlemesine kullanmadan ihtiyaca uygun, doğrulanabilir ve geri alınabilir bir yapılandırma oluşturmak. En sık karşılaşılan riskler ise örnek dosyayı olduğu gibi üretime almak, gizli bilgiyi dosyaya gömmek ve değişiklik kaydı tutmamak. İşlemi başarılı saymak için yapılandırma testinin geçmesi, hizmetin yeniden başlatma sonrası çalışması ve eski sürüme dönüşün mümkün olması gerekir.

Önemli: Komutları doğrudan üretim sunucusunda kopyalayıp çalıştırmayın. Önce test sunucusunda uygulayın, yedek alın ve ikinci bir yönetim oturumunu açık tutun. Parola, API anahtarı ve özel anahtarları XML, Git deposu veya düz metin yapılandırma dosyası içine yazmayın.

Bu rehber sonunda ne elde edeceksiniz?

  • node-166 isimli örnek düğüm üzerinde Docker Engine için doğrulanmış bir temel yapı,
  • yapılandırma kontrolü, servis sağlık testi ve ağ doğrulaması,
  • logların nereden okunacağını gösteren tanı adımları,
  • yedekleme, geri yükleme ve sürüm geri dönüş komutları,
  • canlıya geçmeden önce kullanılabilecek ayrıntılı kontrol listesi.

Önkoşullar

Başlamadan önce aşağıdaki koşulları sağlayın:

  1. Yönetici yetkisine sahip, kişisel hesabınıza bağlı bir kullanıcı.
  2. Konsol veya sağlayıcı panelinden acil erişim imkânı.
  3. En az bir güncel tam yedek ve mümkünse ayrı depolama hedefi.
  4. DNS değişikliği yapılacaksa mevcut kayıtların dışa aktarımı.
  5. Kullanılacak portların ve erişecek kaynak IP adreslerinin yazılı listesi.
  6. Sunucu saati, zaman dilimi ve NTP eşitlemesinin doğru olması.
  7. Değişiklik öncesi disk, bellek ve servis durumunun kaydedilmesi.

Örnek ortam değişkenlerini aşağıdaki gibi tanımlayabilirsiniz:

export HOSTNAME_EXPECTED="node-166"
export SERVER_IP="192.0.2.176"
export ADMIN_IP="198.51.100.176"
export APP_DOMAIN="lab-166.example.com"
printf "Host=%s\nServer=%s\nAdmin=%s\nDomain=%s\n"   "$HOSTNAME_EXPECTED" "$SERVER_IP" "$ADMIN_IP" "$APP_DOMAIN"

Bu değerler sadece örnektir. Gerçek IP ve alan adlarını kendi altyapınıza göre değiştirin.

Konuya özel laboratuvar — Docker Engine yapılandırmasını kontrollü uygulayın

Bu başlığın merkezindeki işlem yapılandırma olduğundan, önce yapılandırmayı ayrı dosyada hazırlayın, sözdizimi kontrolü yapın ve ardından servisi kesintisiz reload etmeyi deneyin.

docker version
docker info
docker run --rm hello-world

Değişiklikten sonra aynı komutu ve gerçek istemci testini tekrar çalıştırın. Hata oluşursa servis üzerinde yeni değişiklikler denemek yerine kayıtlı önceki dosyaya dönün ve logdaki ilk hatayı inceleyin.

Adım 1 — Mevcut durumu kaydedin

Canlı sistemde doğrudan deneme yapmayın. Kurulum veya ayar değişikliği öncesinde işletim sistemi, açık portlar, disk alanı, saat ve mevcut servisler kaydedilmelidir. Bu kayıt, sorun çıktığında “önceden böyle miydi?” sorusunu cevaplar ve geri dönüş kararını hızlandırır.

date -Is
hostnamectl 2>/dev/null || hostname
uname -a
ip -brief address 2>/dev/null || ipconfig
ss -lntup 2>/dev/null || true
df -hT 2>/dev/null || true
free -h 2>/dev/null || true
systemctl --failed 2>/dev/null || true

Windows tabanlı bir başlıkta aynı envanteri PowerShell ile alın:

Get-Date -Format o
Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber
Get-NetIPConfiguration
Get-NetTCPConnection -State Listen | Sort-Object LocalPort
Get-Volume
Get-Service | Where-Object Status -eq "Running" | Select-Object -First 30

Çıktıyı olay kaydına veya bakım biletine ekleyin. Disk doluysa, saat yanlışsa veya sistemde başarısız servis varsa önce bu temel sorunu çözün; üzerine yeni bileşen kurmak tanıyı zorlaştırır.

Adım 2 — Docker Engine bileşenini kurun veya hazır olduğunu doğrulayın

Aynı anda tek değişkeni değiştirin. Paket yöneticisini ve resmî depoyu kullanmak, güncelleme ve güvenlik düzeltmelerinin izlenebilmesi açısından önemlidir. Aşağıdaki komutlar bu konu için başlangıç akışını gösterir:

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo tee /etc/apt/keyrings/docker.asc >/dev/null
sudo chmod a+r /etc/apt/keyrings/docker.asc
. /etc/os-release
printf "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu %s stable
" "$VERSION_CODENAME" | sudo tee /etc/apt/sources.list.d/docker.list >/dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Kurulum tamamlandığında sürüm ve servis durumunu hemen kontrol edin:

docker version
docker info
docker run --rm hello-world

Beklenen sonuç, kritik komutların hata kodu 0 ile tamamlanması ve hizmetin etkin görünmesidir. Örnek çıktı:

Hello from Docker!

Paket bulunamıyorsa rastgele bir üçüncü taraf betiği çalıştırmayın. İşletim sistemi sürümünün desteklendiğini, depo imzasını ve mimariyi (amd64, arm64) doğrulayın. Kurulum sırasında eski yapılandırma dosyasıyla yeni paket arasında seçim sorulursa mevcut dosyayı önce kopyalayın ve farkı inceleyin.

Adım 3 — Yapılandırmayı açık ve denetlenebilir biçimde oluşturun

Aşağıdaki örnek, Docker Engine için güvenli bir başlangıç şablonudur. CHANGE_ME, özel anahtar veya örnek IP bulunan alanlar gerçek değerlerle değiştirilmelidir. Gizli bilgiler mümkünse ortam değişkeni, işletim sistemi secret deposu veya Vault benzeri bir çözümden okunmalıdır.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true,
  "userland-proxy": false
}

Yapılandırmayı doğrudan ana dosyanın sonuna eklemek yerine ürün destekliyorsa conf.d, sites-available, drop-in veya ayrı environment dosyaları kullanın. Böylece varsayılan dosya ile sizin değişikliğiniz ayrılır. Dosya izinlerini de kontrol edin:

sudo find /etc -maxdepth 3 -type f -name "*.conf" -perm /022 -print 2>/dev/null | head -50
sudo stat -c "%A %U:%G %n" /etc/ssh/sshd_config 2>/dev/null || true
sudo systemd-analyze verify /etc/systemd/system/*.service 2>/dev/null || true

Log, port ve uygulama yanıtını birlikte değerlendirin. Yapılandırma testi olmayan ürünlerde, servisi yeniden başlatmadan önce test instance veya dry-run seçeneği kullanın. Değişiklik kaydında dosyanın eski ve yeni checksum değerlerini saklamak sonradan karşılaştırma yapmayı kolaylaştırır.

Adım 4 — Ağ erişimini ve güvenlik sınırlarını belirleyin

“Servis çalışıyor” ile “servis güvenli biçimde erişilebilir” aynı şey değildir. Yönetim portu yalnızca 198.51.100.176 gibi izin verilen kaynaklardan erişilebilir olmalı; halka açık hizmetlerde ise 80/443, DNS veya posta gibi gerçekten gerekli portlar açılmalıdır.

sudo nft list ruleset
docker network ls
ss -lntup

Kural eklemeden önce mevcut SSH veya RDP oturumunu kapatmayın. Yeni bir terminalden ikinci bağlantıyı test edin. Firewall kuralı ile uygulamanın bind adresini birlikte değerlendirin: uygulama 0.0.0.0 üzerinde dinliyorsa firewall tek koruma katmanı olur; yalnızca yerel reverse proxy kullanılacaksa 127.0.0.1 üzerinde dinlemek daha dar bir yüzey sağlar.

Dinleyen portları ve işlemleri tekrar görüntüleyin:

ss -lntup 2>/dev/null || true
sudo lsof -nP -iTCP -sTCP:LISTEN 2>/dev/null || true
# Dış bir yönetim bilgisayarından:
# nc -vz lab-001.example.com 443
# nc -vz lab-001.example.com <YONETIM_PORTU>

Beklemediğiniz bir port görürseniz yalnızca firewall ile gizlemeyin; portu açan servisin neden çalıştığını araştırın ve gereksizse devre dışı bırakın.

Adım 5 — Yapılandırmayı ve gerçek hizmet yanıtını doğrulayın

Doğrulama üç katmanda yapılmalıdır: yapılandırma sözdizimi, yerel servis sağlığı ve istemci tarafından gerçek erişim. Bu başlık için temel kontrol komutları şunlardır:

docker info
systemctl is-active docker
docker run --rm hello-world

Ardından genel doğrulama akışını çalıştırın:

# DNS ve ağ
getent hosts lab-166.example.com 2>/dev/null || nslookup lab-166.example.com
# TLS kullanılan hizmetlerde sertifika zinciri
openssl s_client -connect lab-166.example.com:443 -servername lab-166.example.com </dev/null 2>/dev/null   | openssl x509 -noout -subject -issuer -dates 2>/dev/null || true
# HTTP hizmetlerinde yanıt başlıkları
curl -fsS -I --connect-timeout 5 https://lab-166.example.com 2>/dev/null || true

Yerel test başarılı, dış test başarısızsa DNS, NAT, güvenlik grubu ve firewall katmanlarını ayrı ayrı kontrol edin. Dış test başarılı fakat uygulama hatalı içerik döndürüyorsa reverse proxy yönlendirmesi, host header ve uygulama logları incelenmelidir. Kontrol sonucunu ekran görüntüsü yerine metin çıktısıyla saklamak arama ve karşılaştırmayı kolaylaştırır.

Adım 6 — Logları, metrikleri ve alarm koşullarını kurun

Docker Engine için başlıca yapılandırma ve log konumları aşağıdadır:

Önemli dosya ve dizinler

  • /etc/docker/daemon.json
  • /etc/systemd/system/docker.service.d/

Log okuma komutları

journalctl -u docker
docker events

Sadece hata satırlarını toplamak yeterli değildir. Zaman damgası, host adı, istemci IP adresi, istek kimliği ve hata kodu gibi alanların kayda girdiğini kontrol edin. Log rotasyonu olmadan büyüyen dosyalar diski doldurabilir. Linux sistemlerde logrotate, Windows tarafında Event Log saklama boyutu ve uygulama tarafında retention politikası açıkça tanımlanmalıdır.

Örnek hızlı kontrol:

journalctl -p warning..alert --since "30 minutes ago" --no-pager 2>/dev/null || true
find /var/log -type f -size +500M -printf "%s %p\n" 2>/dev/null | sort -nr | head
systemctl --failed 2>/dev/null || true

Alarmı oluşturmadan önce test edin. Alarm mesajında hangi sistemin etkilendiği, ilk görüldüğü zaman, son değer, eşik ve ilk müdahale bağlantısı bulunmalıdır. Tek bir kısa sıçrama için sürekli bildirim üreten alarm yerine süre ve tekrar koşulu kullanın.

Adım 7 — Yedek alın ve geri yüklemeyi gerçekten deneyin

Yedekleme görevi başarıyla çalıştı mesajı, yedeğin geri yüklenebildiğini kanıtlamaz. Yapılandırma, veri, sertifika ve gizli anahtarların hangi yöntemle yedeklendiğini ayrı ayrı belirleyin. İlk örnek yedek komutları:

docker compose config > /var/backups/compose-resolved-$(date +%F).yaml
docker run --rm -v app_data:/data -v /var/backups:/backup alpine tar -czf /backup/app-data-$(date +%F).tar.gz -C /data .

Yedek dosyasının boyutunu ve checksum değerini kaydedin:

find /var/backups -type f -mtime -1 -printf "%TY-%Tm-%Td %TH:%TM %s %p\n" 2>/dev/null | sort
sha256sum /var/backups/* 2>/dev/null | tail -20

Geri yüklemeyi mümkünse ayrı bir test sunucusunda veya ayrı veritabanı/namespace üzerinde gerçekleştirin:

docker run --rm -v app_data:/data -v /var/backups:/backup alpine sh -c "rm -rf /data/* && tar -xzf /backup/app-data-YYYY-MM-DD.tar.gz -C /data"

Restore sonrasında yalnızca dosyanın açıldığını değil, uygulamanın gerçek sorgu ve sağlık kontrollerini de çalıştırın. RPO için son geri kazanılabilir verinin zamanı, RTO için hizmetin kullanılabilir hâle gelmesine kadar geçen süre kaydedilmelidir.

Adım 8 — Değişiklik sonrası gözlem ve geri dönüş

Canlıya aldıktan sonraki ilk dakikalarda hata oranı, gecikme, bellek, disk I/O ve bağlantı sayısı izlenmelidir. Önceki sürüme göre belirgin kötüleşme varsa “biraz daha bekleyelim” yerine önceden belirlenmiş eşiklere göre geri dönüş kararı verin.

docker compose pull
docker compose up -d
# Sorun varsa image etiketini önceki sabit sürüme alın ve yeniden çalıştırın.

Geri dönüşten sonra sağlık kontrolünü tekrar çalıştırın ve olay kaydına şu bilgileri ekleyin: değişikliğin başlangıç/bitiş zamanı, uygulanan sürüm, geri dönüş sebebi, etkilenen kullanıcılar, kalıcı düzeltme için açılan görev ve sonraki deneme koşulları.

Özellikle yapılandırma çalışmalarında, başarılı komut çıktısı kadar başarısızlık anındaki davranış da test edilmelidir. Servisi kontrollü durdurma, bir düğümü ağdan ayırma, geçersiz yapılandırma verme veya test alarmı üretme gibi tatbikatlar sistemin gerçek dayanıklılığını gösterir.

Yaygın sorunlar ve çözüm sırası

Servis başlamıyor

Önce servis durumunu ve son logları okuyun. Hemen yeniden kurulum yapmak, asıl hata mesajını kaybetmenize neden olabilir.

systemctl status docker --no-pager 2>/dev/null || true
journalctl -u docker -n 100 --no-pager 2>/dev/null || true
systemctl cat docker 2>/dev/null || true

Port dinlemiyor

Yapılandırmadaki bind adresini, port çakışmasını ve servisin doğru kullanıcıyla çalıştığını kontrol edin. 127.0.0.1 üzerinde dinleyen bir uygulamaya başka makineden doğrudan erişilemez; reverse proxy veya uygun bind adresi gerekir.

Yerelde çalışıyor, dışarıdan açılmıyor

DNS kaydı, sağlayıcı güvenlik grubu, işletim sistemi firewall'u, NAT ve uygulama portu sırasıyla kontrol edilmelidir. Her katmanda aynı anda değişiklik yapmayın.

Yapılandırma testi geçiyor ama uygulama hata veriyor

Sözdizimi doğru olsa da dosya izinleri, environment değişkenleri, veritabanı erişimi veya upstream hizmetleri hatalı olabilir. İstek kimliğiyle loglar arasında bağlantı kurun.

Güncellemeden sonra davranış değişti

Sürüm notlarını, varsayılan değer değişikliklerini ve kaldırılan seçenekleri inceleyin. Eski dosyayı doğrudan yeni sürüme kopyalamak yerine üreticinin migration adımını uygulayın.

Canlıya geçiş kontrol listesi

  • Kullanılan işletim sistemi ve Docker Engine sürümü destekleniyor.
  • Yapılandırma dosyaları yedeklendi ve fark çıktısı saklandı.
  • Gizli bilgiler düz metin içinde bulunmuyor.
  • Yönetim erişimi 198.51.100.176 veya VPN ile sınırlandı.
  • Yalnızca gerekli portlar dinliyor.
  • Yapılandırma testi ve servis sağlık kontrolü başarılı.
  • DNS ve TLS kontrolleri dış bir istemciden yapıldı.
  • Log rotasyonu ve saklama süresi tanımlandı.
  • Alarm kuralı test olayıyla doğrulandı.
  • Yedek checksum değeri kaydedildi.
  • Ayrı hedefte geri yükleme testi tamamlandı.
  • Geri dönüş komutu ve karar eşiği bakım kaydında bulunuyor.
  • Değişiklik sonrası en az bir gözlem penceresi tamamlandı.

Sık sorulan sorular

Bu komutları doğrudan kendi sunucumda çalıştırabilir miyim?

Örnekler güvenli dokümantasyon IP ve alan adları kullanır. Paket adı, ağ kartı, servis adı, dosya yolu ve sürüm işletim sistemine göre değişebilir. Önce test ortamında çalıştırmalı, komutun yardım çıktısını ve resmî belgeyi kontrol etmelisiniz.

Firewall açmadan önce neyi kontrol etmeliyim?

Servisin gerçekten hangi adreste dinlediğini, portun neden gerekli olduğunu ve kimlerin erişeceğini belirleyin. Yönetim portlarını tüm internete açmak yerine kaynak IP, VPN veya kimlik tabanlı erişim kullanın.

Yedek aldıktan sonra neden restore testi gerekiyor?

Eksik izin, bozuk arşiv, uyumsuz sürüm veya unutulmuş anahtar nedeniyle yedek dosyası kullanılamayabilir. Restore testi hem yedeğin doğruluğunu hem de ekibin kurtarma adımlarını uygulayabildiğini gösterir.

Güncelleme sonrası ne kadar süre izlemeliyim?

Tek bir sabit süre yoktur. Normal trafik döngüsünü, arka plan görevlerini ve yoğun saatleri kapsayan bir pencere seçin. Hata oranı, gecikme ve kaynak tüketimi için önceden geri dönüş eşikleri belirleyin.

Parolaları örnek dosyalarda nasıl göstermeliyim?

Gerçek parola kullanmayın. CHANGE_ME, <SECRET_FROM_VAULT> gibi açık yer tutucular kullanın ve uygulamada değeri güvenli secret deposundan alın. Yer tutucunun canlıda kalmasını deployment doğrulamasıyla engelleyin.

Sonuç

Bu rehberde Docker Image İmzalama, SBOM ve Provenance Zinciri konusu; önkoşullar, kurulum veya değişiklik adımları, gerçek komutlar, yapılandırma örneği, ağ güvenliği, sağlık kontrolü, loglama, yedekleme ve geri dönüş planıyla birlikte ele alındı. İşlemi tamamlanmış saymak için yalnızca Docker Engine servisinin çalışması yeterli değildir; dış erişim, güvenlik sınırları, loglar ve kurtarma akışı da doğrulanmalıdır.

Bu yazıyla ilişkili diğer içerikler:

Resmî kaynaklar

Aşağıdaki kaynaklar sürüm ve seçenek doğrulaması için kullanılmalıdır:

  • https://docs.docker.com/engine/install/ubuntu/

Etiketler: CI/CD ve Dağıtım, Docker, Docker Engine, adım adım rehber, sunucu yönetimi, yapılandırma

Paylaş:

Bu yazı hakkında sorunuz mu var? İletişime geçin.

İletişime Geç

İlgili yazılar

.NET, API, veritabanı ve kullanıcı arayüzü bileşenlerinden oluşan yazılım mimarisi
CI/CD ve Dağıtım 15.05.2026

GitLab Runner Docker Executor Kurulumu ve İzolasyonu

GitLab Runner Docker Executor Kurulumu ve İzolasyonu için gerçek komutlar, yapılandırma örnekleri, beklenen çıktılar, güvenlik kontrolleri, yedekleme ve geri dönüş adımları içeren uygulamalı rehber. Amaç; sıfırdan kurulum yapmak, varsayılan davranışı görmek ve servisin gerçekten çalıştığını kanıtlamak.

15 May 2026
.NET, API, veritabanı ve kullanıcı arayüzü bileşenlerinden oluşan yazılım mimarisi
CI/CD ve Dağıtım 28.07.2026

Argo CD ile GitOps Deployment ve Drift Yönetimi

Argo CD ile GitOps Deployment ve Drift Yönetimi için gerçek komutlar, yapılandırma örnekleri, beklenen çıktılar, güvenlik kontrolleri, yedekleme ve geri dönüş adımları içeren uygulamalı rehber. Amaç; varsayılan ayarları körlemesine kullanmadan ihtiyaca uygun, doğrulanabilir ve geri alınabilir bir yapılandırma oluşturmak.

28 Tem 2026
.NET, API, veritabanı ve kullanıcı arayüzü bileşenlerinden oluşan yazılım mimarisi
CI/CD ve Dağıtım 04.06.2026

Nginx ile Canary Release ve Kademeli Trafik Dağıtımı

Nginx ile Canary Release ve Kademeli Trafik Dağıtımı için gerçek komutlar, yapılandırma örnekleri, beklenen çıktılar, güvenlik kontrolleri, yedekleme ve geri dönüş adımları içeren uygulamalı rehber. Amaç; varsayılan ayarları körlemesine kullanmadan ihtiyaca uygun, doğrulanabilir ve geri alınabilir bir yapılandırma oluşturmak.

04 Haz 2026
.NET, API, veritabanı ve kullanıcı arayüzü bileşenlerinden oluşan yazılım mimarisi
CI/CD ve Dağıtım 30.05.2026

Zero-Downtime Veritabanı Migration Stratejisi

Zero-Downtime Veritabanı Migration Stratejisi için gerçek komutlar, yapılandırma örnekleri, beklenen çıktılar, güvenlik kontrolleri, yedekleme ve geri dönüş adımları içeren uygulamalı rehber. Amaç; varsayılan ayarları körlemesine kullanmadan ihtiyaca uygun, doğrulanabilir ve geri alınabilir bir yapılandırma oluşturmak.

30 May 2026
.NET, API, veritabanı ve kullanıcı arayüzü bileşenlerinden oluşan yazılım mimarisi
CI/CD ve Dağıtım 26.05.2026

IIS Blue-Green Deployment ve Trafik Geçişi

IIS Blue-Green Deployment ve Trafik Geçişi için gerçek komutlar, yapılandırma örnekleri, beklenen çıktılar, güvenlik kontrolleri, yedekleme ve geri dönüş adımları içeren uygulamalı rehber. Amaç; varsayılan ayarları körlemesine kullanmadan ihtiyaca uygun, doğrulanabilir ve geri alınabilir bir yapılandırma oluşturmak.

26 May 2026
.NET, API, veritabanı ve kullanıcı arayüzü bileşenlerinden oluşan yazılım mimarisi
CI/CD ve Dağıtım 25.04.2026

GitHub Actions ile Yeniden Kullanılabilir .NET Build Pipeline

GitHub Actions ile Yeniden Kullanılabilir .NET Build Pipeline için gerçek komutlar, yapılandırma örnekleri, beklenen çıktılar, güvenlik kontrolleri, yedekleme ve geri dönüş adımları içeren uygulamalı rehber. Amaç; varsayılan ayarları körlemesine kullanmadan ihtiyaca uygun, doğrulanabilir ve geri alınabilir bir yapılandırma oluşturmak.

25 Nis 2026