Einstieg in die Welt der Container?

Sinnvolle Literatur und ein Raspberry Pi reichen zum Verstehen:
https://www.heise.de/newsticker/meldung/Jetzt-erhaeltlich-c-t-wissen-Doc ...

Wie Kollege @wiesi200 schon richtig gesagt hat. Linux VM mit Nginx oder Apachen und fertisch iss. Gibts alles schon als fertige Container.

Hallo, Grundlagen Container z.B.: https://jaxenter.de/einfuehrung-docker-tutorial-container-61528
...

vG
LS

Wenn Du einen Hyper-V Server als Host hast, laufen darauf VMs. In einer VM installierst Du den Docker-Container-Dienst und der wiederum kann Anwendungen als Container laufen lassen. Das ist keine VM in der VM. Wird auch hier ganz gut erklärt: https://docs.microsoft.com/de-de/virtualization/windowscontainers/deploy ...
Wenn Du nach "Server 2019 Docker" suchst, findest Du viel Infos ...
Ebenso kannst Du eine Linux-VM istallieren und darin den Docker-Dienst installieren und dann Container ....

Du wirst sinnvoller Weise unten drunter ein Linux haben wollen. Alleine schon, weil Du Dich sonst bei den Docker-Containern einschränkst.

Dieses Linux kann auf Blech oder HyperV laufen. Wobei es ziemlich easy ist ein Linux in HyperV zu konfigurieren ... Ubuntu LTS ist doch als Install-Option in HyperV vorkonfiguriert?! D.h. einen Knopf drücken und schon läuft das. Anschließend google „Docker auf Ubuntu“ und dann das Manual zum speziellen Container. Das habe sogar ich Newbie schon hinbekommen - ist also lösbar 😉

und hier noch ein Link, mit dessen Hilfe es nun klappen sollte: https://decatec.de/home-server/docker-auf-ubuntu-server/
viel Erfolg!
LS

Moin,

falls ihr im Unternehmen keine Pinguine verwalten könnt/wollt, ist der Server 2019 eine super-Plattform, um auch Linux-Container zu hosten (docker). Für 2019 ist die Docker Enterprise Edition kostenlos und im Zusammenspiel mit WSL2 auch ordentlich performant. Sogar der Mischbetrieb von Win- und Linux-Containern ist möglich. Der aktivierte Modus (Win oder Linux) schränkt lediglich die Art der Images ein, welche gestartet werden können; laufende Container werden nicht abgerissen ^^

MS hat für die Installation entsprechende Anleitungen ins Netz gestellt.

Moin,

hab' Mist erzählt; das HowTo kommt von docker selbst: unter (klick me) ist die Installation von docker EE beschrieben; vorher sollten die Rollen/Features "Hyper-V", "Container" und "Windows Subsystem for Linux" auf der Kiste installiert sein.
Wenn Du bei der Build-Version nicht konservativ sein musst, würde ich Eine nehmen, die bereits WSL2 unterstützt.

[edited]
P.S. Für die ersten Gehversuche kann ich "Kitematic" empfehlen; kann nicht viel, aber für Schritt 1 von n reicht's ;)

Als jemand der Docker seit ~2015 und Kubernetes seit ~2018 in verschiedenen Umgebungen betreut hole ich mal etwas aus, damit du das ganze grundlegend verstehst: Docker nutzt Linux-Technologie. Die ist seit weit über 10 Jahren Bestandteil des Kernels und dementsprechend ausgereift. Und weil das zum Kernel gehört gibt es in dem Sinne auch kein echtes Docker für Windows. Das ist einfach nur der eingeschränktere und weniger elegante Weg zu dem was hier schon vorgeschlagen wurde: Eine Linux VM. So lange Windows nicht zum Linux-Kernel wechselt, wird das wohl auch so bleiben.

Als das ganze durch Docker damals stark an Verbreitung gewann, kopierte Microsoft das ganze: Windows Container waren geboren. Im Prinzip ähnlich wie die Linux-Container, aber auf Windows beschränkt. Dementsprechend konnte sich das ganze bis heute nicht wirklich durchsetzen. Es gibt wenig Anwendungsfälle wo das Sinn macht. Wer in .NET entwickelt und auf Windows angewiesen ist, hat eine leichtgewichtige Alternative zu VMs. Aber eben eher eine Nische: .NET Core selbst ist ja seit Jahren plattformunabhängig. Wer nicht gerade spezielle Anforderungen hat, braucht kein Windows mehr. Vieles wird ja auch auf anderen, offenen Plattformen (z.B. NodeJS, Python, PHP etc) entwickelt - alles OS Technologien, die eher Linux als Windows nahe stehen.

Damit sind wir bei deinem Thema: Es macht wenig Sinn, das auf Windows betreiben zu wollen. Das gibt einen Krampf und du zahlst noch einen haufen Lizenzgebühren. Nimm lieber eine der großen Distris (Ubuntu, Debian, CentOS, ...). Wenn du unbedingt für Support bezahlen willst geht das ja bei den meisten auch (RHEL, Ubuntu Abo etc). Die große Mehrheit der Container nutzt die offenen Linux-Container. Für PHP gibt es da auch offizielle Images: https://hub.docker.com/_/php Und man erhält deutlich mehr Support auf Stackoverflow oder anderen Foren.

Habe ich selbst seit Jahren auf einem Ubuntu-Host im Einsatz. Für schnell und einfach empfehle ich das Standard-PHP Modul mit Apache. Ist weniger komplex und euch reicht ein Container für den Applikationsserver (ggf. noch DB mit dazu, je nachdem was die alles braucht). Für den Anfang gut geeignet, wenn es um Performance geht lieber NGINX mit PHP-FPM. Falls Apache aus funktionellen Gründen benötigt wird, läuft auch Nginx für statische Inhalte und der Apache als Reverse-Proxy für PHP nicht schlecht.

Die Container verwaltest du dann ganz normal auf der Konsole: docker ps listet dir z.B. alle aufenden Container auf. Ich würde aber von langen docker run Befehlen abraten. Lieber gleich Docker-Compose nutzen. Vereinfacht das Handling und du kannst gut Abhängigkeiten abbilden, die man heutzutage bei so ziemlich jeder Webanwendung hat: Anwendungsserver muss auf die DB, hängt vllt noch einem Redis oder was vergleichbarem ab etc. Bleibt auch bei mehreren Containern übersichtlicher.

Wenn es noch größer wird wäre über Kubernetes nachzudenken. So wie ich das interpretiere ist das wohl aber aktuell noch definitiv overkill. Klar kann man das auch für was kleineres nehmen. Ich würde aber davon abraten, alles mit Kubernetes erschlagen zu wollen. Vor allem wenn ihr noch am Anfang seid. Für was größeres ist das toll, ansonsten bringt es eher mehr Komplexität.

Entwickeln würde ich btw auch auf Linux. Ist bei uns seit einiger Zeit ein Diskussionthema. Die Entwickler wollen das alle, weils unter Windows ein Krampf ist. Aber die Zuständigen sind von der "Ich hab schon Windows administriert als ihr noch in die Windeln geschissen habt" Sorte. Dell bietet da z.B. Laptops als Developer Edition an, mit Ubuntu, alles offiziell unterstützt, mit Support etc. Bei uns Admins stehen so lange zwei ausgemusterte i7 Rechner unterm Tisch mit Linux im Installationsnetz. Für das Alter laufen die erstaunlich gut. Da fehlt aber natürlich auch der ganze Overhead, der bei uns per Softwareverteilung überall zwangsinstalliert wird.

Moin,

docker for Windows virtualisierten per Hyper-V einen stark angepasstes mini-linux, auf dem dann docker läuft. Dasselbe Prinzip wie bei Deiner Virtualisierungslösung, nur dass nicht ein ganzer Rechner inkl. Hardware+BIOS/UEFI virtualisiert wird, sondern nur der OS-Kernel. Ich stimme Dir zu, dass Linux zum Betrieb als Plattform die beste Lösung ist - wenn Linux als Host ausfällt (AD, SSO, Azure connect, Anwendungen f. Win-Clients), ist Dein Vorschlag aber wesentlich inperformanter als "Docker for Windows". Insbesondere im Zusammenspiel mit WSL2. Falls bei Dir Interesse zu dessen (Linux/docker) Implementierung unter Windows besteht, kann ich Dir diesen Podcast empfehlen.

Es ist kein Problem, Linux-Images unter Windows zu starten - machen wir hier seit knapp einem Jahr unter Einsatz von Kubernetes und sehen keine großen Performance-Einbußen dabei und ist afaik die einzige Möglichkeit, containerisierte SSO-Lösungen per AD/Win auth anzubieten (hab leider noch keine Lösung gefunden, nginx, samba oder einen anderen Pinguin-Webserver dazu zu bewegen, WinAuth anzubieten - Kerberos & Co. sind aber auch bömische Dörfer für mich und bin für Tipps dankbar).
Ich persönlich bevorzuge ebenfalls einen Linux-Host, falls mgl., aber da spielen die Anforderungen an die Plattform oder Anwendung halt auch eine Rolle.

Zum Thema Entwickeln unter Linux: die berühmte out-of-the-box "F5-expereance" ist imho nach wie vor ungeschlagen und sorgt bei Vorführungen immer noch für jaw-drops; das bootstrapping + toolchain einrichten + Debugging und breakpoints an beliebiger Stelle beschränkt sich auf die Auswahl der passenden Projektvorlage und wem das zu unflexibel ist, wird immernoch die Möglichkeit der manuellen Anpassung/Konfiguration geboten; hat sich einiges massiv bei M$ geändert, seit Nadella der Captain ist.

Falls ich hier wie ein fanboy klinge: die Plattform ist mir piepegal, meine Hauptkiste läuft unter Linux, konnte mir seit der Uni nix anderes Vorstellen und wurde vom AG Anfang der 2000er gezwungendermaßen zur Win-Entwicklung getrieben.
Ist auf jeder Plattform dasselbe; kennt man sie nicht en détail, verhält sie sich halt nicht so, wie man's gerne hätte.
...Nur Vorurteile finde ich halt albern; es gibt kein "besseres" System, nur solche, die zu Anforderungen passen oder nicht bzw. diese leichter realisierbar machen. Und dertowa hat die Randbedingungen klar vorgegeben. Diese über den Haufen zu werfen, weil man eine Plattform favorisiert ist unprofessionell.

Hallo ToWa,

Deine Bedenken sind absolut nachvollziehbar.
Der Softwareentwickler ist ein Dienstleister. Normalerweise bekommt der ein Lastenheft und liefert eine Lösung, die ihr dann gut oder schlecht findet.
Scheinbar eine Webanwendung à la (W)AMP
Wenn ihr nun keine Container wollt, wegen des zusätzlichen Aufwandes, dann würde ich dem Entwickler sagen, dass ich das so nicht will. Und er muss mir einen Vorschlag bringen, der in meine Landschaft passt.
Wäre doch auch eine Option?
Ausserdem, er würde gern, na ja, ich würde auch gern vieles ..., aber ihr bezahlt doch...

vG
LS

klingt doch gut die Einigung. Die VM kannst du dann auch komplett sichern und auch in einer Testumgebung testen.
viel Erfolg
LS

Dann wäre doch jetzt ein guter Moment, damit anzufangen. Container werden zunehmend zum Standard für Entwicklung und Softwareverteilung, was ja auch Sinn macht. Eine VM ist wesentlich schwerfälliger und ressourcenfressender. Wer mit dem Thema noch gar nichts gemacht hat und in einem Bereich arbeitet, in dem das irgendwie halbwegs Sinn macht, würde ich empfehlen, mich damit auseinanderzusetzen. Unabhängig von deinem Ursprungsthema.


Für mich klingt das nach einer normalen agilen Testumgebung. Häufiges Deployen ist da nicht nur normal, sondern ausdrücklich gewünscht. Wenn er so einen Wunsch äußert, vermute ich mal, dass er gerne automatisiertes Deployment (CI/CD) hätte, aber das in der jetzigen Lösung nicht kann oder darf. Dafür bietet sich Docker durchaus an (gerade für Testumgebungen). Geht aber natürlich auch ohne. Vor allem wenn man die Maschinen automatisiert hochzieht, kommt man auf ein ähnliches Ergebnis, nur halt mit mehr Overhead.


Naja also wild irgendwelche Entwicklungsstände einfach so aufs Produktivsystem zu deployen, macht man auch in der modernen Softwareentwicklung nicht, im Gegenteil ;) Normal hat man mindestens 2 Umgebungen (Test/Prod), bei kritischen Sachen auch bis zu 4 für Staging/Quality.

Klassischerweise geht man oft den Mittelweg aus 3 Systemen: Ich schreibe Code, der landet automatisch auf einem Dev-System (1). Wenn der als stabil angesehen wird, kommt er auf ein Quality-System (2). Das sollte ein möglichst identisches Spiegelsystem vom produktiven sein. Am besten auch mit realistischen Daten. Da hat man (je nach Umfang/Projekt) auch gerne mal Testser drauf. Im Scrum-Umfeld z.B. würde da auch der Product Owner abnehmen.

Normalerweise sollten zwischendrin auch noch automatisierte Tests durchgelaufen sein, um konsistente Qualität gewährleisten zu können. Machen leider viele nicht, ist für eine (konsistente!) Softwarequalität aber wichtig. Das nur mal so am Rande.
Wenn meine ganzen Tests grün sind, ich mit der Funktion zufrieden bin, auf dem Staging-System alles gut läuft und im besten falle der PO das sogar abgenommen hat, gibts einen Merge Request. Ob ich bis hierhin einen dev- oder Feature Branch genutzt habe ist sekundär, kann man so oder so machen. Aber direkt im Master hab ich als Entwickler nix verloren. Bei dem Merge Request gilt normal das 4-Augen Prinzip: Ich mache den Request auf und ein zweiter guckt drüber. Das kann ein Kollege sein, der Chef, Gruppenleiter oder wer auch immer. Wichtig wäre, dass die Person den Code zumindest lesen kann. Wenn die Person ihr Okay gibt, kann deployt werden (ggf. auch Nightly wegen Downtimes).

Wie du siehst ist da recht viel Spielraum. Das kommt auf viele Faktoren an, wie Teamgröße, Projekt, Relvanz, Strukturen etc. Und wie schon oben gesagt gehts dabei in erster Linie um Prozesse. Docker kann eine konsistente und schnelle Umsetzung erleichtern. Aber letztendlich kann man das mit entsprechenden Einschränkungen auch mit klassischen VMs umsetzen.


Container kannst du genau so troubleshooten. Sogar teils besser, weil es manchmal einfacher ist, einen kaputten Container neu zu bauen statt sich den Kopf mit Reparieren zu zerbrechen (geht bei einer VM nur bedingt so einfach). Aber ich sag mal so: Wenn ihr Container einsetzt, musst du als Admin darin fit sein. Damit du im Fehlerfall deinen Job machen kannst. Deinen Entwicklern irgendwas hinstellen wofür du verantwortlich bist, wird nicht funktionieren.

Letztendlich müsst ihr euch darauf einigen, wer was macht UND wer auch für welchen Part Verantwortung trägt. Prinzipiell gibts 3 Möglichkeiten:

1. Ihr setzt Docker ein und du administrierst das wie gehabt. Dafür musst du das ganze verstehen und zumindest adminseitig damit sicher umgehen können (Container Starten/Stoppen, Logs lesen, mit Compose umgehen, wissen wie die deployen etc)
2. Ihr verlagert das mehr hin zu den Entwicklern, sodass die für weitere Teile der Administration verantwortlich sind
3. Jemand macht "DevOps" und ist dazwischen angesiedelt: Der kennt beide Seiten, du machst dann eher Server/OS Support, alles andere macht entweder er oder klärts mit den Devs

Auf Variante #3 ists bei mir raus gelaufen: Ich hab schon vor der Ausbildung viel entwickelt, aber fand isoliertes Entwickeln genau wie isoliertes Administrieren auf Dauer zu langweilig und hab mich auch mit der Infrastruktur drum herum beschäftigt. In meiner Ausbildungszeit eskalierte das Docker-Problem in meinem Ausbildungsbetrieb. Die Entwickler wollten davor schon Docker machen, aber die Admins hatten keine Ahnung davon und wollten auch nicht weg von ihren VMs (damals haben auch noch viele Win Only gemacht, es gab nur 2 Linux Admins).

Jedenfalls hat das ganze natürlich zu Chaos geführt, weil zig Entwickler wild dran rumgebastelt haben. Gegen Ende hin hat man mich auch mal als Azubi z.B. aus dem Lager ans Telefon geholt, weil jemand den Docker Server abgeschossen hatte und keiner wusste wie man das wieder repariert. Seit dem betreue ich das, mittlerweile mit einem 2. Kollegen weil es alleine unmöglich ist, die letzten ~15 Jahre verschlafene Automatisierung und Standartisierung mal eben nachzuholen.

Wir sind bis heute nicht fertig (wenn man das denn jemals ist?) aber mittlerweile auf einem guten Weg: Es ist geordneter geworden und gibt weniger Konflikte. Das ist jetzt eine lange Geschichte, aber was ich dir damit aufzeigen will: Der wo das betreut muss zumindest die Technologie verstehen. Am besten noch bisschen Entwicklererfahrung haben. Das hilft mir ungemein Themen zu verstehen, bei denen unsere klassischen Server-Admins mit den Schultern zucken und eher abblocken, weil sie weder mit Containern noch mit Entwicklung was zutun haben und das eigentlich auch gar nicht wollen.



Das halte ich für unwahrscheinlich, weil Docker ja genau das verhindern soll: Ich entwickle irgendwas, packe das in ein Image. Das läuft auf meinem Linux Server genau wie beim Kollegen auf dem Linux-Laptop. Selbst ein Mac-User muss lediglich Docker installieren und auch dort läuft meine Anwendung in der von mir definierten Umgebung. Das ist einer der Hauptgründe für Docker. Mit einer VM bekomme ich das zwar auch hin, aber selbst mit Linux ist das Teil mehrere GB groß. Updates wenn der andere da Daten drin liegen hat? Aua... Mit Docker Volumes? Kein Stress.

Container sind eine fundamentale Technologie, vergleichbar wie damals der Wechsel von Bare Metal hin zu VMs. Und ich sage bewusst Container, nicht Docker. Gut möglich, dass Docker verschwindet. Aber die Container-Specs bleiben. Dann wird halt Podman als Runtime genutzt. Merkt der User nicht mal, weil standartisiert. Daher kann man bereits im jetzigen frühen Stadium Podman benutzen und ein Alias auf Docker setzen.

Ich würde Container daher nicht mit irgend einem Hype-Buzzword gleichsetzen, das in wenigen Jahren keine Relevanz mehr hat.


Verständlich. Warum baut ihr dann nich erst mal eine Testumgebung auf? Da kannst du auch Erfahrung sammeln. Produktiv würde ich erst gehen, wenn es mindestens eine Person bei euch gibt, die mit der Technik sicher umgehen kann.


Naja es geht im Grunde auch nicht. Der Windows Kernel kann das nicht und das wird sich so schnell auch nicht ändern. Dein Docker für Windows startet im Hintergrund einfach nur eine Linux-VM. Die siehst du halt nur nicht, weil ein Wrapper dazwischen steckt der das ganze abstrahiert. Man hat also Docker für Win, der das Linux-Docker abstrahiert, was wiederum über libcontainer auf die Linux Kernelfunktionen zugreift.

Wenn das in einer VM läuft, wirds noch lustiger: Dann habe ich eine VM in einer 2. VM geschachtelt. Selbst wenn ich hardcore Windows Fan wäre, würde ich mir doch überlegen, ob ich so ein Konstrukt wirklich einsetzen will - noch dazu produktiv und für was kritisches... Nicht nur dass die Performance flöten geht, das Nesting evtl Probleme macht. Das ganze wird halt einfach komplexer ohne Mehrwert. Im Gegenteil, einziger Mehrwert ist ein proprietäres OS über ein freies gestülpt. Klingt noch grauenvoller als Docker in Docker, was ich auch schon keinem empfehlen würde.

Im Bezug auf Docker bringt dir das auch keinen Mehrwert. Auch du wirst z.B. docker run --rm hello-world ausführen, genau wie ich auf meinem Linux und ein anderer auf dem Mac. Einziger Unterschied ist, dass du halt ein Win patchst (oder patchen lässt). Mehr wird auf dem Server dann sowieso nicht laufen, weil die Applikationen ja alle auf Docker sind.

Macht grundsätzlich Sinn, an Infrastructure as Code bin ich auch dran mit einer HCL Connections Umgebung. Bin mittlerweile so weit, dass ein grundlegendes System nach 1,5h zuschauen steht (davor: Consultant mit 10 Jahren Erfahrung braucht mindestens 1 Arbeitstag, ich am Anfang fürs Grundsystem ~1,5). Und zwar immer exakt gleich nach Doku konfiguriert. Aktuell für Testumgebungen, aber mein Plan ist, damit z.B. bei einem Update eine Testinstanz hochzufahren, auf Knopfdruck alle Anpassungen draufzuspielen und wenn alles passt das gleiche mit Prod zu machen. Noch cooler wird das mit Kubernetes Clustern, das hab ich mit KVM mal POC mäßig gemacht.

Ob das für euch Sinn macht, kommt auf die Umgebung drauf an. Für eine einzelne PHP-Anwendung wäre das in meinen Augen etwas oversized, auch wenn ich den Ansatz gut finde.


Wie gesagt nur über die Virtualisierung. Über eine reguläre VM (also in VirtualBox, Hyper-V, Vagrant oder was auch immer selbst installiert) ging das schon immer. Ich würde nicht sagen, dass Windows das kann, nur weil eine Black Box VM irgendwo im Hintergrund läuft. Wenn ich unter Linux eine Win VM installiere läuft auch MS Office. Ob das rechtfertigt zu sagen, Office läuft auf Linux? Naja.... Aber das ist Definitionssache, was man darunter versteht. Je nachdem wie er und du es meinen habt ihr evtl. beide recht.


Verstehe ich nicht wieso er Bare Metal will? So lange eure Hardware das packt ist für ihn doch egal, ob du ihm eine VM oder einen kompletten Bare Metal Server bereitstellst. Der einzige Grund den ich mir vorstellen könnte ist, dass er dort mit Terraform oder was vergleichbarem automatisch VMs erstellen will (wie zu Beginn schon angesprochen).


Das klingt nach einem guten Deal für ihn, aber nach einem weniger guten für dich. Wie oft wird das denn deployt und was musst du da alles anpassen? Wenn die Antwort darauf nicht "überraschend wenig" lautet, würde ich mir über ein zeitgemäßes Deployment Gedanken machen.

Selbst wenn es für den Anfang nur was halblebiges wird wie z.B. er stellt ein Ansible für die Pakete (Webserver, PHP etc) bereit und um den aktuellen Quellcode vom Git Server zu holen, was du dann ausführst. Wenn es mehr wird, würde ich da einen Jenkins, Gitlab oder so was hinstellen. Wenn dir das zu viel Rechte in den Händen des Entwicklers ist, kannst du ja dann in den Master-Branch das Review durchführen. So lange du da nicht mergen klickst, landet nix im Produktivsystem. Man kann da bei Bedarf auch weitere Schutzmaßnahmen treffen und z.B. direktes Pushen in den Master-Branch verbieten.

Keine Schleife, da ein Container keine VM ist, sondern nur Virtualisierungsfunktionen nutzt.
Auf einem Hyper-V Host (Blech), Knoten sollte KEINE andere Software zusätzlich laufen ... - wie du schon erkannt hast.
vG
LS