PHP Mehrere PHP-Anwendungen verwalten (Git)?

[BeBur]

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

Das ist sicher ein guter Punkt, falls man mehrere Projekte auf einem Server laufen lässt. Generell hast du mit Docker ja aber eben "zig lokal installierte und konfigurierte Software" in Containern, welche auf einem Server laufen, auf dem wiederum diverse (aber natürlich weniger) Software lokal installiert und konfiguriert ist.

 

[DefconDev]

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.

Ja, ich habe dich falsch zitiert, war keine böse Absicht.
Aber deine Aussage ist immer noch fragwürdig. Zu sagen, du würdest Docker produktiv nicht verwenden aus Sicherheitsgründen, liest sich so als wäre es für alle nicht geeignet.

Zu 1:
Images zu verwenden und die am besten noch mit dem latest Tag zu versehen ist einfach fahrlässig. Das ist aber kein Docker Problem sondern kann dir genau so gut passieren wenn du eine Anwendung mit zig Abhängigkeiten hast. Aber auch Geschichten wie Log4j oder Npm zeigen doch, dass das ein Problem ist, was die ganze Softwareentwicklung betrifft. Also Supply-Chain Attacken sind nichts Docker spezifisches.

Zu 2:
Ist definitiv ein Problem.

Zu 3:
Korrigiere mich aber das Host-System ist doch die Limitierung. Aus meiner beruflichen Erfahrungen kann ich nur sagen, dass Docker nahezu immer auf irgendwelchen Azure- oder Aws Instanzen liefen und die jeweilige VM ganz klar vorgegeben hat wie viel Hardware genutzt werden soll.

Zu 4:
Produktiv habe ich die immer mindestens logisch getrennt gesehen wenn nötig. Und in produktiv hast du Firewallregeln, Bastion Host, DMZ und anderen Schnick-Schnack.

Zu 5:
Keine Ahnung was du unter kurzen Laufzeiten meinst und inwiefern das ein Sicherheitsproblem ist. Aber ich lerne gerne dazu.


Wo ich komplett deiner Meinung bin, ist die Komplexität. Ich bin kein Devops, purer Entwickler und darf gerade mit meinem Team mich in Azure und das ganze Thema einarbeiten. Und es ist gefühlt viel schwieriger als eine simple Linux Maschine zu nehmen und dort zu deployen mit beispielsweise Jenkins.
Das fängt bei uns mit Terraform an, geht weiter mit zig Pipelines unterstützt durch Ansible, Helm Chart, bis hin zu Azure Eigenarten. Dann kommen noch Spielereien wie eigene VM-Images definieren mit Ansible. Oder die Firewall anpassen, damit auch gewisse Requests deiner eigenen Anwendung überhaupt ankommen.
Das alles zu automatisieren ist ein steiniger Weg. Gerade wenn du eine Legacy Webanwendung hast, die ohne das ganze schon nicht leicht zu meistern war.
Meine anfängliche Begeisterung ist absolut dahin.
Und für eine Privatperson ist das vielleicht interessant um was dazuzulernen aber Produktiv für eine Privatperson ohne weitere Expertise nie im Leben.
Also ja, meistens reicht auch einfach ne simple VM.

 

[Falc410]

Wenn du nur ein Projekt hast, dann bist du mit einer simplen VM vermutlich schneller dran.

Aber ich bin hab jetzt meinen Workflow langsam gefunden. Ja es hat viel Zeit gekostet bis alles lief aber dafür passieren jetzt keine Fehler mehr und alles ist viel entspannter - also ich rede nur vom Deployen. Gitlab Versions Tag pushen, dann in Terraform noch was anpassen und deployen, fertig.

zu 3: Ich kann bei AWS bzw. muss! genau die Ressourcen festlegen die ein (1) Container bekommt, also CPU + RAM. Da gibt es Soft- und Hardlimits.

zu 5: Ich habe auch einzelne Container die nur ein Script ausführen und nur wenige Sekunden laufen. Die Loggen trotzdem alles schön in Cloudwatch rein, also da wüsste ich nicht was da das Problem sein sollte

zu 4: Ich hab neulich mal Elastic + Kibana lokal zum testen als Docker deployed. Die Container können NICHT miteinander kommunizieren, ausser man legt vorher ein entsprechendes virtuelles Network an. Also die Container sind erst einmal von einander getrennt.