Installazione avanzata di OTOBO con Docker Compose

Questa sezione fornisce ulteriori informazioni tecniche su ciò che avviene sotto il cofano.

::: version Elenco dei contenitori Docker; 10+ Contenitore otobo_web_1 : Server web OTOBO sulla porta interna 5000.

Contenitore otobo_daemon_1 : Demone OTOBO. Il demone OTOBO viene avviato e controllato periodicamente.

Contenitore otobo_db_1 : Esegue il database MariaDB sulla porta interna 3306.

Contenitore otobo_elastic_1 : Elasticsearch sulle porte interne 9200 e 9300.

Contenitore otobo_redis_1 : Esegue Redis come servizio di caching.

Contenitore opzionale otobo_nginx_1 : Esegue nginx come proxy inverso per fornire supporto HTTPS. :::

::: version Elenco dei contenitori Docker; 11 Contenitore otobo-web-1 : Server web OTOBO sulla porta interna 5000.

Contenitore otobo-daemon-1 : Demone OTOBO. Il demone OTOBO viene avviato e controllato periodicamente.

Contenitore otobo-db-1 : Esegue il database MariaDB sulla porta interna 3306.

Contenitore otobo-elastic-1 : Elasticsearch sulle porte interne 9200 e 9300.

Contenitore otobo-redis-1 : Esegue Redis come servizio di caching.

Contenitore opzionale otobo-nginx-1 : Esegue nginx come proxy inverso per fornire supporto HTTPS. :::

Panoramica dei volumi Docker

I volumi Docker vengono creati sull'host per i dati persistenti. Questo consente di avviare e arrestare i servizi senza perdita di dati. Nota che i contenitori sono temporanei e solo i dati nei volumi sono permanenti.

otobo_opt_otobo : contiene /opt/otobo nei contenitori web e daemon.

otobo_mariadb_data : contiene /var/lib/mysql nel contenitore db.

otobo_elasticsearch_data : contiene /usr/share/elasticsearch/data nel contenitore elastic.

otobo_redis_data : contiene i dati per il contenitore redis.

otobo_nginx_ssl : contiene i file TLS, certificato e chiave privata; deve essere inizializzato manualmente.

Variabili d'ambiente Docker

Nelle istruzioni abbiamo effettuato solo una configurazione minima. Tuttavia, il file .env consente di impostare ulteriori variabili. Di seguito una breve lista delle principali variabili d'ambiente. Nota che le immagini base supportano ulteriori variabili d'ambiente.

Impostazioni MariaDB

OTOBO_DB_ROOT_PASSWORD : La password root per MariaDB. Questa impostazione è necessaria per far funzionare il servizio db.

Impostazioni Elasticsearch

Elasticsearch richiede alcune configurazioni per ambienti produttivi. Consulta https://www.elastic.co/guide/en/elasticsearch/reference/7.8/docker.html#docker-prod-prerequisites per informazioni dettagliate.

OTOBO_Elasticsearch_ES_JAVA_OPTS : Esempio: OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m. Adatta questo valore fino a 4g per ambienti di produzione.

Impostazioni del server web

OTOBO_WEB_HTTP_PORT : Imposta questo valore se la porta HTTP deve differire dalla porta standard 80. Se HTTPS è attivo, la porta HTTP viene reindirizzata su HTTPS.

Impostazioni del proxy web Nginx : Queste impostazioni vengono utilizzate quando HTTPS è abilitato.

OTOBO_WEB_HTTP_PORT : Imposta questo valore se la porta HTTP differisce dalla porta standard 80. Viene reindirizzata su HTTPS.

OTOBO_WEB_HTTPS_PORT : Imposta questo valore se la porta HTTPS differisce dalla porta standard 443.

OTOBO_NGINX_SSL_CERTIFICATE : Certificato SSL per il proxy web Nginx. Esempio: OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/acme.crt

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Chiave SSL per il proxy web Nginx. Esempio: OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/acme.key

Impostazioni Nginx per Kerberos : Queste impostazioni vengono utilizzate da Nginx quando Kerberos è abilitato per Single Sign-On.

OTOBO_NGINX_KERBEROS_KEYTAB : File keytab Kerberos. Il valore predefinito è /etc/krb5.keytab.

OTOBO_NGINX_KERBEROS_CONFIG : File di configurazione Kerberos. Il valore predefinito è /etc/krb5.conf, solitamente generato da krb5.conf.template.

OTOBO_NGINX_KERBEROS_SERVICE_NAME : Nome del servizio Kerberos. Non è chiaro dove questa impostazione venga effettivamente utilizzata.

OTOBO_NGINX_KERBEROS_REALM : Realm Kerberos. Utilizzato in /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_KDC : KDC Kerberos / Controller AD. Utilizzato in /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_ADMIN_SERVER : Server amministrativo Kerberos. Utilizzato in /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_DEFAULT_DOMAIN : Dominio predefinito Kerberos. Utilizzato in /etc/krb5.conf.

NGINX_ENVSUBST_TEMPLATE_DIR : Fornisce una directory personalizzata per i template di configurazione Nginx. Offre maggiore flessibilità.

Impostazioni Docker Compose : Queste impostazioni vengono utilizzate direttamente da Docker Compose.

COMPOSE_PROJECT_NAME : Il nome del progetto viene usato come prefisso per volumi e contenitori. Per impostazione predefinita è otobo, risultando in nomi come otobo_web_1 e otobo_db_1. Modifica questo nome se desideri eseguire più istanze di OTOBO sullo stesso server.

COMPOSE_PATH_SEPARATOR : Separatore per il valore di COMPOSE_FILE

COMPOSE_FILE : Usa docker-compose/otobo-base.yml come base e aggiungi i file di estensione desiderati. Ad esempio docker-compose/otobo-override-http.yml o docker-compose/otobo-override-https.yml.

OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX, \... : Utilizzato per specificare immagini Docker alternative. Utile per testare build locali o usare versioni aggiornate delle immagini.

Configurazione personalizzata del proxy web Nginx

Il contenitore otobo_nginx_1 fornisce supporto HTTPS eseguendo Nginx come proxy inverso. L'immagine Docker in esecuzione si basa sull'immagine ufficiale di Nginx, https://hub.docker.com/_/nginx, integrata con una configurazione Nginx specifica per OTOBO.
La configurazione predefinita specifica per OTOBO si trova all'interno dell'immagine Docker in /etc/nginx/template/otobo_nginx.conf.template. In realtà, si tratta solo di un modello per la configurazione finale. Un processo fornito dall'immagine base di Nginx sostituisce i macro nel template con le corrispondenti variabili d'ambiente durante l'avvio del contenitore. Nel file modello predefinito vengono utilizzati i seguenti macro:

OTOBO_NGINX_SSL_CERTIFICATE : Per la configurazione SSL.

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Per la configurazione SSL.

OTOBO_NGINX_WEB_HOST : L'host HTTP interno utilizzato.

OTOBO_NGINX_WEB_PORT : La porta HTTP interna utilizzata.

Vedi il passo [4.] per l'utilizzo di questa opzione di configurazione per impostare il certificato SSL.

Se i macro predefiniti non sono sufficienti, è possibile effettuare personalizzazioni più approfondite sostituendo il modello di configurazione con una versione personalizzata. È una buona pratica non modificare direttamente la configurazione nel contenitore in esecuzione.
Nei seguenti comandi di esempio, usiamo il modello esistente come punto di partenza.

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

Aggiungi la seguente riga al file docker-compose/otobo-override-https.yml:

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

Puoi usare il tuo editor di testo preferito con Putty o WinSCP.

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

Ora puoi modificare il file /opt/otobo-docker/nginx/otobo_nginx.conf.
Per applicare le modifiche, riavvia i contenitori:

docker-compose up -d --build

Single Sign-On con supporto Kerberos in Nginx

Per abilitare l'autenticazione Kerberos, basa il tuo file .env sul file di esempio .docker_compose_env_https_kerberos. Questo attiva la configurazione speciale in docker-compose/otobo-override-https-kerberos.yml. Questo file di configurazione Docker Compose seleziona un'immagine Nginx che supporta Kerberos e passa alcune impostazioni specifiche di Kerberos come variabili d'ambiente al contenitore Nginx in esecuzione. Queste impostazioni sono elencate sopra.
Come di consueto, i valori possono essere specificati nel file .env. La maggior parte di queste impostazioni viene utilizzata come sostituzioni nel template https://github.com/RotherOSS/otobo/blob/rel-10_1/scripts/nginx/kerberos/templates/krb5.conf.template. La sostituzione avviene all'avvio del contenitore. All'interno del contenitore in esecuzione, la configurazione personalizzata sarà disponibile in /etc/krb5.conf.
È comunque possibile fornire un file /etc/krb5.conf personalizzato montando un volume che sovrascrive /etc/krb5.conf nel contenitore. Questo può essere fatto impostando OTOBO_NGINX_KERBEROS_CONFIG nel file .env e abilitando la direttiva di montaggio in docker-compose/otobo-override-https-kerberos.yml.
Il file /etc/krb5.keytab è sempre specifico dell'installazione e deve quindi essere sempre montato dal sistema host.
Guida all'installazione Kerberos SSO
sso-kerberos

Uso di porte non standard

Per impostazione predefinita, le porte 443 e 80 gestiscono rispettivamente HTTPS e HTTP. Possono esserci casi in cui una o entrambe le porte sono già utilizzate da altri servizi. In questi casi, le porte predefinite possono essere sovrascritte specificando OTOBO_WEB_HTTP_PORT e OTOBO_WEB_HTTPS_PORT nel file .env.

Saltare l'avvio di servizi specifici

L'attuale configurazione Docker Compose avvia cinque servizi, sei se HTTPS è abilitato. Tuttavia, esistono casi d'uso validi in cui uno o più di questi servizi non sono necessari. L'esempio principale è quando il database viene eseguito non come servizio Docker, ma come database esterno.

docker-compose up -d web nginx daemon redis elastic

Naturalmente, lo stesso risultato può essere ottenuto modificando il file docker-compose/otobo-base.yml e rimuovendo le definizioni dei servizi rilevanti.

Personalizzazione di OTOBO Docker Compose

Invece di modificare i file nella directory docker-compose/ e rischiare di sovrascrivere le proprie opzioni con il prossimo aggiornamento della cartella otobo-docker, è consigliabile creare un file YAML aggiuntivo in cui sovrascrivere i servizi specifici con opzioni aggiuntive.
Un esempio comune è rendere accessibile il contenitore del database dall'esterno sulla porta 3306. A tale scopo, potresti creare un file Docker Compose aggiuntivo simile al seguente:

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

Ora dobbiamo informare docker-compose di includere il nostro nuovo file. Aggiungi il tuo file YAML alla variabile COMPOSE_FILE nel file .env, ad esempio:

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

Ora possiamo usare docker-compose per ricreare i contenitori:

docker-compose stop
docker-compose up -d

Con questo metodo, puoi personalizzare qualsiasi servizio o volume.

Personalizzazione dell'immagine Docker OTOBO

Molte personalizzazioni possono essere effettuate nel volume esterno otobo_opt_otobo, corrispondente alla directory /opt/otobo nell'immagine Docker. Funziona, ad esempio, per moduli Perl locali che possono essere installati in /opt/otobo/local. Di seguito un esempio che installa il modulo CPAN Acme::123, non particolarmente 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

Il vantaggio di questo approccio è che l'immagine Docker stessa non deve essere modificata.
Installare pacchetti Debian aggiuntivi è un po' più complesso. Un approccio consiste nel creare un Dockerfile personalizzato usando l'immagine OTOBO come immagine base. Un altro approccio è creare direttamente un'immagine modificata da un contenitore in esecuzione, usando il comando docker commit (https://docs.docker.com/engine/reference/commandline/commit/). Una buona spiegazione di questo processo è disponibile su https://phoenixnap.com/kb/how-to-commit-changes-to-docker-image.
Per quest'ultimo approccio, ci sono due ostacoli da superare. Primo, l'immagine otobo viene eseguita per impostazione predefinita come utente otobo con UID 1000. Il problema è che l'utente otobo non ha i permessi per installare pacchetti di sistema. La prima parte della soluzione è quindi usare l'opzione --user root all'avvio dell'immagine.
Il secondo ostacolo è che lo script di ingresso predefinito /opt/otobo_install/entrypoint.sh termina immediatamente se eseguito come root. Questa scelta progettuale mira a evitare l'esecuzione accidentale come root. La seconda parte della soluzione è quindi specificare uno script di ingresso diverso che non controlli l'identità del chiamante. Arriviamo così ai seguenti comandi di esempio, in cui aggiungiamo a OTOBO i "fortune cookies":

Scarica un'immagine OTOBO taggata, se non ce l'hai già, e verifica se l'immagine fornisce già i 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

Aggiungi fortune cookies a un contenitore denominato che esegue l'immagine OTOBO originale. Questo avviene in una sessione interattiva come utente 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

Crea un'immagine dal contenitore arrestato e dagli un nome. Nota che l'utente predefinito e lo script di ingresso devono essere ripristinati:

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

Infine, possiamo verificarlo:

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'immagine modificata può essere impostata nel file .env e poi utilizzata per divertimento e profitto.

Creazione di immagini locali

INFO

La creazione locale di immagini Docker è solitamente necessaria solo durante lo sviluppo. Altri casi d'uso includono l'uso di immagini base più aggiornate per un'installazione o l'aggiunta di funzionalità extra alle immagini.

I file Docker necessari per creare localmente le immagini Docker fanno parte del repository git https://github.com/RotherOSS/otobo:

• otobo.web.dockerfile
• otobo.nginx.dockerfile
• otobo.elasticsearch.dockerfile

Lo script per la creazione effettiva delle immagini è bin/docker/build_docker_images.sh.

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

Passa al ramo desiderato, ad esempio:

git checkout rel-10_0_11

cd otobo

Modifica i file Docker se necessario

bin/docker/build_docker_images.sh
docker image ls

Le immagini Docker create localmente vengono taggate come local-<OTOBO_VERSION>, utilizzando la versione dal file RELEASE.
Dopo aver creato le immagini locali, puoi tornare alla directory docker-compose. Le immagini locali vengono dichiarate impostando OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX nel file .env.

Installazione automatica

Invece di eseguire il processo tramite http://yourIPorFQDN/otobo/installer.pl, puoi prendere una scorciatoia. È utile per eseguire la suite di test su una installazione fresca.

WARNING

docker-compose down -v rimuoverà tutti i setup e i dati precedenti.

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

Elenco di comandi utili

Docker

• docker system prune -a Pulizia del sistema (rimuove tutte le immagini, contenitori, volumi e reti non utilizzati)
• docker version Mostra la versione
• e molti altri comandi Docker utili.

Docker Compose

• docker-compose config Verifica e mostra la configurazione
• docker-compose ps Mostra i contenitori in esecuzione
• e altri comandi Docker Compose utili.