Voici une traduction de l'article de Patrick Lee Scott publié sur hackernoon.com. L'auteur propose de se familiariser avec plusieurs principes importants qui vous aideront à pomper dans DevOps.
Il y a quelques jours, j'ai essayé de peler un œuf d'une manière stupide, et ma petite amie Angeli m'a demandé pourquoi je faisais ça.
Elle prit un autre œuf dur et le frappa sur une planche à découper, puis le pressa et le roula sur la table. Il n'a fallu que 3 secondes pour nettoyer. Et je me suis levé et j'ai enlevé la coquille pièce par pièce.
Ce que je veux dire par ceci:
nous exagérons l'importance des efforts.Les meilleures solutions sont simples et efficaces. Est-il difficile de nettoyer un boulon rouillé? Probablement oui. Mais seulement si vous ne savez pas que cela peut être fait avec Coca-Cola. Toujours compliqué? Non. Il suffit de mettre le boulon dans le verre et d'attendre.
Sans connaître des techniques simples, vous ne pouvez pas les appliquer. Au lieu de mettre en œuvre, vous menez des expériences; au lieu de répliquer, vous faites des recherches.
Si, en programmation, vous utilisez encore et encore une sorte d'approche, car elle vous permet de simplifier le problème à résoudre, cette approche devient un modèle ou la soi-disant meilleure pratique.
Malgré des noms complexes et intimidants tels que Command Query Responsibility Segregation (CQRS) ou Event Sourcing (ES), ces pratiques aident à résoudre les problèmes. Surtout ceux qui surviennent lors de la construction de systèmes distribués.
Si vous regardez le développement dans son ensemble, nous verrons qu'il existe des principes plus universels, par exemple, «Keep it Simple, Stupid» (KISS) et «Don't Repeat Yourself» (DRY). Je voudrais parler de modèles et de principes similaires en relation avec DevOps.
DevOps est souvent présenté comme la terre promise, sur laquelle les oiseaux chantent et le soleil brille. Mais sans utiliser les bonnes méthodes, DevOps se transformera en enfer, et vous percerez tous vos doigts avec une coquille (comme moi).
En créant des systèmes DevOps, j'ai trouvé plusieurs solutions pour moi en plus des principes universels comme KISS et DRY. Bien qu'ils ne puissent pas être appelés modèles, ils vous aideront à nettoyer rapidement l'œuf. Ces solutions (dans un ordre aléatoire):
- Ne faites pas ce que les autres ont fait avant vous.
- Laissez les développeurs être aussi productifs que possible.
- La production est un mythe.
- Transférez tout sur le cluster et sauvegardez le tout.
- Le VPN est trop compliqué, les solutions sont plus faciles.
- Organisez, automatisez et conquérez!
Leçon 1. Ne faites pas ce que les autres ont fait avant vous
Si vous avez la possibilité d'acheter un produit fini ou si vous disposez de l'outil nécessaire et pratique dans le domaine public, utilisez-le.
Ne réinventez pas la roue - achetez-la.
Saviez-vous que vous pouvez utiliser le même serveur de messagerie que Craigslist utilise? Et c'est gratuit? Besoin d'un serveur de messagerie - n'en créez pas un nouveau, travaillez avec un serveur existant.
J'aime chercher des outils dans des listes géniales auto-hébergées ou utiliser le Helm Hub pour cela.
Malgré le fait que Helm soit un outil assez nouveau pour trouver des logiciels, ce site a déjà été créé: https://v3.helm.sh/Avec Helm, vous pouvez facilement rechercher vos vélos finis.
Revenons dans le temps quand je commençais à peine à programmer. En 9e année, j'ai appris ma première «vraie» langue - QBasic. Avant cela, je crée des sites HTML et CSS depuis quelques années. Ensuite, Internet était nouveau, et bien que les gens savaient comment créer des packages, ils ne les partageaient pas, comme nous le sommes maintenant. Habituellement, j'utilisais des disquettes pour le stockage - ce serait génial de les trouver avec un jeu comme arkanoid, que j'ai écrit dans Java Swing en 11e année ...
Tout ce que j'utilisais alors, c'était des bibliothèques standard, bébé! Au moins à 13 ans, je ne les connaissais que. Même si je suis sûr que certains java pros (bonjour, Vlad et Nick!) Étaient déjà cool à l'époque. ;)
Maintenant, tout va mal. Aujourd'hui, vous pouvez trouver des bibliothèques d'interface utilisateur entières. Vous pouvez trouver une bibliothèque pour traiter les dates avec élégance et facilité avec une seule commande.
Ce serait formidable s'il y avait un outil pour utiliser et installer des sous-systèmes pleinement fonctionnels, non? Besoin d'une base de données?
installer la base de donnéesBonne nouvelle: un tel outil existe! Avec Helm, vous pouvez également installer des sous-systèmes pleinement fonctionnels, conditionnés et prêts à l'emploi.
Le principe est le même que pour NPM et Gradle, mais les packages que nous gérons dans Helm sont appelés graphiques. Les graphiques balisent les conteneurs afin qu'ils s'exécutent sur Kubernetes de différentes manières.
Il s'avère une solution clé en main, l'achat d'un vélo. Les graphiques sont la roue, et les conteneurs avec des descriptions qui s'exécutent à l'intérieur de Kubernetes sont des roues.
Ce qui est cool avec les graphiques, c'est la possibilité de regrouper des services et de les exécuter dans n'importe quel cluster Kubernetes et même de les partager avec d'autres personnes si vous le souhaitez.
Cela signifie que vous pouvez décrire l'environnement entier à l'aide de code:
- name: backup repository: http:
Besoin de mettre à niveau votre site marketing vers 1.2.0? Apportez des modifications et engagez-vous.
Leçon 2. Laissez les développeurs être aussi productifs que possible.
Une fois, je me suis assis à la table, j'ai regardé mon code et j'ai essayé de suivre le bug. Les utilisateurs se plaignent de lui depuis plusieurs semaines maintenant, et finalement j'ai eu un peu de temps libre pour traîner.
Tada-a-am! Je l'ai trouvé! Fixé!
Je me suis assis derrière une cloison sur mon lieu de travail dans une pièce ensoleillée et j'ai crié aux autres: "J'ai corrigé le bug!"
Mardi prochain, lorsque les utilisateurs verront la sortie, ils apprécieront certainement mes efforts! Mais pour cela, nous devrons emballer et essayer de déplacer la version de l'endroit ... Peut-être que nous réussirons si rien ne se passe ...
Eh bien,
si la sortie arrive toujours mardi prochain, les utilisateurs l'apprécieront certainement!
C'est ainsi que je faisais le déploiement lors de mon premier emploi universitaire, en tant que programmeur junior.
Depuis lors, beaucoup de choses ont changé.
Maintenant, j'utilise le développement basé sur les troncs et déploie des modules plusieurs fois par jour. Lorsque j'envoie une demande Pull, le bot publiera un commentaire correspondant avec le code de révision avec l'environnement collecté après que les tests ont réussi et que les builds ont été collectés.
Aujourd'hui, vous n'avez plus à crier à travers la cloison du bureau.
Plus vous accordez de liberté aux programmeurs - la liberté de contrôler les parties de l'infrastructure dont ils ont besoin - plus il vous est facile de travailler en tant qu'ingénieur DevOps.
Dans la première leçon, nous avons vu que pour la mise à jour en production, il suffit de changer un chiffre et de valider. Dans un monde idéal dans lequel nous regroupons les applications dans des graphiques, chaque programmeur d'une équipe a la possibilité d'influencer le fonctionnement de l'outil au stade de la production. Kubernetes comprend les graphiques comme des descriptions de conteneurs, c'est pourquoi ils décrivent les besoins en ressources.
La logique est quelque chose comme ceci: je ne peux pas deviner combien de mémoire ou quels paramètres CPU seront nécessaires pour un nouveau service (et je pense que je ne suis pas le seul). Par conséquent, je déploie également une surveillance et des alertes avec des règles selon lesquelles mon équipe et moi serons informés dans Slack que ces paramètres doivent être modifiés. Autrement dit, le système vous informera des paramètres nécessaires lorsque nous le déploierons. J'avais l'habitude de m'asseoir pendant des heures, envoyant des demandes via Prometheus et ajustant les paramètres, tout comme j'avais l'habitude de choisir la coque. Et maintenant, j'ai appris à tout faire avec sagesse.
Je vous entends déjà dire: "Cela semble trop compliqué!" Non. Définissez simplement le graphique.
Si vous pouvez automatiser ou simplifier quelque chose, allez-y. Par exemple, que se passerait-il si vous pouviez attribuer un chemin DNS en déployant simplement le service avec le libellé "expose: true"? C'est là que les opérateurs apparaissent. Il s'agit d'un outil Kubernetes plus avancé, et vous devriez le connaître. Mais n'allons pas trop loin dans les détails.
Leçon 3. La production est un mythe
Ce fut une véritable révélation pour moi. J'ai dû regarder les choses sous un angle différent, alors écoutez attentivement.
Pendant plus de dix ans, j'ai pensé que dans le monde il n'y a que quelques types d'environnements. Dans le scénario le plus simple, il y a la mise en scène et la production de l'environnement. D'abord déployé en mise en scène, puis testé, passé à l'étape suivante, déployé, testé, etc. Dès que tout est collé - le fils est intégré - vous pouvez passer en production.
J'ai suivi ce modèle année après année et je n'en ai jamais douté. Il en a toujours été ainsi.
Et ce schéma est un autre moyen improductif de se débarrasser de la coque.
En substance, un graphique est un graphique de dépendance. Il peut être utilisé pour représenter l'environnement, puis le processus de déploiement en production se résume au déploiement d'un seul graphique.
Si chaque équipe, projet ou groupe connecté par un contexte commun a son propre graphique, plusieurs environnements apparaissent qui vous permettent de regrouper et de mettre à jour tous les services en une seule transaction.
Ne prenez pas la production comme un énorme environnement global, en fait c'est beaucoup de petite production.
Des changements majeurs sont effrayants dans son ampleur. Et si vous disposez de plusieurs petits environnements de développement, vous pouvez isoler les modifications et rendre le système plus flexible.
De plus, si tout est organisé sous forme de graphiques, les variables seront définies et pourront être modifiées de l'extérieur, de la même manière. Par exemple, pour connecter un cluster kafka moins puissant à la préproduction, là où il n'est pas requis, il vous suffit de modifier la configuration.
Leçon 4. Transférez tout sur le cluster et sauvegardez l'ensemble
Nous avons donc trié la production. Que faire des bases de données? Avec Kafka? Avec des problèmes de sécurité?
Si vous lisez attentivement, souvenez-vous: j'ai écrit que les bases de données peuvent être incluses dans le package graphique.
Kubernetes dispose d'une API distincte pour exécuter des bases de données et d'autres applications avec état sous une forme pratique -
StatefulSets.L'essence même de Kubernetes est d'améliorer la fiabilité du lancement de conteneurs. Avec lui et en utilisant l'outil Velero (installé via Helm Chart), vous pouvez créer une sauvegarde de l'ensemble du cluster Kubernetes, ainsi que les disques qui y sont attachés, par exemple, ceux qui ont été créés par StatefulSet, et tout restaurer avec une seule commande. De plus, il est facile de configurer une sauvegarde automatique selon un calendrier.
Les sauvegardes, la restauration en une seule équipe et le gestionnaire Kubernetes vous aideront à déployer un cluster entièrement nouveau et à restaurer sa sauvegarde avec seulement deux équipes. Un maximum de trois, si vous souhaitez d'abord créer une nouvelle sauvegarde.
Au lieu de penser aux serveurs, vous pouvez opérer sur des clusters entiers.
La pré-production est-elle ennuyeuse? Mettez-le hors de vue - à distance de la sauvegarde, de la récupération et du changement de DNS.
Leçon 5. Le VPN est trop compliqué, il existe des solutions plus faciles
Avez-vous déjà utilisé un VPN avec plaisir?Non, vraiment.
Est-ce même possible?Google a eu une telle tentative. Mais il y a quelques années, la société a annoncé qu'elle n'utiliserait pas de VPN. Je pense qu'ils n'ont pas apprécié non plus.
Google est passé à des réseaux sans confiance. Ils n'ont pas de clé principale adaptée à n'importe quel réseau, mais à l'entrée de chaque service, il y a une clé sous la forme d'un écran de connexion SSO. Vous souhaitez vous connecter au service de surveillance? Connectez-vous en utilisant le nom d'utilisateur et le mot de passe de votre entreprise.
Seul un petit changement est nécessaire: au lieu d'utiliser un VPN pour l'autorisation, utilisez un proxy.
Le VPN héberge également le lien de gestion Kubernetes sur le réseau privé, contrairement à SSO. Mais ils ont leur propre mécanisme d'autorisation. Dans le cas de Google Cloud et AWS, il s'agit de la gestion des identités et des accès (IAM) et de la possibilité de mettre des adresses IP en liste blanche.
S'il est possible de travailler avec une architecture moins volumineuse sans trop de pertes, pourquoi pas? Soyez comme Google: passez d'un VPN à des systèmes «sans confiance».
Leçon 6. Organiser, automatiser et conquérir
Ah, il vous semble que systématiser c'est long? Un non-sens! À l'avenir, cela vous fera gagner des heures, des jours et même des semaines. Pour travailler!
La systématisation est le seul moyen réaliste de recréer l'infrastructure plus d'une fois.
Si chaque élément de réglage peut être amélioré en modifiant et en validant quelque chose dans git, votre organisation technologique entière est essentiellement déclarative. Tout développeur ayant accès à git peut facilement maintenir n'importe quel système en état de marche.
Pour ce faire, utilisez plusieurs petits référentiels. Les monorepos incitent les gens à couper les coins et dépendent des structures d'importance artificielle. Au lieu de cela, il est préférable d'utiliser de nombreux petits référentiels que vous pourrez lier ultérieurement.
Mon ami Matt et moi créons un outil appelé
meta pour aider à le faire au stade du développement. Helm le fait au stade de la production: pour lui, tout est un tableau de dépendance!
Conclusion
Ne cueillez pas la coquille de l'oeuf morceau par morceau. Battre et rouler.