Docker-compose для начинающих простыми словами _ Проект GSpot

докер композ докер композ используется для запуска нескольких связанных сервисов .

по сути он запускает все те же самые команды докера , которые можно нагромозить в командой строке .

только все это в более удобном плоском и наблядном виде армии яму файла в деклатином стиле docker-compose нет ничего такого что нельзя было бы запустить одной или несколькими командами там docker-build , docker-run с кучей переданных аргументов зачем нужен docker compose ?

во-первых , это для остальных разработчиков для нашей локальной разработки чтобы можно было поднять сразу все сервисы и спокойно работать .

во-вторых , compose file является некой документацией для девопса , для инфраструктурщиков .

такая некая сигнал-актуальная документация , где указаны какие порты , какие вольюмы , там связи между сервисами , как вообще работать с этим человеком , который не разрабатывал эти сервисы , этот композ .

желательно , чтобы композ был в репозитории в таком виде , в котором можно сразу взять его и запустить , чтобы были там указаны все переменные окружения , хоть какие-то там для примера , чтобы это все запускалось .

а не так , чтобы запустить композ , нужно еще в 50 местах что-то дописать пройдем по основным моментам здесь у нас указывается название сервиса который станет названием контейнера , если не указан контейнер name .

название тогда будет состоять из названия папки , с которой запущен доктор докеркапфорс и название сервиса .

далее указывается либо имя имиджа , которое нужно спулить из registry по умолчанию в качестве registry у нас обычно dockerhub стоит либо пишется команда build и указывается путь до dockerfile который нужно сбилдить по дефолту ну если здесь стоит точка , то берется файл с именем docker file в этой же папке , откуда запущен наш docker compose также можно здесь указать контекст то есть это каталог , из которого будет собираться docker file , откуда будет копироваться файлы , инструкции docker file , копии и прочее .

можно здесь указать путь до docker file относительно контекста .

crestart – это у нас политика перезапуска контейнера .

как docker server будет обработать падение контейнера , перезапуск сервера , то есть надо ли перезапускать наш контейнер , если у нас сервер перезапустился при включении сервиса , надо ли запустить его или нет .

то есть это есть несколько политик , которые в документации подробно описаны .

in файл здесь можно указать файл с переменными окружения .

в данном случае эта запись не имеет смысла , потому что docker compose при команде docker composeup по дефолту подхватит этот файл с таким именем .

если у нас какое-то другое имя файла с переменным гружением , нужно здесь его указать .

возюмы – это каталоги , которые примонтируются к контейнеру .

в docker есть несколько способов монтирования .

в данном случае в таком виде в контейнер мапится папка с хоста .

здесь у нас создается dockervolume .

используется dockervolume ранее созданный с именем osgres-data .

который здесь внизу должен быть перечислен если надо здесь прописываются его настройки монтировать можно как пустые каталогии так и предназначать каталогии в котором уже есть какое-то содержимое например если в образе есть папка с нашим кодом , мы при запуске контейнера можем примонтировать вместо этой папки каталог с хоста , в котором идем в разработку и запускать наш код в docker контейнере получится что-то вроде виртуального окружения .

для локальной разработки это удобно , а сервери на продакшене в этом смысла никакого нет , но у нас весь код должен быть уже в образе .

далее у нас порты .

эта команда открывает порт asta и пробрасывает его в контейнер .

есть команда expos , есть порт .

expos просто говорит , что у нас в контейнере слушается такой порт .

ну ничего не открывает , не пробрасывает .

этот порт будет проброшен только если docker будет запущен с аргументом p .

желательно прописывать эксполус , чтобы другие разработчики понимали по какому порту нужно подключаться к нашему сервису , нашему контейнеру .

port открывает порт на хосте и пробрастывает его в контейнер на указанный порт .

вообще , в большинстве случаев нам не нужно открывать порты на хосте .

когда серверы находятся в одной сети docker , то они и так видят друг друга , могут обращаться друг другу по имени сервиса , а также видят все порты друг друга .

если мы говорим про production server , то обычно оно открывается только 80-й порт на каком-то основном сервисе , а все остальное общение между сервисами идет в виртуальной сети docker .

при локальной разработке можно открывать порты , если вы планируете возвращаться , например , к базе данных напрямую с консоли или из какой-то gui панели .

для общения сервисов внутри докера , внутри одной виртуальной докеровской сети это не нужно .

dpenson указывает какие сервисы нам нужно запустить до этого сервиса .

задает некоторую последовательность запуска наших контейнеров .

тут нужно понимать , что если контейнер , например , база данных начал запускаться , это не значит , что он сразу же готов слушать запросы к себе .

запуск обычно занимает какое-то время .

если наш контейнер запустился раньше , чем база данных начала слушать .

если он запустился и сразу начал стучаться в контейнер базы данных , то он может не достучаться , так как база данных еще не поднялась , не готова слушать .

если эта ситуация никак не обрабатывается , то контейнер может упасть , не дарвавшись ответа от вас данных .

для этого у нас есть health check .

по health check'ам docker server определяет , во-первых , это момент , когда контейнер упал , и его надо перезапускать .

во-вторых , переход из состояния контейнера starting в состояние healthy , то есть здоров .

пока контейнер не придет в состояние healthy , он считается незапущенным , и другие сервисы , зависящие от него , не запускаются .

сам холлс-чек представляет собой либо http запрос какой-то простенький , либо команда shell , которая запускается с определенной периодичностью .

что-то простенькое , что случится в наших сервисах .

ручки не , скажем так , определяются .

есть ответ , нет ответа .

соответственно , живой сервис или не живой .

в networks перечисляются в виртуальной сети docker , в котором будет подключен контейнер .

если ничего не указано , то compose создает сеть default для этих сервисов .

все сервисы указанную docker compose живут в одной сети там primates default будет сеть , если мы никакую не указываем .

в данном случае у нас бэкэндов много , желательно как-то здесь дать внятное имя , чтобы наши бэкэнды жили в разных сетях , чтобы наглядно понятно было , к какому бэкэнду относится сеть .

и для общения между разными бэкэндами нужно будет выделить какую-то отдельную сеть , остальное желательно изолировать друг от друга .

сети перечисляются здесь внизу .

также мы можем подключить какую-то внешнюю сеть .

дальше указав параметр external равно true .

если мы ранее запустили какой-то комплс файл , например , там уже была создана сеть , мы можем здесь ее прописать и к ней подключиться также , если нам нужно переназначить какие-то параметры docker compose мы можем использовать файлик docker-compose.override.yaml переназначить , как добавить какие-то поля к сервису или переназначить какие-то свойства сервиса и использовать например docker compose для продакшена и взять файлик docker compose override и в нем что-то дописать и использовать его в локальной разработке .

при команде docker compose app он подтянет оба файла docker compose и docker compose уверяет .

запишет или дополнит те поля , которые у нас есть в docker compose .

с вами был игорь негода .