A Docker Compose bemutatása

1. Áttekintés

A Docker széles körű használatakor több különféle konténer kezelése gyorsan nehézkessé válik.

A Docker Compose olyan eszköz, amely segít leküzdeni ezt a problémát és könnyen kezelhet több tárolót egyszerre.

Ebben az oktatóanyagban áttekintjük főbb jellemzőit és hatékony mechanizmusait.

2. A YAML-konfiguráció magyarázata

Röviden, a Docker Compose sok belül deklarált szabály alkalmazásával működik egyetlen dokkoló-összeállít.yml konfigurációs fájl.

Ezek az ember által olvasható és gépre optimalizált YAML-szabályok hatékony módszert kínálnak arra, hogy tízezer lábról néhány sorban pillanatképet készítsünk.

Szinte minden szabály helyettesít egy adott Docker parancsot, így végül csak futtatnunk kell:

dokkoló-összeáll

Tucatnyi konfigurációt kaphatunk a Compose által a motorháztető alatt. Ez megment minket a gondtól, ha Bash-szel vagy valami mással írjuk őket.

Ebben a fájlban meg kell adnunk a változat az Írás fájlformátum közül legalább egyet szolgáltatásés opcionálisan kötetek és hálózatok:

verzió: "3.7" szolgáltatások: ... kötet: ... hálózatok: ... 

Lássuk, mik is ezek az elemek valójában.

2.1. Szolgáltatások

Először is, szolgáltatások lásd a konténerek konfigurációját.

Vegyünk például egy dokkolt webalkalmazást, amely egy elülső végből, egy háttérből és egy adatbázisból áll: Valószínűleg három képre osztanánk ezeket az összetevőket, és három különböző szolgáltatásként definiálnánk őket a konfigurációban:

szolgáltatások: frontend: image: my-vue-app ... backend: image: my-springboot-app ... db: image: postgres ... 

Többféle beállítást alkalmazhatunk a szolgáltatásokra, és később ezeket alaposan megvizsgáljuk.

2.2. Kötetek és hálózatok

Kötetekmásrészt a lemezterület fizikai területei vannak megosztva a gazdagép és a tároló között, vagy akár a tárolók között. Más szavakkal, egy kötet egy megosztott könyvtár a gazdagépen, néhány vagy az összes tartályból látható.

Hasonlóképpen, hálózatok meghatározza a tárolók közötti, valamint a tároló és a gazdagép közötti kommunikációs szabályokat. A közös hálózati zónák felfedezhetik a konténerek szolgáltatásait, míg a privát zónák elkülönítik őket a virtuális homokozóban.

Ismét többet megtudhatunk róluk a következő szakaszban.

3. Szolgáltatás szétválasztása

Most kezdjük el ellenőrizni a szolgáltatás fő beállításait.

3.1. Kép húzása

Előfordul, hogy a szolgáltatásunkhoz szükséges képet (mi vagy mások) már közzétettük a Docker Hubban vagy egy másik Docker Registry-ben.

Ha ez a helyzet, akkor a kép attribútumot a kép nevének és címkéjének megadásával:

szolgáltatások: saját szolgáltatásom: kép: ubuntu: legújabb ... 

3.2. Kép építése

Ehelyett előfordulhat, hogy egy képet kell készítenünk a forráskódból annak elolvasásával Dockerfile.

Ezúttal a épít kulcsszó, átadva az elérési utat a Dockerfile-nek értékként:

szolgáltatások: my-custom-app: build: / path / to / dockerfile / ... 

URL-t is használhatunk elérési út helyett:

szolgáltatások: my-custom-app: build: //github.com/my-company/my-project.git ... 

Ezenkívül megadhatunk egy kép név a épít attribútum, amely megnevezi a képet, miután létrehozta, elérhetővé téve más szolgáltatások számára:

szolgáltatások: my-custom-app: build: //github.com/my-company/my-project.git image: my-project-image ... 

3.3. A hálózat konfigurálása

A Docker konténerek a Docker Compose által implicit módon vagy konfiguráció útján létrehozott hálózatokban kommunikálnak egymással. Egy szolgáltatás kommunikálhat ugyanazon a hálózaton található másik szolgáltatással, ha egyszerűen hivatkozik rá a tároló neve és portja alapján (például hálózat-példa-szolgáltatás: 80), feltéve, hogy a portot a leleplezni kulcsszó:

szolgáltatások: network-example-service: image: karthequian / helloworld: latest expose: - "80" 

Ebben az esetben egyébként az expozíció nélkül is működne, mert a leleplezni irányelv már szerepel a Dockerfile képen.

Ahhoz, hogy elérje a konténert a gazdától, a kikötőket deklaratív módon ki kell terjeszteni a kikötők kulcsszó, amely azt is lehetővé teszi számunkra, hogy kiválasszuk, ha a port másképp teszi ki a gazdagépet:

szolgáltatások: network-example-service: image: karthequian / helloworld: legújabb portok: - "80:80" ... my-custom-app: image: myapp: legújabb portok: - "8080: 3000" ... my- custom-app-replica: image: myapp: legújabb portok: - "8081: 3000" ... 

A 80-as port mostantól látható lesz a gazdagépről, míg a másik két konténer 3000-es portja a 8080-as és 8081-es porton lesz elérhető. Ez a hatékony mechanizmus lehetővé teszi számunkra, hogy különböző konténereket futtassunk, ugyanazokat a portokat téve ki ütközés nélkül.

Végül további virtuális hálózatokat határozhatunk meg a tárolók elkülönítésére:

szolgáltatások: network-example-service: image: karthequian / helloworld: legfrissebb hálózatok: - my-shared-network ... másik-service-in-the-azonos-network: image: alpine: legújabb hálózatok: - my-shared- hálózat ... másik szolgáltatás a saját hálózatában: image: alpine: legújabb hálózatok: - saját-magán-hálózatom ... hálózatok: megosztott-hálózatom: {} saját-magán-hálózatom: {} 

Ebben az utolsó példában ezt láthatjuk egy másik szolgáltatás ugyanabban a hálózatban képes lesz pingelni és elérni a network-example-service, miközben egy másik szolgáltatás a saját hálózatában szokás.

3.4. A kötetek beállítása

Háromféle kötet létezik: névtelen, nevezett, és házigazda azok.

Docker névtelen és megnevezett köteteket is kezel, automatikusan telepíti őket a gazdagép saját generált könyvtáraiba. Míg az anonim kötetek hasznosak voltak a Docker régebbi verzióival (1.9 előtt), manapság a megnevezettek a javasolt módszerek. A hosztkötetek lehetővé teszik egy meglévő mappa megadását is a gazdagépen.

Konfigurálhatjuk a gazdagépköteteket szolgáltatási szinten, a megnevezett köteteket pedig a konfiguráció külső szintjén, annak érdekében, hogy az utóbbiak más tárolók számára is láthatóak legyenek, és ne csak annak, amelyhez tartoznak:

szolgáltatások: kötetek-példa-szolgáltatás: kép: alpine: legújabb kötetek: - my-named-global-volume: / saját-kötetek / named-globális-kötet - / tmp: / saját-kötetek / gazdagép-kötet - / home: / my-volumenek / readonly-host-volume: ro ... egy másik-kötetek-példa-szolgáltatás: image: alpine: legújabb kötetek: - my-named-global-volume: / another-path / the-same-named- globális-kötet ... kötetek: saját nevű-globális-kötet: 

Itt mindkét tárolónak lesz olvasási / írási hozzáférése a az én nevem-globális-kötet megosztott mappa, függetlenül a különböző utaktól, amelyhez leképezték. Ehelyett a két gazdagép csak a kötetek-példa-szolgáltatás.

A / tmp A gazdagép fájlrendszerének mappája a / én-kötetek / gazdagép-kötet a tároló mappája.

A fájlrendszer ezen része írható, ami azt jelenti, hogy a tároló nem csak olvashat, hanem írhat is (és törölhet) fájlokat a gazdagépen.

A kötetet csak olvasható módban tudjuk felcsatolni a hozzáfűzéssel : ro a szabályhoz, mint a /itthon mappa (nem akarjuk, hogy egy Docker-tároló tévedésből törölje a felhasználóinkat).

3.5. A függőségek deklarálása

Gyakran létre kell hoznunk egy függőségi láncot a szolgáltatásaink között, hogy egyes szolgáltatások feltöltődjenek más szolgáltatások előtt (és azok után). Ezt az eredményt a attól függ kulcsszó:

szolgáltatások: kafka: kép: wurstmeister / kafka: 2.11-0.11.0.3 attól függ: - zookeeper ... zookeeper: image: wurstmeister / zookeeper ... 

Tudnunk kell azonban, hogy a Compose nem várja meg a állatgondozó szolgáltatás a rakodás befejezéséhez a kafka szolgáltatás: egyszerűen megvárja, amíg elindul. Ha egy szolgáltatás teljes feltöltésére van szükségünk egy másik szolgáltatás megkezdése előtt, akkor mélyebben ellenőriznünk kell az indítási és leállítási sorrendet a Compose alkalmazásban.

4. Környezeti változók kezelése

A Compose-ban könnyű a környezeti változókkal dolgozni. Meghatározhatunk statikus környezeti változókat, és a ${} jelölés:

szolgáltatások: adatbázis: kép: "postgres: $ {POSTGRES_VERSION}" környezet: DB: mydb USER: "$ {USER}" 

Különböző módszerek léteznek ezeknek az értékeknek a komponálásához.

Például az egyik beállítja őket a .env fájl ugyanabban a könyvtárban, a struktúrához hasonlóan .tulajdonságok fájl, kulcs = érték:

POSTGRES_VERSION = alpesi FELHASZNÁLÓ = foo

Ellenkező esetben beállíthatjuk őket az operációs rendszerben, mielőtt meghívnánk a parancsot:

export POSTGRES_VERSION = alpesi export USER = foo dokkoló-összeállítás 

Végül hasznos lehet egy egyszerű egybélésű használat a héjban:

POSTGRES_VERSION = alpesi FELHASZNÁLÓ = foo docker-compose up 

Keverhetjük a megközelítéseket, de ne felejtsük el, hogy a Compose a következő prioritási sorrendet használja, felülírva a kevésbé fontosakat a magasabbakkal:

  1. Fájl írása
  2. Shell környezeti változók
  3. Környezetfájl
  4. Dockerfile
  5. Változó nincs meghatározva

5. Méretezés és másolatok

A régebbi Compose verziókban átengedhettük a tároló példányait a dokkoló-komponáló skála parancs. Az újabb verziók elavulták és kicserélték a skála választási lehetőség.

A másik oldalon kiaknázhatjuk a Docker Swarmot - a Docker Motorok klaszterét - és deklaratív módon méretezhetjük konténereinket a másolatok attribútuma bevetni szakasz:

szolgáltatások: munkavállaló: image: dokkolóminták / examplevotingapp_worker hálózatok: - frontend - backend telepítés: mód: replikált replikák: 6 erőforrás: korlátok: cpus: '0,50' memória: 50M foglalások: cpus: '0,25' memória: 20M ... 

Alatt bevetni, számos más lehetőséget is megadhatunk, például az erőforrásküszöböket. Írjon azonban az egészet figyelembe veszi bevetni szakasz csak akkor, ha Swarmba telepítik, és másként figyelmen kívül hagyja.

6. Egy valós példa: Tavaszi felhő adatfolyam

Míg a kis kísérletek segítenek megérteni az egyes fogaskerekeket, a valós kód működés közbeni látása mindenképpen leleplezi az összképet.

A Spring Cloud Data Flow egy összetett projekt, de elég egyszerű ahhoz, hogy érthető legyen. Töltsük le a YAML fájlt, és futtassuk:

DATAFLOW_VERSION = 2.1.0. RELEASE SKIPPER_VERSION = 2.0.2. RELEASE dokkoló-összeállítás 

A Compose minden komponenst letölt, konfigurál és elindít, majd a konténer naplóit egyetlen áramlásba metszik az aktuális terminálon.

Ezenkívül egyedi színeket alkalmaz mindegyikükhöz a nagyszerű felhasználói élmény érdekében:

A következő hibát tapasztalhatjuk egy teljesen új Docker Compose telepítés futtatásakor:

lookup register-1.docker.io: nincs ilyen gazdagép

Bár erre a közös csapdára különböző megoldások vannak, a 8.8.8.8 mivel a DNS valószínűleg a legegyszerűbb.

7. Életciklus-kezelés

Vizsgáljuk meg végül közelebbről a Docker Compose szintaxisát:

docker-compose [-f ...] [opciók] [COMMAND] [ARGS ...] 

Noha számos lehetőség és parancs áll rendelkezésre, legalább ismernünk kell azokat, amelyek az egész rendszert helyesen aktiválják és deaktiválják.

7.1. üzembe helyezés

Láttuk, hogy a konfigurációban definiált tárolókat, hálózatokat és köteteket ezzel létrehozhatjuk és elindíthatjuk fel:

dokkoló-összeáll

Az első alkalom után azonban egyszerűen használhatjuk Rajt a szolgáltatások megkezdéséhez:

dokkoló-komponálás kezdete

Abban az esetben, ha fájlunknak az alapértelmezettől eltérő neve van (dokkoló-összeállít.yml), kihasználhatjuk a -f és fájl zászlók alternatív fájlnév megadásához:

docker-compose -f custom-compose-file.yml indítás

A Compose a háttérben futtatható démonként is, amikor a -d választási lehetőség:

dokkoló-komponál fel -d

7.2. Leállitás

Az aktív szolgáltatások biztonságos leállításához használhatjuk álljon meg, amely megőrzi a tárolókat, a köteteket és a hálózatokat, minden változtatással együtt:

dokkoló-író megálló

A projektünk állapotának visszaállításához ehelyett egyszerűen futtatunk le-, amely csak a külső kötetek kivételével mindent elpusztít:

dokkoló-komponálj le

8. Következtetés

Ebben az oktatóanyagban megtudtuk a Docker Compose programot és annak működését.

Szokás szerint megtalálhatjuk a forrást dokkoló-összeállít.yml fájlt a GitHubon, a tesztek hasznos elemével együtt, amely azonnal elérhető a következő képen: