Installation avancée d'OTOBO avec Docker Compose

Installation avancée d’OTOBO avec Docker Compose

Cette section donne quelques aperçus techniques supplémentaires sur ce qui se passe en coulisses.

::: version Liste des conteneurs Docker ; 10+ Conteneur otobo_web_1 : Serveur web OTOBO sur le port interne 5000.

Conteneur otobo_daemon_1 : Démon OTOBO. Le démon OTOBO est démarré et vérifié périodiquement.

Conteneur otobo_db_1 : Exécute la base de données MariaDB sur le port interne 3306.

Conteneur otobo_elastic_1 : Elasticsearch sur les ports internes 9200 et 9300.

Conteneur otobo_redis_1 : Exécute Redis en tant que service de cache.

Conteneur optionnel otobo_nginx_1 : Exécute nginx en tant que reverse-proxy pour fournir la prise en charge HTTPS. :::

::: version Liste des conteneurs Docker ; 11 Conteneur otobo-web-1 : Serveur web OTOBO sur le port interne 5000.

Conteneur otobo-daemon-1 : Démon OTOBO. Le démon OTOBO est démarré et vérifié périodiquement.

Conteneur otobo-db-1 : Exécute la base de données MariaDB sur le port interne 3306.

Conteneur otobo-elastic-1 : Elasticsearch sur les ports internes 9200 et 9300.

Conteneur otobo-redis-1 : Exécute Redis en tant que service de cache.

Conteneur optionnel otobo-nginx-1 : Exécute nginx en tant que reverse-proxy pour fournir la prise en charge HTTPS. :::

Aperçu des volumes Docker

Les volumes Docker sont créés sur l’hôte pour les données persistantes. Ils permettent de démarrer et d’arrêter les services sans perte de données. Notez que les conteneurs sont temporaires et que seules les données dans les volumes sont permanentes. otobo_opt_otobo : contient /opt/otobo dans les conteneurs web et daemon.

otobo_mariadb_data : contient /var/lib/mysql dans le conteneur db.

otobo_elasticsearch_data : contient /usr/share/elasticsearch/data dans le conteneur elastic.

otobo_redis_data : contient les données pour le conteneur redis.

otobo_nginx_ssl : contient les fichiers TLS, le certificat et la clé privée, doit être initialisé manuellement.

Variables d’environnement Docker

Dans les instructions, nous avons effectué une configuration minimale. Mais le fichier .env permet de définir plus de variables. Voici une courte liste des variables d’environnement les plus importantes. Notez que les images de base prennent en charge davantage de variables d’environnement.

Paramètres MariaDB

OTOBO_DB_ROOT_PASSWORD : Le mot de passe root pour MariaDB. Ce paramètre est nécessaire pour faire fonctionner le service db.

Paramètres Elasticsearch

Elasticsearch nécessite certains paramètres pour les environnements de production. Veuillez lire https://www.elastic.co/guide/en/elasticsearch/reference/7.8/docker.html#docker-prod-prerequisites pour des informations détaillées.

OTOBO_Elasticsearch_ES_JAVA_OPTS : Exemple de paramètre : OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m Veuillez ajuster cette valeur jusqu’à 4g pour les environnements de production.

Paramètres du serveur web

OTOBO_WEB_HTTP_PORT : Définissez cette valeur si le port HTTP doit être différent du port standard 80. Si HTTPS est activé, le port HTTP est redirigé vers HTTPS.

Paramètres du proxy web Nginx : Ces paramètres sont utilisés lorsque HTTPS est activé.

OTOBO_WEB_HTTP_PORT : Définissez cette valeur si le port HTTP doit être différent du port standard 80. Redirigé vers HTTPS.

OTOBO_WEB_HTTPS_PORT : Définissez cette valeur si le port HTTPS doit être différent du port standard 443.

OTOBO_NGINX_SSL_CERTIFICATE : Certificat SSL pour le proxy web Nginx. Exemple : OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/acme.crt

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Clé SSL pour le proxy web Nginx. Exemple : OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/acme.key

Paramètres du proxy web Nginx pour Kerberos : Ces paramètres sont utilisés par Nginx lorsque Kerberos est utilisé pour le Single Sign-On.

OTOBO_NGINX_KERBEROS_KEYTAB Fichier keytab Kerberos. La valeur par défaut est /etc/krb5.keytab.

OTOBO_NGINX_KERBEROS_CONFIG : Fichier de configuration Kerberos. La valeur par défaut est /etc/krb5.conf, généralement généré à partir de krb5.conf.template.

OTOBO_NGINX_KERBEROS_SERVICE_NAME : Nom du service Kerberos. Il n’est pas clair où ce paramètre est réellement utilisé.

OTOBO_NGINX_KERBEROS_REALM : REALM Kerberos. Utilisé dans /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_KDC : KDC Kerberos / Contrôleur AD. Utilisé dans /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_ADMIN_SERVER : Serveur d’administration Kerberos. Utilisé dans /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_DEFAULT_DOMAIN : Domaine par défaut Kerberos. Utilisé dans /etc/krb5.conf.

NGINX_ENVSUBST_TEMPLATE_DIR : Fournit un répertoire de modèles de configuration Nginx personnalisé. Offre une flexibilité supplémentaire.

Paramètres Docker Compose : Ces paramètres sont utilisés directement par Docker Compose.

COMPOSE_PROJECT_NAME : Le nom du projet est utilisé comme préfixe pour les volumes et les conteneurs. Par défaut, ce préfixe est défini sur otobo, ce qui donne des noms de conteneurs tels que otobo_web_1 et otobo_db_1. Modifiez ce nom si vous souhaitez exploiter plus d’une instance de OTOBO sur le même serveur.

COMPOSE_PATH_SEPARATOR : Séparateur pour la valeur de COMPOSE_FILE

COMPOSE_FILE : Utilisez docker-compose/otobo-base.yml comme base et ajoutez les fichiers d’extension souhaités. Par exemple, docker-compose/otobo-override-http.yml ou docker-compose/otobo-override-https.yml.

OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX, \... : Utilisé pour spécifier des images Docker alternatives. Utile pour tester des builds locaux ou pour utiliser des versions mises à jour des images.

Configuration personnalisée du proxy web Nginx

Le conteneur otobo_nginx_1 fournit la prise en charge HTTPS en exécutant Nginx en tant que reverse-proxy. L’image Docker qui s’exécute dans le conteneur se compose de l’image Docker officielle Nginx, https://hub.docker.com/_/nginx, ainsi que d’une configuration Nginx spécifique à OTOBO. La configuration par défaut spécifique à OTOBO se trouve à l’intérieur de l’image Docker sous /etc/nginx/template/otobo_nginx.conf.template. En fait, il ne s’agit que d’un modèle pour la configuration finale. Il existe un processus fourni par l’image de base Nginx qui remplace les macros dans le modèle par les variables d’environnement correspondantes. Ce processus est exécuté au démarrage du conteneur. Dans le fichier de modèle par défaut, les macros suivantes sont utilisées :

OTOBO_NGINX_SSL_CERTIFICATE : Pour la configuration SSL.

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Pour la configuration SSL.

OTOBO_NGINX_WEB_HOST : L’hôte HTTP utilisé en interne.

OTOBO_NGINX_WEB_PORT : Le port HTTP utilisé en interne.

Voir l’étape [4.] pour l’utilisation de cette option de configuration afin de configurer le certificat SSL.

Si les macros par défaut ne suffisent pas, la personnalisation peut aller plus loin. Cela peut être réalisé en remplaçant le modèle de configuration par défaut par une version personnalisée. Il est recommandé de ne pas modifier la configuration directement dans le conteneur en cours d’exécution. Dans ces exemples de commandes, nous utilisons le modèle existant comme point de départ.

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

Ajoutez la ligne suivante dans le fichier docker-compose/otobo-override-https.yml :

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

Pour ce faire, vous pouvez utiliser votre éditeur de texte préféré avec Putty ou WinSCP.

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

Maintenant, vous pouvez modifier le fichier /opt/otobo-docker/nginx/otobo_nginx.conf. Pour appliquer les modifications, les conteneurs doivent être redémarrés :

docker-compose up -d --build

Single Sign-On avec la prise en charge Kerberos dans Nginx

Pour activer l’authentification avec Kerberos, veuillez baser votre fichier .env sur l’exemple de fichier .docker_compose_env_https_kerberos. Cela active la configuration spéciale dans docker-compose/otobo-override-https-kerberos.yml. Ce fichier de configuration Docker Compose sélectionne une image Nginx qui prend en charge Kerberos. Il transmet également certains paramètres spécifiques à Kerberos en tant que valeurs d’environnement au conteneur Nginx en cours d’exécution. Ces paramètres sont listés ci-dessus. Comme d’habitude, les valeurs de ces paramètres peuvent être spécifiées dans le fichier .env. La plupart de ces paramètres sont utilisés comme valeurs de remplacement pour le modèle https://github.com/RotherOSS/otobo/blob/rel-10_1/scripts/nginx/kerberos/templates/krb5.conf.template Le remplacement a lieu pendant le démarrage du conteneur. Dans le conteneur en cours d’exécution, la configuration personnalisée est alors disponible dans /etc/krb5.conf. Il est toujours possible de fournir un fichier /etc/krb5.conf personnalisé. Cela peut être fait en montant un volume qui remplace /etc/krb5.conf dans le conteneur. Cela peut être réalisé en définissant OTOBO_NGINX_KERBEROS_CONFIG dans le fichier .env et en activant la directive de montage dans docker-compose/otobo-override-https-kerberos.yml. /etc/krb5.keytab est toujours spécifique à l’installation et doit donc toujours être monté depuis le système hôte. Guide d’installation Kerberos SSO sso-kerberos

Choix de ports non standard

Par défaut, les ports 443 et 80 servent respectivement HTTPS et HTTP. Il peut y avoir des cas où l’un ou les deux ports sont déjà utilisés par d’autres services. Dans ces cas, les ports par défaut peuvent être remplacés en spécifiant OTOBO_WEB_HTTP_PORT et OTOBO_WEB_HTTPS_PORT dans le fichier .env.

Ignorer le démarrage de certains services

La configuration Docker Compose actuelle démarre cinq services, six si HTTPS est activé. Il existe cependant des cas d’utilisation valides où un ou plusieurs de ces services ne sont pas nécessaires. L’exemple principal est lorsque la base de données ne doit pas être exploitée en tant que service Docker, mais en tant que base de données externe.

docker-compose up -d web nginx daemon redis elastic

Bien sûr, le même objectif peut être atteint en modifiant le fichier docker-compose/otobo-base.yml et en supprimant les définitions de services pertinentes.

Personnalisation de OTOBO Docker Compose

Au lieu de modifier les fichiers sous docker-compose/ et de risquer d’écraser vos propres options lors de la prochaine mise à jour du dossier otobo-docker, il est conseillé de créer un fichier YAML supplémentaire dans lequel les services spécifiques sont remplacés par des options supplémentaires. Un exemple courant serait de rendre le conteneur de base de données accessible de l’extérieur via le port 3306. Pour ce faire, vous pourriez créer un fichier Docker Compose supplémentaire qui ressemble à ceci :

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

Maintenant, nous devons dire à docker-compose d’inclure notre nouveau fichier. Pour ce faire, vous devez ajouter votre fichier YAML à la variable COMPOSE_FILE dans le fichier .env, par exemple :

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

Maintenant, nous pouvons utiliser docker-compose pour recréer nos conteneurs :

docker-compose stop
docker-compose up -d

Avec cette procédure, vous pouvez personnaliser n’importe quel service ou volume.

Personnalisation de l’image Docker OTOBO

De nombreuses personnalisations peuvent être effectuées dans le volume externe otobo_opt_otobo, qui correspond au répertoire /opt/otobo dans l’image Docker. Cela fonctionne par exemple pour les modules Perl locaux qui peuvent être installés dans /opt/otobo/local. Voici un exemple qui installe le module CPAN Acme::123, qui n’est pas très utile.

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

L’avantage de cette approche est que l’image Docker elle-même n’a pas besoin d’être modifiée. L’installation de paquets Debian supplémentaires est un peu plus délicate. Une approche consiste à créer un Dockerfile personnalisé et à utiliser l’image OTOBO comme image de base. Une autre approche consiste à créer une image modifiée directement à partir d’un conteneur en cours d’exécution. Cela peut être fait avec la commande docker commit, https://docs.docker.com/engine/reference/commandline/commit/. Une bonne description de ce processus se trouve sur https://phoenixnap.com/kb/how-to-commit-changes-to-docker-image. Pour cette dernière approche, il y a deux obstacles à surmonter. Premièrement, l’image otobo s’exécute par défaut en tant qu’utilisateur otobo avec l’UID 1000. Le problème est que l’utilisateur otobo n’est pas autorisé à installer des paquets système. La première partie de la solution consiste donc à utiliser l’option --user root lors du démarrage de l’image. Le deuxième obstacle est que le script d’entrée par défaut /opt/otobo_install/entrypoint.sh s’arrête immédiatement s’il est appelé en tant que root. La réflexion derrière cette décision de conception est d’éviter une exécution accidentelle en tant que root. La deuxième partie de la solution consiste donc à spécifier un autre script d’entrée qui ne se soucie pas de savoir qui est l’appelant. Cela nous amène aux exemples de commandes suivants, où nous ajoutons des Fortune Cookies à otobo : Récupérez une image OTOBO taguée si nous ne l’avons pas encore, et vérifiez si l’image fournit déjà des Fortune Cookies :

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

Ajoutez des Fortune Cookies à un conteneur nommé qui exécute l’image OTOBO originale. Cela se fait dans une session interactive en tant qu’utilisateur 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

Créez une image à partir du conteneur arrêté et donnez-lui un nom. Notez que l’utilisateur par défaut et le script d’entrée doivent être restaurés : Enfin, nous pouvons vérifier :

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

L’image modifiée peut être définie dans votre fichier .env puis utilisée pour le plaisir et le profit.

Création d’images locales

::: info La création locale d’images Docker n’est généralement nécessaire que pendant le développement. D’autres cas d’utilisation sont lorsque des images de base plus récentes devraient être utilisées pour une installation ou lorsque des fonctionnalités supplémentaires doivent être ajoutées aux images. ::: Les fichiers Docker nécessaires à la création locale d’images Docker font partie du dépôt git https://github.com/RotherOSS/otobo :

• otobo.web.dockerfile
• otobo.nginx.dockerfile
• otobo.elasticsearch.dockerfile Le script pour la création réelle des images est bin/docker/build_docker_images.sh.

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

Passez à la branche souhaitée, par ex.

git checkout rel-10_0_11

cd otobo

Modifiez les fichiers Docker si nécessaire

bin/docker/build_docker_images.sh
docker image ls

Les images Docker créées localement sont taguées en tant que local-<OTOBO_VERSION>, où la version est extraite du fichier RELEASE. Une fois les images locales créées, on peut revenir au répertoire docker-compose. Les images locales sont déclarées en définissant OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX dans .env.

Installation automatique

Au lieu d’effectuer le processus via http://yourIPorFQDN/otobo/installer.pl, on peut prendre un raccourci. C’est utile pour exécuter la suite de tests sur une installation fraîche. ::: warning docker-compose down -v supprimera toutes les configurations et données précédentes. :::

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 des commandes utiles

Docker

• docker system prune -a Nettoyage du système (supprime toutes les images, conteneurs, volumes, réseaux inutilisés)
• docker version Affiche la version
• et bien d’autres commandes Docker utiles.

Docker Compose

• docker-compose config Vérifie et affiche la configuration
• docker-compose ps Affiche les conteneurs en cours d’exécution
• et d’autres commandes Docker Compose utiles.