Archives par mot-clé : conteneur

Les microservices expliqués simplement

Pour donner une définition des microservices, on peut dire que c’est une approche d’architecture logicielle où une application est décomposée en plusieurs petits services. Et ces services sont souvent spécialisés dans une seule tâche.

A noter que quand on parle de service, il faut comprendre service métier, c’est à dire un groupe de services techniques qui fournissent une fonctionnalité avec un sens métier.

Si on prend l’exemple d’un site de vente en ligne, on aura des microservices par exemple pour le panier, la page d’accueil, l’historique, l’inventaire, etc

Ensuite, l’architecture microservices a été inventée pour répondre aux problèmes rencontrées par les applications dites monolithes.

Une application monolithe est une application qui a pour ambition de traiter toutes les demandes possibles et répondre à un maximum de cas d’usage. Sauf qu’avec le temps, les applications ont tendance à grossir en intégrant toujours plus de nouvelles fonctionnalités mais en supprimant rarement les anciennes fonctionnalités, même lorsqu’elles deviennent inutiles ou obsolètes. Et avec le temps les différentes briques développent des interdépendances entre elles. Et avec ça, la quantité de code augmente et ce code devient de plus en plus complexe.

Il devient alors impossible d’avoir en tête un modèle global du projet.
On se retrouve devant une application difficile à maîtriser et à faire évoluer.

Enfin, plus un projet est gros, plus il est critique pour l’entreprise, et moins on va prendre de risques pour tester des nouveautés, on va donc préférer la stabilité à l’innovation

La réponse de l’architecture microservices à ce problème est simple :  découper l’application en différents modules fonctionnels, en microservices.

Chaque microservice exécute une partie spécifique et unique de l’application. Et ces services peuvent être accédés par le client via l’API du microservice correspondant. Le but de l’architecture microservices est de redonner un maximum d’agilité et d’évolutivité à une application.

Côté technique l’architecture microservices est très souvent couplé à la technologie des conteneurs, et notamment Docker.

Quant aux conteneurs, Le principe est d’avoir un conteneur par unité de microservices. Ainsi, Chaque microservice a son propre environnement d’exécution pour héberger son code. Avec les conteneurs, Il est donc très facile en fonction du besoin d’adapter le nombre de microservices, à la hausse comme à la baisse.

SI un service est plus demandé lors d’un pic de charge, il suffit de créer plus de conteneurs fournissant ce microservice. A contrario, quand la demande de ce service diminue, il suffit de ne garder que le minimum de microservices pour couvrir la demande. Dans l’architecture microservices, il suffit juste d’adapter le nombre de ce microservice au besoin alors que dans les application monolithe, il aurait fallu modifier la totalité de l’application à cause des interdépendance.

Et c’est en étant couplé avec l’utilisation des conteneurs que Chaque microservice devient autonome vis à vis des autres microservices
Un microservice peut être alors modifiée, supprimée ou déployée sans impacter les autres microservices.

Ce qui veut dire qu’avec une application découpée en microservices, il est plus simple de cibler les différentes parties impactées d’une application lors d’une évolution. Ce qui facilite la modification des parties concernées sans risque pour le reste de l’application non impliqué.

Du coup, les mises à jour et nouvelles fonctionnalités peuvent être déployées beaucoup plus facilement et rapidement, rendant le déploiement continu possible.

Concernant l’organisation humaine, la taille des projets est limitée à une équipe de quelques personnes. Chaque équipe est autonome et va donc gérer son organisation et sa base de code.
Une équipe est alors libre des choix techniques en fonction de leurs besoins propres.

Terminons par des points d’attention à propos des microservices
Et tout ce que l’on vient de voir doit permettre aux entreprise d’avoir un atout très très important et c’est d’ailleurs ça qui va pousser à l’adoption des microservices.

Et cette carotte c’est le fait d’avoir un time to market plus rapide. Le time to market c’est le délai de mise sur le marché.cad le temps qu’il y a entre la naissance d’une idée jusqu’à son lancement sur le marché. Aujourd’hui un time to market rapide est devenu un facteur stratégique majeur, il permet à une entreprise de prendre un avantage concurrentiel décisif sur ces concurrents en intégrant la toute dernière innovation dans ses produits ou d’adapter ses produits aux nouveaux besoins du marché.

Comme on l’a vu tout à l’heure les microservices permettent justement de déployer plus rapidement et facilement. Ce qui veut dire être capable de s’adapter plus rapidement à la demande du marché et aux nouveautés.

Par contre et il est important de souligner :

Plus les itérations sont nombreuses et rapides (notamment dans le cadre d’un déploiement continu), plus cela va demander cela va demander aux équipes de se synchroniser rapidement.
Cela va demander une organisation mature pour la communication et coordination entre les équipes et une synchronisation de leurs priorités et objectifs pour qu’ils soient alignés avec les enjeux business

 

Kubernetes pour les débutants

Kubernetes et les conteneurs

Pour comprendre ce qu’est Kubernetes, il faut d’abord savoir ce qu’est un conteneur :

  • En gros, la virtualisation par conteneur est une méthode de cloisonnement au niveau de l’OS basé sur la technologie de virtualisation Linux LXC, pour Linux Containers.
  • Le principe est de faire tourner des environnements Linux isolés les uns des autres dans des conteneurs tout en se partageant le même noyau Linux, le Kernel donc.

Le conteneur virtualise seulement l’environnement d’exécution (comme le processeur, la mémoire vive ou le système de fichier…) et ne virtualise donc pas la machine entière comme pour une VM (Pas de virtualisation d’OS inviténotamment dans un conteneur par rapport à une VM).

Le conteneur est donc plus léger que la VM, ce qui permet de créer beaucoup plus de conteneurs que de VM sur un même serveur. Docker est un exemple de technologie de virtualisation par container.

A noter que pour le reste de la vidéo, je vais prendre l’exemple des conteneurs Docker pour illustrer les fonctionnalités de kubernetes.

Et justement comme un conteneur est fortement relié au kernel, le conteneur n’a pas “conscience” de ce qui se passe en dehors de ce kernel et de la machine hôte.

Et c’est là que Kubernetes intervient :

  • c’est Kubernetes qui va apporter l’orchestration et la gestion des conteneurs sur des clusters de serveurs
  • Dis autrement, Kubernetes permet ainsi de prendre en charge plusieurs kernel et pouvoir gérer les conteneurs sur ces différents serveur hôtes Linux (qu’ils soient physique ou virtuel d’ailleurs). Ces clusters peuvent couvrir des hôtes situés dans des clouds publics, privés ou hybrides.
Les fonctionnalités de Kubernetes

Les fonctionnalités d’orchestration de Kubernetes vous permettent de :

  • créer des services applicatifs ( que ce soir front end ou backend) et ceci sur plusieurs conteneurs,
  • planifier l’exécution de ces conteneurs dans un cluster,
  • garantir leur intégrité au fil du temps.
  • assurer leur monitoring

Avec Kubernetes, le développeur n’ a plus à s’occuper de la gestion des VM, il à disposition directement son environnement d’exécution (qui est le conteneur) pour y déployer son code, et c’est kubernetes qui s’occupe des couches d’infrastructures sous-jacentes.

Avec Kubernetes, le développeur n’a plu à s’occuper de la partie infrastructure, il n’a pas besoin de savoir où tournent leur applications, l’infra sous-jacente est masquée pour le développeur

Architecture de Kubernetes

Il y a d’abord le Kubernetes Master qui est le serveur contrôlant les nodes : ce sont des noeuds esclaves et ce sont des machines hébergeant les hôtes Docker qui exécutent les tâches qui leur sont assignées. Au sein d’un node tourne un pod. Le pod est un environnement d’exécution d’un ou plusieurs conteneur(s) Docker.

C’est le master qui va dire quel node va faire tourner un pod non ordonnancé en se basant sur la disponibilité des ressources. Le master gère l’utilisation des ressources sur chaque node afin de s’assurer que la charge de travail n’est pas en excès par rapport aux ressources disponibles.

Pour accomplir cet objectif, l’ordonnanceur doit connaître les ressources disponibles et celles actuellement assignées sur les serveurs. Et c’est ces information qui sont apporté par les kubelets. Kubelet est un composant exécuté sur des nœuds et qui s’assure que les conteneurs définis ont démarré et fonctionnent comme comme prévus lors de leur conception. Si un noeud tombe par exemple, c’est Kubelet qui va le signaler au master.

Et c’est le master qui vérifie le nombre de copies identiques demandée d’un pod qui doivent s’exécuter dans le cluster. Le master gère la résilience des pod.

 

Voyons de plus près la notion de  pod :

  • Cet environnement d’exécution peut contenir un ou plusieurs conteneur(s) Docker (on va déployer deux containers sur un même POD s’il est nécessaire de partager des ressources locales).
  • En effet Tous les conteneurs d’un pod partagent une même adresse IP, un même nom d’hôte et les même ports réseau et d’autres ressources.
  • La scalabilité horizontale sera réalisée en instanciant l’application dans de multiples pods,

Un volume c’est un espace de stockage accessible à tous les conteneurs sur un pod.

Il repond à 2 besoins :

  • le premier c’est le besoin de préserver les données au delà du cycle de vie d’un conteneur : les données et fichiers dans un conteneur sont éphémères, donc si des données utilisées par les conteneurs doivent être conservés au dela du cycle de vie d’un contneeur, ces données seront stocké dans le volume.
  • Ensuite, le volume est necessaire pour Le partage des données entre 2 conteneurs : quand plusieurs conteneurs s’exécutent dans un même pod, il est souvent nécessaire de partager les fichiers (et données) entre eux. Et c’est réalisé via le volume.

Passons maintenant à la notion de service :

  • Le « Service » est un point d’entrée permettant un accès « load-balancé » à un groupe de containers identiques, autrement dit c’est une VIP ou Virtual IP.
  • Kubernetes fournit un service de routage en assignant une adresse IP et un nom de domaine à un service, et équilibre la charge du trafic vers les différents pods.
  • Les requêtes de service sont alors transférés par Kubernetes vers un des pods.

 

Fonctionnement de Kubernetes

Kubernetes s’exécute au-dessus de l’OS et interagit avec les pods de conteneurs qui s’exécutent sur les nœuds.

Le master Kubernetes reçoit les commandes de la part d’un administrateur (ou d’une équipe DevOps) et relaie ces instructions aux nodes. Comme on l’a vu tout à l’heure, ce système de transfert fonctionne avec une multitude de services et choisit automatiquement le nœud le plus adapté pour chaque tâche. Il alloue ensuite les ressources aux pods désignés dans ce nœud pour qu’ils effectuent la tâche requise.

Lorsque le Kubernetes master planifie un pod dans un nœud, le kubelet de ce nœud ordonne à Docker de lancer les conteneurs spécifiés. Docker démarre/arrête les conteneurs, comme d’habitude.

Le kubelet collecte ensuite en continu le statut de ces conteneurs via Docker et rassemble ces informations sur le serveur master.

On voit donc qu’avec Kubernetes, les ordres proviennent d’un système automatisé et non plus d’un administrateur qui assigne manuellement des tâches à tous les nœuds pour chaque conteneur.

Docker : comprendre l’essentiel en 7 minutes

Dans cette vidéo, je vais vous parler de Docker!

  • Qu’est ce que Docker ?
  • Comment ça marche?
  • Et pourquoi est ce que l’on en parle autant?

 

C’est quoi la virtualisation par conteneurs ?

Avant de parler de Docker, il faut d’abord comprendre ce qu’est un conteneur

La virtualisation par conteneurs se base sur la virtualisation Linux LXC, pour Linux Containers. Il s’agit d’une méthode de cloisonnement au niveau de l’OS. Le principe est de faire tourner des environnements Linux isolés les uns des autres dans des conteneurs partageant le même noyau.

Ce qui veut dire que contrairement aux machines virtuelles traditionnelles, un conteneur n’inclut pas d’OS, puisqu’il s’appuie sur les fonctionnalités de l’OS de la machine hôte. Les conteneurs accèdent alors à l’OS hôte de manière totalement isolée les uns des autres.

Le conteneur virtualise l’environnement d’exécution (comme le processeur, la mémoire vive ou le système de fichier…) et ne virtualise donc pas la machine. C’est pour cela que l’on parle de « conteneur » et non de machine virtuelle (VM).

Fonctionnalités Linux pour LXC

LXC repose principalement sur 2 fonctionnalités du noyau Linux :

  • La première est la fonctionnalité des cgroups (pour control groups). C’est ce qui permet de limiter et d’isoler l’utilisation des ressources
  • Ensuite, la fonctionnalités de cloisonnement des espaces de nommage (ou namespace en anglais), permet d’empêcher qu’un group puisse « voir » les ressources des autres groupes.

La virtualisation par conteneur est aussi caractérisée par la couche intermédiaire du contrôleur qui gère un ensemble de fonctionnalités pour les conteneurs :

  • En premier lieu il y a évidemment l’interaction des conteneurs avec l’OS.
  • La sécurité par la gestion de privilèges et de ressources
  • La scalabilité : c’est à dire la duplication et la suppression de conteneurs
  • L’accessibilité des conteneurs à travers la gestion des API et CLI
  • La portabilité :c’est à dire la migration (à froid ou à chaud) de conteneurs

Différence entre un conteneur et un VM classique

  • Une machine virtuelle ou VM recrée intégralement un serveur. contenant donc un OS complet, avec ses pilotes, ses fichiers binaires ou bibliothèques, ainsi que l’application elle-même.
  • Comme le conteneur n’’embarque pas d’OS, il est donc beaucoup plus léger que la VM.  Le conteneur est donc plus facile à migrer ou à télécharger, et plus rapide à sauvegarder ou à restaurer.
  • La virtualisation par conteneur permet au serveur d’héberger potentiellement beaucoup plus de conteneurs que s’il s’agissait de machines virtuelles.

Et c’est quoi alors Docker?

Docker était initialement basé sur le LXC de Linux.

Docker est passé à Libcontainer après la v.1.8 (bye bye LXC!).
Rassurez-vous le principe est le même. L’intérêt est que Docker peut maintenant supporter plus de technologies d’isolation

Docker permet de créer des conteneurs qui vont uniquement contenir des applications avec leurs dépendances. Les conteneurs Docker permettent d’embarquer des applications afin de les exécuter au sein de l’ OS hôte mais de manière virtuellement isolée.

Le Docker engine fait tourner les conteneurs et joue le rôle de contrôleur.

En termes d’architecture,

  • Docker fonctionne sur une architecture client serveur.
  • Le client Docker communique avec le Docker daemon qui fait tourner le docker engine, pour construire et gérer les conteneurs Docker.
  • Le client Docket et le daemon Docker peuvent tourner sur la même machine, comme sur des machines différentes.

Maintenant passons à un autre concept important de Docker : il s’agit des images Docker

Une image Docker est un template prêt à l’emploi avec des instructions pour la création de conteneur. L’environnement d’exécution d’un conteneur peut nécessiter l’empilement de plusieurs images

Par exemple :

  • On trouve à la base les composants nécessaires à Docker, et qui sont fournis par le noyau Linux de l’hôte.
  • Ensuite, on va prendre l’exemple de 2 containers avec deux images différentes : un avec Debian et un avec uBuntu.
  • Il est possible d’ajouter d’autres images, par par exemple sur le premier conteneur, on ajoute une image d’editeur de texte emacs et une image de serveur web Nginx.

A noter qu’une image ne peut pas être modifiée directement, elle reste toujours en lecture seule. C’est pour cela qu’on trouve une dernière couche, qui est la partie du conteneur accessible en écriture, qui contiendra toutes les modifications apportées à l’application.

Une image Peut être construit à partir d’un Dockerfile ou bien d’une image existante ou être récupéré sur un Registre Docker. Ces registre sont accessible depuis le docker Hub, un dépôt public d’images

 

Workflow de création d’un conteneur Docker

Lorsque je souhaite crée un container. J’ai la possibilité d’utiliser une image existante que je reprend du registre docker (public ou privé).

A noter que je peux aussi créer l’image via le Docker File. Les Dockerfiles sont des fichiers qui permettent de construire une image Docker étape par étape et ceci de facon automatisé

le Docker engine exécute ensuite cette image pour créer un container. Une fois que j’ai ce nouveau conteneur, je peux décider d’en faire une nouvelle image que je fais restocker dans un registre,

 

Pourquoi est ce que l’on en parle autant?

La principale raison est que  Docker permet de faciliter et  d’accélérer les déploiements. En effet, comme toutes les dépendances sont dans le conteneur, le conteneur est autosuffisant. Les conteneurs Docker fournissent le moyen de transporter de manière fluide les applications de l’environnement de développement jusqu’à l’infrastructure de production.

Les admin system n’ont alors plus qu’à “installer le conteneur” sur leurs serveurs Linux. Ce qui permet aux admin system de moins s’arracher la tête sur la gestion de telle ou telle version de librairies, de logiciels, etc.

En ce sens il rapprochent les équipes de dev et de production. C’est pour cela qu’on associe souvent Docker au Devops.