Das RIT 2018 Festival in Skolkovo war groß und sehr vielfältig. Mobile Entwicklung, Backend, Frontend, DevOps, Projektmanagement und sogar Psychologie sind Themen für jeden Geschmack und in einem vollen Zeitplan von morgens bis abends. Die Themen sind in separate Spuren unterteilt, die Spuren sind an die Hallen gebunden. Wenn nur spezielle Berichte von Interesse sind, können Sie sich im richtigen Raum niederlassen. Der Keynote-Saal wurde jedoch nach Bedarf von Referenten verschiedener Themen genutzt.
Im Großen und Ganzen war ich mit dem Wissen von DevOps vertraut, und nachdem ich meine Eindrücke von der Konferenz mit meinen Kollegen geteilt hatte, stellte ich eine kurze Liste von Berichten zusammen, an die ich mich erinnerte. Einige Monate vergingen, und ich erinnere mich noch gut daran, worüber sie gesprochen haben.
Also 3 technische Berichte, an die ich mich bei RIT 2018 erinnerte.
Überwachung und Kubernetes
Die jetzt verwendeten Überwachungstools unterstützen Anwendungen der Microservice-Architektur nicht so gut. Je dynamischer das System ist, desto schwieriger ist es, die Überwachung dafür zu konfigurieren. Eine bequeme Überwachung von Clustersystemen wie Kubernetes, die dem Extremismus Dynamik verleihen, ist im Allgemeinen keine triviale Aufgabe. Warum so? Dmitry Stolyarov, technischer Direktor von Flant, spricht über die Gründe für diese Komplexität und ihre Auswirkungen auf die Hauptüberwachungsmission.
Herkömmliche Überwachungssysteme basieren auf der Arbeit mit statischen Servern, die relativ selten zur Anwendungsinfrastruktur hinzugefügt und daraus entfernt werden. In Kubernetes erfolgt das Erstellen und Löschen von Herdumgebungen und Dienstanwendungen jede Sekunde, sodass vorhandene automatische Erkennungsverfahren dieses Volume einfach nicht bewältigen können.
Die Anzahl der Umgebungen selbst liegt ebenfalls bei zehn und Hunderten. Dementsprechend erhöht sich die Menge der übertragenen Telemetrie um den gleichen Betrag. Und sie muss noch irgendwo aufbewahrt werden.
Ein separates Problem ist die Kollision der physischen und der virtuellen Welt: Der Ressourcenverbrauch von Anwendungen in Kubernetes ist sehr kurzlebig und spiegelt sich in Einschränkungen der Herde wider. Der Verbrauch von Pod-Ressourcen wirkt sich jedoch bereits spezifisch auf die verfügbaren Serverkapazitäten aus. Wenn Sie Diagramme betrachten, müssen Sie immer berücksichtigen, aus welcher Sicht Sie Ressourcen betrachten. In der Praxis interessieren sich nur wenige Menschen für einzelne Pods. Interessant ist der Ressourcenverbrauch der gesamten Anwendung, und dies erfordert bereits eine flexible Gruppierung von Telemetrie-Pods nach bestimmten von Benutzern festgelegten Kriterien.
Und Sie müssen das resultierende Schema für die weit verbreiteten Entwicklungs- / Staging- / Produktumgebungen mehrmals erhöhen!
Der Bericht wird jedem empfohlen, der den Kubernetes-Cluster unterstützen muss.
Link zur Präsentation.
Box Development Devops
Es war äußerst interessant für uns, den Bericht von Maxim Lapshin zu hören, in dem er die seltene Erfahrung des Einsatzes von Devo-Praktiken bei der Entwicklung von Boxprodukten teilte. Ein Boxed-Produkt ist eine herkömmliche Software, die mit Benutzerfunktionen installiert und ausgeführt wird.
Erlyvideo entwickelt einen Video-Streaming-Server. Wir sind ein Konfigurationsserver für Internetdienste. Unsere Probleme ähneln in vielerlei Hinsicht denen, die die DevOps-Transformation von ErOlvideo verursacht haben.
Maxim beginnt den Bericht mit einer Antwort auf die wichtigste Frage: "Wofür ist das alles?" Dieselben Faktoren, die die Einführung der DevOps-Kultur bei der Entwicklung von Dienstleistungen vorantreiben, sind auch in Branchen vorhanden, in denen eine traditionellere Entwicklung im Gange ist. Und der Einfluss dieser Faktoren auf verpackte Produkte wird wahrscheinlich dramatischer sein als bei der Arbeit an einer Dienstleistung. Je weniger Releases beispielsweise verfügbar sind, desto mehr Änderungen werden bereitgestellt. Wenn Sie einen neuen Service einführen, können Sie sicherstellen oder sich einfach davon überzeugen, dass er sicher ist. Wenn Sie jedoch eine Produktdistribution mit einer Vielzahl von Änderungen veröffentlichen, reicht es nicht aus, sich von der Sicherheit des Updates zu überzeugen, sondern Sie müssen auch Ihre Benutzer von der Sicherheit des Updates überzeugen. Hier helfen kleine, aber häufige Wechselstücke. Und das ist nur eines der Probleme.
Der Bericht befasst sich eingehender mit diesem und vielen anderen Gründen für die Verwendung der kontinuierlichen Bereitstellung, das Ziehen von Parallelen und das Hervorheben der Unterschiede zu der allgemein einfacheren Arbeit im CI / CD-Modus mit Diensten.
Wie ist das möglich? In dem Bericht beschreibt Maxim die in Erlyvideo verwendeten Vorgehensweisen, um eine kontinuierliche Bereitstellung des Änderungsflusses zu gewährleisten. Viele Ansätze werden so wie sie sind nützlich sein, etwas wird eine Anpassung an die Realität unserer Arbeit erfordern. Auf jeden Fall kann diese wunderbare Erfolgsgeschichte dazu inspirieren, ihre Probleme zu überdenken und Lösungen in einer Vielzahl von DevOps-Praktiken zu finden.
Der Bericht wird für alle, die an Produktdistributionen arbeiten, sehr interessant sein.
Link zur Präsentation.
Kubernetes-Netzwerkbasen
Die allgegenwärtige Kurzanleitung, der Crashkurs und die Tutorials „Erste Schritte mit Kubernetes“ machen es relativ einfach, in dieses Auto zu springen, einen Cluster bereitzustellen und die Anwendung bereitzustellen. Angesichts der unglaublichen Popularität dieses Themas tun es viele. Vergessen Sie jedoch nicht, dass Kubernetes im Wesentlichen ein ziemlich komplexes System ist, dessen Wartung spezifisches Wissen erfordert. In Ingram Micro Cloud war dieses Wissen erforderlich, als die nächste Anwendung plötzlich nicht mehr über das Netzwerk verfügbar war. Aus der Untersuchung dieses Vorfalls begann die faszinierende Reise von Alexander Khayorov durch das Netzwerksubsystem.
Der Bericht führt uns in die immer komplexer werdenden Elemente des Kubernetes-Netzwerkstapels ein und erklärt, wie groß und komplex das Routing aus Elementarblöcken besteht. Es stellt sich als besonders interessant heraus, wenn Alexander darüber spricht, warum dies getan wird, und nicht anders, als hypothetische andere Implementierungsoptionen zu modellieren.
Dies ist wirklich das Kubernetes-Alphabet, auf das die meisten Benutzer stoßen werden. Ich selbst stellte die Fragen "Warum NodePort?" und "Warum sehe ich die IP meines Dienstes nicht auf der Schnittstelle?"
Interessant und informativ.
Link zur Präsentation.