1. Введение
Зачем переходить от монолитного приложения к архитектуре микросервисов? Разбиение приложения на микросервисы имеет следующие преимущества: большинство из них связано с тем, что микросервисы слабо связаны.
- Микросервисы можно тестировать и развертывать независимо. Чем меньше единица развертывания, тем проще развертывание.
- Они могут быть реализованы на разных языках и платформах. Для каждого микросервиса вы можете выбрать лучшую технологию для конкретного случая использования.
- Ими могут управлять разные команды. Граница между микросервисами упрощает выделение команды для одного или нескольких микросервисов.
- Переходя на микросервисы, вы ослабляете зависимости между командами. Каждой команде приходится заботиться только об API микросервисов, от которых они зависят. Команде не нужно думать о том, как эти микросервисы реализованы, о циклах их выпуска и так далее.
- Вам будет легче спроектировать неудачу. Имея четкие границы между службами, легче определить, что делать, если служба не работает.
Некоторые недостатки по сравнению с монолитами:
- Поскольку приложение на основе микросервиса представляет собой сеть различных сервисов, которые часто взаимодействуют неочевидным образом, общая сложность системы имеет тенденцию к росту.
- В отличие от внутреннего устройства монолита, микросервисы взаимодействуют по сети. В некоторых обстоятельствах это можно рассматривать как проблему безопасности. Istio решает эту проблему, автоматически шифруя трафик между микросервисами.
- Может быть сложно достичь того же уровня производительности, что и при монолитном подходе, из-за задержек между сервисами.
- Поведение вашей системы определяется не одной службой, а многими из них и их взаимодействием. Из-за этого понять, как ваша система ведет себя в продакшене (ее наблюдаемость), сложнее. Istio также является решением этой проблемы.
В этой лабораторной работе мы будем запускать микросервисы в Google Kubernetes Engine (GKE). Kubernetes — это платформа для управления, размещения, масштабирования и развертывания контейнеров. Контейнеры — это портативный способ упаковки и запуска кода. Они хорошо подходят для шаблона микросервисов, где каждый микросервис может работать в своем собственном контейнере.
В рамках этой лабораторной работы мы развернем существующее монолитное приложение в кластере Google Kubernetes Engine, а затем разобьем его на микросервисы!
Схема архитектуры наших микросервисов
Начнем с того, что разобьем наш монолит на три микросервиса, по одному за раз. К микросервисам относятся заказы, продукты и интерфейс. Мы создаем образ 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 ) и создайте новый проект:
Запомните идентификатор проекта — уникальное имя для всех проектов 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 Cloud, что значительно повышает производительность сети и аутентификацию. Это означает, что все, что вам понадобится для этой лаборатории кода, — это браузер (да, он работает на 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 ? Узнайте, какой идентификатор вы использовали на этапах настройки, или найдите его на панели управления 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-адрес для своего монолита, скопируйте IP-адрес. Направьте свой браузер на этот URL-адрес (например, http://203.0.113.0), чтобы проверить, доступен ли ваш монолит.
Вы должны увидеть страницу приветствия монолитного веб-сайта, как на картинке выше. Страница приветствия — это статическая страница, которая позже будет обслуживаться микросервисом Frontend. Теперь ваш монолит полностью работает в Kubernetes!
6. Перенос заказов в микросервис
Теперь, когда у нас есть существующий монолитный веб-сайт, работающий на GKE, мы можем начать разбивать каждый сервис на микросервис. Как правило, необходимо спланировать, какие службы разбить на более мелкие фрагменты, обычно вокруг конкретных частей приложения, например бизнес-сферы. В демонстрационных целях мы создали тривиальный пример и разбили каждую службу по бизнес-сфере: заказы, продукты и интерфейс. Код уже перенесен, и мы сосредоточимся на создании и развертывании сервисов в Google Kubernetes Engine (GKE).
Микросервис создания новых заказов
Первая услуга, которую мы представим, — это служба «Заказы». Мы воспользуемся отдельной предоставленной кодовой базой и создадим отдельный контейнер Docker для этого сервиса.
Создайте Docker-контейнер с помощью Google Cloud Build
Поскольку мы уже перенесли для вас кодовую базу, нашим первым шагом будет создание Docker-контейнера нашей службы заказов с помощью Google Cloud Build.
Обычно вам придется применить двухэтапный подход, который влечет за собой создание Docker-контейнера и отправку его в реестр для хранения образа, из которого GKE сможет извлечь данные. Но мы можем облегчить жизнь: мы можем использовать Google Cloud Build для создания Docker-контейнера и поместить его в реестр Google Cloud Container с помощью одной команды! Это позволяет нам выполнить одну команду для сборки и перемещения нашего образа в реестр контейнеров. Чтобы просмотреть ручной процесс создания файла 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. Нажмите кнопку меню в левом верхнем углу, прокрутите вниз до «Инструменты» → «Создание облака» и нажмите «История». Здесь вы можете увидеть список всех ваших предыдущих сборок, должна быть только одна, которую вы только что создали.
Если вы щелкнете по идентификатору сборки, вы увидите все подробности этой сборки, включая выходные данные журнала.
На странице сведений о сборке вы можете просмотреть созданный образ контейнера, щелкнув имя образа в разделе информации о сборке.
Развертывание контейнера в GKE
Теперь, когда мы контейнеризировали наш веб-сайт и поместили его в реестр контейнеров Google, пришло время развернуть его в Kubernetes!
Kubernetes представляет приложения как Pods — модули, представляющие контейнер (или группу тесно связанных контейнеров). Pod — это самая маленькая развертываемая единица в Kubernetes. В этом руководстве каждый модуль содержит только контейнер микросервисов.
Для развертывания приложений и управления ими в кластере GKE необходимо взаимодействовать с системой управления кластером Kubernetes. Обычно это делается с помощью инструмента командной строки kubectl из Cloud Shell.
Сначала мы создадим ресурс развертывания . Развертывание управляет несколькими копиями вашего приложения, называемыми репликами, и планирует их запуск на отдельных узлах вашего кластера. В этом случае при развертывании будет запущен только один модуль вашего приложения. Развертывания обеспечивают это путем создания ReplicaSet . ReplicaSet отвечает за то, чтобы указанное количество реплик всегда работало.
Приведенная ниже команда kubectl create deployment заставляет Kubernetes создать в вашем кластере развертывание с именем Orders с 1 репликой.
Запустите следующую команду, чтобы развернуть приложение:
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-адресов. Вы должны явно предоставить своему приложению доступ к трафику из Интернета через ресурс службы . Служба обеспечивает поддержку сети и IP для модулей вашего приложения. GKE создает внешний IP-адрес и балансировщик нагрузки ( при условии оплаты ) для вашего приложения.
Когда мы развернули нашу службу Orders, мы открыли ее через порт 8081 внутри компании через развертывание Kubernetes. Чтобы предоставить доступ к этой службе извне, нам нужно создать службу Kubernetes типа LoadBalancer для маршрутизации трафика с порта 80 извне на внутренний порт 8081 для службы Orders. Запустите следующую команду, чтобы открыть доступ к вашему веб-сайту из Интернета:
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
Доступ к услуге
GKE назначает внешний IP-адрес ресурсу службы, а не развертыванию. Если вы хотите узнать внешний IP-адрес, предоставленный GKE для вашего приложения, вы можете проверить Службу с помощью команды 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-адрес для своего приложения, скопируйте 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 от нашего микросервиса Orders.
Далее нам нужно будет перестроить наш монолитный интерфейс и повторить процесс сборки, чтобы построить контейнер для монолита и повторно развернуть его в нашем кластере GKE. Выполните следующие команды, чтобы завершить эти шаги:
Восстановить файлы конфигурации Monolith
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
Вы можете убедиться, что ваше приложение теперь использует новый микросервис Orders, перейдя в монолитное приложение в браузере и перейдя на страницу Orders. Все идентификаторы заказов должны заканчиваться суффиксом -MICROSERVICE, как показано ниже:
7. Миграция продуктов на микросервис
Создание новых продуктов Микросервис
Мы можем продолжить развитие наших услуг, перенеся сервис «Продукты». Мы будем следовать тому же процессу, что и предыдущий шаг. Выполните следующие команды, чтобы создать контейнер 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-адрес для следующего шага, когда мы переконфигурируем наш монолит, чтобы он указывал на наш новый микросервис «Продукты».
Переконфигурировать Монолит
Используйте редактор nano, чтобы заменить локальный URL-адрес IP-адресом наших новых микросервисов продуктов:
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 от нашего микросервиса продуктов.
Далее нам нужно будет перестроить наш монолитный интерфейс и повторить процесс сборки, чтобы построить контейнер для монолита и повторно развернуть его в нашем кластере GKE. Выполните следующие команды, чтобы завершить эти шаги:
Восстановить файлы конфигурации Monolith
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
Вы можете убедиться, что ваше приложение теперь использует новый микросервис «Продукты», перейдя к монолитному приложению в браузере и перейдя на страницу «Продукты». Все названия продуктов должны начинаться с префикса 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-адрес для вашей внешней микрослужбы, скопируйте IP-адрес. Направьте свой браузер на этот URL-адрес (например, http://203.0.113.0), чтобы проверить, доступен ли ваш интерфейс. Ваш сайт должен быть таким же, каким был до того, как мы разбили монолит на микросервисы!
9. Очистка
Когда все будет готово, самый простой способ очистить все выполненные действия — удалить проект. При удалении проекта удаляются все ресурсы, созданные в рамках этой Codelab, чтобы исключить возникновение непредвиденных периодических расходов. Выполните следующую команду в 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
Дополнительные ресурсы
- Докер — https://docs.docker.com/
- Кубернетес — 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