Стенды разработки без очередей и простоев

[allexx]

Первую из ваших проблем может решить terragrunt.

И позволю «докопаться» до вашего tf «кода»:
1. Зачем делать "${var.env_name}", когда ниже вы уже умеете = var.subnet_address?
2. Никогда не понимал почему в имени ресурса добавляют его тип? Например resource «azurerm_virtual_network» «vnet», обращение к ресурсам всегда через {type}.{name} везде, выглядит избыточно azurerm_virtual_network.vnet, а смысловая часть имени отсутсвует.

[ksastan]

1. Предположу, что имеется в виду var.subnet_address и var.vnet_address содержащие одинаковое значение.
   В моём случае модуль Terraform используется и для других стендов, в которых один VNET может содержать несколько подсетей и, в этом случае, значения var.vnet_address и var.subnet_address будут отличаться.
2. Полностью согласен. Это следствие замены реальных имён на что-то более общее.

[allexx]

p1. Вероятно в результате урощения примера, "${var.env_name}" содержал что-то, что требовало интерполяцию, в демо примере же она похоже избыточна.

[ksastan]

Вы правы, в данном случае правильнее будет заменить ${var.env_name} на var.env_name

[Gutt]

Насколько я понимаю, subnets.txt существует только в этом проекте, поэтому никогда два параллельных пайплайна не вызовут env.sh одновременно? Просто первая мысль при записи в текстовый файл в скрипте, который потенциально может быть вызван несколькими пользователями одновременно, — о race condition с последующим повреждением содержимого…

[ksastan]

В точку. При увеличении количества деплоев будет расти вероятность возникновения race condition's. Сейчас нужно дожидаться завершения предыдущих пайплайнов.

Я вижу несколько вариантов решения данной проблемы:

1. Если наши деплои будут выполняться на единственном gitlab runner мы можем использовать flock
2. Если раннеров больше одного, переносим scripts/subnets.txt в БД и реализуем механизм выставления локов в этой же БД. Добавляем возможность проверки и ожидания снятия лока в сценарий env.sh