Dies ist der erste Beitrag einer mehrteiligen Serie zu einigen der betrieblichen Herausforderungen, die das Team von PagerDuty löst.

Bei PagerDuty streben wir nach hoher Verfügbarkeit auf jeder Ebene unseres Stacks. Dies erreichen wir, indem wir robuste Software schreiben, die dann auf einer robusten Infrastruktur läuft. Dies berücksichtigen wir bei der Entwicklung unserer Infrastrukturautomatisierung. Wir gehen davon aus, dass Teile ausfallen werden und dass wir Teile entweder schnell ersetzen oder neu erstellen müssen.

In diesem ersten Beitrag über unser Operations Engineering-Team werden wir erläutern, wie wir unsere Infrastruktur mit Chef, einem hochgradig erweiterbaren, auf Ruby basierenden, suchgesteuerten Konfigurationsmanagement-Tool, automatisieren und welche Praktiken wir dabei gelernt haben. Wir werden unseren typischen Arbeitsablauf erläutern und wie wir sicherstellen, dass wir eine neue, robuste und vorhersehbare Infrastruktur sicher einführen können.

Das Team

Bevor wir uns in die technischen Details vertiefen, zunächst ein paar Hintergrundinformationen zum Team hinter der Magie. Unser Operations Engineering-Team bei PagerDuty besteht derzeit aus 4 Ingenieuren. Das Team ist für einige Bereiche verantwortlich: Infrastrukturautomatisierung, Sicherheit auf Hostebene, Persistenz/Datenspeicherung und Produktivitätstools. Das Team besteht aus Generalisten, wobei jedes Teammitglied 1-2 Bereiche vertieft kennt. Während das Operations Engineering-Team seinen eigenen PagerDuty -Rufdienst hat, nimmt jedes Ingenieurteam bei PagerDuty auch am Rufdienst teil.

Die Hardware

Wir besitzen derzeit über 150 Server bei mehreren Cloud-Anbietern. Die Server sind in mehrere Umgebungen (Staging, Lasttest und Produktion) und mehrere Dienste (App-Server, Persistenzserver, Lastverteiler und Mailserver) aufgeteilt. Jede unserer drei Umgebungen verfügt über einen dedizierten Chef-Server, um zu verhindern, dass Hosts andere Umgebungen verschmutzen.

Der Workflow

Die Chef-Codebasis ist 3 Jahre alt und hat ungefähr 3,5.000 Commits.

Nachfolgend sehen Sie das Grundgerüst unserer Chef-Repository :

• Git-Repository
  • Kochbücher (speichert Gemeinschaftskochbücher, die unsere Anpassungen enthalten)
  • site-coobooks (speichert unsere Wrapper für Community-Kochbücher, unsere benutzerdefinierten Kochbücher, lwrps usw.)
  • data_bags (speichert alle Datenbeutel, die nicht verschlüsselt sind)
  • lib (Ruby-Bibliotheken, die in site-cookbook/* und Knife-Plugins verwendet werden)
  • Rollen (speichert alle Rollen)

Wir verwenden den Standard-Feature-Branch-Workflow für unser Repo. Ein Feature kann taktische Arbeit (Erstellen eines neuen Servicetyps), Wartungsarbeit (Upgrade/Patching) oder strategische Arbeit (Infrastrukturverbesserungen, groß angelegtes Refactoring usw.) sein. Feature-Branchs werden über Jenkins Unit-getestet, das Github ständig auf neue Änderungen überwacht. Anschließend verwenden wir die Staging-Umgebung für Integrationstests. Feature-Branchs, die die Tests bestehen, werden dann auf dem Chef-Server der Staging-Umgebung bereitgestellt. Es hängt vom Feature ab, aber die meisten Branches durchlaufen eine Codeüberprüfung über eine Pull-Anfrage. Die Codeüberprüfung erfolgt absichtlich manuell, wobei wir sicherstellen, dass mindestens ein anderes Teammitglied dem Code ein +1 gibt. Wenn es eine größere Debatte über den Code gibt, reservieren wir während unserer Teambesprechungen Zeit, um darüber zu diskutieren. Von dort aus wird der Feature-Branch zusammengeführt und wir rufen unser Wiederherstellungsskript auf, um alle vorhandenen Cookbooks vom Chef-Server zu löschen und alle Rollen, Umgebungen und Cookbooks vom Master hochzuladen. Im Allgemeinen dauert der Wiederherstellungsprozess weniger als eine Minute. Wir befolgen keine strengen Bereitstellungspläne, sondern bevorzugen die Bereitstellung, wann immer wir können. Sofern es sich nicht um einen Hotfix handelt, führen wir Bereitstellungen lieber während der Bürozeiten durch, wenn alle wach sind. Wir führen Chef-Client die ganze Woche über einmal täglich über Cron aus. Wenn wir Chef-Ausführung auf Abruf benötigen, verwenden wir PSSH oder Knife SSH mit einem kontrollierten Parallelitätsgrad.

Chef-Test

Alle PagerDuty Kochbücher haben ein Spezifikationsverzeichnis, das ChefSpec-basierte Tests enthält. Wir sind kürzlich zu folgendem Verzeichnis migriert: ChefSpec 3 Wir verwenden Chefspec und Rspec Stubbing-Funktionen werden umfassend genutzt, da die überwiegende Mehrheit unserer benutzerdefinierten Rezepte Suchfunktionen, verschlüsselte Datenbeutel usw. verwendet. Abgesehen von kochbuchspezifischen Unit-Tests, die sich im Unterverzeichnis spec einzelner Kochbücher befinden, haben wir ein Verzeichnis spec auf oberster Ebene, das Funktions- und Unit-Tests enthält. Unit-Tests sind meist ChefSpec-basierte Rollen- oder Umgebungsbehauptungen, während Funktionstests alle lxc- und Rspec-basierte Behauptungen sind. Die Funktionstestsuite verwendet Chef Zero, um einen In-Memory-Server zu erstellen, und verwendet dann ein Wiederherstellungsskript und das Chef Restore Knife-Plugin, um einen Staging- oder Produktionsserver zu emulieren. Dann erzeugen wir einzelne lxc pro Rolle mit demselben Bootstrap-Prozess wie unsere Produktionsserver. Sobald wir einen Knoten erfolgreich konvergieren, behaupten wir basierend auf der Rolle. Beispielsweise wird eine Zookeeper-Funktionsspezifikation lokal per Telnet ausgeführt und 'Statistiken' um zu sehen, ob Anfragen bedient werden können. Dies deckt den größten Teil unserer Codebasis ab, mit Ausnahme der Integration mit einzelnen Cloud-Anbietern.

Kochbuchverwaltung

Wir verwenden in großem Umfang Community-Kochbücher. Wir versuchen, keine Kochbücher zu erstellen, wenn es eine gut gepflegte Open-Source-Alternative gibt. Wir schreiben lieber Wrapper-Kochbücher mit einem „pd“-Präfix, das unsere Anpassungen gegenüber den Community-Kochbüchern berücksichtigt. Ein Beispiel wäre das pd-memcached-Kochbuch, das die memcached Community-Kochbücher umschließt und iptables und andere PagerDuty spezifische Anpassungen bereitstellt.

Sowohl Community-Kochbücher als auch unsere PagerDuty Kochbücher werden verwaltet von Berkshelf . Alle benutzerdefinierten Kochbücher (pd-* ) bleiben im Verzeichnis site-cookbooks in Chef-Repo . Wir verwenden mehrere benutzerdefinierte Knife-Plugins. Zwei davon, Chef Restore und Chef Backup, kümmern sich um die vollständige Sicherung und Wiederherstellung unseres Chef-Servers (Knoten, Clients, Datenbeutel). Damit können wir Chef-Server problemlos von Host zu Host verschieben. Andere Knife-Plugins werden verwendet, um Server zu starten, Abstürze durchzuführen und den Status von Diensten Dritter zu überprüfen.

Vertrauen gewinnen durch Tests und Vorhersagbarkeit

Derzeit sind wir zuversichtlich, dass wir unsere Infrastruktur aufbauen und sicher abbauen können, wenn wir die entsprechenden Tests durchgeführt haben. Als wir zunächst eine TDD Ansatz für unsere Infrastruktur, gab es eine steile Lernkurve für das Team. Wir stoßen immer noch auf Probleme, wenn wir Knoten über mehrere Anbieter hinweg und Netzwerkabhängigkeiten für externe Konfigurationen (z. B. gehostete Überwachungsdienste, Protokollverwaltungsdienste) betreiben, daher haben wir zusätzliche Fehlermodi und Sicherheitsanforderungen eingeführt. Wir haben auf diese Herausforderungen reagiert, indem wir aggressive Memoisierung Techniken, Einführung von Tools zur Automatisierung von Sicherheitstests (z. B. gauntlet ) im Operations-Toolkit (mehr dazu in einem späteren Beitrag).

Eine zentrale Herausforderung bleiben weiterhin Probleme mit der Versionierung von Komponenten über mehrere Komponenten hinweg sowie die frühzeitige und proaktive Aktualisierung von Abhängigkeiten. Einige Probleme mit der Codequalität aus Community-Kochbüchern haben uns ebenfalls behindert. Aber wir verstehen, dass es sich dabei um komplexe, zeitgebundene Probleme handelt. Wir sind Teil der größeren Community, die für deren Behebung verantwortlich ist.