OTOBO Installation mit Docker und Docker Compose

Einleitung

OTOBO ist ein kostenfreies, umfangreiches Open-Source-Ticketsystem. In dieser Anleitung erfährst Du, wie Du OTOBO auf Ubuntu oder Debian installierst. Wir stellen Dir zwei Methoden vor: die Standardinstallation und die Docker-Installation von OTOBO. Für die Nutzung von OTOBO ist ein Server erforderlich, auf dem das Ticketsystem installiert wird. Als Betriebssysteme kommen Debian, Ubuntu, CentOS oder vergleichbare Systeme in Frage.

Hardwareanforderungen

Die Hardwareanforderungen hängen stark von der Nutzung von OTOBO ab. OTOBO kann dazu verwendet werden, ein paar Tickets pro Monat zu bearbeiten oder hunderte von Tickets pro Tag zu verarbeiten. Der Speicherbedarf hängt auch von der Anzahl der Tickets und der Größe der Anhänge ab.

Type	CPU	RAM	Speicher
Development	2 x 2 GHZ	2 GB	16 GB
Production	4 x 3 GHZ	8 GB	40 GB

OTOBO Backups

Regelmäßige Backups sind wichtig, um Datenverluste zu vermeiden. Bei der Entwicklung des OTOBO-Ticketsystems empfiehlt es sich, iterativ vorzugehen: Entwicklungen werden zunächst auf einer Entwicklungsumgebung durchgeführt und nach Fertigstellung auf das Produktionssystem übertragen, um die Ausfallwahrscheinlichkeit zu minimieren. OTOBO Backups erstellen

Otobo Hosting

Für das Hosting eines OTOBO-Servers empfehlen wir die Verwendung von Ubuntu Version 20 oder neueren Versionen. Du kannst Deinen Server bei Anbietern wie Hetzner hosten. Um den Server zu verwalten und Befehle auszuführen, ist das Programm Putty sehr nützlich. Für den Dateizugriff auf dem Server bietet sich WinSCP an. Zur Verwaltung der OTOBO-Datenbank empfehlen wir DataGrip.

Es besteht auch die Möglichkeit, OTOBO auf einem eigenen Server zu betreiben. Falls Du bereits über einen Server verfügst und keine zusätzlichen Kosten für einen neuen Server aufwenden möchtest, kannst Du OTOBO auch in einer Docker-Version installieren. Achte dabei auf die Verwendung unterschiedlicher Ports für verschiedene Anwendungen, da jeder Port nur von einer Applikation genutzt werden kann.

Server Hosting für die OTOBO Installation

Notiz

Für das Hosting des OTOBO-Ticketsystems kannst Du jeden Anbieter wählen, wobei der Server aus Datenschutzgründen (DSGVO) vorzugsweise in Deutschland stehen sollte. Der Server sollte Ubuntu 20 oder neuer betreiben, wobei auch Debian oder andere Linux-Distributionen möglich sind.

Im Folgenden zeigen wir wie man einen Server bei Hetzner hosten kann. Auf Server hinzufügen klicken.

OTOBO Ticketsystem Installation - Server Hosting - Ubuntu / Debian

Neuer Server bei Hetzner

1. Deutschen Standort wählen
2. Ubuntu 20 wählen / Debian
3. Standard wählen
4. Eine Option wählen die mindestens 4 GB RAM hat

Fertig! Erstellen. Statt Ubuntu kann man auch Debian verwenden.

Server Authentifizierung

Verwende für die Serverauthentifizierung SSH (Public-Private Key), da dies sicherer und praktikabler ist. Du kannst ein bereits vorhandenes Schlüsselpaar verwenden oder ein neues erstellen. Für zusätzliche Sicherheit kann dem Private Key eine Passphrase hinzugefügt werden. Bewahre Deinen Private Key sicher auf und teile ihn mit niemandem.

Installations-Vorbereitung

1. Standard-Installation von OTOBO
2. OTOBO-Installation mit Docker Ein Server ist für die Installation des Ticketsystems erforderlich. Du kannst entweder einen Hostinganbieter wählen oder, wie oben beschrieben, einen eigenen Server verwenden. Die Docker-Version wird von OTOBO empfohlen, da sie eine Trennung der verschiedenen Systemkomponenten (Webserver, Datenbank, Redis-Cache, Elasticsearch etc.) in separate Container ermöglicht. Diese Container laufen in einer virtuellen Umgebung mit geringen Abhängigkeiten zueinander und können leicht auf andere Server übertragen werden.

Docker Dienste

Mit der Docker-basierten OTOBO-Bereitstellung können Sie innerhalb von Minuten Ihre persönliche OTOBO-Instanz zum Laufen bringen. Alle Abhängigkeiten von OTOBO sind bereits in der bereitgestellten Sammlung von Docker-Images enthalten.

• db: MariaDB wird als Standarddatenbank eingerichtet.
• elastic: Elasticsearch wird für die OTOBO-Powersuche eingerichtet.
• redis: Redis wird für schnelles Caching aktiviert.
• web: Gazelle wird als schneller Perl-Webserver verwendet.
• nginx: Nginx wird als optionaler Reverse-Proxy für die Unterstützung von HTTPS verwendet.

Softwareanforderungen

Datenbanken

• MySQL 5.6 oder höher
• MariaDB
• PostgreSQL 9.2 oder höher
• Oracle 10g oder höher

Webbrowser

• Apple Safari
• Google Chrome
• Microsoft Edge
• Mozilla Firefox

Anforderungen

Die minimalen Versionen der erforderlichen Software, die getestet wurden, sind hier aufgelistet:

• Docker 19.03.13
• Docker Compose 1.25.0
• Git 2.17.1 Git, Docker und Docker Compose können mit den Standard-Systemtools installiert werden. Hier ist ein Beispiel für die Installation auf Ubuntu 20.04:

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

Bitte prüfen Sie die Git- und Docker-Dokumentation für weitere Einrichtungsanweisungen.

Schritt für Schritt - Installation

Die folgenden Anweisungen setzen voraus, dass alle Anforderungen erfüllt sind und dass Sie eine funktionierende Docker-Umgebung haben. Wir gehen hier davon aus, dass der Benutzer docker_admin zur Interaktion mit Docker verwendet wird. Der Docker-Admin soll ein dedizierter Benutzer mit den erforderlichen Berechtigungen sein und nicht der root Nutzer. Damit Sie die Docker-Befehle ausführen können, müssen Sie Mitglied der Gruppe docker sein. Sie können sich mit folgendem Befehl zur Docker Gruppe hinzufügen:

sudo usermod -aG docker <username>

1. Klonen des Github Repositorys

Um das OTOBO-Docker-Repository zu klonen, verwenden Sie den folgenden Befehl. Wählen Sie die Version, die Sie installieren möchten.

Notiz

Der Speicherort des geklonten Repositories spielt keine Rolle. Für diese Anleitungen haben wir /opt/otobo-docker als Arbeitsverzeichnis gewählt.

Version 10.0.XX

cd /opt
git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-10_0 --single-branch

Version 10.1.XX

cd /opt
git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-10_1 --single-branch

Version 11.0.XX

Warnung

Version 11.0 ist noch nicht offiziell veröffentlicht.

cd /opt
git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-11_0 --single-branch

2. Erstellen einer initialen .env-Datei

Die Docker Compose-Konfigurationsdatei .env ist Ihre primäre Schnittstelle zur Verwaltung Ihrer OTOBO-Installation. Diese Datei muss zuerst erstellt und dann von Ihnen angepasst werden. Um die Aufgabe zu vereinfachen, gibt es mehrere Beispieldateien, die als Ausgangspunkt verwendet werden sollten. Welche Beispieldatei am besten geeignet ist, hängt von Ihrem Anwendungsfall ab. In den meisten Fällen liegt die Entscheidung zwischen .docker_compose_env_http und .docker_compose_env_https, je nachdem, ob TLS unterstützt werden muss oder nicht. Die anderen Dateien sind für speziellere Anwendungsfälle.

.docker_compose_env_http Die OTOBO-Web-App stellt HTTP bereit.

.docker_compose_env_https Die OTOBO-Web-App stellt HTTPS bereit, indem Nginx als Reverse-Proxy-Webserver ausgeführt wird.

.docker_compose_env_https_custom_nginx Wie .docker_compose_env_https, aber mit Unterstützung für eine benutzerdefinierte Nginx-Konfiguration.

.docker_compose_env_https_kerberos Wie .docker_compose_env_https, aber mit Beispielkonfiguration für Single Sign-On. Beachten Sie, dass die Kerberos-Unterstützung noch experimentell ist.

.docker_compose_env_http_selenium und .docker_compose_env_https_selenium werden nur für die Entwicklung verwendet, wenn Selenium-Tests aktiviert sind.

Notiz

Verwenden Sie ls -a, um die versteckten Beispiel-Dateien aufzulisten.

Per Standard wird OTOBO auf den Standardports bereitgestellt. Port 443 für HTTPS und Port 80 für HTTP. Wenn HTTPS aktiviert ist, läuft die OTOBO-Webanwendung tatsächlich immer noch mit HTTP. Die Unterstützung für HTTPS wird durch einen zusätzlichen Reverse-Proxy erreicht, der als nginx-Dienst implementiert ist. Für die folgenden Befehle nehmen wir an, dass HTTPS unterstützt werden soll.

Mit HTTPS (empfohlen)

cd /opt/otobo-docker
cp -p .docker_compose_env_https .env 

Ohne HTTPS

cd /opt/otobo-docker
cp -p .docker_compose_env_http .env 

3. Konfigurieren Sie das Passwort für den Datenbank-Admin-Benutzer

Ändern Sie die folgende Einstellung in Ihrer .env-Datei: OTOBO_DB_ROOT_PASSWORD=<Ihr_geheimes_Passwort>

Das Passwort für den Datenbank-Admin-Benutzer kann frei gewählt werden. Der Datenbank-Admin-Benutzer wird benötigt, um den Datenbankbenutzer otobo und das Datenbankschema otobo zu erstellen. OTOBO wird tatsächlich den speziellen Datenbankbenutzer otobo verwenden.

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

Dieser Schritt kann übersprungen werden, wenn OTOBO nur über HTTP verfügbar sein soll. nginx benötigt für die SSL-Verschlüsselung ein Zertifikat und einen privaten Schlüssel.

Notiz

Für Tests und Entwicklung kann ein selbst signiertes Zertifikat verwendet werden. Jedoch sollten Sie für den produktiven Einsatz mit regulär registrierten Zertifikaten arbeiten.

Erhalten Sie ein SSL-Zertifikat von Let's Encrypt (optional)

Um mit Certbot ein SSL-Zertifikat auf Ubuntu als Standalone-Zertifikat zu erhalten, folge diesen Schritten:

1. Certbot installieren:
   • Öffne ein Terminal.
   • Aktualisiere die Paketliste:

sudo apt update

• Installiere Certbot und das Certbot-Standalone-Plugin mit:

  sudo apt install certbot
  

2. SSL-Zertifikat anfordern:

• Führe Certbot im Standalone-Modus aus:

sudo certbot certonly --standalone

• Befolge die Anweisungen im Terminal, um dein Domain-Name einzugeben und die Verifizierung abzuschließen.

Notiz

Der Standalone-Modus ist ideal, wenn kein Webserver läuft oder wenn du keinen direkten Zugriff auf die Webserver-Konfiguration hast. Certbot startet temporär einen Webserver auf Port 80 oder 443, um die Domain-Validierung durchzuführen.

Vergiss nicht, deine Firewall so zu konfigurieren, dass Zugriffe auf die benötigten Ports (in der Regel 80 und 443) erlaubt sind, bevor du den Certbot-Befehl ausführst.

Nach erfolgreicher Ausstellung findest du deine Zertifikatdateien unter /etc/letsencrypt/archive/deinedomain.com/. Es ist wichtig, dass du einen Prozess für die regelmäßige Erneuerung der Zertifikate einrichtest, da Let's Encrypt-Zertifikate alle 90 Tage ablaufen. Certbot bietet einen automatischen Erneuerungsprozess, den du mit

sudo certbot renew --dry-run

testen kannst, um sicherzustellen, dass die Erneuerung funktioniert.

Volume für SSL-Konfiguration einrichten

Das neu erstellte SSL-Zertifikat und der private Schlüssel müssen für den nginx-Webproxy in einem Docker-Volume bereitgestellt werden. Dafür müssen folgende Zeilen in der Datei /opt/otobo-docker/docker-compose/otobo-override-https.yml hinzugefügt werden:

    volumes:
      - /etc/letsencrypt/archive/yourdomain.com/:/etc/nginx/ssl/

Dafür kann man den nano Editor verwenden:

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

Die Namen der kopierten Dateien müssen in unserer neu erstellten .env-Datei festgelegt werden. Z.B. OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/cert1.pem und OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/privkey1.pem Bitte passen Sie nur den Namen der Dateien an, da der Pfad /etc/nginx/ssl/ im Docker-Image fest codiert ist.

nano /opt/otobo-docker/.env

5. Starten Sie die Docker-Container mit Docker Compose

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

docker-compose up --detach

Um zu überprüfen, ob die sechs erforderlichen Dienste (fünf im Falle von HTTP nur) tatsächlich laufen, geben Sie ein:

docker-compose ps
docker volume ls

6. Installieren und starten Sie OTOBO

Führen Sie den OTOBO-Installer unter http://yourIPorFQDN/otobo/installer.pl aus. Bitte konfigurieren Sie OTOBO im Installer mit einer neuen MySQL-Datenbank. Als MySQL-Datenbank-Root-Passwort verwenden Sie bitte das Passwort, das Sie in der Variablen OTOBO_DB_ROOT_PASSWORD Ihrer .env-Datei konfiguriert haben. Bitte lassen Sie den Wert db für den MySQL-Hostname unverändert.

Tips

Um in dem OTOBO-Verzeichnis, innerhalb des laufenden Containers, zu wechseln, um wie gewohnt an der Kommandozeile zu arbeiten, können Sie den folgenden Docker-Befehl verwenden: docker-compose exec web bash.

Zusätzliche technische Informationen

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

Liste der Docker-Container

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.

Fortgeschrittene Themen

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-Installationsanleitungsso-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_admin> 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

Notiz

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.

Warnung

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.::: details Welche Hardwareanforderungen gibt es für die OTOBO-Installation? Für die OTOBO-Installation gibt es verschiedene Hardwareanforderungen, abhängig von der Nutzung. Es werden spezielle Anforderungen für die Entwicklung und die Produktion bereitgestellt, die sich hinsichtlich CPU, RAM und Speicher unterscheiden. :::

Welche Methode wird für die Docker-Installation von OTOBO empfohlen?

Für die Installation von OTOBO wird die Docker-Version empfohlen, da sie eine effiziente Trennung der verschiedenen Systemkomponenten (Webserver, Datenbank, Redis-Cache, Elasticsearch etc.) in separate Container ermöglicht.

Welche Dienste sind in der Docker-basierten OTOBO-Bereitstellung enthalten?

Die Docker-basierte OTOBO-Bereitstellung enthält verschiedene Dienste wie MariaDB als Standarddatenbank, Elasticsearch für die Powersuche von OTOBO, Redis für schnelles Caching, Gazelle als schnellen Perl-Webserver und optional Nginx als Reverse-Proxy für HTTPS-Unterstützung.

Welche Softwareanforderungen gibt es für die OTOBO-Installation?

Für die OTOBO-Installation werden verschiedene Softwareanforderungen wie Docker, Docker Compose und Git aufgeführt. Es wird empfohlen, die Git- und Docker-Dokumentation für weitere Einrichtungsanweisungen zu konsultieren.

Wie kann die Docker-Installation von OTOBO in wenigen Schritten durchgeführt werden?

Die Docker-Installation von OTOBO kann in wenigen Schritten erfolgen: Zuerst wird das Github-Repository geklont, dann wird eine initiale .env-Datei erstellt, das Passwort für den Datenbank-Admin-Benutzer konfiguriert, ein Volume mit SSL-Konfiguration eingerichtet (optional), die Docker-Container mit Docker Compose gestartet und schließlich OTOBO installiert und gestartet.