А вот оно что. Ну сильно завернули - потому что в начале статьи кажется, что растягивали ETCD самого k8s. И тут я надеялся на не хилую драму и высокий полёт инженерной мысли, а потом понял что тянули вспомогательный, который служит сервисом блокировок/хранилищем.
Ну примеры периодически проскакивают. Просто вы ищете их не там. У Флант есть тулза для деплоя - werf. Вот в статьях по ней и стоит искать ответы на ваши вопросы. Но, опять-таки, werf - это просто пример, вы можете использовать всё что вам удобно, по рукам вам за это не настучат. Можете использовать всё что угодно.
Олег, на мой взгляд, ты путаешь концепцию и инструментарий. В концепции нет точного описания инструментов, а есть только общая линия построения рабочих процессов. Именно поэтому там не рассматривается повторяемость. Она подразумевается, но её реализация отдана на откуп sre-инженера.
Ну раз вы не можете гарантировать повторяемость - тогда это к вам же вопросы, а не к gitops.
Люди бьются, чтобы у них была повторяемая среда. Чтобы их системы сборки изо дня в день выдавали один и тот же результат, а вы нивелируете их усилия своим отношением - у нас не получилось - ни у кого не получилось. Пока я это вижу и в статье и в ответах автора.
Вот прям под каждым словом подпишусь. У вас же программы бинарные, а код вполне себе текстом является. Почему же тогда вас смущает docker-образ, но бинарник, полученный путём компиляции, не смущает.
После прочтения не покидает ощущение, что статья является не критикой gitops, а антирекламой flux.
Как уже выше заметили - наличие registry не отменяет принципа единого источника правды. Просто некоторые системы понимают один формат, в некоторые он другой и, соответственно, внедрение некой подписи выглядит как достойное расширение - есть коммит в git - он подписан ключем maintainer, далее по цепочке "подписываются" или тегируются артефакты. И вот у вас есть стройная цепочка. Главное, чтобы CD сам в Git не лез.
Есть такое понятие - цельность инструмента. Тут именно про это история. Есть центральный модуль для входа, автопровизионинг dashboards. Соответственно модули установлены с определённым списком настроек, которые спускаются сверху-вниз.
То, что это реально сделать самому - спору нет. Однако зачем, если есть готовое?
Опять же, никто не запрещает использовать лишь часть инструментов, установив остальные самостоятельно.
В статье устаревшие конфиги приведены как пример. С 8 версии php-fpm появилась директива pm.status_listen, которая позволяет избавиться от уродливого костыля в виде пула healthcheck. Это так же позволит наконец-то сделать скейлинг исходя из загрузки worker- процессов.
Рабочая схема такая - DVA1622 - 7.1.1-42962 + SurveillanceStation 9.0.2-10057
Для тестовых примеров я бы предложил образ
Стоит использовать пакет iptables-persistent или переходить на nftables, а не /etc/network/interfaces. Да и с interfaces пора уходить на systemd.
А вот оно что. Ну сильно завернули - потому что в начале статьи кажется, что растягивали ETCD самого k8s. И тут я надеялся на не хилую драму и высокий полёт инженерной мысли, а потом понял что тянули вспомогательный, который служит сервисом блокировок/хранилищем.
Привет. Учитывая, что всё это делалось для Patroni - почему не сделали standby_cluster?
Ага. Я честно изуродовал ноутбук дочери :) и знаете - всё завелось. Был бы ценителем фряхи - так и оставил бы.
Хочется отметить, что это не всегда так. Иногда авторы публикую статьи в блог компании потому, что статья завязана на бизнес компании.
Так это же Proof of Work. Какой уровень отказоустойчивости нужен уже должен пользователь.
Жаль. Как пользователь ваших продуктов - меня это интересует.
Очень интересно. А не думали автоматически из ilo брать данные и реализовывать превентивный мониторинг? Или даже продавать это клиентам.
Потому что deckhouse == kubernetes. Этот дистрибутив приближен к ванильному K8S и различий нет. В то время как в Openshift свои примитивы для деплоя.
Ну примеры периодически проскакивают. Просто вы ищете их не там. У Флант есть тулза для деплоя - werf. Вот в статьях по ней и стоит искать ответы на ваши вопросы. Но, опять-таки, werf - это просто пример, вы можете использовать всё что вам удобно, по рукам вам за это не настучат. Можете использовать всё что угодно.
Тем не менее ты её приводишь в пример.
Олег, на мой взгляд, ты путаешь концепцию и инструментарий. В концепции нет точного описания инструментов, а есть только общая линия построения рабочих процессов. Именно поэтому там не рассматривается повторяемость. Она подразумевается, но её реализация отдана на откуп sre-инженера.
Ну раз вы не можете гарантировать повторяемость - тогда это к вам же вопросы, а не к gitops.
Люди бьются, чтобы у них была повторяемая среда. Чтобы их системы сборки изо дня в день выдавали один и тот же результат, а вы нивелируете их усилия своим отношением - у нас не получилось - ни у кого не получилось. Пока я это вижу и в статье и в ответах автора.
Вот прям под каждым словом подпишусь. У вас же программы бинарные, а код вполне себе текстом является. Почему же тогда вас смущает docker-образ, но бинарник, полученный путём компиляции, не смущает.
Ты сам werf упомянул. Вот там, на мой взгляд, лучше. Там есть тот самый механизм подписи, пусть и условный. И связка werf + argocd неплоха.
После прочтения не покидает ощущение, что статья является не критикой gitops, а антирекламой flux.
Как уже выше заметили - наличие registry не отменяет принципа единого источника правды. Просто некоторые системы понимают один формат, в некоторые он другой и, соответственно, внедрение некой подписи выглядит как достойное расширение - есть коммит в git - он подписан ключем maintainer, далее по цепочке "подписываются" или тегируются артефакты. И вот у вас есть стройная цепочка. Главное, чтобы CD сам в Git не лез.
Есть такое понятие - цельность инструмента. Тут именно про это история. Есть центральный модуль для входа, автопровизионинг dashboards. Соответственно модули установлены с определённым списком настроек, которые спускаются сверху-вниз.
То, что это реально сделать самому - спору нет. Однако зачем, если есть готовое?
Опять же, никто не запрещает использовать лишь часть инструментов, установив остальные самостоятельно.
В статье устаревшие конфиги приведены как пример. С 8 версии php-fpm появилась директива
pm.status_listen, которая позволяет избавиться от уродливого костыля в виде пулаhealthcheck. Это так же позволит наконец-то сделать скейлинг исходя из загрузки worker- процессов.