WebSocket за Application Load Balancer в Yandex Cloud

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

Код примера

И так код сервера на TypeScript с использованием Socket.io. На голых веб-сокетах мне лень писать.

Базовый пример я расширил эндпоинтом, который пригодится нам для проверки живости приложения нашим балансером.

Еще одно дополнение — это отправка сообщения с hostname контейнера, чтобы запустив код клиента в несколько потоков, вы могли убедиться, что соединения обрабатываются разными серверами.

Код клиента я тоже постарался оставить минималистичным и лишь постарался добавить джиттер к отправке ping, чтобы они не слали все разом и было чуть поинтереснее.

Дальше в репозитории вы сможете в корне найти docker-compose.yml, который вам пригодится для локального запуска и отладки примера, если вы захотите с ним поиграть и внести какие-то изменения.

Создание инфраструктуры

Можно было бы наделать много красивых скриншотов, но они бы устарели, когда UI перерисуют. Со скринов не удобно копировать инфу, сложно понять, что важно, а где остались дефолтные значения. Поэтому я решил не заморачиваться этим, а сразу написать пример Terraform рецепта для развертывания. Ссылка на код будет ниже, а пока по шагам разберем как и зачем мы создаем ресурсы.

Сеть

Балансировать трафик мы будем сразу на 3 зоны присутствия. Поэтому подготовим сеть и по подсети в каждой AZ.

resource "yandex_vpc_network" "ws" {
  name = "ws"
}


resource "yandex_vpc_subnet" "ws-subnet-a" {
  name           = "ws-subnet-a"
  zone           = "ru-central1-a"
  network_id     = yandex_vpc_network.ws.id
  v4_cidr_blocks = ["10.240.1.0/24"]
}

resource "yandex_vpc_subnet" "ws-subnet-b" {
  name           = "ws-subnet-b"
  zone           = "ru-central1-b"
  network_id     = yandex_vpc_network.ws.id
  v4_cidr_blocks = ["10.240.2.0/24"]
}

resource "yandex_vpc_subnet" "ws-subnet-c" {
  name           = "ws-subnet-c"
  zone           = "ru-central1-c"
  network_id     = yandex_vpc_network.ws.id
  v4_cidr_blocks = ["10.240.3.0/24"]
}

Сервисный аккаунт

Этот аккаунт понадобится нам, для того чтобы передать его в Instance group, а она при помощи него могла управлять пересозданием VM.

resource "yandex_iam_service_account" "ig_sa" {
  name        = "ig-sa"
  description = "service account to manage ig"
}


resource "yandex_resourcemanager_folder_iam_binding" "sabind" {
  folder_id = "${var.folder_id}"

  role = "editor"

  members = [
    "serviceAccount:${yandex_iam_service_account.ig_sa.id}",
  ]
}

Instance group

Зачем? Ну теоретически, можно создать все виртуальные машины. Но тогда нам бы пришлось отдельно создавать ресурс целевой группы, руками наполнять его. А так потом было бы сложнее обновлять эти машины, так как пришлось бы делать это на каждой по очереди.

Перед заданием IG определим два источника данных: образ Container Optimized Image из Маркетплейса и шаблон конфига cloud init’а.

data "yandex_compute_image" "container-optimized-image" {
  family    = "container-optimized-image"
  folder_id = "standard-images"
}

data "template_file" "cloud_init" {
  template = "${file("cloud-init.tpl.yaml")}"
  vars     = {
    ssh_key = "${file(var.public_key_path)}"
  }
}

В instance group’е много параметров, значения которых можно посмотреть в документации, я же хотел обратить внимание на следующие:

resource "yandex_compute_instance_group" "ws-ig" {
  name               = "ig-ws"
  service_account_id = yandex_iam_service_account.ig_sa.id

  instance_template {
    boot_disk {
      mode = "READ_WRITE"
      initialize_params {
        image_id = data.yandex_compute_image.container-optimized-image.id
        ...
      }
    }
    network_interface {
      subnet_ids = [
        yandex_vpc_subnet.ws-subnet-a.id,
        yandex_vpc_subnet.ws-subnet-b.id,
        yandex_vpc_subnet.ws-subnet-c.id,
      ]
      
    }

    metadata = {
      docker-compose     = file("docker-compose.yaml")
      user-data          = "${data.template_file.cloud_init.rendered}"
      serial-port-enable = 1
    }
  }

  ...

  allocation_policy {
    zones = ["ru-central1-a", "ru-central1-b", "ru-central1-c"]
  }

  application_load_balancer {
    target_group_name = "ws-tg"
  }
}

И так по порядку:
— передаем service account, о котором я писал выше;
—указываем, что будем использовать подсети во всех AZ;
— передаем содержимое файла docker-compose.yaml в ключ метаданных ВМ. Агент стоящий на машинах сможет его вычитать и на основе все описанные в файле контейнеры. В ключ user-data передается отрендеренный шаблон для cloud init, куда подставляется публичный ключ, чтобы у вас была возможность зайти на созданные ВМ.
— отдельно указываем, что IG должна разворачивать инстансы во всех трех доступных AZ.
— ну и последннее, но очень важное в нашем примере, указать, что IG должна автоматически все создаваемые инстансы добавить в целевую группу L7-балансировщика.

Application Load Balancer

Теперь можем перейти к ресурсам непосредственно относящимся к ALB. И начнем с описания группы бэкендов.

resource "yandex_alb_backend_group" "ws-backend-group" {
  name = "ws-backend-group"

  http_backend {
    name             = "ws-http-backend"
    weight           = 1
    port             = 8080
    target_group_ids = [yandex_compute_instance_group.ws-ig.application_load_balancer.0.target_group_id]
    load_balancing_config {
      panic_threshold = 50
    }
    healthcheck {
      timeout  = "1s"
      interval = "1s"
      healthcheck_port = 8080
      http_healthcheck {
        path = "/"
      }
    }
  }
}

Как вы могли заметить мы указываем id целевой группы, которую нам автоматически предсоздала IG.

Также обратите внимание на настройки проверки живости наших машин за балансером. Тут мы указываем порт и путь эндпоинта, которы доопределяли в коде сервера специально для этих целей.

Еще я думал, что для нормального балансирования веб-сокетов необходимо настроить режим балансировки в значение Maglev hashing, так как только он по идее обеспечивает консистентное детерминированное распределение запросов по бэкендам, но оказалось что, для session affinity не надо ничего настраивать: WebSocket после апгрейда забирает себе соединение (или h2 стрим) и общение идёт с бекендом выбранным с самого начала.

Теперь надо описать роутер.

resource "yandex_alb_http_router" "ws-router" {
  name   = "ws-http-router"
}

И виртуальные хосты входящие в него.

resource "yandex_alb_virtual_host" "ws-virtual-host" {
  name           = "ws-virtual-host"
  http_router_id = yandex_alb_http_router.ws-router.id
  route {
    name = "socketio"
    http_route {
      http_route_action {
        backend_group_id = yandex_alb_backend_group.ws-backend-group.id
        timeout          = "3s"
        upgrade_types    = ["websocket"]
      }
    }
  }
}

Как видно они ссылаются и на роутер, и на группы бэкендов. В хостах как раз и описываются все правила роутинга. Но так как у нас довольно простой пример, все что мы укажем тут — возможность апгрейда соединения до websocket.

Вот почти и всё. Нам осталось только создать сам балансер, передав в него параметры зон развертывания, роутера и порта на котором слушать трафик, чтобы передавать в этот роутер.

resource "yandex_alb_load_balancer" "ws-balancer" {
  name = "ws-alb"

  network_id = yandex_vpc_network.ws.id

  allocation_policy {
    location {
      zone_id   = "ru-central1-a"
      subnet_id = yandex_vpc_subnet.ws-subnet-a.id
    }
    location {
      zone_id   = "ru-central1-b"
      subnet_id = yandex_vpc_subnet.ws-subnet-b.id
    }
    location {
      zone_id   = "ru-central1-c"
      subnet_id = yandex_vpc_subnet.ws-subnet-c.id
    }
  }

  listener {
    name = "socket-io"
    endpoint {
      address {
        external_ipv4_address {
        }
      }
      ports = [8080]
    }
    http {
      handler {
        http_router_id = yandex_alb_http_router.ws-router.id
      }
    }
  }
}

Готово. Теперь можно выполнить команду terraform apply и подождать пока все ресурсы создадутся. Это может занять минуть 5–10.

Полный код примера на GitHub.