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

И так заходим на 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 и теперь нам нужно просто авторизоваться: