Vom 4. bis 6. September findet im Konferenzraum von Selectel in Sankt Petersburg ein dreitägiger .
Wir haben das Programm mit der Überlegung erstellt, dass theoretische Arbeiten zu DevOps sowie Handbücher zu Werkzeugen jeder selbst lesen kann. Interessant sind nur Erfahrung und Praxis: eine Erklärung, wie man es machen sollte und wie nicht, und ein Bericht darüber, wie wir es tun.
In jedem Unternehmen hat jeder Administrator oder Entwickler sein eigenes Niveau an DevOps. Einige nutzen Git falsch, andere implementieren SRE. Der Kurs ist so organisiert, dass jeder etwas Relevantes findet, das er hier und jetzt umsetzen kann.
Wir beginnen mit Git, schauen uns dann die Anwendungsentwicklung an, die Interaktion zwischen Code und Infrastruktur, bauen CI/CD, beschreiben Infrastruktur als Code (IaC), testen die entstandene Lösung, richten Monitoring ein, sammeln und analysieren Logs und kommen schließlich zu SRE: wir verwandeln Zuverlässigkeit in eine messbare und steuerbare Geschichte.
Git
Heute nutzt nur derjenige Git, der gestern seinen ersten Laptop gekauft hat. Dies ist ein triviales und weit verbreitetes Werkzeug, dennoch treffen wir oft auf seine falsche Verwendung: vom forcieren eines Pushs in den Master bis hin zum Kopieren von Dateien aus Git auf den Server über Ctrl-C, Ctrl-V.
Wir erklären, wie man es nicht machen sollte, wie man es machen sollte, wie es bei Southbridge gemacht wird.
Wir machen Praktika: Grundlagen von Git, Teamarbeit.
Thema Nr. 1: Grundlagen der Arbeit mit Git
- Basisbefehle git init, commit, add, diff, log, status, pull, push
- Git flow, Branches und Tags, Merge-Strategien
- Arbeiten mit mehreren Remote-Repos
Thema Nr. 2: Teamarbeit mit Git
- GitHub flow
- Fork, Remote, Pull Request
- Konflikte, Releases, nochmals über Gitflow und andere Flows im Hinblick auf Teams
Das Material ist so organisiert, dass Administratoren und Entwickler sofort alle Praktiken in der Arbeit umsetzen können.
Aus der Sicht von DevOps ordnet die richtige Arbeit mit Git die Entwicklungs- und Verwaltungsprozesse und automatisiert sie, schließt eine Reihe von wiederkehrenden Problemen aus und steigert die Produktivität.
DevOps-Entwickler
Wir betrachten DevOps aus der Sicht eines Entwicklers: wir starten eine lokale Umgebung, schreiben eine Anwendung, richten deren Monitoring und Logging ein, testen sie lokal, organisieren die Speicherung von Variablen/Sekreten und Service Discovery, betrachten Tracing (opentracing).
Thema Nr. 3: Arbeiten mit der Anwendung aus der Sicht der Entwicklung
- Einrichtung der lokalen Umgebung: praktische Empfehlungen
- Wir schreiben einen Mikrodienst in Python (einschließlich Tests)
- Einsatz von docker-compose in der Entwicklung
Thema Nr. 4: Interaktion zwischen Code und Infrastruktur
- Praxis im Umgang mit Konfigurationen
Am Ende werden die Entwickler sehen, wie der Code Logs senden soll, wie man ihn testet und wie er später.debugged wird. Administratoren werden die Bedürfnisse der Entwickler verstehen: welche Fehler im Code auftreten können, wie man das Testen für Entwickler organisiert und wie man das Projekt selbst testet.
In diesem Schritt wird die Hauptaufgabe von DevOps gelöst: Verständnis und Zusammenarbeit zwischen Entwicklern und Operations wird aufgebaut. Dies ist der entscheidende Schritt zum Übergang von der reinen Aufgabenverlagerung zu einem verantwortungsvollen Miteinander.
Dadurch steigt die Geschwindigkeit und Qualität der Arbeit.
CI/CD
Moderne Automatisierung beinhaltet CI/CD. Wir beginnen damit, dass wir uns die manuelle Automatisierung ansehen: Makefiles, Git-Hooks, Skripte. Wir werden analysieren, wann diese Werkzeuge noch relevant sind und wann sie vermieden werden sollten.
Dann betrachten wir die besten Praktiken moderner CI am Beispiel von Gitlab.
Thema Nr. 5: CI/CD Einführung in die Automatisierung
- Einführung in die Automatisierung
- Werkzeuge (bash, make, gradle)
- Einsatz von Git-Hooks zur Automatisierung von Prozessen
- Fabrik-Assembly-Linien und deren Anwendung in der IT
- Beispiel für den Aufbau einer 'gemeinsamen' Pipeline
- Moderne Software für CI/CD: Drone CI, BitBucket Pipelines, Travis usw.
Thema Nr. 6: CI/CD: Arbeiten mit Gitlab
- Gitlab CI - Allgemeines
- Gitlab Runner, deren Typen und Anwendung
- Gitlab CI, Besonderheiten der Konfiguration, beste Praktiken
- Phasen von Gitlab CI
- Gitlab CI-Variablen
- Bauen, Testen, Deployment
- Kontrolle und Einschränkungen der Ausführung: only, when
- Arbeit mit Artefakten
- Vorlagen innerhalb von .gitlab-ci.yml, Wiederverwendung von Aktionen in verschiedenen Teilen der Pipeline
- Include - Abschnitte
- Zentralisierte Verwaltung von gitlab-ci.yml (eine Datei und automatisches Push in die anderen Repositories)
Die Zusammenarbeit von Administratoren und Entwicklern wird auf ein neues Niveau gehoben: Der Administrator erstellt eine CI-Vorlage, die Entwickler passen sie an und gestalten ihr CI unabhängig vom Administrator.
Die Abhängigkeit der Entwickler von den Administratoren wird verringert, die manuelle Arbeit wird reduziert, und das Problem der 'einzigen Person, die weiß, wie man mit Makefiles arbeitet' verschwindet. Rollouts erfolgen zuverlässig und schnell.
. Das ist verständlich. Denn nur sie ermöglichten die vollständige Konfiguration eines virtuellen Rechenzentrums: Keine physischen Server, keine Racks, keine Netzwerkkomponenten, die gesamte Infrastruktur kann durch Skripte und Konfigurationsdateien beschrieben werden.
Das Thema Infrastructure as Code am Beispiel von Terraform wird vom Cloud-Administrator von Selectel, Alexey Stepanenko, vorgestellt. Er wird zeigen, wie man Server schnell und automatisiert bereitstellt und skaliert, wie man Images automatisch verpackt und wie man Konfigurationstemplates verwendet, um sofort konfigurierte Maschinen zu erhalten.
Der Mensch, der Tausende von IaC-Lösungen geschaffen hat, wird darüber berichten, wie man es richtig macht und wie man es besser nicht machen sollte.
Die Lösung für die Cloud Selectel ist mit minimalen Anpassungen für die Clouds von Google und Amazon geeignet.
Der Mitarbeiter von Southbridge, Nikolai Mesropyans, wird am Beispiel von Ansible zeigen, wie man eine funktionierende Anwendung ohne Ausfallzeiten bereitstellt und deren Funktionalität überprüft.
Wenn Sie die Infrastruktur manuell ändern (Server einrichten, bei Bedarf Bibliotheken und Pakete installieren), müssen Sie sich an all Ihre Schritte erinnern und sie reproduzieren, wenn Sie versuchen, eine Kopie der Umgebung zu erstellen. Diese Aufgabe kann leicht 3-5 Tage in Anspruch nehmen. Die Arbeit mit Infrastruktur als Code garantiert, dass Sie eine aktuelle Beschreibung der Umgebung haben, die in Minuten bereitgestellt werden kann.
Nikolai wird darüber sprechen, wie man Playbooks schreibt, welche Fehler häufig auftreten und warum Playbooks manchmal langsam oder nicht wie erwartet funktionieren. Dies ist die Erfahrung aus vielen Jahren der Nutzung von IaC bei Southbridge.
Thema Nr. 7: Infrastructure as Code
- IaC: Ansatz zur Infrastruktur als Code
- Cloud-Anbieter als Infrastruktur-Lieferanten
- Systeminitialisierungswerkzeuge, Image-Building (packer)
- IaC am Beispiel Terraform
- Konfigurationsspeicherung, Zusammenarbeit, Anwendungsautomatisierung
- Praxis der Erstellung von Ansible Playbooks
- Idempotenz, Deklarativität
- IaC am Beispiel Ansible
- Database as a Code / Ausfallsicherheit von PostgreSQL
Die Infrastruktur erhält Deklarativität und Idempotenz.
Der Administrator lernt, komplexe Infrastrukturen zu verwalten: neue Umgebungen schnell zu erstellen, die Einheitlichkeit aller Umgebungen zu gewährleisten und die Historie der Änderungen zu verfolgen, was entscheidend ist, wenn mehrere Teams an einem Projekt arbeiten.
Der Entwickler kann die Infrastruktur erkunden und sich selbstständig Umgebungen bereitstellen.
Ein Bonus des Abschnitts ist die Erstellung und Konfiguration eines ausfallsicheren PostgreSQL-Datenbankclusters. Wir stellen Ihnen ein fertiges Playbook zur Verfügung, das wir in Southbridge verwenden. Sie werden ein Cluster in einer Schulungsumgebung bereitstellen und dieses Lösung in Ihrem Unternehmen nutzen können.
Testen der Infrastruktur und Überwachung
Automatisierung ermöglicht es, einen Fehler sofort auf tausend Servern auszurollen. Bei jeder Änderung ist ein Test erforderlich. Andererseits nimmt manuelles Testen so viel Zeit in Anspruch, dass die Vorteile der Automatisierung zunichtegemacht werden.
Wir zeigen in der Praxis, wie man Rollentests schreibt. Am Ende können Sie Tests für Ihr Unternehmen erstellen. Es ist nicht mehr notwendig, sich die vorgenommenen Einstellungen zu merken, Sie beschreiben sie in den Tests und überprüfen automatisch, dass alle früheren Lösungen und Workarounds vorhanden sind.
Dann lernen wir, alle neuen Server automatisch zur Überwachung hinzuzufügen. Wir betrachten die Überwachung von Infrastruktur und Anwendungen separat. Wir zeigen schlechte und gute Praktiken.
Thema Nr. 8: Infrastrukturtests
- Tests und kontinuierliche Integration mit Molecule und Gitlab CI
- Anwendung von Vagrant
Thema Nr. 9: Infrastrukturüberwachung mit Prometheus
- Warum ist Überwachung notwendig?
- Typen der Überwachung
- Benachrichtigungen im Überwachungssystem
- Wie man ein gesundes Überwachungssystem aufbaut
- Menschlich lesbare Benachrichtigungen für alle
- Health Check: Worauf man achten sollte
- Automatisierung basierend auf Daten aus der Überwachung
Eine fehlerhaft arbeitende Überwachung heißt, dass keine Überwachung vorhanden ist. Es ist dem Unternehmen egal, ob die Hauptseite des Online-Shops verfügbar ist, wenn das Zahlungsformular einen Fehler ausgibt.
Bei der Einstellung der Überwachung und der Problemlösung arbeiten Entwickler und Administratoren gleichberechtigt. Traditionell fallen die Aufgaben der Überwachung jedoch auf die Administratoren. Unser Kurs zeigt den Entwicklern, welche Rolle sie bei der Schaffung einer effektiven Überwachung spielen. Administratoren erhalten die besten Praktiken von Southbridge. Infolgedessen wird die Zahl der Verluste, die durch Ausfälle und Verlangsamungen der Webseite oder Anwendung verursacht werden, schnell zurückgehen.
Bonus des Abschnitts: Automatisierung auf der Grundlage von Überwachung. Zum Beispiel meldet die Überwachung, dass die Webseite stark belastet wird, und das Scaling der Webserver wird automatisch gestartet.
Protokollierung
Der Hauptfehler im Umgang mit Logs besteht darin, dass Administratoren und Entwickler diese direkt auf den Servern einsehen. Wenn Sie mehr als einen Server haben, dauert das lange. Es ist unsicher: Ein Entwickler betritt einen Server, wo er nicht sein sollte.
DevOps erfordert eine zentralisierte Sammlung, Verarbeitung und Analyse von Logs.
Thema Nr. 10: Anwendungsprotokollierung mit ELK
- Hauptanwendungen und Möglichkeiten von elastic (Suche, Speicherung, Besonderheiten der Skalierung, Flexibilität der Einstellungen)
- Überblick über Kibana (Hauptfunktionen, Abfragesprache, Dashboardverwaltung, Grafikerstellung)
- Überblick über Produkte auf Basis von elastic und deren Anwendungen
- Wir sammeln Metriken in APM (Anwendungstracking)
- Zusätzlich: Überblick über das neue Produkt – SIEM
Die Implementierung dieses Ansatzes macht Protokolle zu einem einfachen und verständlichen Werkzeug für die Analyse, Anpassung und Wartung von Anwendungen und Infrastruktur.
SRE
Und wir kommen zum Thema, auf das Southbridge nur einen Blick wirft und wegen dem andere Sprecher bis zum letzten Tag des Slermos bleiben wollen. Wir freuen uns, dass Ivan Kruglov von Booking.com zugestimmt hat, es zu lesen.
Das Projekt lebt in der realen Welt, wo Zuverlässigkeit nie absolut ist und jede Entscheidung Geld kostet.
Was ist SLA im Kontext eines komplexen Projekts? Lassen Sie uns sagen, wie man bewertet, dass die Website verfügbar ist, aber die Bilder mit Verzögerung geladen werden. Was sind die SLA-Metriken, woher stammen sie und wie werden sie gemessen?
Wie stellt man SLA auf? Wie hält man sie ein?
Thema Nr. 11: SRE
Definition von SLA, SLO, Error Budget und anderen gruseligen Begriffen aus der SRE-Welt
SRE: Praxis des Monitorings von SLI und SLO
SRE: Praxis der Anwendung von Error Budget
SRE: Management von Unterbrechungen und Betriebsbelastung (apigateway, service mesh, circuit brackers)
Das Geschäft will SRE. Zumindest auf der einfachsten Ebene: einen Backup-Server übernehmen oder aus einem Backup starten? Eine Datenbank oder ein Cluster? DDoS-Schutz präventiv oder nur im Moment eines Angriffs installieren?
Die Direktoren sind mit der Aussage „die Website funktioniert“ nicht zufrieden, wenn ein Kunde anruft und berichtet, dass das Bestellformular nicht geöffnet wird.
Deshalb ist es für einen DevOps-Ingenieur wichtig, zumindest oberflächlich Verständnis für SRE zu haben, um angemessen mit dem Geschäft über seine Bedürfnisse zu sprechen.
Fazit
Im Laufe von werden Administratoren und Entwickler lernen:
— richtig mit Git zu arbeiten;
— lokale Entwicklung zu organisieren;
— CI/CD einzurichten (Administratoren) und zu nutzen (Entwickler);
— mit Infrastruktur als Code zu arbeiten;
— Infrastruktur zu testen;
— Infrastruktur und Anwendung zu monitoren;
— Logging einzurichten;
— SRE zu verstehen und idealerweise zu nutzen.
Für aufmerksame Leser — mit dem Promo-Code habrapost gibt es einen Rabatt von 15%.
Für alle Punkte bereiten wir Praxis und Werkzeuge vor. So kann jeder Teilnehmer nach seiner Rückkehr vom Slermo sein Unternehmen auf die nächste Stufe von DevOps bringen.
Für das Geschäft bedeutet dies eine Kostensenkung bei der Administration und Entwicklung, weniger Ausfallzeiten, eine höhere Zuverlässigkeit, schnellere Bereitstellung von Features und die Behebung von Bugs.
Quelle: habr.com
