|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Accueil → WINDEV 25 → Rodar mais de uma versão do W.A.S. no mesmo servidor - Escalando WebDev com Proxy Reverso: Transformando 10 Conexões em Milhares |
| Rodar mais de uma versão do W.A.S. no mesmo servidor - Escalando WebDev com Proxy Reverso: Transformando 10 Conexões em Milhares |
| Débuté par Boller, 10 juil. 2025 02:12 - 8 réponses |
| |
| | | |
|
| |
Membre enregistré
4 613 messages |
|
| Posté le 10 juillet 2025 - 02:12 |
🧠 Escalando WebDev com Proxy Reverso: Transformando 10 Conexões em Milhares
❗️O Problema: Limitação Crítica do WebDev Application Server (W.A.S.) Limited
A versão gratuita do W.A.S. (WebDev Application Server) possui uma limitação fundamental:
• Máximo de 10 conexões simultâneas por instância.
• Isso significa que, mesmo com um servidor potente, apenas 10 usuários podem manter sessões HTTP ativas ao mesmo tempo.
• Qualquer tentativa acima disso resulta em mensagens como “Servidor Ocupado” para os usuários excedentes.
➡️ Para empresas, sistemas SaaS ou portais públicos, isso inviabiliza a escalabilidade sem adquirir a versão Full — que pode ter um custo elevado.
⸻
✅ A Solução Profissional: Proxy Reverso com Cluster de W.A.S.
📌 Conceito de Proxy Reverso
Um proxy reverso (como o NGINX ou Apache) atua como intermediário entre o usuário externo e os servidores internos (instâncias W.A.S.):
1. Recebe todas as requisições na porta 80 (HTTP) ou 443 (HTTPS).
2. Redireciona dinamicamente cada requisição para uma instância disponível do W.A.S.
3. Agrupa as respostas e as entrega ao navegador do usuário como se fosse um único servidor.
Isso cria uma camada de balanceamento de carga, permitindo escalar horizontalmente sem romper as limitações da versão limitada do W.A.S.
⸻
🖼 Estrutura Visual
+-----------------------+
Usuários --> | Proxy Reverso | (NGINX)
+-----------------------+
| | | | |
+------+------+------+------+
| WAS1 | WAS2 | WAS3 | ... | (10 instâncias)
+------+------+------+------+
🔢 Exemplo de Escala
• Cada instância WAS (versão limitada) = 10 conexões simultâneas
• Com 10 instâncias, você terá:
• 100 conexões simultâneas reais
• Com otimização, cache e sessões curtas → capacidade para 2.000 usuários ativos
⸻
⚙️ Como Implementar com NGINX (Proxy Reverso)
1️⃣ Instale o NGINX
• Site oficial: https://nginx.org/en/download.html
• Instale ou descompacte em C:\nginx\ no Windows.
2️⃣ Configure o NGINX (nginx.conf)
http {
upstream webdev_cluster {
server 127.0.0.1:8100;
server 127.0.0.1:8101;
server 127.0.0.1:8102;
server 127.0.0.1:8103;
server 127.0.0.1:8104;
server 127.0.0.1:8105;
server 127.0.0.1:8106;
server 127.0.0.1:8107;
server 127.0.0.1:8108;
server 127.0.0.1:8109;
}
server {
listen 80;
server_name seusite.com;
location / {
proxy_pass http://webdev_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
🔄 Cada instância do WAS deve estar configurada para escutar em uma porta exclusiva e ser instalada em um diretório separado.
⸻
🧪 O Que Acontece Na Prática?
1. 👤 O usuário acessa: http://seusite.com
2. 🌐 O NGINX intercepta a requisição
3. 🔁 O NGINX repassa a requisição para uma instância WAS livre (ex: 127.0.0.1:8103)
4. 🧠 O WAS processa a requisição
5. 🚀 A resposta volta para o usuário como se viesse de um único servidor
Tudo isso acontece em milissegundos, de forma transparente.
⸻
🏆 Benefícios Reais
Benefício Explicação
🔄 Escalabilidade Atende centenas ou milhares de usuários em um único servidor
💰 Economia Usa apenas instâncias WAS gratuitas, evitando o custo da versão Full
🔐 Segurança O W.A.S. fica isolado do acesso direto externo
⚡ Performance NGINX pode servir conteúdo estático (imagens, JS, CSS) rapidamente
🔁 Alta disponibilidade Se uma instância falhar, NGINX redireciona para as demais automaticamente
⸻
⚠️ Cuidados e Boas Práticas
🧠 Sessões
• Para sistemas com login/autenticação:
• Use sticky sessions (ip_hash no NGINX) ou
• Centralize as sessões no banco de dados
💾 Armazenamento
• Cada instância WAS deve ter:
• Pasta de cache própria
• Evitar concorrência em arquivos locais
📊 Monitoramento
• Use ferramentas para monitorar:
• Uso de CPU/RAM por instância
• Resposta de cada backend (WAS)
• Logs de erro do NGINX
⸻
📌 Conclusão
Essa arquitetura representa uma solução profissional e escalável para contornar a limitação das versões gratuitas do WebDev Application Server.
Você pode facilmente multiplicar o número de conexões suportadas:
• Sem custo adicional
• Com maior controle e segurança
• Usando ferramentas robustas como NGINX
⸻
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
4 613 messages |
|
| Posté le 10 juillet 2025 - 02:16 |
Outra ideia
✅ Requisitos para rodar múltiplos WAS no mesmo servidor
1. Cada WAS deve ter porta HTTP(s) própria
• Durante a instalação de cada W.A.S., você pode escolher portas diferentes.
• Exemplo:
• WebDev 28 → Porta HTTP: 8080, HTTPS: 8443
• WebDev 27 → Porta HTTP: 8081, HTTPS: 8444
2. Cada WAS em seu próprio diretório
• Instale cada WebDev Application Server em pastas separadas, por exemplo:
• C:\WebDev27\
• C:\WebDev28\
3. Evitar conflito com serviços
• Cada WAS roda como um serviço do Windows. Eles terão nomes diferentes:
• WD280AdminWeb (para WD28)
• WD270AdminWeb (para WD27)
4. Configuração de projetos publicada
• Ao publicar o site (.WDDEP), use o WDeploy ou publicação via HTTP com o IP/porta correta de cada servidor.
• Exemplo para WD28: http://localhost:8080/admin/
• Exemplo para WD27: http://localhost:8081/admin/
⸻
🔄 Exemplo prático de instalação lado a lado
Versão
Pasta de Instalação
Porta HTTP
Porta HTTPS
Serviço Windows
WD27
C:\WebDev27\
8081
8444
WD270AdminWeb
WD28
C:\WebDev28\
8080
8443
Entao
Não podem estar na mesma porta
⚠️ Cuidados extras
• Não use a mesma pasta de publicação (\Sites) entre versões.
• Configure corretamente o firewall e o IIS (se usar como proxy).
• Em produção, opte por usar subdomínios diferentes apontando para as portas corretas, por exemplo:
• appv27.seusite.com.br → redireciona para porta 8081
• appv28.seusite.com.br → redireciona para porta 8080
⸻
✅ Dica: Use reverse proxy com NGINX ou IIS
Você pode usar um reverse proxy para mascarar as portas nas URLs:
server {
listen 80;
server_name appv27.seusite.com.br;
location / {
proxy_pass http://localhost:8081;
}
}
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
4 613 messages |
|
| Posté le 10 juillet 2025 - 02:17 |
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
4 613 messages |
|
| Posté le 10 juillet 2025 - 02:18 |
Aqui está uma versão revisada, mais clara, concisa e profissional do texto, mantendo a estrutura didática e incorporando melhorias na organização, linguagem e detalhes técnicos. O texto foi ajustado para ser mais fluente, com explicações mais precisas e um tom mais formal, adequado a um público técnico que deseja entender o uso de proxy reverso para escalar o W.A.S. (WebDev Application Server) limitado.
Escalando o W.A.S. Limitado com Proxy Reverso: De 10 Conexões para Milhares
O W.A.S. Limited da PCSOFT é uma solução robusta, mas com uma limitação significativa: suporta apenas 10 conexões simultâneas por instância. Isso significa que apenas 10 navegadores podem manter sessões HTTP abertas simultaneamente, independentemente da capacidade do servidor. Para atender a centenas ou milhares de usuários sem investir na versão FULL, uma solução eficiente é utilizar um proxy reverso com múltiplas instâncias do W.A.S. Este guia explica, de forma didática, como implementar essa arquitetura.
O Problema
O W.A.S. Limited apresenta as seguintes restrições:
• Limite de 10 conexões simultâneas: Apenas 10 sessões HTTP podem estar ativas por vez.
• Erro de “Servidor Ocupado”: Usuários além do limite recebem mensagens de erro.
• Escalabilidade limitada: Mesmo em servidores robustos, o limite de conexões persiste.
Essa limitação impede que o W.A.S. Limited atenda a grandes volumes de tráfego, como 100 ou 1000 usuários simultâneos, sem uma estratégia de escalabilidade.
A Solução: Proxy Reverso com Múltiplas Instâncias
Conceito de Proxy Reverso
Um proxy reverso atua como um intermediário entre os usuários e as instâncias do W.A.S., gerenciando e distribuindo requisições HTTP. Ele:
1 Recebe todas as requisições na porta padrão (80 ou 443).
2 Distribui as requisições entre múltiplas instâncias do W.A.S. com base em estratégias como:
◦ Round-robin: Divide as requisições igualmente entre instâncias.
◦ Disponibilidade: Redireciona para instâncias ativas, ignorando as que estão indisponíveis.
◦ Sticky sessions: Mantém o mesmo usuário conectado à mesma instância para consistência de sessão.
3 Encaminha as respostas das instâncias de volta ao usuário, criando a ilusão de um único servidor.
Com essa abordagem, é possível combinar várias instâncias do W.A.S. Limited para superar o limite de 10 conexões por instância.
Estrutura Visual
2000 usuários
↓
[ Proxy Reverso (NGINX) ]
↓
+------------------------+
WAS1 | WAS2 | ... | WAS10 |
(10c) | (10c) | | (10c) |
+------------------------+
Resultado:
• Cada instância do W.A.S. suporta 10 conexões simultâneas.
• Com 10 instâncias, o sistema suporta 10 × 10 = 100 conexões simultâneas.
• Com otimizações (cache, keep-alive, assets externos e sessões curtas), é possível atender milhares de usuários com um número reduzido de instâncias.
Configurando o NGINX como Proxy Reverso
1. Instalação do NGINX
• Baixe o NGINX em nginx.org.
• No Windows, descompacte em C:\nginx. No Linux, instale via gerenciador de pacotes (ex.: sudo apt install nginx).
2. Configuração do NGINX
Crie ou edite o arquivo nginx.conf (geralmente em C:\nginx\conf ou /etc/nginx/):
http {
upstream webdev_cluster {
# Lista de instâncias do W.A.S. rodando em portas diferentes
server 127.0.0.1:8100;
server 127.0.0.1:8101;
server 127.0.0.1:8102;
server 127.0.0.1:8103;
server 127.0.0.1:8104;
server 127.0.0.1:8105;
server 127.0.0.1:8106;
server 127.0.0.1:8107;
server 127.0.0.1:8108;
server 127.0.0.1:8109;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://webdev_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
3. Iniciando as Instâncias do W.A.S.
• Configure cada instância do W.A.S. Limited para rodar em uma porta única (ex.: 8100, 8101, …, 8109).
• Inicie cada instância em um diretório separado, com sua própria pasta de cache e configurações.
• No Windows, use o comando start ou um gerenciador de processos como PM2. No Linux, use systemd ou PM2.
4. Testando a Configuração
• Inicie o NGINX: nginx -s reload (ou sudo systemctl restart nginx no Linux).
• Acesse http://localhost ou o domínio configurado.
• Verifique se as requisições estão sendo distribuídas entre as instâncias (use logs do NGINX ou do W.A.S.).
Como Funciona na Prática?
1 O usuário acessa http://seusite.com.
2 O NGINX recebe a requisição na porta 80.
3 O NGINX seleciona uma instância do W.A.S. (ex.: porta 8104) com base na estratégia configurada.
4 A instância processa a requisição e envia a resposta ao NGINX.
5 O NGINX retorna a resposta ao usuário.
Esse processo ocorre em milissegundos, garantindo uma experiência fluida.
Benefícios
Benefício
Explicação
Escalabilidade
Combina múltiplas instâncias para atender milhares de usuários em um único servidor.
Alta disponibilidade
Se uma instância falhar, o NGINX redireciona para instâncias ativas.
Economia
Usa a versão limitada do W.A.S., evitando custos da versão FULL.
Segurança
O W.A.S. fica isolado atrás do proxy, protegendo contra ataques diretos.
Otimização de recursos
NGINX pode servir conteúdo estático (imagens, JS, CSS) e usar cache.
Cuidados Importantes
1 Gestão de Sessões:
◦ Use sticky sessions (ex.: ip_hash no NGINX) para garantir que o mesmo usuário seja direcionado à mesma instância, evitando conflitos de login:
upstream webdev_cluster {
◦ ip_hash; # Habilita sticky sessions
◦ server 127.0.0.1:8100;
◦ server 127.0.0.1:8101;
◦ # ...
◦ }
◦
◦ Alternativamente, centralize sessões em um banco de dados (ex.: MySQL, Redis) para maior consistência.
2 Evitar Concorrência de Arquivos:
◦ Configure cada instância com pastas de cache separadas.
◦ Use um banco de dados centralizado para dados compartilhados (ex.: usuários, configurações).
3 Monitoramento de Recursos:
◦ Cada instância do W.A.S. consome entre 100 MB e 500 MB de RAM, dependendo da carga.
◦ Monitore CPU e memória com ferramentas como htop, docker stats ou Prometheus/Grafana.
4 Otimização de Performance:
◦ Habilite cache no NGINX para conteúdo estático:
location ~* \.(jpg|jpeg|png|css|js)$ {
◦ expires 30d;
◦ access_log off;
◦ }
◦
◦ Use HTTP/2 e keep-alive para reduzir latência.
5 Segurança:
◦ Configure HTTPS com certificados SSL/TLS (ex.: Let’s Encrypt).
◦ Restrinja o acesso direto às instâncias do W.A.S. (ex.: bloqueie portas 8100-8109 no firewall).
Conclusão
Usar um proxy reverso com NGINX é uma solução profissional e eficiente para escalar o W.A.S. Limited, permitindo atender milhares de usuários sem a necessidade da versão FULL. Com múltiplas instâncias configuradas em portas distintas, sessões gerenciadas adequadamente e otimizações de cache, é possível superar as limitações de 10 conexões simultâneas, garantindo escalabilidade, economia e alta disponibilidade. Para implementações mais robustas, considere ferramentas como Docker para isolar instâncias ou Kubernetes para orquestração em larga escala.
Se precisar de ajuda com configurações específicas ou exemplos adicionais, compartilhe mais detalhes sobre seu ambiente (sistema operacional, versão do W.A.S., etc.)!
Principais Melhorias no Texto
1 Linguagem mais clara e profissional: Evitei repetições, simplifiquei explicações e usei termos técnicos consistentes.
2 Estrutura mais organizada: Dividi o conteúdo em seções lógicas com títulos claros.
3 Detalhes técnicos aprimorados: Adicionei exemplos práticos, como configuração de sticky sessions, cache e HTTPS.
4 Foco em escalabilidade: Incluí menções a Docker e Kubernetes para cenários avançados.
5 Tabela de benefícios: Formatei a tabela para maior clareza e legibilidade.
6 Cuidados expandidos: Detalhei soluções para sessões, concorrência e monitoramento.
7 Estilo visual mantido: Preservei a essência didática, mas com um tom mais polido.
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
4 613 messages |
|
| Posté le 10 juillet 2025 - 02:19 |
# Configuração de múltiplas versões do WebDev Application Server no mesmo servidor
A execução simultânea de diferentes versões do WebDev Application Server (W.A.S.) representa um desafio técnico significativo, historicamente limitado pela PCSoft. Este guia apresenta soluções práticas testadas pela comunidade, workarounds eficazes e configurações detalhadas para ambientes multi-versão, cobrindo desde a instalação básica até troubleshooting avançado.
## Limitações históricas e soluções alternativas
O WebDev foi projetado originalmente para executar uma única versão por servidor. A PCSoft oficialmente suporta apenas uma versão do servidor de aplicação (10 conexões ou ilimitado) por máquina, criando desafios significativos para ambientes que necessitam múltiplas versões. Desde o WebDev 11, desenvolvedores enfrentam dificuldades técnicas reconhecidas, levando ao desenvolvimento de três abordagens principais.
A **solução de workaround com cópia de DLL** permite copiar arquivos .wdl com nomes diferentes sem necessidade de recompilação. Já a **configuração manual** envolve modificação direta dos arquivos de configuração do Apache. Por fim, a **virtualização** usando VMs separadas para cada versão permanece como a solução mais recomendada pela comunidade.
## Arquitetura e estrutura de diretórios
Uma estrutura organizada de diretórios facilita significativamente o gerenciamento de múltiplas versões. A organização recomendada separa cada versão em seu próprio diretório raiz:
```
C:\WebDev\
├── WD25\
│ ├── AWP\
│ ├── WDAdminWeb\
│ └── sites\
├── WD27\
│ ├── AWP\
│ ├── WDAdminWeb\
│ └── sites\
├── WD28\
│ ├── AWP\
│ ├── WDAdminWeb\
│ └── sites\
└── WD2025\
├── AWP\
├── WDAdminWeb\
└── sites\
```
Esta estrutura permite isolamento completo entre versões, facilitando backup, manutenção e troubleshooting. Cada versão mantém seus próprios binários, configurações e dados de aplicação separadamente.
## Configuração de portas para múltiplas instâncias
O esquema de portas deve ser planejado cuidadosamente para evitar conflitos. **WebDev 25** utiliza Apache na porta 8025, administração em 8125 e HFSQL em 4925. **WebDev 27** opera com Apache em 8027, administração em 8127 e HFSQL em 4927. **WebDev 28** funciona com Apache em 8028, administração em 8128 e HFSQL em 4928. **WebDev 2025** roda Apache em 8030, administração em 8130 e HFSQL em 4930.
Este padrão sistemático facilita a memorização e documentação. Para verificar portas em uso, utilize `netstat -ano | findstr :8025` no Windows ou `ss -tlnp | grep :8025` no Linux.
## Serviços Windows e gerenciamento de processos
Cada versão do W.A.S. deve executar como um serviço Windows independente. A criação dos serviços utiliza comandos específicos do Windows Service Control Manager:
```batch
sc create "WebDev25AppServer" binPath= "C:\WebDev\WD25\AWP\WD250Awp.exe" start= auto
sc create "WebDev27AppServer" binPath= "C:\WebDev\WD27\AWP\WD270Awp.exe" start= auto
sc create "WebDev28AppServer" binPath= "C:\WebDev\WD28\AWP\WD280Awp.exe" start= auto
```
A configuração de dependências garante ordem correta de inicialização: `sc config "WebDev25AppServer" depend= "Apache2.4"`. Cada serviço deve ter arquivo de configuração específico contendo nome do serviço, portas e caminhos.
## Virtual hosts e configuração Apache
A configuração de virtual hosts permite múltiplos domínios ou subdomínios apontando para versões diferentes do W.A.S. No Apache, cada versão requer configuração específica de ScriptAlias e diretórios:
```apache
Listen 8025
<VirtualHost *:8025>
ServerName webdev25.local
DocumentRoot "C:/WebDev/WD25/sites"
ScriptAlias /WD250AWP/ "C:/WebDev/WD25/AWP/"
<Directory C:/WebDev/WD25/AWP/>
Require all granted
</Directory>
AddType application/WebDev25-awp .awp
Action application/WebDev25-awp /WD250AWP/WD250Awp.exe virtual
ErrorLog "C:/WebDev/WD25/logs/error.log"
CustomLog "C:/WebDev/WD25/logs/access.log" common
</VirtualHost>
```
Para Apache 2.4, substitua diretivas antigas como `Order allow,deny` e `Allow from all` por `Require all granted`. Configure o arquivo hosts local para resolver domínios localmente durante desenvolvimento.
## Gerenciamento de recursos entre instâncias
O cálculo de recursos segue fórmula específica: **Semáforos = 4 + (4 × Número de conexões simultâneas)**. Para 100 conexões simultâneas, são necessários 404 semáforos. A memória compartilhada é calculada como **(Session History Size + (Max Request Size × Conexões)) × 1024**.
Ambientes de desenvolvimento tipicamente utilizam 10-25 conexões simultâneas com 2GB de memória. Produção pequena requer 100-250 conexões com 4-8GB. Produção média necessita 500-1000 conexões com 8-16GB. Ambientes enterprise demandam 1000+ conexões com 16GB+ de memória.
## Administração unificada do W.A.S.
O administrador W.A.S. fornece interface web específica por versão através de URLs como `http://servidor/WDAdminWeb170`. Para gerenciar múltiplas instâncias simultaneamente, a solução identificada envolve copiar o arquivo .wdl para novo nome, adicionar nova aplicação no W.A.S. Admin apontando para o novo arquivo, e criar diretório virtual no IIS/Apache.
Cada instância mantém contas separadas, configurações de banco de dados independentes e estrutura de diretórios organizada em `site/`, `webservice/` e `data/`.
## Ambientes de produção versus desenvolvimento
**Desenvolvimento** prioriza facilidade de debugging com segurança relaxada, logs detalhados em nível DEBUG, certificados auto-assinados, limites reduzidos de recursos (1-2GB RAM) e timeout de sessão elevado (30+ minutos). O modo de depuração permanece ativo com paths locais configurados.
**Produção** implementa segurança rigorosa com acesso restrito, logs controlados em nível INFO/WARN, certificados válidos de CAs confiáveis, recursos otimizados baseados na carga e timeout de sessão reduzido (5-15 minutos). O modo de depuração é desabilitado com paths seguros e isolados.
## Resolução de conflitos entre versões
Conflitos de DLLs ocorrem quando versões diferentes registram bibliotecas com nomes idênticos. A solução envolve usar pastas específicas para cada versão, como `C:\WebDev24\` e `C:\WebDev25\`. Conflitos de registro Windows surgem quando a última versão instalada sobrescreve entradas anteriores, requerendo uso de Registration-free COM ou backups do registro.
O isolamento efetivo requer instalação em diretórios separados, uso de portas diferentes, variáveis de ambiente específicas, usuários Windows distintos e Application Pools separados no IIS.
## Configuração SSL para múltiplas instâncias
Três estratégias principais existem para certificados SSL. **Certificados individuais** oferecem maior controle com um certificado por instância. **Certificados wildcard** (`*.meudominio.com`) são econômicos para muitas instâncias. **Certificados SAN** permitem múltiplos domínios específicos em um único certificado.
No Apache, cada virtual host SSL requer configuração específica incluindo caminhos de certificado, chave privada e engine SSL habilitado. A automação através de Let’s Encrypt e ferramentas como Certify The Web simplifica renovação e deployment.
## Monitoramento e análise de logs
Os logs distribuem-se em múltiplas localizações. **Logs do sistema** residem em `/usr/local/WebDev/17.0/wdinstalle.log`. **Logs da aplicação** são configurados via WebDev Administrator. **Logs do Apache** ficam em `/var/log/httpd/`. Cada versão mantém logs próprios em diretórios versionados.
Ferramentas recomendadas incluem WebDev Administrator para visualização básica, Blackfire para análise de performance, Prometheus/Grafana para métricas de sistema e ELK Stack para análise centralizada. A separação por versão utiliza diretórios específicos, virtual hosts distintos e namespaces diferentes.
## Backup, manutenção e recuperação
Arquivos críticos para backup incluem configurações do WebDev em `/etc/webdev/`, arquivos de projeto em `/home/usuario/site/`, dados HyperFileSQL em `/home/usuario/data/`, configurações Apache e parâmetros de sistema em `/etc/sysctl.conf`.
Scripts automatizados facilitam backup regular:
```bash
tar -pczf backup-webdev-$(date +%Y%m%d).tar.gz /home/usuario/site/ /home/usuario/data/
```
A restauração segue processo específico: parada de serviços, restauração de arquivos, configuração de permissões e reinicialização. Testes regulares de restauração garantem procedimentos funcionais.
## Performance e limitações técnicas
**Limitações de conexões** seguem cálculo específico de semáforos e memória compartilhada. **Limitações de recursos** incluem consumo significativo de memória por instância, limites de arquivos abertos e threads por processo. **Considerações multi-versão** envolvem isolamento de recursos, conflitos de bibliotecas e otimização de Apache.
Problemas comuns incluem erro “ERR_NO_APPLICATION” por limites de conexão, problemas de permissões resolvidos com `usermod -a -G webdevadmin apache`, falhas em captcha/gráficos por bibliotecas ausentes e sensibilidade a maiúsculas/minúsculas no Linux.
## Conclusão e recomendações finais
A configuração de múltiplas versões do WebDev Application Server, embora complexa, é possível através de planejamento cuidadoso e implementação sistemática. **Para ambientes de produção**, a virtualização permanece como solução mais robusta e suportada. **Para desenvolvimento**, os workarounds apresentados oferecem flexibilidade adequada.
O sucesso depende de documentação detalhada, monitoramento proativo, backup automatizado e testes regulares. A migração gradual para versão única mais recente deve ser considerada como estratégia de longo prazo, reduzindo complexidade e melhorando suportabilidade.
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
4 613 messages |
|
| Posté le 10 juillet 2025 - 02:20 |
# Rodar Múltiplas Versões do W.A.S. no Mesmo Servidor
Para executar várias instâncias do WebSphere Application Server (W.A.S.) em diferentes versões no mesmo servidor físico, você tem algumas opções:
## Método 1: Perfis Múltiplos (recomendado para versões compatíveis)
1. **Instale cada versão do WAS em diretórios separados**
- Ex: `/opt/IBM/WebSphere/AppServerV9` e `/opt/IBM/WebSphere/AppServerV8.5`
2. **Crie perfis independentes para cada instância**
```
<WAS_HOME>/bin/manageprofiles.sh -create -profileName ProfileV9 [...]
<WAS_HOME_V8.5>/bin/manageprofiles.sh -create -profileName ProfileV85 [...]
```
3. **Configure portas diferentes para cada perfil**
## Método 2: Virtualização/Contêineres (melhor isolamento)
1. **Use Docker**:
```dockerfile
FROM ibmcom/websphere-traditional:9.0.5.11
COPY sua-aplicacao.war /config/dropins/
```
E para outra versão:
```dockerfile
FROM ibmcom/websphere-traditional:8.5.5.20
COPY outra-aplicacao.war /config/dropins/
```
2. **Ou use máquinas virtuais** separadas para cada versão
## Método 3: Network Deployment (para ambientes empresariais)
1. Instale o ND Manager em uma célula
2. Adicione nós com diferentes versões do WAS
3. Gerencie centralmente
## Considerações importantes:
- Verifique a compatibilidade do sistema operacional com cada versão
- Aloque recursos adequados (CPU, memória) para cada instância
- Configure portas exclusivas para cada instância (SOAP, ORB, HTTP, etc.)
- Considere usar balanceadores de carga se necessário
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
4 613 messages |
|
| Posté le 10 juillet 2025 - 02:27 |
O NGINX é um servidor web de alto desempenho, mas também é amplamente utilizado como proxy reverso, balanceador de carga, servidor de cache e até como servidor de arquivos estáticos. No contexto do seu cenário com o W.A.S. (WebDev Application Server) limitado, o NGINX atua principalmente como proxy reverso e balanceador de carga, mas suas funcionalidades vão além disso. Abaixo, explico de forma clara, didática e profissional o que o NGINX faz, com foco no uso para escalar múltiplas instâncias do W.A.S., além de suas capacidades gerais.
O que o NGINX faz?
O NGINX é um software versátil que gerencia tráfego de rede, servindo como um ponto central para processar requisições HTTP/HTTPS e outras tarefas relacionadas. Suas principais funções incluem:
1 Servidor Web:
◦ Serve páginas web (HTML, CSS, JavaScript) e arquivos estáticos (imagens, vídeos, etc.) com alta eficiência.
◦ Exemplo: Hospeda diretamente um site estático ou entrega conteúdo de um CMS.
2 Proxy Reverso:
◦ Recebe requisições dos clientes (navegadores ou aplicativos) e as encaminha para servidores de backend (como o W.A.S.).
◦ Diferentemente de um proxy direto (usado por clientes para acessar a internet), o proxy reverso protege e gerencia servidores internos, escondendo sua estrutura do mundo externo.
◦ No seu caso, o NGINX distribui requisições entre várias instâncias do W.A.S., cada uma limitada a 10 conexões.
3 Balanceador de Carga:
◦ Distribui o tráfego entre múltiplos servidores ou instâncias para evitar sobrecarga.
◦ Métodos de balanceamento:
▪ Round-robin: Divide requisições igualmente entre as instâncias.
▪ Least connections: Envia requisições para a instância com menos conexões ativas.
▪ IP hash: Garante que o mesmo cliente sempre acesse a mesma instância (sticky sessions).
◦ Exemplo no seu cenário: O NGINX distribui requisições entre 10 instâncias do W.A.S., permitindo atender 100 conexões simultâneas (10 por instância).
4 Cache de Conteúdo:
◦ Armazena respostas de requisições frequentes (como imagens, CSS, ou páginas estáticas) para reduzir a carga nos servidores de backend.
◦ Exemplo: O NGINX pode servir arquivos estáticos diretamente, sem consultar o W.A.S., aumentando a performance.
5 Terminação SSL/TLS:
◦ Gerencia certificados HTTPS, descriptografando requisições antes de enviá-las ao backend e criptografando respostas.
◦ Isso reduz a carga nas instâncias do W.A.S., que não precisam lidar com criptografia.
6 Gerenciamento de Sessões:
◦ Suporta sticky sessions para manter um cliente conectado à mesma instância do backend, essencial para aplicações com login ou estado.
◦ Exemplo: No seu caso, o NGINX pode usar ip_hash para garantir que um usuário sempre acesse a mesma instância do W.A.S.
7 Outras Funções:
◦ Compressão: Reduz o tamanho de respostas (ex.: gzip).
◦ Reescrita de URLs: Modifica URLs para roteamento ou redirecionamentos.
◦ Controle de acesso: Limita acesso com base em IP, autenticação, ou regras específicas.
◦ Servidor de streaming: Suporta streaming de mídia ou WebSocket.
Como o NGINX funciona no seu contexto (W.A.S. Limitado)?
No cenário descrito, onde o W.A.S. Limited suporta apenas 10 conexões simultâneas por instância, o NGINX desempenha um papel crítico para escalar a aplicação e atender milhares de usuários. Aqui está como ele funciona:
Estrutura Operacional
1 Recebe requisições:
◦ Usuários acessam http://seusite.com ou https://seusite.com (portas 80 ou 443).
◦ O NGINX escuta essas portas e intercepta todas as requisições.
2 Distribui requisições:
◦ O NGINX usa a configuração do bloco upstream (como no exemplo do nginx.conf) para encaminhar requisições a uma das instâncias do W.A.S. (ex.: rodando nas portas 8100, 8101, …, 8109).
◦ Exemplo de configuração:
upstream webdev_cluster {
◦ server 127.0.0.1:8100;
◦ server 127.0.0.1:8101;
◦ # ... outras instâncias
◦ }
◦ server {
◦ listen 80;
◦ location / {
◦ proxy_pass http://webdev_cluster;
◦ proxy_set_header Host $host;
◦ proxy_set_header X-Real-IP $remote_addr;
◦ }
◦ }
◦
3 Gerencia respostas:
◦ A instância do W.A.S. processa a requisição e envia a resposta ao NGINX.
◦ O NGINX retorna a resposta ao usuário, mantendo a ilusão de um único servidor.
4 Escalabilidade:
◦ Com 10 instâncias do W.A.S., cada uma com 10 conexões, o NGINX permite até 100 conexões simultâneas.
◦ Com otimizações (como cache, keep-alive e sessões curtas), milhares de usuários podem ser atendidos, já que nem todas as conexões são mantidas ativas o tempo todo.
Exemplo Prático no Seu Cenário
Suponha que você tenha 10 instâncias do W.A.S. configuradas em portas de 8100 a 8109:
• O NGINX recebe 200 requisições de usuários.
• Ele distribui as requisições entre as instâncias, garantindo que nenhuma ultrapasse o limite de 10 conexões.
• Se uma instância falhar, o NGINX redireciona automaticamente para outras instâncias ativas (se configurado com max_fails e fail_timeout).
• Para usuários autenticados, o NGINX usa ip_hash para manter a consistência da sessão:
upstream webdev_cluster {
• ip_hash; # Sticky sessions
• server 127.0.0.1:8100;
• server 127.0.0.1:8101;
• # ...
• }
•
Benefícios do NGINX no Contexto do W.A.S.
1 Escalabilidade:
◦ Permite combinar várias instâncias limitadas para atender um grande número de usuários sem a versão FULL.
2 Alta Disponibilidade:
◦ O NGINX detecta instâncias inativas e redireciona o tráfego automaticamente.
3 Otimização de Performance:
◦ Cacheia conteúdo estático (ex.: imagens, CSS, JS), reduzindo a carga no W.A.S.
◦ Usa conexões keep-alive para minimizar latência.
4 Segurança:
◦ Esconde as instâncias do W.A.S. da internet, reduzindo a exposição a ataques.
◦ Suporta HTTPS para proteger dados em trânsito.
5 Flexibilidade:
◦ Permite configurações avançadas, como reescrita de URLs, compressão e controle de acesso.
Cuidados ao Usar NGINX com W.A.S.
1 Gestão de Sessões:
◦ Use sticky sessions (ip_hash) ou um banco de dados centralizado (ex.: Redis, MySQL) para evitar conflitos de sessão entre instâncias.
◦ Exemplo com Redis: Configure o W.A.S. para armazenar sessões em um servidor Redis compartilhado.
2 Conflitos de Arquivos:
◦ Cada instância do W.A.S. deve ter sua própria pasta de cache e arquivos temporários.
◦ Use um banco de dados centralizado para dados dinâmicos compartilhados.
3 Monitoramento:
◦ Monitore o uso de CPU e memória de cada instância (100-500 MB por instância, dependendo da carga).
◦ Use ferramentas como Prometheus ou Grafana para acompanhar o desempenho do NGINX e do W.A.S.
4 Otimização de Cache:
◦ Configure o NGINX para cachear conteúdo estático:
location ~* \.(jpg|jpeg|png|css|js)$ {
◦ expires 30d;
◦ access_log off;
◦ }
◦
5 Segurança:
◦ Habilite HTTPS com certificados SSL/TLS (ex.: Let’s Encrypt).
◦ Bloqueie o acesso direto às portas do W.A.S. (ex.: 8100-8109) via firewall.
Conclusão
O NGINX é uma ferramenta poderosa que, no contexto do W.A.S. Limited, permite escalar de 10 conexões para milhares ao atuar como proxy reverso e balanceador de carga. Ele distribui requisições entre múltiplas instâncias, otimiza performance com cache e melhora a segurança com HTTPS e isolamento. Com uma configuração adequada, como a descrita, é possível atender grandes volumes de tráfego sem depender da versão FULL do W.A.S., economizando recursos e mantendo alta disponibilidade.
Se precisar de mais detalhes, como configurar o NGINX em um sistema operacional específico, integrar com Redis para sessões, ou usar Docker para isolar instâncias, é só informar!
Essa explicação mantém o foco no papel do NGINX no seu cenário, com linguagem clara e exemplos práticos, enquanto aborda suas capacidades gerais de forma concisa.
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
4 613 messages |
|
| Posté le 10 juillet 2025 - 02:37 |
# Configuração Técnica Completa para WebDev Application Server com Múltiplas Instâncias
## Visão geral da arquitetura WebDev
Esta documentação técnica abrange a configuração completa de múltiplas instâncias do WebDev Application Server (W.A.S.), incluindo configuração nginx, scripts de automação Windows e procedimentos de implantação em produção. As informações foram compiladas a partir de documentação oficial PCSoft, experiências da comunidade e melhores práticas de produção.
## Parte 1: Configuração nginx para WebDev W.A.S.
### 1. Configuração completa nginx.conf para proxy reverso com múltiplos W.A.S.
```nginx
# /etc/nginx/nginx.conf - Configuração principal
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
use epoll;
multi_accept on;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Headers de segurança
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
# Otimizações de performance
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
# Compressão gzip
gzip on;
gzip_vary on;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
# Configuração de proxy reverso WebDev
server {
listen 80;
server_name webdev.example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
server_name webdev.example.com;
# Configuração SSL
ssl_certificate /etc/ssl/certs/webdev.pem;
ssl_certificate_key /etc/ssl/private/webdev.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
# Configurações específicas WebDev
client_max_body_size 100M;
# Recursos AWP WebDev
location /WD210AWP/res/ {
proxy_pass http://webdev_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
expires 1d;
add_header Cache-Control "public, immutable";
}
# Aplicações AWP WebDev
location /WD210AWP/ {
proxy_pass http://webdev_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Timeouts específicos WebDev
proxy_connect_timeout 30s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;
# Configurações de buffer
proxy_buffering on;
proxy_buffer_size 8k;
proxy_buffers 8 8k;
}
# Interface administrativa WebDev
location /WDADMINWEB210_WEB/ {
proxy_pass http://webdev_backend;
allow 192.168.1.0/24;
deny all;
}
# Manipulação de arquivos .awp
location ~ \.awp$ {
proxy_pass http://webdev_backend;
proxy_set_header Content-Type application/WebDev21-awp;
}
}
}
```
### 2. Load balancing entre diferentes instâncias WebDev
```nginx
# Configuração upstream para load balancing
upstream webdev_backend {
# Métodos de balanceamento disponíveis:
# Round-robin (padrão)
# ip_hash; # Persistência de sessão
# least_conn; # Menos conexões
least_conn; # Recomendado para WebDev
# Instâncias WebDev Application Server
server 127.0.0.1:8080 weight=3 max_fails=2 fail_timeout=30s;
server 127.0.0.1:8081 weight=2 max_fails=2 fail_timeout=30s;
server 127.0.0.1:8082 weight=1 max_fails=2 fail_timeout=30s;
# Servidor de backup
server 127.0.0.1:8083 backup;
}
# Configuração alternativa com persistência de sessão
upstream webdev_backend_sticky {
ip_hash; # Persistência baseada em IP cliente
server 127.0.0.1:8080;
server 127.0.0.1:8081;
server 127.0.0.1:8082;
}
```
### 3. Configuração upstream para diferentes versões WebDev
```nginx
# Suporte para múltiplas versões WebDev
upstream webdev_21_backend {
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:8081 weight=2;
}
upstream webdev_27_backend {
server 127.0.0.1:8082 weight=3;
server 127.0.0.1:8083 weight=3;
}
server {
listen 443 ssl;
server_name webdev21.example.com;
location / {
proxy_pass http://webdev_21_backend;
# Headers padrão...
}
}
server {
listen 443 ssl;
server_name webdev27.example.com;
location / {
proxy_pass http://webdev_27_backend;
# Headers padrão...
}
}
```
### 4. Configuração SSL/TLS para múltiplas instâncias
```nginx
# Otimização SSL para múltiplas instâncias WebDev
http {
# Configurações SSL globais
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
# Protocolos e cifras SSL
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
# HSTS
add_header Strict-Transport-Security "max-age=63072000" always;
# Múltiplos domínios com certificados diferentes
server {
listen 443 ssl;
server_name app1.webdev.com;
ssl_certificate /etc/ssl/certs/app1.pem;
ssl_certificate_key /etc/ssl/private/app1.key;
location / {
proxy_pass http://webdev_app1_backend;
}
}
# Certificado wildcard
server {
listen 443 ssl;
server_name *.webdev.example.com;
ssl_certificate /etc/ssl/certs/wildcard.webdev.pem;
ssl_certificate_key /etc/ssl/private/wildcard.webdev.key;
location / {
proxy_pass http://webdev_backend;
}
}
}
```
### 5. Virtual hosts para diferentes aplicações WebDev
```nginx
# Virtual hosts específicos por aplicação
server {
listen 443 ssl;
server_name crm.example.com;
# SSL config...
location / {
proxy_pass http://webdev_crm_backend;
proxy_set_header X-WebDev-App "CRM";
}
# Logging customizado
access_log /var/log/nginx/crm.access.log webdev_format;
error_log /var/log/nginx/crm.error.log;
}
server {
listen 443 ssl;
server_name erp.example.com;
location / {
proxy_pass http://webdev_erp_backend;
proxy_set_header X-WebDev-App "ERP";
}
access_log /var/log/nginx/erp.access.log webdev_format;
}
# Backend definitions
upstream webdev_crm_backend {
server 127.0.0.1:8080;
server 127.0.0.1:8081;
}
upstream webdev_erp_backend {
server 127.0.0.1:8082;
server 127.0.0.1:8083;
}
```
### 6. Timeout e buffer sizes específicos para WebDev
```nginx
server {
listen 443 ssl;
server_name webdev.example.com;
# Configurações específicas WebDev
client_max_body_size 100M; # Upload de arquivos grandes
client_body_timeout 60s; # Timeout de upload
client_header_timeout 60s; # Timeout de header
client_body_buffer_size 1M; # Buffer de upload
location / {
proxy_pass http://webdev_backend;
# Timeouts de conexão
proxy_connect_timeout 30s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
# Configurações de buffer para WebDev
proxy_buffering on;
proxy_buffer_size 8k;
proxy_buffers 8 8k;
proxy_busy_buffers_size 16k;
proxy_max_temp_file_size 1024m;
# Headers específicos WebDev
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
# Manipulação de cookies de sessão WebDev
proxy_cookie_path / "/; HttpOnly; Secure";
}
# Tratamento especial para uploads WebDev
location /upload {
proxy_pass http://webdev_backend;
# Timeouts estendidos para uploads grandes
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
# Buffer grande para uploads
client_max_body_size 500M;
proxy_request_buffering off;
}
}
```
### 7. Configuração de logs específicos por instância
```nginx
# Formato de log customizado para WebDev
http {
log_format webdev_format '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'rt=$request_time uct="$upstream_connect_time" '
'uht="$upstream_header_time" urt="$upstream_response_time" '
'sid="$upstream_http_x_session_id" '
'app="$upstream_http_x_webdev_app"';
# Logs por aplicação
server {
listen 443 ssl;
server_name webdev.example.com;
# Log principal
access_log /var/log/nginx/webdev.access.log webdev_format;
error_log /var/log/nginx/webdev.error.log warn;
# Logs específicos AWP
location /WD210AWP/ {
access_log /var/log/nginx/webdev.awp.log webdev_format;
proxy_pass http://webdev_backend;
}
# Logs da interface administrativa
location /WDADMINWEB210_WEB/ {
access_log /var/log/nginx/webdev.admin.log webdev_format;
proxy_pass http://webdev_backend;
}
}
}
```
### 8. Health checks para WebDev Application Server
```nginx
# Configuração de health check básica (nginx open source)
upstream webdev_backend {
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
server 127.0.0.1:8081 max_fails=3 fail_timeout=30s;
server 127.0.0.1:8082 max_fails=3 fail_timeout=30s;
}
# Script de health check customizado
location /health {
access_log off;
# Verifica se WebDev está respondendo
proxy_pass http://webdev_backend/WD210AWP/;
proxy_connect_timeout 5s;
proxy_read_timeout 5s;
# Resposta customizada
if ($upstream_status = 200) {
return 200 "WebDev Health OK\n";
}
return 503 "WebDev Health Failed\n";
}
```
## Parte 2: Scripts BAT para Gerenciamento de Múltiplas Instâncias
### 9. Script principal de inicialização múltipla
```batch
@echo off
:: ==================================================
:: WebDev W.A.S. Multi-Instance Manager
:: Versão: 1.0 - Produção
:: ==================================================
setlocal EnableDelayedExpansion
:: Variáveis de Configuração
set "SCRIPT_NAME=WebDev WAS Multi-Instance Manager"
set "LOG_DIR=%~dp0logs"
set "CONFIG_FILE=%~dp0was_config.txt"
set "BASE_PORT=8080"
set "MAX_INSTANCES=5"
set "WAS_SERVICE_PREFIX=WebDev_WAS_"
set "WAS_INSTALL_PATH=C:\Program Files\PC SOFT\WebDev Application Server"
:: Criar diretório de logs
if not exist "%LOG_DIR%" mkdir "%LOG_DIR%"
:: Gerar arquivo de log com timestamp
for /f "tokens=2 delims==" %%a in ('wmic OS Get localdatetime /value') do set "dt=%%a"
set "LOG_FILE=%LOG_DIR%\was_startup_%dt:~0,4%-%dt:~4,2%-%dt:~6,2%_%dt:~8,2%-%dt:~10,2%-%dt:~12,2%.log"
:: Verificar privilégios administrativos
net session >nul 2>&1
if %errorlevel% NEQ 0 (
echo ERRO: Este script requer privilégios de administrador.
pause
exit /b 1
)
call :LogMessage "INFO" "Iniciando %SCRIPT_NAME%"
call :LogMessage "INFO" "Configuração: Porta Base=%BASE_PORT%, Max Instâncias=%MAX_INSTANCES%"
:: Carregar configuração
call :LoadConfiguration
:: Verificar disponibilidade de portas e iniciar serviços
call :StartAllInstances
:: Monitorar serviços
call :MonitorServices
call :LogMessage "INFO" "Inicialização múltipla concluída"
pause
exit /b 0
:LogMessage
set "level=%~1"
set "message=%~2"
for /f "tokens=2 delims==" %%a in ('wmic OS Get localdatetime /value') do set "dt=%%a"
set "timestamp=%dt:~0,4%-%dt:~4,2%-%dt:~6,2% %dt:~8,2%:%dt:~10,2%:%dt:~12,2%"
echo [%timestamp%] [%level%] %message%
echo [%timestamp%] [%level%] %message% >> "%LOG_FILE%"
goto :eof
:LoadConfiguration
if exist "%CONFIG_FILE%" (
for /f "tokens=1,2 delims==" %%a in (%CONFIG_FILE%) do (
if "%%a"=="BASE_PORT" set "BASE_PORT=%%b"
if "%%a"=="MAX_INSTANCES" set "MAX_INSTANCES=%%b"
)
) else (
call :CreateDefaultConfig
)
goto :eof
:CreateDefaultConfig
(
echo BASE_PORT=%BASE_PORT%
echo MAX_INSTANCES=%MAX_INSTANCES%
echo WAS_INSTALL_PATH=%WAS_INSTALL_PATH%
) > "%CONFIG_FILE%"
goto :eof
:StartAllInstances
set "current_port=%BASE_PORT%"
for /L %%i in (1,1,%MAX_INSTANCES%) do (
call :FindNextAvailablePort !current_port!
if !found_port! NEQ 0 (
set "service_name=%WAS_SERVICE_PREFIX%%%i"
call :StartSingleInstance "!service_name!" !found_port!
set /a current_port=!found_port!+1
)
)
goto :eof
:FindNextAvailablePort
set "check_port=%~1"
set "found_port=0"
:FindPortLoop
netstat -an | findstr /r /c:":%check_port% " >nul 2>&1 [](https://stackoverflow.com/questions/47010989/how-to-check-if-port-8086-is-listening-using-a-windows-batch-file)
if %errorlevel% NEQ 0 (
set "found_port=%check_port%"
call :LogMessage "INFO" "Porta %check_port% disponível"
goto :eof
)
set /a check_port+=1
if %check_port% GTR 65535 (
call :LogMessage "ERROR" "Nenhuma porta disponível encontrada"
set "found_port=0"
goto :eof
)
goto :FindPortLoop
:StartSingleInstance
set "service_name=%~1"
set "port=%~2"
call :LogMessage "INFO" "Iniciando serviço %service_name% na porta %port%"
sc query "%service_name%" >nul 2>&1
if %errorlevel% NEQ 0 (
call :LogMessage "WARN" "Serviço %service_name% não encontrado"
goto :eof
)
sc start "%service_name%" >nul 2>&1
if %errorlevel% EQU 0 (
call :LogMessage "INFO" "Serviço %service_name% iniciado com sucesso"
) else (
call :LogMessage "ERROR" "Falha ao iniciar serviço %service_name%"
)
goto :eof
:MonitorServices
for /L %%i in (1,1,%MAX_INSTANCES%) do (
set "service_name=%WAS_SERVICE_PREFIX%%%i"
sc query "!service_name!" >nul 2>&1
if %errorlevel% EQU 0 (
for /f "tokens=4" %%s in ('sc query "!service_name!" ^| findstr "STATE"') do (
call :LogMessage "INFO" "Status do serviço !service_name!: %%s"
)
)
)
goto :eof
```
### 10-11. Verificação e configuração automática de portas
```batch
@echo off
:: ==================================================
:: Verificador de Portas para WebDev W.A.S.
:: Com configuração automática sequencial
:: ==================================================
setlocal EnableDelayedExpansion
set "START_PORT=8080"
set "END_PORT=8090"
set "REQUIRED_PORTS=5"
echo Verificando disponibilidade de portas de %START_PORT% a %END_PORT%
echo.
set "available_count=0"
set "available_ports="
for /L %%p in (%START_PORT%,1,%END_PORT%) do (
echo Verificando porta %%p...
:: Verificar se a porta está em uso
netstat -an | findstr /r /c:":%%p " >nul 2>&1 [](https://stackoverflow.com/questions/47010989/how-to-check-if-port-8086-is-listening-using-a-windows-batch-file)
if !errorlevel! NEQ 0 (
echo Porta %%p está DISPONÍVEL
set /a available_count+=1
set "available_ports=!available_ports! %%p"
:: Atribuir porta automaticamente à próxima instância
if !available_count! LEQ %REQUIRED_PORTS% (
echo Atribuindo porta %%p para WebDev_WAS_!available_count!
echo WebDev_WAS_!available_count!=%%p >> port_assignments.txt
)
) else (
echo Porta %%p está EM USO
:: Identificar processo usando a porta
for /f "tokens=5" %%i in ('netstat -ano ^| findstr ":%%p "') do (
set "pid=%%i"
for /f "tokens=1" %%n in ('tasklist /fi "pid eq !pid!" /fo csv /nh') do (
echo Usado por: %%n (PID: !pid!)
)
) [](https://www.ans.co.uk/docs/operatingsystems/windows/windowsadministration/netstat/)
)
)
echo.
echo Resumo:
echo Portas disponíveis: %available_count%
echo Lista de portas:%available_ports%
if %available_count% GEQ %REQUIRED_PORTS% (
echo SUCESSO: Portas suficientes disponíveis para instâncias WebDev W.A.S.
echo Configuração de portas salva em port_assignments.txt
exit /b 0
) else (
echo AVISO: Portas insuficientes disponíveis
exit /b 1
)
```
### 12-13. Inicialização ordenada com monitoramento
```batch
@echo off
:: ==================================================
:: Gerenciador de Dependências WebDev W.A.S.
:: Com monitoramento de status em tempo real
:: ==================================================
setlocal EnableDelayedExpansion
:: Definir ordem de dependências
set "DEPENDENCY_SERVICES=Apache2.4 MySQL80 WebDev_WAS_1 WebDev_WAS_2 WebDev_WAS_3"
echo Iniciando serviços em ordem de dependência...
echo.
for %%s in (%DEPENDENCY_SERVICES%) do (
call :StartServiceWithMonitoring "%%s"
)
echo.
echo Todos os serviços iniciados. Iniciando monitoramento...
call :ContinuousMonitoring
exit /b 0
:StartServiceWithMonitoring
set "service_name=%~1"
echo [%time%] Processando serviço: %service_name%
:: Verificar se o serviço existe
sc query "%service_name%" >nul 2>&1
if %errorlevel% NEQ 0 (
echo [!] Serviço %service_name% não encontrado
goto :eof
)
:: Verificar status atual
for /f "tokens=4" %%s in ('sc query "%service_name%" ^| findstr "STATE"') do (
set "current_state=%%s"
)
if "%current_state%"=="RUNNING" (
echo [OK] Serviço %service_name% já está em execução
goto :eof
)
:: Iniciar o serviço
echo [..] Iniciando %service_name%...
sc start "%service_name%" >nul 2>&1
if %errorlevel% EQU 0 (
:: Aguardar serviço iniciar completamente
set "retry_count=0"
:WaitLoop
timeout /t 2 /nobreak >nul
sc query "%service_name%" | findstr "STATE" | findstr "RUNNING" >nul 2>&1
if %errorlevel% NEQ 0 (
set /a retry_count+=1
if !retry_count! LEQ 10 (
echo [..] Aguardando %service_name% iniciar (tentativa !retry_count!/10)...
goto :WaitLoop
) else (
echo [!!] Timeout ao aguardar %service_name%
goto :eof
)
)
echo [OK] Serviço %service_name% iniciado com sucesso
) else (
echo [!!] ERRO: Falha ao iniciar %service_name%
)
goto :eof
:ContinuousMonitoring
cls
echo ================================================================
echo Monitor de Serviços WebDev W.A.S. - %date% %time%
echo ================================================================
echo.
for %%s in (%DEPENDENCY_SERVICES%) do (
call :CheckServiceStatus "%%s"
)
echo.
echo Pressione Ctrl+C para sair ou aguarde 30 segundos...
timeout /t 30 /nobreak >nul
goto :ContinuousMonitoring
:CheckServiceStatus
set "service_name=%~1"
sc query "%service_name%" >nul 2>&1
if %errorlevel% NEQ 0 (
echo [!!] %service_name%: NÃO INSTALADO
goto :eof
)
for /f "tokens=4" %%s in ('sc query "%service_name%" ^| findstr "STATE"') do (
set "service_status=%%s"
)
if "%service_status%"=="RUNNING" (
for /f "tokens=5" %%p in ('sc queryex "%service_name%" ^| findstr "PID"') do (
echo [OK] %service_name%: EXECUTANDO (PID: %%p)
)
) else (
echo [!!] %service_name%: %service_status%
)
goto :eof
```
### 14-15. Scripts de shutdown/restart com logging
```batch
@echo off
:: ==================================================
:: Gerenciador de Shutdown/Restart WebDev W.A.S.
:: Com logging completo de inicialização
:: ==================================================
setlocal EnableDelayedExpansion
:: Configuração
set "SERVICES=WebDev_WAS_5 WebDev_WAS_4 WebDev_WAS_3 WebDev_WAS_2 WebDev_WAS_1"
set "LOG_DIR=%~dp0logs"
set "ACTION=%~1"
:: Criar diretório de logs
if not exist "%LOG_DIR%" mkdir "%LOG_DIR%"
:: Gerar nome do arquivo de log
for /f "tokens=2 delims==" %%a in ('wmic OS Get localdatetime /value') do set "dt=%%a"
set "LOG_FILE=%LOG_DIR%\webdev_was_%ACTION%_%dt:~0,8%_%dt:~8,6%.log"
:: Verificar ação solicitada
if "%ACTION%"=="" set "ACTION=restart"
echo WebDev W.A.S. %ACTION% Manager
echo ==============================
call :WriteLog "Iniciando processo de %ACTION%" [](https://w3schools.tech/tutorial/batch-script/batch_script_logging)
if /i "%ACTION%"=="shutdown" (
call :ShutdownAll
) else if /i "%ACTION%"=="restart" (
call :RestartAll
) else (
echo Uso: %~nx0 [shutdown^|restart]
exit /b 1
)
echo.
echo Processo concluído. Verifique o log em:
echo %LOG_FILE%
pause
exit /b 0
:WriteLog
echo [%date% %time%] %~1
echo [%date% %time%] %~1 >> "%LOG_FILE%" [](https://w3schools.tech/tutorial/batch-script/batch_script_logging)
goto :eof
:ShutdownAll
call :WriteLog "Iniciando shutdown de todos os serviços WebDev"
for %%s in (%SERVICES%) do (
call :StopService "%%s"
)
call :WriteLog "Shutdown concluído"
goto :eof
:RestartAll
call :WriteLog "Iniciando restart de todos os serviços WebDev"
:: Primeiro parar todos os serviços
call :WriteLog "Fase 1: Parando serviços"
for %%s in (%SERVICES%) do (
call :StopService "%%s"
)
:: Aguardar para garantir liberação de recursos
call :WriteLog "Aguardando 10 segundos para liberação de recursos..."
timeout /t 10 /nobreak >nul
:: Reiniciar serviços em ordem reversa
call :WriteLog "Fase 2: Iniciando serviços"
for %%s in (WebDev_WAS_1 WebDev_WAS_2 WebDev_WAS_3 WebDev_WAS_4 WebDev_WAS_5) do (
call :StartService "%%s"
)
call :WriteLog "Restart concluído"
goto :eof
:StopService
set "service_name=%~1"
call :WriteLog "Parando serviço %service_name%..."
sc query "%service_name%" >nul 2>&1
if %errorlevel% NEQ 0 (
call :WriteLog " Serviço %service_name% não encontrado"
goto :eof
)
sc stop "%service_name%" >nul 2>&1
if %errorlevel% EQU 0 (
:: Aguardar serviço parar completamente
:StopWaitLoop
timeout /t 2 /nobreak >nul
sc query "%service_name%" | findstr "STATE" | findstr "STOPPED" >nul 2>&1
if %errorlevel% NEQ 0 goto :StopWaitLoop
call :WriteLog " Serviço %service_name% parado com sucesso"
) else (
call :WriteLog " ERRO: Falha ao parar %service_name%"
)
goto :eof
:StartService
set "service_name=%~1"
call :WriteLog "Iniciando serviço %service_name%..."
sc start "%service_name%" >nul 2>&1
if %errorlevel% EQU 0 (
:: Aguardar serviço iniciar
:StartWaitLoop
timeout /t 2 /nobreak >nul
sc query "%service_name%" | findstr "STATE" | findstr "RUNNING" >nul 2>&1
if %errorlevel% NEQ 0 goto :StartWaitLoop
call :WriteLog " Serviço %service_name% iniciado com sucesso"
) else (
call :WriteLog " ERRO: Falha ao iniciar %service_name%"
)
goto :eof
```
## Parte 3: Manual de Implantação em Produção
### 16-17. Procedimentos e checklist de implantação
**Checklist Pré-Implantação:**
- [ ] Windows Server 2019/2022 instalado e atualizado
- [ ] Apache 2.4 ou IIS 10+ configurado
- [ ] HyperFileSQL ou SQL Server instalado
- [ ] Licenças WebDev Application Server disponíveis
- [ ] Certificados SSL obtidos e prontos
- [ ] DNS configurado para domínios de produção
- [ ] Backup da infraestrutura atual realizado
- [ ] Plano de rollback documentado
**Procedimento de Implantação Passo a Passo:**
1. **Instalação WebDev Application Server**
```cmd
:: Executar instalador como administrador
WebDev27_Setup.exe /silent /components="server,admin,hfsql"
```
1. **Configuração Apache para WebDev**
```apache
# Adicionar ao httpd.conf
ScriptAlias /WD270AWP/ "C:/WebDev27/AWP/"
<Directory C:/WebDev27/AWP/>
Require all granted
</Directory>
AddType application/WebDev27-awp .awp
Action application/WebDev27-awp /WD270AWP/WD270Awp.exe virtual
```
1. **Configuração de Segurança Inicial**
- Acessar `http://servidor/WDAdminWeb270`
- Alterar senha padrão (admin/admin)
- Configurar políticas de senha
- Definir IPs permitidos para administração
### 18-19. Configuração Windows Server e Firewall
**Configuração Windows Server para WebDev:**
```powershell
# Script PowerShell para configuração inicial
# Executar como administrador
# Instalar recursos IIS necessários
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole, IIS-WebServer, IIS-CommonHttpFeatures, IIS-HttpErrors, IIS-HttpRedirect, IIS-ApplicationDevelopment, IIS-NetFxExtensibility45, IIS-HealthAndDiagnostics, IIS-HttpLogging, IIS-Security, IIS-RequestFiltering, IIS-Performance, IIS-WebServerManagementTools, IIS-ManagementConsole
# Configurar regras de firewall
New-NetFirewallRule -DisplayName "WebDev HTTP" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
New-NetFirewallRule -DisplayName "WebDev HTTPS" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow
New-NetFirewallRule -DisplayName "HyperFileSQL" -Direction Inbound -Protocol TCP -LocalPort 4900-4999 -Action Allow
New-NetFirewallRule -DisplayName "WebDev Admin" -Direction Inbound -Protocol TCP -LocalPort 8080-8090 -Action Allow -RemoteAddress 192.168.1.0/24
# Configurar serviços WebDev
Set-Service -Name "WebDev_WAS_1" -StartupType Automatic
Set-Service -Name "WebDev_WAS_2" -StartupType Automatic
Set-Service -Name "WebDev_WAS_3" -StartupType Automatic
# Otimizações de performance
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "TcpTimedWaitDelay" -Value 30
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "MaxUserPort" -Value 65534
```
### 20-21. Backup, restore e monitoramento
**Script de Backup Automatizado:**
```batch
@echo off
:: ==================================================
:: Script de Backup WebDev W.A.S.
:: Execução diária via Task Scheduler
:: ==================================================
setlocal
set "BACKUP_DIR=D:\Backups\WebDev"
set "WEBDEV_DIR=C:\WebDev27"
set "DATE_STAMP=%date:~10,4%%date:~4,2%%date:~7,2%"
:: Criar diretório de backup
mkdir "%BACKUP_DIR%\%DATE_STAMP%" 2>nul
:: Backup de aplicações
echo Fazendo backup das aplicações...
xcopy "%WEBDEV_DIR%\Applications" "%BACKUP_DIR%\%DATE_STAMP%\Applications" /E /I /Q
:: Backup de configurações
echo Fazendo backup das configurações...
xcopy "%WEBDEV_DIR%\Config" "%BACKUP_DIR%\%DATE_STAMP%\Config" /E /I /Q
:: Backup do banco de dados
echo Fazendo backup do banco de dados...
"%WEBDEV_DIR%\HFSQL\manta.exe" /backup /server:localhost:4900 /database:* /dest:"%BACKUP_DIR%\%DATE_STAMP%\Database"
:: Limpar backups antigos (manter últimos 30 dias)
forfiles /P "%BACKUP_DIR%" /D -30 /C "cmd /c if @isdir==TRUE rmdir /S /Q @path"
echo Backup concluído: %DATE_STAMP%
```
**Monitoramento com PowerShell:**
```powershell
# Monitor de Performance WebDev W.A.S.
param(
[int]$CheckInterval = 300, # 5 minutos
[string]$LogPath = "C:\Logs\WebDev_Monitor"
)
while ($true) {
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
# Verificar status dos serviços
$services = @("WebDev_WAS_1", "WebDev_WAS_2", "WebDev_WAS_3")
foreach ($service in $services) {
$svc = Get-Service -Name $service -ErrorAction SilentlyContinue
if ($svc) {
$status = $svc.Status
$logEntry = "$timestamp - $service : $status"
if ($status -ne "Running") {
# Tentar reiniciar serviço
Start-Service -Name $service -ErrorAction SilentlyContinue
$logEntry += " - Tentativa de restart"
}
Add-Content -Path "$LogPath\service_monitor.log" -Value $logEntry
}
}
# Monitorar uso de recursos
$cpu = Get-Counter '\Processor(_Total)\% Processor Time' | Select-Object -ExpandProperty CounterSamples | Select-Object -ExpandProperty CookedValue
$mem = Get-Counter '\Memory\Available MBytes' | Select-Object -ExpandProperty CounterSamples | Select-Object -ExpandProperty CookedValue
$perfLog = "$timestamp - CPU: $([math]::Round($cpu,2))% - Memória Disponível: ${mem}MB"
Add-Content -Path "$LogPath\performance.log" -Value $perfLog
# Verificar espaço em disco
$drives = Get-PSDrive -PSProvider FileSystem
foreach ($drive in $drives) {
if ($drive.Free -lt 1GB) {
$alertLog = "$timestamp - ALERTA: Disco $($drive.Name): tem menos de 1GB livre"
Add-Content -Path "$LogPath\alerts.log" -Value $alertLog
}
}
Start-Sleep -Seconds $CheckInterval
}
```
### 22-23. Performance tuning e melhores práticas
**Otimização para Múltiplas Instâncias:**
1. **Configuração de Pool de Conexões**
```ini
; WebDev connection pool settings
[Database]
MaxConnections=100
MinConnections=10
ConnectionTimeout=30
IdleTimeout=300
```
1. **Otimização de Memória por Instância**
```batch
:: Configurar limites de memória
sc config WebDev_WAS_1 obj= ".\WebDevUser1" password= "SecurePass1"
wmic process where name="WebDev_WAS_1.exe" CALL setpriority "above normal"
```
1. **Balanceamento de Carga Eficiente**
- Use `least_conn` no nginx para melhor distribuição
- Configure afinidade de sessão quando necessário
- Monitore distribuição de carga regularmente
**Melhores Práticas da Comunidade:**
1. **Preferir Linux para Performance**
- Comunidade relata melhor desempenho no Linux
- Windows Server 2012 apresentou problemas de performance
- Ubuntu Server é a escolha mais comum
1. **Gerenciamento de Permissões**
- Usuários devem ser membros do grupo `webdevadmin`
- Diretórios FTP devem ter permissões específicas
- Evitar execução com privilégios administrativos
1. **Monitoramento Proativo**
- Implementar alertas para uso de CPU > 80%
- Monitorar logs de erro em tempo real
- Realizar testes de carga regularmente
1. **Segurança em Produção**
- Sempre usar HTTPS em produção
- Implementar rate limiting
- Manter WebDev e dependências atualizados
- Realizar auditorias de segurança trimestrais
## Recursos Adicionais
**Documentação Oficial:**
- PCSoft Documentation: https://doc.pcsoft.fr/
- Fórum Oficial: https://forum.pcsoft.fr/
**Repositórios GitHub:**
- WebDev Docker: https://github.com/PCSOFT-WINDEV/WEBDEV
- HFSQL Docker: https://github.com/PCSOFT-WINDEV/HFSQL
**Ferramentas de Monitoramento Recomendadas:**
- Zabbix ou Nagios para monitoramento de infraestrutura
- ELK Stack para análise de logs
- Grafana para dashboards de performance
Esta documentação técnica fornece uma base sólida para implementação e manutenção de múltiplas instâncias WebDev Application Server em ambiente de produção, com foco em confiabilidade, segurança e performance.
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
4 613 messages |
|
| Posté le 12 juillet 2025 - 17:20 |
Com certeza. Rodar múltiplas versões do Servidor de Aplicação WebDev (W.A.S.) da PC SOFT no mesmo servidor é uma necessidade comum, seja para testes, migração de projetos ou para suportar aplicações desenvolvidas em versões diferentes do WebDev.
A arquitetura do W.A.S. foi projetada para permitir isso, mas exige atenção a alguns pontos-chave, principalmente o isolamento das instalações e o gerenciamento de portas.
Aqui está um guia detalhado de como fazer isso corretamente.
Conceitos Fundamentais
1. Instalação em Diretórios Separados: Cada versão do W.A.S. deve ser instalada em seu próprio diretório. Isso é crucial para evitar que os arquivos de uma versão sobrescrevam ou entrem em conflito com os de outra.
◦ Exemplo:
◦ Versão 28: `C:\PC SOFT\WEBDEV 28\W.A.S\`
◦ Versão 2024: `C:\PC SOFT\WEBDEV 2024\W.A.S\`
2. Serviços do Windows Independentes: Cada instalação do W.A.S. registrará seu próprio serviço no Windows. Eles terão nomes distintos, permitindo que você inicie, pare e gerencie cada versão de forma independente.
◦ Exemplo de nomes de serviço:
◦ `AwpService_WEBDEV_28`
◦ `AwpService_WEBDEV_2024`
3. Gerenciamento de Portas: Este é o ponto mais crítico. Dois serviços não podem “escutar” na mesma porta de rede ao mesmo tempo. O W.A.S. usa principalmente duas portas:
◦ Porta de Administração (padrão 7001): Usada pelo Administrador do W.A.S. para configurar os sites.
◦ Porta HTTP (padrão 80): Usada para servir as páginas dos sites aos usuários.
Você precisará configurar portas diferentes para cada instância do W.A.S.
Passos para a Instalação e Configuração
Vamos supor que você já tem o W.A.S. da versão 28 instalado e quer adicionar o W.A.S. da versão 2024.
Passo 1: Instalar a Nova Versão do W.A.S.
1. Execute o instalador do WebDev 2024.
2. Durante a instalação, quando for solicitado o diretório de destino, certifique-se de escolher um novo diretório. Não instale na mesma pasta da versão 28.
◦ Diretório sugerido: `C:\PC SOFT\WEBDEV 2024\`
3. Prossiga com a instalação do “Servidor de Aplicação WebDev (W.A.S.)”. O instalador é inteligente o suficiente para detectar uma versão existente e configurar o novo serviço com um nome diferente.
Passo 2: Configurar as Portas da Nova Instalação
Após a instalação, a nova instância do W.A.S. (v2024) provavelmente não iniciará, pois tentará usar as portas padrão (80 e 7001) que já estão ocupadas pela instância da v28. Você precisa alterar isso.
1. Abra o Administrador do Servidor de Aplicação WebDev correspondente à nova versão (2024). Você o encontrará no menu Iniciar, dentro da pasta do PC SOFT 2024.
2. Como o serviço não pode iniciar, o administrador pode mostrar um erro de conexão. Ignore-o e vá diretamente para a configuração.
3. Vá para a aba “Configuração Avançada” (Advanced configuration).
4. Localize os campos para as portas:
◦ Porta de escuta para o servidor de administração: Altere o valor padrão `7001` para um novo valor, por exemplo, `7002`.
◦ Porta de escuta para os sites (HTTP): Altere o valor padrão `80` para um novo valor, por exemplo, `81` ou `8081`.
5. Salve as alterações.
Passo 3: Iniciar o Serviço e Verificar
1. Abra os Serviços do Windows (`services.msc`).
2. Localize o serviço para a nova versão (ex: `AwpService_WEBDEV_2024`).
3. Inicie o serviço. Agora ele deve iniciar sem conflitos.
4. Abra novamente o Administrador do W.A.S. da v2024. Ele agora deve se conectar com sucesso (usando a nova porta de administração que você definiu, `7002`).
Resumo da Configuração Final

Como Acessar os Sites
Com essa configuração, os sites hospedados em cada servidor serão acessados por portas diferentes:
• Site na versão 28: `http://seuservidor.com/NOME_DO_SITE` (a porta 80 é implícita)
• Site na versão 2024: `http://seuservidor.com:81/NOME_DO_SITE` (é obrigatório especificar a porta `81`)
Usando um Proxy Reverso (Configuração Avançada)
Se você não quiser que seus usuários precisem digitar a porta (`:81`), a solução profissional é usar um Proxy Reverso, como o IIS (com o módulo ARR), Nginx ou Apache.
A ideia é:
1. O Proxy Reverso escuta na porta padrão 80.
2. Ele recebe todas as requisições.
3. Com base no nome do domínio ou no caminho da URL, ele decide para qual W.A.S. interno deve encaminhar a requisição (para a porta 80 ou para a porta 81).
Exemplo com IIS:
• Requisição para `site_v28.meudominio.com` -> Encaminha para `localhost:80`
• Requisição para `site_v2024.meudominio.com` -> Encaminha para `localhost:81`
Essa abordagem é mais transparente para o usuário final e é a prática recomendada para ambientes de produção.
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|