Comments 5
Создаем «серверы-фениксы» вместо «серверов-снежинок»: если что-то пойдет
не так, можно все задестроить, а потом задеплоить заново. Это будет
наиболее продуктивный и наименее затратный подход при инициализации
инфраструктуры.
В миру такой подход называется cattle not pets
возьмете в команду?)
Добрый день!
Список актуальных вакансий есть здесь.
И всё же зачем GL Envs вместо Terragrunt? По его появлению в статье понял что вы с второго перешли на первый? Не сказал бы что он сложнее, разве что нужно за пару "кликопсов" законфигурировать)
Мы Terragrunt использовали для деплоя файлового хранилища, там как раз удобно было генерировать ресурсы исходя из конфигурации клиентов
В ML платформе выбрали связку terraform+Gitlab, так как это оказалось удобно с точки зрения разработки. Инженеру нужно добавить новую фичу - он просто создает новую ветку, так как используется Gitlab env то название ветки прокидывается и в название проекта в облаке, и в остальные ресурсы (удобный динамический нейминг). Плюс мы стараемся ветки называть по номеру таски в Jira, всегда можно отследить по названию ресурсов к какой задаче он принадлежит.
Плюс удобно передаются переменные CI/CD в различные environments. Код один, меняем только их.
Как мы ускорили деплой облачной платформы в 20 раз и избавились от панических атак