Contrairement à la transition précédente et tout aussi révolutionnaire du bare metal aux machines virtuelles, les conteneurs réduisent considérablement la redondance de la pile logicielle et modifient la nature même de la gestion des systèmes d'exploitation dans l'entreprise.
Beaucoup choisissent d'accélérer leur migration vers des conteneurs avec Red Hat OpenShift Container Platform, la plateforme Kubernetes leader du secteur pour le secteur des entreprises. Cette solution prend automatiquement en charge la plupart des tâches du premier jour et offre le meilleur écosystème Kubernetes basé sur une plate-forme unique, soigneusement testée et hautement sécurisée. Il s'agit de la solution la plus complète et la plus fonctionnelle pour les entreprises qui contient tout ce dont vous avez besoin pour démarrer et supprime de nombreux obstacles techniques et complexités lors de la création d'une plate-forme Kubernetes.
Cependant, OpenShift n'est pas une baguette magique qui résout tous les problèmes à elle seule. Oui, grâce à ses capacités, cette plateforme est en mesure d'apporter - et apporte à ses clients - de nombreux avantages et est rapidement rentable, à condition qu'au moment de son lancement, vous ayez un plan bien pensé. Pour réussir, sept domaines doivent être minutieusement définis avant de déplacer des charges de travail vers OpenShift.
1. Normalisation des règles de dénomination et des métadonnées
Il n'y a que deux choses difficiles en informatique: invalider le cache et nommer les entités.
- Phil Karlton
Chaque entité dans OpenShift et Kubernetes a son propre nom. Et chaque service doit avoir son propre nom DNS , la seule limitation ici est les règles de nommage DNS. Imaginez maintenant qu'une application monolithique se soit décomposée en 100 500 microservices distincts, chacun avec sa propre base de données. Et oui, dans OpenShift, tout est hiérarchique, lié ou doit suivre un modèle. Il faudra donc nommer la masse et la masse de tout. Et si vous ne préparez pas de normes à l'avance, ce sera un véritable Far West.
Avez-vous déjà planifié le schéma de mise en œuvre du service? Disons que ce sera un grand espace de noms, par exemple "bases de données", dans lequel chacun hébergera ses bases de données. OK, et supposons même que tout le monde le fasse, mais ensuite ils commencent à héberger leurs clusters Kafka dans leurs propres espaces de noms. Oui, mais avez-vous besoin de créer un "middleware" d'espace de noms? Ou est-il préférable de l'appeler «messagerie»? Et comme d'habitude, à un moment donné, il y a des gars qui suivent toujours leur propre chemin et se considèrent spéciaux et disent qu'ils ont besoin de leurs propres espaces de noms. Et écoutez, nous avons 17 départements dans l'organisation, nous devons peut-être attacher nos préfixes de département standard à tous les espaces de noms?
Pensez aux normes de dénomination et de classement avant de mettre quoi que ce soit en production - vous pouvez gagner beaucoup de temps et d'efforts si vous le faites à l'avance. Établissez des normes pour tout. De plus, ce n'est pas tant leur qualité qui importe ici, mais leur disponibilité, leur intégrité et leur mise en œuvre.
Les métadonnées sont une autre chose très utile . Standardisez les ressources que vous souhaitez suivre et assurez-vous que les bonnes métadonnées sont écrites sur les bonnes ressources. Commencez avec les étiquettes recommandées... Par exemple, annoter "support_email" dans les métadonnées de l'espace de noms peut vous faire gagner un temps précieux lorsque vous contactez le support de niveau 2 en cas de panne majeure. En outre, les métadonnées peuvent être utilisées pour raccourcir les noms de ressources à une longueur significative, plutôt que de couper toutes les informations nécessaires. Impliquez tout le monde, des architectes d'applications aux opérateurs informatiques, réfléchissez et découvrez ce qu'il faudrait pour avoir des normes solides lors du lancement d'OpenShift.
2. Normalisation des images de base de l’entreprise
L'une des principales caractéristiques des conteneurs est la possibilité de mélanger et de faire correspondre toutes les pièces de la pile logicielle. Vous pouvez, bien sûr, prendre votre type de système d'exploitation préféré et tout construire dessus, mais en agissant de cette façon, l'organisation manque d'énormes opportunités. Après tout, qu'est-ce qui est vraiment cool avec les images de conteneurs? Superposition. Vous pouvez supprimer de nombreuses tâches critiques des développeurs et les résoudre en standardisant les images.
Prenons par exemple une application Java de base. Il est peu probable que vos développeurs se trompent avec OpenJDK, mais avec la gestion des vulnérabilités, la mise à jour des bibliothèques et d'autres problèmes d'hygiène informatique - ils le peuvent. Nous savons tous que les problèmes commerciaux sont souvent résolus au prix de compromis techniques, comme l'utilisation délibérée d'anciennes versions de Java. Heureusement, ces tâches sont facilement automatisées et gérées au niveau de l'entreprise. Vous pouvez toujours utiliser les images de base du fournisseur , mais en même temps définir et contrôler vos cycles de mise à jour en créant vos propres images de base.
Pour revenir à l'exemple ci-dessus, disons que les développeurs veulent Java 11 et que vous voulez qu'ils utilisent toujours la dernière version de Java 11. Ensuite, vous créez une image de base d'entreprise (registry.yourcompany.io/java11) en utilisant comme point de départ image de base du fournisseur du système d'exploitation (registry.redhat.io/ubi8/openjdk-11). Et lorsque cette image de base est mise à jour, vous aidez automatiquement les développeurs à implémenter les dernières mises à jour. En outre, cela fournit une couche d'abstraction qui vous permet d'étendre de manière transparente l'image standard avec les bibliothèques ou les packages Linux requis.
3. Normalisation des contrôles de santé et de préparation
Surveillance de l'aptitude au service, elle est nécessaire presque partout. On pense qu'un examen médical annuel est suffisant pour une personne. La santé des applications doit être vérifiée, bien sûr, beaucoup plus souvent, et deux éléments clés doivent être surveillés:
- Si l'application est en cours d'exécution (vérification de l'état).
- Si l'application est prête (contrôle de disponibilité).
Il existe des tonnes d'autres mesures pour faciliter la surveillance des applications, mais ces deux éléments sont à la base non seulement de la surveillance, mais également de la mise à l'échelle. L'intégrité est généralement déterminée par la connectivité réseau et la capacité de l'hôte exécutant l'application à répondre à une demande. En ce qui concerne la préparation, ici déjà chaque application doit répondre aux demandes selon ses propres normes. Par exemple, le lancement d'une application avec de très faibles latences peut entraîner une longue actualisation du cache ou un préchauffage de la JVM . Et en conséquence, la pause entre les réponses «Commencé» et «Prêt» peut atteindre plusieurs minutes. Mais, par exemple, pour une API REST sans état avec une base de données relationnelle, ces réponses viendront simultanément.
Le plus important dans ces vérifications est de ne pas s'écarter de la logique purement binaire. Lancé signifie lancé, sans aucune «sorte de lancé» là-bas. Terminé signifie prêt, et pas de gradations, comme «prêt à répondre à de telles demandes, mais pas à de telles demandes». Le principe est simple: tout ou rien.
Le deuxième aspect de ces contrôles est la normalisation. Comment vérifier l'état de préparation? Si vous n'avez pas de normes, alors même une question aussi simple peut être un véritable cauchemar de surveillance. Comparez simplement les divergences entre les normes Quarkus et Spring Boot . Mais personne ne voulait cela, mais les normes sont toujours le cas. La seule différence est que votre organisation a désormais le pouvoir de définir et d'appliquer des normes.
Remarque dans la marge. N'inventez pas vos propres normes. Il suffit de trouver et d'utiliser un modèle prêt à l'emploi .
4. Standardisation des journaux
Poursuivant le thème de la surveillance, nous notons que la combinaison de stockages bon marché et de solutions de Big Data a donné naissance à un nouveau monstre dans les entreprises: la journalisation totale. Auparavant, il s'agissait de journaux de console non structurés et archaïques qui ne vivaient pas longtemps et étaient créés de temps en temps. Désormais, ils s'efforcent de tout consigner et de développer la science des données avec l'apprentissage automatique pour optimiser les opérations et la surveillance de la manière la plus révolutionnaire. Hélas, nous devons admettre une évidence: toute tentative de commencer à collecter des journaux de centaines d'applications, sans avoir absolument aucun standard et sans même y penser, conduit invariablement à des dépenses inutiles et exorbitantes en outils de gestion des journaux et de transformation de données juste pour commencer. travail. C'est-à-dire avant même que vous compreniezque les messages «Transition terminée» ou «Ce bloc déclenché» n’ont probablement rien à voir avec vos opérations.
La structure doit être normalisée. Encore une fois, l'intégrité des normes est plus importante que leur exactitude. Il devrait y avoir des moyens d'écrire un analyseur de journal distinct pour chaque application qui se trouve dans l'entreprise. Oui, ce seront des éléments purement fragmentaires et non reproduits. Oui, vous aurez un tas d'exceptions qui ne peuvent pas être contrôlées, en particulier pour les applications en boîte. Mais ne jetez pas le bébé avec l'eau, faites attention aux détails: par exemple, l'horodatage de chaque journal doit répondre à la norme ISO appropriée ; la sortie elle-même doit être en UTC avec une précision du 5ème chiffre en microsecondes (2018-11-07T00: 25: 00.07387Z). Les niveaux de journal doivent être émis avec CAPS et il doit y avoir des éléments TRACE, DEBUG, INFO, WARN, ERROR. En général, définissez la structure, puis entrez dans les détails.
La normalisation structurelle obligera tout le monde à respecter les mêmes règles et à utiliser les mêmes modèles architecturaux. Cela est vrai pour les journaux d'application et de plate-forme. Et ne vous écartez pas d'une solution toute faite à moins que cela ne soit absolument nécessaire. La pile EFK (Elasticsearch, Fluentd et Kibana) de la plateforme OpenShift devrait être capable de gérer tous vos scripts. Après tout, il est entré dans la plate-forme pour une raison, et lorsqu'elle est mise à jour, c'est une autre chose dont vous n'avez pas à vous soucier.
5. Passer à GitOps
L'une des grandes choses à propos d'OpenShift est que tout ici - littéralement: tout - est en fin de compte soit la configuration, soit le code, ce qui signifie qu'il peut être contrôlé via un système de contrôle de version. Cela vous permet de révolutionner les méthodes de livraison et de vous débarrasser de la bureaucratie lors du lancement en production.
En particulier, le schéma traditionnel basé sur les tickets peut être complètement remplacé par le modèle git pull.... Disons que le propriétaire de l'application souhaite ajuster les ressources allouées à l'application après y avoir implémenté de nouvelles fonctions, par exemple en augmentant la mémoire de 8 Go à 16 Go. Dans le schéma traditionnel, un développeur doit créer un ticket et attendre que quelqu'un d'autre termine la tâche correspondante. Ce quelqu'un d'autre est le plus souvent un opérateur informatique qui n'introduit qu'un retard tangible dans le processus de mise en œuvre des changements, sans ajouter de valeur à ce processus, ou pire, en ajoutant des cycles supplémentaires inutiles à ce processus. En effet, l'opérateur a deux options. Tout d'abord, il passe en revue l'application et décide de l'exécuter, pour laquelle il entre dans l'environnement de production, effectue manuellement les modifications demandées et redémarre l'application.
En plus du temps nécessaire pour effectuer le travail lui-même, il y a un délai supplémentaire ici, car l'opérateur, en règle générale, a toujours toute une file d'attente de demandes d'exécution. De plus, il existe un risque d'erreur humaine, comme une entrée de 160 Go au lieu de 16 Go. Deuxième option: l'opérateur met en doute l'application et lance ainsi une réaction en chaîne pour connaître les raisons et les conséquences des changements demandés, à tel point que parfois les autorités doivent intervenir.
Voyons maintenant comment cela se fait dans GitOps. La demande de changement va au référentiel git et devient une demande d'extraction. Après cela, le développeur peut soumettre cette pull request (en particulier s'il s'agit de changements dans l'environnement de production) pour approbation par les parties impliquées. De cette façon, les professionnels de la sécurité peuvent s'impliquer à un stade précoce et il est toujours possible de suivre la séquence des changements. Les normes dans ce domaine peuvent être mises en œuvre par programme à l'aide des outils appropriés dans la chaîne d'outils CI / CD. Une fois approuvée, la demande d'extraction est versionnée et facilement vérifiée. De plus, il peut être testé dans un environnement de pré-production dans le cadre d'un processus standard , éliminant complètement le risque d'erreur humaine.
Comme vous pouvez le voir, les changements sont radicaux. Mais ils ne seront pas tant nouveaux pour les développeurs habitués aux systèmes de contrôle de version que pour les administrateurs système et les spécialistes de la sécurité. Mais dès qu'ils se plongeront dans le nouveau paradigme et apprécieront sa force et sa simplicité, l'idée partira en grand.
6. Plans directeurs
Le passage des applications monolithiques aux microservices renforce le rôle des modèles de conception d'applications (modèles). En effet, l'application monolithique typique n'est pas très classifiable. En règle générale, il existe des API REST, un traitement par lots et un événement piloté. HTTP, FTP, kafka, JMS et Infinispan ? Oui, s'il vous plaît, et cela fonctionne également avec trois bases de données différentes en même temps. Et comment pouvez-vous créer un schéma lorsqu'un ensemble de modèles d'intégration d'applications d'entreprise sont mélangés ici? En aucune façon.
Mais si vous décomposez une telle application monolithique en parties distinctes, les modèles se distinguent beaucoup plus facilement et plus facilement. Disons qu'il existe désormais quatre applications distinctes et qu'elles utilisent les modèles suivants:
- API REST pour la gestion des données dans un SGBD.
- Traitement par lots qui vérifiera le serveur FTP pour les mises à jour des données et les enverra à la rubrique kafka.
- Camel est un adaptateur qui prend les données de ce sujet kafka et les envoie à l'API REST
- API REST qui exposent des informations agrégées collectées à partir d'une grille de données qui agit comme une machine à états.
Nous avons donc maintenant des schémas, et les schémas peuvent être standardisés. Les API REST doivent être conformes aux normes Open API . Les travaux par lots seront gérés en tant que travaux par lots OpenShift . Les intégrations utiliseront Camel... Vous pouvez créer des schémas pour les API, pour les travaux par lots, pour AI / ML, pour les applications de multidiffusion, ou autre. Ensuite, vous pouvez déterminer comment déployer ces schémas, comment les configurer, quels modèles utiliser. Avec ces normes en place, vous n'avez pas à réinventer la roue à chaque fois et vous pouvez mieux vous concentrer sur les tâches vraiment importantes, comme la création de nouvelles fonctionnalités commerciales. L'élaboration des circuits peut sembler une perte de temps, mais l'effort dépensé reviendra au centuple dans le futur.
7. Préparez-vous pour l'API
Les API sont accompagnées d'une architecture de microservices. Ils devront également être gérés et mieux préparés pour cela à l'avance.
Premièrement, ici encore, des normes sont nécessaires. Vous pouvez prendre les standards Open API comme point de départ , mais vous devez vous plonger plus profondément dans la jungle. Bien qu'il soit important de trouver un équilibre ici et de ne pas tomber dans une sur-réglementation excessive avec un tas de restrictions. Regardez ces questions: Lorsqu'une nouvelle entité est créée à l'aide de POST, devons-nous renvoyer 201 ou 200? est-il autorisé à mettre à jour des entités en utilisant POST et non PUT? Quelle est la différence entre 400 et 500 réponses? - à peu près le même niveau de détail dont vous avez besoin.
Deuxièmement, vous avez besoin d'un service mesh... C'est une chose vraiment forte et avec le temps, elle deviendra une partie intégrante de Kubernetes. Pourquoi? Parce que le trafic deviendra tôt ou tard un problème, et vous voudrez le gérer à la fois à l'intérieur du centre de données (le trafic dit «est-ouest») et entre le centre de données et le monde extérieur («nord- Sud"). Vous souhaiterez extraire l'authentification et l'autorisation des applications et les amener au niveau de la plate-forme. Vous aurez besoin des capacités de Kiali pour visualiser le trafic à l'intérieur du maillage de service, ainsi que des schémas de déploiement d'application bleu-vert et Canary, ou, par exemple, du contrôle dynamique du trafic. En général, le maillage de services entre dans la catégorie des tâches du premier jour sans aucun doute.
Troisièmement, vous aurez besoin d'une solution de gestion centralisée des API... Vous voudrez avoir une «fenêtre unique» pour trouver et réutiliser les API. Les développeurs devront pouvoir accéder à l'API Store, trouver l'API de leur choix et obtenir de la documentation sur son utilisation. Vous souhaiterez gérer de manière cohérente les versions et les obsolètes. Si vous créez une API pour des consommateurs externes, il peut s'agir d'un point de terminaison nord-sud pour la sécurité et la gestion de la charge. 3Scale peut même aider à la monétisation des API. Eh bien, tôt ou tard, votre direction voudra recevoir un rapport répondant à la question "Quelle API avons-nous?"
En conclusion, nous notons que si l'identification des domaines de normalisation et la documentation des normes d'entreprise peuvent être décourageantes en soi, la part du lion de l'effort n'est pas consacrée à cela, mais à la surveillance et à l'application des normes. Mélange puissant d' entropie organisationnelleet une réticence tout à fait naturelle à entrer en conflit avec des collègues dès le début du travail contre les normes. Le combat se divise en d'innombrables batailles minuscules et parfois invisibles: l'étiquette requise manque ici, et ce nom, bien que pas complètement, répond toujours suffisamment à la norme. Les normes meurent généralement de mille coupures, et peu, voire aucune, dans l'organisation en a connaissance. Dans un sens, les normes sont comme l'exercice: personne ne veut transpirer et se fatiguer, mais tout le monde sait qu'une vie longue et saine est impossible sans eux.
Cependant, il y a de l'espoir, et cela réside dans l'automatisation. Chacune des normes ci-dessus peut être mise en œuvre à l'aide de l'automatisation. Le processus GitOps peut vérifier que toutes les étiquettes et annotations requises sont présentes dans tous les fichiers yaml pertinents. Le processus CI / CD peut appliquer des normes pour les images d'entreprise. Tout peut être codifié, testé et harmonisé. De plus, l'automatisation peut être améliorée lorsque vous introduisez de nouvelles normes ou modifiez des normes existantes. L'avantage incontestable de la standardisation par l'automatisation est que l'ordinateur n'évite pas les conflits, mais énonce simplement les faits. Par conséquent, avec suffisamment de sophistication et d'investissement dans l'automatisation, la plate-forme dans laquelle vous investissez autant aujourd'hui estpeut apporter un retour sur investissement beaucoup plus important dans le futur sous la forme d'une performance et d'une stabilité améliorées.