Kubernetes et Docker : 9 raisons pour lesquelles le DevOps est meilleur avec Docker et Kubernetes

Kubernetes et Docker peuvent aider les entreprises √† surmonter l’un des principaux d√©fis – un long d√©lai de commercialisation, qui survient g√©n√©ralement lorsque votre processus de d√©veloppement est ralenti.

Lors du d√©ploiement d’applications, la plupart des √©quipes sont g√©n√©ralement confront√©es √† un probl√®me entre Dev et Ops. En effet, ces deux d√©partements r√©alisent la m√™me application mais travaillent de mani√®re compl√®tement diff√©rente.

Ne serait-il pas agr√©able qu’ils travaillent ensemble sans aucun malentendu afin de r√©duire le temps de mise sur le march√© ?

network cloud hosting hidora

J’ai rassembl√© cette liste d’avantages que DevOps + Docker & Kubernetes peut vous apporter par rapport √† l’approche DevOps traditionnelle.

kubernetes and docker with hidora

L’approche traditionnelle de DevOps

  1. Dans l’approche DevOps traditionnelle, les d√©veloppeurs √©crivent du code et le d√©posent dans un d√©p√īt git.
  2. Ils vérifient ensuite comment il fonctionne localement et dans un environnement de développement.
  3. Ils lancent un processus de construction du code √† l’aide d’un outil de CI, par exemple Jenkins, qui ex√©cute √©galement des tests fonctionnels pendant la construction. Si les tests sont r√©ussis, les modifications sont fusionn√©es dans une branche de publication.
  4. Les tests sont trait√©s sur sc√®ne-environnement et √† la fin du sprint, la version est publi√©e. Les administrateurs syst√®me pr√©parent les scripts pour le d√©ploiement des applications en production, √† l’aide d’Ansible, Puppet ou Chef.
  5. Enfin, les administrateurs syst√®me d√©ploient les changements en production, c’est-√†-dire qu’ils mettent √† jour la version.

Les probl√®mes de l’approche traditionnelle

  • Le premier probl√®me est que les administrateurs syst√®me et les d√©veloppeurs utilisent des outils diff√©rents. Par exemple, la majorit√© des d√©veloppeurs ne savent pas comment travailler avec Ansible, Puppet ou Chef. Le r√©sultat courant de cette situation est que la t√Ęche de pr√©parer la mise en production retombe sur les √©paules des administrateurs syst√®me. Or, les administrateurs syst√®me ne comprennent souvent pas comment une application doit fonctionner, car ce sont les d√©veloppeurs qui ont l’expertise dans ce domaine.
  • Le deuxi√®me probl√®me est que les environnements de d√©veloppement sont g√©n√©ralement mis √† jour manuellement sans aucune automatisation. Par cons√©quent, ils sont tr√®s instables et tombent constamment en panne. Les modifications apport√©es par un d√©veloppeur cassent les modifications apport√©es par un autre d√©veloppeur. La recherche des probl√®mes prend g√©n√©ralement beaucoup de temps. Enfin, les d√©lais de mise sur le march√© sont tr√®s longs.
  • Le troisi√®me probl√®me est que les environnements de d√©veloppement peuvent √™tre tr√®s diff√©rents des environnements de d√©veloppement et de production. De plus, le staging peut ne pas √™tre du tout similaire √† la production. Cela entra√ģne de nombreuses difficult√©s. Par exemple, une version pr√©par√©e par les d√©veloppeurs peut ne pas fonctionner correctement dans l’environnement de test. M√™me si les tests sont pass√©s avec succ√®s dans l’environnement de test, certains probl√®mes peuvent appara√ģtre de mani√®re inattendue dans la production. Parall√®lement, le processus de retour en arri√®re d’une version cass√©e de la production est tr√®s probl√©matique et pas trivial, m√™me en utilisant Ansible, Puppet ou Chef.
  • Le quatri√®me probl√®me est que l’√©criture de manifestes Ansible est longue et difficile. Il est tr√®s facile de perdre la trace des modifications apport√©es aux manifestes, en mettant √† jour une application de version en version. Cela peut entra√ģner un nombre √©lev√© d’erreurs.

Am√©lioration de l’approche DevOps avec Docker

  1. Le principal avantage de cette approche est que les développeurs et les administrateurs système utilisent le même outil РDocker.
  2. Les développeurs créent des images docker à partir de fichiers docker à un stade de développement. Ils les fabriquent sur des ordinateurs locaux et les exécutent sur un environnement de développement.
  3. Les m√™mes images Docker sont utilis√©es par les administrateurs syst√®me qui effectuent des mises √† jour des environnements de stage et de production √† l’aide de Docker. Il est tr√®s important que les conteneurs Docker ne soient pas patch√©s lors de la mise √† jour vers une nouvelle version d’un logiciel. Cela signifie qu’une nouvelle version de votre logiciel est repr√©sent√©e par une nouvelle image Docker et une nouvelle copie du conteneur Docker, mais pas par un patch de l’ancien conteneur Docker.
  4. Ainsi, vous pouvez cr√©er des environnements immuables pour le d√©veloppement, le stockage et la production. Vous pouvez b√©n√©ficier de plusieurs avantages en utilisant cette approche. Tout d’abord, il existe un niveau √©lev√© de contr√īle de toutes les modifications, car les modifications sont effectu√©es √† l’aide d’images et de conteneurs Docker immuables. Vous pouvez revenir √† la version pr√©c√©dente √† tout moment. Les environnements de d√©veloppement, de mise en place et de production deviennent plus similaires les uns aux autres que dans le cas de l’utilisation d’Ansible. En utilisant Docker, vous pouvez garantir que si la fonctionnalit√© fonctionne dans l’environnement de d√©veloppement, elle fonctionnera √©galement dans les environnements de d√©veloppement et de production.

Comment obtenir des superpouvoirs DevOps avec Kubernetes et Docker

  1. Le processus de cr√©ation de la topologie d’une application, contenant plusieurs composants interconnect√©s, devient beaucoup plus facile et compr√©hensible par rapport √† Docker.
  2. Le processus de configuration de l’√©quilibrage des charges est grandement simplifi√© gr√Ęce aux concepts int√©gr√©s de service et d’entr√©e.
  3. Gr√Ęce aux fonctions int√©gr√©es de Kubernetes Deployments, StatefulSets et ReplicaSets, le processus de mise √† jour continue ou de d√©ploiement vert/bleu devient tr√®s facile.
  4. Vous pouvez faire du CI/CD en utilisant Helm, ce qui est plus confortable qu’avec les conteneurs Docker pour ces raisons :
    • Les diagrammes Helm sont plus stables et pr√™ts pour la production que les images Docker individuelles. Vous avez tr√®s probablement √©t√© confront√© √† un probl√®me lorsque vous avez essay√© d’interconnecter diff√©rents conteneurs Docker dans une topologie commune, mais vous avez √©chou√© parce que ces images n’√©taient pas pr√™tes pour ce type d’interconnexion.
    • Il vous fournit un langage de mod√®les de haut niveau et un concept de versions d’applications qui peuvent √™tre annul√©es si n√©cessaire.
    • De plus, vous pouvez utiliser les graphiques Helm existants comme d√©pendances pour vos propres graphiques, ce qui vous permet d’avoir des topologies complexes en utilisant des blocs de construction tiers.
  5. Kubernetes prend en charge un sc√©nario de d√©ploiement pr√™t √† l’emploi sur plusieurs sitescloud (AWS, Google, Hidora ou un autre fournisseur d’h√©bergement) par le biais d’outils de f√©d√©ration ou de maillage de services.

Avez-vous simplifié vos processus DevOps en utilisant Docker et Kubernetes? Partagez votre expérience !

Written by

Matthieu Robin Hidora
Matthieu ROBIN
18/10/2018

Matthieu Robin is CEO at Hidora, an experienced strategic leader, a former system administrator who had managed and configured more environments manually than anyone on the planet and after understanding that it could be done in several clicks established Hidora SA. He regularly speaks at conferences and helps companies to optimize business processes using DevOps. Follow him on Twitter @matthieurobin.

Recevoir nos actualités