Instalación avanzada de OTOBO con Docker Compose

Esta sección ofrece algunas perspectivas técnicas adicionales sobre lo que sucede bajo el capó.

::: version Lista de contenedores Docker; 10+ Container otobo_web_1 : Servidor web OTOBO en el puerto interno 5000.

Container otobo_daemon_1 : Demonio de OTOBO. El demonio de OTOBO se inicia y se verifica periódicamente.

Container otobo_db_1 : Ejecuta la base de datos MariaDB en el puerto interno 3306.

Container otobo_elastic_1 : Elasticsearch en los puertos internos 9200 y 9300.

Container otobo_redis_1 : Ejecuta Redis como servicio de caché.

Optional Container otobo_nginx_1 : Ejecuta nginx como reverse proxy para proporcionar soporte HTTPS. :::

::: version Lista de contenedores Docker; 11 Container otobo-web-1 : Servidor web OTOBO en el puerto interno 5000.

Container otobo-daemon-1 : Demonio de OTOBO. El demonio de OTOBO se inicia y se verifica periódicamente.

Container otobo-db-1 : Ejecuta la base de datos MariaDB en el puerto interno 3306.

Container otobo-elastic-1 : Elasticsearch en los puertos internos 9200 y 9300.

Container otobo-redis-1 : Ejecuta Redis como servicio de caché.

Optional Container otobo-nginx-1 : Ejecuta nginx como reverse proxy para proporcionar soporte HTTPS. :::

Resumen de los volúmenes de Docker

Los volúmenes de Docker se crean en el host para datos persistentes. Estos permiten iniciar y detener los servicios sin pérdida de datos. Tenga en cuenta que los contenedores son temporales y solo los datos en los volúmenes son permanentes.

otobo_opt_otobo : contiene /opt/otobo en los contenedores web y daemon.

otobo_mariadb_data : contiene /var/lib/mysql en el contenedor db.

otobo_elasticsearch_data : contiene /usr/share/elasticsearch/data en el contenedor elastic.

otobo_redis_data : contiene datos para el contenedor redis.

otobo_nginx_ssl : contiene los archivos TLS, certificado y clave privada; debe inicializarse manualmente.

Variables de entorno de Docker

En las instrucciones realizamos solo una configuración mínima. Pero el archivo .env permite establecer más variables. Aquí hay una breve lista de las variables de entorno más importantes. Tenga en cuenta que las imágenes base admiten más variables de entorno.

Configuración de MariaDB

OTOBO_DB_ROOT_PASSWORD : La contraseña de root para MariaDB. Esta configuración es necesaria para operar el servicio db.

Configuración de Elasticsearch

Elasticsearch requiere algunas configuraciones para entornos productivos. Por favor, lea https://www.elastic.co/guide/en/elasticsearch/reference/7.8/docker.html#docker-prod-prerequisites para obtener información detallada.

OTOBO_Elasticsearch_ES_JAVA_OPTS : Ejemplo de configuración: OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m Por favor, ajuste este valor hasta 4g para entornos de producción.

Configuración del servidor web

OTOBO_WEB_HTTP_PORT : Establezca este valor si el puerto HTTP debe ser diferente del puerto estándar 80. Si HTTPS está activado, el puerto HTTP se redirigirá a HTTPS.

Configuración del proxy web Nginx : Estas configuraciones se utilizan cuando HTTPS está activado.

OTOBO_WEB_HTTP_PORT : Establezca este valor si el puerto HTTP debe ser diferente del puerto estándar 80. Se redirigirá a HTTPS.

OTOBO_WEB_HTTPS_PORT : Establezca este valor si el puerto HTTPS debe ser diferente del puerto estándar 443.

OTOBO_NGINX_SSL_CERTIFICATE : Certificado SSL para el proxy web Nginx. Ejemplo: OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/acme.crt

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Clave SSL para el proxy web Nginx. Ejemplo: OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/acme.key

Configuración del proxy web Nginx para Kerberos : Estas configuraciones son utilizadas por Nginx cuando se usa Kerberos para Single Sign-On.

OTOBO_NGINX_KERBEROS_KEYTAB : Archivo keytab de Kerberos. El valor predeterminado es /etc/krb5.keytab.

OTOBO_NGINX_KERBEROS_CONFIG : Archivo de configuración de Kerberos. El valor predeterminado es /etc/krb5.conf, normalmente generado a partir de krb5.conf.template.

OTOBO_NGINX_KERBEROS_SERVICE_NAME : Nombre del servicio Kerberos. No está claro dónde se utiliza realmente esta configuración.

OTOBO_NGINX_KERBEROS_REALM : REALM de Kerberos. Utilizado en /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_KDC : kdc de Kerberos / Controlador AD. Utilizado en /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_ADMIN_SERVER : Servidor de administración de Kerberos. Utilizado en /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_DEFAULT_DOMAIN : Dominio predeterminado de Kerberos. Utilizado en /etc/krb5.conf.

NGINX_ENVSUBST_TEMPLATE_DIR : Proporciona un directorio de plantillas de configuración de Nginx personalizado. Ofrece flexibilidad adicional.

Configuración de Docker Compose : Estas configuraciones son utilizadas directamente por Docker Compose.

COMPOSE_PROJECT_NAME : El nombre del proyecto se utiliza como prefijo para los volúmenes y contenedores. Por defecto, este prefijo está establecido en otobo, lo que resulta en nombres de contenedores como otobo_web_1 y otobo_db_1. Cambie este nombre si desea ejecutar más de una instancia de OTOBO en el mismo servidor.

COMPOSE_PATH_SEPARATOR : Separador para el valor de COMPOSE_FILE.

COMPOSE_FILE : Utilice docker-compose/otobo-base.yml como base y añada los archivos de extensión deseados. Por ejemplo, docker-compose/otobo-override-http.yml o docker-compose/otobo-override-https.yml.

OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX, ... : Utilizado para la especificación de imágenes Docker alternativas. Útil para probar builds locales o para usar versiones actualizadas de las imágenes.

Configuración personalizada del proxy web Nginx

El contenedor otobo_nginx_1 proporciona soporte HTTPS ejecutando Nginx como reverse proxy. La imagen Docker que se ejecuta en el contenedor consiste en la imagen oficial de Nginx, https://hub.docker.com/_/nginx, junto con una configuración de Nginx específica de OTOBO. La configuración predeterminada específica de OTOBO se encuentra dentro de la imagen Docker en /etc/nginx/template/otobo_nginx.conf.template. De hecho, se trata solo de una plantilla para la configuración final. Existe un proceso proporcionado por la imagen base de Nginx que reemplaza las macros en la plantilla con las variables de entorno correspondientes. Este proceso se ejecuta cuando el contenedor se inicia. En el archivo de plantilla predeterminado se utilizan las siguientes macros:

OTOBO_NGINX_SSL_CERTIFICATE : Para configurar SSL.

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Para configurar SSL.

OTOBO_NGINX_WEB_HOST : El host HTTP utilizado internamente.

OTOBO_NGINX_WEB_PORT : El puerto HTTP utilizado internamente.

Consulte el paso [4.] para el uso de esta opción de configuración para configurar el certificado SSL.

Si las macros estándar no son suficientes, la personalización puede ir más allá. Esto se puede lograr reemplazando la plantilla de configuración predeterminada por una versión personalizada. Es una buena práctica no modificar la configuración simplemente en el contenedor en ejecución. En estos comandos de ejemplo, utilizamos la plantilla existente como punto de partida.

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

Añada la siguiente línea al archivo docker-compose/otobo-override-https.yml:

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

Para ello, puede utilizar su editor de texto favorito con Putty o WinSCP.

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

Ahora puede editar el archivo /opt/otobo-docker/nginx/otobo_nginx.conf. Para aplicar los cambios, los contenedores deben reiniciarse:

docker-compose up -d --build

Single Sign-On con soporte Kerberos en Nginx

Para activar la autenticación con Kerberos, base su archivo .env en el archivo de ejemplo .docker_compose_env_https_kerberos. Esto activa la configuración especial en docker-compose/otobo-override-https-kerberos.yml. Este archivo de configuración de Docker Compose selecciona una imagen de Nginx que admite Kerberos. También pasa algunas configuraciones específicas de Kerberos como valores de entorno al contenedor Nginx en ejecución. Estas configuraciones se enumeran arriba. Como es habitual, los valores para estas configuraciones se pueden especificar en el archivo .env. La mayoría de estas configuraciones se utilizan como valores de reemplazo para la plantilla https://github.com/RotherOSS/otobo/blob/rel-10_1/scripts/nginx/kerberos/templates/krb5.conf.template. El reemplazo tiene lugar durante el inicio del contenedor. En el contenedor en ejecución, la configuración personalizada está disponible en /etc/krb5.conf. Proporcionar un archivo /etc/krb5.conf personalizado sigue siendo posible. Esto se puede hacer montando un volumen que sobrescriba /etc/krb5.conf en el contenedor. Esto se puede lograr estableciendo OTOBO_NGINX_KERBEROS_CONFIG en el archivo .env y activando la directiva de montaje en docker-compose/otobo-override-https-kerberos.yml. /etc/krb5.keytab es siempre específico de la instalación y, por lo tanto, siempre debe montarse desde el sistema host. Guía de instalación de Kerberos SSO sso-kerberos

Selección de puertos no estándar

Por defecto, los puertos 443 y 80 sirven HTTPS y HTTP respectivamente. Puede haber casos en los que uno o ambos puertos ya estén siendo utilizados por otros servicios. En estos casos, los puertos estándar pueden sobrescribirse especificando OTOBO_WEB_HTTP_PORT y OTOBO_WEB_HTTPS_PORT en el archivo .env.

Omitir el inicio de servicios específicos

La configuración actual de Docker Compose inicia cinco servicios, seis si HTTPS está activado. Sin embargo, existen casos de uso válidos en los que uno o más de estos servicios no son necesarios. El ejemplo principal es cuando la base de datos no debe operarse como un servicio Docker, sino como una base de datos externa.

docker-compose up -d web nginx daemon redis elastic

Por supuesto, el mismo objetivo también se puede lograr editando el archivo docker-compose/otobo-base.yml y eliminando las definiciones de servicio relevantes.

Personalización de OTOBO Docker Compose

En lugar de editar los archivos en docker-compose/ y correr el riesgo de sobrescribir sus propias opciones con la próxima actualización de la carpeta otobo-docker, es aconsejable crear un archivo YAML adicional en el que se sobrescriban los servicios específicos con opciones adicionales. Un ejemplo común sería hacer que el contenedor de la base de datos sea accesible desde el exterior a través del puerto 3306. Para ello, podría crear un archivo Docker Compose adicional que se vea así:

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

Ahora debemos decirle a docker-compose que incluya nuestro nuevo archivo. Para ello, debe añadir su archivo YAML a la variable COMPOSE_FILE en el archivo .env, por ejemplo:

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

Ahora podemos usar docker-compose para recrear nuestros contenedores:

docker-compose stop
docker-compose up -d

Con este procedimiento puede personalizar cualquier servicio o volumen.

Personalización de la imagen Docker de OTOBO

Muchas personalizaciones se pueden realizar en el volumen externo otobo_opt_otobo, que corresponde al directorio /opt/otobo en la imagen Docker. Esto funciona, por ejemplo, para módulos Perl locales que pueden instalarse en /opt/otobo/local. Aquí hay un ejemplo que instala el módulo CPAN Acme::123, que no es muy útil.

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

Lo bueno de este enfoque es que la imagen Docker en sí no necesita ser modificada. Instalar paquetes Debian adicionales es un poco más complicado. Un enfoque es crear un Dockerfile personalizado y utilizar la imagen de OTOBO como imagen base. Otro enfoque consiste en crear una imagen modificada directamente a partir de un contenedor en ejecución. Esto se puede hacer con el comando docker commit, https://docs.docker.com/engine/reference/commandline/commit/. Puede encontrar una buena descripción de este proceso en https://phoenixnap.com/kb/how-to-commit-changes-to-docker-image. Para este último enfoque hay dos obstáculos que superar. Primero, la imagen otobo se ejecuta por defecto como usuario otobo con el UID 1000. El problema es que el usuario otobo no tiene permiso para instalar paquetes del sistema. Así que la primera parte de la solución es usar la opción --user root cuando se inicia la imagen. El segundo obstáculo es que el script de entrada predeterminado /opt/otobo_install/entrypoint.sh termina inmediatamente si se llama como root. La razón detrás de esta decisión de diseño es evitar la ejecución accidental como root. La segunda parte de la solución es, por lo tanto, especificar un script de entrada diferente al que no le importe quién sea el llamador. Con esto llegamos a los siguientes comandos de ejemplo, donde añadimos Fortune Cookies a otobo: Descargue una imagen de OTOBO etiquetada, en caso de que aún no la tengamos, y verifique si la imagen ya proporciona 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

Añada Fortune Cookies a un contenedor con nombre que ejecute la imagen original de OTOBO. Esto se hace en una sesión interactiva como usuario 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

Cree una imagen a partir del contenedor detenido y asígnele un nombre. Tenga en cuenta que el usuario predeterminado y el script de entrada deben restaurarse: Finalmente, podemos 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

La imagen modificada se puede especificar en su archivo .env y luego utilizarse para diversión y beneficio.

Crear imágenes locales

::: info La creación local de imágenes Docker suele ser necesaria solo durante el desarrollo. Otros casos de uso son cuando se deben utilizar imágenes base más actuales para una instalación o cuando se deben añadir funcionalidades adicionales a las imágenes. ::: Los archivos Docker necesarios para crear imágenes Docker localmente son parte del repositorio git https://github.com/RotherOSS/otobo:

otobo.web.dockerfile
otobo.nginx.dockerfile
otobo.elasticsearch.dockerfile El script para la creación real de las imágenes es bin/docker/build_docker_images.sh.

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

Cambie a la rama deseada, p. ej.

git checkout rel-10_0_11

cd otobo

Modifique los archivos Docker si es necesario

bin/docker/build_docker_images.sh
docker image ls

Las imágenes Docker creadas localmente se etiquetan como local-<OTOBO_VERSION>, utilizando la versión del archivo RELEASE. Después de crear las imágenes locales, puede volver al directorio docker-compose. Las imágenes locales se declaran estableciendo OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX en .env.

Instalación automática

En lugar de realizar el proceso a través de http://yourIPorFQDN/otobo/installer.pl, se puede tomar un atajo. Esto es útil para ejecutar la suite de pruebas en una instalación nueva. ::: warning docker-compose down -v eliminará todas las configuraciones y datos anteriores. :::

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

Lista de comandos útiles

Docker

docker system prune -a Limpieza del sistema (elimina todas las imágenes, contenedores, volúmenes y redes no utilizados)
docker version Muestra la versión
y muchos otros comandos útiles de Docker.

Docker Compose

docker-compose config Verifica y muestra la configuración
docker-compose ps Muestra los contenedores en ejecución
y otros comandos útiles de Docker Compose.