Archives par mot-clé : Docker

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.

Comprendre le DevOps en 8 minutes et en emojis!

 

Qu’est ce que le DevOps?

Pour mieux comprendre le DevOps, voyons d’abord un fonctionnement traditionnelle d’entreprise sans DevOps :

  • Les Développeurs (abrégé Dev) collectent les exigences du métier pour ensuite en développer le code.  
  • Ensuite cette même équipe de Dev teste le nouveau code de l’application puis la livre à l’équipe Production et Exploitation (abrégé Ops pour Operationnals).
  • Les Ops se charge de la mettre en production, puis de gérer son exploitation.

Cependant ce modèle pose des problèmes car les 2 équipes Dev et Ops donc ont objectifs complétement différents :

  • D’un côté, l’équipe Dev doit faire évoluer les applications le plus rapidement possible. C’est la recherche d’un time to market réduit, le time to market étant le délai entre l’idée initiale et sa concrétisation en production,
  • De l’autre côté, l’objectif principal d’une équipe Ops est de garantir la stabilité du système. Cela passe par un contrôle sévère des changements apportés au Système d’information. Une panne de la production peut coûter cher à l’entreprise (business perdu, image écornée, contraintes légales non respectées…).

L’antagonisme de ces objectifs cree des conflits d’intérêts entre ces 2 équipes :

  • Les Devs blament les Ops pour les retards et problèmes de livraison.
  • Les Ops tiennent l’équipe des Dev pour responsable des incidents en production liés à une mauvaise qualité du code

Bref c’est pas joli à voir…

L’approche DevOps cherche justement donc à réconcilier ces 2 mondes (d’où la contraction du terme DevOps). Le but est d’aligner leurs objectifs court terme différents  autour d’un objectif commun long terme : celui de la création de valeur pour l’entreprise.

Et cette création de valeur passe par 3 canaux:

  • Un time to market plus rapide
  • Des produits de qualité
  • Des équipes plus efficaces

 

Les grands principes du DevOps 

Cette approche DevOps repose sur 5 grands principes :

  • La culture de collaboration
  • L’automatisation
  • La création de valeur comme objectifs
  • La mise en place de métriques à tous les niveaux
  • Le partage comme valeur forte

Culture de collaboration :

  • Créer une culture de collaboration est très importante car elle permet de donner à toutes les équipes une vision globale du système d’information.
  • Le but ultime est de fluidifier et faciliter l’intercommunication entre Dev et Ops.

La recherche systématique de valeur ajoutée pour client :

  • Elle se décline à travers la mise en place d’un cycle d’amélioration continue, et donc la suppression des taches sans valeur ajoutée.
  • Mais aussi en les incitant les équipes à se concentrer sur la création de valeur business et la satisfaction client.

La mise en place de métriques :

  • Les métriques sont nécessaire car on ne peut parler d’amélioration que si l’on est capable de mesurer l’état initial, l’état final et l’évolution entre les 2 états.
  • Ce sont des métriques à tout les niveaux :  métriques, métriques d’équipe et la mesure de la satisfaction client)

Principe de partage au sens large :

  • Il s’agit de partager un objectif commun, mais aussi les problèmes, les connaissances et les REX.
  • Cela permet de faire émerger un sentiment d’entraite mais aussi des idées nouvelles.

 

Automatisation des processus :

Il se décline sur plusieurs niveaux :

  • Provisionning d’environnements automatisé pour les devs
  • Tests automatisés pour valider la qualité d’un nouveau code
  • Déploiements automatisés une fois que ce code est validé comme conforme à la qualité attendue

Tout ceci en vue de tendre vers le déploiement continu :

  • Le déploiement continu est une approche qui considère qu’une application doit être construite de telle manière à ce  qu’elle puisse être envoyée en production à tout moment (déploiement en production après validation par les tests)
  • L’idée est d’accélérer les cycles de mise en production pour une accélération du time to market.

 

 

 

Et en pratique?

Dans une entreprise Devops, on a alors la situation suivante :

  • Les Devs collectent les besoins métiers et développent un nouveau code de l’application pour répondre à ces besoins.
  • L’application est automatiquement compilés et testés à différents niveau. Si le code atteint le niveau d’exigences demandées en termes de qualité, l’évolution est livrés en production automatiquement et rapidement
  • En cas d’incident en prod, la nouvelle évolution peut être désactivée rapidement pour retourner sous l’ancienne version tout en remontant l’incident à corriger à l’équipe de dev
  • Le travail des Ops est quant à lui facilité  car les dev ont compris les contraintes de l’equipe de production et ont intégré ces problématiques d’exploitation et de production dans son code. Par exemple, le dev a intégré dans la conception de son application des métriques d’exploitation permettant de surveiller l’état de santé de l’application.
  • Les équipes opérationnelles comprennent ainsi mieux les besoins des développeurs pour permettre une meilleure optimisation des ressources de la production, un meilleur monitoring et une meilleure remontée d’erreur.

 

 

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.