Il s'agit du premier d'une série d'articles sur les modifications, améliorations et ajouts de la prochaine mise à jour de Red Hat OpenShift Platform 4.0 qui vous aideront à préparer la transition vers la nouvelle version.
Dès le moment où la toute jeune communauté Kubernetes s'est réunie pour la première fois au bureau de Google à Seattle à l'automne 2014, il était clair que le projet Kubernetes était destiné à révolutionner la façon dont les logiciels sont développés et déployés aujourd'hui. Dans le même temps, les fournisseurs de services de cloud public ont continué à investir activement dans le développement d'infrastructures et de services, ce qui a rendu le travail avec l'informatique et la création de logiciels beaucoup plus faciles et accessibles, et les a rendus incroyablement accessibles, ce que peu auraient pu imaginer au début de l'année. la décennie.
Bien entendu, l'annonce de chaque nouveau service cloud a été accompagnée de nombreuses discussions entre experts sur Twitter, et des débats ont été menés sur une variété de sujets, notamment la fin de l'ère open source, le déclin de l'informatique sur site et l'inévitabilité d'un nouveau monopole logiciel dans le cloud, et comment le nouveau paradigme X remplacera tous les autres paradigmes.
Inutile de dire que toutes ces disputes étaient très stupides
La réalité est que rien ne va disparaître et nous assistons aujourd’hui à une croissance exponentielle des produits finaux et de la manière dont ils sont développés, en raison de l’émergence constante de nouveaux logiciels dans nos vies. Et malgré le fait que tout autour va changer, en même temps, essentiellement, tout restera inchangé. Les développeurs de logiciels écriront toujours du code avec des erreurs, les ingénieurs d'exploitation et les spécialistes de la fiabilité se promèneront toujours avec des téléavertisseurs et recevront des alertes automatiques dans Slack, les responsables continueront à fonctionner en termes d'OpEx et de CapEx, et chaque fois qu'une panne se produit, le senior du développeur le fera. soupire tristement avec les mots : « Je te l'avais bien dit »...
Oh vraiment devrait être discuté, voici les outils dont nous pouvons disposer pour créer de meilleurs produits logiciels, et comment ils peuvent améliorer la sécurité et rendre le développement plus facile et plus fiable. À mesure que les projets deviennent plus complexes, de nouveaux risques apparaissent et, aujourd'hui, la vie des gens dépend tellement des logiciels que les développeurs doivent simplement essayer de mieux faire leur travail.
Kubernetes est l'un de ces outils. Des travaux sont en cours pour combiner Red Hat OpenShift avec d'autres outils et services en une plate-forme unique qui rendrait le logiciel plus fiable, plus facile à gérer et plus sûr pour les utilisateurs.
Cela dit, l'équipe OpenShift pose une question simple :
Comment pouvez-vous rendre le travail avec Kubernetes plus facile et plus pratique ?
La réponse est étonnamment évidente :
- automatiser les aspects complexes du déploiement sur le cloud ou en dehors du cloud ;
- se concentrer sur la fiabilité tout en cachant la complexité ;
- continuer à travailler continuellement pour publier des mises à jour simples et sécurisées ;
- atteindre la contrôlabilité et l’auditabilité ;
- s'efforcer d'assurer initialement une sécurité élevée, mais pas au détriment de la convivialité.
La prochaine version d'OpenShift devrait prendre en compte à la fois l'expérience des créateurs et celle des autres développeurs qui implémentent des logiciels à grande échelle dans les plus grandes entreprises du monde. En outre, elle doit prendre en compte toute l’expérience accumulée des écosystèmes ouverts qui sont à la base du monde moderne d’aujourd’hui. Dans le même temps, il est nécessaire d’abandonner l’ancienne mentalité du développeur amateur et de passer à une nouvelle philosophie d’un avenir automatisé. Il doit combler le fossé entre les anciennes et les nouvelles méthodes de déploiement de logiciels et tirer pleinement parti de toutes les infrastructures disponibles, qu'elles soient hébergées par le plus grand fournisseur de cloud ou exécutées sur de minuscules systèmes en périphérie.
Comment parvenir à ce résultat ?
Chez Red Hat, il est d'usage de faire un travail ennuyeux et ingrat pendant longtemps afin de préserver la communauté établie et d'éviter la fermeture des projets dans lesquels l'entreprise est impliquée. La communauté open source contient un grand nombre de développeurs talentueux qui créent les choses les plus extraordinaires - divertissantes, éducatives, ouvrant de nouvelles opportunités et tout simplement belles, mais, bien sûr, personne ne s'attend à ce que tout le monde avance dans la même direction ou poursuive des objectifs communs. . Capter cette énergie et la réorienter dans la bonne direction est parfois nécessaire pour développer des domaines qui bénéficieraient à nos utilisateurs, mais nous devons en même temps suivre le développement de nos communautés et en tirer des leçons.
Début 2018, Red Hat a acquis le projet CoreOS, qui avait une vision similaire de l'avenir : plus sécurisé et plus fiable, créé selon des principes open source. L'entreprise s'est efforcée de développer davantage ces idées et de les mettre en œuvre, en mettant notre philosophie en pratique : en essayant de garantir que tous les logiciels fonctionnent en toute sécurité. Tout ce travail s'appuie sur Kubernetes, Linux, les cloud publics, les cloud privés et des milliers d'autres projets qui soutiennent notre écosystème numérique moderne.
La nouvelle version d'OpenShift 4 sera claire, automatisée et plus naturelle
La plate-forme OpenShift fonctionnera avec les systèmes d'exploitation Linux les meilleurs et les plus fiables, avec une prise en charge du matériel nu, une virtualisation pratique, une programmation automatique de l'infrastructure et, bien sûr, des conteneurs (qui ne sont essentiellement que des images Linux).
La plate-forme doit être sécurisée dès le départ, tout en permettant aux développeurs d'effectuer des itérations facilement, c'est-à-dire qu'elle doit être suffisamment flexible et sécurisée tout en permettant aux administrateurs de l'auditer et de la gérer facilement.
Il devrait permettre aux logiciels d'être exécutés « en tant que service » et ne pas conduire à une croissance de l'infrastructure ingérable pour les opérateurs.
Cela permettra aux développeurs de se concentrer sur la création de produits réels pour les utilisateurs et les clients. Vous n’aurez pas à parcourir la jungle des paramètres matériels et logiciels, et toutes les complications accidentelles appartiendront au passé.
OpenShift 4 : plateforme NoOps qui ne nécessite pas de maintenance
В a décrit les tâches qui ont contribué à façonner la vision de l'entreprise pour OpenShift 4. L'objectif de l'équipe est de simplifier autant que possible les tâches quotidiennes d'exploitation et de maintenance des logiciels, afin de rendre ces processus faciles et détendus - tant pour les spécialistes impliqués dans la mise en œuvre que pour les développeurs. Mais comment se rapprocher de cet objectif ? Comment créer une plate-forme pour exécuter des logiciels nécessitant une intervention minimale ? Que signifie NoOps dans ce contexte ?
Si vous essayez de faire abstraction, alors pour les développeurs, les concepts de « sans serveur » ou de « NoOps » désignent des outils et des services qui vous permettent de masquer le composant « opérationnel » ou de minimiser cette charge pour le développeur.
- Ne travaillez pas avec des systèmes, mais avec des interfaces d'application (API).
- Ne vous embêtez pas à implémenter un logiciel : laissez le fournisseur le faire pour vous.
- Ne vous lancez pas tout de suite dans la création d'un grand framework - commencez par écrire de petits éléments qui agiront comme des "blocs de construction", essayez de faire fonctionner ce code avec des données et des événements, et non avec des disques et des bases de données.
L'objectif, comme auparavant, est d'accélérer les itérations dans le développement de logiciels, d'offrir la possibilité de créer de meilleurs produits et de faire en sorte que le développeur n'ait pas à se soucier des systèmes sur lesquels son logiciel s'exécute. Un développeur expérimenté est bien conscient que se concentrer sur les utilisateurs peut rapidement changer la donne, vous ne devriez donc pas consacrer trop d'efforts à l'écriture d'un logiciel à moins d'être absolument sûr que cela est nécessaire.
Pour les professionnels de la maintenance et des opérations, le mot « NoOps » peut sembler un peu effrayant. Mais lorsqu'on communique avec les ingénieurs de terrain, il devient évident que les modèles et les techniques qu'ils utilisent pour assurer la fiabilité et la fiabilité (Site Reliability Engineering, SRE) présentent de nombreuses similitudes avec les modèles décrits ci-dessus :
- Ne gérez pas les systèmes, automatisez leurs processus de gestion.
- N'implémentez pas de logiciel - créez un pipeline pour le déployer.
- Évitez de regrouper tous vos services et de laisser la défaillance d'un seul entraîner la défaillance de l'ensemble du système : répartissez-les sur l'ensemble de votre infrastructure à l'aide d'outils d'automatisation et connectez-les de manière à pouvoir être surveillés et surveillés.
Les SRE savent que quelque chose peut mal tourner et qu'ils devront localiser et résoudre le problème. Ils automatisent donc le travail de routine et définissent des budgets d'erreur à l'avance afin d'être prêts à établir des priorités et à prendre des décisions lorsqu'un problème survient.
Kubernetes dans OpenShift est une plate-forme conçue pour résoudre deux problèmes principaux : au lieu de vous obliger à comprendre les machines virtuelles ou les API d'équilibrage de charge, elle fonctionne avec des abstractions d'ordre supérieur : les processus et services de déploiement. Au lieu d'installer des agents logiciels, vous pouvez exécuter des conteneurs et, au lieu d'écrire votre propre pile de surveillance, utiliser les outils déjà disponibles sur la plateforme. Ainsi, la sauce secrète d'OpenShift 4 n'est vraiment pas un secret : il s'agit simplement de prendre les principes SRE et les concepts sans serveur et de les amener à leur conclusion logique pour aider les développeurs et les ingénieurs d'exploitation :
- Automatisez et standardisez l’infrastructure utilisée par les applications
- Reliez les processus de déploiement et de développement sans restreindre les développeurs eux-mêmes
- S'assurer que le lancement, l'audit et la sécurisation du XNUMXème service, fonctionnalité, application ou pile entière ne sont pas plus difficiles que le premier.
Mais quelle est la différence entre la plateforme OpenShift 4 et ses prédécesseurs et par rapport à l'approche « standard » pour résoudre de tels problèmes ? Qu’est-ce qui détermine l’évolutivité des équipes de mise en œuvre et d’exploitation ? En raison du fait que le roi dans cette situation est le cluster. Donc,
- Nous nous assurons que le but des clusters est clair (Cher cloud, j'ai choisi ce cluster parce que je pouvais)
- Des machines et des systèmes d'exploitation existent pour servir le cluster (Votre Majesté)
- Gérer l'état des hôtes du cluster, minimiser leur reconstruction (dérive).
- Pour chaque élément important du système, une nounou (mécanisme) est nécessaire pour surveiller et éliminer les problèmes.
- La défaillance de *chaque* aspect ou élément d'un système et les mécanismes de récupération associés font partie de la vie normale.
- L'ensemble de l'infrastructure doit être configuré via API.
- Utilisez Kubernetes pour exécuter Kubernetes. (Oui, oui, ce n'est pas une faute de frappe)
- Les mises à jour doivent être faciles et sans tracas à installer. S'il faut plus d'un clic pour installer une mise à jour, il est évident que nous faisons quelque chose de mal.
- La surveillance et le débogage de n'importe quel composant ne devraient pas poser de problème, et par conséquent, le suivi et la création de rapports sur l'ensemble de l'infrastructure devraient également être faciles et pratiques.
Vous voulez voir les capacités de la plateforme en action ?
Une version préliminaire d'OpenShift 4 est désormais disponible pour les développeurs. Avec un programme d'installation facile à utiliser, vous pouvez exécuter un cluster sur AWS au-dessus de Red Had CoreOS. Pour utiliser l'aperçu, vous n'avez besoin que d'un compte AWS pour provisionner l'infrastructure et d'un ensemble de comptes pour accéder aux images d'aperçu.
- Pour commencer, allez sur et cliquez sur « Commencer ».
- Connectez-vous à votre compte Red Hat (ou créez-en un nouveau) et suivez les instructions pour configurer votre premier cluster.
Après une installation réussie, consultez nos tutoriels pour mieux comprendre les systèmes et les concepts qui font de la plate-forme OpenShift 4 un moyen si simple et pratique d'exécuter Kubernetes.
Essayez la nouvelle version d'OpenShift et partagez votre opinion. Nous nous engageons à rendre le travail avec Kumbernetes aussi accessible et simple que possible : l'avenir de NoOps commence aujourd'hui.
Et maintenant attention!
À la conférence Le 20 avril, l'un des développeurs d'OpenShift, Vadim Rutkovsky, organisera une master class : il brisera dix clusters et les forcera à les réparer. La conférence est payante, mais avec le code promotionnel #RedHat vous bénéficiez d'une réduction de 37%
Master class de 17h15 à 18h15, et le stand est ouvert toute la journée. T-shirts, chapeaux, autocollants – comme d'habitude !
Salle #2
"Ici, c'est tout le système qui doit être changé : nous réparons les clusters K8 cassés en collaboration avec des mécaniciens certifiés."
Source: habr.com