Использование Kubernetes для развертывания чат-шлюза (или когда технология работает так, как имеет)

1656651247 ispolzovanie kubernetes dlya razvertyvaniya chat shlyuza ili kogda tehnologiya rabotaet tak

Ричард Ли

1*ZsohwEQHHw_sh0KX37pdeg
Фотография Top Five Buzz Travel Magazine на Unsplash

TL; DR

Это история о том, что происходит, когда облачные технологии работают так, как они должны. В этом случае технологиями являются Docker и Kubernetes.

Введение

В Datawire мы используем Gitter, чтобы пользователи наших инструментов с открытым кодом могли общаться с нами (и друг с другом). Нам нравится Gitter, потому что присоединиться к нему мало, особенно если у вас есть аккаунт GitHub или Twitter. Однако мобильный клиент Gitter не является отличным, и уведомления в целом работают плохо.

Поскольку миграция сообщества пользователей – это достаточно сложная работа, я решил проверить, смогу ли я развернуть мост между Slack (то, что мы используем внутри) и нашим чатом Gitter. Немного гуглование привело меня к Matterbridge.

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

Докер отличный

Я хотел запустить Matterbridge локально для настройки конфигурации. Я придерживался общих инструкций по созданию аккаунтов для Slack и Gitter, а затем разместил необходимые маркеры аутентификации в matterbridge.toml файл.

Я был рад увидеть, как Matterbridge доступен как образ Docker, и я смог просто скопировать свой файл конфигурации в образ Docker, чтобы проверить конфигурацию. Все, что мне нужно было сделать, это указать мой конфигурационный файл при использовании docker run:

docker run -ti -v /tmp/matterbridge.toml:/matterbridge.toml 42wim/matterbridge

Мне пришлось совершить несколько оборотов, чтобы наладить свою конфигурацию, но это было быстро и легко. Образ Docker выполнил именно то, что должен делать: предоставил проверенную среду исполнения для Matterbridge, поэтому мне не пришлось отлаживать его на своем ноутбуке.

Бег в облаке

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

Для развертывания в Kubernetes я написал простой Dockerfile:

FROM 42wim/matterbridge:1.9.0ADD matterbridge.toml .CMD ["/bin/matterbridge"]

Тогда мне нужен был только манифест Kubernetes.

Kubernetes

В своем манифесте Kubernetes я могу указать ряд ключевых сведений о службе:

  • Моя стратегия обновления, RollingUpdate
  • Минимальный и максимальный объем ЦБ и памяти для выделения
  • Количество реплик сервиса

Вот мой основной манифест:

---apiVersion: apps/v1beta1kind: Deploymentmetadata:  name: {{build.name}}  namespace: {{service.namespace}}spec:  replicas: 1  strategy:    type: RollingUpdate  template:    metadata:      labels:        app: {{build.name}}    spec:      containers:      - name: {{build.name}}        image: {{build.images["Dockerfile"]}}        imagePullPolicy: IfNotPresent        resources:          requests:            memory: 0.1G            cpu: 0.1          limits:            memory: {{service.max_memory}}            cpu: {{service.max_cpu}}    

(Обратите внимание, что я использую Forge для создания шаблонов и управления службой, поэтому это шаблонный манифест Kubernetes).

Благодаря этому манифесту я смог запустить свой сервис в Kubernetes.

Мой сервис Matterbridge в Git

Подытоживая, моя услуга состоит из:

  • Файл Docker
  • Манифест (по шаблону) Kubernetes
  • А matterbridge.toml файл конфигурации

все это я смог проверить в репозитории Git.

Мир к Kubernetes

Легкость, с которой я смог надежно получить услугу, заставила меня задуматься о том, как бы я сделал это за дни виртуальной машины. Мне пришлось бы:

  • Предоставление виртуальной машины (и/или создание группы автоматического масштабирования)
  • Установите необходимые зависимости среды выполнения на виртуальную машину с помощью взлома сценария bash (или воспользуйтесь Ansible или создайте специальный AMI)
  • Скопируйте мою конфигурацию на виртуальную машину

Кроме того, если бы я хотел сделать вышеупомянутое воспроизводимое, мне пришлось бы использовать Terraform, Ansible, CloudFormation или один из этих типов инструментов. Вот пример из документации Terraform о том, как создать экземпляр EC2:

# Create a new instance of the latest Ubuntu 14.04 on an# t2.micro node with an AWS Tag naming it "HelloWorld"provider "aws" {  region = "us-west-2"}data "aws_ami" "ubuntu" {  most_recent = true  filter {    name   = "name"    values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]  }  filter {    name   = "virtualization-type"    values = ["hvm"]  }  owners = ["099720109477"] # Canonical}resource "aws_instance" "web" {  ami           = "${data.aws_ami.ubuntu.id}"  instance_type = "t2.micro"  tags {    Name = "HelloWorld"  }}

Меня, как разработчика, многие из вышеприведенных параметров (регион, тип экземпляра) не очень волнуют. Тем не менее это текущая абстракция, если я хочу зафиксировать инфраструктуру как код.

Резюме

Kubernetes – это больше, чем просто планировщик контейнеров. Это действительно дает вам примитивы, необходимые для контроля работы вашей службы, не погружаясь в детали развертывания. Мы безусловно принимаем менталитет, когда небольшая команда оперативников управляет кластером Kubernetes, а остальная команда разработчиков просто управляет своими службами с помощью примитивов Kubernetes.

Хотя в Kubernetes-land не всегда светло и розы, в моем случае развертывание Matterbridge так и было. Вам придется подождать другой статьи, чтобы прочитать о вызовах!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *