Einsatz von Docker Container für Subversion Server effizienter als VirtualBox & Co.?

[mjustin]

Hallo,

hat schon jemand einen Subversion Server über Docker Container aufgebaut und kann etwas dazu sagen, ob sich der Aufwand lohnt - gegenüber einem dedizierten Subversions-Server zum Beispiel, der in einer VirtualBox Umgebung aufgesetzt wird?

Wenn man nach Docker Containern für Subversion sucht, findet man viele mehr oder weniger fertig vorkonfigurierte Dockerfiles (mit nur wenigen Zeilen Code Länge, bis hinunter auf zehn Zeilen).

Diese zu installeren und zu konfigurieren ist vermutlich deutlich weniger Aufwand als ein Linux-basiertes System unter VirtualBox manuell aufzusetzen. Oder überschätze ich die Ansprüche, die der Betrieb von Docker Containern an den durchschnittlichen Entwickler stellt?

[Sir Rufo]

Der Vorteil bei so einem Docker-File ist ja, dass du dort festlegen kannst was benötigt wird (Linux-Version, Subversion-Server-Version) und wie es konfiguriert werden soll.

Die Einrichtung auf einem neuen System (Docker ist schon installiert) reduziert sich dann im starten des Containers, kurz warten, loslegen.

[Lemmy]

Zitat:

Zitat von Sir Rufo (Beitrag 1341838)

Der Vorteil bei so einem Docker-File ist ja, dass du dort festlegen kannst was benötigt wird (Linux-Version, Subversion-Server-Version)

Linuxversion? Ich dachte der Container läuft direkt auf dem Hostkernel - sprich keine andere Kernelversion möglich ist (daher leichtgewichtig im Gegensatz zu virtuellen Maschinen)....

[Sir Rufo]

Hier eine Einführung (ja schon älter) http://www.linux-magazin.de/Ausgaben/2014/09/Docker-1.0 aber man beachte den Container

Code:

01 FROM centos:latest
02 MAINTAINER Tux <[e-mail]>
03 RUN yum install -y mysql mysql-server
04 ADD start.sh /start
05 RUN chmod +x /start
06 EXPOSE 3306
07 CMD ["/start"]

Ich kann (muss aber nicht) eine bestimmte Distribution vorgeben

[Valle]

Wie viele Benutzer sollen diesen Subversion Server denn benutzen? o.O

Ich sehe für einen Service wie Subversion keinen Performance-Unterschied zwischen Virtualisierung und Containern. Ich würde an deiner Stelle das nehmen, womit du dich am besten vertraut fühlst. Wenn du Lust auf Container hast, dann probier's aus. Wenn du dich mit VMs wohler fühlst, dann spricht dort nichts dagegen. Wir verwenden Git auf einem virtualisierten Server und ich sehe da absolut keinen Unterschied zwischen VM oder dediziertem Server.

Rein technisch gesehen (weil du nach Effizienz fragst), ist eine Containerlösung natürlich deutlich effizienter als die Emulierung eines kompletten Betriebssystems. Das liegt in der Natur der Technologie. Das spielt für einen einzelnen Subversion Server aber imho überhaupt keine Rolle. Erfahrung ist da der Aspekt der für mich deutlich wichtiger wäre.

[Sherlock]

Zitat:

Zitat von Valle (Beitrag 1341841)

Rein technisch gesehen (weil du nach Effizienz fragst), ist eine Containerlösung natürlich deutlich effizienter als die Emulierung eines kompletten Betriebssystems. Das liegt in der Natur der Technologie.

Welchen Teil des Betriebssystems läßt Docker denn wegfallen? Nur so als Info für mich, damit ich weiß, was ich darin nicht laufen lassen kann.

Sherlock

[sh17]

Docker läuft innerhalb eines Linux-Systems und schottet "nur" Prozesse gegeneinander ab (und alles was dran hängt, Netzwerk, Dateisystem,...), was Linux von Haus aus schon unterstützt. Deswegen kann in einem Container immer nur ein Prozess laufen, z.B. der Web-Server. Brauch man eine DB, benötigt man einen weiteren Container. usw. Das muss man bei der Wahl VM oder Docker ebenfalls beachten.

[hstreicher]

Nicht nur Linux ,Kommt auch in Windows Server 2016

https://www.docker.com/microsoft

https://msdn.microsoft.com/de-de/vir...windows_server

[sh17]

Zitat:

Zitat von hstreicher (Beitrag 1341867)

Nicht nur Linux ,Kommt auch in Windows Server 2016

https://www.docker.com/microsoft

https://msdn.microsoft.com/de-de/vir...windows_server

Das ist richtig, es können aber keine Linux-Container unter Windows laufen und umgekehrt.

[Sir Rufo]

Zitat:

Zitat von sh17 (Beitrag 1341868)

Zitat:

Zitat von hstreicher (Beitrag 1341867)

Nicht nur Linux ,Kommt auch in Windows Server 2016

https://www.docker.com/microsoft

https://msdn.microsoft.com/de-de/vir...windows_server

Das ist richtig, es können aber keine Linux-Container unter Windows laufen und umgekehrt.

Das halte ich eher für ein Gerücht (bezogen auf Docker unter Windows)
siehe http://www.heise.de/developer/meldun...t-3152696.html

[sh17]

"Docker for Windows Server 2016" bitte nicht verwechseln mit "Docker for Windows" oder "Docker Toolbox"

Docker for Windows Server 2016 verwendet spezielle Windows-Container, die auf einem Windows Server Core-Image aufsetzen. Dann kann man dann seine Anwendungen drüber pappen, mit .NET-Schicht z.B.

[Sir Rufo]

@sh17

Die Links zeigten beide Varianten, darum war deine pauschale Aussage nicht richtig :stupid:

[Valle]

Zitat:

Zitat von Sherlock (Beitrag 1341846)

Welchen Teil des Betriebssystems läßt Docker denn wegfallen? Nur so als Info für mich, damit ich weiß, was ich darin nicht laufen lassen kann.

Das ist einfach beantwortet: den Kernel.

Allerdings sind es nicht nur Teile eines Betriebssystems, die wegfallen, sondern auch Emulierung von Hardware. Festplatten und Netzwerkadapter können viel effizienter an den Gast weitergereicht werden. Es muss nicht umständlich eine Hardware emuliert werden um sie anschließend per Treiber wieder anzusprechen. Auch ein BIOS wird nicht benötigt.

Zitat:

Zitat von sh17 (Beitrag 1341851)

Docker läuft innerhalb eines Linux-Systems und schottet "nur" Prozesse gegeneinander ab (und alles was dran hängt, Netzwerk, Dateisystem,...), was Linux von Haus aus schon unterstützt. Deswegen kann in einem Container immer nur ein Prozess laufen, z.B. der Web-Server. Brauch man eine DB, benötigt man einen weiteren Container. usw. Das muss man bei der Wahl VM oder Docker ebenfalls beachten.

Das erste ist richtig. Containerlösungen schotten quasi den Userspace des Kernels ab. Es läuft weiterhin nur ein Kernel, aber alles was auf diesem läuft ist dann quasi einem Container (oder dem Host) zugeordnet. Es kann dann mehrere Prozesse mit einer PID geben. Diese PID ist natürlich nur innerhalb des eigenen Containers aussagekräftig.

Dass nur ein Prozess in einem Container laufen kann stimmt aber nicht. Es können beliebig viele Prozesse laufen. Ein Web- oder Datenbankserver benötigt ja auch mehrere Prozesse um richtig zu funktionieren.

Man könnte allenfalls behaupten, dass die Abschottung in mehrere Container durchaus sinnvoll ist, um eine gewisse Unabhängigkeit zu erreichen. Man hat eventuell bessere Portabilität oder ein einfacher durchzuführende Backups. Das sind aber alles keine notwendigen Gründe für alles einen eigenen Container zu verwenden.

[mjustin]

Vielen Dank für die Antworten bisher! Ich werde mal ein Test-Dockersystem mit einem Subversion Server aufsetzen und den Aufwand für den Weg dorthin mit dem Aufsetzen einer Linux VM vergleichen. Spannend ist unter anderem der Bedarf an Datenträgerplatz gegenüber einer VM Lösung, und ob die Größe der Docker Container / Volumes dynamisch an die Größe des Subversion Repositories angepasst wird.

Unter http://stackoverflow.com/questions/1...ases-in-docker find ich dazu schon einige Hinweise zur Trennung von SVN Server und Daten.