у нас нет деплоя сразу в несколько кластеров. Мы придерживаемся стандартного подхода dev-stage-prod. Код разделен по веткам. Описание переменных под каждое окружение с помощью helm и gitlab environment.
Согласен, Go мне тоже ближе чем Ruby. И да Gitea, как и Gogs намного легковесней. Знаю что у них недавно появилось CI/CD наподобее GitHub Actions. Но не уверен что оно сравнимо с Gitlab( тут спорить не буду очень давно не трогал Github Actions). Да и на самом деле все зависит от проектов и команд. Проектов у нас много разных и команд много разных, c разным стеком, инфраструктурой и прочим. Тут плюшки Gitlab намного больше закрывают чем только хранение кода. Если бы у нас была одна команда с парой проектов я бы тоже однозначно топил за Gitea.
Видимо мы друг друга не поняли, речь шла чисто про cli уитилиту werf и нас вполне устраивает гитерменизм (не сказать что мы его не нарушаем конечно). Насчет Rancher Server - пробывали, но он превратился в огромного монстра из разных операторов, плюс мы не сильно хотели завязываться на VendorLock ну и есть кучу других рабочих нюансов почему конкретно Rancher Server мы не хотим использовать. Про Rancher Fleet тоже в курсе, его не рассматривали, хотя его возможность деплоить на несколько кластеров сразу - заманчива.
Werf - это утилита сI/cd, у нее нет оператора. Она умеет интегрироваться с Argo CD, но мы это редко используем, ибо Werf сама по себе закрывает наши «хотелки». Подробней можно почитать здесь.
Поясню к чему вопрос, не для желания кого то задеть и повысить чсв. Я много работаю с вендорами и зачастую с разными внедрениями. И за частую все они страдают одной проблемой - отсутствием автоматизации, что бы позволяло ускорить внедрение. Потому ваше согласие со статьей меня удивляет. Готов выслушать ваше мнение по этому поводу.
Опять же спорно, большинство контейнеров снабжено хорошей докой, да и докерфайл зачастую хватает почитать. Насчет тонкой настройки - контейнеры не отменяют чтения доки по соответсвующему софту. Принцип х*як х*як в продакшен зависит от специалиста, но никак к применяемой технологии. Будь то вм, iac, контейнеры, ката контейнерс и так далее. Еще раз повторюсь я не сторонник пихания всего в контейнеры, только когда это оправдано. И не сторонник распила монолита, если монолит не реальный Франкенштейн из костылей и велосипедов.
Ну ради юмора замерь время сколько ты руками раскатываешь что то сродни пускай Apache NIFI и за сколько подымешь в докер компоузе. Я не спорю что контейнеры - не панацея. Но все таки все забывают что контейнеры это просто быстрый и удобный способ доставки и упаковки приложений. Современный аналог нсиса и далее-далее-далее. Так что утверждение автора как и ваше спорно, хоть от части и не лишено смысла.
Коллеги то вам как мед "неправильные" девопсы попадались. Правильным - без разницы докер это или не докер. А некоторые даже strace иногда расчехляют. То что пришло поколение после курсов (в основном 2000+ года рождения) которые хотят миллионы и ничего не делать и учится тут я с вами согласен. Не раз собеседуя на таких нарывался.
"Ближайшие лет 5 будет в том, что разработчики сами станут строить инфраструктурные решения." - По опыту говорю что это будет тот еще цирк, костыли и велосипеды. Потому что большинство(не готов утверждать что все, видел разных) современных разработчиков в инфраструктуре , а тем более архитектуре не смыслят ничего. Встречаются либо - мое дело писать код - а вы ops парьтесь как хотите, либо я использую то что знаю, а то что этот инструмент для этого не предназначен - "так исторически сложилось". Так что я в корне с вами не согласен.
Из моего будничного - давеча написал api утилитку на go для автоматизации получения сетевых доступов. Но есть много и ops задач, согласен. Все больше сталкиваюсь с тем что разработка умеет писать код, но не понимает как работает определенная бд и архитектурные вопросы в целом. Мой любимый пример очереди в redis. Так что коллеги тут монета ребром как говорится.
Я так понимаю вы предварительно проверяли скрипты на тестовом окружении? И не думали об откатах? Согласен подход рабочий с некоторыми но. Но почему например не развить подход в сторону liquibase , flydb?
Прочел.Отвечу - вы забываете что инженер владеющий практиками DevOps тоже умеет писать код и даже порою не на одном ЯП, но почему то все упорно толкают их именно в сторону ops.
Этож какие такие ETL файлы? Apache Nifi и Airflow прекрасно справляются с ETL процессами. И они как раз гибче масштабируются в k8s. А про модно и молодежно, похоже на старую шутку «вы просто не умеете их готовить»
Так а не проще было просто повесить на Nexus валидные сертификаты?
Коллеги, а вы не рассматривали https://glaber.io/ ? Тот же заббикс с СH. Только еще допиленный.
у нас нет деплоя сразу в несколько кластеров. Мы придерживаемся стандартного подхода dev-stage-prod. Код разделен по веткам. Описание переменных под каждое окружение с помощью helm и gitlab environment.
Согласен, Go мне тоже ближе чем Ruby. И да Gitea, как и Gogs намного легковесней. Знаю что у них недавно появилось CI/CD наподобее GitHub Actions. Но не уверен что оно сравнимо с Gitlab( тут спорить не буду очень давно не трогал Github Actions). Да и на самом деле все зависит от проектов и команд. Проектов у нас много разных и команд много разных, c разным стеком, инфраструктурой и прочим. Тут плюшки Gitlab намного больше закрывают чем только хранение кода. Если бы у нас была одна команда с парой проектов я бы тоже однозначно топил за Gitea.
Видимо мы друг друга не поняли, речь шла чисто про cli уитилиту werf и нас вполне устраивает гитерменизм (не сказать что мы его не нарушаем конечно). Насчет Rancher Server - пробывали, но он превратился в огромного монстра из разных операторов, плюс мы не сильно хотели завязываться на VendorLock ну и есть кучу других рабочих нюансов почему конкретно Rancher Server мы не хотим использовать. Про Rancher Fleet тоже в курсе, его не рассматривали, хотя его возможность деплоить на несколько кластеров сразу - заманчива.
Werf - это утилита сI/cd, у нее нет оператора. Она умеет интегрироваться с Argo CD, но мы это редко используем, ибо Werf сама по себе закрывает наши «хотелки». Подробней можно почитать здесь.
Поясню к чему вопрос, не для желания кого то задеть и повысить чсв. Я много работаю с вендорами и зачастую с разными внедрениями. И за частую все они страдают одной проблемой - отсутствием автоматизации, что бы позволяло ускорить внедрение. Потому ваше согласие со статьей меня удивляет. Готов выслушать ваше мнение по этому поводу.
Опять же спорно, большинство контейнеров снабжено хорошей докой, да и докерфайл зачастую хватает почитать. Насчет тонкой настройки - контейнеры не отменяют чтения доки по соответсвующему софту. Принцип х*як х*як в продакшен зависит от специалиста, но никак к применяемой технологии. Будь то вм, iac, контейнеры, ката контейнерс и так далее. Еще раз повторюсь я не сторонник пихания всего в контейнеры, только когда это оправдано. И не сторонник распила монолита, если монолит не реальный Франкенштейн из костылей и велосипедов.
Ну ради юмора замерь время сколько ты руками раскатываешь что то сродни пускай Apache NIFI и за сколько подымешь в докер компоузе. Я не спорю что контейнеры - не панацея. Но все таки все забывают что контейнеры это просто быстрый и удобный способ доставки и упаковки приложений. Современный аналог нсиса и далее-далее-далее. Так что утверждение автора как и ваше спорно, хоть от части и не лишено смысла.
Внедряете руками и на коленке? очень странно звучит.
Коллеги то вам как мед "неправильные" девопсы попадались. Правильным - без разницы докер это или не докер. А некоторые даже strace иногда расчехляют. То что пришло поколение после курсов (в основном 2000+ года рождения) которые хотят миллионы и ничего не делать и учится тут я с вами согласен. Не раз собеседуя на таких нарывался.
"Ближайшие лет 5 будет в том, что разработчики сами станут строить инфраструктурные решения." - По опыту говорю что это будет тот еще цирк, костыли и велосипеды. Потому что большинство(не готов утверждать что все, видел разных) современных разработчиков в инфраструктуре , а тем более архитектуре не смыслят ничего. Встречаются либо - мое дело писать код - а вы ops парьтесь как хотите, либо я использую то что знаю, а то что этот инструмент для этого не предназначен - "так исторически сложилось". Так что я в корне с вами не согласен.
Соглашусь, однако используют его зачастую именно для оркестрации ETL. Ну насчет нет ничего, не соглашусь. Как же DAG’и которые добавляют ему гибкости.
Из моего будничного - давеча написал api утилитку на go для автоматизации получения сетевых доступов. Но есть много и ops задач, согласен. Все больше сталкиваюсь с тем что разработка умеет писать код, но не понимает как работает определенная бд и архитектурные вопросы в целом. Мой любимый пример очереди в redis. Так что коллеги тут монета ребром как говорится.
Эм это как бы нынче стандарты etl процессов)))
Я так понимаю вы предварительно проверяли скрипты на тестовом окружении? И не думали об откатах? Согласен подход рабочий с некоторыми но. Но почему например не развить подход в сторону liquibase , flydb?
Прочел.Отвечу - вы забываете что инженер владеющий практиками DevOps тоже умеет писать код и даже порою не на одном ЯП, но почему то все упорно толкают их именно в сторону ops.
Хм а вы «старое поколение» до сих пор считаете ftp безопасным протоколом?
И я открою страшную тайну есть виндовые контейнеры и ноды к8s на винде)
Этож какие такие ETL файлы? Apache Nifi и Airflow прекрасно справляются с ETL процессами. И они как раз гибче масштабируются в k8s. А про модно и молодежно, похоже на старую шутку «вы просто не умеете их готовить»