1. command .... && tail -f /dev/null 2. вырубить демон и срать в консоль, не отпустит процесс - не выключиться контейнер 3. стартануть uwsgi без демона 4. забить на все и сделать docker-compose up -d, но образ надо проверить... чтоб срал по п.2,3

... &

nohup и & ляжет скорее всего

там все-таки uwsgi, гуни

вернут управление тобишь, и все

но, возможно я ошибаюсь, just try

комманды в 11, 12 строках - демоны

Как правильно упаковывать фронтенд для прода? Его должен отдавать nginx. Как их скоммутировать?

Не могу понять, запустил на vds контейнер с апачем+пхп, всё стартует, а как из сети зайти в него?

Не могу понять, запустил на vds контейнер с апачем+пхп, всё стартует, а как из сети зайти в него?

покажи как создал контейнеры.

покажи как создал контейнеры.

version: "2" services: www: build: . ports: - "8001:80" volumes: - ./project:/var/www/notification - ./apache2:/etc/apache2 links: - db networks: - default db: image: mysql:5.7 entrypoint: ['/entrypoint.sh', '--character-set-server=utf8', '--collation-server=utf8_general_ci'] ports: - "3306:3306" environment: MYSQL_DATABASE: notifications MYSQL_USER: user MYSQL_PASSWORD: test MYSQL_ROOT_PASSWORD: test volumes: - ./dump:/docker-entrypoint-initdb.d - persistent:/var/lib/mysql networks: - default phpmyadmin: image: phpmyadmin/phpmyadmin:4.6 links: - db:db ports: - 8000:80 environment: MYSQL_USER: user MYSQL_PASSWORD: test MYSQL_ROOT_PASSWORD: test volumes: persistent:

Не могу понять, запустил на vds контейнер с апачем+пхп, всё стартует, а как из сети зайти в него?

и зайти как - в баш консоль контейнера или на 80 порт апача попасть?

и зайти как - в баш консоль контейнера или на 80 порт апача попасть?

из браузера

и зайти как - в баш консоль контейнера или на 80 порт апача попасть?

чтобы просто вбить адрес в браузере и попасть на сайт, который в контейнере

чтобы просто вбить адрес в браузере и попасть на сайт, который в контейнере

твойip:8001

Не тому походу написал

О, сработало, спасибо!

Еще вопрос, как избавиться от порта?

Чтобы по прямому адресу работало

Еще вопрос, как избавиться от порта?

80-й порт наружу вытащить

Еще вопрос, как избавиться от порта?

поменяй www: build: . ports: - "8001:80" на www: build: . ports: - "80:80"

www: build: . ports: - "80:80"

Спасибо!

С башем проще docker exec -it idcontener bash

А вообще поставь ранчера и через него билдь

Проще

Товарищи, сдается мне вопрос частый и банальный, но что-то не найду ответа( При shared volume между контейнерами в docker-compose, как указать конкретно, из какого контейнера надо брать даныне? ну если шаринг между app1 app2 и app3, чтобы там данные из app1 гарантировано лежали?

shared volume это "диск" подключенный ко всем твоим контейнерам, куда ты его подключил

может неверно выражаюсь.

volumes: src:

нужен контекст, что пытаешься сделать и чего хочешь получить?

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

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

положи статику по пути который подключаешь и она будет доступна в обоих контейнерах

Он она уже в контейнере с приложением. Что значит "положить по пути"?

То есть, есть два контейнера. на хостовой машине нет ничего

а где volume?

Давай сначала. Я думал, что указав вот так (как выше) volume, я могу сделать следующее: в этот волюм попадет папка из контейнера app и я смогу ее прокинуть в контейнер nginx (то есть между контейнерами, без участия хоста)

Вот такую задачу можно решить?

$ docker volume inspect my-vol [ { "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/my-vol/_data", "Name": "my-vol", "Options": {}, "Scope": "local" } ]

Давай сначала. Я думал, что указав вот так (как выше) volume, я могу сделать следующее: в этот волюм попадет папка из контейнера app и я смогу ее прокинуть в контейнер nginx (то есть между контейнерами, без участия хоста)

насколько я помню - она на хосте все равно присутствует

вон выше кинули

во второй версии была такая директива volumes_from

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

это общее место, оно не весит в воздухе

на счет третей версии композа точно не помню

на счет третей версии композа точно не помню

в третьей нет такого

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

когда ты добавляешь volume в контейнер - ты указываешь как будет называться папка в контейнере

а, то есть в третьей версии нет?

для nginx укажи /var/www/html к примеру и она будет доступна с дефолтного хоста

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

ну смотри, сейчас у меня вот как-то так: app: volume: src:/path nginx: volumes: src:/path volumes: src: (не смотрите на отступы, пишу руками)

ну если прокидывать без named volumes - тогда вроде хостовые данные имеют приоритет

чтобы статика была доступна с Nginx - она должна лежать в папке где настроен виртуальный хост

и в `src`у меня содержимое контейнера nginx.

чтобы статика была доступна с Nginx - она должна лежать в папке где настроен виртуальный хост

мммразвивай мысль

А, то есть скорее всего при первом запуске на хосте папка создалсь

ну всё в /path будут твои данные

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

и в `src`у меня содержимое контейнера nginx.

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

у меня так

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

у меня сейчас так) я и хочу от этого уйти

и при этом папка даже может не существовать на хосте

я наоборот ушел к такому от прокинутой вольюмами папки)

У меня в gitlab ci при сборке приложения сразу и собирает образ nginx со статикой

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

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

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

именно

ну так в чем проблема то?

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

Желание: отказаться от кастомного образа nginx со статикой внутри и использовать (например) nginx официальный и просто статику волюмом в него пробрасывать с контейнера приложения

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

Согласен. У меня сейчас в голове "качели" между подходами

Теперь уже склоняюсь к тому, чтобы внутре было все

волюмы нужны при разработке

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

угу, так же считаю

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

картинку в новость там или что...

имхо можно поделить статику на 2 части - папку где ничего не меняется - зашивать, папку в которую грузят картинки и т.д. из админки проекта - делать volume, и синхронизировать раз в какое-то время через тот же rsync

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

ну картинки - это не статика, а ассеты

по уму это вообще на s3 какой надо складывать или подобную штуку

www.minio.io - крутая штука с поддержкой Amazon S3 API может кому интересно будет

Желание: отказаться от кастомного образа nginx со статикой внутри и использовать (например) nginx официальный и просто статику волюмом в него пробрасывать с контейнера приложения

Сделай на хосте папку и пробросит ее в два контейнера. Коллега же об этом выше написал

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

Сделай на хосте папку и пробросит ее в два контейнера. Коллега же об этом выше написал

Ну так этого и не хотелось. Ну пока решил ничего не менять

Я может не совсем понял вопрос. А в чем минус такого подхода? Если тебе надо с двух контейнеров на одном хост5 иметь доступ в одну папку ?

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

В образах СУБД есть папка docker-entrypoint-initdb.d оттуда sql и sh скрипты выполняются только 1 раз. При первом запуске контейнера

В образах СУБД есть папка docker-entrypoint-initdb.d оттуда sql и sh скрипты выполняются только 1 раз. При первом запуске контейнера

volumes: - ./dump:/docker-entrypoint-initdb.d Не применяет ничего

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

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

Хз как это работает с монтированием, я туда просто копировал файлы и у меня все работало

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

вы хотите композом менять контейнер не перезапуская его?)0

вы хотите композом менять контейнер не перезапуская его?)0

я останавлию все и делаю compose up —build

Я вот думаю, может надо таки удалять все контейнеры?

у вас может не пробрасываться том правильно если прав нет на точку монтирования