Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Der Betriebsleiter des Portals Banki.ru, Andrey Nikolsky, sprach auf der letztjährigen Konferenz DevOpsDays Moskau über verwaiste Dienste: Wie erkennt man einen verwaisten Dienst in der Infrastruktur, warum sind verwaiste Dienste schlecht, was ist mit ihnen zu tun und was ist zu tun, wenn nichts hilft?

Unterhalb des Ausschnitts befindet sich eine Textversion des Berichts.


Hallo Kollegen! Mein Name ist Andrey, ich leite den Betrieb bei Banki.ru.

Wir haben große Dienste, das sind solche monolithischen Dienste, es gibt Dienste im eher klassischen Sinne und es gibt sehr kleine. In meiner Arbeiter-Bauern-Terminologie sage ich: Wenn eine Dienstleistung einfach und klein ist, dann handelt es sich um eine Mikrodienstleistung, und wenn sie nicht sehr einfach und klein ist, dann ist sie nur eine Dienstleistung.

Vorteile von Dienstleistungen

Ich werde kurz auf die Vorteile der Dienste eingehen.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Die erste ist die Skalierung. Sie können schnell etwas am Service ändern und mit der Produktion beginnen. Sie haben Datenverkehr empfangen und den Dienst geklont. Sie haben mehr Verkehr, Sie haben ihn geklont und leben damit. Das ist ein guter Bonus, und als wir angefangen haben, war es für uns grundsätzlich das Wichtigste, warum wir das alles machen.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Zweitens: isolierte Entwicklung, wenn Sie mehrere Entwicklungsteams haben, mehrere unterschiedliche Entwickler in jedem Team und jedes Team seinen eigenen Service entwickelt.

Bei Teams gibt es eine Nuance. Entwickler sind unterschiedlich. Und es gibt zum Beispiel Schneeflockenmenschen. Ich habe das zum ersten Mal bei Maxim Dorofeev gesehen. Manchmal sind Schneeflockenmenschen in manchen Teams und nicht in anderen. Dies führt dazu, dass die verschiedenen Dienste, die im gesamten Unternehmen genutzt werden, etwas uneinheitlich sind.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Schauen Sie sich das Bild an: Das ist ein guter Entwickler, er hat große Hände, er kann viel. Das Hauptproblem ist, woher diese Hände kommen.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Dienste ermöglichen es, verschiedene Programmiersprachen zu verwenden, die für unterschiedliche Aufgaben besser geeignet sind. Manche Dienste sind in Go, manche in Erlang, manche in Ruby, manche in PHP, manche in Python. Generell kann man sehr weit expandieren. Auch hier gibt es Nuancen.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Bei der serviceorientierten Architektur geht es in erster Linie um Entwickler. Das heißt, wenn Sie keine Automatisierung haben, gibt es keinen Bereitstellungsprozess, wenn Sie ihn manuell konfigurieren, können sich Ihre Konfigurationen von Dienstinstanz zu Instanz ändern und Sie müssen dorthin gehen, um etwas zu tun, dann sind Sie in der Hölle.

Sie haben beispielsweise 20 Dienste und müssen diese manuell bereitstellen, Sie haben 20 Konsolen und drücken gleichzeitig die Eingabetaste wie ein Ninja. Es ist nicht sehr gut.

Wenn Sie einen Dienst nach dem Testen haben (wenn es Tests gibt, natürlich) und ihn noch mit einer Datei fertigstellen müssen, damit er in der Produktion funktioniert, habe ich auch schlechte Nachrichten für Sie.

Wenn man auf bestimmte Amazon-Dienste setzt und in Russland arbeitet, dann hieß es vor zwei Monaten auch: „Alles drumherum brennt, mir geht es gut, alles ist cool.“

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Wir verwenden Ansible, um die Bereitstellung zu automatisieren, Puppet für die Konvergenz, Bamboo, um die Bereitstellung zu automatisieren, und Confluence, um alles irgendwie zu beschreiben.

Ich werde hierauf nicht näher eingehen, da es in dem Bericht eher um Interaktionspraktiken und nicht um die technische Umsetzung geht.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Wir hatten zum Beispiel Probleme, bei denen Puppet auf dem Server mit Ruby 2 funktionierte, einige Anwendungen jedoch für Ruby 1.8 geschrieben wurden und nicht zusammenarbeiteten. Da geht etwas schief. Und wenn Sie mehrere Ruby-Versionen auf einem Rechner ausführen müssen, treten normalerweise Probleme auf.

Zum Beispiel stellen wir jedem Entwickler eine Plattform zur Verfügung, auf der sich ungefähr alles befindet, was wir haben, alle Dienste, die entwickelt werden können, sodass er über eine isolierte Umgebung verfügt, die er nach Belieben aufteilen und aufbauen kann.

Es kommt vor, dass Sie dort ein speziell kompiliertes Paket mit Unterstützung für etwas benötigen. Es ist ziemlich hart. Ich habe mir einen Bericht angehört, in dem das Docker-Image 45 GB wiegt. Unter Linux ist es natürlich einfacher, dort ist alles kleiner, aber trotzdem wird es nicht genug Platz geben.

Nun, es gibt widersprüchliche Abhängigkeiten, wenn ein Teil des Projekts von einer Bibliothek einer Version abhängt, ein anderer Teil des Projekts von einer anderen Version und die Bibliotheken überhaupt nicht zusammen installiert werden.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Wir haben Websites und Dienste in PHP 5.6, wir schämen uns dafür, aber was können wir tun? Dies ist unsere einzige Website. Es gibt Websites und Dienste auf PHP 7, es gibt noch mehr davon, wir schämen uns nicht für sie. Und jeder Entwickler hat seine eigene Basis, in der er gerne sägt.

Wenn man in einem Unternehmen in einer Sprache schreibt, dann klingen drei virtuelle Maschinen pro Entwickler normal. Wenn Sie unterschiedliche Programmiersprachen haben, wird die Situation noch schlimmer.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Sie haben hier Websites und Dienste, dann eine weitere Website für Go, eine Website für Ruby und nebenbei noch einige andere Redis. Infolgedessen wird all dies zu einem großen Unterstützungsfeld, und immer wieder kann etwas davon kaputt gehen.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Daher haben wir die Vorteile der Programmiersprache durch die Verwendung verschiedener Frameworks ersetzt, da PHP-Frameworks sehr unterschiedlich sind, unterschiedliche Fähigkeiten, unterschiedliche Communities und unterschiedliche Unterstützung haben. Und Sie können einen Service so schreiben, dass Sie bereits etwas dafür parat haben.

Jeder Dienst hat sein eigenes Team

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Unser Hauptvorteil, der sich über mehrere Jahre herauskristallisiert hat, besteht darin, dass jeder Dienst über ein eigenes Team verfügt. Dies ist praktisch für ein großes Projekt, Sie können Zeit bei der Dokumentation sparen und Manager kennen ihr Projekt gut.

Sie können Aufgaben ganz einfach über den Support einreichen. Beispielsweise ist der Versicherungsdienst ausgefallen. Und sofort macht sich das Versicherungsteam daran, das Problem zu beheben.

Neue Funktionen werden schnell erstellt, denn wenn Sie einen einzigen atomaren Dienst haben, können Sie schnell etwas hineinschrauben.

Und wenn Sie Ihren Dienst unterbrechen, und das passiert unweigerlich, haben Sie keine Auswirkungen auf die Dienste anderer Leute, und Entwickler aus anderen Teams kommen nicht mit Bits auf Sie zugerannt und sagen: „Ay-ay, tun Sie das nicht.“

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Wie immer gibt es Nuancen. Wir haben stabile Teams, Manager sind fest mit dem Team verbunden. Es gibt klare Dokumente, die Manager überwachen alles genau. Jedes Team mit einem Manager hat mehrere Dienste und es gibt einen bestimmten Kompetenzpunkt.

Wenn die Teams schweben (das nutzen wir manchmal auch), gibt es eine gute Methode namens „Sternkarte“.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Sie haben eine Liste von Diensten und Personen. Ein Sternchen bedeutet, dass die Person ein Experte für diesen Dienst ist, ein Buch bedeutet, dass die Person diesen Dienst studiert. Die Aufgabe der Person besteht darin, das Heft gegen ein Sternchen auszutauschen. Und wenn vor dem Gottesdienst nichts geschrieben wird, beginnen Probleme, über die ich weiter sprechen werde.

Wie erscheinen Waisendienste?

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Das erste Problem, der erste Weg, einen Waisendienst in Ihre Infrastruktur zu integrieren, besteht darin, Leute zu entlassen. Hat jemand jemals erlebt, dass ein Unternehmen Fristen eingehalten hat, bevor Aufgaben bewertet wurden? Manchmal kommt es vor, dass die Fristen knapp sind und einfach nicht genug Zeit für die Dokumentation bleibt. „Wir müssen den Service an die Produktion übergeben, dann fügen wir ihn hinzu.“

Wenn das Team klein ist, kommt es vor, dass es einen Entwickler gibt, der alles schreibt, der Rest steht in den Startlöchern. „Ich habe die Grundarchitektur geschrieben, jetzt fügen wir die Schnittstellen hinzu.“ Dann geht irgendwann zum Beispiel der Manager. Und in dieser Zeit, wenn der Manager ausgeschieden ist und noch kein neuer ernannt wurde, entscheiden die Entwickler selbst, wohin der Dienst geht und was dort passiert. Und wie wir wissen (gehen wir ein paar Folien zurück), gibt es in manchen Teams Schneeflocken-Leute, manchmal führt ein Schneeflocken-Team sie. Dann gibt er auf und wir bekommen einen Waisendienst.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Gleichzeitig verschwinden Aufgaben aus dem Support und aus dem Business nicht, sondern landen im Backlog. Sollten bei der Entwicklung des Dienstes Architekturfehler aufgetreten sein, landen diese ebenfalls im Backlog. Der Service verschlechtert sich langsam.

Wie erkennt man ein Waisenkind?

Diese Liste beschreibt die Situation gut. Wer hat etwas über seine Infrastruktur erfahren?

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Über dokumentierte Problemumgehungen: Es gibt einen Dienst und im Allgemeinen funktioniert er. Es gibt ein zweiseitiges Handbuch zur Verwendung damit, aber niemand weiß, wie er im Inneren funktioniert.

Oder es gibt zum Beispiel eine Art Link-Shortener. Beispielsweise haben wir derzeit drei Link-Shortener für unterschiedliche Zwecke in verschiedenen Diensten im Einsatz. Das sind nur die Konsequenzen.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Jetzt werde ich der Kapitän des Offensichtlichen sein. Was soll getan werden? Zuerst müssen wir den Dienst an einen anderen Manager, ein anderes Team übertragen. Wenn Ihr Teamleiter noch nicht gekündigt hat, müssen Sie in diesem anderen Team, wenn Sie verstehen, dass der Dienst wie eine Waise ist, jemanden einbeziehen, der zumindest etwas davon versteht.

Die Hauptsache: Sie müssen die Überweisungsmodalitäten in Blut niederschreiben lassen. In unserem Fall überwache ich das normalerweise, weil ich alles brauche, um zu funktionieren. Führungskräfte brauchen eine schnelle Lieferung, und was später damit passiert, ist ihnen nicht mehr so ​​wichtig.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Der nächste Weg, ein Waisenkind zu machen, ist: „Wir machen es ausgelagert, es geht schneller, und dann übergeben wir es dem Team.“ Es ist klar, dass jeder im Team irgendwelche Pläne hat, eine Wende. Oftmals denkt ein Geschäftskunde, dass der Outsourcer das Gleiche tun wird wie die technische Abteilung des Unternehmens. Obwohl ihre Motivatoren unterschiedlich sind. Es gibt seltsame technologische Lösungen und seltsame algorithmische Lösungen im Outsourcing.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Wir hatten zum Beispiel einen Dienst, bei dem Sphinx an verschiedenen unerwarteten Orten zu sehen war. Ich erzähle dir später, was ich tun musste.

Outsourcer verfügen über selbst geschriebene Frameworks. Dies ist nur reines PHP mit Kopieren und Einfügen aus einem früheren Projekt, in dem Sie alle möglichen Dinge finden können. Bereitstellungsskripte sind ein großer Nachteil, wenn Sie komplexe Bash-Skripte verwenden müssen, um mehrere Zeilen in einer Datei zu ändern, und diese Bereitstellungsskripte von einem dritten Skript aufgerufen werden. Infolgedessen ändern Sie das Bereitstellungssystem, wählen etwas anderes und springen, aber Ihr Dienst funktioniert nicht. Denn dort mussten noch 8 weitere Links zwischen verschiedenen Ordnern gesetzt werden. Oder es passiert, dass tausend Datensätze funktionieren, hunderttausend aber nicht mehr funktionieren.

Ich werde weiterhin Kapitän sein. Die Annahme einer ausgelagerten Dienstleistung ist ein verpflichtendes Verfahren. Hat es schon einmal jemand erlebt, dass ein ausgelagerter Service angekommen ist und nirgendwo akzeptiert wurde? Dies ist natürlich nicht so beliebt wie ein Waisendienst, aber dennoch.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Der Dienst muss überprüft werden, der Dienst muss überprüft werden, Passwörter müssen geändert werden. Wir hatten einen Fall, als sie uns einen Service zur Verfügung stellten, es gab ein Admin-Panel „if login == 'admin' && password == 'admin'...“, es steht direkt im Code. Wir sitzen da und denken nach, und die Leute schreiben das im Jahr 2018?

Auch das Testen der Speicherkapazität ist notwendig. Sie müssen sich ansehen, was auf hunderttausend Datensätzen passieren wird, noch bevor Sie diesen Dienst irgendwo in Produktion nehmen.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Es sollte keine Schande sein, einen Service zur Verbesserung einzusenden. Wenn Sie sagen: „Wir werden diese Leistung nicht annehmen, wir haben 20 Aufgaben, erledigen Sie sie, dann nehmen wir an“, ist das normal. Ihr Gewissen sollte nicht dadurch verletzt werden, dass Sie einen Manager einsetzen oder dass das Unternehmen Geld verschwendet. Das Unternehmen wird dann mehr ausgeben.

Wir hatten einen Fall, als wir beschlossen, ein Pilotprojekt auszulagern.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Die pünktliche Lieferung war das einzige Qualitätskriterium. Deshalb haben wir ein weiteres Pilotprojekt gemacht, das eigentlich gar kein Pilotprojekt mehr war. Diese Dienste wurden angenommen und auf administrativem Wege sagten sie: Hier ist Ihr Code, hier ist das Team, hier ist Ihr Manager. Tatsächlich haben die Dienste bereits begonnen, Gewinne zu erwirtschaften. Gleichzeitig sind sie in Wirklichkeit immer noch Waisen, niemand versteht, wie sie arbeiten, und die Manager tun ihr Bestes, um ihre Aufgaben zu verleugnen.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Es gibt noch ein weiteres großartiges Konzept – Guerilla-Entwicklung. Wenn eine Abteilung, in der Regel die Marketingabteilung, eine Hypothese testen möchte und die gesamte Dienstleistung auslagern lässt. Der Verkehr strömt hinein, sie schließen die Dokumente, unterschreiben die Dokumente mit dem Auftragnehmer, kommen in Betrieb und sagen: „Leute, wir haben hier einen Dienst, der hat bereits Verkehr, er bringt uns Geld, nehmen wir ihn an.“ Wir dachten: „Oppa, wie kann das sein?“

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Und eine andere Möglichkeit, einen verwaisten Dienst zu erhalten: Wenn ein Team plötzlich überlastet ist, sagt das Management: „Übertragen wir den Dienst dieses Teams auf ein anderes Team, es hat eine geringere Auslastung.“ Und dann übertragen wir es auf eine dritte Mannschaft und wechseln den Manager. Und am Ende haben wir wieder ein Waisenkind.

Was ist das Problem mit Waisenkindern?

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Wer weiß es nicht, das ist das in Schweden gebaute Schlachtschiff Wasa, das dafür bekannt ist, dass es 5 Minuten nach dem Stapellauf sank. Und der König von Schweden hat dafür übrigens niemanden hingerichtet. Es wurde von zwei Generationen von Ingenieuren gebaut, die nicht wussten, wie man solche Schiffe baut. Natürliche Wirkung.

Das Schiff hätte übrigens auch viel schlimmer sinken können, zum Beispiel als der König bereits irgendwo im Sturm darauf ritt. Und so ertrank er sofort. Laut Agile ist es gut, früh zu scheitern.

Wenn wir frühzeitig scheitern, gibt es in der Regel keine Probleme. Beispielsweise wurde es bei der Abnahme zur Überarbeitung geschickt. Aber wenn wir bereits in der Produktion scheitern, wenn Geld investiert wird, dann kann es zu Problemen kommen. Konsequenzen, wie man sie in der Wirtschaft nennt.

Warum Waisendienste gefährlich sind:

  • Der Dienst kann plötzlich unterbrochen werden.
  • Die Reparatur dauert lange oder wird überhaupt nicht repariert.
  • Sicherheitsprobleme.
  • Probleme mit Verbesserungen und Updates.
  • Fällt ein wichtiger Dienst aus, leidet der Ruf des Unternehmens.

Was tun mit Waisendiensten?

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Ich wiederhole noch einmal, was zu tun ist. Zunächst muss eine Dokumentation vorhanden sein. 7 Jahre bei Banki.ru haben mich gelehrt, dass Tester sich nicht auf das Wort der Entwickler verlassen sollten und der Betrieb sich nicht auf das Wort aller verlassen sollte. Wir müssen das überprüfen.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Zweitens ist es notwendig, Interaktionsdiagramme zu schreiben, da es vorkommt, dass Dienste, die nicht sehr gut angenommen werden, Abhängigkeiten enthalten, über die niemand gesprochen hat. Beispielsweise haben die Entwickler den Dienst auf ihrem Schlüssel zu einigen Yandex.Maps oder Dadata installiert. Ihr kostenloses Limit ist aufgebraucht, alles ist kaputt und Sie wissen überhaupt nicht, was passiert ist. Alle derartigen Rechen müssen beschrieben werden: Der Dienst verwendet Dadata, SMS und etwas anderes.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Drittens die Arbeit mit technischen Schulden. Wenn Sie auf Krücken gehen oder eine Dienstleistung annehmen und sagen, dass etwas getan werden muss, müssen Sie sicherstellen, dass es getan wird. Denn dann könnte sich herausstellen, dass das kleine Loch gar nicht so klein ist, und man fällt hindurch.

Bei architektonischen Aufgaben hatten wir eine Geschichte über Sphinx. Einer der Dienste nutzte Sphinx zur Eingabe von Listen. Nur eine paginierte Liste, die jedoch jede Nacht neu indiziert wurde. Es wurde aus zwei Registern zusammengesetzt: Ein großes wurde jede Nacht indexiert, außerdem gab es noch ein kleines Register, das daran verschraubt war. Jeden Tag stürzte der Index während der Berechnung mit einer Wahrscheinlichkeit von 50 % ab, ob es zu einem Bombenanschlag kam oder nicht, und unsere Nachrichten wurden auf der Hauptseite nicht mehr aktualisiert. Zuerst dauerte die Neuindizierung des Index 5 Minuten, dann wuchs der Index und irgendwann dauerte die Neuindizierung 40 Minuten. Als wir das rausnahmen, atmeten wir erleichtert auf, denn es war klar, dass noch etwas Zeit vergehen würde und unser Index ganztägig neu indexiert werden würde. Das wird für unser Portal ein Misserfolg sein, es gibt acht Stunden lang keine Neuigkeiten – das war's, der Betrieb ist eingestellt.

Planen Sie die Zusammenarbeit mit einem Waisendienst

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Tatsächlich ist dies sehr schwierig, da es bei Devops um Kommunikation geht. Sie möchten ein gutes Verhältnis zu Ihren Kollegen haben, und wenn Sie Ihre Kollegen und Vorgesetzten mit Vorschriften über den Haufen werfen, hegen diese möglicherweise widersprüchliche Gefühle gegenüber den Menschen, die dies tun.

Zusätzlich zu all diesen Punkten gibt es noch einen weiteren wichtigen Punkt: Für jeden spezifischen Dienst, für jeden spezifischen Abschnitt des Bereitstellungsverfahrens müssen bestimmte Personen verantwortlich sein. Wenn es keine Leute gibt und man andere Leute dazu bringen muss, sich mit dieser ganzen Angelegenheit zu befassen, wird es schwierig.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Wenn das alles nicht geholfen hat und Ihr Waisendienst immer noch ein Waisendienst ist, niemand ihn übernehmen möchte, die Dokumentation nicht geschrieben ist, das Team, das zu diesem Dienst gerufen wurde, sich weigert, irgendetwas zu tun, gibt es einen einfachen Weg: Wiederholen alles.

Das heißt, Sie nehmen die Anforderungen an den Dienst neu und schreiben einen neuen Dienst, besser, auf einer besseren Plattform, ohne seltsame technologische Lösungen. Und du wanderst im Kampf dorthin.

Orphan Services: die Kehrseite der (Mikro-)Service-Architektur

Wir hatten eine Situation, in der wir einen Dienst auf Yii 1 übernahmen und feststellten, dass wir ihn nicht weiterentwickeln konnten, weil uns die Entwickler ausgingen, die gut auf Yii 1 schreiben konnten. Alle Entwickler schreiben gut auf Symfony XNUMX. Was zu tun ist? Wir haben Zeit eingeteilt, ein Team zugeteilt, einen Manager zugeteilt, das Projekt neu geschrieben und den Verkehr reibungslos darauf umgestellt.

Danach kann der alte Dienst gelöscht werden. Dies ist mein Lieblingsverfahren, wenn Sie einen Dienst aus dem Konfigurationsverwaltungssystem entfernen und dann überprüfen müssen, ob alle in der Produktion befindlichen Autos deaktiviert wurden, sodass die Entwickler keine Spuren mehr hinterlassen. Das Repository bleibt in Git.

Das ist alles, worüber ich sprechen wollte, ich bin bereit zu diskutieren, das Thema ist Holivar, viele sind darin geschwommen.

Auf den Folien stand, dass Sie die Sprachen vereinheitlicht haben. Ein Beispiel war die Größenänderung von Bildern. Ist es wirklich notwendig, es strikt auf eine Sprache zu beschränken? Denn die Größenänderung von Bildern in PHP könnte tatsächlich in Golang erfolgen.

Tatsächlich ist es wie alle Praktiken optional. Vielleicht ist es in manchen Fällen sogar unerwünscht. Aber Sie müssen verstehen, dass, wenn Sie eine technische Abteilung in einem Unternehmen mit 50 Mitarbeitern haben, 45 davon PHP-Spezialisten sind, weitere 3 Entwickler sind, die sich mit Python, Ansible, Puppet und so etwas auskennen, und in einigen Fällen schreibt nur einer von ihnen Art von Sprache. Ein Go-Dienst zur Größenänderung von Bildern, und wenn er verschwindet, geht das Fachwissen mit. Gleichzeitig müssen Sie nach einem marktspezifischen Entwickler suchen, der diese Sprache beherrscht, insbesondere wenn sie selten vorkommt. Das heißt, aus organisatorischer Sicht ist dies problematisch. Aus Entwicklersicht müssen Sie nicht nur einige vorgefertigte Playbooks klonen, die Sie zum Bereitstellen von Diensten verwenden, sondern Sie müssen sie noch einmal neu schreiben.

Wir bauen derzeit einen Dienst auf Node.js auf, und dies wird nur eine Plattform in der Nähe für jeden Entwickler mit einer eigenen Sprache sein. Aber wir saßen da und dachten, dass das Spiel die Kerze wert war. Das heißt, das ist eine Frage, über die Sie nachdenken sollten.

Wie überwachen Sie Ihre Dienste? Wie sammeln und überwachen Sie Protokolle?

Wir sammeln Protokolle in Elasticsearch und legen sie in Kibana ab. Je nachdem, ob es sich um Produktions- oder Testumgebungen handelt, kommen dort unterschiedliche Collectors zum Einsatz. Irgendwo Lumberjack, woanders etwas anderes, ich erinnere mich nicht. Und es gibt immer noch einige Stellen in bestimmten Diensten, an denen wir Telegraf installieren und woanders separat filmen.

Wie kann man mit Puppet und Ansible in derselben Umgebung leben?

Tatsächlich haben wir jetzt zwei Umgebungen, eine ist Puppet und die andere ist Ansible. Wir arbeiten daran, sie zu hybridisieren. Ansible ist ein gutes Framework für die Ersteinrichtung, Puppet ist ein schlechtes Framework für die Ersteinrichtung, da es praktische Arbeit direkt auf der Plattform erfordert, und Puppet sorgt für Konfigurationskonvergenz. Dies bedeutet, dass die Plattform sich selbst auf dem neuesten Stand hält. Damit die ansibilisierte Maschine auf dem neuesten Stand bleibt, müssen Sie ständig und mit einer gewissen Häufigkeit Playbooks darauf ausführen. Das ist der Unterschied.

Wie halten Sie die Kompatibilität aufrecht? Haben Sie Konfigurationen sowohl in Ansible als auch in Puppet?

Das ist unser großer Schmerz, wir halten die Kompatibilität mit unseren Händen aufrecht und überlegen, wie wir jetzt irgendwo von all dem weiterkommen können. Es stellt sich heraus, dass Puppet Pakete ausrollt und dort einige Links pflegt, und Ansible beispielsweise den Code ausrollt und dort die neuesten Anwendungskonfigurationen anpasst.

In der Präsentation ging es um verschiedene Versionen von Ruby. Welche Lösung?

Das ist uns an einem Ort begegnet und wir müssen es die ganze Zeit im Kopf behalten. Wir haben einfach den Teil, der auf Ruby lief und mit den Anwendungen nicht kompatibel war, ausgeschaltet und ihn getrennt gehalten.

Die diesjährige Konferenz DevOpsDays Moskau findet am 7. Dezember im Technopolis statt. Bewerbungen für Gutachten nehmen wir bis zum 11. November entgegen. Schreiben uns, wenn Sie sprechen möchten.

Die Anmeldung für Teilnehmer ist geöffnet, seien Sie dabei!

Source: habr.com

Kommentar hinzufügen