Stellen Sie den Code direkt im Docker-Container bereit. Oder wie man nicht nach jedem Commit zögert

Die Aufgabe kam WEB-12982
Erstellen Sie einen Web-12982-Zweig im Repository
Während die Filiale läuft, lesen Sie tz und trinken Sie Kaffee
Fahren Sie direkt mit der Entwicklung fort

Git Commit, Git Push
Während der Zweig wieder zusammengebaut wird
Git Commit, Git Push
Während der Zweig wieder aufgebaut wird, wird Twitter umgedreht
Git Commit, Git Push
...
Sie übergeben einen Bewertungszweig mit 50 Commits

Sie verstehen, dass 50 Commits genau 50 Minuten reine Zeit sind, die in Anfällen und Starts gesammelt werden, da 1-Minuten-Intervalle zu klein sind, um etwas anderes als Aufschub und Grundbedürfnisse zu tun.

Ist die Situation bekannt? In meinem Unternehmen ist die Entwicklungsinfrastruktur wie folgt organisiert:

• Hitlab verfügt über viele Projekt-Repositories
• Um die Entwicklung beim Erstellen eines neuen Zweigs zu vereinfachen, erstellen Docker automatisch ihre eigene Sandbox an einer eindeutigen Adresse, einer vollständigen Kopie des übergeordneten Zweigs mit der erforderlichen Umgebung.
• Alles, was Sie brauchen, ist fertig - schreiben Sie einfach den Code und testen Sie das Ergebnis nach jedem Commit. Es ist sehr praktisch!

Aber langsam ... Wenn diese Situation in Ihrer Nähe ist, begrüßen Sie unter Katze.

• Das Wesentliche des Problems
• Lösungsoptionen
• Lösungsimplementierung

Das Wesentliche des Problems

tldr: Änderungen am Code erfordern das Zusammensetzen der Container und den Zeitaufwand (mehr als eine Minute, dies hängt vom Projekt ab, insbesondere wenn CI \ CD konfiguriert ist), was zwar nicht sinnvoll ausgegeben werden kann, aber die Arbeitszeit des Programmierers erheblich beeinträchtigt .

Ich habe zuvor einen Artikel zu einem verwandten Thema veröffentlicht , der sich jedoch auf den Debugging-Prozess bezieht (übrigens danke für die informativen Kommentare und das positive Feedback). Das Problem mit dem Schnitt ist jedoch im Wesentlichen nicht verschwunden. Wir warten auch weiterhin, bis der Zweig wieder zusammengesetzt ist.

Selbst wenn Sie die zusätzlichen Phasen überspringen und nur Build-Dev und Deployment-Dev belassen, ist die Wartezeit für nützliche Aktionen unerheblich, jedoch erheblich für die Gesamtzeit, die insbesondere für CI \ CD von Gitlab aufgewendet wird.

Natürlich können Sie den Prozess beschleunigen, indem Sie das Projekt lokal zusammenstellen, vorausgesetzt, der Programmierer verfügt über einen relativ leistungsstarken Computer, Gitlab-Runner ist konfiguriert, dieselbe Umgebung ist wie auf dem Remote-Server konfiguriert und die entsprechenden Tags werden zu gitlab-ci.yml hinzugefügt, aber ich bezweifle Die Erstellungsgeschwindigkeit entspricht der automatischen Bereitstellung des FTP-Codes nach den Tasten Strg + s.

Besonders Verbrennungen machen wütend Es ist anstrengend, wenn Sie während des Entwicklungsprozesses Tippfehler / Fehler machen, die sich im Allgemeinen nicht auf den Betrieb der Anwendung auswirken, aber nicht einfach so belassen werden können, und die Sie erst bemerken, wenn Sie das Ergebnis nach dem Zusammenbau betrachten.

Was ist erforderlich und Lösungsoptionen

tldr: Finden Sie einen Weg, um das Ergebnis Ihrer Änderungen so einfach und schnell wie möglich zu sehen. Um nicht jedes Mal ein Commit durchzuführen und nicht auf den Wiederaufbau des Zweigs zu warten. Ich habe rsync vom lokalen Computer in den Remote-Server-Ordner ausgewählt, der mit dem Container-Ordner bereitgestellt wurde.

Ich habe im Internet keine vollständige Lösung gefunden, aber tatsächlich gibt es mehrere Möglichkeiten:

• Konfigurieren Sie ftp \ ssh direkt im Container mit der Codebasis, fügen Sie es in das Image ein und stellen Sie über FTP eine direkte Verbindung zum Container selbst her
  
  • Persönlich erschien mir diese Option etwas kompliziert und zu „krückenhaft“, obwohl hier alle Optionen Krücken sind
• (für den lokalen Gebrauch) Verwenden Sie Docker CP , um Code direkt in den Container zu laden
  
  • Die Option ist nicht für die Arbeit mit einem Remote-Server geeignet.
  • Docker-CP verfügt über äußerst eingeschränkte Funktionen, da Herstellerordner, die nicht jedes Mal kopiert werden sollten, und der Kopieralgorithmus selbst eher langsam sind.
• (für Remote- / lokale Verwendung) Hängen Sie den gewünschten Containerordner in den externen Hostordner ein. Laden Sie lokale Dateien direkt in den bereitgestellten Hostordner herunter. Es gibt bereits viele Implementierungsoptionen:
  
  • Verwenden Sie Docker-Maschine und speziell Docker-Maschine scp
    
    • Auch hier müssen Sie die Umgebung konfigurieren, Docker-Maschine konfigurieren. Vielleicht ist dies sinnvoll, wenn Sie ständig mit verschiedenen Servern arbeiten
  • Konfigurieren Sie in der IDE eine FTP-Verbindung mit dem gewünschten Hostordner
    
    • Für jeden neuen Zweig muss eine neue Verbindung erstellt oder die Zuordnung geändert werden
  • Verwenden Sie scp oder rsync, um Dateien in den gewünschten Hostordner hochzuladen. Verwenden Sie dazu ein kleines Bash-Skript und hängen Sie es an die Hotkeys
    
    • Zunächst scheint es unnötig kompliziert zu sein, aber tatsächlich ist es nicht so. Das Skript selbst ist so einfach wie möglich und wird benötigt, um den Prozess zu automatisieren, damit Sie die Zuordnungen nicht jedes Mal neu konfigurieren müssen

Lösung selbst: rsync + Volumes

tldr:

• Benötigen Sie SSH-Zugriff auf einen Remote-Server und Rsync auf dem lokalen Computer
• Der Remote-Server muss über einen beschreibbaren Ordner verfügen
• Hängen Sie den Projektordner im Container in den externen Hostordner ein
• Fügen Sie dem Stammverzeichnis des Projekts ein kleines Bash-Skript hinzu, um Dateien mit dem Remote-Server zu synchronisieren
• Konfigurieren Sie einen Hotkey für die Ausführung des Synchronisationsskripts

Es ist anzumerken, dass die bereitgestellte Lösung für die Entwicklungs- und Testumgebung ausgeschlossen ist

In diesem Fall werde ich mir die Docker-Compose- und Gitlab-CI-Umgebungen ansehen, wobei Docker-Compose Umgebungsvariablen von Gitlab-CI verwendet.

Wir bilden den Pfad zum Zielordner in gitlab-ci und exportieren diesen Pfad in docker-compose.yml:

before_script: - export SHARED_DIR_BASE='/var/www/builds' #    ,      - export SHARED_BRANCH_DIR=${SHARED_DIR_BASE}/${PROJECT_GROUP}/${PROJECT_NAME}/${CI_COMMIT_REF_NAME} #     web-123   my_group/my_project,      /var/shared/my_group/my_project/web-123 Deploy dev: stage: deploy_dev script: #   ,         - mkdir -p ${SHARED_BRANCH_DIR} - rsync -r --exclude-from=.gitignore --exclude-from=.dockerignore . ${SHARED_BRANCH_DIR} - find ${SHARED_BRANCH_DIR} -type d -exec setfacl -d -mo:rwx {} \; - find ${SHARED_BRANCH_DIR} -type d -exec setfacl -mo:rwx {} \; - find ${SHARED_BRANCH_DIR} -type f -exec setfacl -mo:rwx {} \; - envsubst < docker-compose.tmpl > docker-compose.yml #     gitlab-ci.yml  docker-compose.yml,   docker-compose.tmpl - docker-compose up -d 

Als nächstes müssen wir die Projektordner in Docker-Compose in den externen Host-Ordner einbinden. Da wir die Variablen in Docker-Compose verwenden, benötigen wir die Vorlage Docker-Compose.tmpl, in der wir diese Variablen verwenden.

 version: '2.3' services: web: ... volumes: - ${SHARED_BRANCH_DIR}:/app/:rw #             #        .    ,      ,           .              ,     ,        - /app/protected/vendor/ 

Bereits die aktuelle Konfiguration ist ausreichend. Wenn Sie jetzt den Zweig auf dem Hostserver erstellen, wird der Ordner / var / www /build / GROUP_NAME / PROJECT_NAME / BRANCH_NAME erstellt und das Projekt wird dort übertragen, mit Ausnahme der Dateien und Ordner, die in .gitignore und .dockerignore angegeben sind Sie können einfach FTP-Zuordnungen konfigurieren, aber wir werden noch etwas weiter gehen und den Prozess etwas automatisieren.

Um Dateien zu synchronisieren, müssen wir ungefähr Folgendes ausführen:

 rsync -r -u \ --delete-after \ --exclude-from=.gitignore \ --exclude-from=.dockerignore \ . $sshUserName@$sshHost:$sharedBaseDir 

Tatsächlich wird dieser Befehl in kleinen und mittleren Projekten schneller ausgeführt, als Sie Zeit haben, Änderungen festzuschreiben und in das Repository zu übertragen. Es bleibt, dieses Skript vollständiger zu gestalten und seine Ausführung an Hotkeys zu binden.

 #!/usr/bin/env bash #    while [ -n "$1" ] do case "$1" in --sshUserName=*) sshUserName=${1#*=} ;; --sshHost=*) sshHost=${1#*=} ;; esac shift done #  shared    gitBranch=$(git branch | grep \* | cut -d ' ' -f2) gitProject=$(git config --local remote.origin.url|sed -n 's#.*/\([^.]*\)\.git#\1#p') gitGroup=$(git config --local remote.origin.url|sed -n 's#.*/\([^.]*\)/.*\.git#\1#p') sharedBaseDir=/var/www/builds/$gitGroup/$gitProject/$gitBranch #         rsync -r -u \ --delete-after \ --exclude-from=.gitignore \ --exclude-from=.dockerignore \ . $sshUserName@$sshHost:$sharedBaseDir echo "done" 

Es ist zu beachten, dass sich das Skript im Stammverzeichnis des Projektordners des Repositorys befinden oder angeben muss, in welchem ​​Verzeichnis es funktionieren soll.

Es bleibt nur, die Ausführung dieses Skripts an bestimmte Hotkeys zu binden und die Parameter sshUserName und sshHost festzulegen (es versteht sich, dass bereits über ssh auf den Remote-Server zugegriffen werden kann). Wie das geht, werde ich ein Beispiel für PHPstorm geben.

• Gehen Sie zu Datei -> Einstellungen
• Erweitern Sie im Einstellungsfenster im linken Menü Extras und wählen Sie Externe Tools
• Wir schreiben den Pfad zum Skript und geben den realen sshUserName und sshHost in den Argumenten an
  
  
• Gehen Sie als Nächstes zu Keymap und suchen Sie nach dem Namen unserer externen Tools. Stellen Sie die erforderliche Kombination ein
  
  

Das ist alles. Wenn Sie nun auf die gewünschte Kombination klicken, werden alle Projektdateien mit dem Remote-Ordner synchronisiert, der mit dem Projektordner im Container bereitgestellt wird. Das heißt, Änderungen werden fast sofort sichtbar.

Ich gebe nicht vor, "ideal" für diese Lösung zu sein, es gibt wahrscheinlich bessere Optionen. Ich werde mich freuen, wenn ich in den Kommentaren davon erfahre. Vielen Dank!