The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Доступен Finch 1.0, инструментарий для Linux-контейнеров от компании Amazon  , opennews (??), 01-Ноя-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


44. "Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..."  +/
Сообщение от Легивон (?), 02-Ноя-23, 19:02 
Он очень нужен тем кто хочет gitops без костылей.
В обычном gitops ты вначале коммитишь код, а только потом CI собирает образ, но одновременно с этим по определению gitops ты хочешь чтобы состояние твоего приложения описывалось кодом. С наколеночным тагированием это невозможно.
С внеднением этих ваших кубирнетисов в массы (а на самом деле и до них, например в 12 factor app уже говорится об этом) результом релиза становится не просто какой-то абстрактный докер образ, а еще и helm chart неотрывно с ним связаный, нужный для его правильного запуска и параметризации по окружениям. И из-за непреодолимой последовательности этого процесса, что код - это один коммит, а изменение образов в helm chart - следующий, приходилось городить лютый зоопарк с двойными репозиториями или костылями в CI.
В werf можно избавиться от необходимости тагирования образов вообще и перейти на тагирование helm чартов - сущностей более высокого порядка обновременно описывающих еще и конфигурацию.
Все остальное что есть в werf - это просто мишура по сравнению с этим. Если бы он просто заменял 3 тулзы - он нафиг был бы не нужен.
Еще важная киллерфитча - возможность маштабируемой и воспроизводимой сборки без докера. (если собирать на 10 ранерах один и тот же код, артефакт в регистри будет неизменным, не будет перезаписываться/повторно качаться, как это бывыет в сборках без кеша).
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

50. "Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..."  –1 +/
Сообщение от Аноним (6), 02-Ноя-23, 22:41 
> С внеднением этих ваших кубирнетисов в массы (а на самом деле и до них, например в 12 factor app уже говорится об этом) результом релиза становится не просто какой-то абстрактный докер образ, а еще и helm chart неотрывно с ним связаный, нужный для его правильного запуска и параметризации по окружениям. И из-за непреодолимой последовательности этого процесса, что код - это один коммит, а изменение образов в helm chart - следующий, приходилось городить лютый зоопарк с двойными репозиториями или костылями в CI.

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

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

Ответить | Правка | Наверх | Cообщить модератору

59. "Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..."  +/
Сообщение от Легивон (?), 03-Ноя-23, 22:22 
Что ты несешь?
> Лютый зоопарк - это натравливать gitops operator на репу с исходниками программы

Зоопарк это когда у тебя много разношерстных зверей сидят в разных клетках.
У тебя 2 репо и 2 тулзы связаные с деплоем - собиратель образов и "gitops operator". У меня 1 репо и 1 тулза и для сборки и для деплоя (и даже команда одна). Вот и подумай у кого зоопарк, если результат один - приложение раскатано в кубер и определяется кодом в гите.
И давай пожалуйста конкретику, почему запускать программу развертывания над кодом это плохо? Мы хотим чтобы состояние в кластере определялось состоянием кода - над чем собственно еще запускать (по определению)? То что вы делаете со 2 репо и отрендереными чартами - это совсем не похоже на то что состояние приложения определяется кодом приложения. Это вторичная ненужная сущность усложняющая систему и ломающая изначальный посыл. У вас на самом деле только конфигурация приложения определяется кодом, а само приложение, его код - нет, оно осталось за скобками когда-то кем-то собраным в образ и мы должны этому свято верить.
> С таким отбитым подходом, какие инструменты не придумывай, всё равно фигня получится, потому что сюр изначально заложен в архитектуру.

В чем отбитость подхода? Можно конкретики?
Что является критерием отбитости? Забыли добавить сущностей ради сущностей?
> gitops operator

Постоянно офигеваю над этими хипсторами нахватавшимися непойми чего на курсах.
У них у всех как на подбор gitops - это не абстрактный подход (отделенный от реализации) по тому как надо делать деплоймент, а это конкретная реализация gitops operator работающая по модели pull... и вообще в 80% случаев это конкретная программа - argo cd.
Сначала они настраивают по стековерфлоу свою argo cd, а потом в их голове оказывается что получившееся и есть gitops, и они лезут со своим выдуманным "gitops" пачкать интернет.
Печально.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру