Евгений Штольц - Из разработчика в архитекторы. Практический путь

Для развёртывания будем использовать Kubernetes для противодействия vender lock, когда инфраструктура проекта завязана на api конкретного облачного провайдера и не позволят перейти на другие или собственные облака без существенных изменений в самом приложении. Kubernetes поддерживается Amazon AWS, Google Cloud, Microsorft Azure, локальной установкой одного иснтанца с помощью MiniKube.

Воспользуемся Google Cloud, на текущий 2018 год он предоставляет бесплатное использование на один год ограниченных ресурсов (300 долларов США), при этом существуют лимиты, которые можно посмотреть в меню IAM и администрирование —> Квоты. Важно заметить, облачные провайдеры не предоставляют тарифов в современном диапазоне, а предоставляют тарифы на использовании определённых мощностей, то есть сайт мало посещаем – платим мало, сложно обрабатываем много данных – платим много. По этой причине, когда потребности в вычислительных мощностях у компании предсказуемы (не стартап) может быть целесообразно использовать собственные возможности для постоянной нагрузки, что может быть экономически целесообразно, не рискую ограниченностью вычислительными мощностями.

И так заходим на cloud.google.com регистрируется, привязываем дебетовую карту с минимальным балансом и переходим в консоль console.cloud.google.com, в котором можно пройти обучение по интерфейсу для общего ознакомления. В меню нажимаем пункт Оплата: у меня нетронутые демо-деньги 300 долларов США и осталось 356 дней (средства списываются не в режиме реального времени).

Если смотреть на как основу для Back-End для мобильной разработки (MBasS, Mobile backend as a service), то его предоставляют разные провайдеры: Google Firebase, AWS Mobile, Azure Mobile

Google App Engine

Создание кластера через Web-интерфейс

Предварительно проверим ограничения (квоты) Меню —> Продукты —> IAM и администрирование —> Квоты, а если вы находитесь на тестовом аккаунте, то Static IP addresses будет равен 1, то не сможет создаться балансировщик и придётся удалять кластер. Создадим кластер в Меню – Ресурсы – Kubernetes Engine в тремя репликами микромашины и последней версией Kubernetes. В левом нижнем углу в пункте Marketplace создадим 2 инстанса Nginx. После создания кластера кликнем по вкладке Сервисы и перейдём по IP-адресу.

MarketPlace: Сеть, Бесплатные, Приложения Kubernetes: Nginx Создадим кастомный кластер standard-cluster-Nginx, выбрав минимум CPU и RAM, 2 ноды вместо 3 и последнюю вер сию Kubernetes (я выбрал 1.11.3, а мой код будет совместим с – не ниже 1.10). В Меню – Ресурсы – Kubernetes Engine во кладке Кластера нажмём кнопку Подключиться. Управлением кластером в командной строке осуществляется с помощью команды cubectl, о ней можно почитать в документации https://kubernetes.io/docs/reference/kubectl/overview/ и список по https://gist.github.com/ipedrazas/95391ffd88190bea94ca188d3d2c1cbe.

Создание виртуальной машины:

Можно создать программный проект, но пользоваться им можно будет только на платном аккаунте:

NAME_PROJECT=bitrix_12345;

NAME_CLUSTER=bitrix;

gcloud projects create $NAME_CLUSTER – name $NAME_CLUSTER;

gcloud config set project $NAME_CLUSTER;

gcloud projects list;

Несколько тонкостей: ключ – zone обязателен и ставится в конце, диска не должен быть меньше 10Gb, а тип машин можно взять из https://cloud.google.com/compute/docs/machine-types. Если реплика у нас одна, то по умолчанию создаётся минимальная конфигурация для тестирования:

gcloud container clusters create $NAME_CLUSTER – zone europe-north1-a

Вы можете увидеть в админке, развернув выпадающий список в шапке, и открыв вкладку Все проекты.

gcloud projects delete NAME_PROJECT;

, если больше – стандартная, параметры которой мы подредактируем:

$ gcloud container clusters create mycluster \

– machine-type=n1-standard-1 —disk-size=10GB – image-type ubuntu \

– scopes compute-rw,gke-default \

– machine-type=custom-1-1024 \

– cluster-version=1.11 —enable-autoupgrade \

– num-nodes=1 —enable-autoscaling – min-nodes=1 —max-nodes=2 \

– zone europe-north1-a

Ключ – enable-autorepair запускаем работу мониторинга доступности ноды и в случае её падения – она будет пересоздана. Ключ требует версию Kubernetes не менее 1.11, а на момент написания книги версия по умолчанию 1.10 и по этому нужно её задать ключом, например, – cluster-version=1.11.4-gke.12. Но можно зафиксировать только мажорную версия – cluster-version=1.11 и установить автообновление версии – enable-autoupgrade. Также зададим авто уверение количества нод, если ресурсов не хватает: —num-nodes=1 —min-nodes=1 —max-nodes=2 —enable-autoscaling.

Теперь поговорим об виртуальный ядрах и оперативной памяти. По умолчанию поднимается машина n1-standart-1, имеющая одно виртуальное ядро и 3.5Gb оперативной памяти, в трёх экземплярах, что совокупно даёт три виртуальных ядра и 10.5Gb оперативной памяти. Важно, чтобы в кластере было всего не менее двух виртуальных ядер процессора, иначе их, формально по лимитам на системные контейнера Kubernetes, не хватит для полноценной работы (могут не подняться контейнера, например, системные). Я возьму две ноды по одному ядру и общее количество ядер будет два. Такая же ситуация и с оперативной памятью, для поднятия контейнера с Nginx мне вполне хватало 1Gb (1024Mb) оперативной памяти, а вот для поднятия контейнера с LAMP (Apache MySQL PHP) уже нет, у меня не поднялся системный сервис kube-dns-548976df6c-mlljx, который отвечает за DNS в поде. Не смотря не то, что он не является жизненно важным и нам не пригодится, в следующий раз может не подняться уж более важный вместо него. При этом важно заметить, что у меня нормально поднимался кластер с 1Gb и было всё нормально, я общий объём в 2Gb оказался пограничным значением. Я задал 1080Mb (1.25Gb), учтя, что минимальная планка оперативной памяти составляет 256Mb (0.25Gb) и мой объём должен быть кратен ей и быть не меньше, для одно ядра, 1Gb. В результате в кластера 2 ядра и 2.5Gb вместо 3 ядре и 10.5Gb, что является существенной оптимизацией ресурсов и цены на платном аккаунте.

Теперь нам нужно подключиться к серверу. Ключ у нас уже есть на сервере ${HOME}/.kube/config и теперь нам нужно просто авторизоваться:

$ gcloud container clusters get-credentials b – zone europe-north1-a – project essch

$ kubectl port-forward Nginxlamp-74c8b5b7f-d2rsg 8080:8080

Forwarding from 127.0.0.1:8080 —> 8080

Forwarding from [::1]:8080 —> 8080

$ google-chrome http://localhost:8080 # это не будет работать в Google Shell

$ kubectl expose Deployment Nginxlamp – type="LoadBalancer" – port=8080

Для локального использования kubectl Вам нужно установить gcloud и с помощью него установить kubectl используя команду gcloud components install kubectl, но пока не будем усложнять первые шаги.

В разделе Сервисы админки будет доступен под не только через сервис балансировщик frontend, но и через внутренний балансировщик Deployment. Хоть и после пересоздания и сохранится, но конфиг более поддерживаем и очевиден.

Также есть возможность дать возможность регулировать количество нод в автоматическом режиме в зависимости от нагрузки, например, количества контейнеров с установленными требованиями к ресурсам, с помощью ключей – enable-autoscaling – min-nodes=1 —max-nodes=2.

Простой кластер в GCP

Для создания кластера можно пойти двумя путями: через графический интрефейс Google Cloud Platform или через его API командой gcloud. Посмотрим, как это можно сделать через UI. Рядом с меню кликнем на выпадающей список и создадим отдельный проект. В разделе Kuberntes Engine выбираем создать кластер. Дадим название, 2CPU, зону europe-north-1 (дата-центр в Финляндии ближе всего к СПб) и последнюю версию Kubernetes. После создания кластера кликаем на подключиться и выбираем Cloud Shell. Для создания через api по кнопке в правом верхнем углу выведем консольную панель и введём в ней: