Антон Швец

Так и не должен видеть. Переменные из .env docker-compose вставляет только в docker-compose.yml
Чтобы передать их в билд, можно использовать вот это
https://docs.docker.com/compose/compose-file/#args

build:
  context: .
  args:
    APP_HOME: $APP_HOME

Но вообще не вижу смысла менять расположение папки с приложением. Это же изолированный контейнер. сделайте просто /app

А и еще вопрос, зачем вам nodejs внутри контейнера с ruby?

1. Контейнер это не виртуальная машина, это способ изоляции приложения.
Производительность почти не меняется. Оверхэд едва заметен.
Да, запускается несколько копий. Конечно не стоит множить ресурсоемкие процессы. Но СУБД и веб-серверы не входят в их число. У меня, например, работают 5 постгресов на одном микросервере без проблем. Опять таки, это до тех пор, пока нагрузки несерьезны.
Образы ОС запущены не будут. Они нужны только чтобы обеспечить приложению среду исполнения. В памяти висят только процессы приложений (ну то что вы в докере запустили)

2. В продакшене основной смысл это упрощение запуска микросервисов на разнообразном парке оборудования. Для классических приложений профит только в развертывании.

3. Есть разница в потраченном времени на настройку как раз redmine, gitlab и еще нескольких сервисов, установленных на хосте, и процесс запуска того же добра в контейнерах. Как раз в случае нескольких сервисов на одной машине докер всё серьезно упрощает.
Все эти rvm, nvm, этого пакета не хватает, того, а тут разные версии. Добавить сюда еще организацию бекапа.
С контейнерами другая проблема - это их корректное обновление.

Логично делать контейнеры из сервисов, которые существуют как независимые функциональные единицы и могут работать друг без друга и настраиваются независимо.
Нода и нжинкс такими являются и следует взять контейнер для ноды и контейнер для нжинкса. Так же монго, редис.
Запускать все вместе удобно с помощью docker-compose.

А насчет ОС, это уж как вам нужно. Если ваше приложение в докере нуждается в ОС, то нужна. Приведите пример где нет FROM ubuntu, debian, alpine etc

1. ping hello.dev
что показывает? должен быть 127.0.0.1
2. монтировать hosts в контейнер не нужно, если только ваш сайт не будет искать сам себя по доменному имени.
3. смотрите конфиг виртуального хоста в nginx. Скорее всего проблема в нём.
4. описывайте ситуацию детальнее. Например что именно означает "а по адресу hello.dev нет".
5. поработайте над русским. Ошибки ужасны, раздражают при прочтении.

Тебе никакой. Докер это инструмент администратора.
Если админ скажет что тестируем все в контейнере, и такой же контейнер пойдет на продакшн, то и будешь так делать. Потому что так будет удобнее.
Можно еще конечно запустить все ваши сервисы не в виртуалках, а в контейнерах. Плюс - меньшее потребление ресурсов. Минус - затраты времени на наладку.

Как организовать сеть контейнеров с помощью docker-compose?

Контейнер это не какая-то вечно запущенная сущность, с которой нужно работать.
Контейнеры должны убиваться и создаваться не затрагивая пользовательские данные (например при обновлении ПО).
В твоем случае "необходимые тебе файлы" копируешь в папку на хост системе с помощью docker cp, удаляешь контейнер и запускаешь уже с volume в этой папке.

Вот у вас же написано в описании сервиса web
links:
- db

####
Более правильно и наглядно было написать
links:
- db:db
)
####

это значит кто контейнер сервиса "db" для сервиса "web" будет доступен по адресу db
localhost внутри контейнера укажет на сам этот контейнер, айпи хоста на сам хост. Конечно по айпи хоста можно добраться до базы, поскольку проброшен порт (что и делает ваш mysql workbench), но видимо докер добавляет это правило iptables только для внешних сетей.

Если данные не требуется изменять - копируй.

1. ssh
2. установить в контейнер "app" docker, примонтировать /var/run/docker.sock и управлять докером на хосте изнутри контейнера.
Только в этом случае ваш контейнер становится всемогущим, фактически получает root на хосте.

А что в Entrypoint и в cmd?
Если процесс в докере будет завершен то и сам контейнер останавливается.

Если там например bash то нужно запускать docker run --name test -it my_image

Смотря для чего использовать.
У тебя же одно node.js приложение, тут вроде все написано https://nodejs.org/en/docs/guides/nodejs-docker-webapp/
Для разработки подключаешь весь /project как внешний том и работаешь с ним, для продакшена копируешь собранное приложение в образ посредством COPY в Dockerfile.

docker-compose к сборке образа не имеет отношения, он для описания условий запуска контейнера или связки контейнеров (плюс интерфейс для управления типа docker-compose up) . Просто удобная альтернатива длинным командам docker run с множеством ключей.

Делай docker exec _container_name_ bash или docker-compose exec _service_name_ bash
Откроет тебе баш в контейнере, правишь что нужно и выходишь ctrl-D
Основной процесс не затронет.

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

Надо смотреть что у контейнера в ENTRYPOINT
в данном случае php -r "hello world" пойдет как аргумент к энтрипойнту.
Зачастую в конце делают exec $@ то есть выполняет аргумент энтрипойнта как команду.

А что вам мешает сделать

docker run --name my-conteiner -it my-image 'php -r "hello world" > /tmp/hello'
docker exec my-conteiner cat /tmp/hello

и посмотреть что получится?

Можно засунуть все в один контейнер при желании. Странный вариант, но вполне работоспособный.

Можно держать контейнер с php+apache, а код приложения в папке рядом. Так же с node.
Не обязательно на разных портах, контейнеры можно вообще не открывать во внешнюю сеть, но тогда понадобится реверс-прокси. Это для разработки.

Можно сделать новый образ, наследуемый из php+apache и содержащий твое приложение.
Тогда достаточно будет залить один файл образа на сервер и запустить контейнер на его основе. Это для быстрого деплоя. Но надо будет у себя обновлять контейнер и повторять процедуру.