Mit Git auf Webspace arbeiten

[Dsimon24]

Moin zusammen,

ich arbeite mich gerade in Git ein und versuche die Projekte an Stelle von FTP mittels
Git auf den Webspace zu bringen.
Wie macht ihr das denn mit sensiblen Dateien wie bspw. Zugangsdaten zur Datenbank -
speichert ihr diese auch in die Reporitories oder wie geht ihr damit im Zusammenspiel
mit Git um? - Würde die Reps grundsätzlich in GitHub hosten.

VG,

 

[madmax2010]

NIEMALS sensieble daten in daten in ein öffentlich gehostetes git repo legen. Wenn du dein eigenes Gitea/gitlab laufen hast kannst du da deinen gpoass store oder eyaml dateien rein legen, aber da bleiben dann die private keys schön raus
Grundsätzlich kannst du dir ci/cd pipelines bauen, welche die tests / deployment automatisiert ausführen. Ansonten : https://medium.com/@francoisromain/vps-deploy-with-git-fea605f1303b

 

[BeBur]

Nein, secrets werden niemals in ein repo hochgeladen, egal ob public, private oder self hosted.
Du kannst z.B. git secrets oder (low-tech, weniger verlässlich) mit .gitignore die entsprechenden Dateien von git ignorieren lassen.

 

[madmax2010]

Mit "eigenes Gitea/gitlab" meine ich überigens nicht ein provates repo, sondern einen selbst betriebenen, nicht aus dem Interrnet erreichbaren Dienst

 

[Yuuri]

Wie macht ihr das denn mit sensiblen Dateien wie bspw. Zugangsdaten zur Datenbank -
speichert ihr diese auch in die Reporitories oder wie geht ihr damit im Zusammenspiel
mit Git um?

Die werden üblicherweise als Umgebungsvariablen deklariert oder ggf. in eine Config-Datei, welche in der .gitignore steht. Regulär hast du dann eine config.php.dist o.ä., welche nur kopiert und dessen Werte ersetzt werden. So bleiben die Credentials lokal und nicht im Repo.

 

[abcddcba]

Wie macht ihr das denn mit sensiblen Dateien wie bspw. Zugangsdaten zur Datenbank -
speichert ihr diese auch in die Reporitories oder wie geht ihr damit im Zusammenspiel
mit Git um? - Würde die Reps grundsätzlich in GitHub hosten.

Ach komm, das kannst du doch nicht wirklich ernst meinen, oder?

Ansonsten, wie schon erwähnt, gängige Paraxis ist config und Settings mit einer Template Datei wie setting.ini.dist die man dann kopiert und anpasst

Falls du aber doch mal auf die absurde Idee kamst und es getan hast: https://help.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository

 

[ayngush]

Also ich habe sowohl privat als auch beruflich jeweils einen Gitea-Server laufen.
Das Deployment für Webgeschichten habe ich über ein Webhook bei einen neuen Release, den man in Gitea konfigurieren kann, vorgenommen.
Dieser Hook spricht ein Skript auf dem oder den Zielservern an und dort wiederrum wird dann ein git clone bzw. git reset und git pull und git checkout vorgenommen - das Reposiroty wird dann mittels rsync lokal in ein versioniertes (über die git tags) Verzeichnis kopiert und dabei das .git Verzeichnis verworfen, damit es nicht aus versehen im Webroot landet und abschließend wird dann ein Symlink auf dieses "neue" Webroot durchgeführt und damit die Webanwendung sozusagen "umgeschaltet".

Das ganze ist ein selbst gebautes Skript welches ohne Testpipeline oder so einfach nur ein simples Deployment vornimmt.

Irgendwelche Konfigurationsdateien sind auf den jeweiligen Servern außerhalb des Webroots welches über git synchronisiert wird, abgelegt und in den Anwendungen entsprechend referenziert - im git selbst darf man niemals irgendwelche Zugangsdaten ablegen. Und man darf auch nicht das .git-Verzeichnis im Web zugänglich machen, da drinnen sind nämlich Kopien des Quellcodes der Webanwendung einsehbar...

 

[Tumbleweed]

Ich will dem Gesagten gar nicht wieder sprechen, würde aber noch hinzufügen, dass es mit ansible-vault (wenn man ansible nicht nutzt, nicht so sinnvoll) und git-crypt Möglichkeiten gibt, secrets im Repo zu versenken. Ich würde aus Prinzip trotzdem immer dafür sorgen, dass so wenig Leute wie möglich Zugriff auf das Repo haben. Sollte der verwendete Algorithmus irgendwann mal geknackt werden, sind diese secrets als kompromittiert anzusehen und müssen geändert (nicht nur neu verschlüsselt, Historie bedenken) werden.

 

[Drexel]

Ich habe in einem Projekt meine Config Datei von Passwörtern gesaübert, die Datei committed, damit sie im Repo ist und dann

git update-index --assume-unchanged

Sollte sich nochmal was an der Datei ändern, was eingecheckt werden soll, muss man das wieder rückgängig machen.