"DB_HOST=db",

docker-compose exec web sh -c "echo $DB_HOST"

ой, имя другое, исправил

пусто

а остальные env переменные?

и до этого работало все ок, так?

там все порядке

ага

тогда я тут самоустраняюсь, к сожалению проблема, видимо, с сетью, а я у меня одну дефолтную юзаю

docker-compose exec web sh -c "echo $DB_HOST"

вот это вообще ничего не выводит и других переменных

хм, секунду

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

пока убрал нетворги

все работает

че странное я в .env указал переменную NODE_ENV=production но в docker inspect он пустой

Подскажите для HEALTHCHECK ответ должен быть в каком то определнном формате или просто код 200 ОК?

Healthcheck вроде exit code проверяет, не?

именно так, только exit коды

0 или 1

есть Dockerfile в котором я делаю COPY и есть volumes в docker-compose в котором делаю тоже самое, в чем разница?

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

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

что значит переподключается?

что значит переподключается?

https://docs.docker.com/storage/volumes/

https://docs.docker.com/storage/volumes/

грубо говоря он не хранит сами файлы там а просто как ссылка на саму директорию?

я не знаю подробностей как он переносит туда файлы, но думаю, что делает ещё один слой для каждого volume при создании контейнера

что значит слой?

https://docs.docker.com/storage/storagedriver/overlayfs-driver/#how-the-overlay-driver-works

https://docs.docker.com/storage/storagedriver/overlayfs-driver/#how-the-overlay-driver-works

получается в принципе я могу не делать COPY на докерфайле

а сразу на docker-compose

или docker-compose берет файлы не с хоста а с image?

нет, compose берёт файлы с хоста, в image никто не лезет

получается в принципе я могу не делать COPY на докерфайле

можно, это зависит от задачи

иногда файл нужен для билда image

иногда файл нужен для билда image

volumes: - ./:/usr/src/app он в /var/lib/docker/volumes создаст volume?

Нет, будет ошибка синтаксиса. И нет, не создаст, он будет использовать текущий каталог. Кстати, я скорее всего был не прав насчёт нового слоя. Вроде мне удалвалось в рантайме менять файл на хостовой ФС и он уже был в контейнере. Хотя может меня плющит к вечеру.

volumes: - ./:/usr/src/app он в /var/lib/docker/volumes создаст volume?

Ты можешь сам попробовать запустить такой сервис, зачем спрашивать, если я могу врать)

просто проверил уже не создает он ничего

он просто в рантайме берет напрямую с хоста кажется

Нет, будет ошибка синтаксиса. И нет, не создаст, он будет использовать текущий каталог. Кстати, я скорее всего был не прав насчёт нового слоя. Вроде мне удалвалось в рантайме менять файл на хостовой ФС и он уже был в контейнере. Хотя может меня плющит к вечеру.

ну да, с вольюмами если изменилось на хосте - изменится и внутри

copy добавляет файлы с хоста в образ volume связывает файлы хоста и контейнера контейнер - это то, что в рантайме образ - по аналогии это то, что в компайлтайме

а как по докер контейнерам распределяются ресурсы сервера? или как они вообще с ними связаны? если на сервере 2 гиг оперативки, и там с десяток контейнеров, то как понять кто сколько использует?

copy добавляет файлы с хоста в образ volume связывает файлы хоста и контейнера контейнер - это то, что в рантайме образ - по аналогии это то, что в компайлтайме

а зачем добавлять файл в образ? если можно сразу в контейнер?

а зачем добавлять файл в образ? если можно сразу в контейнер?

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

Парни вопрос; сижу читаю теорию и задался вопросом а docker уже поддерживает cgroup v2?

Парни вопрос; сижу читаю теорию и задался вопросом а docker уже поддерживает cgroup v2?

тебя такие вопросы не должны волновать)

Ну вот почему же. Вот на 3 Сообщения выше вопрос Никиты

А ответ в теории ) я пока не протыкал но ему никто не мешает посмотреть что там в cgroups

https://habr.com/company/selectel/blog/303190/

всем утра) можете напомнить, как посмотреть dockerfile в образе, если там нет вкладки или после скачивания можно как то его увидеть? например, вот этот образ https://hub.docker.com/r/tutum/lamp/

https://github.com/tutumcloud/lamp/tree/master

всем утра) можете напомнить, как посмотреть dockerfile в образе, если там нет вкладки или после скачивания можно как то его увидеть? например, вот этот образ https://hub.docker.com/r/tutum/lamp/

инспект

docker inspect container_id

такие вещи проще через docker-compose делать, не?

не зря, видимо, помечено как deprecated

такие вещи проще через docker-compose делать, не?

какие? читать докерфайл?

не

собирать php + mysql

какие? читать докерфайл?

кстати, как инспект поможет узреть исходник докерфайла?

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

кстати, как инспект поможет узреть исходник докерфайла?

полностью не поможет, но покажет как собирался, команды

а, понял. анализировать и восстанавливать картину самому.

именно так

есть разные более сложные варианты, но ничего толкового я не находил

ERROR: S client not available

полностью не поможет, но покажет как собирался, команды

Не надо несколько сервисов в один контейнер — это порочная практика

скажите, какое заклинание нужно докеру сказать, чтоб он перестал в мой айпитейблес со своими правилами лезть??

скажите, какое заклинание нужно докеру сказать, чтоб он перестал в мой айпитейблес со своими правилами лезть??

https://docs.docker.com/network/iptables/

http://bfy.tw/IgQu

да, я добавлял в daemon.json, все равно модицифировало. буду смотреть

Не надо несколько сервисов в один контейнер — это порочная практика

Что? Это вообще к чему?

К тому что не надо несколько сервисов в один контейнер

services: minio1: image: minio/minio:RELEASE.2018-06-09T03-43-35Z volumes: - data1:/data ports: - "9001:9000" environment: MINIO_ACCESS_KEY: minio MINIO_SECRET_KEY: minio123 # command: server http://minio1/data http://minio2/data http://minio3/data http://minio4/data command: server http://minio1/data volumes: data1: driver: host driver_opts: source: /home/sat/minio-test/volumes/data1 Ребят как правильно ссылки на тома описывать? Дока в подробности не сильна

я объявил проброс томов для сервиса и хочу в конце композа указать где том лежит

Парни вопрос, с утра что то не догоню. Есть самописной приложение, которое хочу убрать в докер, чтобы разрабы могли сами поднимать его. Но конфиг его при этом могли править. То есть по уму через volume оставлять в хвостовой системе. Вопрос как идеологически правильно. Чтобы у разрабов работала без гемороя, типа docker run, ведь ложить конфиг внутрь контейнера не вариант

для разработки - вольюмы, для деплоя - зависит от потребностей

Просто мне то антиблом не проблема поднять контейнер и положить конфиг

А разрабы они же часто - поднялось значит работает. И будут править конфиг внутри контейнера

Чего я избежать хочу

какие-то странные разрабы, если честно у тебя один прод сервак?

ты главное разрабов на прод конфиги не пускай ну их нафих

у меня так есть docker-compose, файлов несколько - просто docker-compose.yml, docker-compose.server.yml, docker-compose.prod/qa.yml

стейдж выдели пусть приводят в порядок - тесты пройдут недельку и пускай

и через энв переменную определяется, где что запускать

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

Конфиг хранить на хосте. А не в контейнере. Потом отдать это разрабам. Не нравиться, что появляется человеческий фактор. Прочтёт ли он доку - что надо конфиг положить в правильное место или нет

Просто в теории разрабы могут взять мой докер композ файл и поднять это хоть на своё ноуте

Если им приспичит

Идея контейнеров в том что они неизменны. Поэтому снаружи контейнеров только данные а конфиг всегда внутри. Если надо изменить конфиг, то собирается новый образ

И это правильно. В идеале ещё и версию контейнера бампать с каждым изменением

Вот про данные понимаю. Про конфигурирование никогда не считал что они не изменяемые. Подумаю об этом на досуге

Чтобы на проде можно было ставить прямое указание на версию для деплоя

Но условно конфиг для прода и дева может отличаться

И очень существенно

Используй какой-нибудь Ansible, чтобы рулить конфиги и сборки.