PHP Mehrere PHP-Anwendungen verwalten (Git)?

[Dsimon24]

Hallo zusammen,

es gibt momentan eine Web-Anwendung, programmiert mittels PHP (Laravel).

Diese Anwendung möchte ich mehrfach unabhängig voneinander nutzen
und installiere sie daher auf jeweils einen vServer.

Da die Anwendung stetig weiterentwickelt wird, könnte ich auf jeden
VPS die Anwendung mittels Git auf den aktuellen Stand halten.

Zusätzlich könnte es sein, dass die Anwendung (bspw. 10x auf jeweils einen VPS installiert)
regelmäßig modifiziert werden müsste. Bei Installation 2 und 4 benötige ich noch ein
paar andere Funktionen, bei Anwendung 6 zum Beispiel wieder andere Funktionen, usw...

Wie kann man das (denke mal mit Git / GitHub?) am besten und saubersten realisieren?
Würde mich freuen, wenn mir jemand ein paar Denkanstöße geben könnte. Bin noch
nicht sehr vertraut mit Git.

LG

 

[Falc410]

Docker und Features über Configswitches an- ausschalten? Falls das nicht geht, halt verschiedene Branches. Mit Gitlab CI die Container automatisch bauen lassen. Deployen über Ansible? Sind jetzt alles so ein paar Dinge die du dir mal anschauen kannst.

 

[Joshinator]

Stichwort ist CI/CD, da gibt es zig Dienste die alle ihre eigenen Vor/Nachteile haben.
Github & Gitlab haben sowas von Haus, Jenkins z.B. wäre was externes oder Drone wenn man Selfhosten will.

Die sauberste Methode wäre es wohl deine Laravel App in Docker zu verpacken, und dann die Container auf den VPS automatisch zu deployen wenn Code zu Git gepusht wurde.
CI/CD ist aber nen recht komplexes Thema, eine Robuste CI/CD Pipeline baut man nicht mal eben zusammen, aber auf Dauer rechnet sich sowas.

Quick & Dirty wäre wohl wirklich Git auf den Servern zu installieren und dann z.B. Webhooks von Github & Co nutzen.
Du pusht Code zu Github, Github Webhook ruft eine URL auf wo dein PHP Script die Änderungen per Git-CLI pullt.

 

[madmax2010]

Was @Falc410 sagt ist vermutlich der einfachste weg.
Parametrisier dir alles was du ggf. brauchst oder nicht und deploy via Ansible. Steuer die Parameter wie auch imer es dir beliebt (umgebungsvariablen, config file, unit file, etc....)

Das Know-How dafür solltest du an einem Tag aufbauen können

Cool und komfortabel ist es bspw. Via Gitlab CI, aber da ist der initiale Aufwand deutlich höher

 

[sandreas]

Wie wärs für den Anfang mit nem simplen shell script, git tags und der software rclone? Diese CI Lösungen sind alle toll, aber erstmal musst du ja sowieso ein "script" (Ablaufplan) zusammen stellen, um die Installation zu automatisieren zu können.

Das dann später auf CI umzustellen, ist dann weniger aufwand, aber du bist vermutlich viel schneller am start. Verpass dann nur den Zeitpunkt nicht, es rechtzeitig umzustellen.

Docker würde ICH in der Produktion aus Sicherheitsgründen übrigens nicht nehmen. Aber das ist Geschmackssache.

 

[Falc410]

Docker würde ICH in der Produktion aus Sicherheitsgründen übrigens nicht nehmen. Aber das ist Geschmackssache.

Was spricht dagegen? Wie würdest du sonst eine skalierbare, hochverfügbare Webapp deployen? Ich bin da auch kein Experte, aber dachte, dass Kubernetes + Docker so der Standard sind.

 

[sandreas]

Was spricht dagegen? Wie würdest du sonst eine skalierbare, hochverfügbare Webapp deployen? Ich bin da auch kein Experte, aber dachte, dass Kubernetes + Docker so der Standard sind.

Vorab: Das war meine Meinung - kein Expertenwissen. Ich hab da zu wenig Erfahrung. Aber für mich klingt die Fragestellung (vServer, PHP) nicht danach, als wenn das eine hochverfügbare Webapp á la Facebook wird, sondern als würde man in einer 100 Mann Bude arbeiten und für ein paar Kunden die selbe Software mit ein paar Anpassungen deployen wollen. Und obwohl Facebook auch mit PHP angefangen hat, haben die vermutlich nicht von Anfang an Kubernetes verwendet - ich weiß es aber nicht :-)

Kubernetes und Docker in der Produktion ist meiner Ansicht nach was für erfahrene Leute, die sich mit vielen Themen auskennen müssen. Ich bin ein Freund von early shipping und wenn ich mich das erste Mal ernsthaft mit der Orchestrierung und Administration von Systemen befassen muss, um ne kleine PHP-App auf 10 Server zu schieben (so klingt die Frage), würde ich eben nicht gleich die großen Kanonen für die Spatzen aus dem Keller holen, sondern es erstmal mit der Schleuder auf der Fensterbank versuchen :-)

Docker hat (eventuell hatte) viele Sicherheitsprobleme. Dazu kommt noch der Performance-Verlust durch die Extra-Schicht (vServer + container).

Wenn ich so n System aufsetzen müsste, würde ich mir temporär n Admin holen, der was davon versteht und jemanden abstellen, der sich anguckt, was der macht.

Wenn ich keine Ahnung und unendlich viel Zeit hätte, würde ich vermutlich auch kubernetes anschauen... oder vielleicht firecracker.

 

[Falc410]

Also wir deployen alles nur als Docker Container. Gerade bei PHP Anwendungen ist das super, weil ich auf dem Server nichts installieren brauche (gut ich deploye sowieso auf AWS Fargate). Da spare ich mir Apache, Nginx, PHP Installation & konfiguration - vor Allem bei jedem vServer. So hab ich alles in einem Container und kann auch super einfach PHP Updaten, lokal testen und dann pushen, Gitlab baut automatisch den Container und wird dann in AWS deployt (über Terraform).

Gerade wenn man wenig Manpower hat und Dev(Sec)Ops betreibt, sollte man doch so viel wie möglich automatisieren.

Aber ich gebe dir Recht - egal was man produktiv betreibt, man sollte sich damit auskennen. Sich an einem Tag in eine CI/CD Pipeline einzuarbeiten und die restlichen Themen, halte ich für gewagt

 

[Yuuri]

Vielleicht sollte man erstmal mit nem simplen git Deployment anfangen, statt gleich mit den CI/CD- und Kubernetes-Kanonen auf die Deployment-Spatzen zu schießen. Es ist beim TE ja nicht mal Erfahrung mit git vorhanden. Auf jeden Fall sollte man heutzutage kein FTP Deployment mehr machen. Und insofern er noch nicht mal Container zum Entwickeln nutzt, ist der direkte Nutzen in Production doch etwas fragwürdig.

Docker hat (eventuell hatte) viele Sicherheitsprobleme.

Welche wären? "Sicherheitsprobleme" bezieht sich mit Sicherheit auf den Daemon und wenn man Bedenken hat, kann man das eindämmen. Eine Alternative ist podman, hat aber so hier und da seine Probleme. Prinzipiell sind Container nicht mehr als herkömmliches LXC und das wird direkt vom Kernel gestellt.

Dazu kommt noch der Performance-Verlust durch die Extra-Schicht (vServer + container).

Die Anwendungen laufen direkt auf dem OS. Da gibts keine "Extra-Schicht" o.ä. Container sind keine VM.

 

[BeBur]

Ich hab mein Nebenprojekt (Ruby on Rails) vor einigen Jahren auf Docker umgestellt, zum Teil aus projektspezifischen Gründen, zum Teil aus allgemeinen Gründen, jedenfalls gab es keinen zwingenden Grund.
Mein Fazit ist eher zwiespältig und ich würde es heute vermutlich eher nicht mehr empfehlen. Vorteile gibt es natürlich, aber die Nachteile überwiegen bei Kleinstprojekten, meiner Meinung nach. Man hat die ganze Zeit eine komplette zusätzliche Schichte Komplexität, auch nachdem man sich in die relevanten Technologien eingearbeitet hat. Viele Dinge sind einfach ein stückweit komplizierter, testing, logging, caching, IDE konfig, ... zieht sich überall durch.
Ein Grund warum ich das gemacht hatte war, um Erfahrung mit Docker zu sammeln... Von daher hat es sich ingesamt für mich gelohnt ;-). Ich bin heute aber der Meinung, man sollte mit solchen Technologien reale Probleme lösen, die man in einem Projekt hat und nicht versuchen, die vermeintliche "best practice" von Anfang an ohne zwingenden Grund umsetzen.

Von daher auch +1 zu dem Hinweis, erstmal Deploy skripte bauen und verwenden und darauf aufbauend bei Bedarf dann eine richtige CI/CD pipeline. Das sind aber mMn alles allgemeine Dinge und weniger spezifisch zu der eigentlichen Fragen.

ImHo die größere Frage ist, wie man App-Varianten verwaltet. Verschiedene git branches bieten sich da sehr an, mMn. Interessant fände ich aber vor allem, wie man sowas im Programmcode am besten modular löst, so dass die Varianten nicht zu stark auseinander driften.

 

[Falc410]

Viele Dinge sind einfach ein stückweit komplizierter, testing, logging, caching, IDE konfig, ... zieht sich überall durch.

Gerade das ist für mich einfacher geworden dank Docker. Ich muss lokal keine zig PHP Versionen parallel installieren.

 

[Yuuri]

Man hat die ganze Zeit eine komplette zusätzliche Schichte Komplexität, auch nachdem man sich in die relevanten Technologien eingearbeitet hat.

Diese "zusätzliche" "Schicht" ist deine Runtime.

 

[BeBur]

Gerade das ist für mich einfacher geworden dank Docker. Ich muss lokal keine zig PHP Versionen parallel installieren.

Ja, wie gesagt, wenn Docker konkrete Probleme löst, dann hat das schnell mehr Vorteile. Ich zumindest würde aber heute bei Kleinstprojekten nicht mehr Docker "einfach so" empfehlen, wenn die Person, bzw. das Team keine Erfahrung damit hat. Es hat auch keine besonders großen Kosten (imHo), wenn man nachträglich Docker einführt, wenn man denn auf Probleme stößt, die Docker lösen kann.

Diese "zusätzliche" "Schicht" ist deine Runtime.

Mit dem Satz kann ich so nichts anfangen, kannst du das ausformulieren?

 

[Yuuri]

Mit dem Satz kann ich so nichts anfangen, kannst du das ausformulieren?

TL;DR In Containern lieferst du eben Infrastruktur mit, die du zur Runtime benötigst - eben jenes komplette Runtime Environment. Damit deine App überhaupt irgendwie zum Laufen gebracht werden kann.

Spoiler: TS;WM

• Deine Anwendung nutzt PHP? Dann gibts da ne PHP Binary + ggf. einen HTTP-Server.
• Python Web App? Dann läuft da ebenso Python + ggf. ein HTTP-Server.
• Java Web App? Tomcat, Jetty, Wildfly...
• .NET? Bereits integriert.
• Mehreres davon? Steckt fertig im Container.
• Braucht ne Datenbank? Integrier diese oder stell nen weiteren Container daneben.
• Braucht Redis als Caching? dito
• Benötigt einen AMQP Server? dito
• ELK? dito
• Horizontales Scaling? Einfach nen Parameter hochsetzen.

Deine PHP-Anwendung brauch zwangsweise oder auch nur optional php-gmp? Dann wird das mitgeliefert. Imagemagick? Ist auch bereits mit drin. Deine Anwendung benötigt noch PHP 7.2 (deprecated), ebenso auch mcrypt (ebenso deprecated)? Steckt im Container. Heutzutage hast du ggf. arge Probleme diese Builds selbst zu erstellen. 20 Cronjobs? Wurden bereits eingerichtet.

Weiterer immenser Vorteil von Containern: Immutability. Der Container wird bereitgestellt wie er ist und Änderungen darin werden beim Neustart verworfen (so man nicht Volumes nutzt, und auch die impliziten verwirft). Dass also irgendwer mal Dateien geändert hat und dort bspw. irgendwas überschrieben wird, ist ausgeschlossen.

Irgendwelche Constraints? Die Anwendung soll maximal eine CPU nutzen? Einfach einstellen. Maximal 2 GB RAM nutzen? Einfach einstellen.

Der Vorteil überhaupt imho: Du hast überall die selbe Config laufen, auch bei der Entwicklung. Kein "bei mir lief das noch" mehr. Und ich muss mich nicht mehr um nen lokal laufenden HTTP Server und etwaige VHosts und sonstige Daemons auch in unterschiedlichsten Versionen kümmern. docker-compose up + http://localhost aufrufen und schon läuft das Teil.

In Containern kannst du eben dein "wirklich laufendes" Projekt bereitstellen. Mit ner ZIP stellst du höchstens den Source Code bereit und wälzt die Arbeit für Installation, Absicherung und Wartung für deine Anwendung auf jemand Anderes ab. Bis dein Projekt dann also das erste Mal überhaupt läuft, können dann schon viele viele Monde vergehen. Da kannst du froh sein, wenn es interpretierte Sprachen sind. Wenn du plötzlich für ein Java Projekt einen Build erstellen musst (weil es bspw. keine offiziellen Binaries gibt), bist du ganz schnell aufgeschmissen, wenn du plötzlich NetBeans oder Eclipse als Build Dependency mit dabei hast und es ohne nicht läuft. Nach dem Build kommt aber noch das Deployment mittels Tomcat o.ä., was einem auch nochmal Probleme bereiten kann (wie jede andere Installation natürlich auch, wenn man sich nicht mit dem Projekt und dessen Tools auskennt). Oder bspw. das richtig gute imapsync - offizielle Binaries existieren nicht. Container aber existieren und auch homebrew bietet fertige Binaries dafür an. In den Ubuntu Repos kein einziger Eintrag. Somit kann es der unbedarfte Admin trotzdem nutzen ohne sich mit Build Tools und deren Konfigurationen beschäftigen zu müssen. Vor allem nicht mit Perl. :O

Nettes Beispiel: mailu
Bestehend aus:

• nginx (Router für alle Requests)
• dovecot (IMAP/POP3)
• postfix (SMTP)
• Redis (Caching)
• unbound (DNS Resolver)
• rspamd (Spamfilter)
• clamav (Antivirus)
• radicale (Cal-/CardDAV)
• fetchmail (Import externer Konten)
• MySQL (DB)
• Rainloop/Roundcube (Webmail)
• Web-Admin

Den ganzen Kram auf dem Host zu installieren und mich selbst drum zu kümmern... Ne lass mal. Ich hab auch noch mehr zu tun im Leben als mich um die Administration davon zu scheren. So kümmert sich das mailu Projekt selbst (deutlich besser) drum und ich hab meine gewünschte Funktion (Mailserver). Mein einziger notwendiger Eingriff besteht dabei lediglich aus

• aktuelles Image laden
• Container neu starten

Es ist also der kleine, aber feine (und deutliche) Unterschied zwischen "hier, mach mal" und "läuft".

Aber man muss nicht mal den Weg einer Web App gehen, denn selbst stupide CLI Tools kann man problemfrei via Container deployen. Bspw. hab ich immer und immer wieder Probleme mit den pyenv Shims (keine Ahnung wieso, nutze sie ja quasi nie). Ein Aufruf von youtube-dl endet also gern mal in kryptischen Fehlermeldung von Python. Irgendwann hatte ich die Schnauze voll und seither geht ein Aufruf von youtube-dl nur noch auf docker run --rm -v "$DIR:/media" tnk4on/yt-dlp "$@". Seither gibts keine überflüssigen Fehlermeldungen mehr, weil sich die Installation mal wieder selbst zerstört hat. testssl nutz ich bspw. auch ausschließlich via Docker und auch andere Tools, die ich selten nutze, für die aber Container bereitgestellt werden. Auch ein restic gibts in aktueller Version nicht in den Ubuntu Repos. Wieder einzig Container oder homebrew.

Aber um nochmal zur 0815 Web App zurückzukommen: Das Container Image erstellst du einmalig. In diesem Image sind auch nur die Schritte verewigt, die du auch auf dem Server ausführen würdest (Dockerfiles sind prinzipiell auch nur Shell Scripts), damit deine Anwendung läuft.

FROM httpd:2.4

RUN apt update \
    && apt install -y gmp-dependency1 gmp-dependency2 ... \
    && docker-php-ext-install gmp ... \
    && a2enmod \
        apache-modul1 \
        apache-modul2 \
        ... \
    && a2dismod \
        modul1-brauch-ich-nicht \
        modul2-brauch-ich-nicht \
        ... \
    && sed 's/alte-config/neue-config/g' /etc/apache2/... \
    && ...

COPY . /app

RUN mkdir -p /app/cache /app/tmp /app/... \
    && chmod 0770 /app/cache /app/tmp /app/...

docker build . und schon läuft deine Anwendung prinzipiell. Nur die Sachen installiert, die auch gebraucht werden. Wer keine Container will, kann sich aus dem Dockerfile jeden einzelnen Schritt raussuchen, damit die Anwendung zum Laufen gebracht werden kann. Es dient also gleichzeitig auch zur Dokumentation. Ne richtige Doku sollte man allerdings trotzdem haben, kann dann aber natürlich für einen Build auf das Dockerfile verweisen.

Vorteil: Der ganze Kram wurde gerade weg automatisiert und du musst die Schritte nie wieder manuell und fehlerbehaftet ausführen.

• Neuer Server? docker-compose up
• Noch ein Server? docker-compose up

Auch Serverumzüge sind nun extrem billig. Deployment via rsync o.ä. auf den neuen Server kopieren, dort einloggen, docker-compose up ausführen, schon läuft alles exakt so wie vorher. Wenn man Named Volumes nutzt, wird es etwas schwerer, aber ist quasi auch nicht mehr als ein Kopieren.

• Update der App? docker-compose pull && docker-compose up
• Anwendung soll nicht mehr laufen? docker-compose down
• Anwendung restlos löschen? rm -r deployment-pfad (mit Named Volumes wieder ein Schritt mehr)
• Backups? Deployment Pfad kopieren (Named Volumes s.o.)
• Änderung im HTTP-Server (bspw. Redirects/Rewrites/API/CORS/...) - einmal im Container oder x-mal auf jedem Deployment-Host?

Fehlt ein Use Case? Downgrades sind quasi auch nur durch ersetzen des Image Tags möglich. Aber hier muss die Anwendung natürlich mitspielen. Die Möglichkeit mittels Container Deployment ist definitiv vorhanden.

Kubernetes wer will ist dann auch nicht weit entfernt. Man sollte sich hierbei allerdings nicht die Finger verbrennen, denn viele bilden sich zwar viel ein ("Hochverfügbarkeit" und sowas und dann nen 0815 Blog oder Shop betreiben), allerdings wird der Kosten/Nutzen-Faktor selten ausgeschöpft und hiermit handelt man sich dann wirklich Komplexität ein, vor allem wenn es kein Managed Hosting ist, was dann aber auch sauschnell sauteuer werden kann. Kann bei entsprechender Anforderung natürlich trotzdem seine Vorteile voll ausspielen.

Wurde mal wieder länger als gewollt... :/

 

[DefconDev]

Vorab: Das war meine Meinung - kein Expertenwissen. Ich hab da zu wenig Erfahrung. Aber für mich klingt die Fragestellung (vServer, PHP) nicht danach, als wenn das eine hochverfügbare Webapp á la Facebook wird, sondern als würde man in einer 100 Mann Bude arbeiten und für ein paar Kunden die selbe Software mit ein paar Anpassungen deployen wollen. Und obwohl Facebook auch mit PHP angefangen hat, haben die vermutlich nicht von Anfang an Kubernetes verwendet - ich weiß es aber nicht :-)

Kubernetes und Docker in der Produktion ist meiner Ansicht nach was für erfahrene Leute, die sich mit vielen Themen auskennen müssen. Ich bin ein Freund von early shipping und wenn ich mich das erste Mal ernsthaft mit der Orchestrierung und Administration von Systemen befassen muss, um ne kleine PHP-App auf 10 Server zu schieben (so klingt die Frage), würde ich eben nicht gleich die großen Kanonen für die Spatzen aus dem Keller holen, sondern es erstmal mit der Schleuder auf der Fensterbank versuchen :-)

Docker hat (eventuell hatte) viele Sicherheitsprobleme. Dazu kommt noch der Performance-Verlust durch die Extra-Schicht (vServer + container).

Wenn ich so n System aufsetzen müsste, würde ich mir temporär n Admin holen, der was davon versteht und jemanden abstellen, der sich anguckt, was der macht.

Wenn ich keine Ahnung und unendlich viel Zeit hätte, würde ich vermutlich auch kubernetes anschauen... oder vielleicht firecracker.

Deine Ursprungsaussage war, das du kein Docker für Prod empfiehlst wegen Sicherheitsmängel. Im Anschluss korrigierst du deine Meinung ein wenig, du seist dir nicht sicher. Hätte der User nicht nachgehakt, kommen andere User noch auf die Idee deinem Halbwissen zu glauben.

Vielleicht solltest du das empfehlen womit du auch selber Erfahrungen gesammelt hast.

Zum Thema selber, ohne die Applikation zu kennen aber vielleicht ist es möglich das ganze aufzusplitten als Module. Also die Funktionen der Anwendung x in ein extra Modul packen und je nach Bedarf das ganze durchs Bauen steuern welche Module zum Code gepackt werden.

 

[sandreas]

Deine Ursprungsaussage war, das du kein Docker für Prod empfiehlst wegen Sicherheitsmängel. Im Anschluss korrigierst du deine Meinung ein wenig, du seist dir nicht sicher. Hätte der User nicht nachgehakt, kommen andere User noch auf die Idee deinem Halbwissen zu glauben.

Vielleicht solltest du das empfehlen womit du auch selber Erfahrungen gesammelt hast.

NEIN, das war nicht meine Aussage. Bitte genau lesen:

Docker würde ICH in der Produktion aus Sicherheitsgründen übrigens nicht nehmen.

ICH würde es nicht NEHMEN... und zwar aus Sicherheitsgründen, nicht wegen SicherheitsMÄNGELN.

Bei aller Kritik an meinem Post, die teilweise konstruktiv und richtig ist: Wenn man mich schon "zitiert", dann bitte richtig. Und die Kernaussage bei meinem Post bezieht sich tatsächlich auch auf etwas anderes... ich versuche wenn möglich, dass KISS Prinzip zu anzuwenden. Und wenn man das deployment für den Anfang mit einem simplen Shell-Script machen kann, ist das eine Überlegung wert.

Ich betreibe auch ein Docker-Homelab und fertige für meine Open Source Projekte diverse multiarch images per github actions an (siehe auch die Workflows in https://github.com/sandreas/tone), ein wenig Erfahrung habe ich also - aber eben wenig, deshalb nicht in der Produktion. Docker kann man bestimmt ganz toll und sicher konfigurieren, aber es ist auch sehr einfach, sich als unerfahrener User damit Löcher in sein "Security-Konzept" (so man eins hat) zu bohren, OHNE es zu wissen. Dabei zählen für mich folgende Aspekte zu den von mir angemerkten SicherheitsPROBLEMEN, die ich bei mir feststellen konnte:

1. Aufgrund der Vielzahl an vorhandenen Images (und besonders der auf einander aufbauenden, die man nie direkt sieht) holt man sich gerne mal von anderen gewartete "Pakete" ins Haus, ohne zu wissen, ob das jeweilige Image sicher / sinnvoll konfiguriert wurde (a la "Hauptsache es läuft")
2. Docker läuft standardmäßig mit root-Rechten
3. Oft gibt es KEINE Limitierung für CPU, RAM oder andere Resourcen
4. Container kommunizieren ohne weitere Konfiguration untereinander OHNE Firewall oder sonstige Restriktionen
5. Container können bei kurzen Laufzeiten oft nur schwierig überwacht / geloggt werden

Und das sind nur die, die mir ad hoc einfallen.

Ich hab manchmal das Gefühl, die erfahrenen Experten vergessen, was für ein langer Weg es ist, sich in solche Cloud-Lösungen einzuarbeiten und diese zu warten. Manchmal ist es einfacher, ein simples Linux-System zu nehmen, die Software, die man braucht zu installieren und regelmäßig ein Backup zu machen. Und das ist auch wieder nur meine MEINUNG. Aber ich halte mich damit jetzt auch zurück. Nur das "deine Ursprungsaussage war..." wollte ich so nicht stehen lassen.

 

[BeBur]

TL;DR In Containern lieferst du eben Infrastruktur mit, die du zur Runtime benötigst - eben jenes komplette Runtime Environment. Damit deine App überhaupt irgendwie zum Laufen gebracht werden kann.

Ja. Und damit hast du eine zusätzliche Schicht Komplexität und zu den möglichen Implikationen hatte ich mich in meinem Beitrag geäußert. Ich hatte nach meinem letzten Beitrag realisiert, dass du dich an dem Begriff "Schicht" reibst, aber Docker Container führen nun einmal eine Komplexitätsschicht ein und ich meinte damit etwas anderes als sandreas in seinem Beitrag.

Deine lange Ausführung ist zum Teil natürlich interessant, aber wie du meinen Beiträgen hier entnehmen kannst arbeite ich selber auch mit Docker und die Vorteile sind mir daher durchaus bekannt.

 

[Joshinator]

sich als unerfahrener User damit Löcher in sein "Security-Konzept" (so man eins hat) zu bohren, OHNE es zu wissen

Grade in Verbindung mit UFW kann Docker ein riesiges Loch in die Firewall reißen: https://github.com/chaifeng/ufw-docker
Kurzum, Docker umgeht Regeln in ufw weil direkt mit iptables gearbeitet wird.
Wenn man bescheid weiß, recht schnell gefixt. Die meisten Leute merken das aber erst wenns zu spät ist.

Ne CI/CD mit reproduzierbaren Umgebungen & Tests ist schon cool, aber man sollte Docker nicht mal eben machen. Hat schon seine Gründe warum es extra Devops-Spezialisten gibt die sich mit genau sowas auseinandersetzen.

 

[Falc410]

Und damit hast du eine zusätzliche Schicht Komplexität

Also ich sehe das anders. Ich nehme eben Komplextität raus, gerade weil ich nicht zig lokal installierte und konfigurierte Software benötige.

 

[ayngush]

Kapitel 1:

Fang erst mal an deine Anwendung in Git zu sortieren. Nimm dafür entweder Github oder Gitlab oder Gitea.
Ich persönlich benutze ein self hostet Gitea, das hat jedoch vor allem mit der No-Cloud Strategie in unseren Haus zu tun. Will man eh in die Cloud, würde ich was nehmen, wo die Cloud auch drann kommt, also einen professionellen Github Plan. Die Kostenseite lasse ich auch mal außen vor.

Gitlab hat meiner Meinung nach zu viele CVE... um es ernsthaft einsetzen zu können aber es gibt viele Leute die drauf schwören. Wenn, dann würde ich Gitlab aber auch gar keinen Fall on premises hosten, sondern die Online-Instanzen nutzen / buchen. Das ist aber nur meine Meinung und insbesondere habe ich auch keine Erfahrung mit Gitlab, villeicht ist das ja mega geil.

Für unterschiedliche Features macht man immer alle Kopien der Hauptsoftware für die unterschiedlichen Mandanten vollständig und regelt den Rest (wer kann was) über individuelle Konfigurationen und/oder Zusatzmodule.
Das Branch-Konzept ist eigentlich nicht für verschiedene Feature-Releases gedacht, sondern für verschiedene Entwicklungszuweige, für Kollaboration, für Testing und Prototyping, für Migrationen, für Refactoring und dann immer mit einen Haupt-Branch pro Repository, was dann auch die stabile Version der Software darstellt.
Beschäftigt euch mal alle, die es anders Vorgeschlagen haben, mit Git Tags, mit den jeweiligen Relase-Mechanismen der Git-Softwaren (Github, Gitea, Gitlab), Branching, Merging und mit semantischer Versionierung.
Zur Not setze halt mehrere Repositories auf, wenn die Hauptanwendung zwar immer gleich ist aber einige Mandanten zusätzliche Module bekommen, dann mach für die Zusatzmodule, halt seperate Repositories mit eigener CI/CD für die entsprechenden Mandanten. Aber macht das nicht mit mehreren "Huaptbranches". Das ist dann zwar auch Git - jedoch falsch verstanden und falsch verwendet

Wegen der Wartbarkeit wirst du dir langfristig danken, wenn du in einen Repository einen Main-Branch hast, der auch gleichzeitig dein stabiler Release genau dieser einen Software ist Nichts ist häßlicher als zig Pull Requests mit nicht funktionierenden Automerge ...

Kapitel 2:
Mache dir Gedanken, wie ein Release einer neuen Version bei dir ausschaut. Wie testest du? Was ist bei dir fertige Software? Wie kompliziert ist ein Release auf eure Infrastruktur? Muss man nur die Daten kopieren oder sind damit einhergehend umfangreiche Systemanpassungen notwendig? Was davon kann man automatisieren? Was davon ist individuelle konfiguration? Benutzt du dafür "Dotenv"? Müssen lokale, vorhandenen Datenbanken bei einen Release aktualisiert werden? Wie soll das automatisch geschehen?

Die Antworten daraus leiten dann deine CI-Pipeline ab. Gibt es automatische Unit-Tests, die bestanden werden müssen? Gibt es einen Staging-Server? Wie geht es danach weiter?

Für meine kleine Entwicklungen benutze ich ein selbst gebautes Deployscript, welches über die Gitea Webhooks angesteuert wird und auf den Zielsystem ein git checkout macht, dann eine Kopie davon via rsync in ein "Versionsverzeichnis" anlegt, dann composer aufruft um die Dependencies (die natürlich nicht im Repository lliegen) zu aktualisieren (bei den PHP-Anwendugen, bei Node dann halt entsprchend NPM usw.) und zum Schluss wird ein symlink geändert, der dann das Ganze im Webservice "aktiviert" bzw. eine pm2-Instanz neu hinzugefügt und die alte gestoppt bei Node usw. Man sieht: Es gibt da keine allgemeine Lösung, nur allgemeine Lösungsansätze.

Für größere Projekte wird man um Jenkins / drone.io und am Ende auch Docker / Kubernetes nicht herum kommen. Firmen, die versuchen darum herum zu kommen, weil sie es von früher her noch so kennen verbrennen viel Zeit und damit Geld mit manuellen Testing, manuellen "Releasen" (teils am Wochenende usw.) und so weiter... und können auf Bugs auch nur viel zu langsam reagieren, weil das Releasen halt sehr, sehr aufwendig ist, wenn der gesamte Releaseprozess nicht seamless automated ist...

Kapitel 3:

Macht dir Gedanken, wie das in Zukunft aussehen soll. Docker? Ist auf jeden Fall sinnvoll, wenn man vor hat mit seiner Anwendung zu skalieren und/oder in die Cloud zu gehen. Lege dir heute keine Steine auf einen Weg, den du morgen gehen willst, nur weil der schnelle Erfolg mit wenig Lese- und Lernaufwand gerade sehr verlockend ausschaut.