Warum sollte sich ein Entwickler für Docker interessieren?

11

Im Allgemeinen kümmert sich ein Entwickler darum, die Geschäftsanforderungen zu erfüllen. Er / sie verfügt möglicherweise über das Fachwissen in einem bestimmten Stack oder Framework. Aber sollte er / sie sich bemühen, Docker und seine verschiedenen Bereitstellungsmethoden (Schwarm, Würfel, Mesos usw.) zu lernen?

Einfach ausgedrückt, warum sollte sich ein Entwickler für Docker interessieren?

PS: Die übergeordnete Frage zu diesem Beitrag lautet: Implikation der Einführung von Docker in das Entwicklungsteam

docker project-management orchestration

— Abhay Pai
quelle

7

Wahrscheinlich nicht die Antwort, die Sie suchen, aber dennoch eine Antwort :)

Das Erlernen von Docker und seiner Bereitstellungsmethoden könnte tatsächlich in die Geschäftsanforderungen einbezogen werden, indem es Teil der Projekt- oder Teamentwicklungsumgebung wird, genau wie die Codesprache (n), das Versionskontrollsystem, die Compiler, die Testinfrastruktur usw. -, um darin zu arbeiten Das Team oder das Projekt, über das man Bescheid wissen und das man nutzen muss, kann (in den meisten Fällen) keine "eigenen mitbringen".

Die Dinge werden etwas komplizierter, wenn Sie mit "einem Entwickler" tatsächlich die Mehrheit oder sogar das gesamte Entwicklungsteam meinen. Es wird sehr schwierig sein, ein Tool in die Entwicklungsumgebung zu bringen, ohne dass einer der Entwickler es unterstützt. Nehmen Sie sich Zeit, um zuerst einen solchen Unterstützer aus der technischen Leitung des Teams zu erstellen.

Randnotiz: Es ist möglicherweise auch nicht erforderlich, dass jeder Entwickler im Team Docker-Experte wird. Mit vordefinierten Verwendungsrezepten, die in einfache, für Cheatsheets geeignete Befehle verpackt sind, können Entwickler häufig Docker-basierte Lösungen verwenden, ohne zu viel über ihr Innenleben zu wissen, was insbesondere in großen Teams durchaus akzeptabel sein kann. Genauso wie Sie Code beitragen können, ohne alle Details darüber zu kennen, wie das Endprodukt erstellt wird.

— Dan Cornilescu
quelle

Darüber hinaus können Sie auf jeder gewünschten Technologie aufbauen, wodurch Sie weniger Einschränkungen haben und Sysadmins weniger Kopfschmerzen haben, wenn Sie alle verschiedenen Technologien unterstützen. Und da der "Entwickler" die Technologie entscheidet, sollte es an ihm liegen, die Docker-Umgebung zu konfigurieren.

— DarkMukke

@DarkMukke Der "Entwickler" entscheidet nicht immer über die Technologie ... In größeren Entwicklerteams ist das Gegenteil oft der Fall - der "Entwickler" verwendet nur die Technologie, die das Team verwendet. Ausnahmen können toleriert werden , wenn sie nicht stören oder negativ auf die Team-Aktivitäten auswirken.

— Dan Cornilescu

Ich stimme teilweise zu, aber ich habe große (200+) Entwicklerfirmen gesehen, die mit Docker so gearbeitet haben, wie ich es beschrieben habe. Ich denke, es ist eine Frage der persönlichen Auswahl nicht nur der Entwicklerteams, sondern auch der darüber liegenden Führungskräfte. Wenn es anständige Entwickler gibt, ist die Menge an Docker, die ein Entwickler benötigt, normalerweise trivial.

— DarkMukke

6

Ich gebe dir meine Perspektive. Entwickler sollten sich für Docker interessieren, da es andere Entwickler gibt, die bereit sind, Docker zu verwenden, und bereits ein Know-how darin aufgebaut haben. Sie sind bereit, die Rolle eines DevOps-Ingenieurs zu übernehmen und gleichzeitig Entwickler zu sein. Der Ops-Teil von DevOps ist das, worauf sie jetzt aufbauen.

Heutzutage finden Sie immer mehr Leute, die Tests entwickeln, orchestrieren, automatisieren, Jobs automatisieren und Tools erstellen können, um dieses Komplettpaket im Alleingang zu überwachen und in die Produktion zu bringen. Dies sind die Leute, die Docker und andere Tools in der Entwickler-Community vorantreiben.

Die Marktflut geht auch in Richtung Virtualisierung, automatische Skalierung, Automatisierung, maschinelles Lernen, und Docker passt in all diese Bereiche. Es ist sehr wichtig geworden, Docker zu verwenden. Die Unternehmen sind bereit, 2x für einen einzelnen Mann zu zahlen, der all diese Aufgaben übernimmt, und wenn eine Nachfrage nach solchen Männern besteht, beginnt auch das Angebot. Dies ist aus Sicht eines Arbeitnehmers-Arbeitgebers.

Technisch gesehen gibt es in den Organisationen, in denen ich gearbeitet habe, separate Entwicklungs- und DevOps-Teams, obwohl sie bei Lieferungen sehr eng zusammenarbeiten. Die DevOps-Ingenieure und -Entwickler teilen hier die überwiegende Mehrheit der Fähigkeiten, und daher wird manchmal über Aufgaben verhandelt.

Das Nötigste, was ein Entwickler tun kann, ist, seine Binärdateien freizugeben. Er muss jedoch verstehen, dass die Binärdateien zum Ausführen in einem Docker-Container verwendet werden und dass er die Funktionsweise von Docker verstehen muss. Bei Kubes, Schwärmen, Mesos usw. ist es dem Entwickler möglicherweise nicht einmal wichtig, was verwendet wird, aber die Grundlagen des Dockers sollten vom Entwickler sehr gut verstanden werden, und es sollte von Anfang an eine Denkweise vorhanden sein, um die Anwendung zu erstellen, die lose für die Wiederverwendung als gekoppelt ist Mikrodienste. Wenn die Anwendung auf dieser Denkweise basiert (für die Docker-Grundlagen erforderlich sind), können die DevOps-Ingenieure sie von dort aus verwenden, um sie automatisch zu skalieren, zu orchestrieren, zu testen, bereitzustellen und zu überwachen.

Außerdem gibt es meistens keine Einheitsgröße für alle möglichen Dinge. Ein Entwickler weiß nicht genau, wie man eine Docker-freundliche App erstellt, und ein DevOps-Ingenieur kennt die Interna des App-Erstellungsprozesses zu Recht nicht. In den meisten Fällen ziehen es Unternehmen daher vor, beide Aufgaben demselben Mitarbeiter zu übertragen, um die Arbeit zu beschleunigen. Wenn es separate Dinge gibt, ist ein kontinuierlicher Feedback-Mechanismus vom DevOps-Team zum Entwicklerteam erforderlich, um die Apps futuristischer und Docker / Cloud / Skalierung-fähiger zu machen.

— Lakshayk
quelle

5

Es geht nicht um Docker oder andere Containerisierungstechnologien.

Container wie Docker, rkt usw. sind nur eine Möglichkeit, Ihre Anwendung auf ähnliche Weise wie statische Binärdateien bereitzustellen. Sie erstellen Ihre Bereitstellung so, dass sie alles enthält, was sie benötigt, und der Endbenutzer benötigt nur die Laufzeit.

Diese Lösungen ähneln fetten JARs in Java, bei denen alles, was Sie (theoretisch) benötigen, nur die vorinstallierte Laufzeit (JRE) und alles Just Works ™ ist.

Der Grund, warum Entwickler die Orchestrierungs-Tools verstehen müssen (sie müssen nicht lernen, wie man ein solches Tool bedient, sondern nur, warum dies erforderlich ist), besteht darin, dass Sie gegenüber der "herkömmlichen" Bereitstellung einige Vorteile erzielen können.

Rinder, keine Haustiere

EngineYard hat einen guten Artikel darüber geschrieben. Der springende Punkt dabei ist, dass Sie, wenn Ihr Server stirbt, mit den Schultern zucken und warten, bis neue angezeigt werden. Sie behandeln sie als Vieh, Sie haben Zehn, Hunderte, Tausende von ihnen am Laufen, und wenn einer untergeht, sollten sich weder Sie noch Ihre Kunden jemals dessen bewusst sein.

Orchestrierungstools erreichen dies, indem sie den Status aller Anwendungen (Pods / Jobs, was auch immer) im Cluster überwachen. Wenn festgestellt wird, dass einer der Server nicht mehr reagiert (ausfällt), werden alle Anwendungen, die auf diesem Server ausgeführt wurden, automatisch an einen anderen Ort verschoben.

Bessere Ressourcennutzung

Dank der Orchestrierung können Sie mehrere Anwendungen auf einem Server ausführen, und der Orchestrator verfolgt die Ressourcen für Sie. Bei Bedarf werden Anwendungen neu angeordnet.

Unveränderliche Infrastruktur

Dank der automatischen Failover-Behandlung in Orchestratoren können Sie Ihre benutzerdefinierten Images unverändert in der Cloud ausführen. Wenn Sie ein Update benötigen, erstellen Sie einfach ein neues Image, stellen Ihre Startkonfiguration so ein, dass es jetzt verwendet wird, und rollen einfach. Alles wird für Sie erledigt:

Erstellen Sie einen neuen Server mit neuer Konfiguration.
Töte einen laufenden Server.
Ihr Orchestrator verschiebt alles auf andere Maschinen (einschließlich neuer).
Wenn noch alte Server übrig sind, gehen Sie zu 1.

Einfachere Operationen

Nicht genug Resourcen? Neuen Computer zum Cluster hinzufügen.
Benötigen Sie weitere Anwendungsinstanzen? Erhöhen Sie die Anzahl und fahren Sie fort.
Überwachung? Erledigt.
Protokollverwaltung? Erledigt.
Geheimnisse? Erraten Sie, was.

TL; DR Bei Whole geht es nicht um Docker, sondern um Orchestrierung. Docker ist nur eine erweiterte Version von Tarball / Fat-JARs, die für eine ordnungsgemäße Orchestrierung erforderlich sind.

— Hauleth
quelle

Das ist es, worum ich frage und darum geht es in der ganzen Frage. Sollten sich Entwickler für eine bessere Ressourcennutzung, unveränderliche Infrastruktur und einfachere Abläufe interessieren? ... Meiner Meinung nach sollten sie sich auf die Bereitstellung von Geschäftsanforderungen und die Codeoptimierung konzentrieren, die zu einer besseren Ressourcennutzung führen würden. Selbst Docker hilft nicht bei einer besseren Nutzung, wenn es sich um einen schlecht / durchschnittlich geschriebenen Code handelt. Lassen Sie uns die Tatsache akzeptieren, dass die Geschäftsanforderungen dazu führen, dass Entwickler die Dinge schneller liefern. Auf diese Weise haben sie keine Zeit, den Code zu optimieren. Warum ihnen die Verantwortung des Dockers hinzufügen?

— Abhay Pai

Wenn Sie einen Überblick über den gesamten Stack haben, von den Tests über die Implementierung bis hin zur Bereitstellung, können Sie sehen, wie Ihre Software verwendet wird, welche Randfälle vorliegen und was abstürzt. Es wird Sie in dem LOC, das Sie schreiben, verlangsamen, aber ihre Qualität erheblich verbessern. Auf lange Sicht Zeit sparen

— Moritz

4

Hier sind zum Beispiel einige Argumente aus einem Blog-Beitrag, der 2014 veröffentlicht wurde und so betitelt ist, dass er Ihrer Antwort entspricht:

Viel flexibleres Einbringen neuer Technologien in die Umwelt

Es gibt immer noch einen großen Schmerzpunkt zwischen dem Festschreiben des endgültig getesteten Codes und dem Ausführen auf den endgültigen Produktionsservern. Docker vereinfacht diesen letzten Schritt erheblich

Docker macht es trivial, ein älteres Betriebssystem beizubehalten, unabhängig davon, welche Linux-Variante Sie verwenden

Von: https://thenewstack.io/why-you-should-care-about-docker/

— Peter Muryshkin
quelle

Ich bin damit einverstanden, neue Technologien einzuführen. Aber es gibt auch einige Probleme damit. Wie die Verwendung von Docker für Datenbanken ( percona.com/blog/2016/11/16/is-docker-for-your-database ). Sie sind im Moment nicht stabil und würden wahrscheinlich in Zukunft stabil sein. Lass uns auf das Beste hoffen. Wir können den getesteten Code ohnehin mit CI / CD zum Produzieren bringen. Warum dann Docker? Entwicklern ist es egal, auf welchem Betriebssystem wir arbeiten. Warum sollten sie sich überhaupt die Mühe machen, Docker zu lernen? Um Devops das Leben zu erleichtern?

— Abhay Pai

Zunächst denke ich nur an das folgende "MVP" -Szenario: dev probiert eine neue Konfiguration / ein neues Tool für die Umgebung als Infrastrukturkomponente aus, sagt imagemagick. Ohne Docker können diese Informationen verloren gehen oder vergessen werden oder müssen zusammen mit vielen anderen kleinen Dingen kommuniziert werden. Das Freigeben einer Docker-Datei ist eine maschinenprüfbare Einrichtung einer funktionierenden Sache, die sogar zur handwerklichen Einrichtung einer Docker-freien Infrastruktur wertvoller ist als nur eine Dokumentation. Sicher, Sie könnten sich auch für Puppet entscheiden. Das Schöne an Docker ist meiner Meinung nach, wie es in sich geschlossene Szenarien ermöglicht.

— Peter Muryshkin

Einverstanden. Das Problem tritt jedoch während der Orchestrierung auf. Der Entwickler muss über Fachkenntnisse in der Docker-Orchestrierung verfügen, um die Best Practices einhalten und die Geschäftsanforderungen erfüllen zu können. Stellen Sie sich Ihr Szenario vor, in dem Entwickler Imagemagick als Service benötigen. Während er eine Docker-Datei erstellt, erhält er die vollständige Kontrolle über die Pakete, die er im Docker-Image installieren kann. Was ist, wenn sie sshd to ssh im Docker installieren und stattdessen Docker-Protokolle verwenden? Was ist, wenn sie Tools installieren, die nichts mit Geschäftslogik zu tun haben, aber die Sicherheit gefährden? Benötigen Entwickler Docker-Know-how?

— Abhay Pai

hm aber was ist, wenn sie eine sockelbasierte Hintertür implementieren? Docker ersetzt nicht enteprise Firewall, denke ich

— Peter Muryshkin

Wahr. Aber das wäre auf jeden Fall eine böswillige Absicht des Entwicklers. Sei es Docker oder kein Docker. Aber wenn Docker Entwicklern vorgestellt wird, können sie Pannen verursachen, nur weil ihnen das entsprechende Wissen fehlt. Warum sollten sie sich überhaupt die Mühe machen, Docker zu lernen (wenn man bedenkt, dass der Orchestrator auch die Komplexität erhöht), wenn dies zu Pannen und Komplikationen führen kann? Bitte stören Sie meine Fragen nicht. Sogar ich liebe Docker. Aber ich versuche, die Perspektive eines Entwicklers zu verstehen. Ich bin selbst seit 3 Jahren Entwickler und jetzt bin ich DevOps-Ingenieur.

— Abhay Pai

4

Wenn Sie Ihre Produktion im Docker-Container ausführen, ist es wichtig, dass diese Container von denselben Entwicklern erstellt werden, die die darauf ausgeführte App erstellt haben. Wer könnte besser wissen, welche externen Abhängigkeiten benötigt werden und so weiter ...?

Außerdem kann die Pipeline bei jedem Schritt während einer CD fehlschlagen, insbesondere wenn es sich um den Docker-Image-Erstellungsschritt handelt. Manchmal fehlt eine Datei oder eine Bibliothek.

Bei der Arbeit haben wir alle Entwickler mit Docker bekannt gemacht und ihnen die Grundlagen zum Erstellen der Docker-Datei erklärt, um ihre App bereitzustellen. Außerdem haben wir die Pipeline vereinfacht, sodass nur ein Name und eine Docker-Datei hinzugefügt werden können und die App automatisch auf der Docker-Datei erstellt wird nächster Push, unabhängig von der Technologie, die ihn ausführt.

Der Docker-Schnellstart ist wirklich eine großartige Einführung, nachdem das devOps-Team den Entwickler bei der Auswahl der Distribution angeleitet hat (viele von ihnen wissen nichts wie alpine).

Unsere Aufgabe ist es, ihnen einen einfachen Zugang zu den Werkzeugen zu ermöglichen. Den Rest erledigen sie, damit sie das Problem beheben können, wenn etwas nicht stimmt. Docker ist wirklich ein Teil des Entwicklungsprozesses und das devOps-Team stellt ihnen Docker-Images zur Verfügung, die unseren Anforderungen entsprechen und einfach genug sind, sodass es nur ein paar Minuten dauert, eine neue App zu erstellen und sie ohne Unterstützung bereitzustellen.

— Juub
quelle

Laut einem Entwickler sollte die Verwendung von Docker in einem Projekt nur dann aufgenommen werden, wenn das Projekt eine externe Abhängigkeit erfordert. Ich denke, Docker ist Teil unseres Entwicklungsprozesses geworden, weil wir es den Entwicklern aufgezwungen haben oder weil wir es für cool halten. Auch das Problem tritt während der Orchestrierung auf. Müssen sie Orchestrator wie Schwarm, Kubernetes oder Mesos lernen? Die Implementierung all dieser Orchestrierungen ist unterschiedlich. Was ist, wenn die Orchestrierung aufgrund einer schlechten Implementierung abstürzt? Wer ist schuld? PS: Kümmere dich nicht um meine Fragen. Ich spiele nur Devlis Anwalt. Ich liebe auch Docker :)

— Abhay Pai

2

Docker erhält viele Presse- und Blog-Erwähnungen, was dazu führt, dass Entwickler sich dafür interessieren. Für manche Menschen ist es das Interesse, mit einer neuen Technologie zu spielen oder zu verstehen, wie die Dinge funktionieren. Für andere ist es ein Wunsch, Schlüsselwörter zu ihrem Lebenslauf hinzuzufügen. Je mehr Entwickler wissen, wie die Dinge funktionieren und wie sie bereitgestellt werden, desto weniger überrascht werden sie später sein. Nach allem, was ich gesehen habe, besteht bereits ein anständiges Interesse daran, so dass es nicht so schwer sein sollte, es weiter zu fördern.

— Küken
quelle

0

Nun, wenn Sie jemals VMs zum Testen verwendet haben, möchten Sie vielleicht versuchen, Container zu verwenden, und Docker ist tatsächlich ein großartiges Zeug zum Testen und es ist viel einfacher zu verwenden als LXC :)

— YV
quelle

Einverstanden. Ich bin nicht gegen die Verwendung von Docker oder verschiedenen Orchestrierungswerkzeugen. I Liebe sie auch. Was ich zu verstehen versuche, ist einfach. Wem gehört die Containerisierung der Anwendung? Entwickler? Oder DevOps? Oder beides ? Wenn beide, wie viel sollte jeder von ihnen beitragen? Wenn Dinge aufgrund von Docker oder Docker-Orchestrierung fehlschlagen, wer sollte dafür verantwortlich gemacht werden? Code-Effizienz im Vergleich dazu, Entwicklern zu helfen, ihr Leben einfacher zu machen. Meine Frage ist eher auf die Rolle eines Individuums als auf die Technologie selbst gerichtet.

— Abhay Pai