volumes: - ./../data/:/var/www/html/content/plugins/data/:cached

?

ща чето про клауд будет видимо

Да уже ж живо

я могу привязать докер с host mode на какой-то один IP или интерфейс? Или он по дефолту на все цепляется

A в gitlab/dind нелзя мультистейдж билды делать что ли? Я посмотрел, там какая-то древняя версия докера ставится и он COPY —from не понимает даже

я могу привязать докер с host mode на какой-то один IP или интерфейс? Или он по дефолту на все цепляется

Нет, он шарит стек сетевой с хостом, но в настройках самого приложения ты можешь определить пару ip:port, на котором он должен слушать

Или на хостовой тачке настроить файрволл

а можно как-то форвардить все порты на один IP? вроде можно -p 1.1.1.1:80, но я не вижу опции range портов

короче можно -p 192.168.2.136::1-65535 и получайте 65535 правил в iptables))

короче можно -p 192.168.2.136::1-65535 и получайте 65535 правил в iptables))

Ну, это же бе

ну это то что надо - бинд на один ИП, но я не понимаю - в докере не слышали про range портов в iptables что ли?

ну это то что надо - бинд на один ИП, но я не понимаю - в докере не слышали про range портов в iptables что ли?

Скорее про ipset

Всем добрый вечер! И снова хочется попросить объяснить одну вещь: поведение инструкции depends_on в Docker Compose. Иногда, после обновления app контейнера, обновляются и рестартуются все прописанные в depends_on контейнеры, в которых ничего не изменялось, а периодически нет. Кто может объяснить такое поведение?)

Нашёл только issue от 18 марта этого года, но там, вроде как, пофиксили. Но что-то как-то нифига=\

Всем добрый вечер! И снова хочется попросить объяснить одну вещь: поведение инструкции depends_on в Docker Compose. Иногда, после обновления app контейнера, обновляются и рестартуются все прописанные в depends_on контейнеры, в которых ничего не изменялось, а периодически нет. Кто может объяснить такое поведение?)

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

Версия последняя

Тем более, если они валятся при обращении к своему сервису-зависимости

Не. Зависимые сервисы не обновлялись. Обновлялся, так скажем, главный сервис, у которого есть зависимые сервисы

Пример компоуза в студию и описание кейса

Можешь выслать специфичные вещи

И такой способ видел: https://t.me/docker_ru/110079 Да?

version: '3.7' x-common_settings: &common restart: always networks: - test x-logger: &logger logging: driver: fluentd options: fluentd-address: 'localhost:24224' tag: 'docker.{{.Name}}' services: &fluentd-service fluentd: image: fluentd-slave container_name: *fluentd-service build: ./fluentd/ volumes: - ./fluentd/conf/:/fluentd/etc/ ports: - "24224:24224" - "24224:24224/udp" <<: *common &postgres-service postgres: image: postgres:10-alpine container_name: *postgres-service depends_on: - *fluentd-service volumes: - data_db:/var/lib/postgresql/data/ <<: *common <<: *logger &redis-service redis: image: redis:5-alpine container_name: *redis-service depends_on: - *fluentd-service volumes: - redis_db:/data/ <<: *common <<: *logger &app-service app: image: myapp container_name: *app-service depends_on: - *fluentd-service - *postgres-service - *redis-service <<: *common volumes: data_db: redis_db: networks: test: external: true

И вот в этом конфиге при обновлении app иногда обновляются и все зависимые компоненты

Why?=\

В смысле постгрес и редис?

Как запускаешь? Команда ?

Все компоненты

docker-compose up -d

Не должен

Только если флюент не складывается...

Ну, и вообще твой конфиг неудобный - docker logs'ом логи не почитать

Fluentd рестартится после постгреса каким-то образом, а там дальше по цепочке

Драйвер docker logs не даст запустить, это да

Вообще у тебя оверинжиниринг с ямл-якорями

Зачем ?

x-common-settings, x-logger - это ок

Вроде же удобно и понятно. И строчек меньше

Дублировать одно и то же не люблю)

*redis-service и аналоги - я это не понимаю

Забудешь где-нибудь поменять и всё. А тут поменял в одном месте и радуйся

Ты наоборот в два раза больше текста написал

Гипотетически - да)

Практически - да.

Но разве якоря не для такого удобства сделаны?

Нет, не для такого

x-common-settings, x-logger - это ок

Для этого - да

*redis-service и аналоги - я это не понимаю

Для этого - нет

Т.е. лучше в container_name, links, depends_on дублировать, например, слово postgres?

Ну, и за 3-й формат компоуза ты наверняка знаешь все сам

(он не нужен)

Да, знаю

Т.е. лучше в container_name, links, depends_on дублировать, например, слово postgres?

Да

И согласен

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

А 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?

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

поддержу