Предпосылки

Если вы не сделали этого раньше, вам необходимо выполнить следующие предварительные условия, прежде чем вы сможете развернуть кластер Prisma в Kubernetes. Тебе нужно:

  • работающий кластер Kubernetes (например, на Google Cloud Platform)
  • локальная версия kubectl, настроенная для связи с вашим работающим кластером Kubernetes

Теперь вы можете создать новый каталог на вашем локальном компьютере - назовите его prisma-k8s. Это будет справочник для нашего путешествия.

Создание отдельного пространства имен

Как вы, возможно, знаете, Kubernetes поставляется с примитивом под названием namespace. Это позволяет логически сгруппировать рабочую нагрузку. Прежде чем применять фактическое пространство имен к кластеру, мы должны написать для него файл определения. В каталоге нашего проекта создайте файл с именем namespace.yml со следующим содержимым:

Это определение приведет к новому пространству имен, называемому prisma. Теперь с помощью kubectl вы можете применить пространство имен, выполнив:

kubectl apply -f Namespace.ymal

После этого вы можете выполнить kubectl get namespaces, чтобы проверить, было ли создано фактическое пространство имен. В новом кластере Kubernetes вы должны увидеть следующее:

❯ kubectl get namespaces
NAME            STATUS    AGE
default         Active    2d
kube-public     Active    2d
kube-system     Active    2d
prisma          Active    10s

MongoDB

Prisma поддерживает множество различных систем баз данных. Хотя мы используем MongoDB для этого руководства, шаги можно легко адаптировать для другой системы баз данных, такой как PostgreSQL, MySQL и т. Д.

Вы можете настроить MongoDB с помощью этого руководства и пропустить раздел MongoDB:



Как развернуть MongoDB на Google Kubernetes Engine (GKE)
Это руководство создано из этого источника в образовательных целях и для предварительного обучения другому руководству. medium. com



или вы можете пойти пошагово и настроить MongoDB, как описано в этом разделе.

Подготовка диска

Теперь, когда у нас есть допустимое пространство имен, в котором мы можем разгневаться, пришло время развернуть MongoDB. Kubernetes разделяет развертывание без отслеживания состояния и развертывание с отслеживанием состояния. База данных по своей природе развертывается с отслеживанием состояния и требует диска для хранения данных. Итак, как мы скажем нашему кластеру создать новый диск в кластере? Используя PersistentVolumeClaim:

Здесь мы запрашиваем диск с объемом памяти 10 ГБ. Вы можете применить этот PVC, выполнив:

kubectl apply -f PersistentVolumeClaim.db.yaml

Теперь, когда у нас есть диск для базы данных, пора создать фактическое определение развертывания нашего экземпляра MongoDB. Краткое напоминание: Kubernetes поставляется с примитивами Pods и ReplicationControllers.

Pod похож на «виртуальную машину», на которой работает контейнерное приложение. Он получает собственный внутренний IP-адрес и (если настроен) подключенные к нему диски. ReplicationController отвечает за планирование Pod на узлах кластера и обеспечение их работы и масштабирования в соответствии с настройками.

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

Определение развертывания нашей базы данных MongoDB выглядит так:

Чтобы действительно применить это определение, выполните:

kubectl apply -f Deployment.mongo.yaml

Вы можете проверить, был ли запланирован фактический Pod, выполнив:

kubectl get pods --namespace prisma

NAME                        READY     STATUS    RESTARTS   AGE
mongo-3199294884-93db4      1/1       Running   0          1m

Развертывание службы

Перед тем, как углубиться в этот раздел, сделаем небольшое резюме.

Теперь наш модуль базы данных MongoDB работает и доступен внутри кластера. Помните, Kubernetes назначает Pod локальный IP-адрес, чтобы другое приложение могло получить доступ к базе данных.

Теперь представьте сценарий, в котором происходит сбой вашей базы данных. Система управления кластером позаботится об этой ситуации и снова планирует Pod. В этом случае Kubernetes назначит другой IP-адрес, что приведет к сбою ваших приложений, взаимодействующих с базой данных.

Чтобы избежать такой ситуации, менеджер кластера предоставляет внутренний механизм разрешения DNS. Вы должны использовать другой примитив, называемый Service, чтобы извлечь из этого пользу. Служба - это внутренний балансировщик нагрузки, доступный через service name. Его задача - перенаправить трафик на ваш Pod(s) и сделать его доступным в кластере по его имени.

Определение службы для нашей базы данных MongoDB будет выглядеть так:

Определение создаст внутренний балансировщик нагрузки с именем mongo. После этого служба становится доступной по этому имени в пространстве имен prisma. Небольшое объяснение раздела spec:

  • ports: здесь вы сопоставляете сервисный порт с фактическим портом контейнера. В этом случае сопоставление 27017 to 27017.
  • селектор: вид запроса. Балансировщик нагрузки идентифицирует Pods, выбирая те, которые имеют указанные метки.

После создания этого файла вы можете применить его с помощью:

kubectl apply -f Service.mongo.yaml

Чтобы убедиться, что служба запущена, выполните:

kubectl get services --namespace prisma

NAME       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
mongo      ClusterIP   10.6.231.114   <none>        27107/TCP   2m

Призма

Хорошо, честно говоря, база данных развернута. Далее: развертывание фактического сервера Prisma, который отвечает за работу в качестве конечной точки для Prisma CLI.

Это приложение взаимодействует с уже развернутой службой database и использует ее в качестве серверной части хранилища. Следовательно, сервер Prisma - это приложение без сохранения состояния, поскольку ему не требуется дополнительное дисковое хранилище.

Развертывание ConfigMap

Серверу Prisma требуется некоторая конфигурация, например информация о подключении к базе данных и тип коннектора, который должна использовать Prisma. Мы развернем эту конфигурацию как так называемый ConfigMap, который действует как обычный файл конфигурации, но содержимое которого может быть вставлено в переменную среды:

После определения файла вы можете применить его через:

kubectl apply -f ConfigMap.prsima.yaml

Развертывание модуля

Развернуть реальный сервер Prisma для работы в Pod довольно просто. Прежде всего вам нужно определить определение развертывания:

Эта конфигурация похожа на конфигурацию развертывания базы данных MongoDB. Мы говорим Kubernetes, что он должен запланировать одну реплику сервера и определить переменную среды, используя ранее развернутый ConfigMap.

После этого мы готовы применить это определение развертывания:

kubectl apply -f Deployment.prisma.yaml

Как и в предыдущих разделах: Чтобы проверить, что сервер Prisma был запланирован в кластере Kubernetes, выполните:

kubectl get pods --namespace prisma
NAME                        READY     STATUS    RESTARTS   AGE
mongo-3199294884-93db4      1/1       Running   0          20m
prisma-1733176504-zlphg     1/1       Running   0          2m

Ура! Сервер Prisma запущен! Переходим к следующему и последнему шагу:

Развертывание службы

Хорошо, круто, база данных Pod работает и перед ней находится внутренний балансировщик нагрузки, сервер Prisma Pod также работает, но отсутствует балансировщик нагрузки, известный как Service. Давайте исправим это:

Примените его через:

kubectl apply -f Service.prisma.yaml

Хорошо, готово! Сервер Prisma теперь доступен в кластере Kubernetes по его имени prisma.

Это все. Prisma работает на Kubernetes!

Последний шаг - настроить локальный Prisma CLI, чтобы вы могли взаимодействовать с экземпляром в кластере Kubernetes.

Предстоящий последний шаг также необходим, если вы хотите интегрировать prisma deploy в процесс CI / CD.

Конфигурация Prisma CLI

Сервер Prisma работает в кластере Kubernetes и имеет внутренний балансировщик нагрузки. Это нормальный уровень безопасности по умолчанию, потому что вы не будете открывать доступ к серверу Prisma напрямую для широкой публики. Вместо этого вы должны разработать GraphQL API и развернуть его также в кластере Kubernetes.

Вы можете спросить: «Хорошо, но как мне выполнить prisma deploy, чтобы заполнить мою модель данных, если я не могу напрямую связаться с сервером Prisma?». Это действительно очень хороший вопрос! kubectl поставляется с механизмом, который позволяет перенаправить локальный порт в приложение, которое находится в кластере Kubernetes.

Поэтому каждый раз, когда вы хотите связаться со своим сервером Prisma в кластере Kubernetes, вы должны выполнить следующие шаги:

  1. kubectl get pods --namespace prisma для определения имени модуля.
  2. kubectl port-forward --namespace prisma <the-pod-name> 4467:4466 - это будет пересылка от 127.0.0.1:4467 - ›kubernetes-cluster:4466

Теперь доступ к серверу Prisma можно получить через http://localhost:4467. Это фактический endpoint, который вы должны указать в своем prisma.yml. Поэтому, когда ваша служба должна иметь имя myservice и вы хотите развернуть ее на этапе production, URL-адрес вашей конечной точки будет выглядеть так: http://localhost:4467/myservice/production.

Пример prisma.yml может выглядеть так:

endpoint: http://localhost:4467/myservice/production
datamodel: datamodel.graphql

Имея это на месте, вы можете развернуть службу Prisma через Prisma CLI (prisma deploy), пока активна переадресация порта в кластер.

OR

вы можете создать средство миграции, которое будет включать правильный datamodel и запустить его в вашем kubernetes env. (Скоро).



Перенос файлов Dockerfiles с Debian apt на APK Alpine
Это руководство по переносу команд управления пакетами Debian apt в команды apk Alpine. medium.com



Любите учиться?

Следуйте за мной в твиттере, где я публикую все о новейших и лучших достижениях искусственного интеллекта, DevOps, VR / AR, технологиях и науке! Присоединяйтесь и ко мне в LinkedIn!