Упражнение. Развертывание решения с несколькими контейнерами в кластере Kubernetes

Завершено

Конвейер выпуска, предоставленный проектом, предназначен для создания решения в качестве контейнера Docker и его развертывания в Службе приложений Azure. Для поддержки развертывания нескольких контейнеров в кластере Kubernetes необходимо изменить этот конвейер.

В этом уроке вы узнаете, как:

• Обновите конвейер, чтобы запускаться при фиксации в основной ветке.
• Определите переменные для совместного использования в конвейере.
• Создание и публикация образов Docker.
• Публикация манифестов Kubernetes.
• Добавьте задачу для создания секрета извлечения образа для использования между экземплярами kubernetes и реестра контейнеров.
• Разверните обновленные образы в кластере Kubernetes.

Обновление конвейера для поддержки триггеров

1. Войдите в организацию Azure DevOps и перейдите к проекту.

2. Выберите Конвейер, а затем выберите ваш конвейер.

3. Выберите Правка, чтобы изменить файл azure-pipelines.yml.

   Энди: Это был этап сборки, который мы имели на месте для предыдущего решения с одним контейнером. Я знал, что это не будет работать должным образом, так что я отключил его. Мы можем начать с повторного включения триггеров фиксаций в ветке main.

4. Замените существующую строку trigger в верхней части файла следующим фрагментом кода. Это запускает запуск конвейера каждый раз, когда производится коммит в основную ветку.

   trigger:
   - 'main'
   

Определение переменных, доступных в конвейере

Энди: Нам потребуется добавить две переменные конвейера. Для указания имени репозитория таблицы лидеров, который является . Другой — название секрета извлечения образа, используемого для совместного доступа между экземплярами AKS и ACR во время развертывания.

1. Добавьте следующий выделенный код в раздел variables.

   variables:
     buildConfiguration: 'Release'
     leaderboardRepository: 'leaderboard'
     webRepository: 'web'
     tag: '$(Build.BuildId)'
     imagePullSecret: 'secret'
   

Создание и публикация образа Docker в реестре контейнеров Azure

Энди: У нас уже есть задача по созданию веб-приложения в качестве контейнера Docker, который мы публикуем в реестре контейнеров. Мы можем просто использовать вторую задачу, чтобы сделать то же самое для нашей таблицы лидеров.

1. Добавьте вторую Docker@2 задачу для сборки и публикации контейнера таблицы лидеров с помощью следующего выделенного фрагмента кода. Добавьте эту задачу сразу после задачи веб-контейнера.

   - task: Docker@2
     displayName: 'Build and push the web image to container registry'
     inputs:
       command: buildAndPush
       buildContext: $(Build.Repository.LocalPath)
       repository: $(webRepository)
       dockerfile: '$(Build.SourcesDirectory)/Tailspin.SpaceGame.Web/Dockerfile'
       containerRegistry: 'Container Registry Connection'
       tags: |
         $(tag)
   
   - task: Docker@2
     displayName: 'Build and push the leaderboard image to container registry'
     inputs:
       command: buildAndPush
       buildContext: $(Build.Repository.LocalPath)
       repository: $(leaderboardRepository)
       dockerfile: '$(Build.SourcesDirectory)/Tailspin.SpaceGame.LeaderboardContainer/Dockerfile'
       containerRegistry: 'Container Registry Connection'
       tags: |
         $(tag)
   

Совет

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

Публикация манифестов Kubernetes

Энди: я думаю, что мы можем перейти к следующему этапу. Вы видите что-нибудь недостающее?

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

Энди: Нужно ли нам? Они разве по-прежнему не будут на локальном диске?

Мара: Они были бы, если бы мы добавили задачи развертывания на том же этапе, что и сборка. Однако так как наши задачи развертывания выполняются в собственном этапе развертывания, он выполняется в новой среде, вероятно, даже на другом агенте. Мы должны быть уверены, что публикуем всё, что создаёт этот этап и в чём нуждается другой этап.

Энди: Это отличная точка. Это легко сделать? Нам нужно просто удостовериться, что папка манифестов , скопирована на нового агента.

Мара: Вот для чего существует задача PublishBuildArtifacts@1. Это так распространено, что даже есть сокращение для этого, publish.

1. Добавьте задачу publish, в которой хранятся манифесты для следующего этапа, как показано в следующем фрагменте кода. Убедитесь, что отступ этой задачи соответствует отступу предыдущей задачи.

   - task: Docker@2
     displayName: 'Build and push the leaderboard image to container registry'
     inputs:
       command: buildAndPush
       buildContext: $(Build.Repository.LocalPath)
       repository: $(leaderboardRepository)
       dockerfile: '$(Build.SourcesDirectory)/Tailspin.SpaceGame.LeaderboardContainer/Dockerfile'
       containerRegistry: 'Container Registry Connection'
       tags: |
         $(tag)
   
   - publish: '$(Build.SourcesDirectory)/manifests'
     artifact: manifests
   

Замена этапа развертывания

Мара: я собираюсь заменить наш существующий этап Deploy на один, использующий задание развертывания. Задание развертывания — это специальное задание, которое позволяет связать развертывание с созданной ранее средой Azure DevOps. Это упрощает отслеживание истории развертывания, что будет особенно полезно по мере того, как наши решения становятся более сложными.

1. Удалите существующий этап Deploy (все, что идет после этапа сборки) и замените его следующим фрагментом. Обратите внимание на выделенную строку, указывающую среду развертывания, которая будет использоваться.

   - stage: 'Deploy'
     displayName: 'Deploy the containers'
     dependsOn: Build
     jobs:
     - deployment: Deploy
       displayName: Deploy
       pool:
         vmImage: 'ubuntu-20.04'
       environment: 'Dev'
       variables:
       - group: Release
       strategy:
         runOnce:
           deploy:
             steps:
   

   Мара: Первым шагом, который мы добавим на этапе развертывания, будет скачивание артефактов манифеста, опубликованных ранее с помощью задачи DownloadBuildArtifacts@0.

   Энди: Позвольте мне догадаться, есть ли download сокращение для этой задачи?

   Мара: Совершенно верно! Можно воспользоваться спецификатором current, чтобы указать, что мы хотим артефакт из текущего запуска конвейера.

2. Добавьте выделенные строки в качестве первого шага этапа развертывания.

   - stage: 'Deploy'
     displayName: 'Deploy the containers'
     dependsOn: Build
     jobs:
     - deployment: Deploy
       displayName: Deploy
       pool:
         vmImage: 'ubuntu-20.04'
       environment: 'spike.default'
       variables:
       - group: Release
       strategy:
         runOnce:
           deploy:
             steps:
             - download: current
               artifact: manifests
   

   Энди: Теперь нам нужно создать секрет для загрузки образов, который будет совместно использоваться между нашими экземплярами ACR и AKS. Знаете ли вы, есть ли задача, которую можно использовать?

   Мара: Я только что искала это, и нам повезло. Задача KubernetesManifest@0 поддерживает действие для создания необходимого секрета.

Задача манифеста Kubernetes

Задача манифеста Kubernetes предназначена для управления всеми основными операциями развертывания, необходимыми для Kubernetes. Он поддерживает несколько опций action, которые варьируются от создания секретов до развертывания образов. В этом случае используется действие createSecret вместе со следующими параметрами:

• action указывает функцию для запуска. В этом случае createSecret создает общий секрет.
• connectionType указывает тип используемого подключения к службе. Варианты: azureResourceManager или kubernetesServiceConnection.
• secretName указывает имя создаваемого секрета.
• dockerRegistryEndpoint указывает имя подключения служб реестра контейнеров Azure.
• azureSubscriptionConnection указывает имя подключения служб ARM.
• azureResourceGroup указывает имя группы ресурсов.
• kubernetesCluster указывает имя кластера AKS.
• namespace указывает пространство имен Kubernetes, к которому применяется это действие.

1. Добавьте следующий фрагмент кода в конец конвейера. Убедитесь, что имя группы ресурсов и имя кластера совпадают с именами тех, которые вы создали ранее. Убедитесь, что форматирование этой задачи соответствует форматированию задачи скачивания .

   - task: KubernetesManifest@1
     displayName: Create imagePullSecret
     inputs:
       action: createSecret
       connectionType: azureResourceManager
       secretName: $(imagePullSecret)
       dockerRegistryEndpoint: 'Container Registry Connection'
       azureSubscriptionConnection: 'Kubernetes Cluster Connection'
       azureResourceGroup: 'tailspin-space-game-rg'
       kubernetesCluster: 'tailspinspacegame-24591'
       namespace: 'default'
   

   Энди: Последний шаг — инициировать развертывание образов в кластере Kubernetes. На основе документации мы можем использовать ту же задачу, но с другим действием и параметрами.

   • action указывает функцию для запуска. В этом случае необходимо развернуть deploy в кластере AKS.
   • connectionType указывает тип используемого подключения к службе. Параметры: AzureResourceManager или KubernetesServiceConnection.
   • azureSubscriptionConnection указывает имя подключения служб ARM.
   • azureResourceGroup указывает имя группы ресурсов.
   • kubernetesCluster указывает имя кластера AKS.
   • namespace указывает пространство имен Kubernetes, к которому применяется это действие.
   • imagePullSecrets указывает список секретов, необходимых для извлечения из реестра контейнеров.
   • containers указывает список образов контейнеров для развертывания.

2. Добавьте следующий фрагмент кода в конец конвейера. Убедитесь, что имя группы ресурсов и имя кластера соответствуют именам тех, которые вы создали ранее. Убедитесь, что отступ этой задачи совпадает с отступом предыдущей задачи.

   - task: KubernetesManifest@1
     displayName: Deploy to Kubernetes cluster
     inputs:
       action: deploy
       connectionType: azureResourceManager
       azureSubscriptionConnection: 'Kubernetes Cluster Connection'
       azureResourceGroup: 'tailspin-space-game-rg'
       kubernetesCluster: 'tailspinspacegame-24591'
       namespace: 'default'
       manifests: |
         $(Pipeline.Workspace)/manifests/deployment.yml
         $(Pipeline.Workspace)/manifests/service.yml
       imagePullSecrets: |
         $(imagePullSecret)
       containers: |
         $(RegistryName)/$(webRepository):$(tag)
         $(RegistryName)/$(leaderboardRepository):$(tag)
   

Запуск конвейера

1. Выберите Сохранить в правом верхнем углу страницы. Выберите Сохранить, чтобы подтвердить сообщение о фиксации.

2. Выберите Запустить, подтвердите имя ветви и выберите Запустить для запуска конвейера.

3. Выберите Конвейеры задач, а затем выберите свой конвейер, чтобы просмотреть журналы в процессе выполнения конвейера.

4. После завершения выполнения конвейера выберите среды в левой области, а затем выберите среду Dev для просмотра заданий развертывания.

5. Теперь давайте проверим наше развернутое веб-приложение и конечную точку API. Для этого необходимо получить внешние IP-адреса для веб- и служб таблицы лидеров.

6. Перейдите на портал Azure, выберите кластер AKS, а затем выберите службы и входящий трафик.

   

7. Выберите внешний IP-адрес для вашей веб-службы, чтобы просмотреть ваш сайт в AKS.

   

8. Вернитесь к окну портала Azure, на котором вы остановились, и затем скопируйте внешний IP для службы таблицы лидеров. Этот IP-адрес, где размещён API таблицы лидеров для общего доступа.

9. Замените заполнитель в следующей ссылке на скопированный внешний IP-адрес. Вы также можете добавить параметр запроса pageSize=10, чтобы упростить просмотр ответа JSON в браузере. Используйте URL-адрес, как показано ниже, на новой вкладке браузера.

   http://[IP]/api/Leaderboard?pageSize=10
   

10. Необработанный ответ JSON можно просмотреть из API таблицы лидеров, размещенного в кластере AKS. Теперь у вас есть REST API, который можно вызвать из других приложений.

    

Энди: Это оказалось здорово! Я думаю, что использование Kubernetes было бы отличным способом для нас принять более широкую стратегию микрослужб.