докер композ докер композ используется для запуска нескольких связанных сервисов .
по сути он запускает все те же самые команды докера , которые можно нагромозить в командой строке .
только все это в более удобном плоском и наблядном виде армии яму файла в деклатином стиле 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 .
с вами был игорь негода .