Im Zeitalter der Gewinner von DevOps müssen Entwickler lediglich wissen, warum Docker-Container benötigt werden und wie sie damit arbeiten sollen. Dies erleichtert die Arbeit erheblich. Darüber hinaus können auch diejenigen, die mit .Net Core in der Visual Studio 2017-Entwicklungsumgebung arbeiten, die volle Leistungsfähigkeit der Containerisierung spüren. Pavel Skiba, Leiter der Abteilung für die Entwicklung von Serveranwendungen, sprach beim
Panda-Meetup C # .Net- Meeting über die verfügbaren Tools und die Konfiguration von Docker für VS.
Was sollte ein Entwickler können? "Programm", antwortest du und ... Vermutung. Aber wenn früher die Liste der notwendigen Kenntnisse damit endete, fängt sie jetzt im DevOps-Zeitalter gerade erst an. Wenn wir Code schreiben, müssen wir unbedingt die Netzwerkstruktur kennen: Was interagiert mit was? Es ist Unterstützung für mehrere Programmiersprachen gleichzeitig erforderlich, und verschiedene Codeteile in einem Projekt können auf alles geschrieben werden.
Wir müssen wissen, wie die Software zurückgesetzt werden kann, wenn ein Fehler erkannt wird. Wir müssen Konfigurationen für verschiedene im Unternehmen verwendete Umgebungen verwalten - dies sind mindestens mehrere Entwicklungsumgebungen, Test- und Kampfumgebungen. Oh ja, Sie müssen immer noch Skripte auf verschiedenen Servern / Betriebssystemen verstehen, da nicht alles mit Code ausgeführt werden kann. Manchmal müssen Sie Skripte schreiben.
Wir müssen die Sicherheitsanforderungen kennen, und sie werden härter und verbrauchen viel Zeit vom Entwickler. Vergessen Sie nicht die Unterstützung und Entwicklung verwandter Software: Git, Jenkins und so weiter. Infolgedessen hat der Entwickler möglicherweise einfach nicht genug Zeit für die reine Entwicklung.
Was tun? Es gibt einen Ausweg, der in den Docker-Containern und ihrem Managementsystem liegt. Sobald Sie all diesen komplexen Koloss bereitgestellt haben, werden Sie, wie in den guten alten Zeiten, nur noch einmal Code schreiben. Alles andere wird entweder von anderen Personen oder vom System selbst gesteuert.
Wir verstehen Container
Was ist ein Docker-Container? Dies ist eine Struktur, die aus mehreren Schichten besteht. Die oberste Ebene ist die binäre Ebene Ihrer Anwendung. Die zweite und dritte Schicht sind jetzt in .Net Core integriert, der Container ist bereits SDK-shny. Die nächste Schicht hängt vom Betriebssystem ab, auf dem der Container bereitgestellt wird. Und die unterste Schicht ist das Betriebssystem selbst.
Auf der unteren Ebene wird Windows Nanoserver bereitgestellt. Dies ist eine Mega-Kürzung von Windows Server, die nichts anderes tun kann, als ein bereitgestelltes Dienstprogramm zu warten. Aber ihre Lautstärke ist 12 mal geringer.
Wenn wir die physischen und virtuellen Server und Container vergleichen, liegen die Vorteile der letzteren auf der Hand.
Als alles auf physischen Servern funktionierte, waren wir mit einer Reihe von Problemen konfrontiert. Die Bibliothekscodes waren nicht isoliert, einige Anwendungen konnten sich gegenseitig stören. Beispiel: Eine Anwendung arbeitete mit .Net 1.1 und eine andere mit .Net 2.0. Meistens führte dies zu einer Tragödie. Nach einiger Zeit erschienen virtuelle Server, das Problem der Isolation wurde gelöst, es gab keine gemeinsam genutzten Bibliotheken. Gleichzeitig wurde es in Bezug auf Ressourcen und Arbeitskräfte sehr teuer: Es war notwendig zu verfolgen, wie viele virtuelle Maschinen sich auf einer virtuellen Maschine, auf Hyper-V und auf einem Stück Eisen drehten.
Container wurden als kostengünstige und bequeme Lösung konzipiert, die nur minimal vom Betriebssystem abhängt. Mal sehen, wie sie sich unterscheiden. Virtuelle Server im System befinden sich ungefähr so.
Die unterste Schicht ist der Host-Server. Es kann entweder physisch oder virtuell sein. Die nächste Schicht ist ein Betriebssystem mit Virtualisierung, oben ein Hypervisor. Oben befinden sich virtuelle Server, die in Gastbetriebssysteme und Anwendungen unterteilt werden können. Das heißt, unter jedem virtuellen Server wird ein Gastbetriebssystem über dem Betriebssystem bereitgestellt, was eine zusätzliche Verschwendung von Ressourcen darstellt.
Mal sehen, wie sich Linux-Container auf dem System befinden.
Wie Sie sehen können, befinden sich Binärdateien mit Anwendungen unmittelbar über dem Hostserver und dem Betriebssystem. Gastbetriebssystem wird nicht benötigt, Ressourcen werden freigegeben, Lizenzen für Gastbetriebssystem werden nicht benötigt.
Windows-Container unterscheiden sich geringfügig von Linux.
Die grundlegenden Schichten sind die gleichen: Infrastruktur, Host-Betriebssystem (aber jetzt Windows). Dann können die Container jedoch direkt mit dem Betriebssystem zusammenarbeiten oder über dem Hypervisor bereitgestellt werden. Im ersten Fall gibt es eine Isolierung von Prozessen und Räumen, aber sie verwenden denselben Kern wie andere Container, die aus Sicherheitsgründen kein Eis sind. Wenn Sie Container über Hyper-V verwenden, wird alles isoliert.
Docker für VS lernen
Fahren wir mit Docker selbst fort. Angenommen, Sie haben Visual Studio und installieren den Docker-Client für Windows zum ersten Mal. In diesem Fall stellt Docker den Docker-Dämonserver, die Schnittstelle in Rest für den Zugriff darauf und den Client selbst bereit - die Docker-Befehlszeile. Damit können wir alles verwalten, was mit Containern zu tun hat: Netzwerk, Bilder, Container, Ebenen.
Die Folie zeigt die einfachsten Befehle: Docker-Container ziehen, starten, sammeln, festschreiben, zurücksenden.
Docker ist sehr organisch mit Visual Studio gepaart. Der Screenshot zeigt ein Bedienfeldmenü aus Visual Studio 2017. Die Unterstützung für das Erstellen von Docker ist direkt in Intellisense integriert, Dockerfile wird unterstützt und alle Artefakte funktionieren über die Befehlszeile.
Interessanterweise können wir Docker-Container direkt in Echtzeit debuggen. Und wenn Ihre Container miteinander verbunden sind, werden sie sofort auf einmal entwertet, und Sie müssen nicht mehrere Umgebungen ausführen.
Wie werden Container zusammengebaut? Das Hauptelement hier ist die Docker-Datei, die Anweisungen zum Erstellen des Images enthält. Jede Docker-Datei wird für jedes Projekt erstellt. Es zeigt an: Woher bekommen wir das Basis-Image, welche Argumente übergeben wir, wie heißt das Arbeitsverzeichnis mit Dateien, Ports?
Dieses Quellargument hat zwei Parameter. Der zweite Parameter ist der Pfad, auf dem das Assembly-Ergebnis im Projekt platziert wird. Der Wert ist standardmäßig festgelegt. Meiner Meinung nach ist dies keine sehr gute Option. In diesem Ordner befindet sich häufig viel Müll. Er muss regelmäßig gereinigt werden. Wenn wir diesen Ordner bereinigen, können wir die Baugruppe reiben. Wenn Sie möchten, können Sie es ändern. Es wird durch den Systemparameter Docker_build_source festgelegt, der auch gehämmert werden kann.
Mit der Entrypoint-Anweisung können Sie den Container als ausführbare Datei konfigurieren. Diese Zeile wird für .Net Core benötigt, damit nach dem erfolgreichen Start des Containers die Meldung "Ihre Anwendung wird ausgeführt" an die Befehlszeile gesendet wird.
Nun zum Debuggen von Containern. Alles hier ist wie ein normales .Net, Sie werden den Unterschied kaum bemerken. Meistens führe ich .Net Core als selbst gehostet unter dotnet.exe aus. Es verwendet den CLRDBG-Debugger, den NuGet-Paketcache und den Quellcode.
ASP.Net 4.5+ wird von IIS oder IIS Express gehostet, verwendet Microsoft Visual Studio Debugger und die Quelle des Site-Stamms in IIS.
Es gibt zwei Umgebungen zum Debuggen: Debug und Release. Das Debugging-Image-Tag ist als dev und die neueste Version markiert. Beim Debuggen wird das Quellargument besser auf obj / Docker / empty gesetzt, um nicht verwirrt zu werden, sondern wenn Sie obj / Docker / Publish freigeben. Hier können Sie dieselben Binärdateien, Ansichten, Ordner wwwroot und alle vorhandenen Abhängigkeiten verwenden.
Beherrschen von Docker Compose
Kommen wir zum lustigen Teil: dem Docker-Compose-Orchestrierungs-Tool. Schauen wir uns ein Beispiel an: Sie haben eine Art Geschäftsdienst, der 5-6 Container betrifft. Und Sie müssen irgendwie festlegen, wie sie in welcher Reihenfolge zusammengebaut werden sollen. Hier bietet sich Docker-compose an, das die gesamte Montage, den Start und die Skalierung von Containern ermöglicht. Es wird einfach verwaltet, alles wird von einem Team gesammelt.
Docker-compose verwendet YAML-Dateien, in denen die Konfiguration für die Zusammenstellung von Containern gespeichert ist. Sie beschreiben, welche Einstellungen Sie für die Images selbst, Assemblys, Services, Volumes, Netzwerke und Umgebungen verwenden müssen. Die Syntax ist für die Veröffentlichung in Clustern identisch. Das heißt, sobald sie eine solche Datei geschrieben haben und in Zukunft ein Geschäftsdienst in einem Cluster bereitgestellt werden muss, müssen Sie nichts mehr hinzufügen.
Betrachten Sie die Struktur einer YAML-Datei. Bild ist ein Docker-Bild. Ein Bild ist ein Container ohne Anwendungsschicht und unveränderlich.
Build gibt an, wie erstellt, wo erstellt und wo bereitgestellt werden soll.
Depends_on - Abhängigkeit davon, von welchen Diensten es abhängig ist.
Umwelt - hier stellen wir die Umwelt ein.
Ports - Zuordnung von Ports, an welchem Port Ihr Container verfügbar sein wird.
Betrachten Sie ein Beispiel. Wir haben nur eine API ohne Service, im Wesentlichen 3 Container: Es gibt SQL.data unter Linux, es gibt eine Anwendung selbst, es hängt von Webapi ab und Webapi hängt von SQL.data ab.
Es spielt keine Rolle, in welcher Reihenfolge die Komponenten in die Datei geschrieben werden. Wenn alles korrekt beschrieben ist, erstellt Compose diese Informationen basierend auf den Abhängigkeiten im Projekt automatisch korrekt. Diese Datei reicht aus, um alle Container gleichzeitig zu sammeln. Die Ausgabe ist eine fertige Version.
Es gibt eine Art „Container-Container“, einen speziellen Container docker-compose.ci.build.yml, in dem die gesamte Komposition zusammengestellt wird. Sie können diesen speziellen Container über die Visual Studio-Befehlszeile ausführen und die Assembly auf einem Build-Server abschließen, z. B. in Jenkins.
Schauen Sie sich die Datei an. Das Beispiel enthält das Arbeitsverzeichnis und woher es kommt. Er stellt das Projekt von GIT wieder her, veröffentlicht diese Lösung selbst, konfiguriert Release und lädt das Ergebnis hoch. Das ist das ganze Team, das aufgebaut werden muss, sonst muss nichts geschrieben werden. Es reicht aus, es einmal zu registrieren und dann die Veröffentlichung mit einer Schaltfläche zu starten.
Was es sonst noch wert ist, beachtet zu werden. Docker-Compose für jede Umgebung sammelt Bilder, für jede Konfiguration eine separate Datei. Für jede Konfiguration in Visual Studio gibt es eine Datei mit den Einstellungen, die Sie für die Umgebung benötigen.
Direkt von VS aus können Sie remote mit dem Debuggen der gesamten Komposition beginnen.
Cluster-Orchestratoren
Abschließend gehen wir auf Themen wie Cluster-Orchestratoren ein. Wir sollten nicht darüber nachdenken, wie Container weiterhin existieren, welche Personen oder Systeme verwaltet werden. Hierfür gibt es vier der beliebtesten Containerverwaltungssysteme: Google Kubernetes, Mesos DC / OS, Docker Swarm und Azure Service Fabric. Mit ihnen können Sie das Clustering und die Zusammensetzung von Containern verwalten.
Diese Systeme sind in der Lage, eine große Schicht von Mikrodiensten zu bewältigen und bieten ihnen alles Notwendige. Der Entwickler muss diese Ebene nur einmal konfigurieren.
Die Vollversion der Aufführung bei Panda Meetup ist unten verfügbar.
Für diejenigen, die tiefer in das Thema eintauchen möchten, empfehle ich Ihnen, die folgenden Materialien zu studieren:
Http://dot.net
Http://docs.docker.com
Http://hub.docker.com/microsoft
Http://docs.microsoft.com
Http://visualstudio.com
Und schließlich ein wichtiger Ratschlag aus der Praxis: Am schwierigsten ist es, sich daran zu erinnern, wo was liegt.
Die Dokumentation bei der Arbeit mit Docker-Containern fällt Ihnen auf die Schultern. Ohne Dokumentation werden Sie vergessen, wo in welchem Container was mit was verbunden ist und was funktioniert. Je mehr Dienste verfügbar sind, desto größer ist das gesamte Verbindungsnetz.