• Из двух предыдущих пунктов вытекает тот факт, что рабочие области могут быть довольно сильно предрасположены к ошибкам. Из-за нехватки прозрачности можно легко забыть, в какой рабочей области вы находитесь, и внести изменения не в том месте (например, случайно выполнить команду terraformdestroy в рабочей области production вместо staging). Поскольку вам приходится использовать один и тот же механизм аутентификации для всех рабочих областей, у вас нет другого уровня защиты от подобных ошибок.
Чтобы как следует изолировать разные окружения, вместо рабочих областей лучше использовать структуру файлов и каталогов, о которой пойдет речь в следующем подразделе. Но прежде, чем двигаться дальше, не забудьте удалить три сервера EC2, которые вы только что развернули. Для этого выполните terraformworkspaceselect<имя> и terraformdestroy в каждой из трех рабочих областей.
Изоляция с помощью описания структуры файлов
Чтобы достичь полной изоляции между окружениями, нужно сделать следующее.
• Поместить конфигурационные файлы Terraform для каждой среды в отдельную папку. Например, вся конфигурация для среды финального тестирования может находиться в папке stage, а в папке prod может храниться конфигурация промышленной среды.
• Предусмотреть для каждой среды разные хранилища с разными механизмами аутентификации и управления доступом (предположим, у каждого окружения может быть отдельная учетная запись AWS со своим бакетом S3 в качестве хранилища).
Благодаря применению отдельных папок вам будет намного легче понять, в какой среде происходит развертывание, а использование отдельных файлов состояния с отдельными механизмами аутентификации значительно уменьшает вероятность того, что случайная оплошность в одной среде будет иметь какое-либо влияние на другие.
Концепцию изоляции лучше опустить на уровень ниже, вплоть до компонентов — наборов связанных между собой ресурсов, которые обычно развертываются совместно. Например, после настройки базовой сетевой топологии для своей инфраструктуры (в терминологии AWS это виртуальное частное облако (VPC) и все связанные с ним подсети, правила маршрутизации, VPN и сетевые списки доступа) вы будете менять ее не чаще раза в месяц. Но новые версии серверов могут развертываться по нескольку раз в день. Управляя инфраструктурой VPC и веб-сервера в одной и той же конфигурации Terraform, вы постоянно рискуете нарушить работу всей своей сетевой топологии (скажем, из-за простой опечатки в коде или случайного выполнения не той команды) без причины.
