Давайте поговорим о некоторых лучших практиках, которым следует следовать при использовании Terraform.
Terraform — это очень популярный инструмент IaC с открытым исходным кодом (инфраструктура как код), позволяющий определять и предоставлять полную инфраструктуру.
Хотя Terraform был запущен в 2014 году, распространение этого инструмента выросло во всем мире. Все больше и больше разработчиков изучают Terraform для развертывания инфраструктуры в своей организации.
Если вы начали использовать Terraform, вам необходимо принять лучшие практики для лучшего обеспечения производственной инфраструктуры.
Если вы новичок, прочтите статью о Terraform для начинающих.
Структурирование
Когда вы работаете над крупным проектом производственной инфраструктуры с использованием Terraform, вы должны следовать правильной структуре каталогов, чтобы избежать сложностей, которые могут возникнуть в проекте. Было бы лучше, если бы у вас были отдельные каталоги для разных целей.
Например, если вы используете terraform в средах разработки, промежуточной и производственной средах, создайте отдельные каталоги для каждой из них.
geekflare@geekflare:~$tree terraform_project/ terraform_project/ ├── dev │ ├── main.tf │ ├── выходы.tf │ └── переменные.tf ├── модули │ ├── ec2 │ │ ├── ec2.tf │ │ └── main.tf │ └── vpc │ ├── main.tf │ └── vpc.tf ├── prod │ ├── main.tf │ ├── outputs.tf │ └ ──variable.tf └──stg ├──main.tf ├──outputs.tf └──variable.tf 6 каталогов, 13 файлов
Даже конфигурации терраформирования должны быть отдельными, поскольку со временем конфигурации растущей инфраструктуры станут сложными.
Например, вы можете написать все свои коды терраформирования (модули, ресурсы, переменные, выходные данные) внутри самого файла main.tf, но наличие отдельных кодов терраформирования для переменных и выходных данных делает его более читабельным и простым для понимания.
Соглашение об именовании
Соглашения об именах используются в Terraform, чтобы упростить понимание.
Например, предположим, что вы хотите создать три разных рабочих пространства для разных сред в проекте. Итак, вместо того, чтобы называть их env1, en2, env3, вам следует называть их dev , stage , prod . Из самого названия становится ясно, что для каждой среды существует три разных рабочих пространства.
Аналогичные соглашения также следует соблюдать для ресурсов, переменных, модулей и т. д. Имя ресурса в Terraform должно начинаться с имени поставщика, за которым следует подчеркивание и другие сведения.
Например, имя ресурса для создания объекта terraform для таблицы маршрутов в AWS будет aws_route_table.
Итак, если вы правильно будете следовать соглашениям об именах, вам будет легче понять даже сложные коды.
Настоятельно рекомендуется использовать доступные официальные модули Terraform. Нет необходимости изобретать уже существующий модуль. Это экономит много времени и боли. В реестре Terraform имеется множество доступных модулей. Внесите изменения в существующие модули по мере необходимости.
Кроме того, каждый модуль должен концентрироваться только на одном аспекте инфраструктуры, например на создании экземпляра AWS EC2, настройке базы данных MySQL и т. д.
Например, если вы хотите использовать AWS VPC в своем коде terraform, вы можете использовать – простой VPC.
модуль «vpc_example_simple-vpc» { source = «terraform-aws-modules/vpc/aws//examples/simple-vpc» version = «2.48.0» }
Последняя версия
Сообщество разработчиков Terraform очень активно, и выпуск новых функций происходит часто. Рекомендуется использовать последнюю версию Terraform, как и в случае выхода нового основного выпуска. Вы можете легко обновиться до последней версии.
Если вы пропустите несколько основных выпусков, обновление станет очень сложным.
Запустите команду terraform -v, чтобы проверить наличие нового обновления.
geekflare@geekflare:~$ terraform -v Terraform v0.11.14 Ваша версия Terraform устарела! Последняя версия — 0.12.0. Вы можете обновить, загрузив с www.terraform.io/downloads.html.
Резервное копирование состояния системы
Всегда делайте резервные копии файлов состояния Terraform.
Эти файлы отслеживают метаданные и ресурсы инфраструктуры. По умолчанию эти файлы, называемые terraform.tfstate, хранятся локально в каталоге рабочей области.
Без этих файлов Terraform не сможет выяснить, какие ресурсы развернуты в инфраструктуре. Поэтому важно иметь резервную копию файла состояния. По умолчанию будет создан файл с именем terraform.tfstate.backup для хранения резервной копии файла состояния.
geekflare@geekflare:~$tree terraform_demo/ terraform_demo/ ├── awsec2.tf ├── terraform.tfstate └── terraform.tfstate.backup 0 каталогов, 3 файла
Если вы хотите сохранить файл состояния резервной копии в другом месте, используйте флаг -backup в команде terraform и укажите путь к этому местоположению.
В большинстве случаев над проектом работают несколько разработчиков. Таким образом, чтобы предоставить им доступ к файлу состояния, его следует хранить в удаленном месте с использованием источника данных terraform_remote_state.
В следующем примере будет выполнено резервное копирование на S3.
data «terraform_remote_state» «vpc» { backend = «s3» config = { Bucket = “s3-terraform-bucket” key = “vpc/terraform.tfstate” регион = “us-east-1” } }
Заблокировать файл состояния
Может быть несколько сценариев, когда несколько разработчиков пытаются одновременно запустить конфигурацию terraform. Это может привести к повреждению файла состояния terraform или даже к потере данных. Механизм блокировки помогает предотвратить подобные сценарии. Он гарантирует, что одновременно только один человек управляет конфигурациями terraform и не возникает конфликтов.
Вот пример блокировки файла состояния, который находится в удаленном месте, с помощью DynamoDB.
ресурс «aws_dynamodb_table» «terraform_state_lock» { name = «terraform-locking» read_capacity = 3 write_capacity = 3 hash_key = атрибут «LockingID» { name = «LockingID» type = «S» } } terraform { backend «s3» { Bucket = « s3-terraform-bucket» key = «vpc/terraform.tfstate» Region = «us-east-2» dynamodb_table = «terraform-locking» } }
Когда несколько пользователей пытаются получить доступ к файлу состояния, имя базы данных DynamoDB и первичный ключ будут использоваться для блокировки состояния и поддержания согласованности.
Примечание. Не все серверные части поддерживают блокировку.
Использовать собственную переменную
Переменная self — это особый вид переменной, который используется, когда вы не знаете ее значение перед развертыванием инфраструктуры.
Допустим, вы хотите использовать IP-адрес экземпляра, который будет развернут только после команды terraform apply, поэтому вы не знаете IP-адрес, пока он не будет запущен и запущен.
В таких случаях вы используете переменные self, а синтаксис для их использования — self.ATTRIBUTE. Итак, в этом случае вы будете использовать self.ipv4_address в качестве переменной self, чтобы получить IP-адрес экземпляра. Эти переменные разрешены только в блоках подключения и обеспечения конфигурации terraform.
соединение {host = self.ipv4_address type = «ssh» user = var.users[2] Private_key = file(var.private_key_path) }
Минимизировать радиус взрыва
Радиус взрыва — это не что иное, как мера ущерба, который может произойти, если что-то пойдет не так, как планировалось.
Например, если вы развертываете в инфраструктуре некоторые конфигурации terraform и конфигурация применяется неправильно, каков будет размер ущерба инфраструктуре?
Поэтому, чтобы минимизировать радиус взрыва, всегда рекомендуется одновременно внедрять в инфраструктуру несколько конфигураций. Так что, если что-то пошло не так, ущерб инфраструктуре будет минимальным и его можно будет быстро исправить. Развертывание большого количества конфигураций одновременно очень рискованно.
Используйте var-файл
В terraform вы можете создать файл с расширением .tfvars и передать этот файл команде terraform apply, используя флаг -var-file. Это поможет вам передать те переменные, которые вы не хотите помещать в код конфигурации terraform.
Всегда рекомендуется передавать переменные для пароля, секретного ключа и т. д. локально через -var-file, а не сохранять их внутри конфигураций terraform или в удаленной системе контроля версий.
Например, если вы хотите запустить экземпляр ec2 с помощью terraform, вы можете передать ключ доступа и секретный ключ, используя -var-file
Создайте файл terraform.tfvars и поместите ключи в этот файл.
geekflare@geekflare:~$ gedit terraform.tfvars access_key = «AKIATYWSDFYU5DUDJI5F» secret_key = «W9VCCs6I838NdRQQsAeclkejYSJA4YtaZ+2TtG2H»
Теперь используйте этот файл var в команде terraform.
geekflare@geekflare:~$ terraform apply -var-file=/home/geekflare/terraform.tfvars
Пользователь Докер
При запуске задания сборки конвейера CI/CD предлагается использовать контейнеры Docker. Terraform предоставляет официальные контейнеры Docker, которые можно использовать. Если вы меняете сервер CI/CD, вы можете легко передать инфраструктуру внутри контейнера.
Перед развертыванием инфраструктуры в производственной среде вы также можете протестировать инфраструктуру в докер-контейнерах, которые очень легко развернуть. Объединив Terraform и Docker, вы получаете портативную, многократно используемую и повторяемую инфраструктуру.
Заключение
Я надеюсь, что эти лучшие практики помогут вам написать лучшие конфигурации Terraform. Продолжайте и начните внедрять их в свои проекты терраформирования для достижения лучших результатов.