Comments 14
Уже не первый раз, когда я слышу от людей, юзающих TF, что 90% проходит в лёт, а оставшиеся (обязательные) 10% — кровь и смертный бой с TF'ом.
Преимущество терраформа перед ансиблом, шефом и тп для инфраструктуры — состояние, что позволяет управлять полным жизненным циклом обьекта, а не только созданием.
В моём случае другой подход: управляем тем, что записано в конфиге.
- Репа есть в конфиге? Она управляется.
- Нет в конфиге? С репой гарантированно ничего не случится.
Некоторые операции у меня не реализованы. Например, удалить репу невозможно. Но это никогда не требовалось. И так даже лучше, не получится случайно отстрелить себе ногу.
А если сархивировать репу, то её и Terraform не сможет разархивировать обратно.
Сам пришел некогда в организацию подобного размера, с 300+ репами. Тоже было организовано с помощью Terraform в одной папке и с одним гигантским стейтом, terraform plan занимал пол часа плюс иногда обрывался из-за лимитов GitHub API. Также при добавлении/удалении юзера из команды(github_team_membership) из-за используемого count сначала все члены команды удалялись, потом добавлялись, что очень раздражало.
Решилось путем разделения Terraform кода в кучу подпапок — по командам с разными state.
CI детектит в каких папках произошли изменения, и там запускает terraform plan.
Если есть перекрестные связи между командами — решается с помощью чтения внешнего data.terraform_remote_state.
Проблему с github_team_membership + count помог решить terraform 0.12 for_each, теперь при добавления юзера в команду terraform делает атомарное изменение и не нужно всю команду каждый раз передобавлять.
Теперь изменения в даже в самой большой команде занимают не больше 1 минуты.
Удаление/добавление репосов и юзеров у нас запрещено на уровне GitHub организации и старые репосы Terraform просто архивирует.
Вполне рабочая схема.
Что хотелось бы сказать:
При том, что такие вещи обычно копипастят, после чего что-то меняют, можно запросто это что-то недоменять или убрать лишнее.
Модули и Terragrunt спасает от копипасты чуть менее, чем полностью.
Поставили минус вместо подчерка — и никто не заметит. Цена ошибки — минуты ожидания.
pre-commit-terraform спасает от большинства неприятностей, связанных с ошибками в синтаксисе и от некоторых ошибок при работе с провайдерами. Человеческие ошибки (_ вместо -) могут быть совершены при работе с любым инструментом.
Представьте себе дебаг с минутами между итерациями...
Здесь может помочь опция -target, довольно удобная при ручном дебаге, но категорически вредная при запуске в CI.
У меня была проблема HTTP 429 при работе с DigitalOcean — 300+ дроплетов и лимит на 2000 обращений к API в час. Решилась общением с саппортом и повышением до 10к + отдельный аккаунт для Terraform. Посему, могу понять Вашу боль.
Тем не менее, я считаю, что Вы недостаточно разобрались в нюансах использования Terraform и в том, как эти нюансы решаются.
На тему rate limits: внутри AWS провайдера, как мне кажется, видел что-то похожее на встроенный exponential backoff, то есть даже если вдруг рейт лимит выстрелит, инструмент попытается восстановиться. Видимо другие провайдеры могут быть не настолько стабильны.
При наших размерах на это уходило около 20 минут, а до следующего изменения нужно было выждать час — мы упирались в лимиты Github-а на количество обращений к API.
Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться со стейтом? Что это такое, как его разделить, например.
Да и синтаксис не зашел. Описание чего угодно довольно многословное.
Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться с модулями? Как их писать и сделать из них нужный формат ресурсов, например.
И когда теперь понадобилось кому-то дать права, мы не можем это сделать. Ведь Terraform про него ничего не знает!
Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться с импортом ресурсов. Как добавить созданный руками ресурс в терраформ 1 командой, например.
- Когда ты нанимаешь людей новых людей, они уже скорее всего знают терраформ. Твой велосипед они не знают. А следовательно быстрее станут приносить пользу.
- На своем велосипеде ты собираешь все грабли, которые в стандартном инструменте уже собраны и обработаны.
- В случае изменения АПИ, добавления новых ресурсов и т.д. тебе не нужно ничего допиливать, т.к. огромное комьнити (в т.ч. сам амазон) делают стандартный инструмент.
- Если для вас превознемогать это прочесть документацию к стандартному инструменту это превознеможение, то вы никчемный инженер.
@igmp Спасибо за пост. Вижу что репозиторий gitwand заархивирован. Ушли с gitwand? На что перешли?
Ушли с Github-а на self-hosted Gitlab.
Управляя Github-ом: через Terraform к самописному решению на Ansible