TL; DR
se tiendra à Moscou du 30 janvier au 1er février.
Encore une fois, nous analyserons les outils DevOps en pratique.
Détails et programme sous la coupe.
SRE a été supprimé du programme car, avec Ivan Kruglov, nous préparons un Slurm SRE distinct. L'annonce viendra plus tard.
Merci à Selectel, nos sponsors depuis le premier Slurm !
À propos de philosophie, de scepticisme et de succès inattendus
J'ai assisté à la DevOpsConf à Moscou fin septembre.
Résumé de ce que j'ai entendu :
— DevOps est nécessaire à la plupart des projets de toute taille ;
— DevOps est une culture, comme toute culture, elle doit venir de l'intérieur de l'entreprise. Vous ne pouvez pas embaucher un ingénieur DevOps et rêver qu’il améliorera les processus.
— À la toute fin de la liste de ce qui est nécessaire à la transformation DevOps se trouve la technologie, c'est-à-dire les outils DevOps mêmes que nous enseignons.
J'ai réalisé que nous avions eu raison de ne pas inclure la philosophie et la culture DevOps dans le cours, car cela ne peut pas être enseigné systématiquement. Celui qui en a besoin le lira dans des livres. Ou il trouvera un coach super cool qui saura convaincre tout le monde par son charisme et son autorité.
Personnellement, j’ai toujours été partisan du « mouvement par le bas », de la mise en œuvre guérilla de la culture à travers les outils. Quelque chose comme celui décrit dans The Phoenix Project. Si le travail d'équipe avec Git est correctement configuré, nous pouvons le compléter lentement avec des réglementations, puis nous arriverons aux valeurs.
Et tout de même, lorsque nous préparions DevOps Slurm, où nous parlions exclusivement d'outils, j'avais peur de la réaction des participants : « Vous avez dit des choses merveilleuses. C’est dommage, je ne pourrai jamais les mettre en œuvre. Il y avait tellement de scepticisme que nous avons immédiatement mis un terme à la répétition du programme.
Cependant, la majorité des participants ont répondu lors de l'enquête que les connaissances acquises étaient applicables dans la pratique et qu'ils mettraient en œuvre quelque chose dans leur propre pays dans un avenir proche. En même temps, tout ce que nous avons expliqué était inclus dans la liste des éléments utiles : Git, Ansible, CI/CD et SRE.
Il convient de rappeler qu'au début, ils disaient également à propos de Slurm Kubernetes qu'il était impossible d'expliquer les k3 en 8 jours.
Avec Ivan Kruglov, qui a dirigé le sujet SRE, nous avons convenu d'un programme séparé. Nous discutons actuellement des détails, je ferai une annonce bientôt.
Que se passera-t-il chez Slurm DevOps ?
Programme
Sujet n°1 : Travail d'équipe avec Git
- Commandes de base git init, commit, add, diff, log, status, pull, push
- Flux Git, branches et tags, stratégies de fusion
- Travailler avec plusieurs représentants à distance
- Flux GitHub
- Fourche, télécommande, demande de tirage
- Conflits, releases, encore une fois à propos de Gitflow et autres flux en relation avec les équipes
Sujet n°2 : Travailler avec l'application d'un point de vue développement
- Écrire un microservice en Python
- Variables d'environnement
- Intégration et tests unitaires
- Utilisation de docker-compose en développement
Sujet n°3 : CI/CD : introduction à l'automatisation
- Introduction à l'automatisation
- Outils (bash, make, gradle)
- Utiliser des git-hooks pour automatiser les processus
- Les chaînes de montage en usine et leur application en informatique
- Un exemple de construction d'un pipeline « général »
- Logiciels modernes pour CI/CD : Drone CI, BitBucket Pipelines, Travis, etc.
Sujet n°4 : CI/CD : Travailler avec Gitlab
- CI Gitlab
- Gitlab Runner, leurs types et applications
- Gitlab CI, fonctionnalités de configuration, bonnes pratiques
- Étapes Gitlab CI
- Variables CI Gitlab
- Construire, tester, déployer
- Contrôle et restrictions d'exécution : uniquement lorsque
- Travailler avec des artefacts
- Modèles dans .gitlab-ci.yml, réutilisant des actions dans différentes parties du pipeline
- Inclure - sections
- Gestion centralisée de gitlab-ci.yml (un seul fichier et push automatique vers d'autres référentiels)
Sujet n°5 : L'infrastructure en tant que code
- IaC : approcher l'infrastructure en tant que code
- Les fournisseurs de cloud en tant que fournisseurs d'infrastructure
- Outils d'initialisation du système, création d'images (packer)
- IaC utilisant Terraform comme exemple
- Stockage de configuration, collaboration, automatisation des applications
- Pratique de création de playbooks Ansible
- Idempotence, déclarativité
- IaC utilisant Ansible comme exemple
Sujet n°6 : Tests d'infrastructure
- Tests et intégration continue avec Molecule et Gitlab CI
- Utiliser Vagrant
Sujet n°7 : Surveillance de l'infrastructure avec Prometheus
- Pourquoi une surveillance est-elle nécessaire ?
- Types de surveillance
- Notifications dans le système de surveillance
- Comment créer un système de surveillance sain
- Notifications lisibles par l'homme, pour tout le monde
- Bilan de santé : ce à quoi vous devez faire attention
- Automatisation basée sur les données de surveillance
Sujet n°8 : Journalisation d'une application avec ELK
- Meilleures pratiques de journalisation
- Pile ELK
Sujet n°9 : Automatisation de l'infrastructure avec ChatOps
- DevOps et ChatOps
- ChatOps : points forts
- Slack et alternatives
- Bots pour ChatOps
- Hubot et alternatives
- sécurité
- Meilleures et pires pratiques
lieu: Moscou, salle de conférence de l'hôtel Sébastopol.
Dates: du 30 janvier au 1er février, 3 jours de dur labeur.
Source: habr.com