К примеру если ты хочешь что бы у тебя какие то действия выполнились в онтейнере а потом записались на него. Тебе надо сделать так

RUN действие

VOLUME data

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

В чём в этом?

А если не указывать его в Dockerfile, а сразу вольюмы монтировать, что изменится?

У меня вот так вот работает тоже, но поведение не всегда одинаковое

Я тебе уже где то писал выше. Если объявить допустим внутри контейнера /var/lib/mysql как раздел, то есть -v mysql:/var/lib/mysql то у тебя сразу примонтирется данная папка как раздел, и на нее будет нормально идти запись.

То есть проиницилизируется mysql к примеру сразу на него

Но!!! при условие, что данный раздел будет пустой при монтирование

А если ты примонтируешь как папку

То у тебя начало, выполнится действии иницилизации базы. Это один слой

а потом данный слой перекроется монтирование папки с хоста

и все летит к ебеням. Так как примонтируется пустая папка

Так и при прописи в Dockerfile VOLUME

Допустим ты хочеть делать так

VOLUME /data RUN touch /data/test.txt

Короче это полное говно

так как VOLUME примонтироется позже

тебе надо объявлять вольюм так

RUN touch /data/test.txt VOLUME /data

В чем разница, сначало создастся файл, а потом проиницилизируется VOLUME и докер скопирует на него все файлы из слоя

Даа, не знаю, знаешь ли ты, но каждое действие в докер файле слой. Это очень важно как раз, что бы не затереть файлы

То у тебя начало, выполнится действии иницилизации базы. Это один слой

Да нет у меня такой проблемы вообще. Другая проблема есть, с конфигом, и я её описывал два раза

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

А не проще ли создать тему на том же оверфлоу и обсудить сию проблему там?

Для этого надо получить повторяемый эффект и грамотно описать, при этом выкинув всё лишнее из докерфайла и композа

Я задал довольно простой вопрос про вольюм

RUN touch /data/test.txt VOLUME /data

А куда потом денется файл test.txt, после того как поверх него будет смониторован каталог из хост системы?

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

Даа, не знаю, знаешь ли ты, но каждое действие в докер файле слой. Это очень важно как раз, что бы не затереть файлы

И это самое выносящее мозг во всём докере, что порождает сплошные грабли

https://habrahabr.ru/company/hexlet/blog/248519/

А куда потом денется файл test.txt, после того как поверх него будет смониторован каталог из хост системы?

Он перенесет данные со слоя в вольюм

https://habrahabr.ru/company/hexlet/blog/248519/

Это не проблема если использовать докер рекомендованным путем - один процесс на один контейнер

Это не проблема если использовать докер рекомендованным путем - один процесс на один контейнер

хм... не факт смотря что за процесс

хм... не факт смотря что за процесс

Да хоть какой, если использовать докер как докер, а не vm, то при выпадении родительского процесса контейнер отвалится просто.

Да хоть какой, если использовать докер как докер, а не vm, то при выпадении родительского процесса контейнер отвалится просто.

Контейнер отвалится да, важно чтобы родительский процесс имел 1 PID. Чтобы все корректно завершалось и не оставалось сирот

Контейнер отвалится да, важно чтобы родительский процесс имел 1 PID. Чтобы все корректно завершалось и не оставалось сирот

Причем тут pid? если отвалится процесс указанный в cmd/entrypoint контейнер по любом упадет

Парни, что то запутался немного. Объяснити, если я бду прописывать в разных docker-compose networks: default: Этого будет достаточно что бы все приложения смотрели в дефолтную сеть?

или все таки дописать еще к каждому приложению что то надо

и в офф документации описанно еще про driver: custom-driver-1

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

Парни, что то запутался немного. Объяснити, если я бду прописывать в разных docker-compose networks: default: Этого будет достаточно что бы все приложения смотрели в дефолтную сеть?

дефолтная сеть у тебя bridge

и в офф документации описанно еще про driver: custom-driver-1

кастомный драйвер это немного не то что ты имеешь ввиду. Это для создания изолированных сетей. Перед указанием, надо сначала ее создать

Спасибо. Тогда такой вопрос. networks: default: external: name: my-pre-existing-network

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

networks: default: # Use a custom driver driver: custom-driver-1

То чем отличается это?

это возможность привязать в режиме хост?

networks: default: # Use a custom driver driver: custom-driver-1

ты в контейнерах какую сеть делаешь? bridge host overlay?

bridge

Это просто смежный вопрос)

к теме, чем отличаться два этих примера будут)

Просто как понимаю, это как networks: default: external: name: my-pre-existing-network Как раз подключиться к созданной

bridge

с оф документации с бриджовой сетью

Это хорошо)

только у тебя наверно без сборки, просто указываешь image

Вообще вопрос был в другом, изначально)

Если будут несколько компос файлов. У них будут свои не связные подсети, если я не ошибаюсь. Так как каждый компос создает свою сеть.

Вопрос вот в чем, что бы поместить их в общую сеть бридж с 172.20.0.0/24 допустим, достаточно ли будет явно указать networks: default: И надо ли явно присваивать сеть для каждого сервиса отдельно, то есть из разряда mysql: image: mysql:8 networks: default: aliases: - mysql.lan volumes: - /opt/docker/mysql:/var/lib/mysql

Если будут несколько компос файлов. У них будут свои не связные подсети, если я не ошибаюсь. Так как каждый компос создает свою сеть.

с дефолтной сетью они буду связаны

просто не по именам

сеть то одна у тебя используется

Хорошо, а что бы по именам?)

Хорошо, а что бы по именам?)

links or service

но лучше в один компос засовывать

Так links уже устаревший, легче же в одну сеть обозначить

Так links уже устаревший, легче же в одну сеть обозначить

так она и так одна

По именам)

Так links уже устаревший, легче же в одну сеть обозначить

в смысле устаревший? depends_on был же устаревшим

Я могу ошибаться. Но у них разве не разные назначения? я как понимаю depends_on ожидает запуска контейнера. А links линкует контейнер по именни

Я могу ошибаться. Но у них разве не разные назначения? я как понимаю depends_on ожидает запуска контейнера. А links линкует контейнер по именни

ну так тебе нужна связанность контейнеров по имени?

если в одну сеть их засунуть, то по ip контейнера можешь связавать между собой

links линукует и ожидает вместе с хелсчеком

Ребят, всем доброго дня! Хочу динамически подключать новые контейнеры на ноде через docker-compose В качестве балансировщика стоит nginx Кто как реализовал данный функционал?

Ребят, всем доброго дня! Хочу динамически подключать новые контейнеры на ноде через docker-compose В качестве балансировщика стоит nginx Кто как реализовал данный функционал?

docker-gen ?

Теперь странное состояние рестартинг, у контейнера, которое висит бесконечно...

Докер в состоянии рестарта зависает и не залить базу в мускуль

# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c0c702cb6cc7 dockerproject_drupal "sh /init.sh" About a minute ago Restarting (0) 18 seconds ago 0.0.0.0:80->80/tcp, 0.0.0.0:3306->3306/tcp dockerproject_drupal_1

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

Почему права рутовые? Это не позволяет мускулю стартануть внутри докера.