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

1. Обзор

В этой лабораторной работе вы научитесь настраивать конвейер непрерывной доставки для GKE с помощью Cloud Build. В работе будет показано, как запускать задания Cloud Build для различных событий Git, а также представлен простой шаблон для автоматизированных канареечных релизов в 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:
   • Менеджер ресурсов
   • ГКЕ
   • Облачные репозитории исходного кода
   • Cloud Build
   • Реестр контейнеров

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

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

   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
   

   Выполните подстановку переменных, выполнив следующую команду.

   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. Сохраните код из репозитория примеров в Cloud Source Repositorys:

   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. Ручное развертывание в канареечную и производственную среды: создайте развертывания и службы для производственной и канареечной среды с помощью команд 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
   

   Развернутый здесь сервис будет направлять трафик как на тестовую (canary), так и на производственную (prod) версии.
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 . Используемый здесь файл CloudBuild автоматически создаст пространство имен и развертывание для любых существующих или новых веток, что позволит разработчикам предварительно просмотреть свой код перед интеграцией с основной веткой.

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 перейдите на страницу «Управление ресурсами» .
2. В списке проектов выберите проект, который хотите удалить, и нажмите кнопку «Удалить» .
3. В диалоговом окне введите идентификатор проекта, а затем нажмите «Завершить» , чтобы удалить проект.