Die Registrierung für Slurm DevOps in Moskau ist geöffnet

TL; DR

Slurm DevOps findet vom 30. Januar bis 1. Februar in Moskau statt.

Auch hier werden wir DevOps-Tools in der Praxis analysieren.
Details und Programm unter dem Schnitt.
SRE wurde aus dem Programm entfernt, da wir zusammen mit Ivan Kruglov ein separates Slurm SRE vorbereiten. Die Ankündigung erfolgt später.
Danke an Selectel, unsere Sponsoren seit dem ersten Slurm!

Die Registrierung für Slurm DevOps in Moskau ist geöffnet

Über Philosophie, Skepsis und unerwarteten Erfolg

Ich habe Ende September an der DevOpsConf in Moskau teilgenommen.
Zusammenfassung dessen, was ich gehört habe:
— DevOps wird von den meisten Projekten jeder Größe benötigt;
— DevOps ist eine Kultur, wie jede Kultur, sie muss aus dem Unternehmen selbst entstehen. Sie können keinen DevOps-Ingenieur einstellen und davon träumen, dass er Prozesse verbessert.
— Ganz am Ende der Liste dessen, was für die DevOps-Transformation benötigt wird, steht die Technologie, also genau die DevOps-Tools, die wir lehren.

Mir wurde klar, dass es richtig war, die DevOps-Philosophie und -Kultur nicht in den Kurs einzubeziehen, da dies nicht systematisch vermittelt werden kann. Wer es braucht, wird es in Büchern lesen. Oder er findet einen supercoolen Trainer, der mit seinem Charisma und seiner Autorität jeden überzeugt.

Persönlich war ich schon immer ein Befürworter der „Bewegung von unten“, der Guerilla-Umsetzung von Kultur durch Werkzeuge. So etwas wie das in The Phoenix Project beschriebene. Wenn wir die Teamarbeit mit Git richtig aufgesetzt haben, können wir sie langsam durch Vorschriften ergänzen, und dann kommt es zu Werten.

Und trotzdem hatte ich bei der Vorbereitung des DevOps Slurm, bei dem es ausschließlich um Tools ging, Angst vor der Reaktion der Teilnehmer: „Sie haben wundervolle Dinge gesagt. Schade, ich werde sie nie umsetzen können.“ Die Skepsis war so groß, dass wir einer Wiederholung des Programms sofort ein Ende setzten.

Allerdings antwortete die Mehrheit der Teilnehmer in der Umfrage, dass die gewonnenen Erkenntnisse in der Praxis anwendbar seien und sie in naher Zukunft etwas im eigenen Land umsetzen würden. Gleichzeitig wurde alles, was wir erklärt haben, in die Liste der nützlichen Dinge aufgenommen: Git, Ansible, CI/CD und SRE.

Es sei daran erinnert, dass zu Beginn auch über Slurm Kubernetes gesagt wurde, dass es unmöglich sei, k3s in 8 Tagen zu erklären.

Mit Ivan Kruglov, der das SRE-Thema leitete, einigten wir uns auf ein eigenes Programm. Wir besprechen derzeit die Details, ich werde bald eine Ankündigung machen.

Was wird bei Slurm DevOps passieren?

Programm

Thema Nr. 1: Teamarbeit mit Git

  • Grundlegende Befehle: Git Init, Commit, Add, Diff, Log, Status, Pull, Push
  • Git-Flow, Branches und Tags, Merge-Strategien
  • Arbeiten mit mehreren Remote-Vertretern
  • GitHub-Flow
  • Fork, Remote, Pull-Anfrage
  • Konflikte, Releases, noch einmal über Gitflow und andere Flows in Bezug auf Teams

Thema Nr. 2: Arbeiten mit der Anwendung aus Entwicklungssicht

  • Einen Microservice in Python schreiben
  • Umgebungsvariablen
  • Integrations- und Unit-Tests
  • Verwendung von Docker-Compose in der Entwicklung

Thema Nr. 3: CI/CD: Einführung in die Automatisierung

  • Einführung in die Automatisierung
  • Werkzeuge (Bash, Make, Gradle)
  • Verwendung von Git-Hooks zur Automatisierung von Prozessen
  • Fabrikmontagelinien und ihre Anwendung in der IT
  • Ein Beispiel für den Aufbau einer „allgemeinen“ Pipeline
  • Moderne Software für CI/CD: Drone CI, BitBucket Pipelines, Travis usw.

Thema Nr. 4: CI/CD: Arbeiten mit Gitlab

  • Gitlab-CI
  • Gitlab Runner, ihre Typen und Anwendungen
  • Gitlab CI, Konfigurationsfunktionen, Best Practices
  • Gitlab CI-Stufen
  • Gitlab CI-Variablen
  • Erstellen, testen, bereitstellen
  • Ausführungskontrolle und Einschränkungen: nur, wann
  • Arbeiten mit Artefakten
  • Vorlagen in .gitlab-ci.yml, die Aktionen in verschiedenen Teilen der Pipeline wiederverwenden
  • Einschließen – Abschnitte
  • Zentralisierte Verwaltung von gitlab-ci.yml (eine Datei und automatischer Push an andere Repositorys)

Thema Nr. 5: Infrastruktur als Code

  • IaC: Infrastruktur als Code angehen
  • Cloud-Anbieter als Infrastrukturanbieter
  • Systeminitialisierungstools, Image-Erstellung (Packer)
  • IaC am Beispiel von Terraform
  • Konfigurationsspeicherung, Zusammenarbeit, Anwendungsautomatisierung
  • Übung zum Erstellen von Ansible-Playbooks
  • Idempotenz, Deklarativität
  • IaC am Beispiel von Ansible

Thema Nr. 6: Infrastrukturtests

  • Testen und kontinuierliche Integration mit Molecule und Gitlab CI
  • Vagrant verwenden

Thema Nr. 7: Infrastrukturüberwachung mit Prometheus

  • Warum ist eine Überwachung erforderlich?
  • Arten der Überwachung
  • Benachrichtigungen im Überwachungssystem
  • So bauen Sie ein gesundes Überwachungssystem auf
  • Für Menschen lesbare Benachrichtigungen für alle
  • Gesundheitscheck: Worauf Sie achten sollten
  • Automatisierung basierend auf Überwachungsdaten

Thema Nr. 8: Protokollieren einer Anwendung mit ELK

  • Beste Protokollierungspraktiken
  • ELK-Stapel

Thema Nr. 9: Infrastrukturautomatisierung mit ChatOps

  • DevOps und ChatOps
  • ChatOps: Stärken
  • Slack und Alternativen
  • Bots für ChatOps
  • Hubot und Alternativen
  • Sicherheit
  • Beste und schlechteste Praktiken

Ort: Moskau, Konferenzraum des Hotels Sewastopol.

Termine: vom 30. Januar bis 1. Februar, 3 Tage harte Arbeit.

Anmelden

Source: habr.com

Kommentar hinzufügen