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

Периодическим пересозданием контейнеров с нуля.

Периодическим пересозданием образов с нуля.

Workflow. Пишешь Dockerfile, создаешь по нему образ, запускаешь контейнер с этим образом. Пришло время обновлять софт: при необходимости редактируешь Dockerfile, создаешь новый образ, старый контейнер удаляешь, запускашь новый.

Второй вариант – внутри контейнера установить новую версию софта, коммитнуть изменение (это создаст новый образ), при необходимости стартануть новый контейнер. Но это не true-docker-way.

По поводу автоматизировать. Собирать новые образы и запускать контейнеры можно скриптами, тут хз что еще автоматизировать. Если софт раскидан по нескольким серверам, имеет смысл поднять docker registry, на одной машине собирать образы и пушить их в registry. А дальше хоть ansible раскидывать по серверам команду на синхронизацию образов и перезапуск контейнеров.

Второй вариант – внутри контейнера установить новую версию софта, коммитнуть изменение (это создаст новый образ), при необходимости стартануть новый контейнер. Но это не true-docker-way.

А ещё это ведёт к увеличению количества «слоёв» на ФС.

А есть ли регулярно обновляющиеся снимки (в которые оперативно включаются security updates)?

Подскажите по «мат. части», пожалуйста.

Допустим, я взял снимок из хаба, (debian stable, например), на базе него сделал свой снимок (шаблон для LAMP, например), на базе этого шаблона - сделал 10 инсталляций (10 сайтов). Далее, я хочу автоматизировать процесс обновления этих 10 инсталляций в случае обновления снимка из хаба. Что для этого нужно сделать?

Сделать «Workflow» (по совету staseg) и запустить его выполнение по cron'у?

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

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

Периодическим пересозданием контейнеров с нуля.

Это ты серьезно?

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

Workflow

Спасибо за правильный термин :)

Изучаю: http://www.luiselizondo.net/a-production-ready-docker-workflow/

Допустим, я взял снимок из хаба, (debian stable, например), на базе него сделал свой снимок (шаблон для LAMP, например), на базе этого шаблона - сделал 10 инсталляций (10 сайтов). Далее, я хочу автоматизировать процесс обновления этих 10 инсталляций в случае обновления снимка из хаба. Что для этого нужно сделать?

Вообще я с докером имею дело больше как разработчик, могу что-нибудь не так сказать по администрированию. Я вижу процесс так: ты просто делаешь docker build на своем Dockerfile. Он выкачает измененный базовый образ, на его основе создаст твой. Дальше можно «обновлять» контейнеры. В таком случае никаких лишних слоев не будет.

Кстати. Скорее всего ты не захочешь запихивать контент сайтов в сам контейнер (данные там неперсистентны). Используй docker lables, чтобы протащить хостовые файлы и директориии в контейнер.

http://www.luiselizondo.net/a-production-ready-docker-workflow/

Еще есть официальная документация, она мне показалась вполне вменяемой :)

Это ты серьезно?

Это не я, это разработчики докера.

Что-то этот ваш докер всё больше кажется каким-то CDROM на стероидах.

Кстати. Скорее всего ты не захочешь запихивать контент сайтов в сам контейнер (данные там неперсистентны). Используй docker lables, чтобы протащить хостовые файлы и директориии в контейнер.

Отлично, одним вопросом меньше :)

Что-то этот ваш докер всё больше кажется каким-то CDROM на стероидах.

Можешь посоветовать альтернативы (для моего use case)?

Оффтопик: команда CoreOS пилила Rocket как альтернативу Docker'у — знаком ли кто с этим решением?

http://www.luiselizondo.net/a-production-ready-docker-workflow/

Еще есть официальная документация, она мне показалась вполне вменяемой :)

Если она оффициальная, то почему она на не в https://docs.docker.com/ ?

P.S.: да, на первый взгляд, выглядит весьма вменяемой.

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

Да

создаешь новый образ, старый контейнер удаляешь, запускашь новый

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

Ээ... ну, я бы сначала посмотрел на виртуалки с virtio (и OpenStack) - просто потому, что я больше знаком с qemu и virtsh, но я ни в коем случае не специалист по развертыванию сервисов.

Оффтопик: команда CoreOS пилила Rocket как альтернативу Docker'у — знаком ли кто с этим решением?

Нет. Я вообще за этими битвами слежу со стороны - я не целевая аудиотория Docker-подобного.

У докера концепция мега пакетного менеджера для микросервисов. Попробуй лучше lxc.

Сейчас кстати сам пробую мигрировать qemu-kvm/libvirt -> lxc.

Наше продакшен воркфлоу:

* Тег релиза в гите
* teamcity event
* сборка deb пакета
* заливка пакета в репозиторий
* генерация Dockerfile
* docker build
* docker push в registry
* деплой

Как-то так

Всем спасибо!

Благодарю всех за советы и обсуждение. Буду пробовать.

Держи нас в курсе, многим было бы интересно.

Что именно интересно? Мы у себя используем докер? Если есть вопросы - пишите?

Извините, что ворвался в тему так.

Интересует больше не докер а lxc.

Да есть ещё вопрос по поводу запуска больше одного процесса в докере и как можно раздавать динамические днс типа как avahi. чтоб у каждого контейнера был какой нибудь постоянный идентификатор типа uuid.local и не менялся при смене ip.

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

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

По поводу процессов - можешь запускать сколько угодно. На докерхабе есть масса образов all in one.

Насчет dns - посмотри на docker weave.

Но поскольку проблемы доставки

Я знаю парней которые распространяют свои «Программные продукты» в виде файлов образов для xen-а и живут неплохо.

Насчет dns - посмотри на docker weave

А есть не привязанное к докеру? мне бы с нормальным lxc гонять надо.

Я сейчас имел в виду именно приложения и сервисы.

Мне кажется управлять приложением в докере - проще и эффективнее, чем в xen.

Насчет lxc - я бы посмотрел в сторону dnsmasq, который занимался бы dhcp&dns

Нашел неплохо написанную книгу по Docker, читаю.

Новичкам (и не только) рекомендую: http://www.it-ebooks.info/book/4844/

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

На самом деле довольно удобно, особенно когда тебе надо быстро отскейлить приложение, введя ещё N инстансов. Ну и для случаев, когда сервис живёт в огороженном вилане, например (актуально для всяких pci dss и прочей энтерпрайз черни).

Чем это лучше просто deb или rpm?

Быстрее в общем случае. Ты за 2..5 минут разворачиваешь полноценный инстанс приложения (с готовыми конфигами и пр.). Опакеченное тебе надо разворачивать в подготовленной среде, значит, мы добавляем время на создание контейнера, приход на него папета/шефа, деплой пакета и рихтовку конфигов аппликухи (тем же папетом?). По моему опыту второй сценарий забирает больше времени.

Впрочем, оба варианта имеют право на жизнь, смотреть надо по ситуации.

Воспроизводимостью окружения и отсутствием геморроя в процессе деплоя. Короче говоря, практически исключены ситуации, когда на одном сервере libjerk одной версии, а на другом - другой. Всё, что собрано в девелопменте и протестировано в тестинге, гарантированно доедет в таком же виде до продакшна. И да, деплой докером не ставит локов как apt, например. Бывает ситуация, когда два сервиса деплоятся на одну и ту же машину. В таком случае кто первый встал - того и тапки, а у второго сервиса деплой прерывается где-то посередине и всё остаётся в расколошмаченном виде. Это я ещё не упомянул неприятных ситуаций, в которых залипает кэш apt, отваливается какой-нибудь репо из списка и apt-get update возвращает не ноль в кластерный шелл/оркестратор, что тоже прерывает процесс деплоя, коллизии конфигов, оверрайды, диверты и прочий срам.

В случае с докером всё просто: пушнул код в репо, сработал вебхук, собрался контейнер по докерфайлу, перданул контейнер в регистри, нажал деплой и всё заработало.