[megoldva] Docker, docker-compose, és fájl struktúra

Virtualizáció

Sziasztok,

Szeretnék egy környezetet kialakítani ahol csak az alap rendszer (Linux) és felette docker konténerek vannak.
A konténerek működnek is, csak az elérési utakkal vagyok bajban.

Tehát van sok könyvtár, benne egy-egy docker-compose.yaml, illetve egyeseskben még Dockerfile is van a helyi image gyártáshoz.
A docker-compose fájlokban van egy-egy volume kivezetés a helyi fájlrendszerre.
Rendszerint ez:
 

volumes:
  - $PWD/idetedd:/container/belso/konyvtar

Ezzel az a baj, hogy ez az éppen aktuális könyvtárat mutatja, tehát ha mondjuk a root könyvtárból indítom a containert:
 

/root# docker-compose -f /fajl/helye/a/fajlrendszeren up

Akkor a root könyvtárban lesz egy ilyenem: /idetedd

Mit kell használnom a $PWD helyett, hogy az mindig egy adott könyvtárra mutasson, de mégse legyen beégetve?

A végső cél az lenne, hogy  elindítom a következő parancsot:

# docker-compose -f docker/container1/docker-compose.yaml -f docker/container2/docker-compose.yaml up

Akkor mindegyik konfiguráció, a saját könyvtárán belül hozza létre a saját hostra kötött könyvtárát.

Google keresés nem segített, lehet, hogy nem jó felé nézelődtem.

üdv: redman

( rascy | 2022. 11. 29., k – 14:18 )

Szerkesztve: 2022. 11. 29., k – 14:21

Beírod a teljes elérési útvonalat:
- /var/www/akarmi/idetedd:/container/belso/konyvtar

Vagy használj .env -et külön a mappákban, ahol a docker-compose.yml fájl van:

.env
WORKING_DIR=/var/www/akarmi

- $WORKING_DIR/idetedd:/container/belso/konyvtar

You can set default values for environment variables using a .env file, which Compose automatically looks for in project directory (parent folder of your Compose file). Values set in the shell environment override those set in the .env file.

szerintem nem kell, elég, ha mellette van. Arra figyelj, hogy a futtató környezetben ne legyen az a változó összeszemetelve, mert az erősebb. 

( gabrielakos v | 2022. 11. 29., k – 14:25 )

Nem a $PWD-ből veszed hanem egy saját mondjuk WORKDIR változóból.
A WORKDIR-t meg a docker-compose előtt beállítod.

WORKDIR=/opt/app/akarmi docker-compose -f ...

A "docker szép" megoldás amúgy a volume-ok használata lenne. Előre létrehozod a volume-okat (akár egy scripttel) és a compose-ban már nincsenek elérési utak csak volume hivatkozások.

Gábriel Ákos

( redman | 2022. 11. 29., k – 16:12 )

Köszönöm, így már jó lesz. Lehetne még kényelmesebb, de azért ez is nagyon jó.

Tehát leteszünk valahova egy environment fájlt
/srv/docker/config.env

Aminek a tartalma ez:
WORKING_DIR=/srv/docker/data

A docker-compos fájlba használjuk a változót: 
volumes:
      - $WORKING_DIR/mysql:/var/lib/mysql

Majd indítjuk a dolgot:
docker-compose --env-file /srv/docker/config.env -f /srv/docker/mysql/docker-compose.yml up

https://www.redman.hu

Ha "config.env" helyett ".env" -nek hívod, akkor elvileg nem kell a --env-file, lásd fentebb, bár csak elivleg, mert egyrészt ezt mondja:

You can set default values for environment variables using a .env file, which Compose automatically looks for in project directory (parent folder of your Compose file). Values set in the shell environment override those set in the .env file.

 később meg ezt:

You can set default values for any environment variables referenced in the Compose file, or used to configure Compose, in an environment file named .env. The .env file path is as follows:

  • Starting from v1.28, the .env file is placed at the base of the project directory.
  • Project directory can be explicitly defined with the --file option or COMPOSE_FILE environment variable. Otherwise, it is the current working directory where the docker compose command is executed (v1.28).
  • For versions older than v1.28, it might have trouble resolving .env file with --file or COMPOSE_FILE. To work around it, it is recommended to use --project-directory, which overrides the path for the .env file. This inconsistency is addressed in v1.28 by limiting the file path to the project directory.

kiemelések tőlem, szóval vagy a docker-compose.yml könyvtára, vagy a $PWD, ahol a .env-et keresi. Sajna az utóbbira tippelnék, mert szerintem csak az elején írtak faszságot, de ki tudja, hátha.

( NevemTeve | 2022. 11. 29., k – 17:32 )

Szerkesztve: 2022. 11. 29., k – 17:33

Talán ilyesmi lehetne:

HomeDir=$(cd $(dirname "$0"); pwd -P)
cd "$HomeDir"

( hrgy84 | 2022. 11. 29., k – 17:56 )

Szerkesztve: 2022. 11. 29., k – 17:59

Egy nagyon fontos infót nem írtak le itt a kollegák. A docker-compose.yml esetében, ha a mappát ponttal (.) adod meg, akkor az a docker-compose.yml -t tartalmazó mappa lesz. Tehát, ha relatív útvonalvezetést használsz, akkor a docker-compose.yml -t tartalmazó mappától számítva is tudsz útvonalakat megadni. Így nem kell égetni az útvonalat (ami nagyon megköti a környezetet, nem költöztethető, nem lesz kipróbálható lokális gépen, stb), és nem kell kívülről definiált environment változóra hagyatkozni.

Amit én javaslok kipróbálásra (ha docker-compose -ban gondolkodtok, és nem merül fel a Kubernetes), az a POCO https://github.com/shiwaforce/poco

Ezt eredetileg házon belül fejlesztettük ki, de közkinccsé tettük, mert sokak számára hasznos lehet.

A lényeg: a projekt gyökerében tudsz lerakni egy poco.yml fájlt, amiben különböző scenariok (plan-ek) mentén különböző konténereket tudsz elindítani.

Példa konfig:

# ez még lokálisan hajtódik végre
before_script:
  - mkdir -p docker/mnt/backend/log 
  - mkdir -p docker/mnt/frontend/logs
  - cd docker/scripts && chmod +x *

# Globális, minden plan-re vonatkozó környezetek
environment:
  include: docker/conf/default/conf.env

plan:
  # Elindítjuk a teljes stacket
  default:
    docker-compose-file:
      - docker/db-proxy.yml
      - docker/dc-db.yml
      - docker/dc-backend.yml
      - docker/dc-frontend.yml
    environment:
      include:
        - docker/conf/backend/conf.env
        - docker/conf/frontend/conf.env
  # csak a backend indul el
  be:
    docker-compose-file:
      - docker/dc-db.yml
      - docker/dc-backend.yml
    environment:
      include:
        - docker/conf/backend/conf.env

Az egyes planeket a poco up PLAN segítségével indítod el. De lehetőség van pl plan-specifikus environment változók definiálására is, így különféle derivációkra van lehetőség benne. A lényeg, hogy egy egyparancsos indítást tudsz megvalósítani többféle konfigurációra.

Mi úgy csináljuk, hogy a docker-compose -os fragment YML-ek azok egy flat könyvtárszerkezetben vannak, és a globálisan behívott docker/conf/default/conf.env -ben van definiálva egy PROJECT_ROOT nevű változó, ami relatív hivatkozással tartalmazza a git repo gyökerére való hivatkozást, a fenti példában ez "PROJECT_ROOT=.." -ot tartalmaz (a docker mappánál eggyel kijebb kezdünk), és az egyes fragmentekben már minden volume mount útvonal ami a projekten belülről jön, úgy van behivatkozva, hogy:

# docker/db-proxy.yml
version: "3"

services:
  proxy:
    image: nginx:1.23
    ports:
      - 8080:80
      - 8443:443
    volumes:
      - ${PROJECT_ROOT}/docker/mnt/proxy/log:/var/log/nginx
      - ${PROJECT_ROOT}/docker/conf/nginx:/etc/nginx

Érdemes emiatt egy mappában tartani a Docker Compose konfigokat.

Arra figyelj, hogy ez egy régi projekt, és még nem a hivatlaos Docker Compose pluginre épül, hanem a Pythonban írt docker-compose utilityre. Nem sok különbség van, de azért van.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-