TL; DR
Slurm DevOps se tiendra à Moscou du 30 janvier au 1er février.
Encore une fois, nous analyserons les outils DevOps dans la pratique.
Détails et programme sous la coupe.
SRE a été retiré du programme, car avec Ivan Kruglov, nous préparons un SREM SRE distinct. L'annonce sera plus tard.
Merci à Selectel, nos sponsors du premier Slurm!
À propos de la philosophie, du scepticisme et du succès inattendu
J'ai visité DevOpsConf à Moscou fin septembre.
Résumé de ce que j'ai entendu:
- DevOps a besoin de la plupart des grands projets;
- DevOps est une culture, comme toute culture, elle doit provenir de l'entreprise. Vous ne pouvez pas engager un ingénieur DevOps et rêver qu'il va offenser les processus.
- À la toute fin de la liste de ce qui est nécessaire pour la transformation DevOps, il y a les technologies, c'est-à-dire les outils DevOps que nous formons.
J'ai réalisé que nous n'avions pas correctement inclus la philosophie et la culture de DevOps dans le cours, car cela ne peut pas être systématiquement enseigné. Celui qui a besoin de lire dans les livres. Ou il trouvera un entraîneur super cool qui convaincra tout le monde avec son charisme et son autorité.
Personnellement, j'ai toujours soutenu le «mouvement d'en bas», l'introduction partisane de la culture à travers les outils. Quelque chose comme cela décrit dans le projet Phoenix. Si nous avons correctement configuré le travail d'équipe avec Git, vous pouvez lentement le compléter avec des réglementations, et là, il s'agit de valeurs.
Et tout de même, lorsque nous préparions le DevOps Slurm, où il s'agissait exclusivement d'outils, j'avais peur de la réaction des participants: «Vous avez dit des choses merveilleuses. Désolé, je ne pourrai jamais les implémenter. " Il y avait tellement de scepticisme que nous avons immédiatement mis fin à la répétition du programme.
Cependant, la majorité des participants ont répondu dans une enquête que les connaissances acquises sont applicables dans la pratique et qu’elles mettront en œuvre quelque chose dans un avenir proche. Dans le même temps, tout ce que nous avons expliqué était dans la liste des utilitaires: Git, et Ansible, et CI / CD, et SRE.
Il convient de rappeler qu'au début, ils parlaient également de Slurm Kubernetes, qu'il est impossible d'expliquer les k8 en 3 jours.
Avec Ivan Kruglov, qui a dirigé le sujet du SRE, nous nous sommes mis d'accord sur un programme distinct. Maintenant que nous discutons des détails, je ferai bientôt une annonce.
Que se passera-t-il sur Slurm DevOps?
Le programme
Sujet n ° 1: Travail d'équipe avec Git
- Commandes de base git init, commit, add, diff, log, status, pull, push
- Git flow, branches et tags, stratégies de fusion
- Travailler avec plusieurs représentants distants
- Flux Github
- Fourche, télécommande, traction
- Conflits, sorties, encore une fois sur Gitflow et autres flux en relation avec les équipes
Thème №2: Travailler avec l'application d'un point de vue de développement
- Écrire un microservice en Python
- Variables d'environnement
- Intégration et tests unitaires
- Utilisation de docker-compose en développement
Thème 3: CI / CD: Introduction à l'automatisation
- Introduction à l'automatisation
- Outils (bash, make, gradle)
- Utilisation de git-hooks pour automatiser les processus
- Lignes d'assemblage de convoyeurs d'usine et leur application en informatique
- Un exemple de construction d'un pipeline «commun»
- Logiciel CI / CD moderne: Drone CI, BitBucket Pipelines, Travis, etc.
Sujet n ° 4: CI / CD: Travailler avec Gitlab
- Gitlab ci
- Gitlab Runner, leurs types et leur application
- Gitlab CI, fonctionnalités de personnalisation, meilleures pratiques
- Étapes Gitlab CI
- Variables CI Gitlab
- Assemblage, test, déploiement
- Restrictions de contrôle et d'exécution: uniquement, lorsque
- Travailler avec des artefacts
- Modèles à l'intérieur de .gitlab-ci.yml, réutilisant des actions sur différentes sections du pipeline
- Inclure - sections
- Gestion centralisée de gitlab-ci.yml (un fichier et push automatique vers d'autres référentiels)
Sujet n ° 5: Infrastructure en tant que code
- IaC: une approche de l'infrastructure en tant que code
- Fournisseurs de cloud en tant que fournisseurs d'infrastructure
- Outils d'initialisation du système, assemblage d'images (packer)
- IaC sur l'exemple de Terraform
- Stockage de configuration, collaboration, automatisation des applications
- Entraînez-vous à créer des livres de jeu ansibles
- Idempotence, déclarativité
- IaC Ansible
Sujet n ° 6: tester l'infrastructure
- Test et intégration continue avec Molecule et Gitlab CI
- Application vagabonde
Sujet n ° 7: Surveillance de l'infrastructure avec Prometheus
- Pourquoi la surveillance est nécessaire
- Types de surveillance
- Notifications dans le système de surveillance
- Comment construire un système de surveillance sain
- Des avis lisibles par l'homme, pour tous
- Bilan de santé: que rechercher
- Automatisation basée sur les données de surveillance
Sujet n ° 8: Journalisation des applications avec ELK
- Meilleures pratiques de journalisation
- Pile ELK
Sujet n ° 9: Automatisation de l'infrastructure avec ChatOps
- DevOps et ChatOps
- ChatOps: points forts
- Mou et alternatives
- Bots pour ChatOps
- Hubot et alternatives
- La 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.
Inscription