да

Может ты делаешь что-то неправильно?

да даже если и так, то как это связано с использованием или не использованием :latest

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

Но судя по тому что ты написал у тебя 13 сервисов в одном гите. Зачем?

а как?

да пофиг, используется то :latest не при сборке, а при запуске

и вот там его использовать и не стоит

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

нет, не микросервисная - микросервисы вообще нарушают концепцию докера

Andrew почему бы и нет?

"концепция докера", хехе

"концепция докера", хехе

ну да, я тоже уже давно не понимаю - зачем это всё

заказчик просто хочет

Andrew почему бы и нет?

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

Да даже если не микросервисная держать софт который разбивается на 13 отдельных контейнеров в одном гите неудобно

Это порождает целый класс проблем связанных с непрерывной интеграцией

но держать 13 реп под это, извините меня, дерьмо - тоже как-то не очень

Andrew, никто не говорить их выкатывать на прод как latest. А тегать во время сборки, почему бы и нет.

Andrew, никто не говорить их выкатывать на прод как latest. А тегать во время сборки, почему бы и нет.

а как тегать во время сборки?

как вести отсчёт?

Через jenkins например

Держать 13 реп под это дело как раз удобно 😊

ну через него, радимого и собираю и доставляю и разворачиваю

Andrew, никто не говорить их выкатывать на прод как latest. А тегать во время сборки, почему бы и нет.

если не использовать, то зачем и тегать? ) ну да ладно, пусть тегается

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

Andrew, использовать можно например на локальной машинке, чтобы не лазить каждый раз и не смотреть какая сейчас свежая версия. Предварительно конечно сделать pull.

вот собственно и вопрос - как не тегая latest узнать какая сейчас последняя

в автоматическом режиме, без участия человека

используя средства автоматической сборки

оно же всё такое API-шное, но что-то банальных вещей нет

например в случае Teamcity использовать сборку как artefact depence для деплой конфигурации

*artifact

думаю в jenkins должен быть аналог

банально хоть в файл записывай и потом вычитывай

единственный минус - при переезде CI - надо восстановить этот файл

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

отлично, с этим определились )))))

осталось понять как узнать эту последнюю версию для каждого конкретного образа )))))

Через артифакты

при сборке делай дополнительный тэг app-latest, app2-latest, app3-latest

А разница?

Разговор о том что ты зайдешь на прод и там будет бла-бла:latest

И ты не будешь знать из какого коммита оно собрано

Так как этот latest может в любой момент перетереться след сборкой

еще же захочется иногда откатиться на предыдущую сборку )))

а она уже не latest и тут наступает полный ступор )))

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

конкретную, а не latest

как у вас там деплой настроен — это другой вопрос

хочу 2 отдельных джобы: - одна взять из регистри последнюю версию и задеплоить ее - взять предыдущую версию и задеплоить ее

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

вам уже сказали как делать можно

и как делают

у меня каждый имедж тегается и пушается гит_коммитом текущим

он уже уходит в консул-ключ

откуда его уже подцепляет "система диплоя" и собственно диплоит

в этот же консул ключ можно засунуть любой git sha

у меня каждый имедж тегается и пушается гит_коммитом текущим

прям весь sha1 ключ?

прям весь, о ужас )

можно 8 символов первые брать, если так бугают 32 символа (или сколько там) :)

Всем привет случайно никто не поднмал samba-ad-dc от pitkley/samba-ad-dc?

Нет, но просто samba-ad-dc поднимали

Я и руками поднмал, потом решил в контейнере поднять у меня всегда ругается на ../source4/dsdb/dns/dns_update.c:294: Failed DNS update - NT_STATUS_ACCESS_DENIED

Всем привет! а кто какой процесс-супервайзер в контейнере использует? например если я хочу запустить в контейнере условный cron, я хотел бы сделать это из под какого менеджера, пока смотрю в сторону s6, supervisord или my_init (https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/, https://blog.tutum.co/2014/12/02/docker-and-s6-my-new-favorite-process-supervisor/)

my_init это не супервайзер процессов

это такой баш-скриптик который умеет init 1 быть нормально

phusion в качестве супервизора предлагает runit использовать (и собственно он есть в их имаджах)

это не столь важно в контексте моего вопроса, но за уточнее спасибо)

ну вроде как в контексте "какой супервайзер выбрать: А, Б или Ц" уточнее, что Ц это не супервайзер, а вот Д — супервайзер вполне себе важно :)

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

по функционалу он конечно не дотягивает до supervisord но это не мешает ему управлять поведением некоторых процессов

баш / питон, ок )

каким поведением он как позволяет управлять?

исходя из кода https://github.com/phusion/baseimage-docker/blob/rel-0.9.16/image/bin/my_init он как минимум умеет запускать и завершать процессы. Причем он умеет запускать загрузочные скрипты из init.id и rc.local

он умеет быть правильным init

сравнивать это с супервизорами типа runit / systemd / supervisord — некорректно

хотя...

почему бы и нет )

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