Automatisation et publication d’une application

1. Suppression d’un déploiement

Durant le précédent chapitre, l’application MailHog a été déployée à l’aide du dashboard. Même si vous ne l’avez pas fait, vous pouvez néanmoins suivre les instructions qui suivent.

Premier point, récupérer la liste des déploiements présents dans le serveur. Pour cela, il faut lancer la commande kubectl suivie du mot-clé get avec le type d’objet deployment. Ci-dessous la commande correspondante :

$ kubectl get deployment 

Ci-dessous le résultat renvoyé :

NAME      READY   UP-TO-DATE   AVAILABLE   AGE 
mailhog   1/1     1            1           8d 

La suppression du déploiement se fait à l’aide de la commande kubectl suivie des éléments suivants :

Ci-dessous la commande à lancer :

$ kubectl delete deployment mailhog 

Ci-dessous le résultat renvoyé par cette commande :

deployment.extensions "mailhog" deleted 

La consultation de la liste des pods renverra alors le contenu suivant :

NAME                       READY   STATUS        RESTARTS   AGE 
mailhog-69bd8f74cb-kl9p5   1/1     Terminating   2          8d 

Au bout de quelques instants, la commande devrait renvoyer le message suivant :

No resources found. 

2. Création d’un déploiement

La commande kubectl, outre les opérations de consultation et de suppression, prend en charge la création d’objets. Dans le cas d’un déploiement, la commande doit être lancée avec les options suivantes :

Ci-dessous la commande correspondant à ces indications :

$ kubectl create deployment mailhog --image=mailhog/mailhog 

Ci-dessous le résultat...

1. Pourquoi utiliser un service ?

Dans ce qui a précédé, l’application MailHog a été accédée grâce au nom de son pod. Si le pod devait disparaître, le gestionnaire de déploiement procédera automatiquement à la création d’un nouveau pod. Malheureusement, le nom aura changé.

Afin de simplifier l’accès à un service hébergé dans un pod, il est nécessaire de passer par un nom de service. Le service remplira plusieurs rôles :

2. Exposition d’un déploiement via un service

La création d’un service se fait avec la commande kubectl suivie de :

Ci-dessous la commande à lancer en fonction de ces instructions :

kubectl expose deployment/mailhog --port 1025,8025 

Et ci-dessous le résultat de cette commande :

service/mailhog exposed 

3. Vérification du service mailhog

Le service est maintenant créé, ce qui va se traduire par la création d’une nouvelle adresse DNS au sein du cluster Kubernetes. Cette dernière doit pointer sur le pod faisant tourner l’application MailHog.

Malheureusement, depuis l’extérieur du cluster, il n’est pas possible d’interroger le serveur DNS de Kubernetes. Pour cela, il faut lancer une requête DNS depuis le pod de MailHog en mode interactif.

Utilisez pour cela la commande kubectl ainsi que l’instruction exec. Cette dernière attend les options suivantes :

En résumant (et en concaténant les options...

1. Mécanisme de création et mise à jour

Dans les chapitres précédents, vous avez déployé l’application MailHog avec les mécanismes suivants :

Pour ces deux mécanismes, une définition au format YAML a été envoyée dans l’API de Kubernetes de manière transparente.

Dans le cadre d’une découverte de Kubernetes, ce mécanisme est suffisant. Pour les opérations de mise à jour ou pour l’utilisation de fonctions avancées (déclaration de règles Ingress), il est préférable de connaître la structure réelle utilisée.

Dans ce qui va suivre, la commande kubectl avec l’option apply sera utilisée pour gérer les créations et mise à jour d’objet.

2. Structure YAML d’un déploiement

$ kubectl get deployment mailhog -o yaml 

apiVersion: extensions/v1beta1  
kind: Deployment  
metadata:  
 annotations: 
   deployment.kubernetes.io/revision: "1" 
 creationTimestamp: "2019-03-10T02:53:49Z" ...

1. Origine du besoin

Dans les sections précédentes, vous avez déployé une application. Malheureusement, cette dernière n’est pas accessible depuis l’extérieur sauf à passer par la commande kubectl port-forward.

Heureusement, Kubernetes offre un mécanisme spécialement conçu pour ce type d’opération : les objets Ingress.

Ces derniers, tout comme les déploiements ou les services, se manipulent à l’aide de la commande kubectl et peuvent être listés (get), décrits (describe), créés (create) ou gérés automatiquement (apply).

2. Rôle d’un proxy inverse

En informatique, un proxy inverse désigne un composant qui va se placer en amont d’un autre afin d’étendre ses capacités. Il s’agit d’une architecture très communément déployée et qui est utilisée pour répondre aux problématiques suivantes :

Il existe de nombreux programmes sur le marché qui prennent en charge tout ou partie de ces fonctions : Apache, Nginx, Haproxy, Traefik, etc.

Minikube dispose d’un contrôleur Nginx prêt à l’emploi par simple activation. C’est lui qui sera utilisé pour la suite du chapitre.

3. Activation du contrôleur Ingress dans Minikube

Première chose à faire si ce n’est pas encore le cas : activer le contrôleur Ingress par défaut de Minikube.

Tout comme pour les autres addons de Minikube, la commande minikube prendra en paramètre les éléments suivants :

Ci-dessous la commande correspondante :...