Docker unter Windows

[7bits]

Können über ein Dockerfile Tools von woanders (z.B. FS) geladen / installiert werden?

 

[Yuuri]

Warum macht man Apps in Container?

Weil es das Deployment bedeutend einfacher und flexibler macht. Bei nem Serverwechsel installier ich Docker, geh ins Verzeichnis und mach ein docker-compose up. Schon läuft die Anwendung wie vorher. Den nginx als Reverse Proxy will ich zukünftig auch noch in nen Container packen. Keine Konfiguration, keine Umgebungsvariablen, keine sonstigen Abhängigkeiten bzw. sind die ja im Container existent und Konfiguration gesetzt bzw. mitgegeben. Will ich auf meinem Notebook was machen - gleiches Szenario - Docker installieren, Container hochfahren, losstarten. Keine fünf Stunden Konfigurationsorgie, wo man hier und da und dort was anpassen muss und dann hat man ja x und y übersehen. Ach und z war ja auch noch... Ich denke du kennst das auch.

1. Isolierte Anwendungen benötigt
2. Container oft in verschiedene Umgebungen verteilen muß

• Servercrash
• unterschiedliche Umgebungen (Production, Staging, ...)
• CI/CD (+ Tests fahren, automatisch deployen, falls Tests fehlschlagen Deploy canceln, ...)
• Unit Tests
• jedes lokale Deployment auf ner Entwicklermaschine
• ...

Bzgl. CI/CD fand ich das Video ganz cool.

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Problem an der Sache bei mir ist leider, dass Gitlab mit Dockers User Namespaces nicht so ganz will. Da bin ich noch nicht ganz dahinter gestiegen. Ist aber mit mein nächstes Angriffsziel, das auch zum Laufen zu bekommen.

Und meine Frage an Dich, warum mußt Du auf einem PC Teamspeak, JDownloader und Co. containeren?

Welcher PC? Ich entwickel lokal und schieb es dann auf meinen Server. Teamspeak ist da, weil man mit Kumpels eben abends auch zockt, JDownloader, weil man auch gern was auf den Server lädt und nicht lokal runterladen und dann auf den Server schieben muss. Alle Web-Interfaces diesbezüglich sind totaler Mist. Und bspw. Youtube lässt sich nur gut mit youtube-dl verarbeiten, allerdings sind die ganzen Web-Interfaces irgendwie alle outdated oder umständlich. Der JDownloader macht da nen besseren Job. Lokal nutz ich dagegen nur die CLI.

Außer mehr Aufwand sehe ich da überhaupt keine Vorteil zu einer normalen Installation. Aus meiner Sicht spart Du Dir hier rein gar nichts, weil es eh Anwendungen sind, die bei Dir laufen.

Ganz im Gegenteil, ich hab bedeutend weniger Arbeit und bedeutend weniger Angriffsfläche. Tools wie PHP, Python, Composer, PiP und Co. benötige ich z.T. nur noch während der Build Phase vom Image, heißt es wird temporär installiert und verfällt dann - übrig bleiben die kompilierten Daten, welche ich als einzige benötige. Ergo keine lokale Abhängigkeit dazu. Auch muss ich nicht mein OS mit externen Paketquellen zumüllen, die dann ggf. ganz andere Effekte hervor bringen und ich mir den Host zerschieße.

Ein Versionsupdate heißt:

• docker-compose down
• docker-compose up

Aktuelles Beispiel: Ich bekomm keine PHP Version außer 7.3 in der WSL 2 unter Ubuntu 20.04 via phpenv-build kompiliert (glaub zlib passte nicht bei 7.4). Versionen < 7.3 bekomm ich natürlich auch nicht zum Laufen, da EOL und die Versionen in den Paketquellen vorn und hinten nicht passen. Aber einige Kunden nutzen den Scheiß natürlich trotzdem noch. Zum Kotzen... Mit Containern läuft es natürlich trotzdem, aber um Composer zu nutzen, will ich nicht erst in den Container wechseln und mir dann ggf. die Rechte versauen.

Flatpacks und Snaps sind auch nichts weiter als lokale Container.

Ich meine, prinzipiell wollen wir das Selbe erreichen: Anwendungen isoliert laufen lassen, sodass weniger Fehlerquellen und Angriffsziele entstehen können. Früher hat man halt aufgrund fehlendem Hypervisors getrennte Maschinen genutzt, mit Hypervisors dann VMs und die nächste Stufe sind halt Container bzw. Flatpacks (die aber auch noch andere Gründe hatten).

Bei mehreren Maschinen hast du das entsprechend bedeutend höhere Ausfallrisiko einer einzelnen Komponente und damit eines ganzen Dienstes. Bei der VM entfällt das Risiko der Hardware, aber du hast den Mehraufwand einer kompletten Distribution (+ dessen Abhängigkeiten). Container andererseits lassen sich beliebig über mehrere Maschinen beliebig skalieren (natürlich nur, wenn die Anwendung entsprechend darauf ausgelegt ist) und sind nicht an ein OS oder dessen Pakete gebunden. Ergo minimierst du du das Problem der Hardware und der kompletten Distribution, hast aber natürlich ggf. ein Problem, wenn ne Anwendung alte, angreifbare Pakete nutzt. Ich denke noch weiter wird es nicht mehr gehen können. Da gäbe es nur noch "Serverless", aber das finde ich dann doch fragwürdig bzw. nur für einzelne Fälle sinnvoll. Hab irgendwo mal von nem "Serverless" Mailserver gelesen... :O Schöne Konzeptstudie, aber imho unbrauchbar.

Können über ein Dockerfile Tools von woanders (z.B. FS) geladen / installiert werden?

Ja, dafür gibts die Build Stage bzw. zur Runtime Volumes. Aber wie gesagt kannst du keine GUI Anwendungen unter Windows per Container nutzen.

 

[PHuV]

Ok, GitLab CI/CD dockern wir auch, und verstehe, Du hast nen Linux Server laufen. Ich dachte, Du machst das ernsthaft unter Windows.
Ja, und das Dockern mit verschiedenen Python-Versionen oder so einen Mist wie Icinga 1 zu dockern ebenso, wo dann beim docker compose interaktiv die Installationsroutinen abfragen stellen.

 

[7bits]

muss denn bei Docker immer alles in Docker ausgeführt werden oder könnte Docker auch als Container für Scripte verwendet werden, die dann von woanders z.b. Conan Dateien laden und außerhalb von Docker speichern und ausführen?