Для обеспечения балансировки нагрузки, масштабируемости и повышения отказоустойчивости могут использоваться вспомогательные средства — оркестраторы. Среди них большой популярностью сейчас пользуется сервис Kubernetes. Самый простой способ попробовать его в деле — развернуть его в облаке, чем мы сегодня и займемся.
Первым делом заходим на портал Azure, нажимаем «Создать ресурс» и находим сервис под названием Kubernetes Service. Выбираем имя и префикс DNS на свой вкус. Имя влияет на то, как ты будешь обращаться к своему кластеру, а вот префикс влияет на его FQDN-адрес.
Практически сразу после релиза Google передала проект Kubernetes в созданный при сотрудничестве с The Linux Foundation фонд под названием Cloud Native Computing Foundation.
Вторым шагом предлагается создать service principal. Service principal — это своеобразный сервисный аккаунт, под которым могут выполняться какие-то определенные задачи. Плюсы в том, что права такого аккаунта можно ограничить. Кроме того, можно создать любое количество подобных аккаунтов (в то время как число обычных аккаунтов ограничено подпиской). Найти созданные аккаунты service principal можно в Active Directory среди App Registrations.
RBAC (role-based access control) — это возможность ограничить или предоставить доступ к определенным ресурсам (или группам ресурсов). То есть ты сможешь разграничить, какие пользователи подписки имеют права доступа, а какие не имеют.
На данный момент процесс занимает минут двадцать, но все может зависеть от конфигурации. Найти официальные руководства можно по ссылкам «создание кластера AKS с помощью портала» и «создание кластера AKS с помощью CLI».
Для работы нам понадобится командная строка Azure — CLI (Command Line Interface). Ее можно установить как под Windows, так и под macOS или Linux. Лично я предпочитаю использовать Azure Cloud Shell. Это командная строка, которая запускается из загруженной в браузер страницы портала Azure. Для работы она требует созданного blob-хранилища. Его стоимость составит несколько центов в месяц, и потому я предпочитаю не париться по поводу установки CLI на свою машину.
Kubernetes поддерживает различные технологии контейнеров, но давай рассмотрим самую популярную — Docker. Docker.hub позволяет хранить один приватный образ докера бесплатно. Если нужно больше, то можно разместить их за деньги. Но за деньги приватный образ докера можно разместить и в Azure Container Registry. Сейчас цены начинаются с 5 долларов в месяц (за базовый SKU).
Я создал сервис ACR под именем myservice. Если ты тоже соберешься воспользоваться ACR, то, создав сервис, будет необходимо получить его ключи.
Затем станет возможным залогиниться, выполнив команду
docker login myservice.azurecr.io
Вводим взятые с портала имя пользователя myservice
и пароль PJSeyO9=lCMRDI7dGkz68wjhFGRGxSY3
. Теперь, зайдя в директорию с проектом, можно будет построить образ, одновременно пометив его нужным тегом. А после этого отправить его в облачный сервис:
docker build -t myservice.azurecr.io/myservice . docker push myservice.azurecr.io/myservice
При работе с развернутым AKS необходимо получить его креды. Иначе команды kubectl не будут выполняться. Получить доступ к AKS позволяет следующая команда:
az aks get-credentials --resource-group KubernetesGroup --name verycoolcluster
Для того чтобы получить доступ к образу докера, расположенному в репозитории докера в приватном контейнере, понадобится создать секрет. Если у тебя публичный образ, то этот шаг можно пропустить. Для создания файла секрета нужно выполнить команду такого вида:
kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
Если твой образ находится в репозитории докера, то значением <your-registry-server>
будет https://index.docker.io/v1/
. Для Azure Container Registry FQDN — <registry-name>.azurecr.io
. То есть, чтобы создать секрет для контейнера в моем случае, я выполнил
kubectl create secret docker-registry regcred --docker-server="myservice.azurecr.io" --docker-username="myservice" --docker-password="PJSeyO9=lCMRDI7dGkz68wjhFGRGxSY3" --docker-email="asommer@yandex.ru"
Посмотреть содержимое созданного файла секрета теперь можно с помощью команды
kubectl get secret regcred --output=yaml
Если ты используешь AKS, то можно не создавать файл секрета, а предоставить доступ сервису AKS к сервису ACR иным способом — выполнив особый скрипт. Взять его можно со следующей странички: Authenticate with Azure Container Registry from Azure Kubernetes Service.
#!/bin/bash AKS_RESOURCE_GROUP=KubernetesGroup AKS_CLUSTER_NAME=verycoolcluster ACR_RESOURCE_GROUP=MyACRGroup ACR_NAME=myservice # Get the id of the service principal configured for AKS CLIENT_ID=$(az aks show --resource-group $AKS_RESOURCE_GROUP --name $AKS_CLUSTER_NAME --query "servicePrincipalProfile.clientId" --output tsv) # Get the ACR registry resource id ACR_ID=$(az acr show --name $ACR_NAME --resource-group $ACR_RESOURCE_GROUP --query "id" --output tsv) # Create role assignment az role assignment create --assignee $CLIENT_ID --role Reader --scope $ACR_ID
Можешь просто модифицировать значения переменных AKS_*
и ACR_*
, скопировать скрипт и вставить его в Azure CLI или Cloud Shell.
Kubernetes содержит безопасное хранилище учетных данных. То есть можно создать файл с настройками, и доступ к этим настройкам получить извне будет затруднительно. В этом файле обычно находятся строки подключения к базам данных и какие-то креды. Если такой информации у тебя в приложении нет (что, правда?), то этот шаг можно пропустить.
Чтобы создать файл с настройками из командной строки, нам понадобятся команды vi.
vi <имя файла>
создаст файл, если он отсутствует, или откроет существующий.Очень сокращенное описание, но его должно хватить. Могу добавить, что может очень пригодиться использование клавиши Insert.
Итак, через Azure Cloud Shell создаешь файл с произвольным названием (допустим, appsettings.json
) и необходимым содержимым. Допустим, таким:
{ "ConnectionString": "some secret string goes there" }
И после выполняешь команду
kubectl create secret generic secret-appsettings --from-file=/home/youraccount/appsettings.json
Эта команда создаст секрет с настройками под именем secret-appsettings
. Узнать, на какой путь заменить /home/youraccount
, можно с помощью команды pwd
.
Deployments предназначены для stateless-сервисов (хорошо сказал, сразу вспоминаются шутки про билингвов, митболы и сторителлинг. 🙂 — Прим. ред.). Они описывают то, как Pods и ReplicaSets будут созданы и как они будут обновляться. Pod — это группа контейнеров (или же один контейнер), которые работают в одном окружении. ReplicaSet следит за тем, чтобы указанное количество pod было запущено и постоянно работало.
Я создаю файл deploy.yaml
, который создаст три пода. Файл содержит следующий код (напоминаю, что пробелы в YAML очень важны):
Материалы из последних выпусков можно покупать отдельно только через два месяца после публикации. Чтобы продолжить чтение, необходимо купить подписку.
Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке
1 год7190 р. Экономия 1400 рублей! |
1 месяц720 р. 25-30 статей в месяц |
Уже подписан?
Читайте также
Последние новости