Get best of the week

Portail d'environnements de test, ou Save our devops



Il y a quelques années, nous nous sommes sentis dans une sorte de rêve surréaliste. Tout le monde est allé dans le cloud pour les tests (il est pratique d'étendre et de réduire les environnements de test), et nous avons essayé de savoir quels outils prêts à l'emploi devraient être fournis. Pour ce faire, nous avons déterminé avec les clients comment fonctionnent les processus devops. Et il s'est avéré que seules quelques entreprises en Russie utilisent l'automatisation avec compétence.

Je vais immédiatement expliquer que, pour la plupart, nous avons parlé soit avec ceux qui sont engagés dans le développement de 150 à 200 personnes au sein de l'entreprise, soit avec des secteurs où l'informatique est traditionnellement difficile. Les grandes entreprises ont généralement à la fois un processus et leur propre cloud, et elles viennent nous voir pour un déploiement de sauvegarde.

La production est généralement bien établie. Il y a un cycle, un plan de publication, il y a un objectif, le code va à l'objectif avec les développeurs.

Les tests et l'assurance qualité sont également bien débogués le plus souvent.

Et entre eux, il y a un abîme. Et DevOps essaie de le remplir. Ce surhomme devrait prendre la sortie (et idéalement l'assembler dans Jenkins ou quelque chose de similaire), créer une voiture, déployer tout là-bas, vérifier le travail, peut-être passer quelques prétests et le donner à QA.

Quel est le problème?


Lorsqu'un produit est un petit type d'application Web, il n'y a aucun problème. Directement, le développeur ou le testeur extrait la base de données de la sauvegarde, se connecte à la dernière version et s'exécute.

Mais lorsque le produit se développe un peu, l'effondrement de la production s'installe.

Devops a obtenu la libération, mais il l'a prise et n'avait pas l'intention de le faire. Puis il commence à chercher l'extrême et à trier les développeurs. Une version peut être collectée pendant plusieurs heures la nuit, et les développeurs sont généralement assis au bureau pendant la journée.

Presque tout se fait à la main. Autrement dit, les ops sont assis et regardent la barre de progression de l'assemblée. Parce que n'importe où peut mal tourner. Ceux qui sont plus énergiques lient tout cela avec leurs propres scripts, et cela se révèle parfois très bien et efficacement. Mais bien plus souvent, nous voyons que le plan de livraison de livraison est effectué étape par étape, une personne distincte est responsable de chaque étape, et il est plus facile pour lui de répéter la procédure vingt fois avec ses mains, car sinon il s'avère que cela ne fonctionne pas.

Dans le même temps, quelqu'un devrait être responsable du processus dans son ensemble, et c'est le principal facteur d'arrêt. Une tentative de trouver une telle personne aboutit souvent à un échec. A savoir, il est responsable de l'automatisation, et c'est lui qui s'y intéresse. Responsable des sections individuelles, puis transférer les flèches à quelqu'un en développement, bien sûr, est toujours plus facile.

La virtualisation ajoute plus d'aspects du chaos. Les environnements virtuels sont toujours un gâchis. Le responsable du regroupement (serveur, rack), il est peu orienté, à qui cela appartient, que cela soit nécessaire ou non. Il est logique que l'administrateur système n'ait pas à se soucier de ce qui se passe avec les développeurs. Mais les devops devraient, mais son rôle n'implique généralement pas une telle connaissance. Et il a peur d'éteindre l'excédent, car il ne comprend pas encore s'il sera nécessaire ou non.

Ensuite, il est nécessaire de publier des comptes internes pour les règlements mutuels des départements. Quelqu'un considère le temps de disponibilité, quelqu'un envisage l'utilisation du processeur, puis ils partagent également ou dans certaines proportions les coûts comme l'électricité et le travail des administrateurs.

De façon inattendue, mais pas de produit fini


Il semblerait que l'ensemble de ce convoyeur devrait être recouvert d'une sorte de produit. Il existe de nombreuses bonnes solutions ponctuelles. Le même Ansible se déploie parfaitement, mais ne sait pas diriger les machines virtuelles. Et les hyperviseurs le peuvent. Il y a tous les outils pour le devops-scripting, vous pouvez connecter les modules ... Il vous suffit de prendre et d'assembler à partir de cette chaîne logicielle, non?

Pas comme ça. Les banques et les entreprises publiques sont venues avec le désir de tester dans le cloud. Tout bon agent de sécurité est sujet à la paranoïa, souvent avec raison. Pour IB Bank, chaque nouvelle installation est un facteur très ennuyeux. Je connais un cas où les opérations ont traîné Jenkins et Terraform dans l'infrastructure, déployé bash derrière, puis le SGBD qui contient tout. Il s'est avéré être un bon convoyeur semi-automatique, qui pourrait être complété par un déploiement entièrement autonome. Seulement pour la sécurité de l'information, c'était un désastre.

Ils voulaient tout en un. Et pour gérer la machine virtuelle (et divers fournisseurs, dont Openstack). Un client sur une application peut avoir à la fois Vmvara et Hyper-in, et quelque chose d'autre ancien et terrible pour supporter FreeBSD ou OS / 2.

Nous avons besoin de notre vélo


En général, nous avons écrit notre plateforme. Sous le capot - Ansible, prêt à l'emploi - intégration avec Jenkins. Vous pouvez écrire vos propres scripts pour Ansible. Vous pouvez tout faire, de la collecte de sous-réseaux à la gestion des versions.



Le portail vit dans le paradigme de l'environnement de test. C'est son essence principale. Un environnement de test = un sous-réseau. De plus, si c'est vraiment mauvais - il y a intégration avec le RPA au cas où il n'y aurait pas d'API, et vous avez besoin d'un robot pour émuler les actions de l'utilisateur et cliquer sur les boutons dans l'interface. Il y a facturation, disponibilité et utilisation sont considérées soit de l'application à l'application: tant que la demande de destruction n'aura pas été écrite, l'argent coulera.

Voilà à quoi ça ressemble. Création d'un environnement à l'aide d'un modèle:



Ajout d'une machine virtuelle:



Script:



Comme il s'est avéré un peu plus tard, les plaintes «je ne veux pas courir sur 50 systèmes» sont entendues de tous les côtés. Nous souffrions beaucoup. Tout gros client avec des tests voulait quelque chose de similaire, mais pour une raison quelconque, il ne l'a pas résolu ou ne l'a pas résolu de manière organisationnelle avec des scripteurs. Les problèmes sont très différents, à commencer par les ordinateurs virtuels sans nom (ils l'ont supprimé, puis quelqu'un s'est souvenu que c'était nécessaire) et se terminant par le fait que personne ne veut être responsable des scripts roulants. Les scripts de roll-up sont difficiles à écrire, les réglementations en souffrent également. Quelque part dans le cycle, il devrait y avoir anonymisation des données, et cela ressemble à "Parfois, au début de l'année, nous avons créé une base de données anonyme", et le logiciel a changé six fois, les données ont été mises à jour.

En général, si quelque chose de similaire vous fait soudainement mal, venez simplement regarder. L'accès à la démonstration est disponible dans le cloud Technoserv .

More articles:


All Articles