Fortgeschrittene Installation von OTOBO mit Docker Compose

Dieser Abschnitt gibt einige weitere technische Einblicke in das, was unter der Haube passiert.

::: version Liste der Docker-Container; 10+ Container otobo_web_1 : OTOBO-Webserver auf internem Port 5000.

Container otobo_daemon_1 : OTOBO-Dämon. Der OTOBO-Dämon wird gestartet und periodisch überprüft.

Container otobo_db_1 : Führt die Datenbank MariaDB auf internem Port 3306 aus.

Container otobo_elastic_1 : Elasticsearch auf den internen Ports 9200 und 9300.

Container otobo_redis_1 : Führt Redis als Caching-Dienst aus.

Optional Container otobo_nginx_1 : Führt nginx als Reverse-Proxy für die Bereitstellung von HTTPS-Unterstützung aus. :::

::: version Liste der Docker-Container; 11 Container otobo-web-1 : OTOBO-Webserver auf internem Port 5000.

Container otobo-daemon-1 : OTOBO-Dämon. Der OTOBO-Dämon wird gestartet und periodisch überprüft.

Container otobo-db-1 : Führt die Datenbank MariaDB auf internem Port 3306 aus.

Container otobo-elastic-1 : Elasticsearch auf den internen Ports 9200 und 9300.

Container otobo-redis-1 : Führt Redis als Caching-Dienst aus.

Optional Container otobo-nginx-1 : Führt nginx als Reverse-Proxy für die Bereitstellung von HTTPS-Unterstützung aus. :::

Übersicht über die Docker-Volumes

Die Docker-Volumes werden auf dem Host für persistente Daten erstellt. Diese ermöglichen das Starten und Stoppen der Dienste ohne Datenverlust. Beachten Sie, dass Container temporär sind und nur Daten in den Volumes dauerhaft sind. otobo_opt_otobo : enthält /opt/otobo im Container web und daemon.

otobo_mariadb_data : enthält /var/lib/mysql im Container db.

otobo_elasticsearch_data : enthält /usr/share/elasticsearch/data im Container elastic.

otobo_redis_data : enthält Daten für den Container redis.

otobo_nginx_ssl : enthält die TLS-Dateien, Zertifikat und privater Schlüssel, muss manuell initialisiert werden.

Docker-Umgebungsvariablen

In den Anweisungen haben wir nur eine minimale Konfiguration durchgeführt. Aber die Datei .env erlaubt es, mehr Variablen zu setzen. Hier ist eine kurze Liste der wichtigsten Umgebungsvariablen. Beachten Sie, dass die Basis-Images mehr Umgebungsvariablen unterstützen.

MariaDB-Einstellungen

OTOBO_DB_ROOT_PASSWORD : Das Root-Passwort für MariaDB. Diese Einstellung wird benötigt, um den Dienst db zu betreiben.

Elasticsearch-Einstellungen

Elasticsearch benötigt einige Einstellungen für produktive Umgebungen. Bitte lesen Sie https://www.elastic.co/guide/en/elasticsearch/reference/7.8/docker.html#docker-prod-prerequisites für detaillierte Informationen.

OTOBO_Elasticsearch_ES_JAVA_OPTS : Beispiel-Einstellung: OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m Bitte passen Sie diesen Wert für Produktionsumgebungen auf bis zu 4g an.

Webserver-Einstellungen

OTOBO_WEB_HTTP_PORT : Setzen Sie diesen Wert, falls sich der HTTP-Port vom Standardport 80 unterscheiden soll. Wenn HTTPS aktiviert ist, wird der HTTP-Port auf HTTPS umgeleitet.

Nginx-Webproxy-Einstellungen : Diese Einstellungen werden verwendet, wenn HTTPS aktiviert ist.

OTOBO_WEB_HTTP_PORT : Setzen Sie diesen Wert, falls sich der HTTP-Port vom Standardport 80 unterscheiden soll. Wird auf HTTPS umgeleitet.

OTOBO_WEB_HTTPS_PORT : Setzen Sie diesen Wert, falls sich der HTTPS-Port vom Standardport 443 unterscheiden soll.

OTOBO_NGINX_SSL_CERTIFICATE : SSL-Zertifikat für den Nginx-Webproxy. Beispiel: OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/acme.crt

OTOBO_NGINX_SSL_CERTIFICATE_KEY : SSL-Schlüssel für den Nginx-Webproxy. Beispiel: OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/acme.key

Nginx-Webproxy-Einstellungen für Kerberos : Diese Einstellungen werden von Nginx verwendet, wenn Kerberos für Single Sign-On verwendet wird.

OTOBO_NGINX_KERBEROS_KEYTAB Kerberos-Keytab-Datei. Der Standard ist /etc/krb5.keytab.

OTOBO_NGINX_KERBEROS_CONFIG : Kerberos-Konfigurationsdatei. Der Standard ist /etc/krb5.conf, normalerweise generiert aus krb5.conf.template.

OTOBO_NGINX_KERBEROS_SERVICE_NAME : Kerberos Service Name. Es ist nicht klar, wo diese Einstellung eigentlich verwendet wird.

OTOBO_NGINX_KERBEROS_REALM : Kerberos-REALM. Verwendet in /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_KDC : Kerberos kdc / AD Controller. Verwendet in /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_ADMIN_SERVER : Kerberos-Admin-Server. Verwendet in /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_DEFAULT_DOMAIN : Kerberos-Standarddomain. Verwendet in /etc/krb5.conf.

NGINX_ENVSUBST_TEMPLATE_DIR : Stellt ein benutzerdefiniertes Nginx-Konfigurationsvorlagenverzeichnis bereit. Bietet zusätzliche Flexibilität.

Docker Compose-Einstellungen : Diese Einstellungen werden direkt von Docker Compose verwendet.

COMPOSE_PROJECT_NAME : Der Projektname wird als Präfix für die Volumes und Container verwendet. Standardmäßig ist dieses Präfix auf otobo gesetzt, was in Containernamen wie otobo_web_1 und otobo_db_1 resultiert. Ändern Sie diesen Namen, wenn Sie mehr als eine Instanz von OTOBO auf demselben Server betreiben möchten.

COMPOSE_PATH_SEPARATOR : Trennzeichen für den Wert von COMPOSE_FILE

COMPOSE_FILE : Verwenden Sie docker-compose/otobo-base.yml als Basis und fügen Sie die gewünschten Erweiterungsdateien hinzu. Z.B. docker-compose/otobo-override-http.yml oder docker-compose/otobo-override-https.yml.

OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX, \... : Verwendet für die Spezifikation alternativer Docker-Images. Nützlich für das Testen lokaler Builds oder für die Verwendung aktualisierter Versionen der Images.

Benutzerdefinierte Konfiguration des Nginx-Webproxys

Der Container otobo_nginx_1 stellt die HTTPS-Unterstützung bereit, indem Nginx als Reverse-Proxy ausgeführt wird. Das Docker-Image, das im Container läuft, besteht aus dem offiziellen Nginx Docker-Image, https://hub.docker.com/_/nginx, zusammen mit einer OTOBO-spezifischen Konfiguration von Nginx. Die standardmäßige OTOBO-spezifische Konfiguration findet sich innerhalb des Docker-Images unter /etc/nginx/template/otobo_nginx.conf.template. Tatsächlich handelt es sich dabei nur um eine Vorlage für die endgültige Konfiguration. Es gibt einen Prozess, der von dem Nginx-Basis-Image bereitgestellt wird, der die Makros in der Vorlage mit den entsprechenden Umgebungsvariablen ersetzt. Dieser Prozess wird ausgeführt, wenn der Container startet. In der Standardvorlagendatei werden die folgenden Makros verwendet:

OTOBO_NGINX_SSL_CERTIFICATE : Zur Konfiguration von SSL.

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Zur Konfiguration von SSL.

OTOBO_NGINX_WEB_HOST : Der intern verwendete HTTP-Host.

OTOBO_NGINX_WEB_PORT : Der intern verwendete HTTP-Port.

Siehe Schritt [4.] für die Nutzung dieser Konfigurationsmöglichkeit zur Einrichtung des SSL-Zertifikats.

Wenn die Standardmakros nicht ausreichen, kann die Anpassung weiter gehen. Dies kann erreicht werden, indem die standardmäßige Konfigurationsvorlage durch eine angepasste Version ersetzt wird. Es ist eine bewährte Praxis, die Konfiguration nicht einfach im laufenden Container zu ändern. In diesen Beispielbefehlen verwenden wir die vorhandene Vorlage als Ausgangspunkt.

cd /opt/otobo-docker
mkdir nginx
docker cp otobo_nginx_1:/etc/nginx/conf.d/otobo_nginx.conf /opt/otobo-docker/nginx/otobo_nginx.conf
docker exec otobo_nginx_1 rm /etc/nginx/conf.d/otobo_nginx.conf

Fügen Sie die folgende Zeile in die Datei docker-compose/otobo-override-https.yml ein:

volumes:
  - /opt/otobo-docker/nginx/otobo_nginx.conf:/opt/otobo-docker/nginx/otobo_nginx.conf

Dazu können Sie Ihren Lieblingstexteditor nutzen mit Putty oder WinSCP.

nano docker-compose/otobo-override-https.yml

Jetzt können Sie die Datei /opt/otobo-docker/nginx/otobo_nginx.conf bearbeiten. Um die Änderungen zu übernehmen, müssen die Container neu gestartet werden:

docker-compose up -d --build

Single Sign-On mit der Kerberos-Unterstützung in Nginx

Um die Authentifizierung mit Kerberos zu aktivieren, basieren Sie bitte Ihre .env-Datei auf der Beispiel-Datei .docker_compose_env_https_kerberos. Dies aktiviert die spezielle Konfiguration in docker-compose/otobo-override-https-kerberos.yml. Diese Docker Compose-Konfigurationsdatei wählt ein Nginx-Image aus, das Kerberos unterstützt. Sie übergibt auch einige Kerberos-spezifische Einstellungen als Umgebungswerte an den laufenden Nginx-Container. Diese Einstellungen sind oben aufgeführt. Wie üblich können die Werte für diese Einstellungen in der .env-Datei angegeben werden. Die meisten dieser Einstellungen werden als Ersatzwerte für die Vorlage https://github.com/RotherOSS/otobo/blob/rel-10_1/scripts/nginx/kerberos/templates/krb5.conf.template verwendet. Der Ersatz findet während des Starts des Containers statt. Im laufenden Container ist dann die angepasste Konfiguration in /etc/krb5.conf verfügbar. Das Bereitstellen einer benutzerspezifischen /etc/krb5.conf-Datei ist immer noch möglich. Dies kann durch das Einbinden eines Volumes erfolgen, das /etc/krb5.conf im Container überschreibt. Dies kann erreicht werden, indem OTOBO_NGINX_KERBEROS_CONFIG in der .env-Datei gesetzt und die Mount-Direktive in docker-compose/otobo-override-https-kerberos.yml aktiviert wird. /etc/krb5.keytab ist immer installationsspezifisch und muss daher immer vom Hostsystem eingebunden werden. Kerberos SSO-Installationsanleitung sso-kerberos

Wählen nicht standardmäßiger Ports

Standardmäßig bedienen die Ports 443 und 80 HTTPS bzw. HTTP. Es kann Fälle geben, in denen einer oder beide dieser Ports bereits von anderen Diensten verwendet werden. In diesen Fällen können die Standardports durch Angabe von OTOBO_WEB_HTTP_PORT und OTOBO_WEB_HTTPS_PORT in der .env-Datei überschrieben werden.

Start bestimmter Dienste überspringen

Die aktuelle Docker Compose-Konfiguration startet fünf, sechs, wenn HTTPS aktiviert ist, Dienste. Es gibt jedoch valide Anwendungsfälle, in denen einer oder mehrere dieser Dienste nicht benötigt werden. Das Hauptbeispiel ist, wenn die Datenbank nicht als Docker-Dienst, sondern als externe Datenbank betrieben werden soll.

docker-compose up -d web nginx daemon redis elastic

Natürlich kann dasselbe Ziel auch erreicht werden, indem die Datei docker-compose/otobo-base.yml bearbeitet und die relevanten Dienstdefinitionen entfernt werden.

Anpassen von OTOBO Docker Compose

Statt die Dateien unter docker-compose/ zu bearbeiten und das Risiko einzugehen, Ihre eigenen Optionen mit dem nächsten Update des otobo-docker-Ordners zu überschreiben, ist es ratsam, eine extra YAML-Datei zu erstellen, in der die spezifischen Dienste mit zusätzlichen Optionen überschrieben werden. Ein gängiges Beispiel wäre, den Datenbankcontainer von außen über Port 3306 zugänglich zu machen. Dazu könnten Sie eine extra Docker-Compose-Datei erstellen, die wie folgt aussieht:

cat custom_db.yml
services:
  db:
    ports:
      - "0.0.0.0:3306:3306"

Jetzt müssen wir docker-compose mitteilen, unsere neue Datei einzubeziehen. Dazu müssen Sie Ihre YAML-Datei der Variablen COMPOSE_FILE in der .env-Datei hinzufügen, zum Beispiel:

COMPOSE_FILE=docker-compose/otobo-base.yml:docker-compose/otobo-override-http.yml:custom_db.yml

Jetzt können wir docker-compose verwenden, um unsere Container neu zu erstellen:

docker-compose stop
docker-compose up -d

Mit diesem Verfahren können Sie jeden Dienst oder jedes Volume anpassen.

Anpassen des OTOBO Docker-Images

Viele Anpassungen können im externen Volume otobo_opt_otobo vorgenommen werden, das dem Verzeichnis /opt/otobo im Docker-Image entspricht. Dies funktioniert z.B. für lokale Perl-Module, die in /opt/otobo/local installiert werden können. Hier ein Beispiel, das das nicht sehr nützliche CPAN-Modul Acme::123 installiert.

docker exec -it ${COMPOSE_PROJECT_NAME:=otobo}_web_1 bash
pwd

/opt/otobo

cpanm -l local Acme::123

—> Working on Acme::123

Fetching http://www.cpan.org/authors/id/N/NA/NATHANM/Acme-123-0.04.zip … OK Configuring Acme-123-0.04 … OK Building and testing Acme-123-0.04 … OK Successfully installed Acme-123-0.04 1 distribution installed

Das Schöne an diesem Ansatz ist, dass das Docker-Image selbst nicht modifiziert werden muss. Das Installieren zusätzlicher Debian-Pakete ist ein wenig kniffliger. Ein Ansatz ist, ein benutzerdefiniertes Dockerfile zu erstellen und das OTOBO-Image als Basis-Image zu verwenden. Ein anderer Ansatz besteht darin, direkt aus einem laufenden Container ein modifiziertes Image zu erstellen. Dies kann mit dem Befehl docker commit gemacht werden, https://docs.docker.com/engine/reference/commandline/commit/. Eine schöne Beschreibung dieses Prozesses finden Sie auf https://phoenixnap.com/kb/how-to-commit-changes-to-docker-image. Für den letztgenannten Ansatz gibt es zwei Hürden zu überwinden. Erstens läuft das Bild otobo standardmäßig als Benutzer otobo mit der UID 1000. Das Problem ist, dass der Benutzer otobo nicht berechtigt ist, Systempakete zu installieren. Also ist der erste Teil der Lösung, die Option --user root zu verwenden, wenn das Image gestartet wird. Die zweite Hürde ist, dass das standardmäßige Einstiegsskript /opt/otobo_install/entrypoint.sh sofort beendet wird, wenn es als root aufgerufen wird. Die Überlegung hinter dieser Designentscheidung ist, dass unbeabsichtigtes Ausführen als root vermieden werden sollte. Der zweite Teil der Lösung ist daher, ein anderes Einstiegsskript zu spezifizieren, das nicht kümmert, wer der Anrufer ist. Damit gelangen wir zu den folgenden Beispielbefehlen, bei denen wir otobo Fortune Cookies hinzufügen: Ziehen Sie ein getaggtes OTOBO-Image, falls wir es noch nicht haben, und prüfen Sie, ob das Image bereits Fortune Cookies bereitstellt:

docker run rotheross/otobo:rel-10_0_10 /usr/games/fortune

/opt/otobo_install/entrypoint.sh: line 57: /usr/games/fortune: No such file or directory

Fügen Sie einem benannten Container, der das ursprüngliche OTOBO-Image ausführt, Fortune Cookies hinzu. Dies geschieht in einer interaktiven Sitzung als Benutzer root:

docker run -it --user root --entrypoint /bin/bash --name otobo_orig rotheross/otobo:rel-10_0_10
apt update
apt install fortunes
exit
docker ps -a | head

Erstellen Sie ein Image aus dem gestoppten Container und geben Sie ihm einen Namen. Beachten Sie, dass der Standardbenutzer und das Einstiegsskript wiederhergestellt werden müssen: Schließlich können wir es überprüfen:

docker run otobo_with_fortune_cookies /usr/games/fortune

A platitude is simply a truth repeated till people get tired of hearing it. — Stanley Baldwin

Das geänderte Image kann in Ihrer .env-Datei festgelegt und dann zu Spaß und Gewinn verwendet werden.

Lokale Images erstellen

::: info Das lokale Erstellen von Docker-Images ist normalerweise nur während der Entwicklung erforderlich. Andere Anwendungsfälle sind, wenn aktuellere Basis-Images für eine Installation verwendet werden sollten oder wenn zusätzliche Funktionalitäten zu den Images hinzugefügt werden müssen. ::: Die Docker-Dateien, die zum lokalen Erstellen von Docker-Images benötigt werden, sind Teil des git-Repositorys https://github.com/RotherOSS/otobo:

otobo.web.dockerfile
otobo.nginx.dockerfile
otobo.elasticsearch.dockerfile Das Skript für die tatsächliche Erstellung der Images ist bin/docker/build_docker_images.sh.

cd /opt
git clone https://github.com/RotherOSS/otobo.git

Wechseln Sie zum gewünschten Branch. z.B.

git checkout rel-10_0_11

cd otobo

Ändern Sie die Docker-Dateien bei Bedarf

bin/docker/build_docker_images.sh
docker image ls

Die lokal erstellten Docker-Images werden als local-<OTOBO_VERSION> getaggt, wobei die Version aus der Datei RELEASE verwendet wird. Nachdem die lokalen Bilder erstellt wurden, kann man zum Verzeichnis docker-compose zurückkehren. Die lokalen Bilder werden durch Setzen von OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX in .env deklariert.

Automatische Installation

Statt den Prozess über http://yourIPorFQDN/otobo/installer.pl durchzuführen, kann man eine Abkürzung nehmen. Das ist nützlich, um die Test-Suite auf einer frischen Installation auszuführen. ::: warning docker-compose down -v wird alle vorherigen Setups und Daten entfernen. :::

docker-compose down -v
docker-compose up --detach
docker-compose stop daemon
docker-compose exec web bash\
-c "rm -f Kernel/Config/Files/ZZZAAuto.pm ; bin/docker/quick_setup.pl --db-password otobo_root"
docker-compose exec web bash\
-c "bin/docker/run_test_suite.sh"
docker-compose start daemon

Liste nützlicher Befehle

Docker

docker system prune -a Systembereinigung (entfernt alle ungenutzten Images, Container, Volumes, Netzwerke)
docker version Zeigt die Version an
und viele weitere nützliche Docker-Befehle.

Docker Compose

docker-compose config Überprüft und zeigt die Konfiguration an
docker-compose ps Zeigt die laufenden Container an
und weitere nützliche Docker Compose-Befehle.