LINUX.ORG.RU
ФорумTalks

Вот делаем систему управления жизненным циклом образов для docker и есть куча вопросов.

 


1

5

Система предназначена для контор которые собирают _свой_ софт в docker образы и потом все это разворачивают на кластер(ы).

Система содержит: docker registry, swarm, а также самописную управлялку для всего этого.

Система имеет вебморду которая позволяет:

  • видеть список развернутых контейнеров (группируя по нодам, образам и т.п. )
  • видеть список нод, список образов в реестре,
  • разворачивать произвольный образ в контейнер на произвольную ноду с дефолтными для это образа настройками.
  • клонировать контейнер (запустить, остановить, удалить и т.п.)
  • видеть логи контейнера

Итак, это то что есть, планируется добавить концепцию «окружения» - develop, qa, production и механизм перехода image по этим окружениям по мере прохождения тестов.

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

ps. будет оно опенсурсно или вообще публично - не знаю.

Deleted

Последнее исправление: Deleted (всего исправлений: 5)

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

SevikL ★★★★★
()
Ответ на: комментарий от Deleted

Ты что-то делаешь не так.

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

tailgunner ★★★★★
()
Ответ на: комментарий от Deleted

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

SevikL ★★★★★
()
Ответ на: комментарий от vrutkovs

A/B deployments

Что-то я вот именно по этому вопросу не понял, тут же надо метрики внутри приложения снимать для оценки, не?

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Предполагается что метрики\прочее будет снимать специально обученный интерн/ELK.

Тут нужно изкоробочно настроить «30% реквестов идут на версию B» и сопутствующие проблемы - например, версия B требует другой структуры базы, новые гемы и прочее.

vrutkovs ★★
()
Ответ на: комментарий от vrutkovs

Предполагается что метрики\прочее будет снимать специально обученный интерн/ELK.

Так без этого это, этот как его «канареечный деплой» вроде зовется.

Deleted
()
Ответ на: комментарий от Deleted

О, у нас богатый опыт поддержки системы на базе докера. Хлам таки остается, особенно после докер-факапов. А если спустите пользователя до уровня докера, мусора будет и без факапов.

Registry может стать узким местом. Если он один или их мало на кластер — упретесь в сеть или диск. Когда у вас станет много образов — можете упереться в сам registry (стало лучше после его переписывания с питона) или их синхронизацию (у нас в худших случаях это могло занимать пару дней). Очень рекомендую подумать о механизмах ограничений числа образов или их суммарного размера на пользователя.

staseg ★★★★★
()
Ответ на: комментарий от staseg

Ку да мы упремся мы сами знаем, и грабли топтали. Вопрос исключительно про фичи, а не грабли 8)

Deleted
()

Хм, а масштабирование приложений планируется? Насколько я слышал swarm что-то такое умеет, а в списке этого нет. Или это тупо пускалка контейнера в облаке?

staseg ★★★★★
()
Ответ на: комментарий от staseg

Хм, а масштабирование приложений планируется? Насколько я слышал swarm что-то такое умеет, а в списке этого нет.

Ну масштабирование - это клонирование + поддержка масштабирования приложением

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

Deleted
()
Ответ на: комментарий от staseg

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

Deleted
()
Ответ на: комментарий от Deleted

«Имейдж» то отмасштабируешь любой. Но это уже вопрос stateful/stateless сервиса, я в целом подразумевал саму возможность быстрого расширения или сужения числа контейнеров, какой-то единый endpoint для них и возможно load balance. Можешь записать фичу :)

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

staseg ★★★★★
()
Ответ на: комментарий от staseg

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

это есть же какраз

какой-то единый endpoint для них и возможно load balance. Можешь записать фичу :)

и это есть, но только для http и без костылей типа «sticky session»

Еще для тяжелых приложений бывает полезно

Ага, что-то такое было, только не помню в каком виде, надо думать.

Deleted
()
Ответ на: комментарий от vrutkovs

rkt .. GCE

Не нужно же, только докер, только хардкор, а то так еще можно поклянчить virtualpc и какуюнить залипуху от вмвари - на все это добро которого наплодили не хватит ни времени ни сил.

Deleted
()
Ответ на: комментарий от Deleted

Ну ок, я не в курсе как в swarm, но в k8s (и openshift) многое уже решено, могу только посоветовать тырить фичи ориентироваться на них

vrutkovs ★★
()
Ответ на: комментарий от Deleted

openshift v3 практически подходит под оригинальные требования (разве что фокус больше на деплойменты чем docker build), но на kubernetes. Например, проекты там - это и есть «окружение» devel - qa - prod. Прохождение по разным окружениям делается через jenkins и promoted builds.

Еще в список фич: permissions (для privileged) и линкинг контейнеров.

С другой стороны пусть цветут тысячи цветов, посмотрим что умеет swarm.

vrutkovs ★★
()
Последнее исправление: vrutkovs (всего исправлений: 2)
Ответ на: комментарий от stevejobs

это просто глобальная эпидемия NIH вируса 8)

Deleted
()
Ответ на: комментарий от Deleted

а, дошло

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

stevejobs ★★★★☆
()
Ответ на: комментарий от Deleted

кстати, ты не знаешь, можно ли vagrant'у как-то сказать, чтобы он fit into RAM всю виртуалку? Сранный виртуалбокс ужасно свопится при старте, ждать старта приходится очень долго, иногда он даже не запускается вообще, жуткое говно короче( А лицензия на vagrant-vmware требует денег... Завтра буду ставить 60-дневный триал vSphere, кажись для него есть бесплатный плагин для вагранта. Но лучше было бы все же придумать, как упихать виртуалбокс в раму...

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

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

Deleted
()
Ответ на: комментарий от true_admin

очень медленно стартует виртуалка. Чем больше рамы - тем медленней. С приемлемой скоростью только на 500мб рамы, на 8гб уже печаль, а мне реально нужны все эти мегабайты.

в vmware есть такая замечательная опция:
1) fit all virtual machine memory into reserved host RAM
2) allow some virtual machine memory to be swapped
3) allow most virtual machine memory to be swapped

варианты 2 и 3 говно полное, вариант 1 самое то. Особенно в комбинации с physical disks. Вот я выделил reserved memory 20 гигабайт, 16 отдал в виртуалку, и у меня совсем ничего не тормозит, и виртуалка стартует мгновенно.

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

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

на 8гб уже печаль

Ты ее будишь штоли? у меня на ноуте 12гиг и 6-8 гиговые виртуалочки (да да, если все разом раздуются то не влезут) стартуют за так, причем на старте они и внутри и на хосте ну по полгига съедают

Deleted
()
Ответ на: комментарий от Deleted

Нет, не бужу. Напротив! Дженкинс (или intellij idea) «вчистую» собирает наш софт, и потом запускаются тесты. В начале теста я ее каждый делаю destroy, потом создаю, и полностью конфигурирую через ansible. Заливаю софт из дженкинса энсиблом, прогоняю тесты, shutdown, destroy. Тестов немало, поэтому меня жутко раздражает, что на 500 мегабайтах оперативки оно стартует всего пару секунд, а на 8Гб - можно успеть быстро дойти до кулера, вернуться назад и прочитать обновления ленты /development на лоре. Понятия не имею, почему так происходит, я там вообще ничего не трогал, и ничего не настраивал. Может это потому, что виртуалбокс говно.

наверное, все закончится vmware workstation, от нее где-то была лицензия

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 2)
Ответ на: комментарий от stevejobs

Эм, это какая-то мистика, но я бы всё же попытался разобраться. Хотя, я всё равно больше qemu люблю.

Слушай, а я правильно понимаю что vagrant не умеет в нормальное управление дисками? Ну, там, задать размер. Всё что я находил это дикие наборы костылей с вызовами команд VBoxManage на сторадж. Но даже получить путь к файлу там непросто.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Ага. Самый простой способ — создать еще диск нужного размера и подмонтировать его. Боксы вагранта имеют фиксированный размер, но в последнее время их стали делать побольше, гигов на 40. Федора и что-то еще.

С этим самым докером как раз попадос: разворачиваешь вагрант, собираешь там пару докер образов и диск тут же кончается. И хостовую файловую систему не подтянуть, потому что докер мапит дырявый файл под себя.

UPD. Ну и да, подтянуть хостовую ФС конечно самый простой вариант, но это не всегда возможно (выше пример с докером) и ломает изоляцию виртуальной машины.

staseg ★★★★★
()
Последнее исправление: staseg (всего исправлений: 1)
Ответ на: комментарий от true_admin

а посоветуй хорошую управлялку виртуалками через командную строку, вот чтобы можно было из готовых образов разворачивать и оверрайдить часть параметров (порты, память, итп)? Желательно чтобы уже была заготовленная библиотека образов, в частности протухших centos6 :) Чтобы можно было выбросить вагрант-виртуалбокс и жить спокойно

просто разворачивать весь vsphere ради пары виртуалок - это какой-то даже не overkill, это double kill, triple kill, multi kill, ultra kill, rampage, monster kill, UNSTOPPABLE, WICKED SICK, GODLIKE

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)

Я пока так и не разобрался, как правильно засунуть в докер реплики монги, и перемещать их при необходимости поменять сервер. Когда образы совсем stateless (скрипты на похапе, ноде, ...) - там особых вопросов нет.

Vit ★★★★★
()
Последнее исправление: Vit (всего исправлений: 1)
Ответ на: комментарий от stevejobs

а посоветуй хорошую управлялку виртуалками

сам ищу такую :( Я в шоке от того говнища что вижу. Собстно, вариантов очень немного — голый virtualbox, какой-нить libvirt, vagrant, virt-manager и, может, ещё что. Я пошёл читать virt-manager, может оно хоть что-то путное умеет. Есть ещё всякие более тяжёлые вещи типа openebula (openstack даже не вспоминаю), но это уже много гемора с настройкой.

заготовленная библиотека образов

Хы-хы :).

Vit

Когда образы совсем stateless (скрипты на похапе, ноде, ...) - там особых вопросов нет.

Самая большая моя проблема. Хочется убивать того кто этот stateless придумал и популяризировал. Все забыли/забили про базы данных, их мониторинг и репликацию. Но докер таки разродился persistent storage (Data volumes). Посмотри https://docs.docker.com/engine/userguide/containers/dockervolumes/ , в крайнем случае можно делать scp/rsync между папками на серверах :). Возможно, есть уже скрипты/средства для этого, я с докером толком ещё не разбирался.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Не-не-не, я в курсе про data volumes. Меня как раз интересует управление ими, потому что они прибиты гвоздями к конкретной железке, если ты не ынтырпрайзный буратина с сетевыми полками.

Решать вопрос вводом в монговский кластер полностью новых реплик и выводом старых по-моему перебор. Хотя если существуют какие-то специфичные вменяемые хаки для mongo + docker, меня б тоже устроило.

Vit ★★★★★
()
Ответ на: комментарий от Vit

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

Дык rsync и вперёд, не? Это же обычная папка, должны работать стандартные средства.

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

Абсолютно, и чем больше база тем хуже. Ящитаю это вообще не вариант. И вот сам щас думаю что делать.

true_admin ★★★★★
()
Ответ на: комментарий от Deleted

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

PS. Визуально, как тупой юзер, я б предпочел чтобы data volumes перетаскивались автоматически при перетаскивании основного контейнера, который их юзает.

Vit ★★★★★
()
Ответ на: комментарий от true_admin

Дык rsync и вперёд, не?

Вручную :) ? IMHO перемещение контейнеров в кластере/облаке - довольно востребованная операция. Типичная причина - замена/перенос сервера.

Vit ★★★★★
()
Ответ на: комментарий от Vit

IMHO перемещение контейнеров в кластере/облаке - довольно востребованная операция.

Похоже, нужно вот это: https://clusterhq.com/flocker/introduction/ Буду сегодня-завтре тестить.

Но, в целом, как я уже говорил, у меня волосы дыбом от большинства этих облачных проектов. Половина точно предполагает что у тебя есть аккаунт на амазоне где все данные и хранятся и «переносятся». Либо толкают свой проприетарный PaaS. Нынешнее поколение вообще не понимает что такое «замена сервера» потому что их никогда не видело :).

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Флокер похож на правду, спасибо. Кастани как будет инфа пожалуйста.

Vit ★★★★★
()

Вообще, по-моему ты пытаешься замутить админку одновременно для железки и бизнес-процесса (прохождения образа по этапам). Что-то тут не так. По-моему эти вещи не особо связаны.

Continuous deployment смотрел? Каждый коммит, который прошел тесты на CI - автоматически выкатывается.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Continuous deployment смотрел? Каждый коммит, который прошел тесты на CI - автоматически выкатывается.

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

Deleted
()
Ответ на: комментарий от Deleted

А зачем такому народу админка, если они кнопку хотят? Можно по кнопке перекидывать сорцы в ветки testing/deployment, и оттуда автоматически раскатывать.

Есть что-то еще, что мешает побить проблему на 2 части?

Vit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.