No WRC, frequentemente vemos clientes entrarem em contato conosco porque seus Web Gateways são incapazes de servir páginas web. Este artigo explicará um motivo frequente para a ocorrência desses erros e descreverá algumas ferramentas que podem ser usadas para depurar o problema. Esta explicação está focada no Web Gateway servindo instâncias do InterSystems IRIS, mas a mesma explicação deve se aplicar ao CSP Gateway servindo instâncias do Caché também.

O Problema:

Recentemente, precisei executar o WebGateway em uma porta adicional, mas com uma diferença - essa porta deve publicar apenas uma aplicação web.
A princípio, pensei em configurar o Web Gateway para permitir apenas aplicativos web específicos (~urls), mas a configuração do Web Gateway é de acordo com a configuração do Apache:

LoadModule csp_module_sa "/opt/webgateway/bin/CSPa24.so"
CSPModulePath "/opt/webgateway/bin/"
CSPConfigPath "/opt/webgateway/bin/"

csp-log-tutorial

Pré-requisitos

Confira se o git está instalado.

Criei uma pasta git dentro do diretório mgr do IRIS. Cliquei com o botão direito do mouse na pasta git e escolhi Git Bash Here no menu de contexto.

git clone https://github.com/oliverwilms/csp-log-tutorial.git

Clone meu repositório do GitHub csp-log-tutorial se quiser testar você mesmo.

Vou descrever neste tutorial como tento usar arquivos access.log e CSP.log em pods webgateway para monitorar solicitações e respostas.

Minha equipe trabalha com contêineres IRIS executados na Red Hat OpenShift Container Platform (Kubernetes) da AWS. Implantamos três pods webgateway que recebem solicitações por um Balanceador de Carga de Rede. As solicitações são processadas em uma produção da InterOperability que é executada em três pods de computação. Usamos a produção do Message Bank que é executada em pods de dados espelhados como um local para analisar todas as mensagens processadas por qualquer pod de computação.

Testamos nossas interfaces usando pods alimentadores para enviar várias mensagens de solicitação ao Balanceador de Carga de Rede. Enviamos 100 mil mensagens e testamos quanto tempo leva para processar todas elas no Message Bank e gravar as respostas nos alimentadores. O número de mensagens depositadas no Message Bank e respostas recebidas pelos alimentadores corresponderam ao número de mensagens de entrada.

Recentemente, recebemos a solicitação para testar os failovers dos pods e da zona de disponibilidade (AZ). Excluímos os pods individuais à força ou não e com ou sem período de carência. Simulamos a falha da zona de disponibilidade ao negar todo o tráfego recebido e enviado a uma subrede (uma das três zonas de disponibilidade) pelo console da AWS enquanto os alimentadores enviam várias mensagens de solicitação ao Balanceador de Carga de Rede. É bastante desafiador contabilizar todas as mensagens enviadas pelos alimentadores.

Outro dia, quando um alimentador enviou 5 mil mensagens, simulamos a falha da AZ. O alimentador recebeu 4933 respostas. O Message Bank estava com 4937 mensagens.

Armazenamos access.log e CSP.log no diretório de dados dos pods webgateway. Adicionamos esta linha ao Dockerfile da nossa imagem webgateway:

RUN sed -i 's|APACHE_LOG_DIR=/var/log/apache2|APACHE_LOG_DIR=/irissys/data/webgateway|g' /etc/apache2/envvars

Definimos o Nível do Log de Eventos no Web Gateway como Ev9r.

Criei os subdiretórios data0, data1 e data2 para nossos três pods webgateway. Copiei os arquivos CSP.log e access.log dos nossos três pods webgateway armazenados em volumes persistentes:

oc cp iris-webgateway-0:/irissys/data/webgateway/access.log data0/access.log
oc cp iris-webgateway-1:/irissys/data/webgateway/access.log data1/access.log
oc cp iris-webgateway-2:/irissys/data/webgateway/access.log data2/access.log
oc cp iris-webgateway-0:/irissys/data/webgateway/CSP.log data0/CSP.log
oc cp iris-webgateway-1:/irissys/data/webgateway/CSP.log data1/CSP.log
oc cp iris-webgateway-2:/irissys/data/webgateway/CSP.log data2/CSP.log

Acabei com três subdiretórios, cada um com arquivos access.log e CSP.log.

Contamos o número de solicitações processadas em qualquer pod webgateway usando este comando:

cat access.log | grep InComingOTW | wc -l

Contamos o número de solicitações e respostas registradas em CSP.log usando este comando:

cat CSP.log | grep InComingOTW | wc -l

Geralmente, esperamos o dobro de linhas no CSP.log em comparação com o access.log. Às vezes, encontramos mais linhas em CSP.log do que o dobro esperado do número de linhas em access.log. Lembro de ver menos linhas do que o esperado em CSP.log em comparação com o que estava em access.log pelo menos uma vez. Suspeitamos que isso tenha ocorrido devido às 500 respostas registradas em access.log, que não foram registradas em CSP.log de maneira adequada, porque o pod webgateway foi encerrado.

Como analisar várias linhas de solicitações e explicar o que aconteceu?

Criei as classes persistentes otw.wgw.apache e otw.wgw.csp para importar linhas de access.log e CSP.log. access.log contém uma linha por solicitação, incluindo o status da resposta. CSP.log contém linhas separadas para solicitações e respostas.

Abra o terminal do IRIS e importe as classes no diretório src do repositório csp-log-tutorial que clonamos antes:

Set src="C:\InterSystems\IRISHealth\mgr\git\csp-log-tutorial\src"
Do $system.OBJ.LoadDir(src,"ck",,1)

Se você não tiver seu próprio arquivo CSP.log para analisar, é possível importar o arquivo do repositório csp-log-tutorial:

Set pFile="C:\InterSystems\IRISHealth\mgr\git\csp-log-tutorial\wg2_20230314_CSP.log"
Do ##class(otw.wgw.csp).ImportMessages(pFile,.pLines,.pFilter,1)

pLines e pFilter são parâmetros de saída que não são tão importantes no momento. pImport controla se Extent é excluído antes de importar os dados.

Depois de importar os dados, podemos executar consultas SQL como esta:

SELECT count(*) FROM otw_wgw.csp where wgEvent='WebGateway.ProcessRequest'

Se o número retornado for ímpar, isso indica que há uma divergência entre as solicitações e as respostas.

Podemos executar a próxima consultar para identificar os nomes de arquivos nas solicitações que não têm uma resposta correspondente:

select zFilename, count(*) from otw_wgw.csp group by zFilename having count(*) = 1

Observe que eu usei o método CalcFilename para definir a propriedade zFilename antes de salvar uma linha importada do arquivo CSP.log.

Também incluí um arquivo access.log de amostra, que podemos importar assim: Se você não tiver seu próprio arquivo CSP.log para analisar, é possível importar o arquivo do repositório csp-log-tutorial:

Set pFile="C:\InterSystems\IRISHealth\mgr\git\csp-log-tutorial\wg2_20230314_access.log"
Do ##class(otw.wgw.apache).ImportMessages(pFile,.pLines,.pFilter,1)

Podemos executar esta consulta para obter o número de mensagens relacionadas a esse tutorial:

SELECT count(*) FROM otw_wgw.apache where Text like '%tutorial%'

O que mais quero fazer se tiver tempo?

Gostaria de combinar os dados das tabelas apache e csp e possivelmente incluir os dados reunidos dos pods de computação.

Acho que posso usar os dados em access.log para determinar quando houve uma interrupção em um pod webgateway.

InterSystems FAQ 

Você pode definir páginas de erro individuais para as seguintes mensagens de erro/respostas de sistema do Web Gateway:   

• erro de servidor 
• servidor ocupado
• servidor indisponível
• tempo limite do servidor
• conexão fechada

As configurações são feitas na tela de Gerenciamento do Web Gateway ([Management Portal] > [System Administration] > [Configuration] > [Web Gateway Management] > [Configuration] > [Default Parameters]).

Na seção Página de Erro do menu de Parâmetros Padrão, defina o nome do arquivo da página html a ser exibida ou o caminho (URL) para a qual redirecionar quando ocorrer um erro.  

Você já deve ter ouvido falar que, a partir das versões IRIS e HealthShare HealthConnect 2023.2, o Apache Server interno será removido da instalação padrão, então será necessário ter um servidor de aplicativos externo como Apache Server ou NGINX.

Neste artigo, procederei à instalação de um HealthShare HealthConnect 2023.1 para que funcione com um servidor Apache pré-instalado. Para isso usarei uma máquina virtual na qual instalei um Ubuntu 22.04.

Instalando Apache Server

Apache Web Gateway com Docker

Olá, comunidade.

Neste artigo, vamos configurar programaticamente um Apache Web Gateway com Docker usando:

• Protocolo HTTPS.
• TLS\SSL para proteger a comunicação entre o Web Gateway e a instância IRIS.

Usaremos duas imagens: uma para o Web Gateway e a segunda para a instância IRIS.

Todos os arquivos necessários estão disponíveis neste repositório do GitHub.

Vamos começar com um git clone:

git clone https://github.com/lscalese/docker-webgateway-sample.git
cd docker-webgateway-sample

Prepare seu sistema

Para evitar problemas com permissões, seu sistema precisa de um usuário e um grupo:

• www-data
• irisowner

É necessário compartilhar arquivos de certificados com os contêineres. Se não estiverem no seu sistema, basta executar:

sudo useradd --uid 51773 --user-group irisowner
sudo groupmod --gid 51773 irisowner
sudo useradd –user-group www-data

Gere certificados

Nesta amostra, usaremos três certificados:

1. Uso do servidor Web HTTPS.
2. Criptografia TLS\SSL no cliente do Web Gateway.
3. Criptografia TLS\SSL na instância IRIS.

Um script pronto para uso está disponível para gerá-los.

No entanto, você deve personalizar o sujeito do certificado. Basta editar o arquivo gen-certificates.sh.

Esta é a estrutura do argumento subj do OpenSSL:

1. C: Código do país
2. ST: Estado
3. L: Local
4. O: Organização
5. OU: Unidade de organização
6. CN: Nome comum (basicamente, o nome do domínio ou do host)

Fique à vontade para mudar esses valores.

# sudo é necessário devido a chown, chgrp, chmod ...
sudo ./gen-certificates.sh

Se estiver tudo certo, você verá dois novos diretórios ./certificates/ e ~/webgateway-apache-certificates/ com certificados:

Considere que, se houver certificados autoassinados, os navegadores da Web mostrarão alertas de segurança. Obviamente, se você tiver um certificado entregue por uma autoridade certificada, você pode usá-lo em vez de um autoassinado (especialmente para o certificado do servidor Apache).

Arquivos de configuração do Web Gateway

Observe os arquivos de configuração.

CSP.INI

Você pode ver um arquivo CSP.INI no diretório webgateway-config-files.
Ele será empurrado para dentro da imagem, mas o conteúdo pode ser modificado no ambiente de execução. Considere o arquivo como um modelo.

Na amostra, os seguintes parâmetros serão substituídos na inicialização do contêiner:

• Ip_Address
• TCP_Port
• System_Manager

Consulte startUpScript.sh para ver mais detalhes. Basicamente, a substituição é realizada com a linha de comando sed.

Além disso, esse arquivo contém a configuração SSL\TLS para proteger a comunicação com a instância IRIS:

SSLCC_Certificate_File=/opt/webgateway/bin/webgateway_client.cer
SSLCC_Certificate_Key_File=/opt/webgateway/bin/webgateway_client.key
SSLCC_CA_Certificate_File=/opt/webgateway/bin/CA_Server.cer

Essas linhas são importantes. Precisamos garantir que os arquivos dos certificados estarão disponíveis para o contêiner.
Faremos isso mais tarde no arquivo docker-compose com um volume.

000-default.conf

Esse é um arquivo de configuração do Apache. Ele permite o uso do protocolo HTTPS e redireciona chamadas HTTP para HTTPS.
Os arquivos de certificado e chave privada são configurados neste arquivo:

SSLCertificateFile /etc/apache2/certificate/apache_webgateway.cer
SSLCertificateKeyFile /etc/apache2/certificate/apache_webgateway.key

Instância IRIS

Para nossa instância IRIS, configuramos somente o requisito mínimo para permitir a comunicação SSL\TLS com o Web Gateway. Isso envolve:

1. Configuração SSL %SuperServer.
2. Permitir a configuração de segurança SSLSuperServer.
3. Restringir a lista de IPs que podem usar o serviço Web Gateway.

Para facilitar a configuração, config-api é usado com um arquivo de configuração JSON simples.

{
   "Security.SSLConfigs": {
       "%SuperServer": {
           "CAFile": "/usr/irissys/mgr/CA_Server.cer",
           "CertificateFile": "/usr/irissys/mgr/iris_server.cer",
           "Name": "%SuperServer",
           "PrivateKeyFile": "/usr/irissys/mgr/iris_server.key",
           "Type": "1",
           "VerifyPeer": 3
       }
   },
   "Security.System": {
       "SSLSuperServer":1
   },
   "Security.Services": {
       "%Service_WebGateway": {
           "ClientSystems": "172.16.238.50;127.0.0.1;172.16.238.20"
       }
   }
}

Nenhuma ação é necessária. A configuração será carregada automaticamente durante a inicialização do contêiner.

Imagem tls-ssl-webgateway

dockerfile

ARG IMAGEWEBGTW=containers.intersystems.com/intersystems/webgateway:2021.1.0.215.0
FROM ${IMAGEWEBGTW}
ADD webgateway-config-files /webgateway-config-files
ADD buildWebGateway.sh /
ADD startUpScript.sh /
RUN chmod +x buildWebGateway.sh startUpScript.sh && /buildWebGateway.sh
ENTRYPOINT ["/startUpScript.sh"]

Por padrão, o ponto de entrada é /startWebGateway, mas precisamos realizar algumas operações antes de iniciar o webserver. Lembre-se de que nosso arquivo CSP.ini é um modelo, e precisamos mudar alguns parâmetros (IP, porta, gerente de sistemas) na inicialização. startUpScript.sh realizará essas mudanças e executará o script de ponto de entrada inicial /startWebGateway.

Inicializando os contêineres

arquivo docker-compose

Antes de iniciar os contêineres, o arquivo docker-compose.yml precisa ser modificado:

• **SYSTEM_MANAGER** precisa ser definido com o IP autorizado para ter acesso ao Gerenciamento do Web Gatewayhttps://localhost/csp/bin/Systems/Module.cxw Basicamente, é seu endereço IP (pode ser uma lista separada por vírgulas).

• **IRIS_WEBAPPS** precisa ser definido com a lista dos seus aplicativos CSP. A lista é separada por espaços, por exemplo: IRIS_WEBAPPS=/csp/sys /swagger-ui. Por padrão, apenas /csp/sys é exposto.

• As portas 80 e 443 são mapeadas. Adapte a outras portas se elas já estão em uso no seu sistema.

version: '3.6'
services:

 webgateway:
   image: tls-ssl-webgateway
   container_name: tls-ssl-webgateway
   networks:
     app_net:
       ipv4_address: 172.16.238.50
   ports:
     # mude a porta local já em uso no seu sistema.
     - "80:80"
     - "443:443"
   environment:
     - IRIS_HOST=172.16.238.20
     - IRIS_PORT=1972
     # Troque pela lista de endereços IP permitidos para abrir o gerente de sistema de CSP
     # https://localhost/csp/bin/Systems/Module.cxw 
     # veja o arquivo .env para definir a variável de ambiente.
     - "SYSTEM_MANAGER=${LOCAL_IP}"
     # a lista de web apps
     # /csp permite que o webgateway redirecione todas as solicitações que começam com /csp à instância iris
     # Você pode especificar uma lista separada por um espaço : "IRIS_WEBAPPS=/csp /api /isc /swagger-ui"
     - "IRIS_WEBAPPS=/csp/sys"
   volumes:
     # Monte os arquivos dos certificados.
     - ./volume-apache/webgateway_client.cer:/opt/webgateway/bin/webgateway_client.cer
     - ./volume-apache/webgateway_client.key:/opt/webgateway/bin/webgateway_client.key
     - ./volume-apache/CA_Server.cer:/opt/webgateway/bin/CA_Server.cer
     - ./volume-apache/apache_webgateway.cer:/etc/apache2/certificate/apache_webgateway.cer
     - ./volume-apache/apache_webgateway.key:/etc/apache2/certificate/apache_webgateway.key
   hostname: webgateway
   command: ["--ssl"]

 iris:
   image: intersystemsdc/iris-community:latest
   container_name: tls-ssl-iris
   networks:
     app_net:
       ipv4_address: 172.16.238.20
   volumes:
     - ./iris-config-files:/opt/config-files
     # Monte os arquivos dos certificados.
     - ./volume-iris/CA_Server.cer:/usr/irissys/mgr/CA_Server.cer
     - ./volume-iris/iris_server.cer:/usr/irissys/mgr/iris_server.cer
     - ./volume-iris/iris_server.key:/usr/irissys/mgr/iris_server.key
   hostname: iris
   # Carregue o arquivo de configuração IRIS ./iris-config-files/iris-config.json
   command: ["-a","sh /opt/config-files/configureIris.sh"]

networks:
 app_net:
   ipam:
     driver: default
     config:
       - subnet: "172.16.238.0/24"

Compile e comece:

docker-compose up -d --build

Os contêineres tls-ssl-iris e tls-ssl-webgateway devem ser inicializados.

Teste o acesso a Web

Página padrão do Apache

Abra a página http://localhost. Você será automaticamente redirecionado para https://localhost.
Os navegadores mostram alertas de segurança. Esse é o comportamento padrão com um certificado autoassinado, aceite o risco e continue.

Página de gerenciamento do Web Gateway

Abra https://localhost/csp/bin/Systems/Module.cxw e teste a conexão com o servidor.

Portal de gerenciamento

Abra https://localhost/csp/sys/utilhome.csp

Ótimo! A amostra do Web Gateway está funcionando!

Espelho IRIS com Web Gateway

No artigo anterior, criamos um ambiente de espelho, mas faltava o Web Gateway. Agora, podemos aprimorar isso.
Um novo repositório iris-miroring-with-webgateway está disponível, incluindo o Web Gateway e mais algumas melhorias:

1. Os certificados não são mais gerados na hora, mas em um processo separado.
2. Os endereços IP são substituídos pelas variáveis de ambiente nos arquivos de configuração docker-compose e JSON. As variáveis são definidas no arquivo '.env'.
3. O repositório pode ser usado como modelo.

Veja o arquivo README.md do repositório para a execução em um ambiente como este:

Olá Comunidade,

Estamos muito felizes em convidar todos os desenvolvedores para o Webinar de Lançamento do Concurso InterSystems IRIS Analytics! O tópico deste webinar é dedicado ao Concurso InterSystems IRIS Analytics.

Neste webinar iremos demonstrar o AtScale, o InterSystems Reports (Logi), o IRIS BI, o IRIS NLP e responder as perguntas referentes a como desenvolver, construir e implantar aplicações Analíticas utilizando a plataforma de dados InterSystems IRIS.

Data & Horário: Segunda-feira, 23 de Agosto — 12:00 horário de brasília

Palestrantes:  
🗣 @Carmen Logue, Gerente de Produtos InterSystems - Analytics e Inteligência Artificial
🗣 @Evgeny Shvarov, Gerente do Ecossistema para Desenvolvedores InterSystems