O que realmente acontece quando você executa um comando com sudo?

Fala pessoal, tudo bem?

Quem utiliza Linux provavelmente já executou algum comando começando com sudo.

Por exemplo:

TERMINAL

sudo apt update

Ou:

TERMINAL

sudo systemctl restart nginx

Na prática, muita gente acaba entendendo o sudo apenas como uma forma de colocar a palavra “mágica” antes do comando e conseguir executá-lo.

Mas o que realmente acontece nesse momento?

O sudo não é simplesmente um atalho para “virar administrador”. Ele envolve autenticação, regras de permissão, alteração de identidade do processo e, dependendo da configuração, também registros de auditoria.

Vamos entender esse caminho.

O que significa sudo?

A palavra sudo vem de superuser do ou, em uma interpretação mais ampla, “executar como superusuário”.

O objetivo principal é permitir que um usuário autorizado execute um determinado comando com os privilégios de outro usuário.

Por padrão, esse outro usuário costuma ser o root, que possui o identificador UID 0 e tem poderes administrativos sobre o sistema.

Mas o sudo também pode executar comandos como outros usuários, não apenas como root.

Por exemplo:

TERMINAL

sudo -u joao whoami

Nesse caso, o comando será executado como o usuário joao, desde que a política de segurança permita essa operação.

Portanto, uma definição simples seria:

sudo permite que um usuário autorizado execute um comando com a identidade e os privilégios de outro usuário.

Por que não usar sempre a conta root?

Em um primeiro momento, pode parecer mais simples entrar diretamente como root e fazer tudo por lá.

Mas isso não costuma ser uma boa prática.

Quando estamos logados como root, qualquer comando executado possui privilégios administrativos. Um erro de digitação ou uma ação mal planejada pode causar consequências muito maiores.

Além disso, quando várias pessoas utilizam diretamente a mesma conta administrativa, fica mais difícil responder perguntas como:

• Quem executou determinado comando?
• Em qual horário isso aconteceu?
• Qual usuário realizou a alteração?
• A mudança foi feita manualmente ou por algum script?

Com o sudo, é possível manter os usuários em suas contas individuais e conceder privilégios administrativos somente quando necessário.

Esse modelo segue uma ideia importante de segurança:

Cada usuário deve possuir somente os privilégios necessários para realizar o seu trabalho.

Primeiro passo: o sudo identifica quem está solicitando o acesso

Quando executamos um comando com sudo, o sistema não olha apenas para o texto digitado.

Ele também identifica o usuário que está solicitando a operação.

Podemos descobrir nosso usuário atual com:

TERMINAL

whoami

E consultar informações adicionais com:

TERMINAL

id

O comando id pode mostrar o identificador do usuário, os grupos aos quais ele pertence e outras informações relacionadas à sua identidade no sistema.

Essa informação será utilizada pelo sudo para verificar se o usuário possui autorização para executar o comando solicitado.

Depois, o sudo consulta a política de segurança

O sudo precisa responder a uma pergunta:

Este usuário pode executar este comando como o usuário solicitado?

A política padrão costuma ser definida no arquivo:

TERMINAL

/etc/sudoers

Também podem existir arquivos complementares dentro do diretório:

TERMINAL

/etc/sudoers.d/

É nesse conjunto de configurações que o administrador define quem pode executar determinados comandos, em quais máquinas e como qual usuário.

Para consultar os comandos que o seu usuário pode executar com sudo, utilize:

TERMINAL

sudo -l

Dependendo da configuração do sistema, será solicitada a sua senha.

O resultado pode mostrar regras amplas, como a permissão para executar qualquer comando, ou regras mais restritas, permitindo apenas ações específicas.

O arquivo sudoers não deve ser editado de qualquer maneira

Um erro de sintaxe em uma configuração de privilégios pode impedir o uso do sudo e dificultar a administração do servidor.

Por esse motivo, a recomendação é utilizar o comando visudo para editar a configuração:

TERMINAL

sudo visudo

O visudo faz uma validação da sintaxe antes de aceitar a alteração.

Isso não significa que ele consiga identificar se a regra está correta do ponto de vista da segurança. Ele ajuda a evitar principalmente erros de formatação que poderiam deixar o arquivo inválido.

Por que o sudo pede a senha do usuário?

Quando a política exige autenticação, o sudo solicita a senha do usuário que está executando o comando.

Não é, necessariamente, a senha do root.

Isso é importante porque o objetivo é confirmar que a pessoa que iniciou a operação é realmente o usuário autenticado naquela sessão.

Um exemplo simples:

TERMINAL

sudo apt update

Ao digitar a senha, os caracteres normalmente não aparecem na tela. Não são mostrados asteriscos e o cursor parece ficar parado.

Isso é esperado.

A senha não está sendo exibida no terminal.

Depois que a autenticação é realizada com sucesso, o sudo pode manter essa validação em cache durante um período definido pela política do sistema. Assim, comandos seguintes podem não pedir a senha imediatamente.

Esse comportamento existe para evitar que o usuário precise se autenticar novamente a cada comando, mas o tempo de cache pode ser ajustado pelo administrador.

Se quiser invalidar a autenticação armazenada, você pode utilizar:

TERMINAL

sudo -k

Para validar ou renovar a autenticação sem executar outro comando, existe a opção:

TERMINAL

sudo -v

O comando não vira uma sessão root automaticamente

Existe uma diferença importante entre executar um comando com sudo e abrir uma sessão como root.

Quando fazemos:

TERMINAL

sudo apt update

apenas o comando apt update é executado com os privilégios autorizados.

Depois que ele termina, o terminal continua pertencendo ao usuário original.

Podemos perceber isso com um exemplo:

TERMINAL

whoami
sudo whoami
whoami

O primeiro whoami mostra o usuário atual.

O segundo mostra o usuário usado para executar aquele comando, normalmente root.

O terceiro volta a mostrar o usuário original da sessão.

Ou seja, o sudo eleva os privilégios do processo específico, não transforma permanentemente o usuário da sessão em administrador.

O que muda dentro do processo?

Quando o comando é autorizado, o sudo prepara o ambiente para executá-lo com a identidade do usuário de destino.

Isso pode envolver:

• Identidade real e efetiva do usuário.
• Grupos associados ao processo.
• Variáveis de ambiente.
• Diretório de trabalho.
• Máscara de criação de arquivos.
• Regras adicionais de segurança.

O processo passa a ter os privilégios necessários para realizar a operação permitida.

Por isso, um comando que falharia para um usuário comum pode funcionar quando executado com sudo.

Um exemplo é a leitura de determinados arquivos do sistema:

TERMINAL

cat /etc/shadow

Em muitos sistemas, um usuário comum não possui permissão para ler esse arquivo.

Já a execução com sudo pode permitir a leitura:

TERMINAL

sudo cat /etc/shadow

Mas atenção: conseguir executar um comando não significa que devemos executá-lo sem entender suas consequências.

Privilégio administrativo deve ser tratado com cuidado.

O ambiente não é exatamente o mesmo

Outro ponto que costuma causar confusão é imaginar que o comando com sudo recebe todas as configurações do usuário atual.

Isso nem sempre acontece.

Por motivos de segurança, o sudo pode filtrar ou redefinir variáveis de ambiente antes de executar o comando.

Esse comportamento ajuda a reduzir riscos envolvendo variáveis que poderiam alterar a forma como um programa é carregado ou executado.

Por isso, às vezes um comando funciona normalmente como usuário comum, mas apresenta um comportamento diferente com sudo.

Também é comum alguém executar:

TERMINAL

sudo comando

quando o que realmente queria era executar um redirecionamento com privilégios administrativos:

TERMINAL

sudo echo "texto" > /arquivo/protegido

Nesse exemplo, o echo é executado com sudo, mas o redirecionamento > é processado pelo shell do usuário atual. Se o arquivo estiver protegido, o comando pode falhar.

Uma alternativa mais apropriada para escrever o conteúdo é utilizar tee:

TERMINAL

echo "texto" | sudo tee /arquivo/protegido

Esse detalhe mostra que não basta apenas colocar sudo em qualquer parte da linha. Precisamos entender qual processo realmente está tentando acessar o arquivo.

sudo -i e sudo -s são a mesma coisa?

Não exatamente.

O comando abaixo solicita um ambiente semelhante ao de uma sessão de login do usuário de destino, normalmente root:

TERMINAL

sudo -i

Já o comando:

TERMINAL

sudo -s

solicita um shell com privilégios elevados, preservando mais características do ambiente atual, conforme as regras configuradas.

Em ambos os casos, é aberta uma sessão interativa com privilégios administrativos.

Mesmo assim, para tarefas pontuais, normalmente é mais seguro executar somente o comando necessário:

TERMINAL

sudo comando

Quanto menor o tempo em que estamos trabalhando com privilégios elevados, menor a chance de executar acidentalmente alguma operação administrativa.

O sudo também pode registrar as ações

Dependendo da configuração, tentativas bem-sucedidas e malsucedidas de uso do sudo podem ser registradas nos logs do sistema.

Esses registros ajudam em atividades de auditoria e investigação.

Eles podem responder, por exemplo:

• Qual usuário tentou executar o comando?
• Em que horário a tentativa aconteceu?
• O comando foi autorizado?
• A autenticação falhou?

Em um servidor, esse tipo de informação pode ser muito importante para entender uma alteração ou investigar um incidente.

Em configurações mais avançadas, também pode existir registro de entrada e saída do terminal durante a execução do comando.

Mais permissão não significa mais conhecimento

Um dos erros mais perigosos é acreditar que, se o comando funcionou com sudo, ele está automaticamente correto.

O sudo não valida a intenção do usuário.

Ele não sabe se você digitou o caminho certo.

Ele não sabe se o arquivo deveria ser apagado.

Ele não sabe se a configuração informada irá derrubar um serviço.

Ele apenas verifica se você está autorizado a executar aquela ação.

Por isso, antes de utilizar privilégios administrativos, vale conferir:

• O comando está correto?
• Estou no servidor certo?
• O caminho do arquivo está correto?
• Tenho um backup ou uma forma de desfazer a alteração?
• Entendi o que cada opção do comando faz?
• A mudança pode afetar outros usuários ou aplicações?

No ambiente de produção, essa conferência é ainda mais importante.

Princípio do menor privilégio

Se uma pessoa precisa reiniciar um único serviço, talvez não seja necessário permitir que ela execute qualquer comando como root.

Uma política mais restritiva pode liberar somente a ação necessária.

Por exemplo, em vez de permitir todos os comandos administrativos, o administrador pode definir uma permissão específica para uma operação controlada.

A ideia é reduzir o impacto caso uma credencial seja comprometida ou uma ação seja realizada de forma incorreta.

Esse conceito é conhecido como princípio do menor privilégio.

Ele aparece em servidores Linux, bancos de dados, aplicações, ambientes em nuvem e praticamente qualquer arquitetura que precise controlar acesso.

Então, o que aconteceu quando usamos sudo?

Podemos resumir o processo da seguinte forma:

1. O usuário solicita a execução de um comando.
2. O sudo identifica quem está fazendo a solicitação.
3. A política de segurança verifica se essa ação é permitida.
4. O usuário pode precisar se autenticar.
5. O ambiente do processo é preparado.
6. O comando é executado com a identidade e os privilégios autorizados.
7. A ação pode ser registrada nos logs.
8. Quando o comando termina, a sessão original continua com o usuário inicial.

Ou seja, aquela pequena palavra no começo do comando envolve uma série de mecanismos de segurança.

Finalizando

O sudo é uma ferramenta extremamente útil no dia a dia de quem trabalha com Linux.

Ele permite administrar o sistema sem a necessidade de utilizar a conta root o tempo todo, ajuda a individualizar as ações dos usuários e pode contribuir para auditoria e controle de acesso.

Mas é importante lembrar que ele não deve ser tratado como um simples “liberador de comandos”.

Cada execução com privilégios elevados deve ser feita com atenção e conhecimento do impacto que pode causar.

Uma boa prática é utilizar o menor privilégio possível, executar somente o comando necessário e revisar cuidadosamente as permissões definidas no sudoers.

Da próxima vez que você digitar sudo, lembre que, por trás dele, existe uma política verificando sua identidade, seus privilégios e a operação que está sendo solicitada.

Abs e até a próxima.

:wq!

Kubernetes do Zero - Parte 2: Preparando nosso laboratório e subindo nosso cluster

Fala pessoal, tudo bem?

Hoje vamos para a parte 2, da nossa sequência de postagens Kubernetes do Zero.

Vamos preparar nosso ambiente que servirá de laboratório para começarmos a colocar um pouco a mão na massa.

O ambiente

Para o laboratório eu vou utilizar a seguinte infraestrutura:

• Meu notebook rodando Windows
• Hypervisor – VirtualBox
• 3 VMs com Ubuntu server instalado (versão 26.04)

o   1 VM será o control plane

§  2 vCPUs

§  3 GB memória (pela documentação do kubernetes.io , pode ser apenas 2GB)

§  20 GB de disco

o   2 VMs serão os workers

§  2 vCPUs

§  3 GB memória (pela documentação do kubernetes.io , pode ser apenas 2GB)

• Placas em modo Bridge, assim as VMs receberão um IP da minha rede DHC.

Importante: Não precisamos instalar o Ubuntu nas 3 VMs. Podemos fazer a instalação de uma VM e depois usar o recurso de clone do VirtualBox. Assim poupamos um pouco de tempo de instalação. Apenas a parte da instalação e criação do cluster kubernetes que iremos fazer em cada uma devido a particularidade.

Preparação

Com as VMs criadas e com sistema operacional instalado, vamos agora fazer a preparação necessária antes de instalar o kubernetes e começar a subir nosso cluster.

Desativar o swap

O kubernetes exige que a memória swap seja desativada. Nas 3 máquinas vamos executar o seguinte comando:

sudo swapoff -a

É necessário com o vim, deletar a linha do swap no /etc/fstab e assim não fazer com que suba novamente caso o servidor reinicie.

Obs.: Isso deve ser feito nos workers também.

Carregar módulos do kernel

Para o kubernetes funcionar corretamente, precisamos carregar os módulos overlay e br_netfilter.

• Overley – sistema de arquivos de sobreposição que permitirá unir múltiplos diretórios ou partições em uma única estrutura de arquivos virtual e transparente.
• Br_netfilter – vai permitir que o tráfego de rede que passar por nossa interface de rede seja processado pelas regras do firewall Iptables.

No terminal, vamos executar o seguinte bloco de comandos:

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter

       Ativar o encaminhamento do IP (Sysctl)

Isso é necessário para que nosso Linux, seja capaz de funcionar como um roteador, repassando pacotes de dados de uma rede para outra.

No terminal, execute o seguinte bloco de comandos:

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
sudo sysctl –system

Instalar o containerd

Como falamos na primeira parte, o kubernetes não executa nativamente, por assim dizer os containers, então para isso vamos instalar o containerd. Ele será o nosso container runtime.

Novamente no terminal, execute o seguinte bloco de comandos:

sudo apt update
sudo apt install containerd -y
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

·        O kubernetes trabalha com cgroups.

Cgroups – ou control groups (grupos de controle), é um recurso do kernel do Linux que permite limitar, contabilizar e isolar o uso de recursos de hadware, como CPU, memória, I/O de disco e rede para um determinado grupo de processos.

Para isso funcionar, vamos permitir que o containerd use cgroups. No arquivo de configuração /etc/containerd/config.toml, o parâmetro SystemdCgroup será alterado de false para true.

Novamente no terminal, execute o seguinte bloco de comandos:

sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/'
/etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd

Pronto!!!

O que era pré-requisito já foi feito.

Só lembrando ... reforçando ... Esses procedimentos precisam ser feitos em todos os nós do cluster. No nosso caso, no nó 1 que é o control plane e no nó 2 e 3 que são os workers.

Agora, vamos adicionar o repositório do kubernetes nos 3 nós e instalar os pacotes necessários.

Instalando os pacotes base e os pacotes do kubernetes

Para adicionar o repositório e o certificado, vamos executar o bloco de comandos abaixo:

sudo apt install apt-transport-https ca-certificates curl gnupg
conntrack
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.37/deb/Release.key |
sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.37/deb/
/' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list

Para instalar o kubeadm, kubelet e kubectl, o bloco de comandos abaixo:

sudo apt update
sudo apt install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

 

O apt-mark hold serve para que toda vez que alguém executar o update/upgrade no servidor, não corra o risco de atualizar automaticamente o kubernetes também. Isso evita muita dor de cabeça para nada quebrar durante uma atualização não planejada.

Finalmente, vamos subir nosso cluster =]

Subindo nosso primeiro cluster kubernetes

Agora, esse comando será executado apenas no control plane. Que no nosso laboratório será a VM kub-node1

sudo kubeadm init --pod-network-cidr=10.244.0.0/16
--apiserver-advertise-address=<O IP QUE VAI FALAR COM OS NODES>

Veja que podemos informar o endereçamento de rede que queremos usar na comunicação interna (rede escolhida 10.244.0.0/16), entre os pods e também informar o IP do nosso apiserve que nada mais é do que nosso control plane (192.168.0.62)

Então no nosso caso, o comando ficaria assim:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16
--apiserver-advertise-address=192.168.0.62

Essa parte pode demorar um pouco, mediante a performance do ambiente e também da conectividade de rede/internet. Uma vez que começa toda a preparação de validar pré-requisitos e baixar tudo que é necessário para criar a estrutura do cluster.

Dando tudo certo, ao final teremos uma saída assim:

Veja que temos duas informações importantes aqui.

1° - Para podermos usar o cluster, com um usuário regular, temos alguns comandos a serem executados no control plane.

• Criar o diretório para o arquivo de configuração do kubernetes no nosso diretório home
• Copiar o arquivo de configuração do kubernetes para essa diretório criado no home do nosso usuário

·         Trocar o grupo e o dono para nosso usuário neste arquivo de configuração

2° - Não menos importante, veja que ele trás o comando que vamos precisar executar nos nodes workers para eles serem membros do nosso cluster efetivamente. Lembrando que para dar certo, precisamos executar com o sudo. Então ficaria assim, de acordo com nosso exemplo:

Sudo kubeadm join 192.168.0.62:6443 --token 48trth.zgu9q9l8t0tve24v
--discovery-token-ca-cert-hash sha256:0674a4a83bd943e86fc5a1784cd5d410c7571336bdb417dbb5b264bbb2876aa5

Dando tudo certo (que é o esperado), devemos receber um log semelhante a esse:

E por fim, para validar, no shell do servidor do control plane:

$ kubectl get nodes

 

Prontinho!!!

Nosso cluster está pronto, certo?

Só que não rs...

Veja que na coluna STATUS ainda temos tudo como NotReady. Mas por que será?

Ainda falta instalarmos nosso CNI para kubernetes e assim ele conseguir proporcionar a comunicação entre os pods. E aí sim, tudo estará funcional em nosso cluster para ele ficar pronto ... ou no caso, Ready.

Mas o que é CNI?

CNI (Container Network Interface) é uma especificação e conjunto de bibliotecas para as configurações de rede em containers. É através dele que temos a comunicação entre os pods e serviços facilitada.

Existem várias opções de CNI, como Calico, Flannel, Cilium e etc...

Eu gosto do Cilium, então ele será o CNI escolhido para o nosso ambiente.

Segue o site do projeto https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/ contendo todas informações e documentações.

De acordo com a página de documentação do Cilium, para instalarmos no nosso ambiente Linux que já contém um cluster, devemos rodar o seguinte bloco de comandos:

CILIUM_CLI_VERSION=$(curl -s
https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64;
fi
curl -L --fail --remote-name-all
https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}

 

Isso fará o download do binário do Cilium e o moverá para o diretório /usr/local/bin permitindo que você consiga executa-lo com seu usuário.

Após o download, vamos rodar a instalação com o comando:

$ cilium install

E vamos acompanhar o processo com o comando:

$ cilium status

Ou

$ cilium status -w

(isso fará com que o shell fique informando a cada atualização, sem que seja necessário executar o comando de status várias vezes)

É normal olharmos o status e aparecerem alguns erros durante o processo de subida. Isso ocorre devido ao cilium estar preparando o ambiente.

Se você tiver mais curiosidade e for impaciente como eu, o cilium faz o deploy dos seus serviços no namespace do kube-system. Para acompanhar podemos ver tudo com o comando:

$ kubectl get pods -n kube-system

Na coluna STATUS, iremos ver status de Init, ContainerCreating e dando tudo certo ... Running.

Assim que tudo estiver running, podemos validar novamente o status dos nodes:

$ kubectl get nodes

Agora sim. Nosso cluster está funcional no que diz respeito a todos os nodes estarem como Ready, com comunicação e visíveis para o control plane.

Fazendo um teste subindo nosso primeiro deployment

Para fazermos um teste bem rápido se está tudo OK, podemos rodar o seguinte comando:

$ kubectl create deployment nginx --image=nginx --replicas 4

Isso vai instruir a criação de um deploy do serviço do nginx, com 4 réplicas. Ou seja, 4 pods espalhados pelos workers.

O processo de subida dos pods pode demorar um pouco também, algo entre de 1 – 4 minutos. Mas vale levar em consideração que o kubernetes vai precisar baixar a imagem, fazer as criações e inicializações dos pods, então isso pode levar esse tempinho ou um pouco a mais.

Tudo como Running!

Que demais!!!

Mas será que o scheduler trabalhou direitinho e balanceou as réplicas pra gente? Já que ele é o responsável por este trabalho?

Vamos validar e para isso vamos executar o comando:

$ kubectl get pods -o wide

Veja que na coluna NODE, temos a informação de onde cada pod está rodando.

Como pedimos 4 réplicas, o scheduler colocou 2 réplicas no kub-node3 e 2 no kub-node2.

- Mas por que ele não usou o control plane, se ele é um node também?

Por via de regra, não teremos nossos pods em execução no control plane. É possível habilitar isso? Sim. Mas não é recomendado.

É até recomendado termos mais de um nó só para o control plane por questões de redundância e resiliência do nosso cluster.

- Eu consigo pegar mais informações dos nossos nodes?

Consegue sim. Basta executar o comando describe, da seguinte forma:

$ kubectl describe node kub-node2

Este é um exemplo do describe do node2

Aqui é apenas um trecho, pois a saída de informações é muito maior.

- Consigo fazer o describe também nos pods?

Sim!!!

$ kubectl describe pods nginx-69b9cdbbdd-bb8lj

Então, para reforçar:

•          Usamos o get quando queremos pegar alguma informação
•          Usamos o describe quando queremos pegar mais informações com detalhes

Finalizando a parte 2

Hoje aprendemos como preparar nosso ambiente para receber a instalação do kubernetes e como subir nosso primeiro cluster, contemplando a instalação do nosso CNI para permitir a comunicação entre os pods no ambiente e também como podemos validar se os nodes estão funcionando corretamente através de um deploy da aplicação do nginx.

Vamos ver o que nos espera na parte 3 ..., mas posso garantir pra vocês que essa jornada está apenas começando e ainda tem muita coisa legal para aprendermos.

Abs e até a próxima.