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 comme service de mise en cache.

Conteneur optionnel otobo_nginx_1 : Exécute nginx comme proxy inverse 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 comme service de mise en cache.

Conteneur optionnel otobo-nginx-1 : Exécute nginx comme proxy inverse pour fournir la prise en charge HTTPS. :::

Vue d'ensemble des volumes Docker

Les volumes Docker sont créés sur l'hôte pour les données persistantes. Ceux-ci permettent de démarrer et d'arrêter les services sans perte de données. Notez que les conteneurs sont temporaires et seules les données dans les volumes sont permanentes. otobo_opt_otobo : contient /opt/otobo dans le conteneur 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, certificat et clé privée, doit être initialisé manuellement.

Variables d'environnement Docker

Dans les instructions, nous n'avons effectué qu'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 plus 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 quelques 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 : Paramètre d'exemple : OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m Veuillez ajuster cette valeur pour les environnements de production jusqu'à 4g.

Paramètres du serveur Web

OTOBO_WEB_HTTP_PORT : Définissez cette valeur si le port HTTP doit différer du port par défaut 80. Si HTTPS est activé, le port HTTP sera 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 différer du port par défaut 80. Sera redirigé vers HTTPS.

OTOBO_WEB_HTTPS_PORT : Définissez cette valeur si le port HTTPS doit différer du port par défaut 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 l'authentification unique.

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 se traduit par des noms de conteneurs tels que otobo_web_1 et otobo_db_1. Modifiez ce nom si vous souhaitez exécuter 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 comme proxy inverse. L'image Docker qui s'exécute dans le conteneur est composée de l'image Docker Nginx officielle, 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 du modèle par les variables d'environnement correspondantes. Ce processus est exécuté au démarrage du conteneur. Dans le fichier modèle par défaut, les macros suivantes sont utilisées :

OTOBO_NGINX_SSL_CERTIFICATE : Pour configurer SSL.

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Pour configurer 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 utiliser cette possibilité de configuration pour 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 simplement la configuration dans le conteneur en cours d'exécution. Dans ces commandes d'exemple, 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 au 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 que les modifications prennent effet, les conteneurs doivent être redémarrés :

docker-compose up -d --build

Authentification unique avec la prise en charge Kerberos dans Nginx

Pour activer l'authentification Kerberos, veuillez baser votre fichier .env sur le fichier d'exemple .docker_compose_env_https_kerberos. Cela activera 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 modifiée dans /etc/krb5.conf sera alors disponible. La fourniture d'un fichier /etc/krb5.conf spécifique à l'utilisateur est toujours possible. 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. Instructions d'installation SSO Kerberossso-kerberos

Sélection de ports non standard

Par défaut, les ports 443 et 80 servent respectivement HTTPS et HTTP. Il peut arriver qu'un ou les deux de ces ports soient 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 services spécifiques

La configuration actuelle de Docker Compose démarre cinq, six si HTTPS est activé, services. 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 exécutée comme un service Docker mais comme une 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 service pertinentes.

Personnalisation de Docker Compose OTOBO

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 cela, 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 informer 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 peu utile Acme::123.

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

La beauté 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 peut être trouvée 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 se termine immédiatement s'il est appelé en tant que root. La raison de 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 script d'entrée différent qui ne se soucie pas de qui est l'appelant. Cela nous amène aux commandes d'exemple suivantes, 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é exécutant l'image OTOBO d'origine. 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 et utilisée ensuite 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 doivent ê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

Changez pour la branche souhaitée. par exemple

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 comme local-<OTOBO_VERSION>, où la version est utilisée à partir du fichier RELEASE. Une fois les images locales créées, vous pouvez 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, vous pouvez 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 de nombreuses 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.