April 2023 – vMind.ru

Варим без Вари. Серверная виртуализация на базе платформы VMmanager

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 оставить в корневом файле.

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

provider "aws" {
  region = "us-east-1"
}

locals {
  list1 = {
    lambda1 = {
      name = "lambda1"
      path = "../lambda1"
    }
    lambda2 = {
      name = "lambda1"
      path = "../lambda1" 
    } 
  }
  list2 = {
    lambda1 = aws_apigatewayv2_api.example_api.execution_arn
    lambda2 = aws_apigatewayv2_api.example_api.execution_arn
  }
}
module "lambda" {
  source   = "../lambda"
  for_each = local.list1
  name     = each.value.name
  ...
}

data "template_file" "example_api" {
  template = "${file("example_api.tpl")}"

  vars = {
    lambda_invocation_url = module.lambda.lambda_function_invoke_url
  }
}

resource "aws_apigatewayv2_api" "example_api" {
  name          = "example_api"
  protocol_type = "HTTP"
  body          = data.template_file.example_api.rendered
}

resource "aws_lambda_permission" "example_permission" {
  for_each      = local.list2
  statement_id  = "AllowAPIGatewayInvoke"
  action        = "lambda:InvokeFunction"
  function_name = module.lambda.lambda_function_arn
  principal     = "apigateway.amazonaws.com"
  source_arn    = each.value
}

provider "aws" {

region = "us-east-1"

}

locals {

list1 = {

lambda1 = {

name = "lambda1"

path = "../lambda1"

}

lambda2 = {

name = "lambda1"

path = "../lambda1"

}

list2 = {

lambda1 = aws_apigatewayv2_api.example_api.execution_arn

lambda2 = aws_apigatewayv2_api.example_api.execution_arn

}

module "lambda" {

source = "../lambda"

for_each = local.list1

name = each.value.name

...

}

data "template_file" "example_api" {

template = "${file("example_api.tpl")}"

vars = {

lambda_invocation_url = module.lambda.lambda_function_invoke_url

}

resource "aws_apigatewayv2_api" "example_api" {

name = "example_api"

protocol_type = "HTTP"

body = data.template_file.example_api.rendered

}

resource "aws_lambda_permission" "example_permission" {

for_each = local.list2

statement_id = "AllowAPIGatewayInvoke"

action = "lambda:InvokeFunction"

function_name = module.lambda.lambda_function_arn

principal = "apigateway.amazonaws.com"

source_arn = each.value

}

provider "aws" {
  region = "us-east-1"
}

resource "aws_lambda_function" "example_lambda" {
  filename         = "lambda_function.zip"
  function_name    = "example_lambda"
  role             = aws_iam_role.lambda_exec.arn
  handler          = "lambda_function.handler"
  runtime          = "nodejs14.x"
  source_code_hash = filebase64sha256("lambda_function.zip")
  
  environment {
    variables = {
      EXAMPLE_VAR = "example_value"
    }
  }
}

resource "aws_iam_role" "lambda_exec" {
  name = "lambda_exec_role"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_exec_policy" {
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
  role       = aws_iam_role.lambda_exec.name
}

output "lambda_function_arn" {
  value = aws_lambda_function.example_lambda.invoke_arn
}

provider "aws" {

region = "us-east-1"

}

resource "aws_lambda_function" "example_lambda" {

filename = "lambda_function.zip"

function_name = "example_lambda"

role = aws_iam_role.lambda_exec.arn

handler = "lambda_function.handler"

runtime = "nodejs14.x"

source_code_hash = filebase64sha256("lambda_function.zip")

environment {

variables = {

EXAMPLE_VAR = "example_value"

}

resource "aws_iam_role" "lambda_exec" {

name = "lambda_exec_role"

assume_role_policy = jsonencode({

Version = "2012-10-17"

Statement = [

{

Action = "sts:AssumeRole"

Effect = "Allow"

Principal = {

Service = "lambda.amazonaws.com"

}

]

})

}

resource "aws_iam_role_policy_attachment" "lambda_exec_policy" {

policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"

role = aws_iam_role.lambda_exec.name

}

output "lambda_function_arn" {

value = aws_lambda_function.example_lambda.invoke_arn

}

Так как функций было несколько, то их входные значения для модуля (имя, путь и т.д.) генерировались в разделе 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.

Полный список нового функционала:

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

Подробная документация:

Release Notes. Описание основных особенностей и ограничений, которые необходимо учитывать при эксплуатации vGate 4.7 на базе VMware vSphere.
Troubleshooting. Решение типовых проблем.
Руководство администратора. Принципы функционирования. Сведения о назначении и функциональных возможностях vGate R2.
Руководство администратора. Установка, настройка и эксплуатация. Сведения для установки, обновления и удаления vGate R2.
Руководство пользователя. Работа в защищенной среде. Сведения для работы в защищенной среде.
Руководство администратора. Быстрый старт. Сведения для первоначальной настройки и эксплуатации vGate R2.

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

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

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

Самые простой вариант – встроенное в менеджер виртуализации средство. Для продуктов на базе 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 Дискуссия “Импортозамещение от базовой виртуализации до инфраструктуры удаленных рабочих мест”

Month: April 2023