Instalación avanzada de OTOBO con Docker Compose
Esta sección proporciona información técnica adicional sobre lo que ocurre bajo el capó.
::: version Lista de contenedores Docker; 10+ Contenedor otobo_web_1 : Servidor web OTOBO en el puerto interno 5000.
Contenedor otobo_daemon_1 : Daemon de OTOBO. El daemon OTOBO se inicia y se verifica periódicamente.
Contenedor otobo_db_1 : Ejecuta la base de datos MariaDB en el puerto interno 3306.
Contenedor otobo_elastic_1 : Elasticsearch en los puertos internos 9200 y 9300.
Contenedor 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 Contenedor otobo-web-1 : Servidor web OTOBO en el puerto interno 5000.
Contenedor otobo-daemon-1 : Daemon de OTOBO. El daemon OTOBO se inicia y se verifica periódicamente.
Contenedor otobo-db-1 : Ejecuta la base de datos MariaDB en el puerto interno 3306.
Contenedor otobo-elastic-1 : Elasticsearch en los puertos internos 9200 y 9300.
Contenedor 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 Docker
Los volúmenes Docker se crean en el host para datos persistentes. Esto permite 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 los datos para el contenedor redis.
otobo_nginx_ssl : contiene los archivos TLS, certificado y clave privada; debe inicializarse manualmente.
Variables de entorno Docker
En las instrucciones, solo realizamos una configuración mínima. Pero el archivo .env permite establecer más variables. A continuación, 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 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. 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 redirige 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 redirige 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 usa 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 esta configuración.
OTOBO_NGINX_KERBEROS_REALM : Dominio Kerberos. Utilizado en /etc/krb5.conf.
OTOBO_NGINX_KERBEROS_KDC : Servidor KDC / Controlador AD de Kerberos. 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 personalizado para plantillas de configuración de Nginx. Ofrece mayor flexibilidad.
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 volúmenes y contenedores. Por defecto, este prefijo es otobo, lo que da como resultado 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 agregue 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 construcciones locales o 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 se basa en la imagen oficial 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 Docker en /etc/nginx/template/otobo_nginx.conf.template. En realidad, es solo una plantilla para la configuración final. Existe un proceso proporcionado por la imagen base de Nginx que reemplaza los macros en la plantilla con las variables de entorno correspondientes. Este proceso se ejecuta al iniciar el contenedor. En el archivo de plantilla predeterminado se utilizan los siguientes macros:
OTOBO_NGINX_SSL_CERTIFICATE : Para configurar SSL.
OTOBO_NGINX_SSL_CERTIFICATE_KEY : Para configurar SSL.
OTOBO_NGINX_WEB_HOST : El host HTTP interno utilizado.
OTOBO_NGINX_WEB_PORT : El puerto HTTP interno utilizado.
Vea el paso [4.] para usar esta opción de configuración y configurar el certificado SSL.
Si los macros predeterminados no son suficientes, se puede realizar una personalización adicional. Esto se logra reemplazando la plantilla de configuración predeterminada por una versión personalizada. Es una buena práctica no modificar la configuración directamente en el contenedor en ejecución. En estos comandos de ejemplo, usamos 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.confAgregue 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.confPuede usar su editor de texto favorito con Putty o WinSCP.
nano docker-compose/otobo-override-https.ymlAhora puede editar el archivo /opt/otobo-docker/nginx/otobo_nginx.conf. Para aplicar los cambios, debe reiniciar los contenedores:
docker-compose up -d --buildSingle Sign-On con soporte Kerberos en Nginx
Para habilitar la autenticación 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 Docker Compose selecciona una imagen Nginx que soporta Kerberos y también pasa algunas configuraciones específicas de Kerberos como variables de entorno al contenedor Nginx en ejecución. Estas configuraciones se enumeran anteriormente. 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 ocurre durante el inicio del contenedor. En el contenedor en ejecución, la configuración adaptada está disponible en /etc/krb5.conf. Aún es posible proporcionar un archivo /etc/krb5.conf personalizado, montándolo como un volumen que sobrescriba /etc/krb5.conf en el contenedor. Esto se puede lograr configurando OTOBO_NGINX_KERBEROS_CONFIG en el archivo .env y activando la directiva de montaje en docker-compose/otobo-override-https-kerberos.yml. El archivo /etc/krb5.keytab siempre es específico de la instalación y debe montarse desde el sistema host.
Guía de instalación de SSO Kerberossso-kerberos
Uso de puertos no estándar
Por defecto, los puertos 443 y 80 sirven HTTPS y HTTP respectivamente. Pueden existir casos en los que uno o ambos puertos ya estén siendo utilizados por otros servicios. En tales casos, los puertos predeterminados 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, o seis si HTTPS está habilitado. Sin embargo, existen casos válidos en los que uno o más de estos servicios no sean necesarios. El ejemplo principal es cuando la base de datos se ejecuta no como un servicio Docker, sino como una base de datos externa.
docker-compose up -d web nginx daemon redis elasticPor supuesto, el mismo objetivo también puede lograrse 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 recomendable crear un archivo YAML adicional que sobrescriba los servicios específicos con opciones adicionales. Un ejemplo común sería hacer accesible el contenedor de la base de datos desde el exterior a través del puerto 3306. Para ello, podría crear un archivo Docker Compose adicional como este:
cat custom_db.yml
services:
db:
ports:
- "0.0.0.0:3306:3306"Ahora debemos indicar a docker-compose que incluya nuestro nuevo archivo. Para ello, agregue 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.ymlAhora podemos usar docker-compose para recrear nuestros contenedores:
docker-compose stop
docker-compose up -dCon este procedimiento, puede personalizar cualquier servicio o volumen.
Personalización de la imagen Docker de OTOBO
Muchas personalizaciones pueden realizarse 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. A continuación, un ejemplo que instala el módulo CPAN Acme::123, aunque no 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 propia imagen Docker no necesita modificarse.
Instalar paquetes Debian adicionales es un poco más complicado. Un enfoque es crear un Dockerfile personalizado y usar la imagen OTOBO como imagen base. Otro enfoque es crear directamente una imagen modificada desde un contenedor en ejecución. Esto puede hacerse con el comando docker commit, https://docs.docker.com/engine/reference/commandline/commit/. Una buena explicación de este proceso se encuentra 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 el usuario otobo con UID 1000. El problema es que el usuario otobo no tiene permisos para instalar paquetes del sistema. Por lo tanto, la primera parte de la solución es usar 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 finaliza inmediatamente si se llama como root. La idea detrás de esta decisión de diseño es evitar la ejecución accidental 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 lo llama. Así llegamos a los siguientes comandos de ejemplo, en los que agregamos cookies de la fortuna a otobo:
Descargue una imagen OTOBO etiquetada si aún no la tiene, y verifique si la imagen ya proporciona cookies de la fortuna:
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
Agregue cookies de la fortuna a un contenedor con nombre que ejecute la imagen OTOBO original. 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 | headCree 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/fortuneA platitude is simply a truth repeated till people get tired of hearing it.
-- Stanley Baldwin
La imagen modificada puede establecerse en su archivo .env y luego usarse para diversión y beneficio.
Creación de imágenes locales
INFO
La creación local de imágenes Docker generalmente solo es necesaria durante el desarrollo. Otros casos de uso incluyen el uso de imágenes base más recientes para una instalación o la necesidad de agregar 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.gitCambie al branch deseado. Por ejemplo:
git checkout rel-10_0_11cd otoboModifique los archivos Docker según sea necesario
bin/docker/build_docker_images.sh
docker image lsLas imágenes Docker creadas localmente se etiquetan como local-<OTOBO_VERSION>, utilizando la versión del archivo RELEASE.
Una vez creadas las imágenes locales, puede regresar 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 fresca.
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 daemonLista de comandos útiles
Docker
docker system prune -aLimpieza del sistema (elimina todas las imágenes, contenedores, volúmenes y redes no utilizados)docker versionMuestra la versión- y muchos otros comandos Docker útiles.
Docker Compose
docker-compose configVerifica y muestra la configuracióndocker-compose psMuestra los contenedores en ejecución- y otros comandos útiles de Docker Compose.