How to become an author
Search
Write a publication
Pull to refresh
127.33
Rating
Слёрм
Учебный центр для тех, кто работает в IT

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

Reading time7 min
Views3.4K
Слёрм corporate blogServer Administration*System administration*
Translation
Original author: Rahul Mahale

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


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


image


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


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


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


Для маршрутизации на основе 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

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


Он же будет разрешать 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 или что-нибудь подобное — решать вам.


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


Сервис 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 решила эту задачу.

Tags:
Hubs:
Total votes 14: ↑14 and ↓0+14
Comments0
Слёрм
Учебный центр для тех, кто работает в IT
Website
115
Karma
0
Rating
@nAbdullin

User

Send message

Articles

Information

Website
slurm.io
Registered
Founded
Employees
51–100 employees
Location
Россия
Representative
Антон Скобин

Your account

Sections

Information

Services

Support
© 2006–2024, Habr