МегаполОС или как мы были вынуждены переизобрести DevOps

[lagger]

А как насчёт воспроизводимости настроенного окружения? (Например надо развернуть точно такой же кластер, но на других серверах)

[freehabr]

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

[Win32Sector]

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

[Thomas_Hanniball]

Мы хотели навести порядок со своими проектами
…
…
Мы решили использовать инструменты DevOps
…
…
Мы пишем свою ОС для контейнеров, которую назвали МегаполОС.

Кажется, здесь что-то пошло не так. :)

P.S. Касательно самой идеи ОС для контейнеров. Посмотрите в сторону СoreOS и RancherOS. Возможно, это то, что вы давно искали.

P.P.S. полОС или полуОС — это название ассоциируется с OS/2 — операционной системой фирмы IBM.

[freehabr]

Мы смотрели существующие решения. Они не автоматизируют полностью жизненный цикл приложения.

[nnstepan]

25 лет в айти и последние несколько лет тоже не могу понять, как айти свернуло не туда, почему в 21 веке надо писать ямл файлы и знать и помнить кучу не особо полезной информации. Напоминает мою первую сборку ядра в слаке году в 97. Так что мнение автора разделяю полностью.

[freehabr]

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

[dobropalka]

Ну, а какие варианты?

комплексность систем возросла, количество слоев абстракций - тоже.

Или вы пишете ямлы, или bash с .ini - принципиально разницы то нет

[freehabr]

Пора перейти на следующий уровень абстракции.

[dobropalka]

чтобы что? писать код вместо ямлов?

а потом конфиги к этому коду?

а потом ямлы для управления конфигами?

и так потом.на третий круг

[freehabr]

Не писать код, конфиги и команды.

[dobropalka]

ну магии не бывает.

вот надо мне поставить мускуль+галера с моими конфигами и моим количеством нод, и это вашим кодом не поддерживается. Что делать? писать собственный драйвер.

а зачем?

[Strangerx]

На самом деле вы изобрели.. Internal Developers Platform Webhosting!

На скриптах, как в свое время всякие ISPmanager’ы и cPanel VestaCP.

Вопрос: зачем?

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

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

И ведь идея-то правильная, обучать разрабов, тем более сторонних, ямлу, хелму и куберу, не нужно, а может и вредно.

Но реализация.. не стандартная, мягко скажем ;)

Зачем уходить от стандартов?

Зачем решать то, что уже решено?

Зачем использовать технологии, от которых отказывается сообщество (docker)?

Эти вопросы не требуют ответов, но стоит хорошенько подумать :)

Удачи!

[MrFrizzy]

Может вам стоит попробовать другие оркестраторы вместо k8s\swarm, прежде чем дальше писать свой?
- https://juju.is/
- https://www.nomadproject.io/ + https://www.consul.io/

[freehabr]

Мы смотрели существующие решения. Они не автоматизируют полностью жизненный цикл приложения.

[dobropalka]

так и вы не автоматизируете. Вы пишете враппер над текущими решениями, и шаг влево\вправо - надо садиться писать драйвер

[freehabr]

Мы пишем не только врапперы, но и логику позволяющую осуществлять высокоуровневые команды.

[dobropalka]

проблема кнопок "сделать хорошо" в том что у каждого это "хорошо" - различается