HashiCorp добавил вкусняшек к своему бесплатному хранилищу стейтов TF: теперь появилась интеграция с VCS, удаленный запуск plan/apply и приватный registry для модулей. Но размер команды для free tier ограничили до 5 человек :(
http://amp.gs/NqcD

чето если честно сыкотно HashiCorp в свою инфраструктуру при apply пускать, даже если credentials там все зашифрованы, их все равно рано или поздно расшифровывать надо перед тем как к API prodiver'а стучаться, а соответсвенно если их заломают, то могут оттуда дохрена до чего дотянуться

Согласен, я вижу юзкейс только для тестов, на тестовом аккаунте с жёсткими лимитами. Но зачем...
Им нужно не хранилище стейтов, а ux как у cloudcraft, чтобы стейты эти блоками рисовать. Terraform designer.

Но я думаю они его уже пишут.

но.. гитхаб же используют? чем хашикорпы хуже

Ну, в принципе - аргумент :)
Только в стейте айди реальных серверов, ip, тэги - слишком жирный вектор атаки.
Впрочем, код в приватных репозиториях тоже может содержать некий сенситив, для разворачивания вектора со стороны приложения.

Как минимум всякие облачные CI могут содержать вектор атаки, если добраться до кода.
Минус хашикорпа в том, что у них вроде никаких секьюрити сертов и гарантий для показа клиенту.
А так то и собственная система может быть уязвима. И уж тем более локальный apply.

я бы предпочел использовать github с pre-commit hook от https://github.com/awslabs/git-secrets
и хранить там там только исходники
а CI/CD делать все таки самостоятельно

CI/CD как SaaS это только для opensource частей проектов

Друзья, подскажите как правильно диски в aws_instance настраивать.

   ebs_block_device {
        device_name           = "disk1"
        iops                  = 1000
        volume_size           = 48
        volume_type           = "io1"

 
Если  snapshot_id   не указывать, то terraform его пересоздает каждый раз.
А если через root_device создавать, то тип диска он использует st2, вместо io1

   ebs_block_device {
        device_name           = "disk1"
        iops                  = 1000
        volume_size           = 48
        volume_type           = "io1"

ignore_changes = "ebs_block_device" , не?

так тоже можно, но тогда размер диска и iops не изменить

народ, проясните, пожалуйста, поведение terrafrom
есть такой вот ресурс:
resource "aws_route53_record" "r53_domains_dev" {
 zone_id = var.hosted_zone_io
#  count   = length(var.domains_dev)
 for_each = toset(var.domains_dev)
#  name    = element(var.domains_dev, count.index)
 name    = each.value
 type    = "A"

 alias {
    name    = var.elb
    zone_id = var.shared_zone
    evaluate_target_health = false
 }
}
как видно, ранее было реализовано через count, но почитав статью на медиуме, понял что если удалить где-то посредине элемент из списка, то происходит сдвиг и вследствии не получаем ожидаемый результат, рекомендуется мол делать подобные вещи с for_each
но проблема в том, что он мне предлагает теперь удалить все домены, которые были добавлены ранее через count и потом опять их добавить... почему так? я что-то упускаю или это так и должно быть при переходе с count на for_each?

Да, он изменяет стейт так

аааа, кажись понял
походу это так и должно быть, но разово при переходе с count на for_each
так как сейчас при plan он выводит все элементы из списка и пересоздает каждый отдельно как сущность независимую(

да, уже осознал, грустно(
в таких случаях даунтаймы простительны вообще?

просто вот если такая ситуация случается со временем, писал раньше, а тут бац постиг дзен и захотел улучшить

Простительность даунтайма зависит от того, что ты делаешь хД в целом, домены рекреетятся быстро, и со старой на новую запись поправится без проблем.
Но если очень хочется - можно по идее руками стейт подвигать

капец, а такое вообще легально? стейт ручками трогать?

Ну в смысле есть команды для мувов. Но можно и ручками.

import чтоль?