Несколько вопросов по развертывании докер контейнеров на сервере?

Question

[Narts]

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

1. терминология: есть докер-образы - упакованные образы различных приложений (linux, node, mysql etc). чтобы запустить этот образ на сервере, мы поднимаем контейнер, внутри которого - нужный нам образ.

если наше приложение состоит из нескольких образов (mysql + redis + образ из dockerfile), мы используем docker-compose.

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

2. я через docker-compose поднял бд mysql и хочу прокинуть в контейнер env-ы. как это лучше сделать, прямо в docker-compose.yml или создать файл .env и его пусть указать в docker-compose?

3. правильно ли я понимаю, что docker-compose.yml в гит веб-приложения не идет? то есть флоу такой: если я разработчик, то просто локально запускаю нужные контейнеры (можно даже не через docker-compose, а просто через docker); если я девопс, то я получаю от разраба требования по конфигу, по env-aм, на основании этого сам собираю docker-compose.yml и разворачиваю на сервере?

смущает просто, что в docker-compose.yml может быть какая-та сенситив (креды от бд, etc) или ненужная информация (названия сетей networks, название контейнеров), которые к самому проекту особо не относятся и могут отличаться у меня на локальном компе и на сервере и соответственно в гит можно не ложить этот файлик

Comments

[Drno]

ложить и не надо. надо класть...

Answer 1

[Дмитрий]

1. понимаешь неправильно. контейнер и образ (image) это разные сущности. нет, если ты используешь docker-compose три образа не сольются сами в один контейнер. docker-compose это просто способ автоматизировать немного рутины при работы с докером.
2. в целом верно. заранее делаешь .env c нужными переменными.
3. хранишь все в .env , его добавляешь в .gitignore , ему в гите делать нечего. docker-compose.yml в гите хранят, никаких проблем, все секретное в .env или подставится из CI/CD системы , Дженкинса или GitHub Actions например, в процессе деплоя. Это головняк девопса, а не разработчика.

Answer 2

[mureevms]

1. Образ и контейнер это разные сущности:
Образ - это сущность, которая образуется после команды docker build, затем которая может быть помещена в регистри или в докер хаб. Можно провести аналогию с ISO образом ОС.
Контейнер - это сущность, которая образуется после команды docker run. Т.е. контейнер - это определенным образом запущенный образ. Можно из одного образа запустить множество контейнеров

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

контейнер !== образ, а контейнер === сервисы, где сервис === образ

Контейнер != образ, факт.
Контейнер может быть сервисом, а может и не быть, все зависит от того, что внутри.
Сервис != образ. В данном случае нет понятия сервиса, это что-то внутри контейнера. Если там демон, принимающий запросы - это сервис. В широком смысле образ это образ и он ничему не равен.
2. Как будет удобно, не принципиально. Но раз уж есть compose, то через него будет удобнее
3. Нет причин не хранить docker-compose.yml в репе. Главное, чтобы в нем не было секретов. Все "ненужное" должно быть вынесено в переменные. Далее, как и сказал Дмитрий, надо правильно доставить это на прод