labs

Bu lab modernize edildi ama ucтan uca dogrulanmadi. Takilirsaniz bize bildirin.

Compose ile Uygulama Derlemek

45 dkdockerGitHub'da gor
Bu sayfada

Compose ile Uygulama Derlemek

Docker Compose modelleri derleme zamanı bilgilerini de içerebilir; böylece tek bir Docker Compose komutuyla birden fazla container imajı derleyebilirsiniz. Override dosyaları kullanmak, imaj referanslarını özelleştirmenize ve imajı kaynak koda kadar izlemenizi sağlayan etiketler koymanıza imkân verir.

Kaynaklar

Komut satırına genel bakış

Docker Compose'un imajlarla çalışan komutları var:

docker compose build --help

docker compose push --help

Bunlar da diğer komutlar gibi aynı şekilde birden fazla YAML dosyasını destekliyor.


Compose ile derlemek

Boyunca kullandığımız rastgele sayı uygulamasının tüm kaynak kodu, Dockerfile ve bir Compose dosyasıyla birlikte rng klasöründe:

Compose'daki tüm yollar, Compose dosyasının bulunduğu konuma göredir.

📋 rng klasörüne geçip imajları derleyin.

Nasıl yapılacağını bilmiyor musunuz?
cd labs/compose-build/rng

docker compose build 

Build komutu, belirtimde build bölümü olan tüm imajları derler. Yapılandırdığınız derleme motorunun çıktısını göreceksiniz — bu lab için eski motoru da BuildKit'i de kullanabilirsiniz.

Bu imajların etiketi 21.05-local. Uygulamayı yerel imajlarınızdan çalıştırmak için aynı Compose dosyasını kullanabilirsiniz.

📋 Uygulamayı yeni imajlarınızla çalıştırıp çalıştığını test edin.

Nasıl yapılacağını bilmiyor musunuz?
docker compose up -d

# uygulamayi http://localhost:8090 adresinde deneyin

Compose belirtimi, uygulamayı çalıştırmak ve derlemek için gereken tüm bilgiyi taşıyor.

Build argümanları ve imaj etiketleri

Uygulamanızı derleyip çalıştıran tek bir Compose dosyası çok çekici geliyor, ama çalıştırma ve derleme seçenekleri birbirinden çok farklı; Compose belirtimlerinizi okunur ve bakımı kolay tutmak için ikisini ayırmak genellikle daha iyi:

  • core.yml — rastgele sayı uygulaması için çekirdek

    servisleri ve ağları tanımlıyor

  • build.yml — servislerin derleme seçeneklerini tanımlıyor;

    build context yolu ve Dockerfile yolu dahil

Birkaç ek yapılandırmayla imajlarınıza faydalı bir denetim izi ekleyebilirsiniz:

  • rng API Dockerfile'ı ARG komutlarını

    kullanıyor — bunlar build argümanı olarak verebileceğiniz değerler — ve imaja metadata ekliyor; build sürümünü ve Git commit ID'sini etiketlerle kaydediyor

  • args.yml imaj adını değiştiriyor ve build argümanları için

    varsayılan değerleri ayarlıyor. Tüm ${VARIABLES} değerleri, derlemeyi çalıştıran makinedeki ortam değişkenleriyle değiştirilebilir.

📋 Uygulamayı derlemek için tüm bu dosyaları birleştirin, sonra API imajının etiketlerini inceleyin.

Nasıl yapılacağını bilmiyor musunuz?
# tam build belirtimi icin tum dosyalari birlestirin:
docker compose -f core.yml -f build.yml -f args.yml build

# bu cikti etiket degerlerini gosteriyor:
docker image inspect --format '{{.Config.Labels}}' courselabs/rng-api:21.05-0

Etiket değerlerini Compose dosyasındaki varsayılanlar belirliyor.

Makinenizde ortam değişkenleri tanımlayarak Compose dosyalarındaki varsayılanları geçersiz kılabilirsiniz:

# macOS veya Linux:
export RELEASE=2021.07
export BUILD_NUMBER=121

# VEYA PowerShell ile:
$env:RELEASE='2021.07'
$env:BUILD_NUMBER='121'

📋 Derlemeyi tekrarlayın. Yeni imaj etiketleri ne oldu? API imajındaki etiket değerleri ne?

Nasıl yapılacağını bilmiyor musunuz?
# ayni dosya kumesi:
docker compose -f core.yml -f build.yml -f args.yml build

# etiket artik 2021.07-121

# yeni etiket degerlerini goster:
docker image inspect --format '{{.Config.Labels}}' courselabs/rng-api:2021.07-121

Farklı build argümanı değerleri bu derleme için önbelleği geçersiz kıldığı için Dockerfile komutlarının yeniden çalıştığını göreceksiniz.

Bu etiket değerleri yerelde derlerken pek işe yaramıyor — ama bir Sürekli Entegrasyon (CI) derlemesinde build servisi tarafından doğru değerlerle doldurulurlar.

CI derlemeleri için Docker Compose

Compose, tek bir makinede çok sayıda üretim dışı ortam çalıştırmak için harika; ama onu bu amaçla kullanmayacaksanız build özelliği Sürekli Entegrasyon için biçilmiş kaftan. Uygulamalarınızı Jenkins veya GitHub Actions'ta yalnızca docker compose build çalıştırarak kolayca derleyebilirsiniz.

Bu repoda, yerelde kullandığınız aynı Docker Compose dosyalarıyla RNG imajlarını derleyen bir GitHub Actions iş akışı da var:

  • rng-build.yml — GitHub iş akışları YAML belirtimi

    kullanır; aşina değilseniz bile aynı docker compose komutlarının çalıştığını göreceksiniz.

Gerçek imajlar herkese açık bir repoda, dolayısıyla iş akışı çıktısına gidebilirsiniz:

https://github.com/courselabs/docker/actions/workflows/rng-build.yml

📋 En son build çıktısının içine girin; gönderilen bir imaj etiketi göreceksiniz. O imajı çekip etiketlerini inceleyin.

Nasıl yapılacağını bilmiyor musunuz?
# build surumu imaj etiketine ekleniyor, ornegin 39 numarali build icin:
docker pull courselabs/rng-api:21.05-39

docker image inspect courselabs/rng-api:21.05-39

İmaj etiketlerinde saklanan gerçek derleme ayrıntılarını göreceksiniz, şuna benzer:

"Labels": {
  "build_tag": "RNG App Docker Image Weekly Build-33-refs/heads/main",
  "commit_sha": "dcd4b265f1406182a2e671b574af44100dbdfdab"
}

Bu, yerelde derlemek için kullandığınız aynı Dockerfile ve Compose dosyalarından geliyor.

İmaj etiketleri, çalışan bir container'dan onu üreten build pipeline'ına ve kaynak kodun tam sürümüne geri izlemenize yardımcı olur.

Lab

GitHub iş akışına dikkatli bakın; iki ayrı derleme ve gönderme kümesi çalıştırdığını göreceksiniz — ikinci küme bir Compose override dosyası daha kullanıyor.

Ekstra Compose dosyasını kullandığınızda fark ne oluyor ve iş akışı bu ikinci derlemeyi neden çalıştırıyor?

API imajını ikinci derlemedeki etiketten çekin ve 21.05-39 etiketiyle aynı olup olmadığını kontrol edin.

Takıldınız mı? İpuçlarına bakın veya çözümü inceleyin.


Temizlik

Bu lab'ın container'larını kaldırın:

docker compose -f core.yml down

Bu komut yalnızca bu lab'in baslattigi container'lari kaldırır. Tamamen temiz bir başlangıç istiyorsanız docker ps ile hâlâ çalışan varsa görebilirsiniz.

Ve devsecops kök dizininde değilseniz oraya geri dönün:

cd ../../..

pwd

# `devsecops` klasorunde oldugunuzdan emin olun