Size: a a a

DevOps — русскоговорящее сообщество

2020 August 03

DF

Dmitry Frolov in DevOps — русскоговорящее сообщество
Виталий Калюжняк
Ребят привет. Есть вопрос на счет docker-compose build.
Нужно сбилдить один образ, но во время билда у него есть зависимости с mysql и elasticsearch.
То есть нужно сначала поднять mysql и es, а уже после билдить app, но что бы он был слинкован с 2я верхними контейнерами.
Пробовал docker-compose.yml ниже, но даже при наличии depends_on, сначала происходит билд.
Как можно реализовать это?
services:
 mysql:
   image: mysql:5.7
   environment:
     MYSQL_DATABASE: 'main'
     MYSQL_USER: 'main'
 
es:
   image: elasticsearch:6.0

 app:
   build:
     context: .
     dockerfile: Dockerfile-app
   links:
    - mysql
    - es
   depends_on:
    - mysql
    - es
В докерфайле использовать https://github.com/eficode/wait-for?
источник

DF

Dmitry Frolov in DevOps — русскоговорящее сообщество
и в конце докерфайла убивать контейнеры БД
источник

ВК

Виталий Калюжняк... in DevOps — русскоговорящее сообщество
это не совсем то что нужно.
если я буду wait-for использовать в command:, то в любом cлучае сначала будет билд, а когда он закончится, то выполнится wait-for
источник

ВК

Виталий Калюжняк... in DevOps — русскоговорящее сообщество
а если в Dockerfile, то он подождет. зависимости не запустятся, потому что билд еще не завершен
источник

i

iPrior in DevOps — русскоговорящее сообщество
Виталий Калюжняк
а если в Dockerfile, то он подождет. зависимости не запустятся, потому что билд еще не завершен
тогда может shell скрипт и не в компосе запускать/билдить, а в докере... вначале сбилдить mysql + es, запустить их
потом сбилдить апп
опустить mysql + es
источник

DF

Dmitry Frolov in DevOps — русскоговорящее сообщество
Виталий Калюжняк
а если в Dockerfile, то он подождет. зависимости не запустятся, потому что билд еще не завершен
Да, точно. Значит не compose-ом, а скриптом.
источник

DF

Dmitry Frolov in DevOps — русскоговорящее сообщество
Вообще CI сюда напрашивается. Можно, кстати, gitlab-runner-ом в локальном режиме (gitlab-runner exec) это сделать.
источник

ВК

Виталий Калюжняк... in DevOps — русскоговорящее сообщество
iPrior
тогда может shell скрипт и не в компосе запускать/билдить, а в докере... вначале сбилдить mysql + es, запустить их
потом сбилдить апп
опустить mysql + es
тогда нужно создавать отдельную сеть, всем контейнерам назначать статику, ибо линковки не будет, имена, полуавтоматом выключать и удалить каждый. Сильно сложная и костыльная реализация получается)
Проще тогда подготовить образ с mysql+es и билдить уже в нем, а результат (получившиеся файлы) перекидывать в другой образ COPY —from
источник

i

iPrior in DevOps — русскоговорящее сообщество
Виталий Калюжняк
тогда нужно создавать отдельную сеть, всем контейнерам назначать статику, ибо линковки не будет, имена, полуавтоматом выключать и удалить каждый. Сильно сложная и костыльная реализация получается)
Проще тогда подготовить образ с mysql+es и билдить уже в нем, а результат (получившиеся файлы) перекидывать в другой образ COPY —from
а по тегу они разве не будут?
источник

ВК

Виталий Калюжняк... in DevOps — русскоговорящее сообщество
Тут и так CI :)
После коммита и запускается билд образа, но пока это 3 шага, сбор артефактов, билд образа и пуш в режестри. Получается нужно еще добавить 4 шага, поднять 2 контейнера и удалить 2 контейнера
источник

ВК

Виталий Калюжняк... in DevOps — русскоговорящее сообщество
iPrior
а по тегу они разве не будут?
Между ними не будет линковки, по тегу не должно работать
источник

i

iPrior in DevOps — русскоговорящее сообщество
Виталий Калюжняк
Между ними не будет линковки, по тегу не должно работать
ну вот так если на вскидку сделать, по тегу они друг-друга не увидят?
мне что-то самому интересно стало

#!/usr/bin/env bash

# создаём общую сеть
docker network create [OPTIONS] NETWORK

# запускаем mysql
docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...] --network=ИМЯ_НАШЕЙ_СЕТИ -t=MYSQL
# запускаем es
docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...] --network=ИМЯ_НАШЕЙ_СЕТИ -t=ES
# запускаем app
docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...] --network=ИМЯ_НАШЕЙ_СЕТИ -t=APP

# удаляем всё
docker container rm -f MYSQL
docker container rm -f ES
источник

АП

Артур Пранкевич... in DevOps — русскоговорящее сообщество
Виталий Калюжняк
тогда нужно создавать отдельную сеть, всем контейнерам назначать статику, ибо линковки не будет, имена, полуавтоматом выключать и удалить каждый. Сильно сложная и костыльная реализация получается)
Проще тогда подготовить образ с mysql+es и билдить уже в нем, а результат (получившиеся файлы) перекидывать в другой образ COPY —from
а нельзя написать docker-compose файл с депенденси?
источник

ВК

Виталий Калюжняк... in DevOps — русскоговорящее сообщество
Артур Пранкевич
а нельзя написать docker-compose файл с депенденси?
Не, в любом случае сперва идет билд, а уже если он не зафейлился, но стартуют сервисы по приоритетам
источник

АП

Артур Пранкевич... in DevOps — русскоговорящее сообщество
ну так dependency в compose и подключи докер файлы для билда
источник

АП

Артур Пранкевич... in DevOps — русскоговорящее сообщество
сперва подымется база к примеру в контейнере а потом запустится билд АПП
источник

ВК

Виталий Калюжняк... in DevOps — русскоговорящее сообщество
Артур Пранкевич
ну так dependency в compose и подключи докер файлы для билда
ты говоришь ор depends_on?
источник

АП

Артур Пранкевич... in DevOps — русскоговорящее сообщество
да
источник

ВК

Виталий Калюжняк... in DevOps — русскоговорящее сообщество
У него другая логика, он не работается при сборки, только при запуске. То есть сначала будет билд app, потом запуск mysql, потому что depends_on в app, а потом уже запуск app
services:
 mysql:
   image: mysql:5.7
   environment:
     MYSQL_DATABASE: 'main'
     MYSQL_USER: 'main'

 app:
   build:
     context: .
     dockerfile: Dockerfile-app
   links:
    - mysql
   depends_on:
    - mysql
источник

i

iPrior in DevOps — русскоговорящее сообщество
Виталий Калюжняк
тогда нужно создавать отдельную сеть, всем контейнерам назначать статику, ибо линковки не будет, имена, полуавтоматом выключать и удалить каждый. Сильно сложная и костыльная реализация получается)
Проще тогда подготовить образ с mysql+es и билдить уже в нем, а результат (получившиеся файлы) перекидывать в другой образ COPY —from
ну даже если и так, то не велика задача как мне кажется (а я могу сильно ошибаться так как больше Dev нежели Ops)

статика вроде так задаётся
docker network connect --ip 10.10.36.122 multi-host-network container2

а резолвить имена можно вот так:

--dns-opt  A key-value pair representing a DNS option and its value. See your operating system’s documentation for resolv.conf for valid options.
источник