Мысли разной степени связности о том, что не хватает контейнерам для нормального применения в боевых задачах. На полноту изложения не претендуют. Без предварительных комментариев могут плохо восприниматься - сорри, но так и задумано.
- https://www.facebook.com/mxsmirnov.arch/posts/691217340982083 + http://mxsmirnov.com/2015/06/02/paas/- подборка ссылок имени нашего любимого Максима Смирнова под кодовым именем "чему именно по этой теме радуются архитекторы в тяжёлом корпоративе"
- https://www.openshift.org/ - заявлено, что это во многом о контейнерах для корпоратива. Серебряной пули и волшебных таблеток не ожидаем, но могут найтись ответы на часть вопросов. Текст про изнанку текущей dev-версии - https://blog.openshift.com/openshift-v3-deep-dive-docker-kubernetes/
- ...
- "Бинарники" - собственно контейнеры. В них собранный код, скрипты и вот это всё. В текущем приближении вполне покрыты контейнерами как они есть в дикой природе.
- "Конфиги" - те или иные настройки. С ними всё заметно хуже. Пихать их в контейнер - не дело. Можно хранить их в чём-то типа etcd. Можно разливать их чем-то типа ansible. Вопросы есть - например, конфиги бывают на ноду, а бывают на кластер. И второе не очень покрыто типовыми тулзами.
- "Данные" - с чем работают бинарники, от статичных страничек до файлов с данными базы. С данными совсем капец. Они должны быть атомарно-транзакционными, примерно как "бинарники". Чисто теоретически тот же Docker предлагает с ними жить средствами OverlayFS. Идея выглядит не совсем очевидной - можно использовать снапшоты LVM (что более распространено), можно снапшоты btrfs (что более модно), можно снапшоты железных хранилок (что более энтерпрайзно). Ну и вообще ни черта в этой области не проверено пока.
- Сборка контейнера. Оно не может быть "как-то где-то там, хз чем". В каком-то виде решение заявляет тот же Openshift - интеграция с Jenkins, сборка по коммиту (?), всё такое. Но сценарий "тут положите ваш произвольный билд-скрипт" - не лучшее решение, мало чем отличается от сборки не коленке хз где и чем.
- Обновление контейнера. Наивные вопросы опять-таки заявляет Openshift (если есть новая сборка - авто-обновление всех задеплоенных). Но этого таки мало - бывают проблемы обновления, бывают откат обновления, бывает обновление кластера, которое должно быть синхронно, а не как получится, бывает связь этого всего с данными.
- ...
- Наивно есть стадии - Prepare, Switch, Rollback или Commit (Success, Go - не суть). И на этих стадиях нужно помнить, что бывают "бинарники", "конфиги" и "данные".
- Стадия Prepare может быть медленной, может быть по-разному медленной на куче хостов. И может запускаться автоматически и идти фоново - человек тут не нужен.
- Скорее всего, хочется иметь несколько версий контейнера, готовых к запуску. Уже на хостах исполнения, чтобы при операциях уровня "Ну, поехали!" или "@#%, верните всё как было!" не тупить на разливке и т.п. Скорее всего, нужны N (2?) последних версий плюс те, что явно помечены как важные релизы.
- Стадия Switch, скорее всего, бывает над нодами (если каждая может обновляться сама) и над группами нод (если это должно быть синхронно над кластером).
- После Switch должен прогоняться какой-то набор проверок, что оно вообще ожило. Далее должен быть минимальный мониторинг, живо ли оно вообще в данный момент времени.
- При сбое должен быть возможен Rollback. Самое весёлое - связь с данными. Не всегда мы хотим откатить всё до старого "бинарника" и старых "данных". Мы можем хотеть старый бинарник и новые данные ("новая АБС быстро упала в сегфолт, но вообще-то успела провести какие-то платежи перед этим").