SSH üzerinden Docker Compose dağıtımı: komutlar aslında ne yapıyor

En küçük sürüm

Sunucuda bir dizin oluştur, compose dosyasını içine kopyala ve stack’i başlat. Bu, eksiksiz bir dağıtımdır.

ssh deploy@203.0.113.10 'mkdir -p ~/apps/shop'
scp compose.yml deploy@203.0.113.10:~/apps/shop/compose.yml
ssh deploy@203.0.113.10 'cd ~/apps/shop && docker compose up -d'

Dizin adı süs değil. Compose onu proje adı olarak kullanır ve proje adı, Compose’un bu stack’in konteynerlerini, ağlarını ve volume’larını yeniden bulma yoludur.

Proje adı Compose’un hafızası

~/apps/shop içinden çalıştırınca konteynerler shop-web-1, shop-db-1 diye adlanır. Aynı dosyayı shop-new adlı bir dizinden çalıştırırsan Compose bunu başka bir proje sayar: ikinci bir kopya başlatır ve ilki çalışmaya devam eder.

Adı dosyanın içinde sabitle; böylece yeniden adlandırılan bir dizin bunu kazara yapamaz. En üstteki name: anahtarı, dosya nerede durursa dursun proje adını belirler.

name: shop

services:
  web:
    image: ghcr.io/example/shop:1.4.0
    env_file: .env
    depends_on: [db]
  db:
    image: postgres:16
    env_file: .env
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

.env nereye gider

Sırlar repoda değil, sunucuda compose dosyasının yanındaki bir .env dosyasında durur. Değişken adlarını ve örnek değerleri içeren bir .env.example commit’le ve .env’i ilk commit’ten önce .gitignore’a ekle — bir sır Git geçmişine girdikten sonra dosyayı silmek onu oradan çıkarmaz.

Compose, compose dosyasındaki ${VARIABLE} referanslarını doldurmak için proje dizinindeki .env’i okur. Dosyayı konteynerlere kendiliğinden geçirmez; bir servis onu yalnızca yukarıdaki gibi env_file: ya da bir environment: girdisiyle alır.

Kopyalarken sunucudaki diğer kullanıcıların onu bir an bile okuyamayacağından emin ol:

ssh deploy@203.0.113.10 'umask 077 && cat > ~/apps/shop/.env' < .env

SSH üzerinden umask 077 ile aktarmak dosyayı baştan 600 izniyle oluşturur. Önce kopyalayıp sonra chmod çalıştırmak, dosyanın okunabilir olduğu kısa bir aralık bırakır.

Compose v2 mi, eski docker-compose mu

Güncel Docker kurulumları Compose’u bir eklenti olarak getirir ve boşlukla, docker compose diye çağrılır. Bağımsız docker-compose ikilisi — Compose v1 — Temmuz 2023’te güncelleme almayı bıraktı. Bir rehber tire kullanıyorsa komutları büyük ölçüde aynen geçerli; ikilinin kendisi ise kullanılmamalı.

Sunucuda ne olduğunu docker compose version ile kontrol et. Docker compose’un bir docker komutu olmadığını söylerse, dağıtımın eski docker-compose paketi yerine Docker’ın kendi deposundaki docker-compose-plugin paketini kur.

İkinci dağıtım

Güncellemek bir pull ve bir up daha demek. Compose çalışan konteynerleri dosyayla karşılaştırır ve yalnızca imajı ya da yapılandırması değişen servisleri yeniden oluşturur.

ssh deploy@203.0.113.10 \
  'cd ~/apps/shop && docker compose pull && docker compose up -d --remove-orphans'

--remove-orphans, dosyadan sildiğin servislerin konteynerlerini kaldırır. Bu olmadan, adı değişen bir servisin eski konteyneri yenisinin yanında çalışmaya devam eder.

Volume’lar veriyi, sen aksini söyleyene kadar tutar

Konteynerler atılabilir; adlandırılmış volume’lar değil. db’yi her dağıtımda yeniden oluşturmak sorun değil, çünkü veritabanı dosyaları up, down ve imaj değişikliklerinden sağ çıkan db_data volume’unda duruyor.

Dikkatle kullanılması gereken komut docker compose down -v. -v, projenin adlandırılmış volume’larını konteynerlerle birlikte, onlarla birlikte de veriyi siler. Test ortamında işe yarar, diğer her yerde yıkıcıdır.

./data:/data gibi bind mount’lar ise compose dosyasının yanındaki bir dizini gösterir. Bu, yedeklemeyi düşünmeyi kolaylaştırır ve dosya izinlerini senin sorumluluğuna bırakır.

Zahmetli kalan kısımlar

1. 01Hangi sunucunun hangi stack’i hangi dizinde çalıştırdığını hatırlamak.
2. 02Bir stack’in ihtiyaç duyduğu ek dosyaları — bir init script’i, bir yapılandırma dosyası, .env — kopyalamak ve compose dosyasıyla uyumlu tutmak.
3. 03Son dağıtımda neyin değiştiğini bilmek. Sen kaydetmedikçe hiçbir şey kaydetmiyor.
4. 04Geri dönmek; bu, önceki imaj etiketini bilmek — ve en baştan latest yerine sabit etiketler kullanmış olmak demek.
5. 05Servisler arasında log okumak: docker compose logs -f --tail 100 çalışır — doğru sunucuda, doğru dizinin içinden.

Aynı akış MihraOps’ta

MihraOps bu adımları SSH üzerinden yürütür ve sonucu sıradan bir Compose projesi olarak bırakır. Her stack sunucunda ~/.mihraops/compose/<project>/ içinde, compose dosyası ve ek dosyalarıyla yan yana durur; yani hâlâ oraya cd ile girip docker compose’u elle çalıştırabilirsin.

Doküman sayfası, Compose düzenleyicisinden güncelleme ve imaj çekmenin nasıl çalıştığı dahil, adım adım anlatıyor.