Едва ли в мире есть более популярный движок для создания блогов и небольших сайтов, чем WordPress — около 26% всех веб-сайтов в интернете созданы на его основе. Многие хостинги включают его в список своих сервисов, а официальный docker-образ был скачан более 10 миллионов раз и является одним из 25 самых популярных образов на Docker Hub. Запустив его не просто в докере, а в Kubernetes, мы можем создать масштабируемую платформу для блога или веб-сайта: при росте нагрузки мы просто масштабируем количество реплик приложения.
Stateless-приложения. Для примера возьмем два приложения — «корзину» в интернет-магазине и наш блог на WordPress. Когда мы добавляем товары в корзину (но не переходим к оплате заказа), она сохраняет все данные в cookies на нашей стороне. По завершении сессии приложение сбрасывает все данные и не хранит ничего на сервере. Когда мы снова заходим в интернет-магазин, информация о товарах считывается из нашей системы и снова отображается в корзине. Чтобы работать с покупателем, корзине не нужно получать никакую информацию с бэкенда — роль хранилища выполняет система покупателя. Такие приложения называются stateless, поскольку они не хранят информацию о своем состоянии.
Stateful-приложения. Теперь посмотрим на наш блог. Когда мы создаем новый пост или оставляем комментарий, нужно чтобы любой пользователь в любое время мог получить к ним доступ. Поэтому все данные должны храниться на стороне сервера. Когда мы переходим на ту или иную страницу, движок блога загружает имеющуюся информацию из базы данных, а если мы что-то меняем на странице — записывает изменения на сервер. Такие приложения, которые должны хранить информацию о своем состоянии для корректной работы, называются stateful. WordPress относится именно к таким приложениям.
С этим разобрались. Но где хранить все эти данные? Рассмотрим два варианта.
Для работы с хранилищем Kubernetes использует абстракции PersistentVolume и PersistentVolumeClaim. Что они из себя представляют? Объект PersistentVolume (PV) управляет постоянным хранилищем в кластере. Он поддерживает различные типы внешнего хранилища, например NFS, GlusterFS, Ceph и многие другие. PersistentVolumeClaim (PVC) — это запрос на использование хранилища для конкретного приложения. В упрощенном виде их взаимодействие можно изобразить следующим образом: приложение обращается к PersistentVolumeClaim, который запрашивает хранилище у PersistentVolume, который, в свою очередь, монтирует данные приложений в директорию на сервере хранилища. Чтобы не создавать PersistentVolume вручную, мы установим nfs-client-provisioner — приложение, которое автоматически создает PV по требованию PVC.
Для работы подов с хранилищами в архитектуре Kubernetes выделена абстракция Volume. Под обращается к нему как хранилищу без учёта того, как это хранилище реализовано. С помощью volume решается две проблемы:
PersistentVolumeClaim (PVC) — это запрос на создание PV и предоставление Storage.
Зайдем на машину-сервер, которую будем использовать для хранения данных, установим на нее файервол и откроем порты TCP:111, UDP: 111, TCP:2049, UDP:2049. В нашем примере мы используем CenOS 7.5. Для этого выполним команды:
sudo yum install firewalld -y
sudo systemctl start firewalld
sudo systemctl enable firewalld
sudo firewall-cmd --zone=public --add-port=111/tcp --permanent
sudo firewall-cmd --zone=public --add-port=111/udp --permanent
sudo firewall-cmd --zone=public --add-port=2049/tcp --permanent
sudo firewall-cmd --zone=public --add-port=2049/udp --permanent
sudo firewall-cmd --reload
Помимо этого, не забудьте дополнительно защитить внутренние ресурсы от доступа из интернета. Для этого закройте доступ к портам извне на уровне фаервола сети, в которой развёрнута ваша инсталляция.
После этого установим NFS-utils для работы с хранилищем:
sudo yum install nfs-utilsСоздадим директорию для монтирования данных на диск (/nfs) и запустим nfs-server:
sudo mkdir -p /nfs
sudo chmod -R 777 /nfs
sudo systemctl enable rpcbind
sudo systemctl enable nfs-server
sudo systemctl enable nfs-lock
sudo systemctl enable nfs-idmap
sudo systemctl start rpcbind
sudo systemctl start nfs-server
sudo systemctl start nfs-lock
sudo systemctl start nfs-idmap
Теперь добавим директорию NFS в частную подсеть Kubernetes:
sudo vi /etc/exportsДобавим следующую строку в файл и сохраним его:
/nfs X.X.X.X/X(rw,sync,no_root_squash)Теперь применим конфигурацию, выполнив команду:
exportfs -aПерезапустим nfs:
sudo systemctl restart nfs-serverЗайдем на остальные машины, установим утилиты для работы с nfs и запустим сервисы:
sudo yum install nfs-utils
systemctl enable rpcbind
systemctl enable nfs-server
systemctl enable nfs-lock
systemctl enable nfs-idmap
systemctl start rpcbind
systemctl start nfs-server
systemctl start nfs-lock
systemctl start nfs-idmap
Готово!
helm install --set nfs.server=Y.Y.Y.Y --set nfs.path=/nfs stable/nfs-client-provisionerСделаем nfs типом хранилища (StorageClass) по умолчанию:
kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'pvc-wordpress.yaml:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: wp-pv-claim labels: app: wordpress spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi
и pvc-mysql.yaml:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: claim-db-wordpress-one labels: app: wordpress-one spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi
Теперь создадим объекты PVC:
kubectl create -f pvc-wordpress.yaml
kubectl create -f pvc-mysql.yamlГотово, теперь можно переходить к запуску MySQL и WordPress.
openssl rand -base64 32 | base64На выходе получим зашифрованный пароль: QlFhZzlEOWF6c3JoMTU4Rjh2U3FDVUdHNE9KSm4xMVBtVDV1Rno1Szkvbz0K
Теперь нужно создать secret.yaml для MySQL и WordPress, на который будет ссылаться MYSQL_ROOT_PASSWORD в environment деплойментов:
apiVersion: v1 kind: Secret metadata: name: mysql-pass type: Opaque data: password: QlFhZzlEOWF6c3JoMTU4Rjh2U3FDVUdHNE9KSm4xMVBtVDV1Rno1Szkvbz0K
Выполним команду для создания секрета из файла:
kubectl create -f secret.yamlapiVersion: v1 kind: Service metadata: name: wordpress-db-one labels: app: wordpress spec: ports: - port: 3306 selector: app: wordpress tier: mysql clusterIP: None --- apiVersion: apps/v1 kind: Deployment metadata: name: wordpress-db-one labels: app: wordpress spec: selector: matchLabels: app: wordpress tier: mysql strategy: type: Recreate template: metadata: labels: app: wordpress tier: mysql spec: containers: - image: mysql:5.7 name: mysql args: - "--ignore-db-dir=lost+found" env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-pass key: password ports: - containerPort: 3306 name: mysql volumeMounts: - name: db-storage mountPath: /var/lib/mysql volumes: - name: db-storage persistentVolumeClaim: claimName: claim-db-wordpress-one
Файл состоит из 2 файлов конфигураций: Service открывает порт 3306 для всех контейнеров, у которых прописаны лейблы app:wordpress и tier:mysql. Часть Deployment описывает параметры создания деплоймента и specs контейнера с MySQL:
kubectl create -f mysql-deploy.yamlapiVersion: v1 kind: Service metadata: name: wordpress labels: app: wordpress spec: ports: - port: 80 selector: app: wordpress tier: frontend type: LoadBalancer --- apiVersion: apps/v1 kind: Deployment metadata: name: wordpress labels: app: wordpress spec: selector: matchLabels: app: wordpress tier: frontend strategy: type: Recreate template: metadata: labels: app: wordpress tier: frontend spec: containers: - image: wordpress:4.8-apache # latest: wordpress:4.9-php7.2-apache name: wordpress env: - name: WORDPRESS_DB_HOST value: wordpress-db-one # This one is from Service - name: WORDPRESS_DB_PASSWORD valueFrom: secretKeyRef: name: mysql-pass key: password ports: - containerPort: 80 name: wordpress volumeMounts: - name: wordpress-persistent-storage mountPath: /var/www/html volumes: - name: wordpress-persistent-storage persistentVolumeClaim: claimName: wp-pv-claim
Как и в предыдущем случае, файл состоит из 2 частей. Service пробрасывает 80-й порт контейнера на внешний IP:порт машины для всех контейнеров с лейблами app:wordpress и tier:frontend. Deployment содержит следующие specs контейнера WordPress:
kubectl create -f wordpress-deploy.yamlУбедимся, что все работает:
kubectl get po
Перейдем по адресу: внешний_IP:порт_сервиса (в нашем случае 32095).
Перед нами появился экран выбора языка — WordPress готов к работе.
Теперь перезапустим поды WordPress и MySQL и проверим, сохранились ли данные приложений.
kubectl get po
Удалим поды и подождем, пока будут созданы новые:
kubectl delete po название_пода1 название_пода2
Снова зайдем на главную страницу WordPress.
Тем не менее, NFS отлично подходит для небольших проектов. Если в какой-то момент что-то пойдет не так и WordPress или MySQL «упадет» или перезапустится, мы не потеряем контент благодаря тому, что они хранятся не внутри контейнеров, а во внешнем хранилище. Главное — не забывать регулярно делать бэкапы.
