Instalación avanzada de OTOBO con Docker Compose

Esta sección proporciona información técnica adicional 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 OTOBO. El demonio OTOBO se inicia y se comprueba 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é.

Contenedor opcional otobo_nginx_1 : Ejecuta nginx como proxy inverso 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 OTOBO. El demonio OTOBO se inicia y se comprueba 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é.

Contenedor opcional otobo-nginx-1 : Ejecuta nginx como proxy inverso para proporcionar soporte HTTPS. :::

Visión general 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 el contenedor 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, solo hemos realizado una configuración mínima. Pero el archivo .env permite establecer más variables. Aquí hay una lista corta 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 de producción. 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 : Configuración de ejemplo: OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m Por favor, ajuste este valor para entornos de producción hasta 4g.

Configuración del servidor web

OTOBO_WEB_HTTP_PORT : Establezca este valor si el puerto HTTP debe diferir del puerto predeterminado 80. Si HTTPS está habilitado, el puerto HTTP se redirigirá a HTTPS.

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

OTOBO_WEB_HTTP_PORT : Establezca este valor si el puerto HTTP debe diferir del puerto predeterminado 80. Se redirigirá a HTTPS.

OTOBO_WEB_HTTPS_PORT : Establezca este valor si el puerto HTTPS debe diferir del puerto predeterminado 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 Kerberos se utiliza para el inicio de sesión único.

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 se establece en otobo, lo que da como resultado nombres de contenedor 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 especificar imágenes Docker alternativas. Útil para probar compilaciones 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 proxy inverso. La imagen Docker que se ejecuta en el contenedor consta de la imagen oficial de Docker de Nginx, https://hub.docker.com/_/nginx, junto con una configuración específica de OTOBO para Nginx. La configuración predeterminada específica de OTOBO se encuentra dentro de la imagen de Docker en /etc/nginx/template/otobo_nginx.conf.template. De hecho, esto es solo una plantilla para la configuración final. Hay 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 se inicia el contenedor. 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 utilizar esta opción de configuración para configurar el certificado SSL.

Si las macros predeterminadas no son suficientes, la personalización puede ir más allá. Esto se puede lograr reemplazando la plantilla de configuración predeterminada con una versión personalizada. Es una buena práctica no modificar la configuración simplemente dentro del 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

Inicio de sesión único con soporte Kerberos en Nginx

Para habilitar la autenticación con Kerberos, por favor, base su archivo .env en el archivo de ejemplo .docker_compose_env_https_kerberos. Esto habilita 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 anteriormente. Como de costumbre, los valores de estas configuraciones se pueden especificar en el archivo .env. La mayoría de estas configuraciones se utilizan como valores de sustitución para la plantilla https://github.com/RotherOSS/otobo/blob/rel-10_1/scripts/nginx/kerberos/templates/krb5.conf.template. La sustitución se realiza durante el inicio del contenedor. En el contenedor en ejecución, la configuración personalizada estará disponible en /etc/krb5.conf. Aún es posible proporcionar un archivo /etc/krb5.conf específico del usuario. 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 habilitando 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. Instrucciones de instalación de SSO con Kerberossso-kerberos

Selección de puertos no predeterminados

Por defecto, los puertos 443 y 80 sirven HTTPS y HTTP respectivamente. Puede haber casos en los que uno o ambos de estos puertos ya estén en uso por otros servicios. En estos casos, los puertos predeterminados se pueden anular 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, seis si HTTPS está habilitado, servicios. 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 ejecutarse como un servicio de Docker, sino como una base de datos externa.

docker-compose up -d web nginx daemon redis elastic

Por supuesto, el mismo objetivo 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 arriesgarse a 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 tenemos que informar a docker-compose para 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 reconstruir 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 dentro de la imagen Docker. Esto funciona, por ejemplo, para módulos Perl locales que se pueden instalar en /opt/otobo/local. Aquí hay un ejemplo que instala el módulo CPAN no muy útil 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

Lo bueno de este enfoque es que la imagen Docker en sí misma 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 es crear una imagen modificada directamente desde un contenedor en ejecución. Esto se puede hacer con el comando docker commit, https://docs.docker.com/engine/reference/commandline/commit/. Una buena descripción de este proceso se puede encontrar 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 UID 1000. El problema es que el usuario otobo no tiene los permisos para instalar paquetes del sistema. Por lo tanto, la primera parte de la solución es utilizar la opción --user root al iniciar la imagen. El segundo obstáculo es que el script de entrada predeterminado /opt/otobo_install/entrypoint.sh se sale inmediatamente si se llama como root. La consideración detrás de esta decisión de diseño es evitar la ejecución involuntaria como root. Por lo tanto, la segunda parte de la solución es especificar un script de entrada diferente que no se preocupe por quién es el llamador. Esto nos lleva a los siguientes comandos de ejemplo, donde añadimos Fortune Cookies a otobo: Descargue una imagen de OTOBO etiquetada, si aún no la tenemos, y compruebe 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 su diversión y beneficio.

Creación de imágenes locales

INFO

La creación local de imágenes Docker normalmente solo es necesaria durante el desarrollo. Otros casos de uso son cuando se deben utilizar imágenes base más recientes 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 forman 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. por ejemplo,

git checkout rel-10_0_11

cd otobo

Modifique los archivos Docker según sea necesario

bin/docker/build_docker_images.sh
docker image ls

Las imágenes Docker creadas localmente se etiquetan como local-<OTOBO_VERSION>, donde la versión se toma 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, 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, redes no utilizados)
• docker version Muestra la versión
• y muchos más comandos útiles de Docker.

Docker Compose

• docker-compose config Comprueba y muestra la configuración
• docker-compose ps Muestra los contenedores en ejecución
• y más comandos útiles de Docker Compose.