пролема интересная да.

давай целиком.

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

вот наверное полный вариант

Да, все ясно теперь

это базовая вводная :) думаю что от нее будут какие то отклонения но пока так вот

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

Я уже придумал название. Smuggler

Как насчет виртуалки virtualbox или vmware, со всеми обновлениями (упаковано в мирУ). Мы ее копируем на комп ответственного лица. Там докер регистри с мини докерхабом. Там же ansible tower или awx. Все сделано красиво, заказчик видит и понимает все действия.

да. сейчас так первая партия и приехала

в виде ova файла

ибо там конечно со сторны заказчика esxi

Плюс в том, что это хорошо можно протестировать и отточить... Было бы круто научиться генерировать ova сервер с полным пакетом нужного софта...

деплой золотыми образами старая тема, но довольно толстая

ну это не совсем так. деплоится не ova а то что на нем. ansible (docker|snaps|rpm) + маленькая копия интернета

а ova приходит на флешке по почте или еще как.

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

но деплой по почте это конечно жесть))

деплой золотыми образами старая тема, но довольно толстая

Видал я и такое - когда есть ami амазонский, и при этом все на него боятся дышать (вдруг протеряется?), и понятия никто не имеет, как эту дрянь воссоздать (=просраны/никогда не написаны доки).

Видал я и такое - когда есть ami амазонский, и при этом все на него боятся дышать (вдруг протеряется?), и понятия никто не имеет, как эту дрянь воссоздать (=просраны/никогда не написаны доки).

Ну тут другое, ova создан повторяемыми методами

ова создан пакером конечно

ова создан пакером конечно

Ну это ова самого приложения, да? не системы для его деплоя

сразу всё.

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

не

инкрементальный апдейты ova это bindiff

это явно не улучшает задачу

Ну тут другое, ova создан повторяемыми методами

Тогда всё просто, да. Однако я согласен с тем, что разработка для защищаемых периметров - боль.

ну снап выглядит огонь

ну снап выглядит огонь

это чтобы rpm/deb не готовить?

Когда я был в софтовой конторе основным средством доставки был ova... но там релизы раз в квартал.

@freeseacher У них там нет никакой другой централизованной системы обновления? например свои rpm/deb?

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

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

+1 deltarpm опять же

вот прям я чувствую запахи red hat, sattelite и типа того

или как там оно называется)

это чтобы rpm/deb не готовить?

что бы не готовить их. ибо 25 микросервисов да. 4 базы. консул, мемкеш, питона много и патчинг пакетов из pip

и на 25 не существует опенсорсных готовых пакетов?

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

Или еще конфигурация на всем этом?

конфигурация в консуле же

и на 25 не существует опенсорсных готовых пакетов?

нет. их мы и пишем. эти 25...

и будет 35 :)

Когда вырасту - напишу книгу "Микросервисы для периметра"

что бы не готовить их. ибо 25 микросервисов да. 4 базы. консул, мемкеш, питона много и патчинг пакетов из pip

ок, 25 пакетов. что там с базами? бОльшая часть всей этой дряни уже опакечена.

да базы опакечены.

кликхаус, монга, постгрес уже да

а вот очереди нет.

nsqd

там конечно гобирарники

зато есть докер)

я вот прямо не могу отказаться от этого пути, ибо все упроститься если организовать доставку образов.

У меня сервисы на питоне. Для нового сервиса я тупо копирую spec-файл с миимальными правками, на выходе получаю rpm, который автомагически учитывает версию, релиз, суффикс, что-то там ещё, и внутри venv питона с приложением (при этом то, что относится к shared-части venv, на всех хостах одинаково).

У меня сервисы на питоне. Для нового сервиса я тупо копирую spec-файл с миимальными правками, на выходе получаю rpm, который автомагически учитывает версию, релиз, суффикс, что-то там ещё, и внутри venv питона с приложением (при этом то, что относится к shared-части venv, на всех хостах одинаково).

есть чо почитать ?

ты пакетишь готовый venv ?

я вот это часто юзал. https://github.com/jordansissel/fpm Оно достаточно умное

https://github.com/jordansissel/fpm/blob/master/examples/python/twisted/Makefile

я вот это часто юзал. https://github.com/jordansissel/fpm Оно достаточно умное

я юзал. оно не оч.

Если отклонения от того что делает нужны, то да. Меня устраивал

для гобинарей fpm рулит

Смотря что нужно. На хабре я писал про свой Python-скрипт, который поддерживает rpm-репу. В итоге дженкинс тупо курлом загружает пакеты, этот скрипт их принимает, раскладывает и умно запускает createrepo для обновления метаданных в репе.

я вот это часто юзал. https://github.com/jordansissel/fpm Оно достаточно умное

Это прямо суровая срань на рубях. Для простых вещей, которые нужно опакетить, я использую checkinstall.

Это прямо суровая срань на рубях. Для простых вещей, которые нужно опакетить, я использую checkinstall.

Зато когда мне надо было создать пакет для соляриса оно мне помогло)

Зато когда мне надо было создать пакет для соляриса оно мне помогло)

Checkinstall тебе помог бы больше

Оно не для deb разве?

а не)

не только

что попросишь

то и будет

slackware, rpm, debian. вроде все

а тот умеет deb rpm solaris freebsd tar directories Mac OS X .pkg files (osxpkg) pacman (ArchLinux) packages

а этого мало, что ли? одна пара deb/rpm покроет бОльшую часть продакшнов. tar, положим, не формат пакета, да и directories тоже.

Ну мне надо было реально быстро запилить pkg для opensolaris

потом все равно пришлось пилить свой билд для родной системы

Ну мне надо было реально быстро запилить pkg для opensolaris

Ну ок, если ты нашёл инструмент, который решил твою конкретную задачу - это лично тебе плюс, а не плюс инструменту.

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

А остальное - родные системы надо ковырять имхо.

Согласен с обоими утверждениями.

не топлю за него, но если устраивает результат то вполне.

тебя и меня не устраивает в проде)