ProHoster > Blog > yönetim > Docker Compose: geliştirmeden üretime

Docker Compose: geliştirmeden üretime

Kursun başlaması beklentisiyle hazırlanan podcast transkripsiyonunun çevirisi "Linux Yöneticisi"

Docker Compose: geliştirmeden üretime

Docker Compose, çalışan bir dosya oluşturmak için harika bir araçtır.
Uygulamanızda kullanılan yığın için ortam. Tanımlamanıza olanak tanır
uygulamanızın her bir bileşeni, açık ve basit bir sözdizimini takip ederek YAML-
Dosyalar.

Gelişiyle liman işçisi v3 oluştur bu YAML dosyaları, aşağıdakilerle çalışırken doğrudan üretim ortamında kullanılabilir:
küme Docker Sürüsü.

Ancak bu, aynı docker-compose dosyasını kullanabileceğiniz anlamına mı geliyor?
geliştirme sürecinde ve üretim ortamında? Veya aynı dosyayı şunun için kullanın:
sahneleme? Genel olarak evet, ancak bu işlevsellik için aşağıdakilere ihtiyacımız var:

  • Değişken enterpolasyonu: bazıları için ortam değişkenlerini kullanma
    her ortamda değişen değerler.
  • Yapılandırmayı geçersiz kılma: bir saniye (veya herhangi bir) tanımlama yeteneği
    ile ilgili bir şeyi değiştirecek başka bir sonraki) docker-compose dosyası
    önce docker compose her iki dosyayı birleştirmeyle ilgilenecektir.

Geliştirme ve üretim dosyaları arasındaki farklar

Geliştirme sırasında büyük olasılıkla kod değişikliklerini kontrol etmek isteyeceksiniz.
gerçek zamanlı. Bunu yapmak için genellikle kaynak kodunun bulunduğu birim eklenir.
uygulamanız için çalışma zamanını içeren kapsayıcı. Ancak bir üretim ortamı için
Bu yöntem uygun değildir.

Üretimde birçok düğümden oluşan bir kümeniz var ve birim yerel
kapsayıcınızın (veya hizmetinizin) üzerinde çalıştığı düğüme göre
kaynak kodunu aşağıdakileri içeren karmaşık işlemler olmadan bağlayabilirsiniz:
kod senkronizasyonu, sinyaller vb.

Bunun yerine genellikle kodunuzun belirli bir sürümünü içeren bir görüntü oluşturmak isteriz.
Uygun etiketle işaretlemek gelenekseldir (anlamsal etiketi kullanabilirsiniz)
versiyonlama veya kendi takdirinize bağlı olarak başka bir sistem).

Yapılandırmayı Geçersiz Kılma

Farklılıklar ve bağımlılıklarınızın senaryolara göre farklılık gösterebileceği göz önüne alındığında
Geliştirme ve üretimde farklı konfigürasyon dosyalarına ihtiyacımız olacağı açıktır.

Docker oluşturma, farklı oluşturma dosyalarını birleştirmeyi destekler
son konfigürasyonu elde edin. Bunun nasıl çalıştığını örnekte görebilirsiniz:

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | < hello! >
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Söylendiği gibi, docker compose birden fazla oluşturmayı birleştirmeyi destekler -
Bu, ikinci dosyadaki çeşitli parametreleri geçersiz kılmanıza olanak tanır. Örneğin:

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Bu sözdizimi, geliştirme sırasında komut kullanıldığında pek uygun değildir.
birçok kez yapılması gerekecektir.

Neyse ki, docker compose otomatik olarak adı verilen özel bir dosyayı arar.
docker-compose.override.yml değerleri geçersiz kılmak liman işçisi-compose.yml. Eğer
ikinci dosyayı yeniden adlandırırsanız, yalnızca orijinal komutu kullanarak aynı sonucu alırsınız:

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Tamam, bunu hatırlamak daha kolay.

Değişkenlerin İnterpolasyonu

Yapılandırma dosyaları desteği interpolasyon
değişkenler ve varsayılan değerler. Yani aşağıdakileri yapabilirsiniz:

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

Ve eğer yaparsan docker-compose build (veya push) ortam değişkeni olmadan
$MY_SERVICE_VERSION, değer kullanılacaktır sonama eğer ayarlarsan
ortam değişkeninin derlemeden önceki değeri, inşa ederken veya iterken kullanılacaktır
kayıt defterine özel.registry.mine.

İlkelerim

Benim için işe yarayan yaklaşımlar sizin için de işe yarayabilir. bunları takip ediyorum
Basit kurallar:

  • Üretim, geliştirme (veya diğer ortamlar) için tüm yığınlarım şu şekilde tanımlanır:
    liman işçisi tarafından oluşturulan dosyalar
  • Mümkün olduğunca tüm ortamlarımı kapsaması gereken yapılandırma dosyaları
    çoğaltmayı önleyin.
  • Her ortamda çalışmak için basit bir komuta ihtiyacım var.
  • Ana konfigürasyon dosyada tanımlanmıştır liman işçisi-compose.yml.
  • Ortam değişkenleri resim etiketlerini veya diğerlerini tanımlamak için kullanılır.
    ortamdan ortama değişebilen değişkenler (aşamalama, entegrasyon,
    üretme).
  • Üretim değişkenlerinin değerleri, değer olarak kullanılır
    varsayılan olarak bu, yığının üretime geçirilmesi durumunda riskleri en aza indirir.
    ortam değişkenini ayarlayın.
  • Üretim ortamında bir hizmeti başlatmak için şu komutu kullanın: docker yığın dağıtımı - dosya oluşturma docker-compose.yml -with-registry-auth my-stack-name.
  • Komut kullanılarak çalışma ortamı başlatılır. docker-up -d kadar-up.

Basit bir örneğe bakalım.

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

И

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

kullanabilirim liman işçisi-oluştur (liman işçisi-oluştur)yığını çalıştırmak için
kaynak kodunun takılı olduğu geliştirme modu /proje/kaynak.

Aynı dosyaları üretimde kullanabilirim! Ve kesinlikle kullanabilirim
aynı dosya liman işçisi-compose.yml sahnelemek için. Bunu genişletmek için
üretim, yalnızca görüntüyü önceden tanımlanmış bir etiketle oluşturup göndermem gerekiyor
CI aşamasında:

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

Üretimde bu, aşağıdaki komutlar kullanılarak çalıştırılabilir:

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

Ve eğer aynısını sahnede yapmak istiyorsanız, sadece tanımlamanız gerekir.
hazırlama ortamında çalışmak için gerekli ortam değişkenleri:

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

Sonuç olarak, iki farklı docker-compose dosyası kullandık.
Sahip olduğunuz herhangi bir ortam için yinelenen yapılandırmalar kullanılabilir!

Kurs hakkında daha fazla bilgi edinin "Linux Yöneticisi"

Kaynak: habr.com

Yorum ekle