Распределенные системы. Паттерны проектирования - страница 31
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 к уже развернутому реплицированному сервису и кэшу.
подразумевает, что файл сертификата носит имя 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. Реплицированные сервисы с распределением нагрузки 99 proxy_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