Несколько вырвано из контекста, но Вам конечно же виднее.

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

Да я вот тоже думаю... но хочется из интереса попробовать на докере решить (

хорошего решения нет. и не предусмотрено бай дизайн.

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

Равно как и вопрос "А зачем делать именно так?"

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

Да я вот тоже думаю... но хочется из интереса попробовать на докере решить (

а почему supervisor, например, плохое решение?

хорошего решения нет. и не предусмотрено бай дизайн.

А чем дизайн запрещает решение этой проблемы? Не троллю, а просто интересуюсь.

а почему supervisor, например, плохое решение?

супервайзор хорошее решение, лучше чем заворачивать это в баш, например.

когда-то давно я тоже пихал ssh в контейнер, делал это с помощью supervisor либо обычного скрипта, который дергает скрипты инициализации

а почему supervisor, например, плохое решение?

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

Меньше мороки с поддержкой

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

тогда нужна дополнительная инфа по инфраструктуре, чтобы понять, как и куда приладить ssh...

тогда нужна дополнительная инфа по инфраструктуре, чтобы понять, как и куда приладить ssh...

Да тут все просто - целевой контейнер, а к нему "как-то" приладкн контейнер, к которому цепляешься по ssh. На целевом контейнере нет ssh. Разработчикам надо - 1) посредством , например winscp залить файлы на целевой контейнер 2) посредством putty подключиться к целевому контейнеру.

Звучит тупо, я понимаю

Первая задача решается

Проблема со второй (

получается, что winscp хочет файло - это волюм

Да

Это решено

а второй посредством путти - для какой цели? mysql?

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

Ну mysql тоже, дамп залить например

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

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

Ну да, сценарий не совсем про докер, но неохота полновесную виртуалку ставить запускать и т.п.

Может я туплю, но мне кажется проще придумать трюк с докером )

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

"Как-то" )

даешь ссш на хост машину и учишь разработчиков работников работать с докером

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

и пусть они там тыкаются

а еще есть docker attach\exec

Может я туплю, но мне кажется проще придумать трюк с докером )

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

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

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

а еще есть docker attach\exec

я об этом и говорю, но т.к. нет доступа к хосту, то нужно контейнер с ssh запускать с -v /run/docker.sock:/run/docker.sock + накатить docker в контейнер ssh

такое для дебага

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

у кого то лица обнаглевшие

ранчер им не нравится

По сути это дэв среда

суй им ссш во все докеры

ну если дэв, то выше правильно сказали

lxc или чтото типа того

я об этом и говорю, но т.к. нет доступа к хосту, то нужно контейнер с ssh запускать с -v /run/docker.sock:/run/docker.sock + накатить docker в контейнер ssh

Докер в докере?

И пользователя с паролем и мапать порты. Тысячи их

Докер в докере?

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

но можно и в данном конкретном случае ))

Да, подумаю насчет докера в докере. Я об этом не думал в таком разрезе

тем не менее это не избавит вас от необходимости делать build

или просто инсталл в контейнере ssh

Ну да

Гемморой короче в любом случае

на всякий случай еще разок скажу: ИМХО, лучшим решением было бы перевести дев-среду в LXC либо собирать персональные окружения с помощью vagrant

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

Я сегодня весь день пытался как-то решить эту задачу. Ни фига не получилось и у меня тоже пошли мысли об lxc и тп

О вагранте я подумал

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

Спасибо за советы!

🙂 не за что!

И пользователя с паролем и мапать порты. Тысячи их

Так и есть, за каждым разрабом свой диапазон портов )

А может и хрен с ним. Если ssh на volume прокинуть - пусть уж "помучаются" с консолью ранчера.

Кто-то юзает Traefik с https? :)

А подскажите самый тонкий образ с линуксом.

alpine?

alpine?

Пасиба. =)

ток там линукс курильщика

лучше, чем тащить весь дебиан в контейнер :/

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

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

А в чём отличие ADD от COPY?

В документации

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

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

restart=always?

хм, попробую

он же сохранит вольюмы и порты?

порты?

он же сохранит вольюмы и порты?

через компоуз запускаете?

нет, руками

стоит попробовать композ?

у меня всего два контейнера, не уверен, нужен ли он тут

друг от друга они зависят?

он же сохранит вольюмы и порты?

все сохраниться при рестарте

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