Dans une grande entreprise, il est souvent très difficile de coordonner l'allocation des ressources pour les tâches de travail. Tout Agile croque contre le mur d'un accord de trois semaines avec le SI d'une nouvelle infrastructure. Par conséquent, nous recevons souvent des demandes de transfert de l'infrastructure vers des conteneurs afin de déployer les modifications non pas tous les trois mois et lorsque l'entreprise en a besoin. En même temps, ils demandent de configurer / implémenter Kubernetes comme l'instrument d'orchestration le plus populaire, bien que, comme le montre la pratique, sur 10 projets, un maximum de trois soit nécessaire. Mais en fait, cela vaut la peine d'utiliser Kubernetes, mais OpenShift, ou de travailler avec lui non pas dans votre infrastructure, mais dans un cloud public, par exemple. Je vais essayer de parler des cas réels que nous avons décidés, je vais décrire les principales différences entre Kubernetes et OpenShift. Et aussi sur la façon dont nous avons réduit la coordination de la sécurité de l'information à 30 minutes, et tout est resté en vie.
Nous avons eu plusieurs implémentations intéressantes dans lesquelles nous avons ratissé les problèmes accumulés du client. Par exemple, une entreprise de vente au détail est venue vers nous qui avait besoin de déployer de nouvelles puces en continu. La compétition est folle! Et ils ne disposent que de l'infrastructure de développement chaque fois que cela prend de six à dix jours, ce qui entraîne des temps d'arrêt. Résoudre le problème en achetant du nouveau matériel pour les tests et le développement coûte cher et ne mène nulle part. En conséquence, nous avons transféré l'infrastructure informatique vers la virtualisation de conteneurs. En conséquence, grâce aux conteneurs, la charge a été réduite de 40%, et l'infrastructure pour le nouveau développement est maintenant préparée de une à quatre heures. Le bonus est une économie, car tous les processus pourraient continuer à être menés sur la base des capacités existantes sans en acheter de nouvelles.
Qu'allons-nous faire de la sécurité de l'information?
IB sont des personnes très nécessaires. Ils vont souvent un peu trop loin dans leurs exigences internes pour les projets, mais c'est bien mieux que de voir une fois que vos pirates roumains ont entouré votre serveur SFTP externe.
Mais il y a un problème avec eux. Si nous considérons le processus commercial comme un convoyeur, leur division devient souvent le goulot d'étranglement sur lequel tout le monde repose. D'une part, ils sont responsables de tous les risques liés à la sécurité, d'autre part, ils n'arrivent tout simplement pas à visualiser manuellement le code et tous les détails de l'architecture du nouveau produit.
La situation est très similaire à celle des services de sécurité dans les zones à forte affluence. Nous pouvons organiser une inspection totale de chaque passager dans le métro, le faire briller sur des scanners, tordre les poches et inspecter le téléphone. Par conséquent, au lieu de la sécurité, vous obtiendrez un effondrement complet du transport et une paralysie du système. La seule option dans cette situation est l'organisation de systèmes automatisés qui répondront, par exemple, aux individus, identifieront les personnes recherchées ou réagiront à un comportement anormal.
Dans notre contexte, de tels systèmes automatisés sont des processus CI / CD correctement organisés avec des analyseurs de code à des étapes intermédiaires, telles que des solutions JFrog Xray pour Artifactory, et des écrous Kubernetes / OpenShift correctement serrés, qui ne permettent pas d'approches dangereuses comme le lancement d'un conteneur à partir de l'utilisateur root. Nous préparons maintenant une solution en boîte qui fournira tout cela.
L'objectif est de passer du concept de "n'entrera pas dans la vente tant que nous ne chercherons pas" à "s'il n'y a pas d'objection, il sera déployé automatiquement". Il n'y a aucun intérêt à l'automatisation si les processus organisationnels restent les mêmes.
Dans l'un des projets, nous avons réussi à réduire le temps de défaillance du SI à 30 minutes. En d'autres termes, si, dans une demi-heure, le «gardien de sécurité» ne rejette pas l'action, elle est automatiquement approuvée et les modifications sont mises en production. Maintenant, nous essayons d'atteindre un délai de 60 minutes pour tous les coordinateurs du projet sans compromettre la sécurité.
Quelle est la différence entre les systèmes de gestion de conteneurs?
Kubernetes et OpenShift sont les principales solutions pour l'orchestration de conteneurs. Analysons les principales différences et avantages pour l'entreprise.
OuvertureKubernetes est un produit entièrement ouvert qui peut être déployé indépendamment et entretenu seul ou avec un support externe. La situation sur le marché du travail s'est déjà plus ou moins stabilisée et trouver des experts sur ce sujet n'est plus un problème.
OpenShift est un produit semi-fermé avec un système de licence sophistiqué de RedHat. En fait, il contient Kubernetes, mais il a un tas de liaisons supplémentaires qui simplifie de nombreuses tâches. Le fournisseur fournit un support payant complet pour son produit.
Ici, le choix dépend de ce qui vous convient le mieux - le soutien des forces de vos spécialistes ou de votre fournisseur.
PlateformesKubernetes fonctionne sur presque toutes les plateformes Linux et la plupart des fournisseurs de cloud.
OpenShift ne fonctionne nulle part sauf sur RHEL, Red Hat Atomic, Red Hat CoreOS. Il existe une version communautaire - OKD, mais elle est étroitement liée aux distributions. La seule exception est qu'il peut être installé sur CentOS. Et gardez à l'esprit qu'officiellement Red Hat ne garantit pas un support payant.
Politiques de sécuritéOpenShift prêt à l'emploi a des paramètres de sécurité plus stricts. C'est un plus lors du déploiement de l'infrastructure à partir de zéro, mais cela peut être un problème en raison de l'incompatibilité de certaines images avec les politiciens. Par exemple, dans OpenShift, il est interdit d'exécuter le conteneur à partir de root, ce qui rompt la compatibilité avec les anciennes images. D'un autre côté, cette approche, combinée à une intégration pratique avec AD, une journalisation pratique sur la base de la pile EFK (ElasticSearch, Fluentd, Kibana) nous donne la sécurité même prête à l'emploi pour décharger l'unité IS.
Kubernetes peut également être terminé à ce niveau, mais cela nécessitera beaucoup d'efforts et de temps de la part des ingénieurs.
PatternsLes modèles OpenShift sont moins flexibles que les graphiques Kubernetes Helm. En raison de politiques de sécurité plus strictes, Red Hat ne peut pas fournir la flexibilité des graphiques Helm pour le moment. Cependant, dans OpenShift 4, la situation s'est stabilisée grâce à l'
OperatorHub intégré.
Avoir des modèles bien conçus prêts à l'emploi facilite la vie. En fait, il s'agit d'une telle option de gestionnaire de packages pour créer et configurer divers services.
Une commande conditionnelle «helm install prometheus-operator» déploie un système assez complexe, qui met très longtemps à se déployer. Kubernetes ouvre la voie.
Conclusions généralesComme la plupart des produits, Red Hat OpenShift est une solution plus encadrée, mais plus résistante sur le plan architectural. Il faut du personnel moins aux yeux rouges et plus expérimenté pour travailler. Scénarios de déploiement plus pratiques, excellente intégration avec les solutions CI / CD, en particulier avec Jenkins. OpenShift est idéal pour les entreprises qui sont plus faciles à payer pour prendre en charge un produit fini que pour embaucher leurs propres spécialistes.
Pour les entreprises possédant de solides spécialistes dans ce domaine, Kubernetes peut être une solution plus flexible et intéressante. Il peut également convenir à une entreprise relativement petite qui souhaite économiser sur les licences Red Hat, mais n'a pas de tâches complexes qui nécessitent des experts hautement qualifiés.
Cas réels
J'essaierai de montrer comment les technologies de conteneurisation ont aidé à résoudre les problèmes commerciaux, enregistré les licences et assuré le lissage des pics de charge lors des raids de masse des utilisateurs.
Étude de cas: commerce électronique
Le problèmeLe client disposait de plus de 100 services actifs exécutant la fondation cloud de VMware. Et tout ce parc a eu plusieurs problèmes différents:
- 12 services exigeants en ressources et sans marge ont été lancés sur VMware, consommant un budget d'environ 408 000 $ par an.
- Trois services (un portail et deux applications mobiles) ont commencé à se développer activement: en sept mois, les ressources nécessaires au travail ont augmenté de 4,5 fois et continuent de croître.
- Plusieurs services clients connaissent des pics de charge, au cours desquels les ressources sont nécessaires six à sept fois plus qu'en temps normal. En conséquence, du matériel a été alloué pour leur bon fonctionnement, qui la plupart du temps a été utilisé par moins de 15%.
En plus de tout cela, le client souhaite ne plus se lier Ă un seul fournisseur de virtualisation.
Notre décisionLa première et la plus simple solution: nous transférons des services avec des pics vers le
cloud CROC public . Avec facturation des ressources consommées. Tout est aussi simple et ennuyeux que possible. Passer du VMware de quelqu'un à notre KVM est l'un des cas les plus fréquents pour les ingénieurs cloud.
Étant donné que le matériel de mise à l'échelle a déjà été acheté par le client, nous n'avons eu qu'à calculer les licences. Pour les nouveaux hôtes de VMware, ils ont coûté environ 2 100 000 $, ce qui ne convenait pas beaucoup au client. Nous avons proposé de transférer certains des services vers KVM exécutant OpenStack. Et pour ne pas se perdre, intégrez la gestion des deux infrastructures par CloudForms (et en même temps OpenShift).
En conséquence, le client a reçu la deuxième épaule d'un cloud privé basé sur OpenStack, ce qui a clos la question du fournisseur. En déplaçant certains des services gourmands en ressources vers une nouvelle épaule, il s'est avéré réduire le coût des licences VMware (la prise en charge 24h / 24 et 7j / 7 du CROC s'est avérée moins coûteuse).
Cas: Retail
Le problèmeAu cours de l'audit, il s'est avéré que quelque chose de terrible se passait avec le client concernant l'allocation des infrastructures. Projets - plus de 250, équipes de développement - plus de 150, demi-conteneurs sur Kubernetes. Les ressources pour chaque nouveau projet sont achetées et y restent affectées sans possibilité de sélection, même si elles ne sont pas utilisées. Il n'y a aucune facturation, il n'y a pas de portail unique. Coûts énormes pour les environnements de test et de pré-production, car ils tournent également sur VMware.
Dans le même temps, le client ne veut pas passer complètement à une nouvelle plateforme et veut tout assembler sous un portail de gestion unique. De plus, «tout» n'est pas seulement VMware, mais aussi PaaS, des conteneurs et une facturation unique.
Notre décisionEn conséquence, à l'intérieur de la solution s'est avérée plutôt entassée, mais à l'extérieur pour le client, tout semble extrêmement simple.
Le répertoire dans lequel l'utilisateur sélectionne les paramètres de la machine virtuelle et le circuit nécessaire: DevTest, PreProd, Prod. Et puis CloudForms choisit où déployer la ressource demandée: sur VMware ou sur OpenShift. Nous travaillons toujours sur la facturation unique, car la solution hybride VMware + OpenShift est assez difficile à mettre en place.
En fait, de cette façon, nous mettons les choses en ordre dans l'infrastructure, en triant les décombres que le client a entassés.
Cas: Industrie
Le problèmeLa copie de VM dans différents environnements (Test, Dev, Prod, Preprod) prend plus de trois jours et nécessite l'exécution manuelle de 15 opérations différentes, chacune prenant jusqu'à 30 minutes. Un audit approfondi a montré qu'auparavant, il avait fallu deux semaines pour allouer des ressources à un nouveau projet, et qu'il y avait 10 à 20 demandes par mois. Il y a maintenant plus de dix demandes de ressources par jour, ce qui, sans automatisation, a entraîné un effondrement.
Notre décisionEn fait, le client devait transférer l'infrastructure informatique vers un modèle de service, reconstruire et automatiser le processus de modification de l'infrastructure, créer un portail libre-service, le remplir avec un catalogue de services et mettre en œuvre un environnement pour gérer les applications conteneurisées. Nous avons automatisé le processus de copie des VM, mais cela a quand même pris beaucoup de temps: 40 à 60 minutes, cela ne convenait pas au client. En conséquence, nous avons proposé de passer aux conteneurs, ce qui a réduit le temps de copie à trois à cinq minutes.
Conclusions
La conteneurisation et les microservices ne sont pas des indulgences pour un mauvais code qui sera écrit avec le pied gauche et volera immédiatement en production. Au contraire, il s'agit d'un concept global, impliquant un tas d'améliorations dues à l'automatisation profonde de tous les processus:
- Le code devient plus propre: linter, analyseurs de code, tests automatisés.
- Le code et l'architecture deviennent de plus en plus sûrs: des outils de sécurité aux capacités étendues, jusqu'au blocage automatique du déploiement de code non sécurisé.
- Les services deviennent de plus en plus flexibles et mobiles: les cycles de développement sont désormais extrêmement courts et répondent rapidement aux changements.
- Mise Ă l'Ă©chelle automatique sous charge: votre ressource ne s'affaisse plus aux heures de pointe, perdant des ventes et des clients.
- Allocation simple des ressources pour les nouveaux projets, réduction du temps consacré à la coordination.
- Souvent, la conteneurisation peut réduire considérablement le délai de mise sur le marché.
Et parfois, la conteneurisation n'est pas du tout nécessaire, et le problème peut être résolu par la migration vers un cloud externe. Mais pour prendre une décision, dans tous les cas, nous avons besoin d'un bon audit externe et d'une bonne analyse de ce qui se passe. En bref, les conteneurs ne sont que l'un des outils pour résoudre les problèmes commerciaux, bien que très cool.