Howto Aktualisierung Docker Setup (18.32.1)

[mplan]

Hallo,
wie aktualisiert man das Docker Setup wie in der README zum Release 18.32 geschrieben?
" Bitte auch das Docker-Setup aktualisieren (https://github.com/kix-service-software/kix-on-premise/tree/master).

Hatte "git pull" versucht. Da kam die Meldung:
  Hinweis: Sie haben abweichende Branches und müssen angeben, wie mit diesen
  Hinweis: umgegangen werden soll.
Da ich nicht wusste, ob man hier ein Merge, Rebase oder pull.ff durchführen sollte, hab' ich das Setup komplett neu gemacht.
Das gesamte kix-on-premise Verzeichnis wurde umbenannt und ein erneutes "git clone" durchgeführt.Danach wieder alles konfiguriert

Aber ich denke, das ist nicht der angedachte und optimale Weg. Hätte es gereicht, die beiden *ssl*.conf Dateien aus dem Repository manuell zu kopieren?

Viele Grüße
Michael

[GHI]

Ahoi,

ich würde vermuten über das OS spezifische Update-Skript im jeweiligen deploy-Unterordner.

[mplan]

Hi,
vielen Dank für Deine Antwort.

Das update.sh Script (Linux) aktualisiert "nur" die Docker-Images.
Ich denke, es hat eher was mit dem git Kommando zu tun.
Hier (git clone ) wird am Ende die proxy/ssl.conf und proxy/non-ssl.conf neu vom Repository geholt (nach Vergleich mit dem Backup)

Da es eigentlich um ein Update geht, wird "git clone" nicht das Richtige sein, da es ja alles neu schreibt, oder?
Wir haben jetzt doch mal versucht, mit dem Merge weiterzukommen (git config pull.rebase false  # Merge). 
Da kommt dann aber gleich der nächste Fehler:

Code Auswählen Erweitern

#> git config pull.rebase false
#> git pull
Schwerwiegend: verweigere den Merge von nicht zusammenhängenden Historien

#>git pull --allow-unrelated-histories
Fehler: Ihre lokalen Änderungen in den folgenden Dateien würden durch den Merge überschrieben werden:
        deploy/linux/docker-compose.yml
Bitte committen oder stashen Sie Ihre Änderungen, bevor Sie mergen.
Abbruch
Merge mit Strategie ort fehlgeschlagen.

Klar, die docker-compose.yml wurde angepasst, ebenso die Start/Stop Scripts.
Gute wäre es, wenn man sehen könnte, was die Unterschiede sind und dann ggf. von Datei zu Datei entscheiden könnte, ob sie überschrieben/behalten oder merged wird.

Viele Grüße
Michael

[Benedikt Geißler]

Hallo zusammen,

gemeint ist damit die Aktualisierung des lokalen kix-on-premise-Verzeichnisses, also des git-Repositories.

Da es momentan leider immer mal wieder zu divergierenden Historien kommt, hier ein paar allgemeine Hinweise, wie sich das lokale Verzeichnis trotzdem sicher aktualisieren lassen sollte:

Beim normalen "git pull" wird – sofern es nicht einfach nur ein Hinzufügen von Commits ist – ein Merge des lokalen mit dem entfernten Stand versucht. Da hier allerdings die Historie im entfernten Repository neu geschrieben wurde, klappt auch dies nicht. Die Alternative lautet dann 

Code Auswählen Erweitern

git pull --rebase
Damit wird ein Umschreiben auch der lokalen Historie zugelassen. Hilfreich ist dabei zudem häufig, vorher ein 

Code Auswählen Erweitern

git stashdurchzuführen, damit lokale Anpassungen an Dateien vorerst zurückgestellt werden. Falls es nun immer noch nicht mittels git pull --rebase klappt, kann es erforderlich sein, von git getrackte Dateien mittels Notieren der Dateinamen in der Datei .gitignore von git ignorieren zu lassen. Eine Übersicht über geänderte und ungetrackte Dateien im Vergleich zum letzten Commit erhält man jederzeit über

Code Auswählen Erweitern

git status

Diese Änderung müsste dann mit einem neuen Commit gesichert werden, etwa mittels 

Code Auswählen Erweitern

git add .gitignore
git commit -m 'ignore local files'
Nun sollte git pull --rebase funktionieren und anschließend können die zuvor zurückgestellten Änderungen folgendermaßen wieder hervorgeholt werden:

Code Auswählen Erweitern

git stash apply
An dieser Stelle kann es passieren, dass es eine Fehlermeldung bezüglich Konflikten gibt. Mit einem erneuten "git status" sieht man, welche Dateien betroffen sind. Diese wären dann zu bearbeiten und die Konflikte manuell aufzulösen. Einen Automatismus gibt es hierbei leider nicht, da es sich um Zeilen oder ganze Abschnitte handelt, die sowohl lokal als auch entfernt modifiziert worden sind. Ein Beispiel dafür wäre die deploy/linux/proxy/ssl.conf – hier ist standardmäßig alles auskommentiert, lokale Anpassungen erfordern aber ein komplettes Einkommentieren. Daher ist hier immer eine manueller Merge der Anpassungen erforderlich. Hilfreich könnte hierbei sein, sich zunächst zu merken, welche Änderung man eigentlich vorgenommen hatte, die lokale Änderung komplett zu verwerfen, den entfernten Stand zu übernehmen und dann nochmal erneut basierend auf dem neuen Stand eigene Anpassungen wieder vorzunehmen. Etwa so:

Code Auswählen Erweitern

git checkout origin/master -- deploy/linux/proxy/ssl.conf
git add deploy/linux/proxy/ssl.conf
git stash apply
Am Ende sollte ein erneutes "git status" ungefähr folgendes anzeigen:

Code Auswählen Erweitern

Auf Branch master
Ihr Branch ist 1 Commit vor 'origin/master'.
  (benutzen Sie "git push", um lokale Commits zu publizieren)
Also auf dem gleichen Stand wie oder vor origin/master, weil ein lokaler Commit zum Ignorieren einiger Dateien oder Verzeichnisse hinzugefügt wurde.

Ich hoffe, die Erläuterungen helfen euch etwas weiter.

Viele Grüße
Benedikt

[mplan]

Hallo Benedikt,
vielen Dank für die Hinweise, vor allem, dass ein "rebase" gemacht werden sollte.
Damit kommen wir weiter. 
Wir haben ein "git stash" vor dem "git pull --rebase" ausgeführt und konnten damit das Repository erfolgreich aktualisieren.
Es gibt noch Meldungen/Hinweise zu "unversionierten Dateien", da in dem Verzeichnis eigene Dateien/Ordner angelegt wurden. Das sind aber zum Glück keine Fehler.
Eventuell packen wir diese Dinge dann in die .gitignore Datei dazu.

Viele Grüße
Michael