Une personne au travail m'a parlé, commentant mes récents articles de blog sur les clusters Raspberry Pi Kubernetes en cours de construction, et s'est demandé "pourquoi devrais-je me soucier de Kubernetes ou de Docker ou de tout ça ?"
Excellente question, et je la trouve moi-même. Il existe de nombreuses ressources, mais aucune ne parlait ma langue, alors voici mes pensées et comment je l'explique.
"Hé, j'ai cette super nouvelle application de blog !"
"Fab, donne-moi !"
"Bien sûr, assurez-vous d'abord que vous disposez de cette version de Windows/Linux, de cette version de .NET/Python/Node et de ces prérequis."
"Attendez, laissez-moi vous appeler la semaine prochaine quand ce sera réglé."
C'est ainsi que les logiciels ont été construits pendant des années. Maintenant, déployons-le.
"Voici le code/les dll/l'application compressés."
"Laissez-moi FTP/SFTP/Faites glisser ceci d'une fenêtre de l'explorateur à une autre."
"Cette version de ce fichier est-elle définie sur ceci ?"
"Attendez, quoi ?"
"Assurez-vous que system/boss/dll/nounjs est la version 4.5.4.1, ils l'ont corrigé."
"Ok, je vais me taire* en production."
Encore une fois, nous sommes tous passés par là. Nous sommes en 2018 et il y a plus de gens qui font ça que vous ne voulez l'admettre.
Entrez dans les machines virtuelles ! Bien mieux, non ? Voici une clé USB avec un fichier qui contient TOUT ce dont vous avez besoin. Géré.
"Oublie ça, utilise ça. C'est mieux qu'un ordinateur, c'est une machine virtuelle. Mais attention, il ne sait pas que c'est virtuel, alors respecte le mensonge."
"D'accord, envoyez-le moi par e-mail."
"Eh bien, c'est 32 concerts. Laissez-moi l'uppresser."
Votre application ne fait que 100 Mo et cette machine virtuelle représente des dizaines de concerts. Pourquoi une personne de 150 livres a-t-elle besoin d'un Hummer de 6 000 livres ? Isolement, je suppose.
"L'application devient plus complexe, mais c'est cool. Il y a quatre machines virtuelles maintenant. Une pour la base de données, une pour Redis et une frontale, et le panier en reçoit une. C'est des microservices !"
"J'adore ça."
"Voici un disque de 2 To."
C'est bien que nous le rompions, mais pas si bien que nous devenons gonflés. Maintenant, nous devons exécuter apt upgrade/windows update sur toutes ces choses et les maintenir. Pourquoi conduire un Hummer quand je peux avoir un Lyft ?
"Ok, je les ai tous fait tourner sur cette grosse machine sous mon bureau."
"Cool, nous passons au cloud."
"Soupir. Je dois mettre à jour toutes ces chaînes de connexion et commencer à télécharger des machines virtuelles."
"Ce sera génial. C'est comme une machine sous votre bureau, sauf que votre bureau est dans le cloud."
"C'est quoi le nuage ?"
"C'est une salle de serveurs que vous ne pouvez pas voir. En gros, ce sont les ordinateurs sous votre bureau. Mais invisibles."
La plupart des infrastructures de VM sont assez bâclées. Ce sont des adresses IP codées en dur, ce sont des machines virtuelles mal nommées vivant dans les mêmes sous-réseaux, puis nous les déplacerons vers le cloud (lift and shift !) Mais elles sont toujours désordonnées, mais elles sont dans le Cloud ™, n'est-ce pas ?
"Vous savez, toutes ces machines virtuelles sont lourdes. Je dois maintenir et déplacer un tas de choses qui NE FONT PAS partie de l'application. Les conteneurs sont la solution. Il suffit de définir les exigences de base de l'application et de partager tout le reste."
"J'en ai entendu parler. Je peux taper "docker run hello-world" et sur n'importe quelle machine, il chargera l'image hello world (basée sur Ubuntu) à partir d'un hub central et l'exécutera de manière essentiellement isolée. Garanti travailler et courir, même si le temps passe."
"Bien, car de plus en plus de parties de notre application sont dans .NET Core sous Linux, mais il y a aussi du Python et des nœuds."
"Oui et tout fonctionnera simplement car les prérequis sont clairement répertoriés dans le conteneur... et les prérequis sont en fait des références à d'autres images de conteneur."
"Ce sont des conteneurs tout en bas."
Désormais, la base de données, Redis, le frontal et le panier peuvent être définis dans de simples fichiers texte. Au lieu que votre système d'exploitation hôte (l'ordinateur principal... le métal) charge un tas de systèmes d'exploitation invités (littéralement des copies !), puis charge toutes les applications et les prérequis, vous partagerez les systèmes d'exploitation et, le cas échéant, les binaires et les bibliothèques. .
"OK, nous avons maintenant un tas de conteneurs en cours d'exécution dans Docker, mais parfois ils tombent en panne ou s'arrêtent."
"Exécutez-les à nouveau ?"
"C'est plus que cela, nous avons parfois besoin d'avoir 3 conteneurs de panier d'achat, et d'autres fois nous avons besoin de 2 conteneurs DB ou plus. De plus, leurs adresses IP changent parfois"
"Nous avons donc besoin de quelque chose pour les faire fonctionner, les mettre à l'échelle ou les mettre à l'échelle automatiquement, ainsi que gérer la mise en réseau et la dénomination/dns."
Entrez un orchestrateur de conteneurs. Il y a Docker Swarm, Mesos/Marathon, Azure Service Fabric et d'autres, mais pour cet article, nous utiliserons Kubernetes.
"Ainsi, Kubernetes exécute mes conteneurs, les fait fonctionner et m'aide à gérer le réseau ?"
"Oui, et non. Des parties de Kubernetes - ou k8s, comme le disent des gens sympas comme moi qui l'utilisent depuis près de 3 heures - font partie des composants principaux, comme etcd pour le stockage des valeurs clés, et le kube-scheduler pour la sélection sur quel nœud exécuter un "pod" (un pod est plus cool à dire qu'un conteneur, mais parfois un pod est plus d'un conteneur. C'est quand même très cool.)
"Je vais devoir faire un glossaire."
"Darn tootin' you will."
Kubernetes a pratiquement tout enfichable. Vous n'aimez pas leur configuration réseau ? Il y a littéralement plus d'une douzaine d'options. Vous voulez de meilleurs tableaux et graphiques ? Tout un monde d'options.
Tout comme un Dockerfile peut expliquer déclarer ce qui est nécessaire pour exécuter une application, un fichier Kubernetes YAML décrit non seulement les conteneurs, mais aussi les ports nécessaires, le nombre de répliques de chacun (pensez à la ferme Web), les noms, les variables d'environnement, etc. Voici un fichier qui montre un front-end, un back-end et un équilibreur de charge. Tout est là, les chaînes de connexion deviennent des recherches DNS internes, chaque service dispose d'un équilibreur de charge (si vous le souhaitez) et vous pouvez effectuer une mise à l'échelle manuelle ou automatique.
"Ok alors pourquoi devrais-je m'en soucier ?"
"Plusieurs raisons. Auparavant, pour installer notre application, je devais vous donner un document Word et un week-end. Maintenant, vous tapez kubectl apply theapp.yaml et il s'exécute en moins d'une minute."
"Je facture toujours le week-end."
En termes simples, nous sommes au début d'une nouvelle phase de DevOps. Celui qui est programmatique, élastique et déclaratif. C'est cohérent, clair et modulaire.
Je vous recommande de consulter les « raisons pour lesquelles Kubernetes est cool » de Julia Evans, ainsi que de lire comment créer un cluster Kubernetes (et les VMS de gestion sont gratuits) dans Azure.
* J'essaie de faire taire une chose. Nous ne sommes pas Es Es Eaytch dans les machines ! Nous nous taisons ! Il se prononce quelque part entre chut et chut. Assurez-vous de jeter un petit jeté quand vous le dites.
* Image utilisée sous CC
Parrain : Libérez un Python plus rapide Boostez les performances de vos applications sur les futures plates-formes Intel® avec la distribution Intel® pour Python. Disponible pour Windows, Linux et macOS. Obtenez la distribution Intel® pour Python* dès maintenant !