Б Бёрнс - Распределенные системы. Паттерны проектирования

SSL-мост

Вдобавок к кэшированию с целью повышения производитель-ности пограничный слой приложения также может выполнять функции SSL-моста. Даже если вы планируете использовать SSL для взаимодействия между внутренними слоями прило-

Глава 5. Реплицированные сервисы с распределением нагрузки 97жения, вам все равно придется применять разные сертификаты для внешнего слоя и для взаимодействия внутренних сервисов. В самом деле, каждый внутренний сервис должен использовать свой собственный сертификат, чтобы можно было обеспечить независимое развертывание слоев.

К сожалению, Varnish нельзя применять для организации SSL-моста, но nginx имеет такую функциональность. Стало быть, в паттерне stateless-приложения нужен третий слой — он будет представлять собой реплицированный набор nginx-серверов, который обеспечит функцию SSL-моста для HTTPS-трафика и передаст его в расшифрованном виде кэширующему серверу Varnish. HTTP-трафик попадет в веб-кэш Varnish, который переадресует его веб-приложению (рис. 5.8).

Рис. 5.8. Пример реплицированного stateless-сервиса 98Часть II. Паттерны проектирования обслуживающих систем Практикум. Развертывание nginx и SSL-моста Следующая инструкция описывает, как добавить SSL-мост на ос-нове nginx к уже развернутому реплицированному сервису и кэшу. пользоваться инструментом openssl. Данная инструкция

подразумевает, что файл сертификата носит имя server.crt, а файл секретного ключа — server.key. Самоподписанные сертификаты вызывают предупреждения безопасности во всех современных браузерах и никогда не должны ис-

Первый шаг — загрузить сертификат в Kubernetes: kubectl create secret tls ssl --cert=server.crt --key=server.key После загрузки сертификата в Kubernetes необходимо создать и настроить nginx для поддержки SSL:

events {

worker_connections 1024;

}

http {

server {

listen 443 ssl;

server_name my-domain.com www.my-domain.com; ssl on;

ssl_certificate /etc/certs/tls.crt;

ssl_certificate_key /etc/certs/tls.key; location / {

proxy_pass http://varnish-service:80; proxy_set_header Host $host;

proxy_set_header X-Forwarded-For

$proxy_add_x_forwarded_for;

Глава 5. Реплицированные сервисы с распределением нагрузки 99proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; }

}

}

Как и в случае с Varnish, нужно преобразовать файл конфигу-рации в объект ConfigMap такой командой: kubectl create configmap nginx-conf --from-file=nginx.conf После загрузки сертификата и настройки nginx пришло вре-мя создать прослойку реплицированных stateless-серверов nginx:

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: nginx-ssl

spec:

replicas: 4

template:

metadata:

labels:

app: nginx-ssl

spec:

containers:

- name: nginx

image: nginx

ports:

- containerPort: 443

volumeMounts:

- name: conf

mountPath: /etc/nginx

- name: certs

mountPath: /etc/certs

volumes:

- name: conf

configMap:

# Объект ConfigMap для nginx, созданный ранее

name: nginx-conf

100Часть II. Паттерны проектирования обслуживающих систем - name: certs

secret:

# Ссылка на загруженные ранее сертификат

# и секретный ключ

secretName: ssl

Для создания реплицированных nginx-серверов нужно выпол-нить такую команду:

kubectl create -f nginx-deploy.yaml

Наконец, опубликуйте SSL-сервер nginx в виде сервиса: kind: Service

apiVersion: v1

metadata:

name: nginx-service

spec:

selector:

app: nginx-ssl

type: LoadBalancer

ports:

- protocol: TCP

port: 443

targetPort: 443

Чтобы создать сервис балансировщика, выполните команду: kubectl create -f nginx-service.yaml

Если вы создали этот сервис в кластере Kubernetes, поддержи-вающем внешние балансировщики нагрузки, у вас появился открытый внешний сервис, принимающий запросы на внешний IP-адрес.

Чтобы узнать этот адрес, выполните команду: kubectl get services

По этому адресу вы сможете обратиться к вашему сервису из браузера.

Глава 5. Реплицированные сервисы с распределением нагрузки 101Резюме

Глава начиналась с описания простого паттерна для реплици-рованных stateless-сервисов. Затем мы дополнили его двумя реплицированными сервисами с балансировщиками нагрузки. Один выполняет функцию кэширования для повышения про-

изводительности, а другой — функцию SSL-моста для обеспе-чения защищенного соединения с клиентами. Полный паттерн реплицированного stateless-сервиса представлен на рис. 5.8. Его можно развернуть в Kubernetes с помощью трех объектов развертывания и трех объектов — сервисов балансировщиков нагрузки. Полные исходные тексты примеров можно найти по адресу https://github.com/brendandburns/designing-distributed-systems . 6 Шардированные сервисыВ предыдущей главе мы обсудили значимость репликации sta-teless-сервисов для надежности, избыточности и масштабирова-ния. В этой главе поговорим о шардированных сервисах. В рамках реплицированных сервисов, рассмотренных в предыдущей главе, каждая копия сервиса была равноценна и могла обслужить любой запрос. В отличие от реплицированных сервисов каждая копия шардированного сервиса (шард) может обслужить только часть запросов. Узел балансировки нагрузки (корневой узел ) отвечает за изучение каждого запроса и перенаправление его соответствую-щему узлу (или узлам) для обработки. Разница между реплици-рованными и шардированными сервисами показана на рис. 6.1. Репликация сервиса обычно используется для построения stateless-сервисов, а шардирование — для сервисов, хранящих состояние (stateful-сервисов). Необходимость шардинга данных возникает, когда объем данных становится слишком велик для обслуживания одной машиной. Шардинг позволяет масштаби-ровать сервис в зависимости от объема обслуживаемых данных. Глава 6. Шардированные сервисы 103

Рис. 6.1. Схемы реплицированного и шардированного сервисовШардирование кэша

Чтобы разобраться в структуре шардированной системы, нужно детально рассмотреть устройство шардированного кэша . Шар-дированный кэш — реализация кэша, стоящая между пользова-тельскими запросами и собственно распределенной реализаци-ей кэша. Общая схема системы приведена на рис. 6.2.

Рис. 6.2. Шардированный кэш

104Часть II. Паттерны проектирования обслуживающих систем В главе 3 мы рассмотрели, как можно использовать паттерн Ambassador для распределения данных в шардированном сер-висе. Здесь поговорим о том, как построить такой сервис. При проектировании шардированного кэша следует задать себе не-сколько вопросов:

‰ ‰ зачем нужен шардированный кэш;