Get best of the week

Kubernetes, Microservices, CI / CDs und Docker für Retrograde: Lerntipps

Das Thema „Warum brauchen wir Kubernetes?“ Scheint schon ärgerlich. Ich möchte sagen: „Jeder, der es braucht, hat es lange verstanden“, aber ich würde die technischen (und nahezu technischen) Mitarbeiter in diejenigen einteilen, die „verstanden haben und wissen, wie man es benutzt“, und diejenigen, die „verstanden haben, aber wissen wollen, wie man Wissen relevant macht ".

Vielleicht sind Sie ein Manager, der seit 10 Jahren am selben Stack arbeitet. Sie sind möglicherweise ein Entwickler, der die alte Lösung unterstützt oder in einer vertrauten Sprache in einer vertrauten Umgebung schreibt. Vielleicht haben Sie gerade vom technischen zum organisatorischen Management gewechselt und plötzlich herausgefunden, dass alles, was Sie wussten, nicht mehr relevant ist, und ich möchte verstehen, ob es ein relativ einfaches Szenario gibt, wie dies aufgeholt werden kann. Ich werde versuchen, Ratschläge zu geben, die auf meinen eigenen Erfahrungen beruhen - von einer Person, die erkannt hat, dass das Organisationsmanagement bald durch die Worte „Kubernetes ist eine effektive Technologie, wir müssen nach ihrer Anwendung streben“ ausgedrückt wird, ohne vollständig zu verstehen, was dahinter steckt mit diesen Worten und hinter all der technischen Kultur, die sich in letzter Zeit entwickelt hat.

Warum finde ich es wichtig, das Paradigma des technologischen Denkens ändern zu können?

Das Schwierigste für diejenigen, die schon lange in der Technologie arbeiten, ist zu akzeptieren, dass der neue Trend dauerhaft geworden ist. In über 20 Jahren Arbeit habe ich gesehen, wie verschiedene Technologien kamen und gingen, und einige von ihnen waren mehrere Monate lang „überrelevant“.

Ich habe Joel Spolsky darüber gelesen, wie Microsoft systematisch einen neuen Stack für Entwickler erfindet, um sie generell daran zu hindern, sich etwas anderes anzusehen. Wie SRE hatte ich doppelte Angst vor jeder neuen Technologie: Alles Neue ist roh, alles Rohe ist instabil. Nun, alles, was instabil ist, führt zu Problemen in der Produktion, und Produktionsstabilität ist die Hauptsache.

Als Programmierer und Unternehmer wollte ich ein Produkt schneller erstellen - ich muss alles Neue lernen, die üblichen Ansätze ändern, dh Funktionen langsamer einführen. Wenn einige neue Technologien schnell eingeführt wurden, musste alles gelehrt werden, was mit mikroserviceorientierter Entwicklung zu tun hat (nennen wir es den gesamten modernen Stack). Und jedes Jahr länger zu lernen; Es ist viel einfacher, auf die altbekannte Weise zu schreiben und das Produkt schneller zu liefern.

Aber die Tatsache bleibt: Manchmal bleiben neue Technologien bestehen und verändern das gesamte Paradigma vollständig. Und hier ergibt sich die Wahl: im alten Paradigma zu bleiben oder in ein neues zu wechseln. Cobol-Programmierer können immer noch einen Job bekommen, Perl-Entwickler erinnern sich an die Buchung, aber alternative Wege für diese Leute werden immer weniger. Und dann wird „rückläufig“ im Namen der Stabilität zu einer Einschränkung. Wenn Sie sich beim gesamten modernen Stack nicht einschränken möchten, ist die Zeit nicht gekommen, aber wir sind bereits im Rückstand. Und wenn wir nicht in Perl stecken bleiben wollen, müssen wir lernen. Es braucht viel Zeit. Ich werde versuchen, meine schrittweisen Erfahrungen beim Lernen zu erzählen.

Tauchanweisungen


Verstehen, wie Anwendungen in Docker ausgeführt werden. Zuallererst sollten Veteranen verstehen, dass sich die Art und Weise, Anwendungen zu speichern und zu starten, für immer geändert hat. Höchstwahrscheinlich hat ein Entwickler, der in den letzten Jahren gelernt hat, sich zu entwickeln, keine Ahnung, wie eine Anwendung in der Produktion ohne Docker ausgeführt werden soll. Im Kopf eines solchen Entwicklers gibt es wahrscheinlich kein Konzept für "Dateien lokal speichern", außer in seltenen Fällen von gemeinsamem Speicher, aber die Hauptsache, die ein "Veteran" verstehen muss, ist: Docker ist eine neue Exe. Das exe-Format mag seine Nachteile haben, aber niemand denkt wirklich darüber nach.

Ja, der Microservice-Ansatz ist zum Standard geworden. Wie es schien, schien OOP großen Teams das Schreiben großer Software zu erleichtern. Jetzt sind Microservices zum gleichen Standard geworden. Sie werden sogar von denselben Leuten kultiviert (siehe Fowler) Dies ist sinnvoll: Wenn die Anwendungs-API versioniert ist, ist es für einzelne Teams einfacher, eigenständige Anwendungen zu schreiben als für eine große. Warum sollte man einen Microservice für kleine Anwendungen schreiben, kann man argumentieren, aber irgendwann haben alle angefangen, sie im OOP-Stil zu schreiben - nur so vertraut (siehe oben über exe). Es gibt viel zu argumentieren, dass die Interprozesskommunikation (insbesondere die auf dem TCP-Stack basierende) eine Million Leistungsmängel aufweist (ein Dienst wird über TCP zum anderen übertragen, anstatt nur einen Assembler-Aufruf durchzuführen - Sie können sich vorstellen, worin der Unterschied besteht Produktivität?), aber die Tatsache bleibt, dass Microservices die Vorteile der Entwicklung mittlerer und großer Projekte haben und auch zum Standard geworden sind. Verstehen Sie, wie Microservices miteinander interagieren (HTTP API, grpc,Asynchrone Interaktion über die Warteschlange (eine Million Möglichkeiten) als Bonus - verstehen, was ein Service-Mesh ist. (Ein Moment des wütenden Humors: Gott, Leute, sie hatten die Idee, die Anwendung zu teilen, und es stellte sich heraus, dass die Kommunikation zwischen den geteilten Anwendungen ein schwieriger Witz ist. Deshalb haben sie eine weitere Ebene hinzugefügt, um den Interprozess-Horror zu lindern. Was ist das für uns?)

, .Wir haben uns also darauf geeinigt, dass wir jetzt die Anwendungen im Docker starten und die Anwendung für Microservices freigeben. Jetzt müssen wir die laufenden Docker irgendwie verwalten. Sie können dies selbst auf dedizierten Servern tun (und beispielsweise Docker Swarm steuern oder Kubernetes erstellen) oder die von Clouds bereitgestellten Dienste verwenden - Containerservices von AWS oder Kubernetes. Die Verwendung von Wolken hat einen großen Vorteil. Sie hören tatsächlich auf, an die Ebene zu denken, die unter dem Containermanager ausgeführt wird (SRE wird jetzt lachen, aber lassen Sie uns zugeben - wenn alles stabil ist, klettern wir in den meisten Fällen nicht auf GKE-Knoten). Tatsächlich verwandelt sich der Containermanager, zu dessen Standard-Kubernetes geworden ist, in ein Betriebssystem. Es hat Paketmanager, Sie können "Software installieren", Sie können "exe-shniki" darin ausführen - Docker,es hat kronjoby. Kubernetes ist ein neues Betriebssystem.

Verstehen Sie, wie Docker-Container geliefert werden müssen. Das Layout einer einfachen Site dauert jetzt 5 Minuten, und die Leute halten dies für die Norm. Wir müssen den Docker sammeln, testen, in die Registrierung stellen und in den Docker-Manager stellen (lassen Sie uns mehr über Kubernetes sprechen). Dies ist die Wildheit (?), An die jeder gewöhnt ist, sie ist optimiert und dies ist der Standard. CI / CD-Systeme sind zum Standardlayout geworden und müssen behandelt werden. Genau wie bei GitOps.

Verstehen Sie, dass On-Premise-Hosting für die meisten Anwendungen der Vergangenheit angehören wird (im Westen - bereits weg).Es war einmal die Norm, Server zu kaufen, zusammenzubauen, nach DC zu bringen, Colocation zu betreiben und zu wechseln. Auch für ein kleines Projekt. Dann kamen dedizierte Server. Wie viele Menschen denken jetzt daran, Eisen bei kleinen und mittleren Projekten zu quälen, zu kaufen und zu sammeln? Engagiert - jetzt im Westen und bald in der Russischen Föderation - wird durch Wolken ersetzt. Darüber wird seit hundert Jahren gesprochen, ich verwende AWS seit 2008 und es gibt Probleme, aber wenn wir über den Dienst sprechen, der die Verwaltung von Kubernetes (EKS, GKE, Kubernetes von Yandex oder Selectel) übernimmt, verstehe ich nicht, warum Kubernetes und Dediks selbst, wenn andere es tun? Ich wechsle die Kühler in Dediks nicht mehr ... Die Frage nach der Verbreitung von Kubernetes-Distributionen vor Ort in der Russischen Föderation ist eine Frage des Dollarkurses.das Gesetz über Persdans und "Jugend" des russischen Cloud-Hostings. Früher oder später wird dies entschieden und vor Ort wird die Wildheit, die Unternehmen und große Projekte wollen. Mit Basen das gleiche. Wenn es sich um die meisten Anwendungen handelt, für die keine extrem hohe Last oder keine besonders leistungsstarke Optimierung erforderlich ist, bietet Cloud-basiertes PostreSQL / MongoDB / MySQL eine Vielzahl von Vorteilen. Sie müssen nicht über das Optimieren nachdenken, Sie müssen nicht über Backups nachdenken. Erstellen Sie einen Entwicklungsserver von einem Produktionsserver aus - einige Befehle in der Cloud-Konsole. Ich verstehe, dass diese ganze Idee Ärger beim Administrator verursachen kann: Leute, ich bin selbst der Administrator, aber für die meisten nicht schlechten Aufgaben ist die Datenbankverwaltung jedoch nicht erforderlich. Vielleicht sind AWS und GKE aufgrund des persischen Gesetzes teuer und für uns unzugänglich, aber dies ist nur eine zusätzliche Zeitverzögerung: Früher oder später werden Yandex oder Selectel dieselben Funktionen haben.und das Paradigma wird sich ändern.

Verstehen Sie, welche Infrastruktur jetzt geschrieben ist. Ich mochte IaaC nicht, als er Chefkoch und Marionette war, aber Gott sei Dank wurden sie durch angemessenere Terraform und Pulumi ersetzt, um zu beschreiben, was Sie im Cluster erhöhen möchten, und Ansible, um darin zu arbeiten. Gehen Sie hinein und legen Sie etwas in die Muschel - jetzt absolute Wildheit. Ja, es ist schneller und bequemer, aber im neuen Paradigma ist es Wildheit: Denken Sie an exe.

Tieftauchkurs


Wie sehe ich einen bestimmten technischen Weg, um zu verstehen, wie man mit einem modernen Stapel arbeitet?

1) Erstellen Sie ein Testkonto für Cloud-Hosting. Alle Hosting-Anbieter stellen sie zur Verfügung. Ich habe mit GKE angefangen, aber Sie können beispielsweise ein Konto für russische Hosting-Dienste erstellen, wenn Sie erwarten, dass Sie höchstwahrscheinlich in diesem Gebiet arbeiten werden.
Wenn Terraform / Pulumi Ihre Cloud unterstützt, beschreiben Sie die Infrastruktur, die Sie in ihnen erstellen möchten. Wenn Sie Programmierkenntnisse haben, empfehle ich Pulumi: Anstelle Ihrer eigenen Terraform SDL können Sie in vertrauten Sprachen und Konstrukten schreiben.

2) Suchen Sie die Anwendung und packen Sie sie in das Docker. Was gibt es zu packen - die Wahl liegt bei Ihnen. Ich entdeckte plötzlich für mich, wie sich NodeJS verbreitete, und beschloss, seine Funktionsweise eingehend zu untersuchen, sodass ich weiterhin mit dem Knoten arbeite. Hier ist zum Beispiel ein Blog über NodeJS , das aufgerufen werden kann, aber im Allgemeinen liegt alles in Ihrem Ermessen.

3) Behandeln Sie die grundlegenden Konstrukte (für, Bereitstellung, Service) von K8S und stellen Sie die Anwendung mit Ihren Händen im K8S-Cluster bereit.

4) Beschäftige dich mit Helm, schreibe ein Helm-Diagramm und setze eine Helm-Anwendung ein.
Nehmen Sie einen kostenlosen Plan für CircleCI als CI-Ke, der nicht festgelegt werden muss, und konfigurieren Sie: Die Konfigurationen ähneln anderen Systemen.

5) Korrigieren Sie die Anwendung über CI-ku.
Trennen Sie CI (was die Anwendung erstellt) und CD. Erstellen Sie eine CD mit GitOps (siehe z. B. ArgoCD).

Was weiter


Von nun an werden Sie im Prinzip die Hauptgrundlagen des modernen Stapels kennen.
Wo kann ich weiter graben?

  • Wenn Sie nach einem Job suchen / im Westen arbeiten möchten, können Sie sich mit Cloud Computing vertraut machen: Senden Sie ein Google-Zertifikat oder ein gleichwertiges Zertifikat von AWS an Cloud Architect (wir haben kürzlich drei solcher Zertifikate bei ITSumma erhalten ). Dies gibt einen Überblick über die Funktionen, die Cloud bieten, und hilft ihnen beim Navigieren. Guter Kurs auf Linuxacademy .
  • Übergabe an CKA: Dies ist ein schwieriges Thema, aber es lohnt sich. Die Vorbereitung auf die Prüfung bietet ein riesiges Wissenspaket.
  • Lernen Sie zu programmieren, wenn Sie nicht wissen wie. Jetzt habe ich die Front studiert und bin erstaunt, wie sich alles verändert hat. Mein Wissen endete irgendwo im Jahr 2012 oder noch früher, zurück in jQuery, die Leute lachen. Das Frontend ist jetzt komplizierter als das Backend, es gibt eine Menge Anwendungslogik und gleichzeitig Paradigmen, die für mich völlig ungewöhnlich sind. Sehr interessant!

Und ich bin ein bisschen regelmäßiger als der Blog hier, ich behalte meinen Telegrammkanal , abonniere :-)

More articles:


All Articles