Azure | App Gateway - Tutorial de implantação e configuração

Neste tutorial vou-me focar apenas no Azure Aplication Gateway (App GW). Vou reaproveitar os backends criados neste tutorial - backend01 e backend02.

Para implantar o Azure Application Gateway há alguns componentes obrigatórios de configurar como os assinalados na figura seguinte:

Backend pools - Os anfitriões de backend para onde será encaminhado/balanceado o tráfego.

Backend settings - Configurações de acesso aos backend, por exemplo, o porto de rede, ssl (se tiver), etc.

Frontend IP configurations - O IP de entrada (inbound) do App Gw. Pode ser público ou não.

Listeners - Aceitam ligação de entrada com base no IP, porta de rede, e protocolo, direccionando estas ligações para o backend apropriado.

Rules - São regras que combinam os listeners e as configurações de backend de forma a encaminhar o trafego para o backendpool certo.

Health probes - É um mecanismo que verifica periodicamente o estado dos backends através de consultas http/https. O encaminhamento para cada um destes endpoints é feito tendo em conta o estado de saúde de cada um.

Ainda como requisito obrigatórios, a App GW precisa de uma subnet própria só para este efeito e um front end IP (publico, privado ou ambos),

Nas figuras seguintes podemos os vários passos do assistente de configuração do Application Gateway.

1. Configurações básicas

2. Configuração/criação do Frontend IP

3. Escolher o conjunto de backends que vão responder

Nota: Neste caso um pouco hipotético por ser um lab de testes, criei 2 backend pools apenas com uma VM cada.

 3.1. Figura já com os 2 backend adicionados.

4. Criar a regra de encaminhamento

Ao verificar a a figura abaixo, neste momento já temos o Frontend IP e os Backend pool. Falta adicionar uma regra de encaminhamento. Vamos criar a regra rule01 e rule02.

Durante a criação da regra temos de seleccionar ou criar um Listener para cada cada encaminhamento que se pretende fazer. Neste caso prático, criei 2 listeners no porto 80 para escutar o tráfego vindo para site1.20-238-134-187.nip.io e site2.20-238-134-187.nip.io. Portanto, iremos esperar tráfego destes dois sub-sites ou sub-dominios de 20-238-134-187.nip.io.

Nota: O nip.io é um serviço disponível na Internet em que podem usar o vosso IP público como se fosse um endereço de DNS. O IP público é convertido para um nome substituindo os pontos por traços (20.238.134.187 -> 20-238-134-187). É muito útil para fazer testes em laboratório, como este.

Continuando na regra que estamos a criar (por exemplo rule01), temos ainda de combinar qual o Backend pool (Backend target) que a regra vai usar. Para a rule01 usamos o backendpool01 e rule02 o backendpool02.

De notar que existem variadas configurações que podem fazer desde Multisite, encaminhar para um caminho (/site1 ou /site2), especificar um url para o caso de erros específicos como 502 ou 403, etc.

Depois de criar o App GW é testar se tudo funciona. Se estão a fazer testes no Azure, não se esquecem de eliminar todos os Resources depois de acabarem os testes, caso contrário vão ficar a consumir e a conta vai-vos chegar ao fim do mês :).

Caso encontrem algum erro, não se acanhem, comentem! :D

Read More

Azure | Tópicos de estudo para a certificação Az-104

(Conteúdo em atualização)

Conteúdos Essenciais para a Certificação AZ-104: Administrador do Azure

1. Identidades e Governança do Azure

   • Azure Active Directory (AD): Configuração e gestão de utilizadores e grupos.

   • RBAC (Role-Based Access Control): Permissões e atribuições.

   • Políticas e Iniciativas do Azure: Aplicação de políticas de governação.

2. Implementação e Gestão de Armazenamento

   • Tipos de Armazenamento: Blobs, ficheiros, discos geridos e não geridos.

   • Armazenamento de Dados: Configuração e gestão de contas de armazenamento.

   • Recuperação de Desastres: Backup e recuperação de dados.

3. Implementação e Gestão de Recursos de Computação

   • Máquinas Virtuais (VMs): Criação, configuração e escalabilidade.

   • Escalabilidade: Conjuntos de escalabilidade de máquinas virtuais e instâncias reservadas.

   • Soluções de Computação Serverless: Funções do Azure.

4. Configuração e Gestão de Redes Virtuais

   • Redes Virtuais (VNets): Configuração de VNets e sub-redes.

   • Gateways de VPN: Configuração de VPNs e conexões de rede privada.

   • Balanceamento de Carga: Configuração de balanceadores de carga e rotas de tráfego.

5. Monitorização e Backup de Recursos do Azure

   • Monitorização: Configuração de métricas, logs e alertas.

   • Azure Monitor: Utilização de Insights, Alertas e Log Analytics.

   • Backup e Recuperação: Configuração de políticas de backup e execução de restaurações.

Read More

Azure | Tutorial prático - Como criar um Azure Load Balancer com 2 backends

Este tutorial faz parte do estudo que estou a realizar para a certificação AZ-104. Demonstra como criar um Azure Load Balancer para balancear o tráfego entre duas máquinas virtuais de backend. O objetivo não é explorar ou explicar todas as configurações e opções disponíveis.

1. Criar o Resource Group, VNet e Subnet:

az group create --location westeurope --name backend_RG

az network vnet create --resource-group backend_RG --name backend_VNET --address-prefix 10.0.0.0/16

az network vnet subnet create --resource-group backend_RG --vnet-name backend_VNET --name backend_SUBNET01 --address-prefix 10.0.1.0/24

Backend01: Criar a interface de rede (NIC), Public IP (PIP)  e associar a NIC ao PIP:

az network nic create --resource-group backend_RG --name backend01_NIC01 --vnet-name backend_VNET --subnet backend_SUBNET01

az network public-ip create --resource-group backend_RG --name backend01_PIP01

az network nic ip-config update --resource-group backend_RG --nic-name backend01_NIC01 --name ipconfig1 --public-ip-address backend01_PIP01

Backend02: Criar a interface de rede (NIC), Public IP (PIP)  e associar a NIC ao PIP:

az network nic create --resource-group backend_RG --name backend02_NIC01 --vnet-name backend_VNET --subnet backend_SUBNET01

az network public-ip create --resource-group backend_RG --name backend02_PIP01

az network nic ip-config update --resource-group backend_RG --nic-name backend02_NIC01 --name ipconfig1 --public-ip-address backend02_PIP01

2. Criar VM backend01:

az vm create \
--resource-group backend_RG \
--name backend01 \
--nics backend01_NIC01 \
--image Canonical:UbuntuServer:18.04-LTS:latest \
--size Standard_DS1_v2 \
--admin-username azureuser \
--generate-ssh-keys

Criar uma NSG, criar uma regra inbound para permitir tráfego 22 (ssh) e associar a NSG à NIC do backend01:

az network nsg create --resource-group backend_RG --name backend_NSG

az network nsg rule create --resource-group backend_RG --nsg-name backend_NSG --name Allow-SSH --priority 1000 --destination-port-ranges 22 --direction Inbound --access Allow --protocol Tcp --description "Allow SSH"

az network nic update --resource-group backend_RG --name backend01_NIC01 --network-security-group backend_NSG

Obter o endereço IP público do backend01, aceder via ssh e instalar o NGINX:

az vm list-ip-addresses --name backend01 --output table
ssh azureuser@IP-Publico
sudo apt-get -y update && sudo apt-get -y install nginx

Adicionar uma descrição ao index.html, para sabermos qual o backend que estamos a aceder quando usarmos o IP do LB:

sudo vim /var/www/html/index.nginx-debian.html

<h1>Welcome to nginx! - backend01</h1>

Abrir o porto 80 para inbound (desta vez via portal):

Portal Azure > backend01 > Networking > Network settings > Rules > + Create port rule:

Verificar se o NGINX funciona:

Colocar no navegador de internet o ip público do backend01 e deverão ter uma resposta do NGINX:
...

Welcome to nginx! - backend01
...

3. Criar a VM backend02:

Nota: Na criação deste VM, usei outra forma propositadamente para dar a conhecer o parâmetro --custom-data que permite que depois da VM criada seja executado um script. Neste caso, instala o nginx, inicia o serviço e altera o index.html.
Mais info: https://learn.microsoft.com/en-us/azure/virtual-machines/custom-data.

Criar o ficheiro cloud-init.txt com o conteúdo mais abaixo. Podem usar o comando vi cloud-init.txt:

#cloud-config
package_upgrade: true
packages:
  - nginx
runcmd:
  - systemctl start nginx
  - sed -i 's/<h1>Welcome to nginx!<\/h1>/<h1>Welcome to nginx! - backend02<\/h1>/' /var/www/html/index.nginx-debian.html

Criar a vm backend02 usando como parâmetro o script cloud-init.txt:

az vm create \
--resource-group backend_RG \
--name backend02 \
--nics backend02_NIC01 \
--image Canonical:UbuntuServer:18.04-LTS:latest \
--size Standard_DS1_v2 \
--admin-username azureuser \
--ssh-key-values ~/.ssh/id_rsa.pub \
--custom-data cloud-init.txt

Agora não precisamos de criar uma nova NSG, vamos apenas associar a backend_NSG à interface de rede backend02_NIC01:

az network nic update --resource-group backend_RG --name backend02_NIC01 --network-security-group backend_NSG

Abrir o porto 80 para inbound:

az vm open-port \
    --port 80 \
    --resource-group "backend_RG" \
    --name backend02

Verificar se o NGINX funciona:

Colocar no navegador de internet o ip público do backend01 e deverão ter uma resposta do NGINX:
...

Welcome to nginx! - backend02
...

4. Criar o Load Balancer

Iremos criar um LB básico de L4 (Camada 4), ou seja, o reencaminhamento do tráfego será via sockets (IP:porto).

Como existe mais que uma solução de balanceamento de tráfego no Azure, o mais simples é colocar na barra de pesquisa do portal Azure "Load Balancing - Help me choose". Uma vez, destro deste assistente vamos respondendo a questões até o Azure no sugerir o melhor LB:

Does your application use HTTP/HTTPS? [No]

Is your application public (internet facing)? [Yes]

Is your application deployed in multiple regions? [No]

Se respondermos desta forma termos a sugestão de um Load Balancer com L4. Clicamos em Create.

4. Testes a efetuar:

Num navegador de internet colocar o IP público do load balancer e verificar que backend é aberto. Lembrem-se que adicionamos uma desrcição (backend01 ou backend02) no index.html para termos a certeza de qual backend nos será mostrado.

Podemos efetuar várias refrescamentos do browser para ver se o backend é alterado. Podemos também forçar a desligar um dos backends para ver se o LB encaminha para a VM disponível.

5. Conclusão

Criámos um load balancer baseado em encaminhamento de IP:porto, ou seja, tudo o que chega a determinado IP público é encaminhado para um de dois backends (backend01 e backend02). Começámos por criar as componentes de rede, bem como as interfaces de rede a serem usadas nas VMs. Para além de criar as VMs, foi também necessário criar um NSG com uma regra para conseguirmos ligar por SSH para efetuar a instalação de pacotes e algumas alterações.

Neste tutorial, tentei demonstrar como realizar alguns passos através do Azure CLI e outros através do Portal do Azure. Após criar o load balancer, os PIPs dos backends podem ser removidos para melhorar a segurança e evitar a exposição dessas VMs à internet pública.

Explorar:

Podem agora criar uma nova VM (backend03), inseri-la num novo backend e encaminhar por exemplo o tráfego no porto 81 do IP público para o 80 do backend03. 
Explorem as várias opções disponíveis no load balancer, por exemplo, as Session persistence (None, Client IP e Client IP and Protocol) que podem ser interessantes dependendo objetivo que se pretende.

Criar uma Inbound NAT rule par adirecionar tráfego apenas para uma VM ou as Outbound rules para controlar o tráfego de saídas das VM são outras configurações a explorar.

Mais info:

https://learn.microsoft.com/en-us/training/modules/improve-app-scalability-resiliency-with-load-balancer/4-exercise-configure-public-load-balancer?pivots=bash

https://learn.microsoft.com/en-us/training/modules/configure-azure-load-balancer/7-create-health-probes

https://learn.microsoft.com/en-us/training/modules/configure-azure-load-balancer/2-determine-uses

https://learn.microsoft.com/en-us/training/modules/improve-app-scalability-resiliency-with-load-balancer/5-internal-load-balancer

Read More

Bash - Mastering Arrays in Bash Scripting

Um video de como fazer um script em bash utilizando arrays:

https://www.youtube.com/watch?v=K2plzc4vJvw

Read More

Os 12 Comandos GIT mais usados

git init - Initialize a new Git repository.
git clone - Clone a remote repository to your local machine.
git status - Check the current state of your working directory.
git add - Stage changes for the next commit.
git commit - Record staged changes and create a snapshot.
git push - Upload local changes to a remote repository.
git pull - Fetch and merge changes from a remote repository.
git branch - List, create, or delete branches.
git checkout / git switch - Switch between branches or commits.
git merge - Integrate changes from one branch into another.
git diff - View differences between working directory and staging area.
git log - Display a chronological list of commits.

Read More