- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Аноним, 22:56 , 01-Ноя-23 (2)
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Хру, 23:00 , 01-Ноя-23 (3)
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Аноним, 02:00 , 02-Ноя-23 (7) +5
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Аноним, 04:13 , 02-Ноя-23 (9) –3
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., BrainFucker, 05:51 , 02-Ноя-23 (10) –1
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Анон из села Кукуево, 09:30 , 02-Ноя-23 (15) +1
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., BrainFucker, 09:47 , 02-Ноя-23 (17) +3
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Аноним, 10:18 , 02-Ноя-23 (19) +1
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., InuYasha, 10:30 , 02-Ноя-23 (22)
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., BrainFucker, 11:18 , 02-Ноя-23 (25)
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., фф, 12:54 , 02-Ноя-23 (32) +1
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Пряник, 12:43 , 02-Ноя-23 (31)
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Анон из села Кукуево, 09:32 , 02-Ноя-23 (16) +2
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Аноним, 03:41 , 02-Ноя-23 (8) +1
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Аноним, 12:24 , 02-Ноя-23 (30) +1
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., антонимус, 13:30 , 02-Ноя-23 (34)
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Легивон, 19:02 , 02-Ноя-23 (44)
Он очень нужен тем кто хочет gitops без костылей. В обычном gitops ты вначале коммитишь код, а только потом CI собирает образ, но одновременно с этим по определению gitops ты хочешь чтобы состояние твоего приложения описывалось кодом. С наколеночным тагированием это невозможно. С внеднением этих ваших кубирнетисов в массы (а на самом деле и до них, например в 12 factor app уже говорится об этом) результом релиза становится не просто какой-то абстрактный докер образ, а еще и helm chart неотрывно с ним связаный, нужный для его правильного запуска и параметризации по окружениям. И из-за непреодолимой последовательности этого процесса, что код - это один коммит, а изменение образов в helm chart - следующий, приходилось городить лютый зоопарк с двойными репозиториями или костылями в CI. В werf можно избавиться от необходимости тагирования образов вообще и перейти на тагирование helm чартов - сущностей более высокого порядка обновременно описывающих еще и конфигурацию. Все остальное что есть в werf - это просто мишура по сравнению с этим. Если бы он просто заменял 3 тулзы - он нафиг был бы не нужен. Еще важная киллерфитча - возможность маштабируемой и воспроизводимой сборки без докера. (если собирать на 10 ранерах один и тот же код, артефакт в регистри будет неизменным, не будет перезаписываться/повторно качаться, как это бывыет в сборках без кеша).
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Аноним, 22:41 , 02-Ноя-23 (50) –1
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Легивон, 22:22 , 03-Ноя-23 (59)
Что ты несешь? > Лютый зоопарк - это натравливать gitops operator на репу с исходниками программыЗоопарк это когда у тебя много разношерстных зверей сидят в разных клетках. У тебя 2 репо и 2 тулзы связаные с деплоем - собиратель образов и "gitops operator". У меня 1 репо и 1 тулза и для сборки и для деплоя (и даже команда одна). Вот и подумай у кого зоопарк, если результат один - приложение раскатано в кубер и определяется кодом в гите. И давай пожалуйста конкретику, почему запускать программу развертывания над кодом это плохо? Мы хотим чтобы состояние в кластере определялось состоянием кода - над чем собственно еще запускать (по определению)? То что вы делаете со 2 репо и отрендереными чартами - это совсем не похоже на то что состояние приложения определяется кодом приложения. Это вторичная ненужная сущность усложняющая систему и ломающая изначальный посыл. У вас на самом деле только конфигурация приложения определяется кодом, а само приложение, его код - нет, оно осталось за скобками когда-то кем-то собраным в образ и мы должны этому свято верить. > С таким отбитым подходом, какие инструменты не придумывай, всё равно фигня получится, потому что сюр изначально заложен в архитектуру. В чем отбитость подхода? Можно конкретики? Что является критерием отбитости? Забыли добавить сущностей ради сущностей? > gitops operator Постоянно офигеваю над этими хипсторами нахватавшимися непойми чего на курсах. У них у всех как на подбор gitops - это не абстрактный подход (отделенный от реализации) по тому как надо делать деплоймент, а это конкретная реализация gitops operator работающая по модели pull... и вообще в 80% случаев это конкретная программа - argo cd. Сначала они настраивают по стековерфлоу свою argo cd, а потом в их голове оказывается что получившееся и есть gitops, и они лезут со своим выдуманным "gitops" пачкать интернет. Печально.
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., YetAnotherOnanym, 08:35 , 02-Ноя-23 (13) +3
- Доступен Finch 1.0, инструментарий для Linux-контейнеров от ..., Пряник, 12:14 , 02-Ноя-23 (28) –2
|