Implantar o Apache Tomcat conectado ao MySQL Database Service

O Apache Tomcat® é um servidor de aplicativos Java de código-fonte aberto. Ele implementa as tecnologias Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket.

O MySQL Database Service é um serviço nativo Oracle Cloud Infrastructure totalmente gerenciado. Ele é desenvolvido, gerenciado e suportado pela equipe do MySQL no Oracle. Tarefas como backup e recuperação, aplicação de patches no banco de dados e no sistema operacional e assim por diante são automatizadas. Você é responsável exclusivamente por gerenciar seus dados, projetos de esquema e políticas de acesso.

Arquitetura

A arquitetura de referência contém um balanceador de carga, uma camada de aplicativo com o Apache Tomcat e uma camada de banco de dados com um Serviço MySQL Database ativado para HA.

Os componentes estão localizados em sub-redes diferentes. O balanceador de carga está em uma sub-rede pública. Os servidores Tomcat compartilham uma sub-rede privada e o banco de dados está em sua própria sub-rede privada. Todo o acesso externo é feito por meio do balanceador de carga por meio de um gateway de Internet.

O MySQL Database Service ativado por HA é uma abstração de um cluster. Tem três instâncias do MySQL, mas com um único ponto final. Uma instância é Primária e as outras duas instâncias são Secundárias. O Principal tem o único ponto final, permitindo leituras e gravações no banco de dados. Os Secundários recebem dados replicados do Principal. Não é permitido acesso direto aos Secundários.

Em caso de falha ou alternância manual, um dos Secundários se torna o novo Primário e o ponto final é redirecionado para ele. Isso significa que o endereço IP do ponto final nunca muda e não há necessidade de atualizar o aplicativo.

Um aplicativo de amostra que mostra o gerenciamento da sessão do aplicativo usando o banco de dados está incluído.

O diagrama a seguir ilustra essa arquitetura de referência.

Veja a seguir a descrição da ilustração architecture-deploy-tomcat-mds-ha.png
Descrição da ilustração architecture-deploy-tomcat-mds-ha.png

arquitetura-deploy-tomcat-mds-oracle.zip

Se a sub-rede for regional, as três instâncias do MySQL serão colocadas em diferentes Domínios de Disponibilidade e Domínios com Falha. Em regiões com um único Domínio de Disponibilidade, as instâncias do MySQL são colocadas em diferentes Domínios de Falha dentro do mesmo Domínio de Disponibilidade.

A arquitetura tem os seguintes componentes:

  • Região

    Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, chamados domínios de disponibilidade. As regiões são independentes de outras regiões e grandes distâncias podem separá-las (entre países ou mesmo continentes).

  • Domínios de disponibilidade

    Os domínios de disponibilidade são data centers independentes e independentes em uma região. Os recursos físicos em cada domínio de disponibilidade são isolados dos recursos nos outros domínios de disponibilidade, o que fornece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura, como energia ou resfriamento, ou a rede interna. Portanto, é improvável que uma falha em um domínio de disponibilidade afete os outros domínios de disponibilidade na região.

  • Domínios com falha

    Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falhas físicas do servidor, manutenção do sistema e falhas de energia dentro de um domínio de falha.

  • Rede virtual na nuvem (VCN) e sub-redes

    Uma VCN é uma rede personalizada e definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs permitem total controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, que podem ter escopo em uma região ou em um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contínuo de endereços que não se sobrepõem com as outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

  • Balanceador de carga

    O serviço Oracle Cloud Infrastructure Load Balancing fornece distribuição de tráfego automatizada de um único ponto de entrada para vários servidores no back-end.

  • Lista de segurança

    Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que devem ser permitidos dentro e fora da sub-rede.

  • Tabela de roteamento

    As tabelas de roteamento virtuais contêm regras para rotear o tráfego de sub-redes para destinos fora de uma VCN, geralmente por meio de gateways.

  • Gateway de Internet

    O gateway de internet permite o tráfego entre as sub-redes públicas em uma VCN e a internet pública.

  • Servidores Tomcat

    Os servidores Tomcat hospedam o Servlet Java, o JavaServer Pages, o Java Expression Language e o Java WebSockets. Seus aplicativos existem nesta camada.

  • Servidores de banco de dados

    O Tomcat pode se conectar a qualquer banco de dados que ofereça JDBC (Java Database Connectivity). Esta arquitetura usa o MySQL Database Service.

  • Host Bastion

    O bastion host é uma instância de computação que serve como um ponto de entrada seguro e controlado para a topologia de fora da nuvem. O bastião hospedeiro é normalmente provisionado em uma zona desmilitarizada (DMZ). Ele permite que você proteja recursos confidenciais colocando-os em redes privadas que não podem ser acessadas diretamente de fora da nuvem. A topologia tem um único ponto de entrada conhecido que você pode monitorar e auditar regularmente. Assim, você pode evitar expor os componentes mais sensíveis da topologia sem comprometer o acesso a eles.

Recomendações

Seus requisitos podem ser diferentes da arquitetura descrita aqui. Use as recomendações a seguir como ponto de partida.

  • VCN

    Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar a sub-redes na VCN. Use blocos CIDR que estão dentro do espaço de endereço IP privado padrão.

    Selecione blocos CIDR que não se sobreponham a nenhuma outra rede (no Oracle Cloud Infrastructure, seu data center local ou outro provedor de nuvem) para a qual você pretende configurar conexões privadas.

    Depois de criar uma VCN, você pode alterar, adicionar e remover seus blocos CIDR.

    Ao projetar as sub-redes, considere o fluxo de tráfego e os requisitos de segurança. Anexe todos os recursos em uma camada ou função específica à mesma sub-rede, que pode servir como um limite de segurança.

  • Balanceador de carga

    Esta arquitetura usa um balanceador de carga de 10 Mbps que está incluído na camada Always Free. Dependendo do número de conexões simultâneas necessárias e do throughput total, você pode usar formas maiores. O throughput pode ser editado a qualquer momento.

    Recomendamos que você use nomes DNS porque o endereço IP do balanceador de carga não pode ser reservado.

  • Instâncias

    Todas as tenancies obtêm duas instâncias de VM (Always Free Compute Virtual Machine), que essa arquitetura usa para os servidores Tomcat.

    Se for necessário mais poder de processamento, você poderá selecionar diferentes formas.

  • Sistemas de banco de dados

    Estabelecendo Conexão com o MySQL: Instale o cliente MySQL mais recente e também instale o MySQL Shell no Repositório Yum do MySQL. Consulte a seção Mais Informações para obter um link para usar o repositório do MySQL Yum.

  • Armazenamento

    As instâncias nesta arquitetura usam armazenamento em blocos regular; nenhum desempenho extra é necessário.

  • Conectividade de rede

    Você pode gerenciar o ambiente conectando-se à sua infraestrutura local existente usando uma VPN site a site ou uma conexão dedicada com o FastConnect.

    Se o ambiente precisar ser segregado da infraestrutura existente ou acessado externamente, um bastião host poderá proteger as conexões de gerenciamento. O bastião hospedeiro é normalmente provisionado em uma zona desmilitarizada (DMZ). Ele protege recursos confidenciais colocando-os em redes privadas que não podem ser acessadas diretamente de fora da nuvem. Você pode evitar expor os componentes mais sensíveis da arquitetura sem comprometer o acesso a eles.

Considerações

Considere os pontos a seguir ao implantar esta arquitetura de referência.

  • Desempenho

    Você pode ajustar o desempenho para corresponder às necessidades específicas do aplicativo alterando as formas da instância (se estiver usando a série Intel) ou OCPU e memória separadamente (se estiver usando a série AMD).

    A instância do banco de dados não pode ser alterada no momento. Escolha o tamanho adequado ao criá-lo.

  • Segurança

    Exceto para o host bastião (se presente) e balanceadores de carga, todos os componentes devem ser colocados em sub-redes privadas.

    Se for necessária uma segurança rigorosa, considere aproveitar as Zonas de Segurança do Oracle. Está incluído sem nenhum custo extra.

  • Disponibilidade

    O balanceador de carga vem com uma instância stand-by e não requer intervenção se ocorrer failover.

    Os servidores Tomcat são implantados como um par e são balanceados pelo balanceador de carga. Cada instância do Tomcat está localizada em um domínio de falha diferente.

    Faça backup do banco de dados quantas vezes forem necessárias para corresponder ao objetivo do ponto de recuperação pretendido (RPO).

    Embora pouco frequente, ajuste a janela de manutenção do MySQL Database Service para atender às necessidades da sua organização.

  • Custo

    O custo dessa arquitetura muda com base no tamanho e nas formas das instâncias, do banco de dados e dos balanceadores de carga. Não há componentes com custos variáveis.

Implantar

O código necessário para implantar esta arquitetura de referência está disponível no GitHub. Você pode inserir o código no Oracle Cloud Infrastructure Resource Manager com um único clique, criar a pilha e implantá-la. Como alternativa, faça download do código do GitHub para o seu computador, personalize-o e implante a arquitetura usando a CLI do Terraform.

  • Implantar usando o Oracle Cloud Infrastructure Resource Manager:
    1. Cliqueem Implantar no Oracle Cloud

      Se você ainda não tiver efetuado sign-in, informe as credenciais da tenancy e do usuário.

    2. Revise e aceite os termos e as condições.
    3. Selecione a região em que deseja implantar a pilha.
    4. Siga os prompts e instruções na tela para criar a pilha.
    5. Depois de criar a pilha, clique em Ações do Terraform e selecione Plano.
    6. Aguarde a conclusão do job e revise o plano.

      Para fazer alterações, retorne à página Detalhes da Pilha, clique em Editar Pilha e faça as alterações necessárias. Em seguida, execute a ação Plano novamente.

    7. Se nenhuma outra alteração for necessária, retorne à página Detalhes da Pilha, clique em Ações do Terraform e selecione Aplicar.
  • Implante usando o código Terraform no GitHub:
    1. Vá para o GitHub.
    2. Clone ou faça download do repositório para o computador local.
    3. Siga as instruções no documento README.

Log de Alterações

Este log lista apenas as alterações significativas: