OK
Да я ж не воевать пришёл) а просто поделился)
Size: a a a
2020 January 15
OK
А вообще по Gitops масса примеров
VT
GitOps пока еще молодое определение, как подход уже давно используется
Отлично ложится на k8s и для него в первую очередь его определили.
Для инфрастуктурного кода тоже работает - спорить о подходах не стоит - достаточно почитать источник.
туда разные подходы вписываются
Отлично ложится на k8s и для него в первую очередь его определили.
Для инфрастуктурного кода тоже работает - спорить о подходах не стоит - достаточно почитать источник.
туда разные подходы вписываются
OK
Могу рассказать как работал у меня гитопс на предыдущей работе... Через мальтибранч плагин в дженкинсе отрабатывала хука... Деплоила модуль... Прогоняла тесты если ок.. Мерджилась и тегалась.. Далее вступал в бой ankyra escape... Это была матрица версий и депенденси тулза.. Там пинились версии...далее в jenkins обновлял версию на дев проекте с старой версией... И Прогоняла e2e... Если ок... Далее следующий дев... И так максимально до прода промоутилась 1 версия модуля... Прод... Выливался по срезу версий с помощью ankyra escape... Выливаем в прод...ПО Кнопке.... Тесты автоматом ... Профит... Так мейнтейнилось порядка 23 модулей + 11 окружений... Полет 3 года отличный... Но мы не сразу к этому пришли. Если что это был продукт с инсталяцией on demand - соответственно продов и стейджей было по 4.... 3 дева(так исторически сложилось)... Основная разработка была в 1 деве... В 2х других девы и девопс творили что хотели... Как то так.. Вертелось все это в AWS
VT
😊у меня появились мысли про что можно было бы рассказать на митапе или конфе.
tf код все уже научились писать - а вот работь в команде, с бранчами и версионностью не все.
tf код все уже научились писать - а вот работь в команде, с бранчами и версионностью не все.
VT
Могу рассказать как работал у меня гитопс на предыдущей работе... Через мальтибранч плагин в дженкинсе отрабатывала хука... Деплоила модуль... Прогоняла тесты если ок.. Мерджилась и тегалась.. Далее вступал в бой ankyra escape... Это была матрица версий и депенденси тулза.. Там пинились версии...далее в jenkins обновлял версию на дев проекте с старой версией... И Прогоняла e2e... Если ок... Далее следующий дев... И так максимально до прода промоутилась 1 версия модуля... Прод... Выливался по срезу версий с помощью ankyra escape... Выливаем в прод...ПО Кнопке.... Тесты автоматом ... Профит... Так мейнтейнилось порядка 23 модулей + 11 окружений... Полет 3 года отличный... Но мы не сразу к этому пришли. Если что это был продукт с инсталяцией on demand - соответственно продов и стейджей было по 4.... 3 дева(так исторически сложилось)... Основная разработка была в 1 деве... В 2х других девы и девопс творили что хотели... Как то так.. Вертелось все это в AWS
Круто!
OK
😊у меня появились мысли про что можно было бы рассказать на митапе или конфе.
tf код все уже научились писать - а вот работь в команде, с бранчами и версионностью не все.
tf код все уже научились писать - а вот работь в команде, с бранчами и версионностью не все.
+
2020 January 16
SG
Это божественно!
Спасибо тебе добрый человек, и как вовремя, там как раз ответ на мой вопрос про tfvars и их динамическое изменение через вэбхуки...
Спасибо тебе добрый человек, и как вовремя, там как раз ответ на мой вопрос про tfvars и их динамическое изменение через вэбхуки...
OK
Одна конфигурация для разных env'ов
In particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams. In this case, the backend used for each deployment often belongs to that deployment, with different credentials and access controls. Named workspaces are not a suitable isolation mechanism for this scenario.
Instead, use one or more re-usable modules to represent the common elements, and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend. In that case, the root module of each configuration will consist only of a backend configuration and a small number of module blocks whose arguments describe any small differences between the deployments.
Where multiple configurations are representing distinct system components rather than multiple deployments, data can be passed from one component to another using paired resources types and data sources.
Instead, use one or more re-usable modules to represent the common elements, and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend. In that case, the root module of each configuration will consist only of a backend configuration and a small number of module blocks whose arguments describe any small differences between the deployments.
Where multiple configurations are representing distinct system components rather than multiple deployments, data can be passed from one component to another using paired resources types and data sources.
b
In particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams. In this case, the backend used for each deployment often belongs to that deployment, with different credentials and access controls. Named workspaces are not a suitable isolation mechanism for this scenario.
Instead, use one or more re-usable modules to represent the common elements, and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend. In that case, the root module of each configuration will consist only of a backend configuration and a small number of module blocks whose arguments describe any small differences between the deployments.
Where multiple configurations are representing distinct system components rather than multiple deployments, data can be passed from one component to another using paired resources types and data sources.
Instead, use one or more re-usable modules to represent the common elements, and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend. In that case, the root module of each configuration will consist only of a backend configuration and a small number of module blocks whose arguments describe any small differences between the deployments.
Where multiple configurations are representing distinct system components rather than multiple deployments, data can be passed from one component to another using paired resources types and data sources.
а можно источник?
OK
Сори за портянку ну по моему видению ситуации с пониманием как и для чего нужны workspaces - желательно читать чтобы понять когда надо юзать workspaces, а когда нужно сплитить окружения по отдельным гит репам (для начала)
OK
а можно источник?
Легко
b
спасибо
OK
Вот отсюда можно начинать.
OK
When to use Multiple Workspaces
A
Xin chao
KO
Привет. У меня следующая задача: развернуть 10 машин на амазоне, установить на них кассандру, на 1 машине запустить нагрузочный тест, снять метрики, всё свернутЬ, убить машины, отчёт выгрузить.
KO
Это как-то делается на терраформе или лучше взять ансибл?