Непрерывное развертывание в Google Kubernetes Engine (GKE) с Cloud Build.

1. Обзор

В ходе этой лабораторной работы вы научитесь настраивать конвейер непрерывной доставки для GKE с помощью Cloud Build. В этой лабораторной работе показано, как запускать задания Cloud Build для различных событий git, а также простой шаблон для автоматических выпусков canary в GKE.

Вы выполните следующие шаги:

• Создайте приложение GKE
• Автоматизируйте развертывание веток git
• Автоматизация развертываний для основной ветки git
• Автоматизируйте развертывание тегов git

2. Прежде чем начать

Для работы с этим справочным руководством вам понадобится проект Google Cloud. Вы можете создать новый или выбрать уже созданный проект:

1. Выберите или создайте проект Google Cloud.

ПЕРЕЙДИТЕ НА СТРАНИЦУ ВЫБОРА ПРОЕКТОВ

1. Включите биллинг для вашего проекта.

ВКЛЮЧИТЬ БИЛЛИНГ

3. Подготовка среды

1. Создайте переменные среды, которые будут использоваться в этом руководстве:

   export PROJECT_ID=$(gcloud config get-value project)
   export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
   
   export ZONE=us-central1-b
   export CLUSTER=gke-progression-cluster
   export APP_NAME=myapp
   

2. Включите следующие API:
   • Менеджер ресурсов
   • ГКЭ
   • Облачные репозитории исходного кода
   • Облачная сборка
   • Реестр контейнеров

   gcloud services enable \
       cloudresourcemanager.googleapis.com \
       container.googleapis.com \
       sourcerepo.googleapis.com \
       cloudbuild.googleapis.com \
       containerregistry.googleapis.com \
       --async
   

3. Клонируйте исходный код образца и переключитесь в каталог лаборатории:

   git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git gke-progression
   
   cd gke-progression/labs/gke-progression
   rm -rf ../../.git
   

4. Замените значения-заполнители в образце репозитория на свой PROJECT_ID . На этом этапе вы создаете экземпляры различных файлов конфигурации, уникальные для вашей текущей среды. Чтобы просмотреть пример обновляемых шаблонов, выполните следующую команду.

   cat k8s/deployments/dev/frontend-dev.yaml.tmpl
   

   Выполните замену переменной, выполнив команду Followign.

   for template in $(find . -name '*.tmpl'); do envsubst '${PROJECT_ID} ${ZONE} ${CLUSTER} ${APP_NAME}' < ${template} > ${template%.*}; done
   

   Чтобы просмотреть пример файла после замены, выполните следующую команду.

   cat k8s/deployments/dev/frontend-dev.yaml
   

5. Если вы ранее не использовали Git в Cloud Shell, задайте значения user.name и user.email , которые вы хотите использовать:

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_USERNAME"
   

6. Сохраните код из примера репозитория в облачных репозиториях исходного кода:

   gcloud source repos create gke-progression
   git init
   git config credential.helper gcloud.sh
   git remote add gcp https://source.developers.google.com/p/$PROJECT_ID/r/gke-progression
   git branch -m main
   git add . && git commit -m "initial commit"
   git push gcp main
   

7. Создайте кластер GKE.

   gcloud container clusters create ${CLUSTER} \
       --project=${PROJECT_ID} \
       --zone=${ZONE}
   

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

   gcloud projects add-iam-policy-binding ${PROJECT_ID} \
       --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
       --role=roles/container.developer
   

Ваша среда готова!

4. Создание приложения GKE

В этом разделе вы создадите и развернете исходное производственное приложение, которое будете использовать в этом руководстве.

1. Создайте приложение с помощью Cloud Build:

   gcloud builds submit --tag gcr.io/$PROJECT_ID/$APP_NAME:1.0.0 src/
   

2. Развертывание вручную в средах Canary и Production: создайте рабочие и Canary-развертывания и сервисы с помощью команд kubectl apply .

   kubectl create ns production
   kubectl apply -f k8s/deployments/prod -n production
   kubectl apply -f k8s/deployments/canary -n production
   kubectl apply -f k8s/services -n production
   

   Развернутая здесь служба будет маршрутизировать трафик как на канареечное, так и на производственное развертывание.
3. Проверьте количество запущенных модулей. Убедитесь, что у вас есть четыре модуля, работающие для внешнего интерфейса, в том числе три для производственного трафика и один для канареечных выпусков. Это означает, что изменения в вашей канареечной версии затронут только 1 из 4 (25%) пользователей.

   kubectl get pods -n production -l app=$APP_NAME -l role=frontend
   

4. Получите внешний IP-адрес для производственных служб.

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

   kubectl get service $APP_NAME -n production
   

   Как только балансировщик нагрузки вернет IP-адрес, перейдите к следующему шагу.
5. Сохраните внешний IP-адрес для дальнейшего использования.

   export PRODUCTION_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}"  --namespace=production services $APP_NAME)
   

6. Просмотрите приложение. Проверьте вывод версии службы. Должно быть написано Hello World v1.0.

   curl http://$PRODUCTION_IP
   

Поздравляем! Вы развернули пример приложения! Далее вы настроите триггеры для постоянного развертывания изменений.

5. Автоматизация развертываний для веток git

В этом разделе вы настроите триггер, который будет выполнять задание Cloudbuild при фиксации любой ветки, кроме main . Используемый здесь файл Cloud Build автоматически создаст пространство имен и развертывание для любых существующих или новых веток, что позволит разработчикам предварительно просмотреть свой код перед интеграцией с основной веткой.

1. Настройте триггер. Ключевым компонентом этого триггера является использование параметра branchName для соответствия main и параметра invertRegex , для которого установлено значение true и изменяет шаблон branchName , чтобы он соответствовал всему, что не является main . Для справки вы можете найти следующие строки в build/branch-trigger.json .

     "branchName": "main",
     "invertRegex": true
   

   Кроме того, последние несколько строк файла Cloud Build, используемые с этим триггером, создают пространство имен, названное в честь ветки, вызвавшей задание, а затем развертывают приложение и службу в новом пространстве имен. Для справки вы можете найти следующие строки в build/branch-cloudbuild.yaml

     kubectl get ns ${BRANCH_NAME} || kubectl create ns ${BRANCH_NAME}
     kubectl apply --namespace ${BRANCH_NAME} --recursive -f k8s/deployments/dev
     kubectl apply --namespace ${BRANCH_NAME} --recursive -f k8s/services
   

   Теперь, когда вы понимаете используемые механизмы, создайте триггер с помощью приведенной ниже команды gcloud.

   gcloud beta builds triggers create cloud-source-repositories \
     --trigger-config build/branch-trigger.json
   

2. Чтобы просмотреть триггер, перейдите на страницу «Триггеры Cloud Build» в консоли. Перейти к триггерам
3. Создайте новую ветку:

   git checkout -b new-feature-1
   

4. Измените код, указав версию 1.1. Отредактируйте src/app.py и измените ответ с 1,0 на 1,1.

   @app.route('/')
   def hello_world():
       return 'Hello World v1.1'
   

5. Зафиксируйте изменение и отправьте его в удаленный репозиторий:

   git add . && git commit -m "updated" && git push gcp new-feature-1
   

6. Чтобы просмотреть ход сборки, перейдите на страницу «История сборок облака» в консоли. Перейти к сборкам. После завершения сборки перейдите к следующему шагу.
7. Получите внешний IP-адрес для вновь развернутой службы филиала.

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

   kubectl get service $APP_NAME -n new-feature-1
   

   Как только балансировщик нагрузки вернет IP-адрес, перейдите к следующему шагу.
8. Сохраните внешний IP-адрес для дальнейшего использования.

   export BRANCH_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}"  --namespace=new-feature-1 services $APP_NAME)
   

9. Просмотрите приложение. Проверьте вывод версии службы. Должно быть написано Hello World v1.0.

   curl http://$BRANCH_IP
   

6. Автоматизация развертывания основной ветки git.

Прежде чем код будет выпущен в рабочую среду, обычно его выпускают для небольшого подмножества активного трафика, а затем переносят весь трафик в новую базу кода.

В этом разделе вы реализуете триггер, который активируется, когда код фиксируется в основной ветке. Триггер развертывает канареечное развертывание, которое получает 25 % всего текущего трафика в новую версию.

1. Настройте триггер для основной ветки:

   gcloud beta builds triggers create cloud-source-repositories \
     --trigger-config build/main-trigger.json
   

2. Чтобы просмотреть новый триггер, перейдите на страницу «Триггеры Cloud Build» в консоли. Перейти к триггерам
3. Объедините ветку с основной строкой и отправьте ее в удаленный репозиторий:

   git checkout main
   git merge new-feature-1
   git push gcp main
   

4. Чтобы просмотреть ход сборки, перейдите на страницу «История сборок облака» в консоли. Перейти к сборкам. После завершения сборки перейдите к следующему шагу.
5. Просмотрите несколько ответов от сервера. Выполните следующую команду и обратите внимание, что примерно 25% ответов показывают новый ответ Hello World v1.1.

   while true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1;  done
   

   Когда вы будете готовы продолжить, нажмите Ctrl+c , чтобы выйти из цикла.

7. Автоматизация развертывания тегов git

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

В этом разделе вы настраиваете триггер, который активируется при создании тега в репозитории. Триггер помечает изображение соответствующим тегом, а затем развертывает обновления в продукте, гарантируя, что 100 % трафика обращается к изображению с тегом.

1. Настройте триггер тега:

   gcloud beta builds triggers create cloud-source-repositories \
     --trigger-config build/tag-trigger.json
   

2. Чтобы просмотреть новый триггер, перейдите на страницу «Триггеры Cloud Build» в консоли. Перейти к триггерам
3. Создайте новый тег и отправьте его в удаленный репозиторий:

   git tag 1.1
   git push gcp 1.1
   

4. Чтобы просмотреть ход сборки, перейдите на страницу «История сборок облака» в консоли. Перейти в Сборки
5. Просмотрите несколько ответов от сервера. Выполните следующую команду и обратите внимание, что 100% ответов отображают новый ответ Hello World v1.1. Это может занять некоторое время, поскольку новые модули развертываются и проверяются работоспособность в GKE.

   while true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1;  done
   

   Когда вы будете готовы продолжить, нажмите Ctrl+c , чтобы выйти из цикла. Поздравляем! Вы создали триггеры CI/CD в Cloud Build для ветвей и тегов для развертывания ваших приложений в GKE.

8. Очистка

Удалить проект

Внимание: Удаление проекта имеет следующие последствия: Все в проекте будет удалено. Если для этого руководства вы использовали существующий проект, то при его удалении вы также удаляете всю другую работу, выполненную в проекте.

1. В Cloud Console перейдите на страницу «Управление ресурсами» .
2. В списке проектов выберите проект, который хотите удалить, и нажмите «Удалить» .
3. В диалоговом окне введите идентификатор проекта, а затем нажмите «Завершить работу» , чтобы удалить проект.