Хабрахабр

[Перевод] Как развернуть приложение Ruby on Rails с HAProxy Ingress, unicorn/puma и веб-сокетами

После нескольких месяцев тестов мы наконец перенесли приложение Ruby on Rails в продакшен с кластером Kubernetes.

В этой статье я расскажу, как настроить маршрутизацию на основе Path для приложения Ruby on Rails в Kubernetes с контроллером HAProxy Ingress.

image

Предполагается, что вы примерно представляете себе, что такое поды, деплои, сервисы, карта конфигурации и Ingress в Kubernetes

У нас был один веб-сервис, открытый наружу через балансировщик, и все работало нормально. Обычно в Rails-приложении есть такие сервисы, как unicorn/puma, sidekiq/delayed-job/resque, веб-сокеты и несколько специальных API сервисов. Но трафик рос, и нужно было маршрутизировать его по URL или Path.

Под нее уже разрабатывается alb-ingress-controller, но он пока на стадии альфы и для продакшена не подходит. В Kubernetes нет готового решения для балансировки нагрузки такого типа.

Для маршрутизации на основе Path лучше всего было использовать Ingress-контроллер.

Мы изучили вопрос и узнали, что в k8s есть разные решения для Ingress.

Мы поэкспериментировали с nginx-ingress и HAProxy и остановились на HAProxy — он лучше подходит для веб-сокетов Rails, которые мы использовали в проекте.

Я расскажу пошагово, как прикрутить HAProxy Ingress к Rails-приложению.

Настройка Rails-приложения с контроллером HAProxy Ingress

Вот что мы будем делать:

  • Создадим Rails-приложение с разными сервисами и деплоями.
  • Создадим секрет TLS для SSL.
  • Создадим карту конфигурации HAProxy Ingress.
  • Создадим контроллер HAProxy Ingress.
  • Откроем доступ к Ingress через сервис типа LoadBalancer.
  • Настроим DNS приложения для сервиса Ingress.
  • Создадим разные правила Ingress для маршрутизации на основе Path.
  • Протестируем маршрутизацию на основе Path.

Давайте создадим манифест развертывания Rails-приложения для разных сервисов — веб (unicorn), фоновые задачи (sidekiq), веб-сокет (ruby thin), API (выделенный unicorn).

Вот наш деплой веб-приложения и шаблон сервиса.

---
apiVersion: v1
kind: Deployment
metadata: name: test-production-web labels: app: test-production-web namespace: test
spec: template: metadata: labels: app: test-production-web spec: containers: - image: <your-repo>/<your-image-name>:latest name: test-production imagePullPolicy: Always env: - name: POSTGRES_HOST value: test-production-postgres - name: REDIS_HOST value: test-production-redis - name: APP_ENV value: production - name: APP_TYPE value: web - name: CLIENT value: test ports: - containerPort: 80 imagePullSecrets: - name: registrykey
---
apiVersion: v1
kind: Service
metadata: name: test-production-web labels: app: test-production-web namespace: test
spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: test-production-web

Вот деплой фонового приложения и шаблон сервиса.

---
apiVersion: v1
kind: Deployment
metadata: name: test-production-background labels: app: test-production-background namespace: test
spec: template: metadata: labels: app: test-production-background spec: containers: - image: <your-repo>/<your-image-name>:latest name: test-production imagePullPolicy: Always env: - name: POSTGRES_HOST value: test-production-postgres - name: REDIS_HOST value: test-production-redis - name: APP_ENV value: production - name: APP_TYPE value: background - name: CLIENT value: test ports: - containerPort: 80 imagePullSecrets: - name: registrykey
---
apiVersion: v1
kind: Service
metadata: name: test-production-background labels: app: test-production-background namespace: test
spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: test-production-background

Вот деплой веб-сокет приложения и шаблон сервиса.

---
apiVersion: v1
kind: Deployment
metadata: name: test-production-websocket labels: app: test-production-websocket namespace: test
spec: template: metadata: labels: app: test-production-websocket spec: containers: - image: <your-repo>/<your-image-name>:latest name: test-production imagePullPolicy: Always env: - name: POSTGRES_HOST value: test-production-postgres - name: REDIS_HOST value: test-production-redis - name: APP_ENV value: production - name: APP_TYPE value: websocket - name: CLIENT value: test ports: - containerPort: 80 imagePullSecrets: - name: registrykey
---
apiVersion: v1
kind: Service
metadata: name: test-production-websocket labels: app: test-production-websocket namespace: test
spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: test-production-websocket

Вот деплой API приложения и сведения о сервисе.

---
`apiVersion: v1
kind: Deployment
metadata: name: test-production-api labels: app: test-production-api namespace: test
spec: template: metadata: labels: app: test-production-api spec: containers: - image: <your-repo>/<your-image-name>:latest name: test-production imagePullPolicy: Always env: - name: POSTGRES_HOST value: test-production-postgres - name: REDIS_HOST value: test-production-redis - name: APP_ENV value: production - name: APP_TYPE value: api - name: CLIENT value: test ports: - containerPort: 80 imagePullSecrets: - name: registrykey
---
apiVersion: v1
kind: Service
metadata: name: test-production-api labels: app: test-production-api namespace: test
spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: test-production-api

Давайте запустим манифест командой kubectl apply.

$ kubectl apply -f test-web.yml -f test-background.yml -f test-websocket.yml -f test-api.yml
deployment "test-production-web" created
service "test-production-web" created
deployment "test-production-background" created
service "test-production-background" created
deployment "test-production-websocket" created
service "test-production-websocket" created
deployment "test-production-api" created
service "test-production-api" created

Но сначала давайте создадим секрет TLS с ключом и сертификатом SSL. Как только приложение будет развернуто и запущено, нужно будет создать HAProxy Ingress.

Он же будет разрешать HTTPS для URL приложения и терминировать его на L7.

$ kubectl create secret tls tls-certificate --key server.key --cert server.pem

server.key здесь — это наш ключ SSL, а server.pem — наш сертификат SSL в формате pem.

Теперь создадим ресурсы контроллера HAProxy.

Карта конфигурации HAProxy

Все доступные параметры конфигурации для HAProxy смотрите здесь.

apiVersion: v1
data: dynamic-scaling: "true" backend-server-slots-increment: "4"
kind: ConfigMap
metadata: name: haproxy-configmap namespace: test

Развертывание контроллера HAProxy Ingress

Шаблон развертывания для Ingress-контроллера минимум с двумя репликами для управления последовательным деплоем.

apiVersion: extensions/v1beta1
kind: Deployment
metadata: labels: run: haproxy-ingress name: haproxy-ingress namespace: test
spec: replicas: 2 selector: matchLabels: run: haproxy-ingress template: metadata: labels: run: haproxy-ingress spec: containers: - name: haproxy-ingress image: quay.io/jcmoraisjr/haproxy-ingress:v0.5-beta.1 args: - --default-backend-service=$(POD_NAMESPACE)/test-production-web - --default-ssl-certificate=$(POD_NAMESPACE)/tls-certificate - --configmap=$(POD_NAMESPACE)/haproxy-configmap - --ingress-class=haproxy ports: - name: http containerPort: 80 - name: https containerPort: 443 - name: stat containerPort: 1936 env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace

В этом манифесте нас особенно интересуют аргументы, передаваемые контроллеру.
--default-backend-service — это сервис, который приложение будет использовать, если запросу не соответствуют никакие правила.

У нас это сервис test-production-web, но это может быть кастомная страница 404 или что-нибудь подобное — решать вам.

Он будет терминировать SSL на L7, и приложение будет доступно извне по HTTPS. --default-ssl-certificate — это секрет SSL, который мы только что создали.

Сервис HAProxy Ingress

Это тип сервиса LoadBalancer, который разрешает клиентскому трафику доступ к нашему Ingress-контроллеру.

У LoadBalancer есть доступ к публичной сети и внутренней сети Kubernetes, а на L7 он маршрутизирует трафик для Ingress-контроллера.

apiVersion: v1
kind: Service
metadata: labels: run: haproxy-ingress name: haproxy-ingress namespace: test
spec: type: LoadBalancer ports: - name: http port: 80 protocol: TCP targetPort: 80 - name: https port: 443 protocol: TCP targetPort: 443 - name: stat port: 1936 protocol: TCP targetPort: 1936 selector: run: haproxy-ingress

Давайте применим все манифесты HAProxy.

$ kubectl apply -f haproxy-configmap.yml -f haproxy-deployment.yml -f haproxy-service.yml
configmap "haproxy-configmap" created
deployment "haproxy-ingress" created
service "haproxy-ingress" created

Когда все ресурсы будут запущены, укажите конечную точку LoadBalancer.

$ kubectl -n test get svc haproxy-ingress -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
haproxy-ingress LoadBalancer 100.67.194.186 a694abcdefghi11e8bc3b0af2eb5c5d8-806901662.us-east-1.elb.amazonaws.com 80:31788/TCP,443:32274/TCP,1936:32157/TCP 2m run=ingress

Сопоставление DNS с URL приложения

Как только мы укажем конечную точку ELB для сервиса Ingress, нужно будет сопоставить между собой DNS сервиса и URL запроса (например test-rails-app.com).

Реализация Ingress

Самое сложное позади, пора настроить Ingress и правила на основе Path.

Нам нужны нужны следующие правила.

Запросы к https://test-rails-app.com будут обрабатываться сервисом test-production-web.

Запросы к https://test-rails-app.com/websocket будут обрабатываться сервисом test-production-websocket.

Запросы к https://test-rails-app.com/api будут обрабатываться сервисом test-production-api.

Давайте создадим манифест Ingress со всеми этими правилами.

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata: name: ingress namespace: test
spec: tls: - hosts: - test-rails-app.com secretName: tls-certificate rules: - host: test-rails-app.com http: paths: - path: / backend: serviceName: test-production-web servicePort: 80 - path: /api backend: serviceName: test-production-api servicePort: 80 - path: /websocket backend: serviceName: test-production-websocket servicePort: 80

На случай изменений конфигурации у нас есть аннотации для Ingress ресурсов.

Как и ожидалось, по умолчанию наш трафик на / маршрутизируется в сервис test-production-web, /api — в test-production-api, а /websocket — в test-production-websocket.

Нам нужна была маршрутизация на основе Path и терминация SSL на L7 в Kubernetes, и реализация Ingress решила эту задачу.

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть