LINUX.ORG.RU

Haven — система управления Docker

 ,


6

8

Проект Haven представляет собой надстройку над инструментарием Docker и предназначен для управления кластерами (основанными на Swarm) или отдельными нодами; имеется веб-интерфейс. Исходный код распространяется под лицензией Apache 2.0.

Концепция проекта:

  • единый интерфейс, позволяющий работать c множеством кластеров и нод;
  • ориентированность на Docker: продукт умеет работать только с ним, но зато полноценно;
  • автоматизация рутинных операций, таких как обновление и очистка.

Некоторые функции:

  • операции над отдельным контейнером (создание, удаление, запуск, просмотр логов и т. п.);
  • объединение контейнеров в «приложения» для последующего развёртывания в другом окружении;
  • импорт приложений из Compose;
  • создание Swarm-кластеров во время выполнения;
  • работа с реестрами Docker (просмотр, назначение каждому кластеру своего списка реестров);
  • перенос нод между кластерами;
  • пакетные операции обновления контейнеров с возможностью отката;
  • централизованное хранение настроек контейнеров (пример);
  • удаление неиспользуемых образов контейнеров.

>>> Подробности

Deleted

Проверено: Shaman007 ()
Последнее исправление: sudopacman (всего исправлений: 4)

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

развернутого стенда для показа нет, но доступно read-only API

и пара скриншотов:

1. Процесс upgrade/rollback images в кластере отсортированы по тому есть ли более свежая версия

2. Процесс деплоя в одну кнопку используя параметры для кластера/контейнера из внешнего источника https://github.com/codeabovelab/haven-example-container-configuration/blob/ma...

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

У нас есть: оператор - называется, обычно на эту роль подходит любой способный читать документацию. А у вас? Если нет то можно напрограммировать 8)

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

2) Может ли это производится из CI?

есть еще решение для CI, tool может пулить указанные repositories в которые паблишит CI, на предмет появления новых версий images и стартовать их с указанными параметрами

UI для этого еще нет - в процессе наполнения

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

Амазон это хостинг с кучей кривых сервисов

Вопросов больше не имею, проталкивайте свой велосипед дальше, авось, на народе.сру взлетит.

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

Как обычно дьявол в деталях, нет рядя критичных вещей в rancher (исходя из _нашего_ с subwoofer опыта промышленного использования docker, swarm, compose)

  • Cоздание/удаление тегов, пример: прошли какие-то images UAT, их нужно отметить как готовые к prod и только такие имеджы должны быть видны на prod, для этого registries для кластера могут иметь фильтры
  • Наличие своей конфигурации для контейнера (или даже версии image) для кластера, чтобы можно было легко запустить контейнер не указывая переменные на своем окружении и желательно в системе версионного контроля. Можно хранить свой compose file для каждого кластера, но тут есть ряд неудобных вещей (сейчас есть docker stack он часть проблем решает)
  • Расширенные политики для swarm - например есть 4 ноды с разными контейнерами и нужно 4 инстанса какого-то конкретного контейнера, swarm запустит по одному на инстансe на ноде гарантироанно только если они например используют общий порт иначе нет гарантий.
  • Разные групповые операции такие как upgrade/_rollback_ списка сервисов, use/cases:
    • проверять/обновлять все имейджи из данного репозиторя на тесте каждые пять минут
    • обновить разово например имейджи использующие общее АПИ, или например ELK стек, etc.
    • или просто кликнуть обновить все в этом кластере
  • Бекапирование.

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

interair
()

Это похожее на то что человек описывает http://vasilisc.com здесь о snappy?
Тогда нативные пакеты туда ну явно никак пихать не нужно.

hbars ★★★★★
()

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

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

яб не сказал что там из 100%, но они такие есть, и где ты смотрел для меня загадка, т.к. лежат они стандартно для maven проектов + кусочек интеграционных снаружи

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

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

- несколько инстансов UI (возможность заложена но пока не используется)

- пайплайны (это нужно исключительно девопсам)

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

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

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

На первом уровне вопросы больше организационные:

- Почему это не лисапед, почему раньше (или сейчас) нельзя было взять готовое и доработать (не было, плохое, кривое, ...)
- Нет ли «вендор-локов», из-за которых надо серьезно переучиваться с альтернативных тулзов и переделывать код. Например, совсем свой формат конфигов вместо композовских и т.п.
- Что с «поддержкой»? Явные косяки закрываются в рабочее время или «PR welcome»? Какова вероятность что завтра начальство скажет «мы больше не можем этим заниматься».
- roadmap есть? (вы уже все фантазии воплотили, или работы еще на годы вперед).

По технической части лично у меня задачи простые:

- развернуть несколько сервисов на одной машине
- возможно развернуть монгу в реплике
- бакапы монги
- безопасное управление «секретами» (пробрасывание ключей, конфигов, сертификатов в образы)

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

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

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

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

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

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

Например, совсем свой формат конфигов вместо композовских и т.п.

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

Что с «поддержкой»? Явные косяки закрываются в рабочее время или «PR welcome»? Какова вероятность что завтра начальство скажет «мы больше не можем этим заниматься».

мы его только выкатили 8), пока «завтра» - это чтобы появились эти самые косяки кроме как найденные нами.

roadmap есть? (вы уже все фантазии воплотили, или работы еще на годы вперед).

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

- безопасное управление «секретами» (пробрасывание ключей, конфигов, сертификатов в образы)

технически как ты это себе представлешь: монтирование с хоста, или из другого контейнера или вообще что-то другое?

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

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

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

технически как ты это себе представлешь: монтирование с хоста, или из другого контейнера или вообще что-то другое?

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

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

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

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

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

они такие есть

Упс, я не везде проверил :). То что тесты есть это радует.

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

Надстройка над надстройкой и надстройкой погоняет. Нафига?

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

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

Средство управления контейнерами. А контейнры это современное модное средство «доставки» приложений. Ты можешь создать репозиторий из контейнеров, обновлять их, запускать итп.

Что-то вроде lxc, только с немного другой философией (один контейнер — одно приложение, disposable containers итп).

true_admin ★★★★★
()

Ждём интерфейс для управления Haven.

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