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

Linux - Configuração de rede com Netplan

Exemplo de configuração de rede com Netplan:

$ vim /etc/netplan/00-installer-config.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses:
        - 10.0.0.1/24
      routes:
        - to: default
          via: 10.0.0.254
      nameservers:
          search: [meuDomain, outroDomain]
          addresses: [10.10.10.10, 10.10.10.11]

$ sudo netplan apply

 

Read More

Linux - Instalação minima

Já vos aconteceu usarem a instalação mínima e não terem ferramentas como o VI ou o Ping?! E depois reconfigurar a rede sem estas ferramentas?! Aqui ficam alguns comandos rápidos para desenrascar:

 

$ ip a add 192.168.0.10/24 dev eth0

$ echo "nameserver 8.8.8.8" > /etc/resolv.conf

$ ip route add default via 192.160.0.254

Ferramentas a instalar que podem ser necessárias:

$ apt-get install vim

$ apt-get install iputils-ping

# Instalar ifconfig, ...
$ apt-get install net-tools

# Instalar dig, Nslookup, ...
$ apt-get install bind9-utils

$ apt-get install telnet

Read More

LVM - Caso prático para estender um volume

Trago aqui um caso prático que me deparei esta semana. Aumentar um volume (VG - Volume Group) que contém 2 discos, ou seja, 2 Physical Volumes, onde um deles é uma partição e o outro é o disco inteiro:

vg-01 = /dev/sda2 (49GB) + /dev/sdb (151GB)

Podemos ver obter a informação acima com o comando pvdisplay.

Passos para incrementar o disco:

- Aumentar o disco físico nas propriedades da VM.

- No Linux, aumentar o PV.

- E de seguida aumentar o LV.

- E por fim aumentar o sistema de ficheiros.

$ pvresize /dev/sdb
$ lvextend -l +100%FREE /dev/vg-01/lv-01
$ resize2fs /dev/vg-01/lv-01

Comandos para verificar os vários passos:

pvdisplay - Verificar se o PV foi aumentado.

lvdisplay - Verificar se o LV foi aumentado.

fdisk - l - Identificar antes de toda a operação os discos e partições existentes.

df -h - Verificar se o aumento de espaço se refletiu.

Read More

Linux - O comando find

 

$ find /usr/share -name 'ficheiro.txt'

#Igual ao anterior mas com case insensitive:
$ find /usr/share -name 'ficheiro.txt'

#Encontrar todos os ficheiros que iniciem por f:
$ find /usr/share -name 'f*'

#Encontrar todos os ficheiros que Não iniciem por f:
$ find /usr/share -not -name 'f*'

$ find /usr/share -size +10M

#Econtrar ficheiro com o tamanho exato de 512k:
$ find /usr/share -size 512k

#Ficheiros modificados no último minuto:
$ find /usr/share -mmin -1

#Ficheiros modificados nas últimmas 24h
$ find /usr/share -mtime -0

#Ficheiros modificados nas últimmas 24h
$ find /usr/share -mtime -0

#Econtra pelo nome e pelo tamanho:
$ find -name 'ficheiro.txt' -size 10M

#Encontra pelo nome ou pelo tamanho:
$ find -name 'ficheiro.txt' -o -size 10M

$ find -perm 664

 

 

Read More

Kubernetes - Confuso em entre Deployments e ReplicaSet?

 

Difference Between Deployment and ReplicaSet in Kubernetes:

https://www.baeldung.com/ops/kubernetes-deployment-vs-replicaset

Read More

Linux - journalctl

Aqui ficam alguns comando do jornalctl que são uma alternativa à análise de logs tradicional do /var/log. 

$ journalctl -e

$ journalctl -p err

$ journalctl -p warning

$ journalctl /usr/bin/sudo

$ journalctl -u sshd.service

$ journalctl -f   #Fica ativo para ir mostrando os logs que estão a ser gerados

$ journalctl -S 04:00

$ journalctl -S 04:00 -U 05:00

$ journalctl -S '2022-11-11 13:05:00'

$ journalctl -b 0   #Logs desde o atual booy

$ journalctl -b -1   #Logs do boot anterior. (É preciso instruções adicionais)

$ last   #Histórico de logs de quem entrou no sistema

$ lastlog

Read More

Desaparecer com a mensagem "blk_update_request i/o eror dev fd0"

Este erro surge porque o módulo da floppy disk está instalado e algo a tentar usar, assim podemos remove-lo da seguinte forma:

sudo rmmod floppy
echo "blacklist floppy" | sudo tee /etc/modprobe.d/blacklist-floppy.conf
sudo dpkg-reconfigure initramfs-tools

Read More

Linux - Instalar uma versão especifica do Java

Uma forma rápida e fácil de instalar uma versão específica do java:

$ sudo curl https://download.java.net/java/GA/jdk20/bdc68b4b9cbc4ebcb30745c85038d91d/36/GPL/openjdk-20_linux-x64_bin.tar.gz --output /opt/openjdk-20_linux-x64_bin.tar.gz

$ sudo tar -xf /opt/openjdk-20_linux-x64_bin.tar.gz -C /opt/

$ /opt/jdk-20/bin/java -version

$ export PATH=$PATH:/opt/jdk-20/bin

 

 

Read More

Docker - Networking

Existem 3 tipos de rede por defeito no Docker: Bridge, None e Host.

Bridge - docker run ubuntu

O Docker cria esta rede privada interna por defeito no anfitrião (host, máquina virtual ou computador físico onde está a correr o Docker) e todos os containers obtêm um IP interno normalmente na gama 172.17.x.x. Os containers ligam-se uns aos outros usando esta rede interna.

Para as redes externas se ligarem a estes containers é preciso mapear portos de rede entre si (anfitrião:80 <-->container:8080).

None - docker run ubuntu --network=none

Os containers estão desligados de qualquer rede estando completamente isolados.

Host - docker run ubuntu --network=host

Outra forma de redes externas obterem acesso aos containers é associar o container à rede do anfitrião quebrando-se desta forma o isolamento que existe entre o anfitrião e o container. Assim, qualquer aplicação a correr no container num porto qualquer fica imediatamente exposto ao exterior no mesmo porto.

Por defeito o Docker cria uma rede interna para os containers comunicarem entre si na gama 172.17.x.x. É possível criar outra rede interna, noutra gama, com o seguinte comando:

$ docker network create --driver bridge --subnet 10.10.0.0/16 custom-isolated-network

DNS

Os containers conseguem comunicar entre si usando o seu nome que por sua vez é um nome DNS no servidor de nomes embebido no Docker.

Quando queremos que uma aplicação num container, aceda a outra noutro container, no mesmo Docker Host, podemos usar o IP interno (por exemplo: 172.17.0.3 <--> 172.17.0.8). Mas a forma mais correta é usar o nome do container, uma vez que ao reiniciar o container, este pode não assumir o mesmo IP.

O servidor DNS embebido no Docker é executado com o IP 127.0.0.11.

Read More

Docker - Comandos básicos mais usados

Deixo aqui alguns dos comandos (básico) mais usados no Docker:

$ docker ps

$ docker ps -a

$ docker rm CONTAINER

$ docker rmi IMAGEM

$ docker run ubuntu

# -it disponibiliza uma shell interativa
$ docker run -it ubuntu
$ docker run -it ubuntu bash

$ docker run -d centos sleep 500

$ docker images

$ docker pull nginx

$ docker run -d ubuntu sleep 500

$ docker exec CONTAINER_ID cat /etc/*release*

$ docker stop $(docker ps -aq)

$ docker rm $(docker ps -aq)

$ docker run -i CONTAINER

# -p mapeia o porto 80 do anfitrião para o 5050 do container nginx
$ docker run -p 80:5050 nginx
$ docker run -p 3306:3306 mysql

# Executa o container mysql mapeando a dir /var/lib/mysql na dir /dados/mysql do anfitrião(host), de forma a persistir os dados:
$ docker run -v /dados/mysql:/var/lib/mysql mysql

# Obter informações do container no formato json:
$ docker inspect CONTAINER

$ docker logs CONTAINER

 

 

Read More