Второй был лучше

А links ни нужен, юзай networks

Второй был лучше

Если сворма нет, то 3.* не нужен

Но, в конце концов, придётся переходить на последнюю версию

А links ни нужен, юзай networks

Это я как пример сказал)

Третий для сворма, да

Но, в конце концов, придётся переходить на последнюю версию

Ее нет. 2.4 - последняя. 3.7 - для сворма

Но сейчас думаю, что, в связи в небольшим бюджетом, может и сворм подрубить...

Касательно перезапуска - рекомендую посмотреть в логи флюента

Он может вызывать каскадный рестарт. Наверное

Смотрел. Дельного там ничего нет(

Такими темпами просто depends_on уберу, если будет так дальше делать

В моём случае просто это можно сделать

Он может вызывать каскадный рестарт. Наверное

Спасибо за ответ и советы!

В который раз выручаете)

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

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

Если бы ты сразу спросил, то может уже и подсказали бы. Откуда такая любовь к мета-вопросам?

спросить почему отваливается drush

Есть ли какая-нибудь утилитка с UI для управления регистри?

возьми регистри с уже готовым уай - например, harbor

а вот так чтобы управлять... нет, такого не видел

А можно сделать в docker-compose что бы один volume всегда удалялся при остановке или пересборке? Или может есть какой-то способ прокинуть папочку подготовленную одним контейнером в другой, не через volume?

Именно прокинуть - только через директиву volume мне кажется. Именно волюмом или просто можно папку подмонтировать. Удалять тоже мне кажется нельзя. Но можно вместо прямого вызова docker-compose накидать bash скрипт. Или просто через && вызывать удаление контейнера.

нет. Пользуйтесь ansible

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

Именно прокинуть - только через директиву volume мне кажется. Именно волюмом или просто можно папку подмонтировать. Удалять тоже мне кажется нельзя. Но можно вместо прямого вызова docker-compose накидать bash скрипт. Или просто через && вызывать удаление контейнера.

либо баш-скрипт, ога. А можно мейкфайл. А можно плейбук на ансибле

не знаю - что лучше

Думаю зависит от конкретной задачи. Постановка вопроса не полная. Не ясно, что больше подойдёт.

а если volume указать не персистентную файловую систему, это не будет очищать volume?

а если volume указать не персистентную файловую систему, это не будет очищать volume?

Попахивает извращениями, не? ))

поддержу

volume на то и вольюм, чтобы переживать остановку контейнера. Либо https://t.me/docker_ru/131091

А, есть совет

те файлы, которые реально нужны - пробрасывайте через bind mount (-v path_host_system:path_in_container)

а те файлы, которые не очень нужны - пихайте в вольюм (именно вольюм,-v NAME_OF_VOLUME:path_in_container) Тогда вольюмы можно грохнуть docker-compose down -v, а файлы в файловой системе через bind mount останутся (!)

@egor777ka @ivgenich

Да. Канает. Но все равно сама задача не очень ясна. Но это вполне себе решение.

В одном контейнере Django + gunicorn, Django собирает статику и ложит в папочку. Во втором контейнере nGinx он смотри в эту папочку и отдаёт эти файлики когда клиент запрашивает статику. Мне бы хотелось что бы при билде эта папочка каждый раз пересобиралась, а то там какое-то хитрое кэширование и если волюм не грохнуть, то статика будет лежать старая.

а вот так чтобы управлять... нет, такого не видел

да мне нужно удалить старые данные.

В одном контейнере Django + gunicorn, Django собирает статику и ложит в папочку. Во втором контейнере nGinx он смотри в эту папочку и отдаёт эти файлики когда клиент запрашивает статику. Мне бы хотелось что бы при билде эта папочка каждый раз пересобиралась, а то там какое-то хитрое кэширование и если волюм не грохнуть, то статика будет лежать старая.

При сборке статики запихивай её в контейнер с nginx

root@srv01:~# docker restart 54f514346c22 Error response from daemon: Cannot restart container 54f514346c22: id already in use

чертов докер. Не дает запустить контейнер со статусом Exit. Пожалуй-ка, пересоздам я его

а еще прекрасно вот это 250874: veth1dabaf2@if250873: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default link/ether de:4a:6d:da:a0:10 brd ff:ff:ff:ff:ff:ff link-netnsid 37 inet6 fe80::dc4a:6dff:feda:a010/64 scope link valid_lft forever preferred_lft forever 250876: veth24fb1d2@if250875: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default link/ether 8a:08:9c:d7:50:c0 brd ff:ff:ff:ff:ff:ff link-netnsid 39 inet6 fe80::8808:9cff:fed7:50c0/64 scope link valid_lft forever preferred_lft forever 250878: veth45ee712@if250877: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default link/ether 96:93:a5:3e:73:9c brd ff:ff:ff:ff:ff:ff link-netnsid 40 inet6 fe80::9493:a5ff:fe3e:739c/64 scope link valid_lft forever preferred_lft forever

как минимум - это вызывает проблемы с вмварью

я с таким говном, например, наелся https://bugs.debian.org/756808

При сборке статики запихивай её в контейнер с nginx

Как это сделать?

Как это сделать?

FROM node:8-slim AS builder RUN mkdir /front WORKDIR /front COPY ./front . RUN npm install --silent RUN npm run prod FROM nginx:1.15.2-alpine COPY ./docker/nginx/nginx.conf /etc/nginx/conf.d/default.conf RUN rm -rf /usr/share/nginx/html/* COPY --from=builder /dist /usr/share/nginx/html/palisad/dist CMD ["nginx", "-g", "daemon off;"]

FROM node:8-slim AS builder RUN mkdir /front WORKDIR /front COPY ./front . RUN npm install --silent RUN npm run prod FROM nginx:1.15.2-alpine COPY ./docker/nginx/nginx.conf /etc/nginx/conf.d/default.conf RUN rm -rf /usr/share/nginx/html/* COPY --from=builder /dist /usr/share/nginx/html/palisad/dist CMD ["nginx", "-g", "daemon off;"]

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

это не играет роли.

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

это не играет роли.

Предлагаешь по 2 раза одно и тоже делать при сборке?

контейнер с статикой и бэком, на nginx разруливаешь трафик

возможно, что это и будет лучше

контейнер с статикой и бэком, на nginx разруливаешь трафик

nGinx должен видеть и бэк и статику(из контейнера с бэком)

в чем проблема сделать общую сеть в docker-compose ?

и обращаться к ним по заданым именам

В смысле как общая сеть поможет в этом?

nGinx должен видеть и бэк и статику(из контейнера с бэком)

у тебя статика на лету, что ли, генерится?

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

у тебя статика на лету, что ли, генерится?

Статика раз собирается бэком

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

да как бэком может статика собираться, что за дич?

(при условии, что ты статику налил при сборке образов)

да как бэком может статика собираться, что за дич?

А чем она должна собираться?

пришли докер файл

(при условии, что ты статику налил при сборке образов)

Я понял вариант по 2 раза делать одно и тоже.

пришли докер файл

FROM python:3 ENV PYTHONUNBUFFERED 1 RUN mkdir /code WORKDIR /code COPY requirements.txt /code/ RUN pip install -r requirements.txt COPY . /code/ RUN python manage.py collectstatic

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

ну это бэк на гуникорне, ни как не статика

и тогда из одного докерфайла ты сможешь собирать и джангу, и энджинкс

Ладно, сейчас это можно решить через мультистейдж. А как делали древние люди около года назад?

они страдали

и так каждый раз на docker stop postgres

может commit ? 😉

а в docker-compose нет возможности разные контейнеры друг на друга намазывать, как в мультистейдж?

а в docker-compose нет возможности разные контейнеры друг на друга намазывать, как в мультистейдж?

в смысле? нет, вряд ли

в смысле? нет, вряд ли

Ну в смысле указать что от чего зависит можно, а вот указать что нужно вытащить из зависимого контейнера?

нет

компоуз не для этого

Подождём годик, может разрабы решат что он для этого.