Podman

Bu belgelerdeki her docker compose ve docker run komutu Podman ile de çalışır. docker yerine podman koy. Bu sayfa adlandırma tuzağını ve rootless farklarını bir kez belgeler. Diğer belgeler bunları tekrarlamak yerine doğrudan buraya bağlantı verir.

podman compose, podman-compose değildir

Bunlar iki farklı araçtır. Yanlış olanı, uyarı vermeden daha az uyumlu bir uygulamayı çalıştırır.

• podman compose (boşluklu), Podman'in içine yerleşik bir alt komuttur. İnce bir sarmalayıcıdır. Makinende harici bir compose sağlayıcısı (docker-compose veya podman-compose) bulur ve komutu ona devreder. Sisteminde docker-compose kuruluysa Podman önce onu kullanır. Bu, Compose belirtiminin orijinal uygulamasıdır. Sağlayıcının bir başlık içinde yazıldığını görmek için podman compose version komutunu çalıştır.
• podman-compose (kısa çizgili), Compose belirtiminin Python tabanlı ayrı bir uygulamasıdır. Docker olmadan kendi başına çalışır. Belirtimin daha azını destekler. depends_on: condition: service_healthy desteği daha zayıftır ve ağları varsayılan olarak farklı şekilde adlandırır.

Sağlayıcı olmadan podman compose hiçbir şey yapmaz. Yalnızca podman kurulu temiz bir Ubuntu 24.04 kurulumu, her podman compose komutuna Error: looking up compose provider failed ile yanıt verir. Önce bir sağlayıcı kur:

sudo apt install podman podman-compose
podman compose version     # names /usr/bin/podman-compose, version 1.0.6

O makinede podman compose ve podman-compose aynı programı çalıştırır. Bu compose dosyalarındaki sağlık kontrolleri onun altında çalışır. Postgres beklemesi dahil olmak üzere, podman 4.9.3 ve podman-compose 1.0.6 ile compose.yml ve compose.core.yml healthy bildirdi. Sağlık kontrolleri bu nedenle tek bir düz kabuk satırı (wget -q -O /dev/null http://127.0.0.1:3000/...) kullanır. Eski node -e "fetch(...)" sözdizimi podman-compose 1.0.6 sürümüne bozuk bir kabuk satırı olarak ulaştı. Ardından uygulama yanıt verirken podman ps sürekli olarak unhealthy bildirdi.

Postgres'i başlatan her compose dosyası (compose.core.yml, compose.full.yml ve openplate-core'un hızlı başlangıç compose.yml dosyası), bir servisi Postgres sağlık kontrolüne bağlamak için depends_on: condition: service_healthy kullanır. Farklı bir sağlayıcı kullanıyorsan bu koşulu desteklediğini doğrula.

Rootless notları

Podman varsayılan olarak rootless çalışır. Konteynerler root olarak değil, kendi kullanıcın olarak çalışır. Bu daha iyi güvenlik sağlar. Kendi sunucunda barındırma yapmadan önce bilinmesi gereken, Docker'dan üç farkı da beraberinde getirir.

SELinux birim etiketleri. Fedora'da varsayılan olan SELinux enforcing modundaki bir konakta, bir konteyner erişim etiketi olmadan bind-mount edilmiş bir konak dizinini okuyamaz veya yazamaz. Yalnızca bir konteyner kullanıyorsa bağlamaya :Z ekle. Birden fazla konteyner paylaşıyorsa (örneğin -v ./pg-data:/var/lib/postgresql:Z) :z ekle. Bu üç depodaki hiçbir compose dosyası bir konak dizinini bind-mount etmez. Tümü, Podman'in otomatik olarak etiketlediği adlandırılmış birimleri kullanır. Bu not yalnızca bir volumes: girdisini bir konak yolu kullanacak şekilde düzenlersen geçerlidir. Bu değişiklik, Postgres için eşitleme basamakları 2 ve 4'ü, model ağırlıkları için çıkarım basamağı 3'ü etkiler.

1024 altındaki bağlantı noktaları. Bir rootless konteyner, izin almadan (örneğin sudo sysctl net.ipv4.ip_unprivileged_port_start=80 aracılığıyla) 1024'ün altındaki bir konak bağlantı noktasına bağlanamaz. Bu compose dosyalarındaki varsayılan bağlantı noktalarının hiçbiri (3000, 3001, 8300) buna ihtiyaç duymaz. Bu sorun yalnızca bir ters vekili atlamak için bir bağlantı noktasını 80 veya 443'e yeniden eşlersen oluşur. Her basamak en az bir bağlantı noktası yayınladığı için bu durum 4 basamağın herhangi birini etkileyebilir.

Rootless Postgres. Postgres konteyneri root olmayan bir kullanıcı olarak çalışır. Bu kullanıcının kendi veri dizinine sahip olması gerekir. apps/core/docker/compose.yml, compose.core.yml ve compose.full.yml tarafından zaten kullanılan adlandırılmış bir birim bunu otomatik olarak çözer. Podman, adlandırılmış birimi doğru sahiplikle oluşturur. Bind-mount edilmiş bir konak dizinine geçersen önce konaktan podman unshare chown -R 70:70 ./pg-data ile sahiplik ayarla. 70 kullanıcı kimliği, sabitlenmiş postgres:18-alpine imajındaki postgres kullanıcısıyla eşleşir; Debian imajları 999 kullanır. Bu adım olmadan konteyner başlangıçta bir izin hatasıyla başarısız olur. Bu durum 2. ve 4. basamakları etkiler.

Quadlet birimleri

Quadlet ne podman compose ne de podman-compose kullanır: systemd her konteyneri bizzat podman ile başlatır. Yalnızca Quadlet istiyorsan yukarıdaki sağlayıcı kurulumunu atla.

Yukarıdaki her compose dosyası ayrıca rootless systemd birimleri olarak da sunulur. Bunlar scripts/quadlet.sh tarafından oluşturulur ve docker/quadlet/ içinde saklanır. Bir birim seti, aktif bir compose işlemi olmadan systemctl --user altında yeniden başlatmalar boyunca kalıcılığını korur. Her dizin kurulum adımlarını, her birimin okuduğu ortam dosyalarını ve test çalıştırma günlüklerini içeren bir README barındırır:

• app: 1. basamak, yalnızca uygulama
• çekirdek: 2. basamak, Postgres, uygulama ve openplate-core
• inference: 3. basamak, openplate-inference ve uygulama
• full: 4. basamak, dördü birden
• openplate-core: tek başına çekirdek sunucu
• openplate-inference: tek başına çıkarım uç noktası

Tek bir yol seç: compose veya Quadlet, asla ikisi birden değil. podman compose up çalıştıran özel bir systemd birimi ile bir Quadlet birim seti aynı görevi yerine getirir. İkisini birden kurarsan önyükleme sırasında 3000 numaralı bağlantı noktası üzerinde çakışırlar. Quadlet'e geçmeden önce mevcut servisi kaldır. Quadlet'i kaldırmak için senaryo README dosyasındaki kaldırma adımlarını izle.

Herhangi bir Podman üzerinde başlamadan önce bilinmesi gereken iki şey:

• Herhangi bir systemctl --user enable adımı yoktur. Servisleri Podman'in üreteci oluşturur. Üretilen birimleri etkinleştiremezsin. Bu komutu çalıştırmak Failed to enable unit: Unit /run/user/1000/systemd/generator/app.service is transient or generated. döndürür. Bu normal bir davranıştır. Otomatik başlatma, loginctl enable-linger "$USER" ile birlikte her birimdeki [Install] WantedBy=default.target satırına dayanır. Bu komut, kullanıcı systemd örneğini ilk oturum açma yerine önyükleme sırasında başlatır.
• Her ayar birime değil, sadece <unit>.env içine yazılır. Her birim kendi dizininden iki ortam dosyası okur: Birimlerle birlikte gelen ve compose varsayılanlarını tutan <unit>.defaults.env, ardından sana ait olan <unit>.env. Podman bunları bu sırayla okur, böylece seninkindeki bir satır öncelik kazanır. Dosyan boş bile olsa var olmalıdır, aksi takdirde konteyner başlamaz. Bir güncelleme, birimleri ve varsayılan dosyaları yeniden kopyalar ve senin dosyana dokunmaz. Senaryo README dosyası insanların değiştirdiği değerleri listeler.

Ubuntu 24.04'ün sürümü olan Podman 4.9, Podman 5'ten iki yönden farklıdır:

• Podman 5.0 veya daha yenisini gerektiren Notify=healthy yok sayılır. Sonuç olarak systemctl --user start, konteyner başlatıldıktan yaklaşık bir saniye sonra, sağlık kontrolü tamamlanmadan önce çıkar. Requires= içeren bir birim, bağımlı sağlık durumunu beklemez. Konteyner durumunu manuel olarak test et:

  bash

  until [ "$(podman inspect --format '{{.State.Health.Status}}' systemd-app)" = healthy ]; do sleep 5; done

• Drop-in dizinlerini okumaz (app.container.d/*.conf). Oraya koyulan dosyaların hiçbir etkisi olmaz. Birimlerin buna ihtiyacı yoktur, değiştirebileceğin her değer <unit>.env dosyasından okunur.