Terraform cycles

Решил я заняться развертыванием AWS Lambda Function и API Gateway через Terraform.

Вводные были следующие:

  • API Gateway создается на основе OpenAPI-шаблона, который вызывает Lambda Functions. Соответственно, в шаблоне должен быть указан Lambda invocation url (lambda типа как prerequisite);
  • Lambda Function должна запускаться только из API Gateway – для разрешения (permission) в качестве source_arn необходимо указать API Gateway execution arn (API gateway prerequisite).

Сначала я создавал lambda function с помощью штатных ресурсов AWS-provider: aws_lambda_function, aws_lambda_permission и archive_file. Проблем с закольцовкой не было: Terraform умело разруливал порядок создания ресурсов.

Но потом лямбда функций стало больше, и я решил использовать принцип DRY (don’t repeat yourself). В Terraform эту роль играют модули.

Я начал использовать публичный модуль для создания лямбд отсюда – и меня догнали Terraform Cycle Error на этапе terraform validate.

Отрицание

Не может такого быть, повторял я и варьировал различные варианты кода.

Неужели придется отказаться от модуля в случае создания таких функций???

Гнев

Пока я изучал модуль, обнаружил в нем входную переменную putin_khuylo, содержащую по умолчанию значение true.

Торг

Внимательное изучение выходных значений модуля подсказало наличие выходного значения function_arn_static, которые должны помочь избежать зацикливания.

НО НЕТ!

Депрессия

Был еще один вариант:

  • выполнить команду terraform -grath -show-cycles;
  • полученный текстовый вывод скормить graphviz либо graphviz онлайн.

Увы, установить утилиту я не мог, а онлайн-утилита вылетала по памяти.

В теории этот путь поможет в разрезании цикла, показав ресурсы, участвующие в цикле.

Принятие

С горя я решил задать вопрос ChatGPT: как избежать зацикливания в данном случае.

Внезапно, мэтр программирования IaC Terraform посоветовал ресурс aws_lambda_function создавать в модуле, а aws_lambda_permission оставить в корневом файле.

Да-да, это то самое чувство, когда соседский мальчик умнее тебя 🙁

Так как функций было несколько, то их входные значения для модуля (имя, путь и т.д.) генерировались в разделе locals. Для использования цикла for_each в ресурсе aws_lambda_permissions потребовалось хранить source_arn в отдельной локальной переменной. УРА, terraform validate пройден.

Правда, на этапе terraform plan выяснилось, что модуль требует для своей работы Python и иногда падает, если в runtime вашей функции указана странная версия Python’а, и в Runner для CI/CD что-то пошло не так 🙂

На этом я решил психануть закопать стюардессу написать свой модуль создания лямбда функции без Питона и Путина.

Релиз Код Безопасности vGate 4.7

Код безопасности выпустил свежую версию своего продукта для защиты виртуальных сред vGate 4.7.
Ключевое отличие обновленной версии продукта – возможность управления различными платформами виртуализации из одной консоли.  Реализована поддержка средств управления KVM-серверами на базе Proxmox и OpenNebula.

Полный список нового функционала:
  1. Реализована возможность использования vGate в неоднородных виртуальных инфраструктурах, где в качестве платформ виртуализации используются vSphere, KVM, Скала-Р, Proxmox и OpenNebula одновременно.
  2.  Реализована поддержка средств управления KVM-серверами на базе Proxmox и OpenNebula.
  3. Добавлены политики безопасности сервера авторизации vGate: “Блокирование параллельных сеансов АВИ”, “Соответствие требованиям сложности пароля”, “Тайм-аут сессии в веб-консоли”, “Архивация базы аудита”. Данные политики позволяют администратору информационной безопасности устанавливать настройки сервера авторизации vGate.
  4. Добавлена привилегия “Администратор сетей vGate”, которая может быть предоставлена администратору информационной безопасности. Привилегия дает возможность просмотра и редактирования параметров межсетевого экрана vGate.
  5. Реализована возможность защиты файла экспорта конфигурации паролем.
  6. Реализована поддержка персонального идентификатора JaСarta в веб-консоли.
  7. Выполнен перенос функций синхронизации настроек серверов авторизации vGate, экспорта и импорта конфигурации, настройки персонального идентификатора из консоли управления в вебконсоль.
Подробная документация:

Российские инструменты миграции между средами виртуализации и облаками

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

Для индивидуальной миграции есть простые варианты.

Самые простой вариант – встроенное в менеджер виртуализации средство. Для продуктов на базе OVirt оно представляет собой virt-v2v или virt-p2v.

Метод посложнее, но, на мой взгляд, более универсальный – использовать СРК и ВД для создания резервного копии из одной среды виртуализации и восстановления в другой. Из российских СРК и ВД самый рабочий вариант – КиберПротект КиберБэкап.

Но также на рынке представлены средства массовой миграции:

ХайСтекс Акура aka Hystax Acura. Позволяет выполняет переезд и в облака Yandex Cloud, SberCloud, VK Cloud, CROC Cloud, а также работать с локальной инфраструктурой на базе VMware и OpenStack.

Mind Migration. Позволяет менять среды виртуализации и облачные решения VMware -> Базис, Private -> Public, AWS -> Яндекс.Облако, VK Cloud -> Sbercloud. Поддерживает большой стек технологий виртуализации.

Виртуализация и импортозамещение: ИТ-решения для замещения иностранных вендоров

00:00 Приветствие. Андрей Мирошкин, компания “Гротек”

07:38 Частное облако Selectel на оборудовании клиента – альтернатива зарубежным облачным решениям. Александр Худяков, Selectel

40:30 Проблемные вопросы обеспечения информационной безопасности при использовании средств контейнеризации. Владимир Карантаев, Центр НТИ МЭИ

1:05:33 Перспективы развития рынка виртуализации в условиях импортозамещения. Олег Шальнов, АО “Концерн Росэнергоатом”

1:30:52 Виртуализация и импортозамещение сегодня. Александр Естафьев, Газпром нефть

1:51:48 Импортозамещение в сфере виртуальной инфраструктуры: мнение заказчика. Максим Бобылев, Hoff

2:20:50 Дискуссия “Импортозамещение от базовой виртуализации до инфраструктуры удаленных рабочих мест”