multistage и вперед

Зачем использовать то, что есть, билдь все либы с нуля

Если я меняю владельца каталога внутри контейнера, то меняется владелец каталога на хосте... Сейчас точно не помню, кто становится владельцем, вроде netdev юзер...

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

а зачем вам на хосте сохранять другие права если все контейнеры в этот маунт могут писать?

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

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

То есть это нормальное поведение докера, когда созданным на хосте каталогам докер сам назначает владельца? При этом доступ с хоста в эти каталоги доступен либо руту, либо пользователю с id аналогичным id владельца?

ну да

главное что из контейнеров они доступны

multistage и вперед

Ты не понял - он там просто не собирается

т.к. присвоив права username на хосте, из контейнера они вряд ли будут иметь владельца username, в скорее всего какой нибудь системный юзер либо вообще id 1001 например

а зачем вам на хосте сохранять другие права если все контейнеры в этот маунт могут писать?

Мне это не нужно. Я вижу это как побочное поведение и меня оно не сильно тревожит. Тревожит тот факт, что мои приложения должны запускаться не от root и тут начинается шаманская пляска внутри контейнера. Приложению нужно писать в /var/log/myapp , а каталог принадлежит руту.

просто один раз изнутри контейнера сделать chown на правильного юзера

и дальше эти права остануться на этом маунте на хосте

и дальше эти права остануться на этом маунте на хосте

А вот тут у меня возникает раздвоение личности :) Чем отличается монтирование каталога в docker-compose.yml от монитирования в Dockerfile, кроме того, что это разные этапы

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

а в докерфайле засовываешь содержимое его при сборке образа

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

так что через докерфайл это впринципе не монтирование

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

То есть я могу в Dockerfile инициализировать нужные каталоги, поместить с хоста нужные файлы и изменить владельца (допустим через sh скрипт), а на этапе docker-compose примонтировать и это не затронет права созданные на предыдущем этапе?

так что через докерфайл это впринципе не монтирование

Кажется понимаю.

да

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

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

одно другое перекрывает

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

Я монтирую с хоста не только код, там mp3 файлы (У меня радио) поэтому копировать не желательно :)

Поэтому на этапе сборки я полюбому должен определить права, либо это нужно делать через compose

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

права можно указать и без скрипта на этапе сборки в докерфайле RUN chown ....

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

только после маунта один раз из этого контейнера необходимо выполнить chown на папку с примонтированными данными

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

только после маунта один раз из этого контейнера необходимо выполнить chown на папку с примонтированными данными

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

ну у тебя маунт же один и тот же?

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

дальнейшие маунты будут с теми же правами в этих образах

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

Ты хочешь сказать, что докер это помнит? Кэш?

в аналогичном образе на базе которого ты собираешь одни и те же id юзеров

а права остаются на хочте

Понял.

к примеру у меня есть папка которая монтируется в /var/lib/mysql и владельцем внутри контейнера mysql:mysql а на хосте она отображается с такими правами drwxr-xr-x 12 systemd-bus-proxy ssh_keys 4096 май 5 10:16 data

и любой образ на базе стандартного mysql образа будет с правильными правами ее видеть если примонтирую к нему

и любой образ на базе стандартного mysql образа будет с правильными правами ее видеть если примонтирую к нему

Артём, а можно я по другому спрошу ? :)

м?

Основная проблема с правами внутри контейнера. Каталоги разбросаны по системе /var/log/myapp /opt/myapp /home/user/myapp может мне все, что связано с приложением хранить в $HOME ? И не нужно будет с chown возиться. С точки зрения практики, насколько это корректно?

можно и так, это не принципиально, контейнер != вм

поэтому в плане безопасности никаких проблем не должно быть, можно хоть в корне хранить

вообще лучше бы аппу работать от рута

тогда не будет проблем с правами

тогда не будет проблем с правами

Точно. Но тут психологическая проблема :))

рут в контейнере != рут доступу к хосту

по правильному там только один процесс аппликейшена должен работать и все

а данные можно будет хранить тогда /app /data /log

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

только без гемороя со сменой прав

К сожалению, есть такая штука liquidsoap, не удается запустить ее от рута :)

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

Ребят, а если я хочу запускать контейнер с базой из systemd при старте

мне в секцию Service что корректно писать ? Restart=no ?

и можно ли ExecStart ууказать как /usr/bin/docker start container-name ?

а зачем еще системд в контейнере?

сама база не может демоном висеть?

не в контейнере на хосте

аа

мне надо после ребута поднять контейнер.

так докер в автозагрузку и контейнеры в restart always может?

докер в автозагрузке

он тогда постоянно ребутиться

если с контейнером все норм и он не выпадает с ошибкой то при restart=always он вроде как запускает те контейнеры которые работали до перезагрузки

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

он тогда постоянно ребутиться

У меня было такое, когда контейнер немедленно останавливался (приложение в контейнере вылетало с ошибкой)

обычно через стейт это можно увидеть и покурить почему в docker logs

приложение в контейнере не вылетает. Если запускать ручками всё ок.

в логах нормальный старт постгреса.

так рестарт будет только если стейт будет не running

точнее UP

в логах нормальный старт постгреса.

А как вы ручками запускаете?

docker start container-name

и контейнера остается запущенным\?

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

да

что значит ребут ?

бесконечно рестартиться если я его через systemd запускаю