Comment devenir un ingénieur DevOps en six mois ou moins, partie 4: paquet

“Packages” de chuttersnap sur Unsplash

Récapitulation rapide

Dans la partie 1, nous avons parlé de la culture DevOps et des bases nécessaires:

Dans la partie 2, nous avons expliqué comment poser correctement les bases des déploiements futurs de code:

Dans la troisième partie, nous avons expliqué comment garder votre code déployé organisé:

Ici, nous allons parler de la façon de conditionner votre code pour un déploiement facile et une exécution ultérieure.

Pour référence, nous sommes ici dans notre voyage:

Paquet

REMARQUE: vous pouvez voir comment chaque partie se construit sur la pièce précédente et pose les bases de la pièce suivante. C'est important et c'est fait exprès.

La raison en est que, que vous parliez à vos employeurs actuels ou futurs, vous devez être en mesure d’expliquer ce que DevOps est et pourquoi c’est important.

Et vous le faites en racontant une histoire cohérente - une histoire sur la meilleure façon d’expédier rapidement et efficacement un code depuis un ordinateur portable de développeur vers un déploiement prod produisant de l’argent.

Par conséquent, nous n’avons pas appris un tas d’outils DevOps déconnectés et à la mode. Nous sommes en train d’acquérir un ensemble de compétences axées sur les besoins de l’entreprise et sur des outils techniques.

Et rappelez-vous, chaque phase dure environ un mois d'apprentissage, pour un total de six mois.

OK, assez de bavardages, allons-y!

Introduction à la virtualisation

Rappelez-vous des serveurs physiques? Ceux que vous avez dû attendre des semaines pour être approuvés par le bon de commande, expédiés, centre de données accepté, en rack, en réseau, installés sur un système d’exploitation et corrigés?

Oui, ceux-là. Ils sont venus en premier.

Essentiellement, imaginez si la seule façon d’avoir un endroit où vivre est de construire une nouvelle maison. Besoin d'un endroit pour vivre? Attendez le temps que cela prend! C'est plutôt cool puisque tout le monde a une maison, mais pas vraiment parce que la construction d'une maison prend beaucoup de temps. Dans cette analogie, un serveur physique est comme une maison.

Ensuite, les gens se sont énervés du temps que tout a pris et des personnes très intelligentes ont proposé l’idée de la virtualisation: comment faire fonctionner un groupe de «machines» factices sur une seule machine physique et faire en sorte que chaque fausse machine soit une véritable machine. Génie!

Donc, si vous voulez vraiment une maison, vous pouvez construire la vôtre et attendre six semaines. Ou vous pourriez aller vivre dans un immeuble et partager les ressources avec d'autres locataires. Peut-être pas aussi génial mais assez bon! Et surtout, il n'y a pas d'attente!

Cela a duré un certain temps et les entreprises (VMWare, par exemple) en ont fait une tuerie absolue.

Jusqu'à ce que d'autres personnes intelligentes décident qu'il ne suffit pas d'intégrer un ensemble de machines virtuelles dans une machine physique: nous avons besoin d'une compression plus compacte de davantage de processus dans moins de ressources.

À ce stade, une maison coûte trop cher et un appartement est encore trop cher. Et si j'ai juste besoin d'une chambre à louer temporairement? C’est incroyable, je peux entrer et sortir à tout moment!

En gros, c’est Docker.

REMARQUE: à compter de décembre 2018,

Naissance de Docker

Docker est nouveau, mais l'idée derrière Docker est très ancienne. Un système d'exploitation appelé FreeBSD avait un concept de prison qui remonte à 2000! Vraiment tout ce qui est nouveau est ancien.

L'idée était alors et maintenant d'isoler des processus individuels au sein du même système d'exploitation, dans ce que l'on appelle la «virtualisation au niveau du système d'exploitation».

REMARQUE: Ce n'est pas la même chose que la «virtualisation complète», qui exécute des machines virtuelles côte à côte sur le même hôte physique.

Qu'est-ce que cela signifie en pratique?

En pratique, cela signifie que la popularité croissante de Docker reflète parfaitement celle des microservices - une approche de l’ingénierie logicielle dans laquelle un logiciel est décomposé en plusieurs composants individuels.

Et ces composants ont besoin d'une maison. Leur déploiement individuel, sous la forme d’applications Java autonomes ou d’exécutables binaires, est très pénible: la gestion d’une application Java diffère de la gestion d’une application C ++ et différente de celle d’une application Golang.

Au lieu de cela, Docker fournit une interface de gestion unique qui permet aux ingénieurs logiciels de créer des packages (!), Déployer et exécuter diverses applications de manière cohérente.

C'est une victoire énorme!

OK, parlons davantage du pour et du contre de Docker.

Avantages de Docker

Isolation de processus

Docker permet à chaque service d'avoir une isolation complète du processus. Service A vit dans son propre petit conteneur, avec toutes ses dépendances. Le service B réside dans son conteneur, avec toutes ses dépendances. Et les deux ne sont pas en conflit!

De plus, si un conteneur tombe en panne, seul ce conteneur est affecté. Le reste va (devrait!) Continuer à courir heureux.

Cela profite également à la sécurité. Si un conteneur est compromis, il est extrêmement difficile (mais pas impossible!) De sortir de ce conteneur et de pirater le système d'exploitation de base.

Enfin, si un conteneur se comporte mal (consommation excessive de CPU ou de mémoire), il est possible de "contenir" le rayon de décharge uniquement sur ce conteneur, sans impacter le reste du système.

Déploiement

Réfléchissez à la manière dont les différentes applications sont construites dans la pratique.

S'il s'agit d'une application Python, elle contiendra une multitude de packages Python. Certains seront installés en tant que modules pip, d'autres sont des packages rpm ou deb, et d'autres sont de simples installations git clone. Ou, si cela est fait avec virtualenv, ce sera un fichier zip contenant toutes les dépendances du répertoire virtualenv.

D’autre part, s’il s’agit d’une application Java, sa construction sera graduelle, avec toutes ses dépendances extraites et réparties aux endroits appropriés.

Tu obtiens le point. Diverses applications, construites avec différentes langues et différentes exécutions, représentent un défi pour le déploiement de ces applications.

Comment pouvons-nous éventuellement garder toutes les dépendances satisfaites?

De plus, le problème est pire s'il y a des conflits. Que se passe-t-il si le service A dépend de la bibliothèque Python v1 alors que le service B dépend de la bibliothèque Python v2? Il existe maintenant un conflit car v1 et v2 ne peuvent pas coexister sur le même ordinateur.

Entrez Docker.

Docker permet non seulement une isolation complète du processus, mais également une isolation complète des dépendances. Il est tout à fait possible et courant que plusieurs conteneurs s'exécutent côte à côte sur le même système d'exploitation, chacun avec ses propres bibliothèques et packages en conflit.

Gestion du temps d'exécution

Encore une fois, la façon dont nous gérons des applications disparates diffère d’une application à l’autre. Le code Java enregistre différemment, est démarré différemment et surveillé différemment de Python. Et Python est différent de Golang, etc.

Avec Docker, nous obtenons une interface de gestion unifiée unique qui nous permet de démarrer, surveiller, centraliser les journaux, d’arrêter et de redémarrer de nombreux types d’applications.

C'est une victoire énorme qui réduit considérablement les coûts opérationnels opérationnels des systèmes de production.

REMARQUE: à compter de décembre 2018, vous n'avez plus à choisir entre le démarrage rapide de Docker et la sécurité des ordinateurs virtuels. Project Firecracker, offert par Amazon, tente de fusionner le meilleur des deux mondes. Pourtant, il s’agit d’une technologie très nouvelle qui ne doit pas encore être déployée.

Cependant, aussi génial que soit Docker, il présente des inconvénients.

Entrez Lambda

Tout d’abord, Docker est toujours en train d’exécuter des serveurs. Les serveurs sont fragiles et feuilletés. Ils doivent être gérés, corrigés et pris en charge autrement.

Deuxièmement, Docker n'est pas sécurisé à 100%. Pas comme une VM, au moins. Il y a une raison pour laquelle les grandes entreprises qui exploitent des conteneurs hébergés le font à l'intérieur de machines virtuelles, et non sur du métal nu. Ils veulent des temps de démarrage rapides des conteneurs et la sécurité des machines virtuelles!

Troisièmement, personne ne gère vraiment Docker tel quel. Au lieu de cela, il est presque toujours déployé dans le cadre d'une structure d'orchestration de conteneur complexe, telle que Kubernetes, ECS, Docker Swarm ou Nomad. Ce sont des plates-formes assez complexes qui nécessitent du personnel dédié pour fonctionner (plus sur ces solutions plus tard).

Cependant, si je suis un développeur, je veux juste écrire du code et le faire exécuter par quelqu'un d'autre. Docker, Kubernetes et tout ce jazz ne sont pas des choses simples à apprendre - dois-je vraiment?!

La réponse courte est, ça dépend!

AWS Lambda (et d'autres solutions similaires) est la solution idéale pour les personnes souhaitant simplement que leur code soit exécuté par d'autres personnes.

AWS Lambda vous permet d'exécuter du code sans provisionner ni gérer les serveurs. Vous ne payez que pour le temps de calcul que vous consommez - il n'y a pas de frais lorsque votre code n'est pas en cours d'exécution.

Si vous avez entendu parler de l'ensemble du mouvement "sans serveur", c'est ça! Plus de serveurs à exécuter ni de conteneurs à gérer. Il suffit d'écrire votre code, de le compacter dans un fichier zip, de le télécharger sur Amazon et de le laisser gérer son mal de tête!

De plus, comme les Lambdas sont de courte durée, il n’ya rien à pirater - les Lambdas sont plutôt sécurisés de par leur conception.

Génial, n'est-ce pas?

C'est mais (surprise!) Il y a des mises en garde.

Premièrement, Lambdas ne peut courir que 15 minutes maximum (à compter de novembre 2018). Cela implique que les processus de longue durée, tels que les consommateurs Kafka ou les applications de calcul automatique, ne peuvent pas s'exécuter en Lambda.

Deuxièmement, les Lambda sont des fonctions en tant que service, ce qui signifie que votre application doit être entièrement décomposée en microservices et orchestrée avec d'autres services PaaS complexes tels que AWS Step Functions. Toutes les entreprises ne se trouvent pas à ce niveau d'architecture de microservice.

Troisièmement, résoudre les problèmes de Lambda est difficile. Ce sont des exécutions en nuage et toutes les corrections de bogues ont lieu dans l'écosystème Amazon. C'est souvent difficile et non intuitif.

En bref, il n'y a pas de repas gratuit.

REMARQUE: Il existe désormais des solutions de conteneur cloud «sans serveur». AWS Fargate est l'une de ces approches. Les mécanismes sont en grande partie similaires. En fait, si vous débutez, je vous recommande fortement d'essayer Fargate - c'est un moyen incroyablement facile de faire fonctionner les conteneurs «de la bonne manière».

MISE À JOUR 13/01/2019: AWS vient d'annoncer une réduction de prix significative pour Fargate, ce qui en fait désormais un choix très attractif pour l'utilisation de conteneurs «sans serveur».

Sommaire

Docker et Lambda sont deux des approches les plus populaires et les plus populaires dans le cloud pour le packaging, l'exécution et la gestion des applications de production.

Ils sont souvent complémentaires, adaptés à des cas d'utilisation et à des applications légèrement différents.

Quoi qu’il en soit, un ingénieur DevOps moderne doit bien connaître les deux. Par conséquent, apprendre Docker et Lambda sont de bons objectifs à court et à moyen terme.

REMARQUE: Jusqu'à présent dans notre série, nous avons traité de sujets que les ingénieurs DevOps de niveau débutant à intermédiaire devraient connaître. Dans les sections suivantes, nous commencerons par discuter des techniques qui conviennent mieux aux ingénieurs DevOps de niveau intermédiaire à expérimenté. Comme toujours, cependant, il n'y a pas de raccourcis à expérimenter!

Prochain

Pour en savoir plus sur les meilleures pratiques de déploiement moderne, lisez la suite!