ну не важно где оно будет собираться, проблему с правами все равноне решает.

решение проблемы прав - явно их задавать

супер... какого юзера ставить файлам?))

любого явно созданного

сделать один id:gid на хосте и внтури - и вперед

в контейнере app. Верно?

вот прикольный тест сделали https://github.com/docker/docker/issues/6119#issuecomment-70606158

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

.

смена прав становиться очень дорогоим удовольствием :)

меняй снаружи перед билдом

так, снаружи это всмысле на хост машине ?

да

пфф... так на них сейчас и стоят права юезра docker который на хост машине

а после COPY в контейнер то на них рут

в том то и проблема :)

да, проблема явно остро обсуждается :)

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

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

а что проверял и что работает?

Билдим с этим: FROM alpine ADD file.tgz /srv Видим это: / # ls -la /srv/ total 1448 drwxr-xr-x 2 root root 40 Dec 27 13:05 . drwxr-xr-x 18 root root 221 Dec 27 13:05 .. -rw------- 1 root root 1222777 Dec 27 12:59 messages -rw-r--r-- 1 982 972 255787 Aug 25 17:02 mongod.log

Билдим с этим: FROM alpine ADD file.tgz /srv Видим это: / # ls -la /srv/ total 1448 drwxr-xr-x 2 root root 40 Dec 27 13:05 . drwxr-xr-x 18 root root 221 Dec 27 13:05 .. -rw------- 1 root root 1222777 Dec 27 12:59 messages -rw-r--r-- 1 982 972 255787 Aug 25 17:02 mongod.log

ну видим что все под рутом

а нет, не все...

я не на каждой своей машине делаю рута с 982:972

я не на каждой своей машине делаю рута с 982:972

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

у меня вот что в контейнере после COPY

~/html $ ls -l total 56 -rw-r--r— 1 root root 1622 Dec 27 11:40 LICENSE.md -rw-r--r— 1 root root 1353 Dec 27 11:40 README.md

а вот что в хост машине -rw-r--r— 1 docker docker 1622 Dec 27 11:40 LICENSE.md -rw-r--r— 1 docker docker 1353 Dec 27 11:40 README.md

А зачем делать копи если можно прочитать Ман?

ну я выбирал между COPY и ADD и узнал что ADD просто чуток больше умеет и работает с архивами

у меня архива нет, так как я делаю git clone с репы делаю в папку и все. Архивов нету... мне надо просто сорцы закинуть в докер

Поэтому я и говорю про костыли

Потому что если ты посмотришь дампом что льется в демона - ты увидишь, что так идет оттриманный

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

я уловил мысль?

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

Вот тут потерялась в конце логическая связь. В остальном все так

оооок... понял. Знаний получил, за что спасибо! А что, если делать git clone в самом Dockerfile. Вариант?

Да, правда там немного другие проблемы лезут

Но я у себя из контейнера клонб

расскажи как.

Если учишся - сначала попробуй

Может сам все решишь

Если учишся - сначала попробуй

ок, я то решу. Но мошно узнать исход заранее? Когда делается git clone в Dockerfile какие права имеют файлы?

Это RUN на нее влияет USER

Это RUN на нее влияет USER

это отличное замечание. Спасибо! А юзер который указан в USER докерфайла будет потом в системе внутри контейнера?

USER так же влияет на CMD и ENTRYPOINT

USER так же влияет на CMD и ENTRYPOINT

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

Пользователь который указан в USER должен присутствовать в системе

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

http://blog.cloud66.com/how-to-get-code-into-a-docker-container/

> According to Docker's best practices guide, COPY is recommended for most cases.

Коллеги, с наступающими!

Тупой вопрос, с которым не первый раз сталкиваюсь.

@voskobovich как вариант можно в образ складывать /docker-entrypoint.sh и в нем chown -r www-data:www-data /app размер образа не изменится, profit!

Что делать с теми средами, которые ставят зависимости в тот же каталог, где исходники? Типа ./node_modules? Невозможно же разрабатывать в режиме -v pwd:/app!

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

@voskobovich как вариант можно в образ складывать /docker-entrypoint.sh и в нем chown -r www-data:www-data /app размер образа не изменится, profit!

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

Учите матчасть, блин. Нодмодули могут быть выше

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

Учите матчасть, блин. Нодмодули могут быть выше

Ну т.е., общее решение — перестать ставить зависимости под исходники и начать жить, правильно понимаю?

веб сервер от www-data, права на чтение файлов у него есть, на запись права выдам куда надо... минусов не вижу.

в плане безопасности... тоже вопросов нет, хм... я что-то не замечаю?

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

А чего собственно плохого, что зависимости в проекте хранятся?

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

размер образа не изменится, потому что скрипт запускается при старте контейнера

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

ок, но ведь если в контейнере чет после сборки изменить то его размер не измениться пока изменения не закомиттить. Так?

ERROR: S client not available

хз, я не комичу контейнеры и не задавался вопросом)

но есть подозрения что эти изменения на ФС не отражаются

ну каждый коммит - новый слой :) так что 99% что да, ну тестом можно проверить. А вообще с энтрипоинтом крутая идея. А скажи плиз, когда именно он запускается? в какой момент

Это плохая идея, в целом. Время отработки чоуна какие?

https://docs.docker.com/engine/reference/builder/#/understand-how-cmd-and-entrypoint-interact

Это плохая идея, в целом. Время отработки чоуна какие?

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

а еще проверил, контейнер не растет в размерах, только /var/lib/docker/aufs/diff/ на несколько байт увеличился

он же diff)

понял, попробую

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

исходники под рутом ничем не плохо

из вариантов — пакуй из своего кода tarball выстявляя нужные привилегии и добавляй через ADD

что-бы не chown’ить и chmod’ить

исходники под рутом ничем не плохо

Только тем, что композер ругается на безопасность

Ну, пока так может работать

А подскажите, плиз, как провернуть следущее: есть сервер1 с несколькими docker-контейнерами, сервер2 с mysql; надо дать возможность коду из контейнеров ходить в mysql. Как такое провернуть вообще можно?

возможно network_mode: "host" поможет

а как это в compose-файле указать? (маны чрезмерно скудные на этот счет…)

А подскажите, плиз, как провернуть следущее: есть сервер1 с несколькими docker-контейнерами, сервер2 с mysql; надо дать возможность коду из контейнеров ходить в mysql. Как такое провернуть вообще можно?

MySQL тоже в контейнере?

нет - он один там на той машине

нет - он один там на той машине

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

а прям так и указывать

https://docs.docker.com/compose/compose-file/#/networkmode

https://docs.docker.com/compose/compose-file/#/networkmode

пасиб!

Зачем в этом случае network в host режиме не понимаю. Разве что в докер ещё нет человеческой поддержки ipv6 по дефолту(пару месяцев не следил за ним) и база у вас на ipv6-only хосте. А так это не обязательно

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

есть подозрение что вот это не верно. хотя может просто я что-то делал не так. Опишите плз как какой нибудь пхп завернуть на базу на хостмашине

есть подозрение что вот это не верно. хотя может просто я что-то делал не так. Опишите плз как какой нибудь пхп завернуть на базу на хостмашине

Ну если база именно на хост -машине, без контейнера, то network в host режиме это действительно выход. А если база на другом сервере то к ней можно просто обратиться по fqdn

Ну если база именно на хост -машине, без контейнера, то network в host режиме это действительно выход. А если база на другом сервере то к ней можно просто обратиться по fqdn

+1

Ребята, не проектируйте инфраструктуру которая рассчитана на "свой веб сервер под каждый проект". Вы не сможете поднять два сервера на одном хосте :( именно на это напоролся сейчас я...

а так все красивенько было скомпоновано в docker-compose.

Фак, бд и мемкеши кажется можно завернуть в локальные сети между композером, и таким обзразом поднять под каждый проект свою БД. Верно?