Du 4 au 6 septembre à Saint-Pétersbourg, dans la salle de conférence Selectel, un séminaire de trois jours aura lieu .
Nous avons construit le programme avec l'idée que chacun peut lire par lui-même les travaux théoriques sur le DevOps, tout comme les manuels des outils. Ce qui compte, c'est l'expérience et la pratique : une explication sur ce qu'il faut faire et ne pas faire, ainsi qu'un récit sur notre façon de faire.
Chaque entreprise, chaque administrateur ou développeur a son propre niveau de DevOps. Certains utilisent mal Git, d'autres mettent en œuvre SRE. Le cours est organisé de manière à ce que chacun trouve quelque chose d'utile à appliquer immédiatement.
Nous commençons par Git, puis nous examinons le développement d'applications, l'interaction entre le code et l'infrastructure, construisons CI/CD, décrivons l'infrastructure en tant que code (IaC), testons la solution obtenue, configurons la surveillance, collectons et analysons les journaux, et enfin nous arrivons à SRE : transformant la fiabilité en une histoire mesurable et gérable.
Git
Actuellement, il n'y a que ceux qui viennent d'acheter leur premier ordinateur portable qui ne savent pas utiliser Git. C'est un outil trivial et omniprésent, et pourtant nous rencontrons souvent des utilisations incorrectes : allant du force push sur master jusqu'à la copie de fichiers de Git sur le serveur via Ctrl-C, Ctrl-V.
Nous montrons comment ne pas faire, comment faire et comment cela se passe chez Southbridge.
Nous passons à la pratique : les bases de Git, le travail d'équipe.
Thème n°1 : Les bases de l'utilisation de Git
- Commandes de base git init, commit, add, diff, log, status, pull, push
- Git flow, branches et tags, stratégies de merge
- Travail avec plusieurs dépôts distants
Thème n°2 : Travail d'équipe avec Git
- GitHub flow
- Fork, distant, demande de tirage
- Conflits, versions, nouveau sur Gitflow et d'autres flux pour les équipes
Le matériel est organisé de manière à ce que les administrateurs et développeurs puissent immédiatement mettre en œuvre toutes les pratiques dans leur travail.
Du point de vue du DevOps, une utilisation correcte de Git organise et automatise les processus de développement et d'administration, élimine un certain nombre de problèmes récurrents et augmente la productivité.
Développeur DevOps
Nous voyons DevOps à travers les yeux d'un développeur : nous lançons un environnement local, écrivons une application, configurons sa surveillance et sa journalisation, la testons localement, organisons le stockage des variables/secrets et la découverte de services, et examinons le traçage (opentracing).
Thème n°3 : Travailler sur l'application du point de vue du développement
- Configuration de l'environnement local : recommandations pratiques
- Écrivons un microservice en Python (y compris les tests)
- Utilisation de docker-compose dans le développement
Thème n°4 : Interaction entre le code et l'infrastructure
- Pratique du travail avec des configurations
Au terme de cette phase, les développeurs verront comment le code doit envoyer des logs, comment le tester, et comment le déboguer par la suite. Les administrateurs comprendront les besoins des développeurs : quels types d'erreurs de code existent, comment organiser les tests pour les développeurs, comment tester un projet soi-même.
À cette étape, la principale tâche de DevOps est résolue : construire une compréhension mutuelle et une collaboration entre les développeurs et les opérations. C'est une étape clé dans la transition d'un simple transfert de tâches à une interaction responsable.
En conséquence, la vitesse et la qualité du travail augmentent.
CI/CD
L'automatisation moderne implique CI/CD. Nous commencerons par examiner l'automatisation manuelle : makefiles, hooks Git, scripts. Nous analyserons quand ces outils sont encore pertinents et quand il vaut mieux ne pas les utiliser.
Ensuite, nous verrons les meilleures pratiques du CI moderne à l'aide de Gitlab.
Thème n°5 : CI/CD introduction à l'automatisation
- Introduction à l'automatisation
- Outils (bash, make, gradle)
- Utilisation des git-hooks pour automatiser les processus
- Lignes de production de fabrication et leur application dans l'IT
- Exemple de construction d'un pipeline 'commun'
- Logiciels modernes pour CI/CD : Drone CI, BitBucket Pipelines, Travis, etc.
Thème n°6 : CI/CD : Travailler avec Gitlab
- Gitlab CI — aperçu général
- Gitlab Runner, leurs types et applications
- Gitlab CI, particularités de la configuration, meilleures pratiques
- Étapes de Gitlab CI
- Variables de Gitlab CI
- Compilation, tests, déploiement
- Contrôle et restrictions d'exécution : only, when
- Travail avec des artefacts
- Modèles dans .gitlab-ci.yml, réutilisation des actions à différents endroits du pipeline
- Include — sections
- Gestion centralisée de gitlab-ci.yml (un fichier et push automatique dans les autres dépôts)
La collaboration entre les administrateurs et les développeurs passe à un niveau supérieur : l'administrateur écrit le modèle CI, et les développeurs le modifient, construisant leur CI indépendamment de l'administrateur.
La dépendance des développeurs vis-à-vis des administrateurs diminue, le travail manuel est réduit, et le problème d'« une seule personne qui sait comment travailler avec le makefile » disparaît. Les déploiements se font de manière fiable et rapide.
IaC
Le thème de l'Infrastructure as Code à travers Terraform sera présenté par l'administrateur cloud de Selectel, Alexey Stepanenko. Il montrera comment déployer et redimensionner rapidement et de manière automatisée des serveurs, comment empaqueter automatiquement des images, et comment utiliser des modèles de configuration pour obtenir immédiatement des machines configurées.
La personne qui a créé des milliers de solutions IaC expliquera comment faire correctement et ce qu'il ne faut pas faire.
La solution cloud de Selectel, avec des modifications minimes, convient aux clouds de Google et d'Amazon.
Nikolay Mesropyan, de Southbridge, montrera, à travers Ansible, comment déployer une application fonctionnelle sans temps d'arrêt et vérifier son bon fonctionnement.
Si vous modifiez l'infrastructure manuellement (configurer des serveurs, installer des bibliothèques et des paquets au fur et à mesure des besoins), lors de la tentative de soulever une copie de l'environnement, vous devrez vous souvenir et reproduire toutes vos actions. Cette tâche peut facilement prendre de 3 à 5 jours. Travailler avec l'infrastructure comme avec du code garantit que vous avez une description à jour de l'environnement, qui peut être déployée en quelques minutes.
Nikolay expliquera comment écrire des playbooks, quelles erreurs peuvent survenir, et pourquoi parfois les playbooks fonctionnent lentement ou pas comme prévu. C'est le fruit de nombreuses années d'utilisation de l'IaC chez Southbridge.
Thème n°7 : Infrastructure as Code
- IaC : Approche de l'infrastructure comme code
- Les fournisseurs cloud en tant que fournisseurs d'infrastructure
- Outils d'initialisation de systèmes, construction d'images (packer)
- IaC à travers Terraform
- Stockage des configurations, collaboration, automatisation des applications
- Pratique de la création de playbooks Ansible
- Idempotence, déclaration
- IaC à travers Ansible
- Database as a Code / Résilience de PostgreSQL
L'infrastructure acquiert une nature déclarative et idempotente.
L'administrateur apprend à gérer une infrastructure complexe : créer rapidement de nouveaux environnements, maintenir l'unité de tous les environnements, voir l'historique des modifications, ce qui est crucial lorsque plusieurs équipes travaillent sur un projet.
Le développeur peut étudier l'infrastructure et déployer ses propres environnements de manière autonome.
Le bonus de cette section est la création et la configuration d'un cluster de bases de données PostgreSQL résilient. Nous fournirons un playbook prêt à l'emploi que nous utilisons chez Southbridge, vous déploierez le cluster sur un banc d'essai éducatif et pourrez utiliser cette solution dans votre entreprise.
Test de l'infrastructure et surveillance
L'automatisation permet de déployer une erreur sur mille serveurs en même temps. À chaque changement, des tests sont nécessaires. D'un autre côté, les tests manuels prennent tellement de temps qu'ils annulent les avantages de l'automatisation.
Nous allons montrer en pratique comment écrire des tests de rôles. En conséquence, vous pourrez écrire des tests pour votre entreprise. Plus besoin de se souvenir des configurations effectuées, vous les décrivez dans vos tests et vérifiez automatiquement que toutes les solutions précédentes et contournements sont en place.
Ensuite, nous apprendrons à ajouter automatiquement tous les nouveaux serveurs à la surveillance. Nous examinerons séparément la surveillance de l'infrastructure et des applications. Nous montrerons les mauvaises et les bonnes pratiques.
Thème n°8 : Test de l'infrastructure
- Tests et intégration continue avec Molecule et Gitlab CI
- Application de Vagrant
Thème n°9 : Surveillance de l'infrastructure avec Prometheus
- Pourquoi la surveillance est-elle nécessaire
- Types de surveillance
- Notifications dans le système de surveillance
- Comment construire un système de surveillance sain
- Notifications lisibles par l'homme, pour tous
- Health Check : ce sur quoi il faut prêter attention
- Automatisation basée sur les données de surveillance
Une surveillance défaillante, c'est l'absence de surveillance. Peu importe que la page d'accueil d'un site e-commerce soit accessible, si le formulaire de paiement renvoie une erreur.
Dans la configuration de la surveillance et la résolution des problèmes, les développeurs et les administrateurs participent sur un pied d'égalité. Traditionnellement, les tâches de surveillance incombent aux administrateurs. Notre cours montrera aux développeurs quel rôle ils jouent dans la création d'une surveillance efficace. Les administrateurs recevront les meilleures pratiques de Southbridge. En conséquence, le nombre de pertes causées par des pannes et des ralentissements de sites ou d'applications diminuera rapidement.
Bonus du chapitre : automatisation basée sur la surveillance. Par exemple, la surveillance signale qu'il y a une charge sur le site, et le scaling des serveurs web se déclenche automatiquement.
Journalisation
L'erreur principale dans la gestion des logs est que les administrateurs et les développeurs les consultent directement sur les serveurs. Si vous avez plus d'un serveur, cela prend du temps. C'est peu sécurisé : un développeur accède à un serveur où il ne devrait pas être.
DevOps nécessite une collecte, un traitement et une analyse centralisés des logs.
Thème n°10 : Journalisation d'application avec ELK
- Applications principales et fonctionnalités d'Elastic (recherche, stockage, caractéristiques de mise à l'échelle, flexibilité de configuration)
- Aperçu de Kibana (fonctionnalités principales, langage de requêtes, gestion des tableaux de bord, création de graphiques)
- Aperçu des produits basés sur Elastic et leur utilisation
- Collecte des métriques dans APM (tracing des applications)
- En complément : Aperçu du nouveau produit — SIEM
La mise en œuvre de cette approche rendra les logs un outil simple et compréhensible pour l'analyse, la configuration et le réglage des applications et infrastructures.
SRE
Et nous en arrivons au sujet que Southbridge n'est qu'en train de considérer et pour lequel d'autres intervenants souhaitent rester jusqu'à la dernière journée du Slyrma. Nous sommes heureux qu'Ivan Kruglov de Booking.com ait accepté de le lire.
Le projet vit dans un monde réel, où la fiabilité n'est jamais absolue, et chaque décision a un coût.
Qu'est-ce qu'un SLA dans le cadre d'un projet complexe ? Par exemple, comment évaluer que le site est accessible, mais que les images mettent du temps à se charger. Quelles sont les métriques SLA, où les recueillir, comment les recueillir ?
Comment établir un SLA ? Comment les respecter ?
Thème n°11 : SRE
Définitions de SLA, SLO, Error Budget et d'autres termes effrayants du monde SRE
SRE : Pratique de la surveillance SLI et SLO
SRE : Pratique de l'application de l'Error Budget
SRE : Gestion des interruptions et de la charge opérationnelle (apigateway, service mesh, circuit breakers)
Les entreprises veulent du SRE. Même au niveau le plus simple : prendre un serveur de sauvegarde ou le restaurer depuis une sauvegarde ? Une base de données ou un cluster ? Mettre en place une protection contre les DDoS préventivement ou seulement au moment de l'attaque ?
Les directeurs ne seront pas satisfaits d'entendre que « le site fonctionne », lorsque leur client les appelle pour dire que le formulaire de commande ne s'ouvre pas.
C'est pourquoi il est important pour l'ingénieur DevOps de comprendre au moins superficiellement le SRE, afin de pouvoir parler de manière adéquate avec l'entreprise de ses besoins.
Conclusion
Au fil du temps les administrateurs et les développeurs apprendront :
— à travailler correctement avec Git;
— à organiser le développement local;
— à configurer (administrateurs) et à utiliser (développeurs) CI/CD;
— à traiter l'infrastructure comme du code;
— à tester l'infrastructure;
— à surveiller l'infrastructure et l'application;
— à configurer la journalisation;
— à comprendre, et idéalement — à utiliser le SRE.
Pour les lecteurs attentifs — avec le code promotionnel habrapost, une réduction de 15 %.
Pour tous les points, nous préparons des pratiques et des outils. Ainsi, chaque participant, à son retour du Slurm, pourra faire passer sa société au niveau supérieur en DevOps.
Pour les entreprises, cela signifie une réduction des coûts d'administration et de développement, une diminution des temps d'arrêt, une fiabilité accrue, une livraison plus rapide des fonctionnalités et la résolution des bugs.
Source : habr.com
