Installation mit Docker und Docker Compose

Mit der Docker-basierten Installation können Sie Ihre komplette OTOBO-Instanz innerhalb weniger Minuten aufsetzen. Alle Abhängigkeiten sind in den Docker Images bereits enthalten.

  • Service db: Als Standard-Datenbank ist MariaDB integriert.

  • Service elastic: Für die OTOBO-Schnellsuche ist Elasticsearch eingerichtet.

  • Service redis: Redis sorgt für schnelles Caching.

  • Service web: Gazelle dient als schneller Perl-Webserver.

  • Service nginx: Als optionaler Reverseproxy für die HTTPS-Unterstützung wird nginx eingesetzt.

Wir denken: Dieses Setup ist die perfekte Umgebung für eine OTOBO-Installation.

Technische Voraussetzungen

Hier sind die bisher getesteten Mindestanforderungen an die verwendete Software aufgeführt:

  • Docker 19.03.13

  • Docker Compose 1.25.0

  • Git 2.17.1

Bemerkung

Um die benötigten Versionen für Ubuntu 18.04 zu installieren, folgen Sie den Anweisungen unter https://www.digitalocean.com/community/tutorials/how-to-install-docker-compose-on-ubuntu-18-04 und https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-18-04.

git, Docker und Docker Compose können mit den Standard-Systemtools installiert werden. Ein Beispiel für die Installation unter Ubuntu 20.04:

root> apt-get install git docker docker-compose curl
root> systemctl enable docker

Informationen zum weiteren Septup entnehmen Sie bitte der Git- und Docker-Dokumentation.

Installation

Wir gehen im Folgenden davon aus, dass alle erforderlichen Softwaremodule installiert sind und eine funktionierende Docker-Umgebung zur Verfügung steht. Außerdem, dass zur Interaktion mit Docker der Benutzer docker_admin verwendet wird. Der Docker-Admin kann entweder der root-Benutzer des Docker-Host oder ein spezieller Benutzer mit den erforderlichen Berechtigungen sein.

1. otobo-docker Repository klonen

Die Docker-Images werden schließlich aus dem Repository https://hub.docker.com abgerufen. Es gibt jedoch einige Setup- und Befehlsdateien, die aus dem Github-Repository otobo-docker geklont werden müssen. Stellen Sie sicher, dass Sie das Tag angeben, das der aktuellen Patch-Level-Version von OTOBO entspricht. Wenn zum Beispiel OTOBO 10.1.10 die aktuelle Version ist, verwenden Sie bitte den Tag rel-10_1_10.

Bemerkung

Wo das geklonte Repository liegt, spielt keine Rolle. In dieser Anleitung wählen wir /opt/otobo-docker als Arbeitsverzeichnis.

docker_admin> cd /opt
docker_admin> git clone https://github.com/RotherOSS/otobo-docker.git --branch <TAG> --single-branch
docker_admin> cd otobo-docker    # change into the git sandbox
docker_admin> ls                 # just a sanity check, for example the file README.md should exist

2. Initiale .env-Datei anlegen

In der Docker Compose Konfigurationsdatei .env werden die Einstellungen für die OTOBO-Umgebung vorgenommen. Diese Datei muss von Ihnen erstellt und individualisiert werden. Um Ihnen die Aufgabe zu erleichtern, werden zwei Beispieldateien mitausgeliefert, die Sie als Ausgangspunkt verwenden können. Soll per HTTPS auf die OTOBO Webapplikation via HTTPS zugegriffen werden, verwenden Sie bitte .docker_compose_env_https. Wir empfehlen, über HTTPS zuzugreifen. Wird kein HTTPS benötigt, verwenden Sie .docker_compose_env_http als Ausgangspunkt.

.docker_compose_env_http

Die OTOBO Oberfläche ist über HTTP erreichbar.

.docker_compose_env_https

Die OTOBO Oberfläche ist über Nginx als Reverse-Proxy per HTTPS erreichbar.

.docker_compose_env_https_custom_nginx

Ähnlich zu .docker_compose_env_https, aber mit Unterstützung einer individuellen Nginx Konfiguration.

.docker_compose_env_https_kerberos

Ähnlich zu .docker_compose_env_https, aber mit Beispiel Konfiguration für Single-Sign-On. Bitte beachten Sie, dass die Unterstützung für Kerberos noch experimentell ist.

.docker_compose_env_http_selenium und .docker_compose_env_https_selenium

Diese werden nur für Entwicklungszwecke genutzt, wenn Selenium Tests aktiviert sind.

Bemerkung

ls -a zeigt die ausgeblendete Template-Dateien an.

In der Grundeinstellung erfolgt die Verbindung zu OTOBO über die Standardports: Port 443 für HTTPS und Port 80 für HTTP. Auch bei aktiviertem HTTPS, läuft die OTOBO Webapplikation via HTTP. Die HTTPS-Unterstützung erfolgt über einen zusätzlichen Reverseproxy, der als nginx-Service vorgeschaltet wird.

Für die folgenden Befehle gehen wir davon aus, dass HTTPS unterstützt werden soll.

docker_admin> cd /opt/otobo-docker
docker_admin> cp -p .docker_compose_env_https .env # or .docker_compose_env_http for HTTP

3. Passwort für den Datenbankadministrator konfigurieren

Ändern Sie folgenden Wert in der .env-Datei:

OTOBO_DB_ROOT_PASSWORD=<Ihr_geheimes_Passwort>

The password for the database admin user may be chosen freely. The database admin user is needed to create the database user otobo and the database schema otobo. OTOBO will actually use the dedicated database user otobo.

4. Volume mit SSL-Konfiguration für den nginx-Webproxy aufsetzen (optional)

Dieser Schritt kann entfallen, wenn nur per HTTP auf OTOBO zugegriffen werden soll.

nginx erfordert für die SSL-Verschlüsselung ein Zertifikat sowie einen privaten Schlüssel.

Bemerkung

Für Testzwecke und beim Entwickeln kann ein selbst signiertes Zertifikat verwendet werden. Grundsätzlich sind jedoch offizielle Zertifikate erforderlich.

Mehr dazu, wie Sie ein selbst signiertes Zertifikat erstellen, erfahren Sie z. B. unter https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-nginx-in-ubuntu-18-04.

Bemerkung

Um in nginx eine CA-Chain zusammen mit einem Zertifikat anzugeben, muss das CA-Chain-File mit dem eigentlichen Zertifikat in eine Datei kopiert werden.

Das Zertifikat und der private Schlüssel werden in einem Volume hinterlegt, um später von nginx verwendet werden zu können. Legen Sie zunächst das Volume an und kopieren Sie anschließend Zertifikat und Schlüssel hinein:

docker_admin> docker volume create otobo_nginx_ssl
docker_admin> otobo_nginx_ssl_mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_nginx_ssl)
docker_admin> echo $otobo_nginx_ssl_mp  # just a sanity check
docker_admin> cp /PathToYourSSLCert/ssl-cert.crt /PathToYourSSLCert/ssl-key.key $otobo_nginx_ssl_mp

Die Namen der kopierten Dateien müssen in die eben angelegte .env-Datei eingegeben werden. Z.B.

OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/ssl-cert.crt und OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/ssl-key.key

Bitte passen Sie nur die Dateinamen an. Der Pfad /etc/nginx/ssl/ ist im Docker Image festgeschrieben.

5. Installation mit Docker und Docker Compose

Jetzt starten wir die Docker Container mit docker-compose. Standardmäßig werden die Docker Images von https://hub.docker.com/u/rotheross heruntergeladen.

docker_admin> docker-compose up --detach

Geben Sie folgende Befehle ein, um sicherzustellen, dass die sechs erforderlichen Dienste (fünf, wenn nur HTTP verwendet werden soll) wirklich laufen :

docker_admin> docker-compose ps
docker_admin> docker volume ls

6. OTOBO installieren und starten

Führen Sie den OTOBO Installer von http://IhreIPoderFQDN/otobo/installer.pl aus.

Bemerkung

Konfigurieren Sie OTOBO im Installer mit einer neuen MySQL-Datenbank. Geben Sie als Root-Passwort für die MySQL-Datenbank das Passwort ein, das Sie für die Variable OTOBO_DB_ROOT_PASSWORD in die .env-Datei eingegeben haben. Bitte behalten Sie den Wert db für den MySQL-Hostnamen unverändert bei.

Viel Vergnügen mit OTOBO!

Bemerkung

Um im laufenden Container in das OTOBO-Verzeichnis zu wechseln und wie gewohnt in der Kommandozeile zu arbeiten, können Sie folgenden Docker-Befehl nutzen: docker-compose exec web bash.

Ergänzende technische Informationen

Dieser Abschnitt bietet einige Zusatzinformationen zu den technischen Hintergründen.

Liste der Docker Container

Container otobo_web_1

OTOBO-Webserver über den internen Port 5000.

Container otobo_daemon_1

OTOBO Daemon. Der OTOBO Daemon wird gestartet und regelmäßig geprüft.

Container otobo_db_1

Betreibt die Datenbank MariaDB über den internen Port 3306.

Container otobo_elastic_1

Elasticsearch über die internen Ports 9200 und 9300.

Container otobo_redis_1

Betreibt Redis als Caching-Dienst.

Optionaler Container otobo_nginx_1

Setzt nginx als Reverseproxy für HTTPS-Verbindungen ein.

Übersicht über die Docker Volumes

Die Docker Volumes werden auf dem Host erstellt, um persistente Daten darin zu speichern. So können die Dienste ohne Datenverlust gestartet und gestoppt werden. Bedenken Sie, dass Container nur begrenzte Zeit verfügbar sind, Volumes dagegen dauerhaft.

otobo_opt_otobo

enthält /opt/otobo in den Containern web and daemon.

otobo_mariadb_data

beinhaltet /var/lib/mysql im Container db.

otobo_elasticsearch_data

enthält /usr/share/elasticsearch/datal im Container elastic.

otobo_redis_data

enthält Daten für den Container redis.

otobo_nginx_ssl

enthält die TLS-Dateien, das Zertifikat und den privaten Schlüssel. Muss von Hand initialisiert werden.

Docker-Umgebungsvariablen

Bisher haben wir nur das Nötigste konfiguriert. In der .env-Datei können weitere Konfigurationen vorgenommen werden. Im Folgenden finden Sie eine Auswahl der wichtigsten Umgebungsvariablen.

MariaDB Einstellungen

OTOBO_DB_ROOT_PASSWORD

Das Root-Passwort für MariaDB. Diese Einstellung wird für den Betrieb des db Service benötigt.

Elasticsearch Einstellungen

Damit Elasticsearch in Produktivumgebungen optimal läuft, sind einige Einstellungen vorzunehmen. Detaillierte Informationen entnehmen Sie bitte der Elasticsearch-Dokumentation unter https://www.elastic.co/guide/en/elasticsearch/reference/7.8/docker.html#docker-prod-prerequisites.

OTOBO_Elasticsearch_ES_JAVA_OPTS

Beispieleinstellung: OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m Bitte setzen Sie diesen Wert in Produktivumgebungen auf einen Wert bis 4g.

Webserver Einstellungen

OTOBO_WEB_HTTP_PORT

Hier sind Angaben nötig, falls der HTTP-Port vom Standardport 80 abweicht. Ist HTTPS aktiv, wird der HTTP-Port auf HTTPS umgeleitet.

Einstellungen für den nginx-Webproxy

Diese Einstellungen werden angewendet, wenn HTTPS aktiv ist.

OTOBO_WEB_HTTP_PORT

Hier sind Angaben nötig, falls der HTTP-Port vom Standardport 80 abweicht.

OTOBO_WEB_HTTPS_PORT

Bitte anpassen, falls der HTTPS-Port vom Standardport 443 abweicht.

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 das Single Sign-on eingesetzt wird.

OTOBO_NGINX_KERBEROS_KEYTAB

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

OTOBO_NGINX_KERBEROS_CONFIG

Kerberos Config-Datei. Standard ist /etc/krb5.conf, usually generated from krb5.conf.template

OTOBO_NGINX_KERBEROS_SERVICE_NAME

Kerberos Service Name. Es ist unklar ob diese Einstellung tatsächlich irgendwo 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 Default Domain. Verwendet in /etc/krb5.conf.

NGINX_ENVSUBST_TEMPLATE_DIR

Angeben eines nginx-Konfigurationsvorlangenverzeichnis. Gewährleistet 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 Docker Volumes und Container verwendet. Als Standardwert wird otobo verwendet, sodass die Container z.B. otobo_web_1 und otobo_db_1 heißen. Wenn Sie mehrere OTOBO Instanzen auf dem selben Server betreiben, passen Sie den Projektnamen bitte jeweils individuell an.

COMPOSE_PATH_SEPARATOR

Separator für die Werte im COMPOSE_FILE

COMPOSE_FILE

Verwenden Sie docker-compose/otobo-base.yml als Grundlage und ergänzen Sie die erforderlichen Extension Files wie docker-compose/otobo-override-http.yml oder docker-compose/otobo-override-https.yml.

OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX, …

Werden verwendet, um alternative Docker Images zu deklarieren. Nützlich zum Testen lokaler Builds oder aktuellerer Versionen der Images.

Weiterführende Themen

Individuelle Konfiguration des nginx-Webproxy

Der Container otobo_nginx_1 bietet HTTPS Unterstützung über einen Nginx als Reverse Proxy. Das Docker Image des Containers besteht aus dem offiziellen Nginx Image, https://hub.docker.com/_/nginx, zusammen mit einer OTOBO spezifischen Nginx Konfiguration.

Die standardmäßige OTOBO-spezifische Konfiguration finden Sie im Docker-Image unter /etc/nginx/template/otobo_nginx.conf.template. Eigentlich ist dies nur eine Vorlage für die endgültige Konfiguration. Es gibt einen Prozess, der vom Nginx-Basis-Image bereitgestellt wird und der die Makros in der Vorlage durch die entsprechenden Umgebungsvariablen ersetzt. Dieser Prozess wird beim Starten des Containers ausgeführt. In der Standard-Vorlagendatei werden die folgenden Makros verwendet:

OTOBO_NGINX_SSL_CERTIFICATE

Um SSL zu konfigurieren.

OTOBO_NGINX_SSL_CERTIFICATE_KEY

Um SSL zu konfigurieren.

OTOBO_NGINX_WEB_HOST

Der intern benutzte HTTP Hostname.

OTOBO_NGINX_WEB_PORT

Der intern benutzte HTTP Port.

Wie diese Konfigurationsmöglichkeit genutzt werden kann, um ein SSL-Zertifikat zu installieren, lesen Sie in Schritt 4..

Wenn die Standardmakros nicht ausreichen, kann die Anpassung weiter gehen. Dies kann erreicht werden, indem die Standardkonfigurationsvorlage durch eine angepasste Version ersetzt wird. Am besten ist es, die Konfiguration nicht einfach im laufenden Container zu ändern. Stattdessen erstellen wir zunächst ein persistentes Volume, das die angepasste Konfiguration enthält. Dann weisen wir den otobo_nginx_1 an, das neue Volume zu mounten und die angepasste Konfiguration zu verwenden.

Zuerst muss ein neues Volume erstellt werden. In den Beispielbefehlen benutzen wir das bestehende Template als Ausgangspunkt.

# stop the possibly running containers
docker_admin> cd /opt/otobo-docker
docker_admin> docker-compose down

# create a volume that is initially not connected to otobo_nginx_1
docker_admin> docker volume create otobo_nginx_custom_config

# find out where the new volume is located on the Docker host
docker_admin> otobo_nginx_custom_config_mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_nginx_custom_config)
docker_admin> echo $otobo_nginx_custom_config_mp  # just a sanity check
docker_admin> ls $otobo_nginx_custom_config_mp    # another sanity check

# copy the default config into the new volume
docker_admin> docker create --name tmp-nginx-container rotheross/otobo-nginx-webproxy:latest-10_1
docker_admin> docker cp tmp-nginx-container:/etc/nginx/templates/otobo_nginx.conf.template $otobo_nginx_custom_config_mp # might need 'sudo'
docker_admin> ls -l $otobo_nginx_custom_config_mp/otobo_nginx.conf.template # just checking, might need 'sudo'
docker_admin> docker rm tmp-nginx-container

# adapt the file $otobo_nginx_custom_config_mp/otobo_nginx.conf.template to your needs
docker_admin> vim $otobo_nginx_custom_config_mp/otobo_nginx.conf.template

Nach dem Einrichten des Volumes muss die angepasste Konfiguration aktiviert werden. Das neue Volume wird in docker-compose/otobo-nginx-custom-config.yml eingerichtet. Dazu muss diese Datei zu COMPOSE_FILE hinzugefügt werden. Dann muss Nginx angewiesen werden, die neue Konfiguration zu verwenden. Dies geschieht durch Setzen von NGINX_ENVSUBST_TEMPLATE_DIR in der Umgebung. Um dies zu erreichen, müssen Sie die folgenden Zeilen in Ihrer .env-Datei auskommentieren oder hinzufügen:

COMPOSE_FILE=docker-compose/otobo-base.yml:docker-compose/otobo-override-https.yml:docker-compose/otobo-nginx-custom-config.yml
NGINX_ENVSUBST_TEMPLATE_DIR=/etc/nginx/config/template-custom

Verwenden Sie den folgenden Befehl, um Informationen zur angepassten Docker-Compose-Konfiguration anzuzeigen:

docker_admin> docker-compose config | more

Schließlich können Sie die Container wieder starten:

docker_admin> docker-compose up --detach

Weitere Informationen dazu finden Sie auf https://hub.docker.com/_/nginx im Abschnitt zur Verwendung von Umgebungsvariablen in der nginx-Konfiguration („Using environment variables in nginx configuration (new in 1.19)“).

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

Kurzbeschreibung

Um die Authentifizierung mit Kerberos zu aktivieren, legen Sie Ihrer .env-Datei die Beispieldatei .docker_compose_env_https_kerberos zugrunde. Dadurch wird die spezielle Konfiguration in docker-compose/otobo-override-https-kerberos.yml aktiviert. 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. Die Ersetzung erfolgt während des Starts des Containers. Im laufenden Container wird die angepasste Konfiguration in /etc/krb5.conf zur Verfügung stehen.

Die Bereitstellung einer benutzerspezifischen /etc/krb5.conf-Datei ist weiterhin möglich. Dies kann durch das Einbinden eines Volumes erreicht werden, das /etc/krb5.conf im Container überschreibt. Dies kann durch Setzen von OTOBO_NGINX_KERBEROS_CONFIG in der .env-Datei und durch Aktivieren des Mount-Directove in docker-compose/otobo-override-https-kerberos.yml erreicht werden.

/etc/krb5.keytab ist immer installationsspezifisch und muss daher immer vom Host-System eingehängt werden.

Kerberos SSO Installationsanleitung

Kerberos Single Sign On in der OTOBO Docker-Installation

Individuelle Ports definieren

Standardmäßig nutzt OTOBO die Ports 443 und 80 für HTTPS und HTTP. In manchen Systemen werden dieses Ports jedoch bereits von anderen Diensten verwendet. In diesem Fall können Sie über die Variablen OTOBO_WEB_HTTP_PORT und OTOBO_WEB_HTTPS_PORT in der .env-Datei andere Ports definieren.

Startvorgang gewisser Dienste überspringen

Bei der aktuellen Einrichtung von Docker Compose werden fünf, bei aktiviertem HTTPS sechs Dienste gestartet. Es gibt jedoch berechtigte Anwendungsfälle, in denen einer oder mehrere dieser Dienste nicht benötigt werden. Das beste Beispiel ist, wenn die Datenbank nicht als Docker-Dienst, sondern als externe Datenbank ausgeführt werden soll. Leider gibt es keine spezielle Docker Compose-Option zum Überspringen bestimmter Dienste. Aber die Option –scale kann für diesen Zweck missbraucht werden. So kann für eine Installation mit einer externen Datenbank der folgende Befehl verwendet werden:

docker_admin> docker-compose up --detach --scale db=0

Selbstverständlich kann das selbe Ziel auch erreicht werden, indem man die Datei docker-compose/otobo-base.yml anpasst und die relevanten Service-Definitionen entfernt.

Native Installation vorbereiten

Bitte laden Sie die neueste Version von otobo-docker auf ein System herunter, das über einen Internetzugang verfügt und auf dem Docker installiert ist. Navigieren Sie dann zum folgenden Ordner otobo-docker/docker-compose.

cd otobo-docker/docker-compose

Jetzt kannst du den folgenden Befehl ausführen, um alle Docker-Images aus einer bestimmten Datei herunterzuladen, in meinem Beispiel verwende ich otobo-base.yml.

for i in $(cat otobo-base.yml| grep image:| cut -d":" -f3,4 | sed -e "s/-//1" -e"s/\}//g"); do docker pull $i; docker save $i -o $(echo $i|sed "s/\//-/g").docker; done

Danach befinden sich die Images (.docker) im Docker-Compose-Ordner und können über z.B. SCP auf das Zielsystem hochgeladen werden.

Gehe auf dem Offline-Zielsystem in den Ordner, in dem die Docker-Images gespeichert sind. Und gib den folgenden Befehl ein, um sie nacheinander zu importieren.

Im folgenden Beispiel importiere ich das mariadb-Image:

docker load --input mariadb:10.5.docker

OTOBO Docker Compose anpassen

Statt die Dateien unter docker-compose/ zu bearbeiten und das Risiko einzugehen, deine 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. Hierfür könnte man eine zusätzliche Docker-Compose-Datei erstellen, die wie folgt aussieht:

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

Nun müssen wir docker-compose mitteilen, dass unsere neue Datei eingebunden werden soll. Dazu müssen Sie Ihre YAML-Datei z.B. in die Variable COMPOSE_FILE in der .env-Datei eintragen:

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

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

$ docker-compose stop # if otobo is running
$ 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 in dem 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 ist ein Beispiel, dass das nicht sehr nützliche CPAN-Modul Acme::123 installiert.

$ docker exec -it ${COMPOSE_PROJECT_NAME:=otobo}_web_1 bash
otobo@ce36ff89e637:~$ pwd
/opt/otobo
otobo@ce36ff89e637:~$ 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
otobo@ce36ff89e637:~$

Das Schöne an diesem Ansatz ist, dass das Docker-Image selbst nicht verändert werden muss.

Zusätzliche Debian-Pakete zu installieren ist etwas aufwändiger. Sie können dazu entweder ein individuelles Dockerfile auf Grundlage des OTOBO Image erzeugen. Oder Sie erstellen das angepasste Image direkt aus einem laufenden Container heraus. Nutzen Sie dazu den Befehl docker commit – mehr dazu unter https://docs.docker.com/engine/reference/commandline/commit/. Eine gute Anleitung mit Beispielen (auf Englisch) finden Sie auch unter https://phoenixnap.com/kb/how-to-commit-changes-to-docker-image.

Für den letzteren Ansatz gibt es jedoch zwei Hürden zu überwinden. Erstens läuft das Image otobo standardmäßig als der Benutzer otobo mit der UID 1000. Das Problem ist, dass der Benutzer otobo nicht berechtigt ist, Systempakete zu installieren. Daher besteht der erste Teil der Lösung darin, beim Ausführen des Images die Option –user root zu übergeben. Die zweite Hürde ist jedoch, dass das Standard-Einstiegspunkt-Skript /opt/otobo_install/entrypoint.sh sofort beendet wird, wenn es als root aufgerufen wird. Der Grund für diese Design-Entscheidung ist, dass ein versehentlicher Aufruf als root verhindert werden soll. Der zweite Teil der Lösung besteht also darin, ein anderes Einstiegspunkt-Skript zu spezifizieren, das sich nicht darum kümmert, wer der Aufrufer ist. Dies führt zu den folgenden Beispielbefehlen, mit denen wir Glückskekse zu OTOBO hinzufügen:

Pullen Sie ein getaggtes OTOBO Image (sofern nicht bereits vorhanden), und prüfen Sie, ob im Image schon Fortune Cookies bereitgestellt werden:

$ docker run rotheross/otobo:rel-10_1_10 /usr/games/fortune
/opt/otobo_install/entrypoint.sh: line 57: /usr/games/fortune: No such file or directory

Ergänzen Sie die Fortune Cookies in einem benannten Container im originalen OTOBO Image. Dazu nutzen wir eine interaktive Session und den User root:

$ docker run -it --user root --entrypoint /bin/bash --name otobo_orig rotheross/otobo:rel-10_1_10
root@50ac203409eb:/opt/otobo# apt update
root@50ac203409eb:/opt/otobo# apt install fortunes
root@50ac203409eb:/opt/otobo# exit
$ docker ps -a | head

Erzeugen Sie ein Image auf Basis des gestoppten Containers und vergeben Sie einen Namen. Beachten Sie, dass der Standardbenutzer und das Entrypoint-Skript wiederhergestellt werden müssen:

$ docker commit -c 'USER otobo'  -c 'ENTRYPOINT ["/opt/otobo_install/entrypoint.sh"]' otobo_orig otobo_with_fortune_cookies

Schließlich prüfen wir, ob alles funktioniert hat:

$ 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 modifizierte Image kann in Ihrer .env-Datei angegeben und frei verwendet werden.

Lokale Images erstellen

Bemerkung

Lokale Docker Images werden in der Regel nur zur Entwicklung erstellt. Weitere Anwendungsfälle sind z.B. wenn aktuellere Basis Images benötigt werden oder wenn Images um zusätzliche Funktionalität erweitert werden sollen.

Die zum Erstellen lokaler Docker Images benötigten Dateien finden Sie im Git Repository unter https://github.com/RotherOSS/otobo:

  • otobo.web.dockerfile

  • otobo.nginx.dockerfile

  • otobo.elasticsearch.dockerfile

Das Script zum Erstellen der Images finden Sie unter bin/docker/build_docker_images.sh.

docker_admin> cd /opt
docker_admin> git clone https://github.com/RotherOSS/otobo.git
docker_admin> cd otobo
docker_admin> # checkout the wanted branch. e.g. git checkout rel-10_1
docker_admin> # modify the docker files if necessary
docker_admin> bin/docker/build_docker_images.sh
docker_admin> docker image ls

Lokal erstellte Images werden auf Basis der in der Datei RELEASE angegebenen Versionsdaten als local-<OTOBO_VERSION> getaggt.

Nach dem Erstellen der lokalen Images können Sie in das docker-compose Verzeichnis zurückkehren. Neu erstellte Images können mit den entsprechenden Vorgaben in OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX in .env ausgewählt werden.

Automatische Installation

Anstatt die URL http://yourIPorFQDN/otobo/installer.pl zu verwenden, können Sie auch eine Abkürzung wählen. Diese Möglichkeit eignet sich besonders, um die Testsuite auf einem frisch installierten System laufen zu lassen.

Warnung

docker-compose down -v löscht alle vorhandenen Einstellungen und Daten.

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

Einige nützliche Befehle

Docker

  • docker system prune -a Systembereinigung (entfernt alle unbenutzten Images, Container, Volumes, Netzwerke)

  • docker version Version anzeigen

  • docker build --tag otobo --file=otobo.web.Dockerfile . Image erstellen

  • docker run --publish 80:5000 otobo Neues Image ausführen

  • docker run -it -v opt_otobo:/opt/otobo otobo bash Login auf neuem Image

  • docker run -it -v opt_otobo:/opt/otobo --entrypoint bash otobo falls das Skript entrypoint.sh nicht funktioniert

  • docker ps Laufende Images anzeigen

  • docker images Verfügbare Images anzeigen

  • docker volume ls Volumes auflisten

  • docker volume inspect otobo_opt_otobo Informationen über ein Volume ausgeben

  • docker volume inspect --format '{{ .Mountpoint }}' otobo_nginx_ssl Volume Mountpoint ausgeben

  • docker volume rm tmp_volume Volume entfernen

  • docker inspect <container> Informationen zu einem Container anzeigen

  • docker save --output otobo.tar otobo:latest-10_1 && tar -tvf otobo.tar Listet Dateien in einem Image auf

  • docker exec -it nginx-server nginx -s reload nginx-Reload

Docker Compose

  • docker-compose config Informationen zur Konfiguration anzeigen

  • docker-compose ps Informationen zu laufenden Containern anzeigen

  • docker-compose exec nginx nginx -s reload nginx-Reload

Ressourcen

Zum Schluss noch eine höchst subjektive Linksammlung.

Grundsätzliche Informationen und Tutorials

Tips und Hinweise

Fehlersuche