Instalação Avançada do OTOBO com Docker Compose

Esta seção fornece mais alguns insights técnicos sobre o que acontece nos bastidores.

::: version Lista de contêineres Docker; 10+ Container otobo_web_1 : Servidor web OTOBO na porta interna 5000.

Container otobo_daemon_1 : Daemon OTOBO. O daemon OTOBO é iniciado e verificado periodicamente.

Container otobo_db_1 : Executa o banco de dados MariaDB na porta interna 3306.

Container otobo_elastic_1 : Elasticsearch nas portas internas 9200 e 9300.

Container otobo_redis_1 : Executa o Redis como um serviço de cache.

Container opcional otobo_nginx_1 : Executa o nginx como um proxy reverso para fornecer suporte HTTPS. :::

::: version Lista de contêineres Docker; 11 Container otobo-web-1 : Servidor web OTOBO na porta interna 5000.

Container otobo-daemon-1 : Daemon OTOBO. O daemon OTOBO é iniciado e verificado periodicamente.

Container otobo-db-1 : Executa o banco de dados MariaDB na porta interna 3306.

Container otobo-elastic-1 : Elasticsearch nas portas internas 9200 e 9300.

Container otobo-redis-1 : Executa o Redis como um serviço de cache.

Container opcional otobo-nginx-1 : Executa o nginx como um proxy reverso para fornecer suporte HTTPS. :::

Visão Geral dos Volumes Docker

Os volumes Docker são criados no host para dados persistentes. Eles permitem iniciar e parar os serviços sem perda de dados. Observe que os contêineres são temporários e apenas os dados nos volumes são permanentes. otobo_opt_otobo : contém /opt/otobo no contêiner web e daemon.

otobo_mariadb_data : contém /var/lib/mysql no contêiner db.

otobo_elasticsearch_data : contém /usr/share/elasticsearch/data no contêiner elastic.

otobo_redis_data : contém dados para o contêiner redis.

otobo_nginx_ssl : contém os arquivos TLS, certificado e chave privada, precisa ser inicializado manualmente.

Variáveis de Ambiente Docker

Nas instruções, realizamos apenas uma configuração mínima. Mas o arquivo .env permite definir mais variáveis. Aqui está uma lista curta das variáveis de ambiente mais importantes. Observe que as imagens base suportam mais variáveis de ambiente.

Configurações do MariaDB

OTOBO_DB_ROOT_PASSWORD : A senha root para o MariaDB. Esta configuração é necessária para operar o serviço db.

Configurações do Elasticsearch

O Elasticsearch requer algumas configurações para ambientes de produção. Por favor, leia https://www.elastic.co/guide/en/elasticsearch/reference/7.8/docker.html#docker-prod-prerequisites para informações detalhadas.

OTOBO_Elasticsearch_ES_JAVA_OPTS : Configuração de exemplo: OTOBO_Elasticsearch_ES_JAVA_OPTS=-Xms512m -Xmx512m Por favor, ajuste este valor para ambientes de produção para até 4g.

Configurações do Servidor Web

OTOBO_WEB_HTTP_PORT : Defina este valor caso a porta HTTP deva ser diferente da porta padrão 80. Se o HTTPS estiver ativado, a porta HTTP será redirecionada para HTTPS.

Configurações do Proxy Reverso Nginx : Estas configurações são usadas quando o HTTPS está ativado.

OTOBO_WEB_HTTP_PORT : Defina este valor caso a porta HTTP deva ser diferente da porta padrão 80. Será redirecionado para HTTPS.

OTOBO_WEB_HTTPS_PORT : Defina este valor caso a porta HTTPS deva ser diferente da porta padrão 443.

OTOBO_NGINX_SSL_CERTIFICATE : Certificado SSL para o proxy reverso Nginx. Exemplo: OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/acme.crt

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Chave SSL para o proxy reverso Nginx. Exemplo: OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/acme.key

Configurações do Proxy Reverso Nginx para Kerberos : Estas configurações são usadas pelo Nginx quando o Kerberos é usado para Single Sign-On.

OTOBO_NGINX_KERBEROS_KEYTAB : Arquivo keytab do Kerberos. O padrão é /etc/krb5.keytab.

OTOBO_NGINX_KERBEROS_CONFIG : Arquivo de configuração do Kerberos. O padrão é /etc/krb5.conf, normalmente gerado a partir de krb5.conf.template.

OTOBO_NGINX_KERBEROS_SERVICE_NAME : Nome do serviço Kerberos. Não está claro onde esta configuração é realmente usada.

OTOBO_NGINX_KERBEROS_REALM : REALM Kerberos. Usado em /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_KDC : kdc Kerberos / Controlador AD. Usado em /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_ADMIN_SERVER : Servidor de administração Kerberos. Usado em /etc/krb5.conf.

OTOBO_NGINX_KERBEROS_DEFAULT_DOMAIN : Domínio padrão Kerberos. Usado em /etc/krb5.conf.

NGINX_ENVSUBST_TEMPLATE_DIR : Fornece um diretório de templates de configuração Nginx personalizado. Oferece flexibilidade adicional.

Configurações do Docker Compose : Estas configurações são usadas diretamente pelo Docker Compose.

COMPOSE_PROJECT_NAME : O nome do projeto é usado como prefixo para os volumes e contêineres. Por padrão, este prefixo é definido como otobo, resultando em nomes de contêineres como otobo_web_1 e otobo_db_1. Altere este nome se você quiser executar mais de uma instância do OTOBO no mesmo servidor.

COMPOSE_PATH_SEPARATOR : Separador para o valor de COMPOSE_FILE

COMPOSE_FILE : Use docker-compose/otobo-base.yml como base e adicione os arquivos de extensão desejados. Por exemplo, docker-compose/otobo-override-http.yml ou docker-compose/otobo-override-https.yml.

OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX, ... : Usado para especificar imagens Docker alternativas. Útil para testar builds locais ou para usar versões atualizadas das imagens.

Configuração Personalizada do Proxy Reverso Nginx

O contêiner otobo_nginx_1 fornece suporte HTTPS executando o Nginx como um proxy reverso. A imagem Docker que roda no contêiner consiste na imagem Docker oficial do Nginx, https://hub.docker.com/_/nginx, juntamente com uma configuração específica do OTOBO para o Nginx. A configuração padrão específica do OTOBO é encontrada dentro da imagem Docker em /etc/nginx/template/otobo_nginx.conf.template. Na verdade, este é apenas um template para a configuração final. Existe um processo fornecido pela imagem base do Nginx que substitui as macros no template pelas variáveis de ambiente correspondentes. Este processo é executado quando o contêiner é iniciado. No arquivo de template padrão, as seguintes macros são usadas:

OTOBO_NGINX_SSL_CERTIFICATE : Para configurar SSL.

OTOBO_NGINX_SSL_CERTIFICATE_KEY : Para configurar SSL.

OTOBO_NGINX_WEB_HOST : O host HTTP usado internamente.

OTOBO_NGINX_WEB_PORT : A porta HTTP usada internamente.

Veja o passo [4.] para usar esta capacidade de configuração para configurar o certificado SSL.

Se as macros padrão não forem suficientes, a personalização pode ir mais longe. Isso pode ser alcançado substituindo o template de configuração padrão por uma versão personalizada. É uma boa prática não modificar a configuração diretamente no contêiner em execução. Nestes comandos de exemplo, usamos o template existente como ponto 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

Adicione a seguinte linha ao arquivo docker-compose/otobo-override-https.yml:

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

Para isso, você pode usar seu editor de texto favorito com Putty ou WinSCP.

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

Agora você pode editar o arquivo /opt/otobo-docker/nginx/otobo_nginx.conf. Para aplicar as alterações, os contêineres precisam ser reiniciados:

docker-compose up -d --build

Single Sign-On com Suporte Kerberos no Nginx

Para ativar a autenticação Kerberos, por favor, baseie seu arquivo .env no arquivo de exemplo .docker_compose_env_https_kerberos. Isso ativará a configuração especial em docker-compose/otobo-override-https-kerberos.yml. Este arquivo de configuração do Docker Compose seleciona uma imagem Nginx que suporta Kerberos. Ele também passa algumas configurações específicas do Kerberos como valores de ambiente para o contêiner Nginx em execução. Essas configurações são listadas acima. Como de costume, os valores para essas configurações podem ser especificados no arquivo .env. A maioria dessas configurações são usadas como valores de substituição para o template https://github.com/RotherOSS/otobo/blob/rel-10_1/scripts/nginx/kerberos/templates/krb5.conf.template. A substituição ocorre durante a inicialização do contêiner. No contêiner em execução, a configuração modificada estará disponível em /etc/krb5.conf. Ainda é possível fornecer um arquivo /etc/krb5.conf específico do usuário. Isso pode ser feito montando um volume que substitui /etc/krb5.conf no contêiner. Isso pode ser alcançado definindo OTOBO_NGINX_KERBEROS_CONFIG no arquivo .env e ativando a diretiva de montagem em docker-compose/otobo-override-https-kerberos.yml. /etc/krb5.keytab é sempre específico da instalação e, portanto, deve sempre ser montado do sistema host. Guia de Instalação Kerberos SSOsso-kerberos

Selecionando Portas Não Padrão

Por padrão, as portas 443 e 80 atendem HTTPS e HTTP, respectivamente. Pode haver casos em que uma ou ambas essas portas já estejam em uso por outros serviços. Nesses casos, as portas padrão podem ser substituídas especificando OTOBO_WEB_HTTP_PORT e OTOBO_WEB_HTTPS_PORT no arquivo .env.

Ignorar a Inicialização de Serviços Específicos

A configuração atual do Docker Compose inicia cinco, seis se o HTTPS estiver ativado, serviços. No entanto, existem casos de uso válidos em que um ou mais desses serviços não são necessários. O principal exemplo é quando o banco de dados deve ser executado como um banco de dados externo, em vez de um serviço Docker.

docker-compose up -d web nginx daemon redis elastic

Claro, o mesmo objetivo pode ser alcançado editando o arquivo docker-compose/otobo-base.yml e removendo as definições de serviço relevantes.

Personalizando o Docker Compose do OTOBO

Em vez de editar os arquivos em docker-compose/ e correr o risco de sobrescrever suas próprias opções com a próxima atualização da pasta otobo-docker, é aconselhável criar um arquivo YAML extra onde os serviços específicos são sobrescritos com opções adicionais. Um exemplo comum seria tornar o contêiner do banco de dados acessível externamente através da porta 3306. Para isso, você pode criar um arquivo Docker Compose extra que se pareça com isto:

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

Agora precisamos informar ao docker-compose para incluir nosso novo arquivo. Para fazer isso, você precisa adicionar seu arquivo YAML à variável COMPOSE_FILE no arquivo .env, por exemplo:

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

Agora podemos usar docker-compose para recriar nossos contêineres:

docker-compose stop
docker-compose up -d

Com este procedimento, você pode personalizar qualquer serviço ou volume.

Personalizando a Imagem Docker do OTOBO

Muitas personalizações podem ser feitas no volume externo otobo_opt_otobo, que corresponde ao diretório /opt/otobo na imagem Docker. Isso funciona, por exemplo, para módulos Perl locais que podem ser instalados em /opt/otobo/local. Aqui está um exemplo que instala o módulo CPAN não muito ú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

A beleza desta abordagem é que a imagem Docker em si não precisa ser modificada. Instalar pacotes Debian adicionais é um pouco mais complicado. Uma abordagem é criar um Dockerfile personalizado e usar a imagem OTOBO como imagem base. Outra abordagem é criar uma imagem modificada diretamente de um contêiner em execução. Isso pode ser feito com o comando docker commit, https://docs.docker.com/engine/reference/commandline/commit/. Uma boa descrição deste processo pode ser encontrada em https://phoenixnap.com/kb/how-to-commit-changes-to-docker-image. Para esta última abordagem, existem dois obstáculos a serem superados. Primeiro, a imagem otobo é executada por padrão como o usuário otobo com UID 1000. O problema é que o usuário otobo não tem permissão para instalar pacotes do sistema. Portanto, a primeira parte da solução é usar a opção --user root ao iniciar a imagem. O segundo obstáculo é que o script de entrada padrão /opt/otobo_install/entrypoint.sh é encerrado imediatamente se for chamado como root. A consideração por trás dessa decisão de design é que a execução acidental como root deve ser evitada. Portanto, a segunda parte da solução é especificar um script de entrada diferente que não se importe com quem é o chamador. Isso nos leva aos seguintes comandos de exemplo, onde adicionamos Fortune Cookies ao otobo: Busque uma imagem OTOBO com tag, caso ainda não a tenhamos, e verifique se a imagem já fornece 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

Adicione Fortune Cookies a um contêiner nomeado que executa a imagem OTOBO original. Isso é feito em uma sessão interativa como usuário 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

Crie uma imagem a partir do contêiner parado e dê um nome a ela. Observe que o usuário padrão e o script de entrada precisam ser restaurados: Finalmente, podemos verificar:

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

A imagem modificada pode ser definida em seu arquivo .env e então usada para diversão e lucro.

Construindo Imagens Locais

INFO

A construção local de imagens Docker é normalmente necessária apenas durante o desenvolvimento. Outros casos de uso incluem quando imagens base mais recentes devem ser usadas para uma instalação ou quando funcionalidades adicionais precisam ser adicionadas às imagens.

Os arquivos Docker necessários para construir imagens Docker localmente fazem parte do repositório git https://github.com/RotherOSS/otobo:

• otobo.web.dockerfile
• otobo.nginx.dockerfile
• otobo.elasticsearch.dockerfile O script para a construção real das imagens é bin/docker/build_docker_images.sh.

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

Mude para o branch desejado. por exemplo,

git checkout rel-10_0_11

cd otobo

Modifique os arquivos Docker conforme necessário

bin/docker/build_docker_images.sh
docker image ls

As imagens Docker construídas localmente são tagadas como local-<OTOBO_VERSION>, onde a versão é retirada do arquivo RELEASE. Após a construção das imagens locais, pode-se retornar ao diretório docker-compose. As imagens locais são declaradas definindo OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH, OTOBO_IMAGE_OTOBO_NGINX em .env.

Instalação Automática

Em vez de realizar o processo através de http://yourIPorFQDN/otobo/installer.pl, pode-se pegar um atalho. Isso é útil para executar a suíte de testes em uma instalação nova.

WARNING

docker-compose down -v removerá todas as configurações e dados 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 Úteis

Docker

• docker system prune -a Limpeza do sistema (remove todas as imagens, contêineres, volumes, redes não utilizados)
• docker version Exibe a versão
• e muitos outros comandos Docker úteis.

Docker Compose

• docker-compose config Verifica e exibe a configuração
• docker-compose ps Exibe os contêineres em execução
• e outros comandos Docker Compose úteis.