но pull тоже не лучшая вещь, при push -f он ломается

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

но pull тоже не лучшая вещь, при push -f он ломается

Поэтому я его и не использую

можно каждый раз делать clone с depth=1

Я ж так и сказал?

да я и не спорю

это всегда COPY и всегда контейнер на проект

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

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

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

Смотря для чего использовать докер, если для формирования enviroment проекта - то использовать volume, если вам нужно распространять проект - то copy во время билда

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

Но зачем оно тогда? почему ты не сделать тогда клон?

Но зачем оно тогда? почему ты не сделать тогда клон?

какой клон? гитовый?

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

Да. Это и называется ci/CD pipeline. Для этого девопсы и нужны

ну хорошо, идеи здравые, спасибо, буду обдумывать детатали. Но вот тогда другая проблема. Допустим, есть у нас этот билд-контейнер, который каким-то образом получает сорцы и потом выплевывает в хост-систему какой-то собранный артифакт. Дальше нужно создать имадж новой версии с этим этим артифактом и сделать пуш в докер-регистри. Как при создании имаджа с приложением узнать, в какую папку был сохранен собранный артифакт? Т.е. мне надо при создании билд-контейнера заложиться на какую-то одну папку в хостовой системе, и потом при сборке имаджа с приложением каждый раз вспоминать, где эта папка находится на текущей системе. Я понимаю, что универсальный ответ "возьми gitlab и не мучайся". Но мне вот приспичило в самолете собрать на ломальной машинке весь проект, запустить его в минимальном окружении и пригнать тесты. Все кэши есть, сорс код вот лежит в папке, докер с имаджами есть.

\о/

\o/

ну хорошо, идеи здравые, спасибо, буду обдумывать детатали. Но вот тогда другая проблема. Допустим, есть у нас этот билд-контейнер, который каким-то образом получает сорцы и потом выплевывает в хост-систему какой-то собранный артифакт. Дальше нужно создать имадж новой версии с этим этим артифактом и сделать пуш в докер-регистри. Как при создании имаджа с приложением узнать, в какую папку был сохранен собранный артифакт? Т.е. мне надо при создании билд-контейнера заложиться на какую-то одну папку в хостовой системе, и потом при сборке имаджа с приложением каждый раз вспоминать, где эта папка находится на текущей системе. Я понимаю, что универсальный ответ "возьми gitlab и не мучайся". Но мне вот приспичило в самолете собрать на ломальной машинке весь проект, запустить его в минимальном окружении и пригнать тесты. Все кэши есть, сорс код вот лежит в папке, докер с имаджами есть.

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

Зачем что-то помнить, все должно происходить атвоматически

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

\=/

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

А как контейнер может собрать новый имадж?

А как не контейнер это делает?

Это делает докер. В текущей задаче докера внутри билд контейнер нет. Или есть?

ну добавьте, в чем проблема? -v /var/lib/docker.sock:/var/lib/docker.sock

и не надо будет ничего помнить

Это считается нормальной практикой?

да

Ужас :/

Аргументируете?

Это нормальная практика

ну добавьте, в чем проблема? -v /var/lib/docker.sock:/var/lib/docker.sock

эта штука спасла меня от растерзания девелоперами, всем рекомендую

Всем привнт

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

?

Что бы это значило....

Аргументируете?

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

А кто-то хвалит полупрозрачный халатик изоляции докера? Вам показалось. Но, при желании никто не мешает запустить DockerInDocker образ и делать все в нем, смысла только в этом тотальный 0 при условии своего проекта

Что бы это значило....

видимо в консоль вывалиться

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

дак он и не знает про систему ничего, у него просто сокет к какому-то докеру есть

можете, в принципе, через http-api прицепиться

Что бы это значило....

Это мне? = ))

ага

можете, в принципе, через http-api прицепиться

это то-же самое. нужно ж чисто. тогда - dind

ну добавьте, в чем проблема? -v /var/lib/docker.sock:/var/lib/docker.sock

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

Теперь внутрь еще один докер,а в нем докер в докере

ну или так

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

Чтоб не пересоздавать контейнер а сразу поставить..

у вас на картинке докер с контейнером в докере. А надо контейнер в контейнере на докере

как-то так

привет

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

говнометанием пренебречь

файлы в вольюм

не особо. если делать в хост системе или в волюме будет более осмысленно

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

вообще я б рекомендовал просто -v

встречал еще практику создания отдельного контейнера data. в который пихается все данные необходимые другим контейнерам и после расшаривается через volumes-from. насколько оправдан такой метод?

если данные нужно подключать к нескольким контейнерам, то их надо вынести в контейнер (типа предложенный выше data). Если данные базы используются только базой (что так и есть обычно), то используем -v (volume)

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

ИМХО еще проще все щарить с папки с хоста

это и есть мой второй вариант

ERROR: S client not available

named volume немного не то

в случае с датой я тоже имелл ввиду что этот контейнер мапит в себя с хоста все что нужно а потом раздает остальным контейнерам. И сам вопрос заключался в целесообразности плодить еще одну сущность в виде data контейнера

я ее не вижу

еще раз с другого конца: а) если нужно проносить данные в другие контейнеры, то юзаем контейнер для данных или named volume б) если не нужно, то маунтим диру с хоста через обычный volume

тогда еще такой вопрос, наверное тоже зависит от ситуации, но все же. Насколько противоречит философии докера билд приложения внутри контейнера(клон кода внутрь контейнера, и какой нить composer собирает все зависимости). Цель - иметь саморазворачивающуюся среду для разработки по docker-compose up. И есть ли возможность вынести код наружу что бы разработчик мог править непосредственно код из докера?

тогда еще такой вопрос, наверное тоже зависит от ситуации, но все же. Насколько противоречит философии докера билд приложения внутри контейнера(клон кода внутрь контейнера, и какой нить composer собирает все зависимости). Цель - иметь саморазворачивающуюся среду для разработки по docker-compose up. И есть ли возможность вынести код наружу что бы разработчик мог править непосредственно код из докера?

при разработке так и делается

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

снаружи? Orly?

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

имеется в виду маунтить диру с хоста

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

комопзер собирает на основе composer.json

о, спасиб, про него я чет не дошел почитать. теперь понятно

Вснм привет

есть знатоки supervisord ?

каждый 3й

пусть я буду третьим

есть знатоки supervisord ?

фууууууууу

ты червертый

Докер должен под рутом работать?

У меня в mint работает только под рутом, что-то тут неладно

Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon. Is the docker daemon running on this host?). Using system default: https://index.docker.io/v1/ Cannot connect to the Docker daemon. Is the docker daemon running on this host?

Группу добавь

Спасибо - помогло ?

Run Docker containers on embedded devices

https://resinos.io/

Что-то я задолбался с логированием в докере :(

а что с ним?

Все плохо.

Хочу syslog в контейнере

зачем?