Forem: Paulo Alves

Versionamento de Banco de Dados com Liquibase

Paulo Alves — Fri, 15 Mar 2024 20:47:51 +0000

O Liquibase é uma ferramenta open-source que permite rastrear e controlar as alterações no esquema do seu banco de dados. Ele funciona como um sistema de controle de versão para seu banco de dados.

Benefícios do Versionamento de Banco de Dados

Rastreabilidade: Permite acompanhar todas as alterações feitas no banco de dados, facilitando a identificação de problemas e a reversibilidade de mudanças.
Facilidade de migração: Simplifica a migração de alterações para diferentes ambientes, como desenvolvimento, teste e produção.
Colaboração entre times: Permite que diferentes desenvolvedores trabalhem no mesmo banco de dados sem conflitos.
Segurança e confiabilidade: Reduz o risco de erros e garante a consistência do banco de dados.

Para começar a usar o Liquibase, você precisa:

Instalar o Liquibase: Acesse o site oficial https://www.liquibase.com/community e baixe a versão mais recente para o seu sistema operacional.
Criar um changelog: O changelog é um arquivo que armazena o histórico de todas as alterações feitas no banco de dados. Você pode criar o changelog manualmente ou usar a ferramenta de linha de comando do Liquibase.
Executar as mudanças: O Liquibase pode aplicar as mudanças no banco de dados de diversas maneiras, como através da linha de comando, scripts SQL ou ferramentas de integração contínua.

Bora praticar

Vamos criar uma tabela simples de usuários usando o Liquibase:

Crie um arquivo XML chamado "changelog.xml" na pasta do seu projeto e adicione o seguinte código ao arquivo:

<databaseChangeLog
  xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.3.xsd">

  <changeSet author="TESTE01" id="1">
    <createTable tableName="usuarios">
      <column name="id" type="integer" autoIncrement="true" primaryKey="true"/>
      <column name="nome" type="varchar(255)"/>
      <column name="email" type="varchar(255)"/>
    </createTable>
  </changeSet>

</databaseChangeLog>

Executar a mudança:

liquibase update

O Liquibase irá criar a tabela "usuarios" no banco de dados.

Alterar a tabela:

Vamos adicionar uma nova coluna à tabela "usuarios":

<changeSet author="TESTE01" id="2">
  <addColumn tableName="usuarios">
    <column name="data_nascimento" type="date"/>
  </addColumn>
</changeSet>

Executar a mudança:

liquibase update

O Liquibase irá adicionar a coluna "data_nascimento" à tabela "usuarios".

O Liquibase é uma ferramenta muito interessante quando se trata de versionamento de banco de dados. A ideia deste guia prático é oferecer uma visão inicial de seu funcionamento e possibilitando a manutenção consistente dos bancos de dados em diversos ambientes. Essa abordagem garante a uniformidade estrutural dos bancos de dados, tanto no ambiente de Desenvolvimento quanto no de Homologação, alinhando-os ao ambiente de Produção. Todo este processo, aliado à pipeline, torna a interação entre times ainda mais rápida.

Recursos Adicionais

Documentação do Liquibase: https://docs.liquibase.com/
Tutoriais do Liquibase: https://www.youtube.com/watch?v=dTmg8NNcWM4
Exemplos de Changelogs: https://docs.liquibase.com/start/design-liquibase-project.html

Simplificando a Entrega de Serviços em Nuvem com Cookiecutter e Terraform

Paulo Alves — Tue, 27 Feb 2024 22:13:40 +0000

Olá pessoal, Paulo Alves aqui compartilhando conhecimento e apresentando duas ferramentas poderosas que podem facilitar bastante o nosso dia a dia: Cookiecutter e Terraform.

E quando falo em facilitar nossa vida, é para não ficamos inventando a roda, começando tudo do zero. E neste caso vamos criar um template e podemos reutilizar ele quantas vezes forem necessário para garantir a entrega do ambiente para os time de desenvolvimentos ou até mesmo serviços que os time de DevOps, Cloud, Security, etc irão utilizar também.

Agilizando a Criação com Templates Personalizados utilizando Cookiecutter

O Cookiecutter é uma ferramenta incrível para a criação de templates personalizados. A prévia definição de um template traz benefícios notáveis, oferecendo estruturas base para documentos, designs e outros tipos de conteúdo. Suas funcionalidades principais incluem:
Criação de Templates: Possibilita a criação de modelos personalizados conforme as necessidades específicas de projetos.
Edição Simples: Facilita a modificação intuitiva de templates, tornando o processo acessível mesmo para usuários sem conhecimento avançado, já que tudo gira em torno de um simples json no processo básico.
Organização: Oferece recursos para organizar e categorizar templates, facilitando a busca e seleção do modelo desejado.
Compatibilidade: Pode ser integrado a diferentes plataformas ou softwares, garantindo compatibilidade e utilização eficiente dos templates.
Colaboração: Possibilita a colaboração entre usuários na criação e edição de templates, promovendo um fluxo de trabalho colaborativo, até mesmo pelo fato de ter que manter esses templates atualizados.
Versatilidade: Adapta-se a diversos tipos de templates, desde documentos de texto até designs gráficos, proporcionando versatilidade de uso.

Automatizando a Infraestrutura como Código utilizando Terraform

A segunda ferramenta é o Terraform, uma criação da HashiCorp, que automatiza a infraestrutura como código (IaC), proporcionando uma gestão eficiente da infraestrutura mantendo sempre o padrão inicial do projeto. Suas características e conceitos principais incluem:

Código Declarativo: Utiliza uma linguagem declarativa para descrever a infraestrutura desejada.
Provisionamento Multi-Cloud: Suporta provisionamento em várias nuvens, além de outros serviços como datadog, cloudflare, elastic, etc.
Controle de Estado: Mantém um arquivo de estado que registra o estado atual da infraestrutura.
Módulos Reutilizáveis: Organiza o código em módulos, possibilitando a reutilização de configurações em diferentes partes do projeto, promovendo modularidade e consistência.
Planejamento Prévio: Antes de efetuar qualquer alteração na infraestrutura, o Terraform fornece um plano detalhado das mudanças propostas.
Versionamento: Permite o versionamento do código de infraestrutura, facilitando o rastreamento de mudanças ao longo do tempo e a colaboração em equipe.

Criando uma VPC na AWS usando Terraform e Cookiecutter

Criando instâncias EC2 da Amazon com discos EBS Multi-Attach usando Terraform

Paulo Alves — Thu, 09 Mar 2023 18:13:19 +0000

Neste artigo, mostraremos como usar o Terraform para criar duas instâncias EC2 da Amazon com um discos compartilhado.

Neste artigo, mostraremos como usar o Terraform para criar duas instâncias EC2 da Amazon com um disco compartilhado.

Por padrão, o / terá apenas 8GB. Depois, será criado outro disco com 30GB para compartilhamento.

Algumas observações ao utilizar o EBS Multi-Attach:

Atualmente, a opção Multi-Attach está disponível apenas para volumes do tipo io1 e io2.
Outro ponto a ser testado é a diminuição do número de IOPS para que não haja um custo elevado na sua conta. No Terraform, defini o valor de 100.
Inicialmente, tentei criar as instâncias com a família t2.micro, mas não é possível trabalhar com o EBS Multi-Attach nessa configuração. Acabei alterando para a família t3.micro.

Depois que as instâncias subirem, os discos estarão disponíveis, mas não acessíveis. Para torná-los acessíveis, execute os comandos abaixo:

$ sudo mkfs -t ext4 /dev/nvme1n1
$ sudo mkdir /area51
$ sudo mount /dev/nvme1n1 /area51

E caso queira deixar em definitivo o disco montado basta executar o comando:

$ sudo echo "/dev/nvme1n1       /area51   ext4    defaults,nofail        0       0" >> /etc/fstab

Para que possa testar, de forma rápida e fácil segue o link do Terraform

E ai vamos nos conectar? Entre em contato comigo:
https://www.linkedin.com/in/pcmalves/

Monitoramento completo com EC2 + Grafana + Prometheus e Loki

Paulo Alves — Thu, 02 Mar 2023 21:52:38 +0000

Em um post passado fiz a criação do servidor do Grafana e instalação do plugin do Loki. Também montei um servidor com nginx padrão para se utilizado no envio dos logs.

Neste post quero trazer o monitoramento full de uma instância EC2, monitoramento de disco, cpu, rede, swap, processos que estão rodando na máquina e logs.

Não vou contemplar a criação do servidor do Grafana e nem o servidor que será monitorado. Já vou direto para o ponto onde vou subir o contêiner com o Prometheus, na máquina do server do Grafana e a configuração do dashboard para análise da saúde do ambiente.

Neste ponto já temos o docker instalado na instância do Grafana, com o contêiner do Grafana e Loki rondando. Agora vou subir o contêiner do Prometheus, mas antes vou baixar o arquivo de configuração e fazer a criação de um diretório onde ficará o arquivo de configuração para ser mapeado no contêiner do Prometheus. Segue abaixo os comandos:

sudo mkdir /docker && \
cd /docker && \
git clone https://gitlab.com/snippets/2484803.git && \
sudo mv 2484803 prometheus

Neste ponto já temos os arquivos de configuração, agora podemos subir o contêiner do Prometheus com esse arquivo de configuração.

docker run -d --name=prometheus \
--network monitoring \
-p 9090:9090 \
-v /docker/prometheus/prometheus.yml:/opt/bitnami/prometheus/conf/prometheus.yml bitnami/prometheus:latest

Se tudo estiver ok, deverá estar desta forma:

Com o contêiner do Prometheus up, vou iniciar a configuração do Datasource. Para isso vá em configurações > Plugins na busca digite Prometheus. Deve estar assim:

Selecionando o plugin do Prometheus irá para tela onde irei configurar o Datasource.

Selecione Create a Prometheus data source e faça o preenchimento das seguintes informações:

Feito isso clique em Salve & test
Neste ponto já temos o Datasource do Prometheus configurado com o Grafana.
Agora vou fazer as configurações na instância que será monitorada. Na instância que será monitorada eu irei configurar o node exporter, que é responsável por enviar as métricas para o Prometheus.

Instalando Node Exporter

Acesse via ssh a instância a ser monitorada. Esse servidor que será monitorado, eu estou utilizando Amazon Linux2. Com isso vou baixar o executável do node_exporter no diretório home do usuário ec2-user utilizando o comando abaixo:

wget https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-amd64.tar.gz

Você pode verificar aqui versões mais atualizadas do node_exporter.
Agora vou descompactar e renomear o diretório do pacote baixado:

tar xf node_exporter-1.5.0.linux-amd64.tar.gz && \
mv node_exporter-1.5.0.linux-amd64 node_exporter

Feito isso, vou acessar o diretório node_exporter e inciar o executável. Vou executar com nohup, para que minha sessão não fica presa ao executável. O comando fica assim:

nohup ./node_exporter &

Pressionando 2x o enter para liberar a console, deverá ficar desta forma:

Para certificar que está tudo ok, podemos acessar via browser:

http://ip_do_server_node_exporter:9100

Você deve ver uma tela igual a essa:

Agora vou voltar ao servidor onde está instalado o Prometheus para que posso adicionar o ip interno da instância a ser monitorada, para que possa fechar a comunicação entre eles.
No servidor do Prometheus vá no diretório docker/prometheus e edite o arquivo prometheus.yml. Se você estiver com o arquivo que eu disponibilizei, deverá editar somente a linha 28.

Basta salvar o arquivo, o servidor já irá começar a se comunicar com o agente. Você pode validar, acessando o Prometheus via browser.

http://ip_do_servidor_grafana:9090

Acessando no menu superior status > Service Discovery. Você será direcionado para essa tela:

Agora clicando em show more, terá no próprio servidor do Prometheus e o servidor que vou monitorar.

Configurações ok, vou para criação do dashboard de monitoramento de recursos e recebimento dos logs. A parte de config de recebimento de logs contemplei neste post
Para facilitar vou pegar um dashboard pronto e apenas importa-lo para o ambiente de teste. Selecione a opção Dashboard > + Import.

Nessa tela você vai adicionar o ID 1860 > load

A tela seguinte deverá estar desta forma:

Agora é clicar em import
Se estiver tudo ok, você deve visualizar algo:

Não esqueça de salvar o dash para não peder as configs..
Agora vou inserir a visualização dos logs, as configs para deixar o Loki funcional estão aqui.
Selecione add painel > add new panel

Add new panel, vamos selecionar o Datasource Loki

Agora vamos filtrar por labels:

Pode dar um Run queries para validar que está trazendo os logs do ambiente correto. Se o retorno estiver desta forma:

Basta dar um apply.
Para que você veja os logs sendo exibidos é necessário acessar o Nginx no servidor que está enviando os logs via browser, e ficar dando f5 na página para gerar conteúdo dentro do access.log.

Ambiente finalizado! Espero ter ajudo e nos vemos no próximo post

E ai vamos se conectar? Entre em contato comigo:
https://www.linkedin.com/in/pcmalves/

kubernetes ingress-controller '400 Bad request - plain HTTP request sent to HTTPS port'

Paulo Alves — Wed, 08 Feb 2023 01:32:26 +0000

Resolvi criar um material de consulta rápida e que pudesse compartilhar, sobre um problema que me consumiu uma quantidade de tempo considerável. E como consegui resolver, resolvi compartilhar...😎

Criei um cluster EKS do zero para testar algumas variações com Terraform.

Legal tudo ok, só que estava chamando a aplicação somente via HTTP e estava funcionando. Como teria um api gateway na frente, achei prudente que a chamada fizesse um redirect de HTTP para HTTPS.

Quando fiz este redirect foi onde comecei a receber a seguinte erro:

O único lugar que havia configurado redirecionamento era no ingress-controller. Decide ir debugando por partes, primeiro validei se a requisição chegava até o POD, isso não ocorria.

Então no service que crie para aplicação, alterei o parâmetro abaixo:
Antes

Depois

Com as alterações de redirects na parte do annotations, as requisições chegavam na aplicação.

Voltei o ambiente como estava antes, e fui pegar os logs do ingress-controller, as requisições chegavam mas dava 400. Com isso resolvi olhar para o service do ingress-controller.

Existe uma parte no service que estava assim:

E ficou assim:

Isso porque no meu caso em específico, o ingress que configurei para aplicação, estava apontando para porta 80.

Espero ter ajudar e até a próxima!!!

E ai vamos se conectar? Entre em contato comigo:
https://www.linkedin.com/in/pcmalves/

EC2 com logs centralizados utilizando Loki + FluentBit + Grafana

Paulo Alves — Wed, 25 Jan 2023 13:07:55 +0000

acessei via SSM e por ai vai. Se eu tivesse um lugar com os logs centralizados das instâncias EC2, eu poderia consultar os logs das instância com problemas e trabalhar na resolução.

Com isso surgiu a ideia de montar este artigo para documentar e ajudar outras pessoas. Neste artigo não reinventei a roda, fiz um compilado do que já existe nas documentações oficiais. Entre outras documentações que fui encontrando para facilitar na configurações.

Vou colocar aqui as adaptações que fiz para o meu cenário de atuação, mas também deixar de forma clara para que qualquer um possa utilizar.

OBS: Neste artigo estou seguindo com uma estrutura de VPC já criada na AWS para as 2 instâncias utilizadas no LAB

Vou fazer um apresentação rápida e básica dos serviços que serão utilizados neste artigo:

EC2 - é um serviço com recurso computacional, redimensionável e que pode ser utilizado para qualquer workload. Uma definição bem básica sobre este serviço disponibilizado pela AWS.

FluentBit - É o agente responsável por ler o arquivo de log e enviar para o Loki.

Grafana Loki - É uma stack de monitoramentos de logs.

Grafana Dashbord - É a ferramenta onde irei criar o dash de visualização de logs da instância que será utilizada como LAB.

Feito um breve resumo das ferramentas que serão utilizadas, vou iniciar a criação do servidor do Grafana.

Para criação do servidor que irá hospedar Grafana, Loki vou utilizar os comandos do awscli. Mas para criação deste ambiente poderia ter sido utilizado outras ferramentas de provisionamento e configurações, segue abaixo alguns exemplos de ferramentas

Um exemplo dessas ferramentas são: Terraform, Cloudformation, Ansible, Chef, Puppet

Criando uma instância do EC2

Para iniciar a criação da instância, ao invés de criar uma chave .pem vou importar a minha chave pública para acessar a instância:

aws ec2 import-key-pair --key-name "grafana-server" --public-key-material fileb://~/.ssh/id_rsa.pub

Na sequência vou criar um security group:

aws ec2 create-security-group --group-name grafana-server  --description "Grafana EC2 Server" --vpc-id vpc-668d120f

Agora vou criar 2 regras de ingress no security group criado:

aws ec2 authorize-security-group-ingress --group-id sg-02c489bbdeffdca1d --protocol tcp --port 22 --cidr 192.168.15/32

aws ec2 authorize-security-group-ingress --group-id sg-02c489bbdeffdca1d --protocol tcp --port 3000 --cidr 192.168.15/32

aws ec2 authorize-security-group-ingress --group-id sg-02c489bbdeffdca1d --protocol tcp --port 3100 --cidr 192.168.15/32

Na última regra liberando a porta 3100 ela é necessária para que o fluent-bit possa se comunicar com o Loki e fazer o envio dos logs.

Deixei as regras do security group somente para acesso da minha rede local

Criando a instância:

aws ec2 run-instances --image-id ami-0b5eea76982371e91 --instance-type t3.medium --key-name grafana-server --security-group-ids sg-0aa58857d399d42d0 --subnet-id subnet-0f322466aad742642 --associate-public-ip-address

Instalando e configurando Docker, Grafana e o Loki

Com o ambiente criado, vou seguir com a instalação do Grafana e Loki. Neste ponto vou subir 2 containers, que irão se comunicar pela rede interna do docker. Vou acessar a console para pegar o endereço público da instância. Para criação da instância utilizei a AMI com Amazon Linux 2, então o acesso será feito desta forma:

ssh ec2-user@ec2-174-129-133-73.compute-1.amazonaws.com

Logado na instância vou fazer a instalação do serviço do docker:

sudo yum update -y
sudo yum install docker -y
sudo service docker start
sudo usermod -a -G docker ec2-user

Após ter feito a instalação se receber a seguinte mensagem:

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json": dial unix /var/run/docker.sock: connect: permission denied

É necessário dar um logout e fazer o login novamente

Agora vou criar a rede no docker e subir o container do Grafana e do Loki

Criando a rede:

docker network create networklogs --driver bridge

Rede criada vou subir os 2 containers:

docker run -d --name=grafana --network monitoring -p 3000:3000 grafana/grafana-os

docker run -d --name=loki --network monitoring -p 3100:3100 grafana/loki

Se os 2 container subiram sem problemas, podemos acessar via browser a console do Grafana.

http://ec2-174-129-133-73.compute-1.amazonaws.com:3000

Se estiver tudo ok, essa tela deverá se exibida

Nessa tela o usuário e senha padrão é admin admin. Após logar você será solicitado a alterar a senha.

Logado na interface vamos fazer a config do Loki, para isso a engrenagem no painel lateral esquerdo > Plugins

Nos plugins vai na busca para procurar pelo plugin do Loki

Agora clique no botão azul Create a Loki data source

Agora vou preencher as informações solicitadas. Em url perceba que coloquei

http://loki:3100

Porque este endereço?

Lembra que incialmente eu cria uma rede interna docker, certo? Com isso ao invés de chamar

http://localhost:3100

Eu estou chamando na url pelo nome do container.

Feito as configs, pode clicar em Save & test. Caso aparece essa mensagem:

É porque ainda não estamos enviando os logs com os labels utilizado nas querys.

Ambiente do Grafana e Loki configurados, vamos configurar o ambiente que fará o envio dos logs. Aqui vou utilizar os mesmo comandos iniciais, já vou partir para o acesso via SSH e instalação do Nginx, que enviará os logs do access.log para o servidor do Loki.

Instalando Nginx no Amazon Linux 2

sudo yum install nginx -y

sudo service nginx start

Necessário somente instalar e dar start no serviço

Na instância onde o Nginx está instalado, é necessário que tenha o docker instalado também. Pois será necessário para subir o container do fluent-bit para que seja feito o envio dos logs.

Iniciando o container do fluent-bit para o envio dos logs, aqui vou utilizar a configuração padrão sem mexer em labels ou qualquer outra config. O valor da variável LOKI_URL vou colocar o ip interno da instância do servidor do Grafana, para que isso não passe pela internet para não termos gastos desnecessários.

docker run -d -v /var/log/nginx:/var/log/nginx -e LOG_PATH="/var/log/nginx/access.log" -e LOKI_URL="http://10.42.12.1:3100/loki/api/v1/push" grafana/fluent-bit-plugin-loki:latest

Assim que o container estiver up, de alguns acesse o Nginx pelo public DNS e de alguns F5 para gerar logs no access.log

Um detalhe, se for novamente na parte dos plugins, verá que aquela mensagem do Datasource que printei anteriormente na config do Loki não está mais aparecendo uma vez que estamos enviando os logs.

Vou validar se os logs estão chegando no Loki, para isso vou fazer um query. Na interface do Grafana, vá em Explore

Em label filters selecione o seguintes valores:

A query deverá fica desta forma. Agora vamos rodar a query e ver se temos os logs da instância do nginx.

Se na parte inferior, retornar desta forma

Funcionou com sucesso as configs.

Tentei demonstrar basicamente a criação de um servidor Grafana com plugin do Loki para coleta dos logs de um Nginx, instalado em uma instância EC2. Os logs aqui foram enviados utilizando o fluent-bit, com as configurações default. Aqui eu utilizei o fluent-bit para fazer a coleta e envio dos logs, mas poderia ser utilizado qualquer outro ship para o envio de logs, por exemplo o Promtail.

E ai vamos se conectar? Entre em contato comigo:
https://www.linkedin.com/in/pcmalves/

Referências:
https://hub.docker.com/r/grafana/fluent-bit-plugin-loki
https://grafana.com/docs/loki/latest/clients/fluentbit/
https://grafana.com/blog/2020/07/13/loki-tutorial-how-to-set-up-promtail-on-aws-ec2-to-find-and-analyze-your-logs/