Terraform: инфраструктура на уровне кода | страница 95

Управление версиями

Если ваши тестовая и промышленная среды ссылаются на папку с одним и тем же модулем, любое изменение в этой папке коснется и той и другой при следующем же развертывании. Такого рода связывание усложняет тестирование изменений в изоляции от промышленного окружения. Вместо этого лучше использовать разные версии модулей: например, v0.0.2 для тестовой среды и v0.0.1 для промышленной, как показано на рис. 4.5.

Рис. 4.5. Применение разных версий модуля в разных окружениях

Во всех примерах с модулями, которые вы видели до сих пор, параметр source содержал локальный файловый путь. Но, помимо файловых путей, модули Terraform поддерживают и другие виды источников, такие как URL-адреса Git/Mercurial и произвольные URL44. Самый простой способ управления версиями модуля — размещение его кода в отдельном Git-репозитории, URL-адрес которого затем прописывается в параметре source. Это означает, что код Terraform будет распределен (как минимум) по двум репозиториям.

•modules — в этом репозитории находятся универсальные модули. Каждый модуль — своего рода «чертеж», который описывает определенную часть вашей инфраструктуры.

•live — репозиторий, который содержит текущую инфраструктуру, развернутую в каждом окружении (stage, prod, mgmt и т. д.). Это такие «здания», которые вы строите по «чертежам», взятым из репозитория modules.

Обновленная структура папок для вашего кода Terraform будет выглядеть примерно так, как на рис. 4.6.

Рис. 4.6. Структура файлов и каталогов с несколькими репозиториями

Чтобы организовать код таким образом, сначала нужно переместить папки stage, prod и global в папку под названием live. Затем вы должны разнести папки live и modules по отдельным Git-репозиториям. Вот пример того, как это делается с папкой modules:

$ cd modules

$ git init

$ git add .

$ git commit -m "Initial commit of modules repo"

$ git remote add origin "(URL OF REMOTE GIT REPOSITORY)"

$ git push origin master

Репозиторию modules можно также назначить тег, который будет использоваться в качестве номера версии. Если вы работаете с сервисом GitHub, это можно сделать в его пользовательском интерфейсе: создайте выпуск (bit.ly/2Yv8kPg), который автоматически создаст тег. Если вы не используете GitHub, можете применить утилиту командной строки Git:

$ git tag -a "v0.0.1" -m "First release of webserver-cluster module"

$ git push --follow-tags

Теперь вы можете работать с разными версиями модуля в тестовой и промышленной средах, указав URL-адрес Git в параметре source. Вот как это будет выглядеть в файле live/stage/services/webserver-cluster/main.tf, если ваш репозиторий modules находится в GitHub по адресу github.com/foo/modules (имейте в виду, что двойная косая черта в URL-адресе Git является обязательной):