Une plateforme moderne pour le développement et le déploiement de logiciels

Ceci est la première publication d'une série de matériaux consacrés aux changements, améliorations et ajouts dans la prochaine mise à jour de la plateforme Red Hat OpenShift vers la version 4.0, qui aidera à préparer la transition vers la nouvelle version.

Depuis le moment où des représentants de la communauté Kubernetes en pleine formation se sont réunis pour la première fois à l'automne 2014 dans les bureaux de Google à Seattle, il était déjà évident que le projet Kubernetes allait profondément transformer les approches modernes du développement et du déploiement de logiciels. Parallèlement, les fournisseurs de services cloud publics ont continué à investir massivement dans le développement d'infrastructures et de services, rendant considérablement plus facile et accessible le travail avec l'IT et la création de logiciels, ce que peu de gens pouvaient imaginer au début de la décennie.

Il va sans dire que l'annonce de chaque nouveau service cloud était accompagnée de nombreuses discussions d'experts sur Twitter, avec des débats sur une variété de sujets – y compris la fin de l'ère des codes ouverts, le déclin de l'IT sur site (on-premises IT), l'inévitabilité d'un nouveau monopole logiciel dans le cloud, et comment la nouvelle paradigme X remplacera tous les autres paradigmes.

Faut-il dire que tous ces débats étaient plutôt ridicules

La réalité est que rien ne disparaît nulle part, et aujourd'hui, on peut observer une croissance exponentielle des produits finaux et des méthodes de développement, ce qui est lié à l'apparition constante de nouveaux logiciels dans nos vies. Et malgré le fait que tout autour changera, en essence, tout restera inchangé. Les développeurs continueront à écrire du code contenant des erreurs, les ingénieurs d'exploitation et les spécialistes de la fiabilité continueront à utiliser des pagers et à recevoir des alertes automatiques sur Slack, les managers continueront de jongler avec les concepts d'OpEx et de CapEx, et chaque fois qu'une défaillance se produira, le développeur senior poussera un triste soupir en disant : « Je l'avais dit »…

Ce qui devrait vraiment être discuté, c'est ce que nous pouvons obtenir comme outils pour créer des produits logiciels de meilleure qualité, et comment ils permettent d'améliorer la sécurité et de rendre le développement plus simple et fiable. Avec l'augmentation de la complexité des projets, de nouveaux risques apparaissent, et aujourd'hui, la vie des gens dépend tellement du logiciel que les développeurs doivent absolument s'efforcer de bien faire leur travail.

Kubernetes est l'un de ces outils. Des efforts sont en cours pour l'intégrer, dans le cadre de Red Hat OpenShift, avec d'autres outils et services en une seule plateforme, afin de rendre le logiciel plus fiable, facile à gérer et sûr pour les utilisateurs.

Dans cette optique, l'équipe OpenShift se pose une simple question :

Comment rendre le travail avec Kubernetes plus simple et agréable ?

La réponse est étonnamment évidente :

• automatiser les moments complexes du déploiement, qu'il soit dans le cloud ou hors cloud ;
• se concentrer sur la fiabilité tout en cachant la complexité ;
• continuer à travailler sur la sortie d'updates simples et sécurisées ;
• assurer une contrôlabilité et une possibilité d'audit ;
• viser à garantir une haute sécurité dès le départ, sans compromettre l'utilisabilité.

La prochaine version d'OpenShift doit tenir compte de l'expérience des créateurs ainsi que de celle d'autres développeurs, qui mettent en œuvre des logiciels à grande échelle dans les plus grandes entreprises du monde. De plus, elle doit intégrer l'ensemble de l'expérience accumulée des écosystèmes ouverts qui sont à la base du monde moderne. Il est essentiel d'abandonner l'ancienne mentalité du développeur amateur et d'adopter une nouvelle philosophie axée sur un avenir automatisé. Cela doit être un « pont » entre les anciennes et les nouvelles méthodes de déploiement de logiciels et tirer pleinement parti de toute l'infrastructure disponible – qu'elle soit gérée par le plus grand fournisseur de cloud ou déployée sur de petits systèmes en périphérie.

Comment atteindre un tel résultat ?

Chez Red Hat, il est courant de consacrer beaucoup de temps à des tâches fastidieuses et ingrate afin de préserver la communauté qui s'est formée et d'éviter la fermeture des projets auxquels l'entreprise participe. La communauté open-source est composée d'un grand nombre de développeurs talentueux qui créent des choses extraordinaires — des divertissements, de l'éducation, de nouvelles opportunités, et simplement de la beauté. Bien entendu, personne ne s'attend à ce que tous les participants avancent dans la même direction ou poursuivent des objectifs communs. Tirer parti de cette énergie, la réorienter dans la bonne direction est parfois nécessaire pour développer des axes qui seraient bénéfiques pour nos utilisateurs, mais nous devons également surveiller l'évolution de nos communautés et en tirer des enseignements.

Au début de 2018, Red Hat a acquis le projet CoreOS, qui partageait des visions similaires pour l'avenir - plus sûr et plus fiable, basé sur les principes de l'open-source. L'entreprise a travaillé à l'avancement de ces idées et à leur réalisation, concrétisant notre philosophie - en cherchant à garantir un fonctionnement sécurisé de tout le logiciel. Tout ce travail repose sur Kubernetes, Linux, les clouds publics, les clouds privés, et des milliers d'autres projets qui constituent notre écosystème numérique moderne.

La nouvelle version d'OpenShift 4 sera claire, automatisée et plus intuitive.

La plateforme OpenShift fonctionnera avec les meilleurs et les plus fiables systèmes d'exploitation Linux, avec un support matériel bare-metal, une virtualisation conviviale, une programmation automatique des infrastructures et, bien sûr, des conteneurs (qui sont essentiellement des images Linux).

La plateforme doit être sécurisée dès le départ, tout en offrant la possibilité d'itérations confortables pour les développeurs - c'est-à-dire qu'elle doit disposer d'une flexibilité et d'une fiabilité suffisantes, tout en permettant aux administrateurs de réaliser des audits et de faciliter la gestion.

Elle doit permettre de faire fonctionner des logiciels « en tant que service », sans mener à une expansion incontrôlée de l'infrastructure pour les opérateurs.

Cela permettra aux développeurs de se concentrer sur la création de véritables produits pour les utilisateurs et les clients. Ils n'auront plus à naviguer à travers les méandres des configurations matérielles et logicielles, et tous les complications aléatoires appartiendront au passé.

OpenShift 4 : une plateforme NoOps sans maintenance requise

Dans cet article Les tâches qui ont aidé à façonner la vision de l'entreprise concernant OpenShift 4 ont été décrites. L'équipe a pour mission de simplifier au maximum les tâches quotidiennes liées à l'exploitation et à la maintenance du logiciel, rendant ces processus faciles et décontractés – tant pour les spécialistes de l'implémentation que pour les développeurs. Mais comment peut-on atteindre cet objectif ? Comment créer une plateforme de déploiement de logiciels nécessitant un minimum d'intervention ? Que signifie réellement NoOps dans ce contexte ?

Si l'on essaie de s'abstraire, pour les développeurs, les concepts de « serverless » ou de « NoOps » signifient des outils et des services permettant de cacher la composante « opérationnelle » ou de minimiser ce fardeau pour le développeur.

• Travaillez non pas avec des systèmes, mais avec des interfaces de programmation (API).
• Ne vous occupez pas de l'implémentation du logiciel – laissez un fournisseur s'en charger à votre place.
• Il ne faut pas chercher à créer d'emblée un grand cadre – commencez par écrire de petits fragments qui serviront de « blocs de construction », veillez à ce que ce code fonctionne 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, de permettre la création de produits de meilleure qualité, et que le développeur ne se préoccupe pas des systèmes sur lesquels son logiciel est exécuté. Un développeur expérimenté sait très bien que si l'on se concentre sur les utilisateurs, la situation peut rapidement changer, c'est pourquoi il ne faut pas investir trop d'efforts dans l'écriture de logiciels si vous n'avez pas la certitude absolue de leur nécessité.

Pour les professionnels impliqués dans la maintenance et l'exploitation, le terme « NoOps » peut sembler quelque peu intimidant. Cependant, lors de discussions avec des ingénieurs en opérations, il devient évident que les modèles et méthodes qu'ils utilisent pour garantir la fiabilité du système (Site Reliability Engineering, SRE) résonnent en grande partie avec les modèles décrits ci-dessus.

• Ne gérez pas les systèmes – automatisez les processus de gestion.
• Ne vous concentrez pas sur l'intégration des logiciels – créez un pipeline pour leur déploiement.
• Essayez de ne pas regrouper tous vos services et évitez qu'un échec d'un d'eux entraîne l'échec du système entier – répartissez-les sur toute l'infrastructure en utilisant des outils d'automatisation, et connectez-les en prévoyant des possibilités de contrôle et de surveillance.

Les spécialistes en SRE savent que quelque chose peut mal tourner, et qu'ils devront surveiller et résoudre le problème – c'est pourquoi ils automatisent les tâches répétitives et définissent à l'avance des écarts acceptables (budgets d'erreur), afin d'être prêts à prioriser et à prendre des décisions en cas de problème.

Kubernetes dans OpenShift est une plateforme conçue pour résoudre deux principaux défis : au lieu de vous obliger à gérer des machines virtuelles ou des interfaces API de load balancers, elle travaille avec des abstractions de niveau plus élevé – déploiements et services. Au lieu d'installer des agents logiciels, vous pouvez exécuter des conteneurs, et plutôt que d'écrire votre propre pile de surveillance, utilisez les outils déjà disponibles sur la plateforme. Ainsi, l'ingrédient secret d'OpenShift 4 n'est en réalité pas un mystère – il suffit d'adopter les principes SRE et les concepts sans serveur, et de les mener à terme, pour aider les développeurs et les ingénieurs des opérations.

• Automatiser et standardiser l'infrastructure utilisée par les applications.
• Lier les processus de déploiement et de développement, sans limiter les développeurs eux-mêmes.
• S'assurer que le lancement, l'audit et la sécurisation du centième service, fonction, application ou ensemble de services ne soit pas plus complexe que celui du premier.

Mais quelle est la différence entre la plateforme OpenShift 4 et ses prédécesseurs, ainsi que par rapport à l'approche « standard » pour résoudre de tels problèmes ? Comment le scaling pour les équipes chargées de l'implémentation et de l'exploitation est-il atteint ? Parce que le roi dans cette situation, c'est le cluster. Donc,

• Nous faisons en sorte que la fonction des clusters soit claire (Cloud coûteux, j'ai créé ce cluster parce que j'ai pu)
• Les machines et les systèmes d'exploitation existent pour servir le cluster (Votre Majesté)
• Gérez l'état des hôtes depuis le cluster, minimisez leurs dérives.
• Pour chaque élément important du système, un mécanisme (nounou) est nécessaire pour surveiller et résoudre les problèmes.
• La défaillance de *chaque* aspect ou élément du système doit être suivie par les mécanismes de récupération - c'est une partie normale de la vie.
• Toute l'infrastructure doit être configurée via API.
• Utilisez Kubernetes pour faire fonctionner Kubernetes. (Oui, ce n'est pas une faute de frappe)
• Les mises à jour doivent être installées facilement et sans contrainte. Si l'installation d'une mise à jour nécessite plus d'un clic de souris, il est évident que vous faites quelque chose de travers.
• La surveillance et le débogage de tout composant ne doivent pas poser de problème, et par conséquent, le suivi et la création de rapports sur l'ensemble de l'infrastructure doivent également être simples et commodes.

Voulez-vous voir les capacités de la plateforme en action ?

La version bêta d'OpenShift 4 est disponible pour les développeurs. Avec un installateur facile à utiliser, vous pouvez déployer un cluster sur AWS avec Red Hat CoreOS. Pour profiter de la version bêta, il suffit d'un compte AWS pour fournir l'infrastructure et d'un ensemble de comptes pour accéder aux images de la version bêta.

1. Pour commencer, allez sur try.openshift.com et cliquez sur “Get Started”.
2. Connectez-vous à votre compte Red Hat (ou créez-en un nouveau) et suivez les instructions pour configurer votre premier cluster.

Après l'installation réussie, consultez nos ressources d'apprentissage OpenShift Training, pour avoir une vision plus approfondie des systèmes et concepts qui rendent la plateforme OpenShift 4 si simple et pratique pour déployer Kubernetes.

Essayez la nouvelle version d'OpenShift et partagez votre avis. Nous nous efforçons de rendre l'utilisation de Kubernetes aussi accessible et sans effort que possible – l'avenir de NoOps commence dès aujourd'hui.

Maintenant, attention !
À la conférence DevOpsForum 2019 Le 20 avril, l'un des développeurs d'OpenShift, Vadim Rutkovski, animera un atelier — il va casser dix clusters et les réparera ensuite. La conférence est payante, mais avec le code promo #RedHat, bénéficiez d'une réduction de 37%

L'atelier se déroule de 17h15 à 18h15, et le stand est ouvert toute la journée. T-shirts, chapeaux, autocollants – comme d'habitude !

Salle #2
« Il faut tout changer dans le système : réparons ensemble des clusters k8s cassés avec des mécaniciens certifiés ».

Source : habr.com