OpenShift 4.0 - se préparer pour l'hyper saut

Il s'agit du premier d'une série de nos publications consacrées aux améliorations et ajouts de la prochaine mise à jour de la plate-forme Red Hat OpenShift vers la version 4.0, qui vous aideront à préparer la transition vers la nouvelle version.



Quels outils pouvez-vous mettre à votre disposition pour créer de meilleurs logiciels et comment amélioreront-ils la sécurité et rendront-ils le développement plus facile et plus fiable?

Dès le moment où les représentants de la communauté Kubernetes nouvellement formée se sont réunis pour la première fois à l'automne 2014 au bureau de Google à Seattle, on peut déjà dire que le projet Kubernetes était destiné à changer fondamentalement les approches modernes du développement et de la mise en œuvre des logiciels. Dans le même temps, les fournisseurs de services de cloud public ont continué à investir activement dans le développement des infrastructures et des services, ce qui a grandement facilité et simplifié le travail avec les TI et la création de logiciels, et les a rendus incroyablement abordables, ce que peu auraient pu imaginer au début de la décennie.

Bien entendu, l'annonce de chaque nouveau service cloud s'est accompagnée de nombreuses discussions d'experts sur Twitter, et des litiges ont eu lieu sur une variété de sujets - dont la fin de l'ère open source, le déclin de l'informatique côté client (informatique sur site), l'inévitabilité d'un nouveau monopole logiciel dans le cloud, et comment le nouveau paradigme X remplacera tous les autres paradigmes.

Cependant, la réalité est que rien ne disparaît, et aujourd'hui vous pouvez observer la croissance exponentielle des produits finaux et des méthodes de leur développement, qui est associée à l'émergence constante de nouveaux logiciels dans nos vies. Et malgré le fait que tout autour changera, en même temps, en substance, tout restera inchangé. Les développeurs de logiciels continueront à écrire du code avec des erreurs, les ingénieurs de maintenance et les spécialistes de la fiabilité continueront à marcher avec les pagers et à recevoir des alertes automatiques dans Slack, les gestionnaires continueront de fonctionner sur les concepts d'OpEx et de CapEx, et chaque fois qu'une défaillance se produira, le développeur soupira tristement avec les mots: "J'ai dit" ...

Avec la complexité croissante des projets, de nouveaux risques apparaissent également, et aujourd'hui la vie des gens dépend tellement des logiciels que les développeurs sont simplement obligés d'essayer de mieux faire leur travail.

Kubernetes est l'un de ces outils. Des travaux sont en cours pour l'intégrer à d'autres outils et services dans une plate-forme unique dans le cadre de Red Hat OpenShift, ce qui rendrait le logiciel plus fiable, facile à gérer et sûr pour les utilisateurs.

Cela dit, la question se pose: comment rendre le travail avec Kubernetes plus facile et plus pratique?

La réponse peut sembler étonnamment simple:

• Automatisez les moments complexes lors du déploiement sur le cloud ou en dehors du cloud
• se concentrer sur la fiabilité tout en cachant la complexité;
• Continuez à travailler sur la publication de mises à jour simples et sécurisées
• atteindre les capacités de contrôlabilité et d'audit;
• s'efforcer de fournir 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 l'expérience des autres développeurs qui mettent en œuvre des logiciels à grande échelle dans les plus grandes entreprises du monde. En outre, il est nécessaire de prendre en compte toute l'expérience accumulée des écosystèmes ouverts qui forment aujourd'hui la base du monde moderne. Dans ce cas, il faut abandonner l'ancienne mentalité de développeur amateur et passer à une nouvelle philosophie d'un avenir automatisé. Il devrait être un «pont» entre les anciennes et les nouvelles façons de déployer les logiciels et de tirer pleinement parti de toutes les infrastructures disponibles - peu importe qu'ils soient gérés par le plus grand fournisseur de cloud ou qu'ils fonctionnent sur de petits systèmes à la périphérie.

Comment obtenir un tel résultat?

Chez Red Hat, il est de coutume de faire un travail ennuyeux et ingrat pendant une longue période afin de préserver la communauté établie et d'empêcher la fermeture des projets auxquels l'entreprise participe. La communauté open-source se compose d'un grand nombre de développeurs talentueux qui créent les choses les plus extraordinaires - divertissantes, éducatives, découvrant de nouvelles opportunités et tout simplement belles, mais, bien sûr, personne ne s'attend à ce que tous les participants évoluent dans la même direction ou poursuivent des objectifs communs. L'utilisation de cette énergie, sa réorientation dans la bonne direction, est parfois nécessaire au développement de zones qui seraient utiles à nos utilisateurs, mais en même temps, nous devons surveiller 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 des vues similaires sur l'avenir - une approche open source plus sûre et fiable. L'entreprise a travaillé au développement de ces idées et à leur mise en œuvre, mettant en œuvre notre philosophie - en essayant de garantir un fonctionnement sûr de tous les logiciels. Tout ce travail s'appuie sur Kubernetes, Linux, les clouds publics, les clouds privés et les milliers d'autres projets qui sous-tendent notre écosystème numérique moderne.

La nouvelle version d'OpenShift 4 sera compréhensible, automatisée et plus naturelle

La plate-forme OpenShift fonctionnera avec les systèmes d'exploitation Linux les meilleurs et les plus fiables, avec un support 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ûre dès le début, mais en même temps, offrir aux développeurs la possibilité d'itérations pratiques - c'est-à-dire, avoir une flexibilité et une fiabilité suffisantes, tout en permettant aux administrateurs d'auditer et de faciliter la gestion.

Il doit vous permettre d'exécuter le logiciel "sous forme de service", et ne pas conduire à une expansion incontrôlée de l'infrastructure des opérateurs.

Il permettra aux développeurs de se concentrer sur la création de vrais produits pour les utilisateurs et les clients. Pas besoin de déchirer la jungle des paramètres matériels et logiciels, et toutes les complications aléatoires appartiendront au passé.

OpenShift 4: la plate-forme NoOps ne nécessite pas de maintenance

Cette publication décrit les tâches qui ont contribué à façonner la vision de l'entreprise pour OpenShift 4. L'équipe a pour tâche de simplifier au maximum les tâches quotidiennes d'exploitation et de maintenance des logiciels, rendant ces processus faciles et sans effort, à la fois pour les spécialistes de l'implémentation et pour les développeurs. Mais comment aborder cet objectif? Comment créer une plateforme de lancement de logiciel qui nécessite une intervention minimale? Que signifie NoOps dans ce contexte?

Si vous essayez de l'ignorer, alors pour les développeurs, les concepts «sans serveur» ou «NoOps» signifient des outils et des services qui vous permettent de masquer le composant «opérationnel» ou de minimiser cette charge pour le développeur.

• Ne fonctionne pas avec des systèmes, mais avec des interfaces d'application (API).
• N'implémentez pas de logiciel - laissez un fournisseur le faire à votre place.
• Vous ne devez pas immédiatement entreprendre la création d'un grand framework - commencez par écrire de petits fragments qui serviront de "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.

La tâche, comme auparavant, est d'accélérer les itérations dans le développement de logiciels, de fournir la possibilité de créer de meilleurs produits, et de sorte que le développeur ne puisse pas se soucier des systèmes sur lesquels son logiciel fonctionne. Un développeur expérimenté est bien conscient que si vous vous concentrez sur les utilisateurs, l'image peut changer rapidement, vous ne devez donc pas faire trop d'efforts pour écrire un logiciel si vous n'avez pas une confiance absolue dans sa nécessité.

Pour les professionnels impliqués dans la maintenance et l'exploitation, le mot «NoOps» peut sembler quelque peu intimidant. Mais en communiquant avec les ingénieurs d'exploitation, il devient évident que les modèles et les méthodes qu'ils utilisent, visant à garantir la fiabilité de la fiabilité (Site Reliability Engineering, SRE), chevauchent largement les modèles décrits ci-dessus:

• Ne gérez pas les systèmes - automatisez leurs processus de gestion.
• Ne pas implémenter de logiciel - créez un pipeline pour son déploiement.
• Essayez de ne pas combiner tous vos services et ne laissez pas la défaillance de l'un d'entre eux entraîner la défaillance de l'ensemble du système - dispersez-les dans l'infrastructure en utilisant des outils d'automatisation et connectez-les, offrant la possibilité de contrôle et de surveillance.

Les spécialistes SRE savent que quelque chose peut mal tourner et ils devront suivre et résoudre le problème - par conséquent, ils automatisent la routine et déterminent à l'avance les tolérances d'erreur afin d'être prêts à établir des priorités et à prendre des décisions lorsqu'un problème survient. .

Kubernetes d'OpenShift est une plateforme conçue pour résoudre deux tâches principales: au lieu de vous forcer à traiter avec des machines virtuelles ou des API d'équilibrage de charge, travaillez avec des abstractions d'ordre supérieur - avec des processus et des 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, utilisez les outils déjà disponibles sur la plate-forme. Ainsi, l'ingrédient secret d'OpenShift 4 ne représente en fait aucun secret - il vous suffit de prendre les principes du SRE et des concepts sans serveur comme base, et de les amener à leur conclusion logique, pour aider les développeurs et les ingénieurs de maintenance:

• Automatisez et standardisez l'infrastructure utilisée par les applications
• Rassemblez les processus de déploiement et de développement sans limiter les développeurs eux-mêmes
• Garantir que le lancement, l'audit et la sécurité d'un centième service, fonction, application ou pile entière n'est pas plus difficile que le premier.

Mais quelle est la différence entre la plate-forme OpenShift 4 et ses prédécesseurs et l'approche «standard» pour résoudre de tels problèmes? Comment évolue-t-on pour les équipes de mise en œuvre et d'exploitation? En raison du fait que le roi dans cette situation est un cluster. Alors

• Nous rendons le but des clusters compréhensible (Cher nuage, j'ai soulevé ce cluster parce que je pouvais)
• Des machines et des systèmes d'exploitation existent pour desservir le cluster (Votre Majesté)
• Gérez l'état des hôtes à partir du cluster, minimisez leur reconstruction (dérive).
• Pour chaque élément important du système, un nounou (mécanisme) est nécessaire pour suivre et résoudre les problèmes
• Échec * de chaque * aspect ou élément du système; les mécanismes de récupération correspondants font partie de la vie ordinaire
• L'ensemble de l'infrastructure doit être configuré via l'API.
• Utilisez Kubernetes pour lancer Kubernetes. (Oui, oui, ce n'est pas une faute de frappe)
• Les mises à jour doivent être installées facilement et naturellement. S'il faut plus d'un clic pour installer la mise à jour, alors évidemment vous \ nous faisons quelque chose de mal.
• La surveillance et le débogage de n'importe quel composant ne devraient pas être un problème et, par conséquent, le suivi et les rapports sur l'ensemble de l'infrastructure devraient également être simples et pratiques.

Vous voulez voir les capacités de la plateforme en action?

Une version préliminaire d'OpenShift 4 est devenue disponible pour les développeurs. Avec un programme d'installation facile à utiliser, vous pouvez exécuter un cluster AWS sur Red Had CoreOS. Pour utiliser la version d'aperçu, vous n'avez besoin que d'un compte AWS pour fournir l'infrastructure et un ensemble de comptes pour accéder aux images de la version d'aperçu.

1. Pour commencer, allez sur try.openshift.com et cliquez sur «Commencer».
2. 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 de formation OpenShift pour en savoir plus sur les systèmes et les concepts qui font de la plate-forme OpenShift 4 un outil simple et pratique pour lancer Kubernetes.

Et lors de la conférence DevOpsForum 2019 , l'un des développeurs d'OpenShift, Vadim Rutkovsky, tiendra une master class `` Ici, vous devez changer tout le système: réparer les clusters k8s cassés avec des serruriers certifiés '' - il cassera dix clusters et montrera comment les réparer.

L'entrée à la conférence est payante, mais en utilisant le code promo #RedHat - 37% de réduction.

Nous vous attendons le 20 avril lors d'une master class dans le Hall # 2 à 17h15, et sur notre stand - toute la journée. Informations utiles sur les produits, rencontre avec des experts, T-shirts, chapeaux, autocollants Red Hat - tout est comme d'habitude! :-)