Architecture d'application traditionnelle avec des machines virtuelles

Le diagramme suivant montre un exemple d'architecture d'application traditionnelle basée sur des machines virtuelles.

1. L'utilisateur envoie une demande au noeud final public de l'application. Le noeud final public est représenté par un service d'équilibrage de la charge qui équilibre le trafic réseau entrant entre les instances de serveur d'applications disponibles.
2. L'équilibreur de charge sélectionne l'une des instances de serveur d'applications saines qui s'exécutent sur une machine virtuelle et transmet la demande. Les fichiers de l'application, tels que le code de l'application, les fichiers de configuration et les dépendances, sont stockés sur la VM du serveur d'application.
3. Le serveur d'application stocke les données de l'application dans une base de données MySQL qui s'exécute sur une VM de base de données.

Architecture conteneurisée

Le diagramme suivant montre un exemple d'architecture de conteneur moderne qui s'exécute dans un cluster Kubernetes.

1. L'utilisateur envoie une demande au noeud final public de l'application. Le noeud final public est représenté par un équilibreur de charge d'application (Application Load Balancer - ALB) Ingress qui équilibre la charge du trafic réseau entrant entre les pods d'application dans le cluster. L'ALB est un ensemble de règles permettant le trafic réseau entrant vers une application exposée publiquement.
2. L'ALB transmet la demande à l'un des pods d'application disponibles dans le cluster. Les pods d'application s'exécutent sur des noeuds worker pouvant être une machine virtuelle ou physique.
3. Les pods d'application stockent les données dans des volumes persistants. Les volumes persistants peuvent être utilisés pour partager des données entre des instances d'application ou des noeuds worker.
4. Les pods d'application stockent les données dans un service de base de données IBM Cloud. Vous pouvez exécuter votre propre base de données dans le cluster Kubernetes, mais une base de données gérée en tant que service (DBaaS) est généralement plus facile à configurer et offre des sauvegardes et une mise à l'échelle intégrées. Vous pouvez trouver de nombreux types de bases de données dans le catalogueIBM Cloud.

Machines virtuelles, conteneurs et Kubernetes

Kubernetes Service permet d'exécuter des applications conteneurisées dans des clusters Kubernetes et fournit les outils et les fonctions suivants :

• Une expérience utilisateur intuitive et des outils puissants.
• Sécurité et isolation intégrées pour permettre la livraison rapide d'applications sécurisées.
• Des services cloud qui intègrent les capacités cognitives d' IBM® Watson™.
• Possibilité de gérer des ressources de cluster dédiées pour les applications sans état et les charges de travail avec état.

Ce qu' IBM fait pour vous

En utilisant les clusters Kubernetes avec IBM Cloud Kubernetes Service, vous bénéficiez des avantages suivants :

• Plusieurs centres de données où vous pouvez déployer vos clusters.
• Prise en charge des options réseau d'intrusion et d'équilibrage de charge.
• Prise en charge des volumes persistants dynamiques.
• Serveurs maîtres Kubernetes gérés par IBM, à haute disponibilité.

Stockage de données non persistant

De par leur conception, les conteneurs ont une durée de vie brève et ne sont pas à l'abri de défaillances inattendues. Vous pouvez stocker des données dans le système de fichiers local d'un conteneur. Les données hébergées au sein d'un conteneur ne peuvent pas être partagées avec d'autres conteneurs ou pods et sont perdues en cas de panne ou de suppression du conteneur.

Création d'un stockage de données persistant pour votre application

Vous pouvez persister les données de l'app et les données du conteneur sur un stockage de fichiers NFS ou un stockage en bloc en utilisant les volumes persistants natifs de Kubernetes.

Pour mettre à disposition le stockage de fichiers NFS ou le stockage par blocs, vous devez demander le stockage de votre pod en créant une réservation de volume persistant (Persistent Volume Claim - PVC). Dans votre PVC, vous pouvez choisir parmi des classes de stockage prédéfinies qui définissent le type de stockage, la capacité de stockage en gigaoctets, l'IOPS, la politique de conservation des données et les autorisations de lecture et d'écriture pour votre stockage. Une PVC met à disposition de manière dynamique un volume persistant (PV) qui représente une unité de stockage réel dans IBM Cloud. Vous pouvez monter la PVC sur votre pod pour lire et écrire sur le PV. Les données stockées dans les PV sont disponibles, même si le conteneur se bloque ou si le pod est replanifié. Le stockage de fichiers NFS et le stockage en bloc qui soutient le PV sont mis en cluster par IBM pour assurer la haute disponibilité de vos données.

Pour apprendre à créer une PVC, effectuez les étapes décrites dans la documentation sur le stockage d'Kubernetes Service.

Déplacement de données existantes vers un stockage persistant

Pour copier des données de votre machine locale vers le stockage persistant, vous devez monter la PVC sur un pod. Ensuite, vous pouvez copier les données de votre machine locale vers le volume persistant de votre pod.

1. Pour copier des données, vous devez d'abord créer une configuration qui ressemble à ce qui suit :

   kind: Pod
   apiVersion: v1
   metadata:
     name: task-pv-pod
   spec:
     volumes:
       - name: task-pv-storage
         persistentVolumeClaim:
          claimName: mypvc
     containers:
       - name: task-pv-container
         image: nginx
         ports:
           - containerPort: 80
             name: "http-server"
         volumeMounts:
           - mountPath: "/mnt/data"
             name: task-pv-storage
   

2. Ensuite, pour copier les données de votre machine locale vers le pod, utilisez une commande similaire à celle-ci :

    kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath>
   

3. Copiez les données d'un pod de votre cluster vers votre machine locale :

   kubectl cp <namespace>/<pod>:<pod_filepath>/<filename> <local_filepath>/<filename>
   

Configuration de sauvegardes du stockage persistant

Les partages de fichiers et le stockage par blocs sont mis à disposition au même emplacement que votre cluster. Le stockage même est hébergé sur des serveurs en cluster par IBM pour assurer une haute disponibilité. Cependant, les partages de fichiers et le stockage par blocs ne sont pas sauvegardés automatiquement et risquent d'être inaccessibles en cas de défaillance de l'emplacement global. Pour éviter que vos données ne soient perdues ou endommagées, vous pouvez configurer des sauvegardes périodiques que vous pouvez utiliser pour restaurer vos données en cas de besoin.

Pour plus d'informations, voir Planification du stockage options for NFS file storage and block storage.

Application des principes des 12 facteurs

L' application à douze facteurs est une méthodologie de construction d'applications natives pour le cloud. Lorsque vous souhaitez conteneuriser une application, la déplacer vers le cloud et l'orchestrer avec Kubernetes, il est important de comprendre et d'appliquer certains de ces principes. Certains de ces principes sont nécessaires dans IBM Cloud.

Les principes clés suivants sont requis:

• Base de code - Tous les fichiers de code source et de configuration sont suivis dans un système de contrôle de version (par exemple, un référentiel GIT), ce qui est nécessaire si vous utilisez le pipeline DevOps pour le déploiement.
• Générer, publier, exécuter - L'application à 12 facteurs utilise une séparation stricte entre les étapes de génération, de publication et d'exécution. Cette opération peut être automatisée avec un pipeline de distribution DevOps intégré pour générer et tester l'application avant de la déployer dans le cluster. Consultez le tutoriel Déployer une application sur Kubernetes pour apprendre à configurer un pipeline d'intégration et de distribution en continu. Il couvre la mise en place du contrôle des sources, les étapes de construction, de test et de déploiement et vous montre comment ajouter des intégrations telles que des scanners de sécurité, des notifications et des analyses.
• Config - Toutes les informations de configuration sont stockées dans des variables d'environnement. Il n'y a pas de données d'identification de service codées en dur dans le code de l'application. Pour stocker les données d'identification, vous pouvez utiliser les secrets Kubernetes. Plus d'informations sur les données d'identification ultérieurement.

Stockage des données d'identification dans les secrets Kubernetes

Ce n'est jamais une bonne pratique de stocker des données d'identification dans le code de l'application. Au lieu de cela, Kubernetes fournit ce que l'on appelle des "secrets" qui contiennent des informations sensibles, telles que des mots de passe, des jetons OAuth ou des clés SSH. Les secrets Kubernetes sont chiffrés par défaut ; il s'agit donc d'une option plus sûre et plus flexible pour stocker des données sensibles que le stockage de ces données en l'état dans une définition de pod ou dans une image de conteneur.

Une façon d'utiliser des secrets à Kubernetes est de faire quelque chose comme ceci :

1. Créez un fichier nommé cloud-secrets.txt et stockez les données d'identification de tout service cloud dans ce fichier.

   {
       "url": "<SERVICE_URL>",
       "api_key": <API_Key>
   }
   

2. Ensuite, créez un secret Kubernetes en exécutant la commande suivante et vérifiez que le secret est créé en utilisant kubectl get secrets après avoir exécuté la commande suivante :

   kubectl create secret generic cloud-service-secret --from-file=cloud-secrets.txt=./cloud-secrets.txt
   

Création d'un fichier Kubernetes deployment.yaml

Pour créer des fichiers Kubernetes deployment.yaml, vous devez procéder de la manière suivante :

1. Créer un fichier deployment.yaml, voici un exemple de fichier YAML de déploiement.

2. Dans votre fichier deployment.yaml, vous pouvez définir des quotas de ressources pour vos conteneurs afin de spécifier la quantité de CPU et de mémoire dont chaque conteneur a besoin pour démarrer correctement. Si des quotas de ressources sont spécifiés dans les conteneurs, le planificateur Kubernetes peut prendre de meilleures décisions concernant le noeud worker sur lequel vos pods doivent être placés.

3. Ensuite, vous pouvez utiliser les commandes suivantes pour créer et visualiser le déploiement et les services créés :

   kubectl create -f <filepath/deployment.yaml>
   kubectl get deployments
   kubectl get services
   kubectl get pods