Share:

Kishan Gohil et Evdokia Pilavaki montrent comment déployer une application conteneurisée avec Azure Kubernetes Service.

Les applications Cloud conteneurisées sont devenues une tendance récente et un sujet intéressant au sein de la communauté du développement Cloud au cours des dernières années. Les conteneurs présentent des avantages considérables par rapport à certaines pratiques traditionnelles de développement d’applications, comme leur légèreté et leur portabilité. Dans le contexte du Cloud Azure de Microsoft, l’utilisation de Azure Kubernetes Service (AKS) nous permet de gérer, d’orchestrer et de faire évoluer ces applications. AKS permet aux développeurs de créer et de déployer leurs applications plus rapidement qu’en empaquetant, déployant et exécutant des applications sur une machine physique ou virtuelle.

AKS peut être exploité avec Azure DevOps pour déployer facilement l’application conteneurisée et l’infrastructure de soutien de manière native. Azure DevOps est devenu un outil SaaS largement adopté pour le contrôle des sources et le CI/CD, car il s’intègre facilement à Azure, AWS et GCP.

Dans cet article, nous ferons la démonstration de technologies telles que Azure Kubernetes Service, Azure Container Registry, Azure DevOps et Terraform avec une application de démonstration. Cette démo montrera comment nous pouvons déployer une application conteneurisée avec Kubernetes.

Architecture globale

Dans cette démonstration, notre application est un jeu de nombres aléatoires fonctionnant sur Azure, utilisant les ressources et services natifs d’Azure pour déployer l’application et l’infrastructure. Nous allons explorer ces ressources et services en détail dans cet article. Le schéma ci-dessous montre l’architecture globale :

Architecture

  • Azure DevOps est un excellent produit SaaS, facile à utiliser. Azure Repos et Azure Pipelines sont deux fonctionnalités d’Azure DevOps qui nous ont aidés à répondre à nos besoins en matière de contrôle des sources et de CI/CD. Le code source se trouve dans un répertoire basé sur Git dans Azure Repos (notre code d’application, d’infrastructure et de pipeline) et notre pipeline CI/CD est un Azure YAML Pipeline.
  • Azure Container Registry (ACR) est un répertoire de conteneurs natif d’Azure, un peu comme Docker Hub, mais c’est la solution de registre de conteneurs d’Azure, qui s’intègre donc aux autres ressources d’Azure et utilise Azure Active Directory pour plus de sécurité. Dans cette démo, Azure Pipeline construit et pousse l’image Docker vers l’ACR (une nouvelle version de l’image est créée à chaque exécution réussie du pipeline).
  • Azure Kubernetes Service (AKS) est un service d’orchestration de conteneurs gérés sans serveur. AKS fonctionne directement sur Azure en tant que service PaaS et nous fournit un environnement Kubernetes pour déployer et gérer notre application Docker conteneurisée. Cet environnement Kubernetes géré est celui qui exécute nos ressources Kubernetes dans cette démo.
  • Azure Active Directory est la solution intégrée de gestion des identités Azure. Dans cette démo, il est important pour nous car nous avons besoin d’un Service Principal (une identité basée sur un Azure AD App Registration). Ce Service Principal est utilisé pour créer une connexion sécurisée et authentifiée basée sur l’identité (une connexion de service au Azure Resource Manager) afin de déployer les ressources avec les autorisations correctes vers l’abonnement Azure correct.
  • Azure Key Vault est un produit PaaS dans Azure qui nous permet de gérer/stocker des clés et des secrets. Le mot de passe Service Principal (le secret client) est stocké dans Azure Key Vault pour une meilleure pratique. Nous utilisons ce Service Principal dans deux cas précis : la connexion au service et comme identité AKS.
  • Terraform est notre outil de choix pour l’infrastructure en tant que code afin de créer nos ressources AKS et ACR.
  • Les comptes Azure Storage sont idéaux pour stocker à distance et en toute sécurité le fichier d’état Terraform. L’utilisation d’un compte Azure Storage présente l’avantage de s’intégrer facilement à notre pipeline Azure DevOps.

Que se passe-t-il dans Azure Pipeline ?

Examinons le Azure YAML Pipeline que nous avons utilisé pour déployer notre infrastructure et notre application dans Azure.

L’Azure Pipeline entièrement automatisé fait appel à plusieurs tâches de déploiement différentes. Les tâches utilisées par Azure Pipeline sont les suivantes :

  • Terraform (Terraform Installer & Terraform Task) : installe Terraform et déploie les AKS et ACR basés sur les modules Terraform dans notre Azure Repo.
  • Docker Compose (Docker Task) : génère et pousse l’image Docker pour l’application.
  • Kubernetes (Kubectl Task) : déploie la dernière image Docker dans un cluster de l’AKS en utilisant un fichier manifeste Kubernetes décrivant les ressources (déploiements et services).

Terraform

Notre Azure Pipeline utilise la tâche Terraform Installer pour installer la version 0.12 de Terraform sur l’agent du pipeline Azure DevOps. Nous utilisons également les tâches Terraform pour exécuter les fonctions terraform init, plan et apply. Les extraits de code du pipeline YAML sont présentés ci-dessous.

Tout d’abord, la tâche terraform init utilise la connexion de service (ARM-DevOps-AKS-DemoApp) pour s’authentifier auprès d’Azure et se connecte au fichier d’état Terraform que nous stockons et gérons dans un compte Azure Storage (en fonction de la configuration du backend Terraform). Ensuite, la tâche du plan terraform compare le code avec le fichier d’état pour identifier les changements qui doivent être déployés. Enfin, dans la tâche terraform apply, les changements sont déployés – dans ce cas, les ressources AKS et ACR sont créées pour la première fois.

steps:
- task: TerraformInstaller@0
  displayName: ’Terraform - Install’
  inputs:
    terraformVersion: ’0.12.26’

- task: TerraformTaskV1@0
  displayName: ’Terraform - Init’
  inputs:
    provider: ’azurerm’
    command: ’init’
    commandOptions: ’-input=false’
    backendServiceArm: ’ARM-DevOps-AKS-DemoApp’
    backendAzureRmResourceGroupName: ’$(TF_STATE_SA_RG)’
    backendAzureRmStorageAccountName: ’$(TF_STATE_STORAGE_ACCOUNT)’
    backendAzureRmContainerName: ’$(TF_STATE_STORAGE_CONTAINER)’
    backendAzureRmKey: ’$(TF_STATE_KEY)’

 

- task: TerraformTaskV1@0
  displayName: ’Terraform - Plan’
  inputs:
    provider: ’azurerm’
    command: ’plan’
    commandOptions: ’-input=false -var-file="azure-pipeline.tfvars"’
    environmentServiceNameAzureRM: ’ARM-DevOps-AKS-DemoApp’
- task: TerraformTaskV1@0
  displayName: ’Terraform - Apply’
  inputs:
    provider: ’azurerm’
    command: ’apply’
    commandOptions: ’-input=false -auto-approve -var-file="azure-pipeline.tfvars"’
    environmentServiceNameAzureRM: ’ARM-DevOps-AKS-DemoApp’

 

Docker

Une fois que Terraform a créé avec succès les ressources AKS et ACR, Azure Pipeline passe aux tâches Docker. Avec le fichier docker-compose.yaml, les services Docker seront construits et l’image Docker résultante sera poussée de l’agent Azure Pipelines vers l’ACR. L’étiquette de la dernière version de l’image sera également mise à jour avec la nouvelle image construite.

- task: DockerCompose@0
  displayName: ’Docker - Build’
  inputs:
    containerRegistryType: ’Azure Container Registry’
    azureSubscription: ’ARM-DevOps-AKS-DemoApp’
    azureContainerRegistry: ’{"loginServer":"$(ACR_LOGIN_SERVER)", "id" : "$(ACR_ID)"}’
    dockerComposeFile: ’docker-compose.yaml’
    dockerComposeFileArgs: ’DOCKER_BUILD_SOURCE=’
    action: ’Build services’
    additionalImageTags: ’$(Build.BuildId)’

 

- task: DockerCompose@0
  displayName: ’Docker - Push’
  inputs:
    containerRegistryType: ’Azure Container Registry’
    azureSubscription: ’ARM-DevOps-AKS-DemoApp’
    azureContainerRegistry: ’{"loginServer":"$(ACR_LOGIN_SERVER)", "id" : "$(ACR_ID)"}’
    dockerComposeFile: ’docker-compose.yaml’
    dockerComposeFileArgs: ’DOCKER_BUILD_SOURCE=’
    action: ’Push services’
    additionalImageTags: ’$(Build.BuildId)’

Kubernetes

Une fois que Docker a terminé de construire et de pousser l’image, le pipeline Azure passe aux tâches Kubernetes, qui utilisent kubectl. Tout d’abord, la tâche Kubernetes va créer les ressources (déploiements et services) sur la base du fichier manifeste Kubernetes azure-random-game-app.yaml. Ensuite, la dernière étape consiste à extraire la dernière version de l’image de l’ACR et à mettre à jour les ressources à l’aide de Kubernetes.

- task: Kubernetes@1
  displayName: ’AKS Deployments & Services’
  inputs:
    connectionType: ’Azure Resource Manager’
    azureSubscriptionEndpoint: ’ARM-DevOps-AKS-DemoApp’
    azureResourceGroup: ’$(AKS_RG_NAME)’
    kubernetesCluster: ’$(AKS_NAME)’
    command: ’apply’
    useConfigurationFile: true
    configuration: ’$(System.DefaultWorkingDirectory)/azure-random-game-app.yaml’
    secretType: ’dockerRegistry’
    containerRegistryType: ’Azure Container Registry’
    azureSubscriptionEndpointForSecrets: ’ARM-DevOps-AKS-DemoApp’
    azureContainerRegistry: ’$(ACR_LOGIN_SERVER)’
    secretName: ’akssecret’
    versionSpec: ’1.8.1’
    checkLatest: true

- task: Kubernetes@1
  displayName: ’AKS - Update Image’
  inputs:
    connectionType: ’Azure Resource Manager’
    azureSubscriptionEndpoint: ’ARM-DevOps-AKS-DemoApp’
    azureResourceGroup: ’$(AKS_RG_NAME)’
    kubernetesCluster: ’$(AKS_NAME)’
    command: ’set’
    arguments: ’image deployment azure-game-front azure-game-front=$(ACR_LOGIN_SERVER)/azure-game-front:$(Build.BuildId)’
    secretType: ’dockerRegistry’
    containerRegistryType: ’Azure Container Registry’
    azureSubscriptionEndpointForSecrets: ’ARM-DevOps-AKS-DemoApp’
    azureContainerRegistry: ’$(ACR_LOGIN_SERVER)’
    secretName: ’akssecret’
    versionSpec: ’1.8.1’
    checkLatest: true

L’application est déployée !

Une fois que l’Azure Pipeline s’est déroulé avec succès, le résultat final montre que les ressources sont déployées sur Azure. L’application est disponible avec deux services en cours d’exécution : azure-game-back et azure-game-front dans le cluster Kubernetes. Le back-end de l’application est un cache Redis et le front-end est une application web construite avec Python et HTML.

Nous pouvons maintenant utiliser les commandes kubectl (montrées ci-dessous) pour valider la disponibilité et trouver l’adresse IP externe du service azure-game-front pour ouvrir l’application.

$ kubectl reçoit des déploiements

 

$ kubectl reçoit des pods

 

$ kubectl reçoit des services

 

L’application peut maintenant être utilisée pour générer un numéro aléatoire. Le numéro de chaque joueur sera stocké dans le cache Redis jusqu’à ce que le bouton de réinitialisation soit pressé. Vous trouverez ci-dessous quelques captures d’écran du jeu.

Jeu de nombres aléatoires

Jeu de nombres aléatoires

Jeu de nombres aléatoires

La fin… ou pas ?

Nous avons vu le déploiement de bout en bout de l’infrastructure et de l’application avec AKS, Azure DevOps et divers autres services. Comme nous l’avons souligné précédemment – par rapport aux déploiements traditionnels d’une application, nous n’avons pas acheté de plans d’hébergement, de plans Azure App Service, de machines virtuelles/physiques et nous avons donc eu un déploiement plus rapide. Nous pouvons facilement revenir aux versions précédentes de l’application, de l’infrastructure et du pipeline YAML, car nous avons utilisé Azure DevOps pour notre Azure Repo et Azure Pipeline. À l’avenir, nous pourrons faire évoluer les ressources avec un minimum d’efforts, car tout existe sous forme de code.

Nous vous encourageons à essayer un laboratoire pratique avec Azure DevOps et Kubernetes, alors jetez un coup d’œil à ces ressources gratuites :

Déploiement de conteneurs avec Azure DevOps :

https://azuredevopslabs.com/labs/vstsextend/kubernetes/

Création d’un Azure YAML Pipeline : 

https://azuredevopslabs.com/labs/azuredevops/yaml/

Pour plus d’informations sur la façon dont nous utilisons les services DevOps et Kubernetes d’Azure, consultez notre pratique Microsoft Azure.