1. Введение
Почему стоит переходить от монолитного приложения к микросервисной архитектуре? Разделение приложения на микросервисы имеет следующие преимущества; большинство из них обусловлено тем, что микросервисы слабо связаны между собой.
- Микросервисы можно тестировать и развертывать независимо друг от друга. Чем меньше единица развертывания, тем проще развертывание.
- Они могут быть реализованы на разных языках и с использованием различных фреймворков. Для каждого микросервиса вы можете свободно выбрать технологию, наиболее подходящую для конкретного случая.
- Управление ими может осуществляться разными командами. Граница между микросервисами упрощает выделение команды для одного или нескольких микросервисов.
- Переход к микросервисам ослабляет зависимость между командами. Каждая команда должна заботиться только об API тех микросервисов, от которых она зависит. Команде не нужно думать о том, как эти микросервисы реализованы, об их циклах выпуска и так далее.
- Спроектировать систему с учетом возможных сбоев проще. Четко разграничивая сервисы, легче определить, что делать, если какой-либо из них выйдет из строя.
К недостаткам по сравнению с монолитными конструкциями относятся, например, следующие:
- Поскольку приложение, основанное на микросервисах, представляет собой сеть различных сервисов, которые часто взаимодействуют неочевидным образом, общая сложность системы, как правило, возрастает.
- В отличие от внутренней структуры монолитной архитектуры, микросервисы взаимодействуют по сети. В некоторых случаях это может представлять угрозу безопасности. Istio решает эту проблему, автоматически шифруя трафик между микросервисами.
- Достичь того же уровня производительности, что и при монолитном подходе, может быть сложно из-за задержек между сервисами.
- Поведение вашей системы определяется не одним сервисом, а множеством сервисов и их взаимодействием. Из-за этого понять, как ваша система ведет себя в производственной среде (ее наблюдаемость), становится сложнее. Istio также является решением этой проблемы.
В этой лабораторной работе мы будем запускать микросервисы в Google Kubernetes Engine (GKE). Kubernetes — это платформа для управления, размещения, масштабирования и развертывания контейнеров. Контейнеры — это портативный способ упаковки и запуска кода. Они хорошо подходят для микросервисной архитектуры, где каждый микросервис может работать в собственном контейнере.
В рамках этой лабораторной работы мы развернем существующее монолитное приложение в кластере Google Kubernetes Engine, а затем разобьем его на микросервисы!
Архитектурная схема наших микросервисов
Начнём с того, что разберём наш монолит на три микросервиса, по очереди. Микросервисы включают в себя Orders, Products и Frontend. Для каждого микросервиса мы создадим образ Docker с помощью Cloud Build, который запустим из Cloud Shell. Затем мы развёрнем и предоставим доступ к нашим микросервисам в Google Kubernetes Engine (GKE) с помощью сервиса Kubernetes типа LoadBalancer. Мы будем делать это для каждого сервиса, одновременно вынося их из монолита. В процессе работы и монолит, и микросервисы будут работать до самого конца, когда мы сможем удалить монолит.
Что вы узнаете
- Как разбить монолитную архитектуру на микросервисы
- Как создать кластер Google Kubernetes Engine
- Как создать образ Docker
- Как развернуть образы Docker в Kubernetes
Предварительные требования
- Учетная запись Google Cloud Platform с административным доступом для создания проектов или проект с ролью владельца проекта.
- Базовое понимание Docker и Kubernetes.
2. Настройка среды
Настройка среды для самостоятельного обучения
Если у вас еще нет учетной записи Google (Gmail или Google Apps), вам необходимо ее создать . Войдите в консоль Google Cloud Platform ( console.cloud.google.com ) и создайте новый проект:
Запомните идентификатор проекта (Project ID) — уникальное имя для всех проектов Google Cloud (указанное выше имя уже занято и вам не подойдёт, извините!). В дальнейшем в этом практическом занятии оно будет обозначаться как PROJECT_ID .
Далее вам потребуется включить оплату в консоли разработчика, чтобы использовать ресурсы Google Cloud и активировать API Container Engine .
Выполнение этого практического задания не должно обойтись вам дороже нескольких долларов, но может стоить больше, если вы решите использовать больше ресурсов или оставите их запущенными (см. раздел «очистка» в конце этого документа). Информация о ценах на Google Kubernetes Engine приведена здесь .
Новые пользователи Google Cloud Platform могут получить бесплатную пробную версию стоимостью 300 долларов .
Google Cloud Shell
Хотя Google Cloud и Kubernetes можно запускать удаленно с ноутбука, в этом практическом занятии мы будем использовать Google Cloud Shell — среду командной строки, работающую в облаке.
Эта виртуальная машина на базе Debian содержит все необходимые инструменты разработки. Она предоставляет постоянный домашний каталог размером 5 ГБ и работает в облаке Google, что значительно повышает производительность сети и аутентификацию. Это означает, что для выполнения этого практического задания вам понадобится только браузер (да, он работает и на Chromebook).
- Для активации Cloud Shell из консоли Cloud Console просто нажмите «Активировать Cloud Shell».
(На подготовку и подключение к среде должно уйти всего несколько минут).
После подключения к Cloud Shell вы увидите, что ваша аутентификация пройдена и проект уже настроен на ваш PROJECT_ID .
gcloud auth list
вывод команды
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
вывод команды
[core] project = <PROJECT_ID>
Если по какой-либо причине проект не создан, просто выполните следующую команду:
gcloud config set project <PROJECT_ID>
Ищете свой PROJECT_ID ? Проверьте, какой ID вы использовали на этапах настройки, или найдите его на панели управления Cloud Console:
Cloud Shell также по умолчанию устанавливает некоторые переменные среды, которые могут быть полезны при выполнении будущих команд.
echo $GOOGLE_CLOUD_PROJECT
вывод команды
<PROJECT_ID>
- Наконец, установите зону по умолчанию и конфигурацию проекта.
gcloud config set compute/zone us-central1-f
Вы можете выбрать различные зоны. Для получения дополнительной информации см. раздел «Регионы и зоны» .
3. Клонировать исходный репозиторий
Мы используем существующее монолитное приложение, представляющее собой воображаемый веб-сайт электронной коммерции, с простой приветственной страницей, страницей товаров и страницей истории заказов. Нам нужно будет просто клонировать исходный код из нашего репозитория Git, чтобы мы могли сосредоточиться на его разбиении на микросервисы и развертывании в Google Kubernetes Engine (GKE).
Выполните следующие команды, чтобы клонировать репозиторий Git в ваш экземпляр Cloud Shell и перейти в соответствующую директорию. Мы также установим зависимости NodeJS, чтобы протестировать наш монолит перед развертыванием. Выполнение этого скрипта может занять несколько минут.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
Эта команда клонирует наш репозиторий на GitHub, перейдет в нужную директорию и установит зависимости, необходимые для локального запуска нашего приложения. Выполнение скрипта может занять несколько минут.
4. Создайте кластер GKE.
Теперь, когда у вас есть рабочая среда разработки, нам нужен кластер Kubernetes для развертывания нашего монолита, а затем и микросервисов! Прежде чем создавать кластер, необходимо убедиться, что включены соответствующие API. Выполните следующую команду, чтобы включить API контейнеров и использовать Google Kubernetes Engine:
gcloud services enable container.googleapis.com
Теперь мы готовы создать наш кластер! Выполните команду ниже, чтобы создать кластер GKE с именем fancy-cluster , состоящий из 3 узлов.
gcloud container clusters create fancy-cluster --num-nodes 3
Создание кластера может занять несколько минут. После завершения выполнения команды выполните следующую команду, чтобы увидеть три рабочих экземпляра виртуальных машин кластера:
gcloud compute instances list
Выход:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
Вы также можете просмотреть свой кластер Kubernetes и связанную с ним информацию в консоли Google Cloud. Нажмите кнопку меню в верхнем левом углу, прокрутите вниз до Kubernetes Engine и нажмите «Кластеры». Вы должны увидеть свой кластер с именем fancy-cluster .
Поздравляем! Вы только что создали свой первый кластер Kubernetes!
5. Развертывание существующего монолита
Поскольку основная цель этой лабораторной работы — разбить монолитное приложение на микросервисы, нам необходимо запустить монолитное приложение. Для развертывания монолитного приложения в нашем кластере GKE для целей этой лабораторной работы выполните следующий скрипт:
cd ~/monolith-to-microservices ./deploy-monolith.sh
Доступ к Монолиту
Чтобы узнать внешний IP-адрес нашего монолитного приложения, выполните следующую команду.
kubectl get service monolith
В результате вы должны увидеть примерно следующий вывод:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
ПРИМЕЧАНИЕ: Для этого необходимо выделить внешний балансировщик нагрузки и IP-адрес, поэтому это займет некоторое время. Если в выводе указан внешний IP-адрес как
<pending> Подождите несколько минут и попробуйте снова.
После того, как вы определили внешний IP-адрес для вашего монолита, скопируйте его. Откройте этот URL-адрес в браузере (например, http://203.0.113.0), чтобы проверить, доступен ли ваш монолит.
Вы должны увидеть приветственную страницу монолитного веб-сайта, точно такую же, как на картинке выше. Приветственная страница — это статическая страница, которая будет позже обслуживаться микросервисом Frontend. Теперь ваш монолит полностью работает на Kubernetes!
6. Перенос заказов в микросервис.
Теперь, когда наш существующий монолитный веб-сайт работает на GKE, мы можем начать разбивать каждый сервис на микросервис. Как правило, необходимо заранее спланировать, какие сервисы разбить на более мелкие части, обычно вокруг конкретных частей приложения, таких как бизнес-домен. В качестве примера мы создали простой пример и разбили каждый сервис вокруг бизнес-домена, заказов, товаров и фронтенда. Код уже перенесен, и мы сосредоточимся на создании и развертывании сервисов на Google Kubernetes Engine (GKE).
Создание новых заказов (микросервис)
Первым сервисом, который мы рассмотрим отдельно, будет сервис заказов. Мы воспользуемся предоставленным отдельным кодом и создадим для этого сервиса отдельный контейнер Docker.
Создание контейнера Docker с помощью Google Cloud Build
Поскольку мы уже перенесли для вас код, первым шагом будет создание Docker-контейнера нашего сервиса Order с помощью Google Cloud Build.
Обычно для этого требуется двухэтапный подход, включающий создание контейнера Docker и его загрузку в реестр для хранения образа, из которого GKE сможет его получить. Но мы можем упростить задачу: мы можем использовать Google Cloud Build для создания контейнера Docker и размещения образа в реестре контейнеров Google Cloud одной командой! Это позволяет нам выполнить одну команду для сборки и перемещения нашего образа в реестр контейнеров. Чтобы посмотреть процесс создания файла Docker и его загрузки вручную, перейдите по этой ссылке .
Google Cloud Build сожмёт файлы из каталога и переместит их в хранилище Google Cloud Storage. Затем процесс сборки возьмёт все файлы из хранилища и использует Dockerfile для запуска процесса сборки Docker. Поскольку мы указали флаг --tag с хостом gcr.io для образа Docker, полученный образ Docker будет отправлен в реестр контейнеров Google Cloud.
Выполните следующие команды, чтобы создать контейнер Docker и отправить его в реестр контейнеров Google:
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
Этот процесс займет несколько минут, но после его завершения в терминале появится примерно следующий вывод:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
Чтобы просмотреть историю сборок или наблюдать за процессом в режиме реального времени, перейдите в консоль Google Cloud. Нажмите кнопку меню в левом верхнем углу, прокрутите вниз до раздела Инструменты → Cloud Build и нажмите История. Здесь вы увидите список всех ваших предыдущих сборок; должна быть только одна, которую вы только что создали.
Если вы щёлкнете по идентификатору сборки, вы сможете увидеть все подробности об этой сборке, включая вывод логов.
На странице сведений о сборке вы можете просмотреть созданный образ контейнера, щелкнув по названию образа в разделе информации о сборке.
Развертывание контейнера в GKE
Теперь, когда мы контейнеризировали наш веб-сайт и загрузили контейнер в реестр контейнеров Google, пришло время развернуть его в Kubernetes!
Kubernetes представляет приложения в виде Pod-ов , которые являются единицами, представляющими собой контейнер (или группу тесно связанных контейнеров). Pod — это наименьшая развертываемая единица в Kubernetes. В этом руководстве каждый Pod содержит только ваш контейнер микросервисов.
Для развертывания и управления приложениями в кластере GKE необходимо взаимодействовать с системой управления кластером Kubernetes. Обычно это делается с помощью инструмента командной строки kubectl в Cloud Shell.
Сначала мы создадим ресурс Deployment . Deployment управляет несколькими копиями вашего приложения, называемыми репликами, и планирует их запуск на отдельных узлах вашего кластера. В данном случае Deployment будет запускать только один Pod вашего приложения. Deployment обеспечивает это путем создания ReplicaSet . ReplicaSet отвечает за то, чтобы указанное количество реплик всегда работало.
Приведенная ниже команда kubectl create deployment заставляет Kubernetes создать развертывание с именем orders в вашем кластере с одной репликой.
Для развертывания приложения выполните следующую команду:
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
Проверка развертывания
Чтобы убедиться в успешном создании развертывания, выполните следующую команду; может потребоваться несколько секунд, чтобы статус пода изменился на «Работает»:
kubectl get all
Выход:
NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s
Этот вывод показывает нам несколько вещей. Мы видим наше развертывание, которое является текущим, наш ReplicaSet с желаемым количеством подов (1) и наш запущенный под. Похоже, все было успешно создано!
Предоставить доступ к контейнеру GKE
Мы развернули наше приложение в GKE, но у нас нет возможности получить к нему доступ извне кластера. По умолчанию контейнеры, запущенные в GKE, недоступны из Интернета, поскольку у них нет внешних IP-адресов. Вам необходимо явно предоставить доступ к вашему приложению для трафика из Интернета через ресурс Service . Service обеспечивает сетевую и IP-поддержку для подов вашего приложения. GKE создает внешний IP-адрес и балансировщик нагрузки ( в зависимости от тарификации ) для вашего приложения.
При развертывании нашего сервиса заказов мы открыли его для внутреннего доступа через порт 8081 с помощью развертывания Kubernetes. Для внешнего доступа к этому сервису нам необходимо создать сервис Kubernetes типа LoadBalancer, который будет перенаправлять трафик с внешнего порта 80 на внутренний порт 8081 для сервиса заказов. Выполните следующую команду, чтобы открыть доступ к вашему веб-сайту в Интернете:
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
Доступ к сервису
GKE назначает внешний IP-адрес ресурсу Service, а не Deployment. Чтобы узнать внешний IP-адрес, который GKE выделил для вашего приложения, вы можете проверить Service с помощью команды kubectl get service:
kubectl get service orders
Выход:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3d
После того, как вы определили внешний IP-адрес для вашего приложения, скопируйте его. Сохраните его для следующего шага, когда мы изменим наш монолит, чтобы он указывал на наш новый сервис заказов!
Реконфигурировать монолит
Поскольку мы удалили сервис Orders из монолита, нам придётся модифицировать монолит, чтобы он указывал на новый внешний микросервис Orders.
При разделении монолита мы удаляем фрагменты кода из одной кодовой базы и развертываем их по отдельности. Поскольку микросервис работает на другом сервере, мы больше не можем ссылаться на URL-адреса наших сервисов как на абсолютные пути; нам необходимо перенаправлять на новый адрес сервера нашего микросервиса Order. Обратите внимание, что это потребует некоторого простоя монолитного сервиса для обновления URL-адреса каждого выделенного сервиса. Это следует учитывать при планировании переноса ваших микросервисов и монолита в продакшн в процессе миграции микросервисов.
Нам необходимо обновить конфигурационный файл в нашем монолите, чтобы он указывал на новый IP-адрес микросервиса Orders. Используйте редактор nano, чтобы заменить локальный URL-адрес на IP-адрес нашего нового микросервиса Orders. Выполните следующую команду для редактирования файла.
cd ~/monolith-to-microservices/react-app nano .env.monolith
После открытия редактора ваш файл должен выглядеть примерно так:
REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products
Замените REACT_APP_ORDERS_URL на новый формат, указав при этом IP-адрес вашего микросервиса Orders, чтобы он соответствовал приведенному ниже примеру:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
Нажмите CTRL+O , затем ENTER , а затем CTRL+X чтобы сохранить файл в редакторе nano.
Вы можете протестировать свой новый микросервис, перейдя по URL-адресу, который вы только что указали в этом файле. Веб-страница должна вернуть JSON-ответ от нашего микросервиса «Заказы».
Далее нам потребуется пересобрать наш монолитный фронтенд и повторить процесс сборки, чтобы создать контейнер для монолита и повторно развернуть его в нашем кластере GKE. Выполните следующие команды и завершите эти шаги:
Пересобрать конфигурационные файлы монолита
npm run build:monolith
Создание контейнера Docker с помощью Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
Развертывание контейнера в GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
Вы можете убедиться, что ваше приложение теперь обращается к новому микросервису «Заказы», открыв в браузере монолитное приложение и перейдя на страницу «Заказы». Все идентификаторы заказов должны заканчиваться суффиксом -MICROSERVICE, как показано ниже:
7. Миграция продуктов на микросервисы
Создание новых продуктов на основе микросервисов
Далее мы можем продолжить разделение наших сервисов, перенеся на следующий этап сервис Products. Мы будем следовать тому же процессу, что и на предыдущем шаге. Выполните следующие команды, чтобы создать контейнер Docker, развернуть его и предоставить к нему доступ через сервис Kubernetes.
Создание контейнера Docker с помощью Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
Развертывание контейнера в GKE
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
Предоставить доступ к контейнеру GKE
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
Найдите публичный IP-адрес наших сервисов «Продукты» тем же способом, что и для сервиса «Заказы», с помощью следующей команды:
kubectl get service products
Выход:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
Сохраните IP-адрес для следующего шага, когда мы перенастроим наш монолит, чтобы он указывал на наш новый микросервис Products.
Реконфигурировать монолит
Воспользуйтесь редактором nano, чтобы заменить локальный URL-адрес на IP-адрес наших новых микросервисов Products:
cd ~/monolith-to-microservices/react-app nano .env.monolith
После открытия редактора ваш файл должен выглядеть примерно так:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
Замените REACT_APP_PRODUCTS_URL на новый формат, указав при этом IP-адрес вашего микросервиса продукта, чтобы он соответствовал приведенному ниже примеру:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
Нажмите CTRL+O , затем ENTER , а затем CTRL+X чтобы сохранить файл в редакторе nano.
Вы можете протестировать свой новый микросервис, перейдя по URL-адресу, который вы только что указали в этом файле. Веб-страница должна вернуть JSON-ответ от нашего микросервиса Products.
Далее нам потребуется пересобрать наш монолитный фронтенд и повторить процесс сборки, чтобы создать контейнер для монолита и повторно развернуть его в нашем кластере GKE. Выполните следующие команды и завершите эти шаги:
Пересобрать конфигурационные файлы монолита
npm run build:monolith
Создание контейнера Docker с помощью Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
Развертывание контейнера в GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
Вы можете убедиться, что ваше приложение теперь обращается к новому микросервису Products, открыв в браузере монолитное приложение и перейдя на страницу Products. Все названия продуктов должны начинаться с префикса MS-, как показано ниже:
8. Переход от фронтенда к микросервисам.
Последний шаг в процессе миграции — перенос кода фронтенда в микросервис и отключение монолита! После завершения этого шага мы успешно переведем наш монолит на микросервисную архитектуру!
Создать новый фронтенд-микросервис
Давайте выполним ту же процедуру, что и в двух предыдущих шагах, чтобы создать новый микросервис для фронтенда.
Ранее, при пересборке нашего монолита, мы обновили конфигурацию, чтобы она указывала на наш монолит, но теперь нам нужно использовать ту же конфигурацию для нашего микросервиса Frontend. Выполните следующие команды, чтобы скопировать файлы конфигурации URL-адресов наших микросервисов в кодовую базу микросервиса Frontend:
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
После этого мы повторим те же шаги, что и в предыдущих. Выполните следующие команды, чтобы создать контейнер Docker, развернуть его и сделать доступным через сервис Kubernetes.
Создание контейнера Docker с помощью Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
Развертывание контейнера в GKE
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
Предоставить доступ к контейнеру GKE
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
Удалить монолит
Теперь, когда все наши сервисы работают как микросервисы, мы можем удалить наше монолитное приложение! Обратите внимание, что при реальной миграции это также повлечет за собой изменения DNS и т. д., чтобы наши существующие доменные имена указывали на новые микросервисы фронтенда для нашего приложения. Выполните следующие команды, чтобы удалить наше монолитное приложение:
kubectl delete deployment monolith kubectl delete service monolith
Проверьте свою работу
Чтобы убедиться, что всё работает, ваш старый IP-адрес от монолитного сервиса не должен работать, а новый IP-адрес от фронтенд-сервиса должен размещать новое приложение. Чтобы увидеть список всех сервисов и IP-адресов, используйте следующую команду:
kubectl get services
Результат должен выглядеть примерно так:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m
После того, как вы определили внешний IP-адрес для вашего фронтенд-микросервиса, скопируйте его. Откройте этот URL-адрес в браузере (например, http://203.0.113.0), чтобы проверить доступность вашего фронтенда. Ваш веб-сайт должен остаться таким же, каким он был до того, как мы разделили монолит на микросервисы!
9. Уборка
После завершения проекта самый простой способ удалить все выполненные действия — это его удалить. Удаление проекта удалит все ресурсы, созданные в рамках этого практического занятия, чтобы избежать непредвиденных повторных расходов. Выполните следующие действия в Cloud Shell, где PROJECT_ID — это полный идентификатор проекта, а не только его название.
gcloud projects delete [PROJECT_ID]
Подтвердите удаление, введя "Y" при появлении соответствующего запроса.
10. Поздравляем!
Вы успешно разбили свое монолитное приложение на микросервисы и развернули их на Google Kubernetes Engine!
Следующие шаги
Ознакомьтесь со следующими практическими занятиями, чтобы узнать больше о Kubernetes:
- Развертывайте, масштабируйте и обновляйте свой веб-сайт на Google Kubernetes Engine.
- Создайте бота для Slack на Node.js в Kubernetes.
- Непрерывная доставка в Kubernetes с использованием Spinnaker
- Разверните Java-приложение в Kubernetes на Google Kubernetes Engine.
Дополнительные ресурсы
- Docker - https://docs.docker.com/
- Kubernetes - https://kubernetes.io/docs/home/
- Google Kubernetes Engine (GKE) – https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build — https://cloud.google.com/cloud-build/docs/
- Реестр контейнеров Google — https://cloud.google.com/container-registry/docs/
- Миграция монолитных приложений в микросервисы - https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke