HELLO

WELCOME
Systems Analyst | DevOps Engineer
Vantagens de usar banco de  dados e aplicação no mesmo Pod

Marcelo L. Oliveira

DevOps Engineer

© 2023 Marcelo L. Oliveira. All Rights Reserved

jun 23, 2022
Vantagens de usar banco de dados e aplicação no mesmo Pod

Falando sobre Kubernetes, você sabe qual é a grande vantagem de se usar banco de dados e aplicação no mesmo Pod?

A resposta para essa pergunta é: NENHUMA!

Eu imagino que você já saiba o que é um Pod, mas vou reforçar: Pod é a menor unidade entregável no Kubernetes. Um Pod pode conter um ou mais containers.

Um Pod deve ser projetado para conter todos os containers que compartilham o mesmo ciclo de vida. Como a maioria das aplicações dependem de uma base de dados, isso pode dar a impressão de que acoplar ambos os recursos em um mesmo Pod pode parecer uma boa prática. Isso facilitaria a conexão, bastando apenas apontar a configuração da aplicação para o localhost. No entanto, vamos analisar outro cenário comum.

Imagine que você precise escalar sua aplicação. Se ela estiver acoplada ao banco, ao escalar um recurso, você estará automaticamente escalando o outro. Ao escalar ambos você terá falhas, já que o banco não foi projetado para ser um cluster.

Outro ponto importante a ser lembrado: mesmo que essa abordagem seja tecnicamente possível, elementos de uma arquitetura de microsserviços não devem ser fortemente acoplados, ou seja, colocar todos esses elementos em um único Pod definitivamente não é uma abordagem recomendada.

Espero que este post responda alguma das suas dúvidas.

More Details
jun 13, 2022
Resolvido: Unable to connect to the server: net/http: TLS handshake timeout

Usando Kubectl no Windows, recentemente me deparei com o seguinte erro:

Unable to connect to the server: net/http: TLS handshake timeout

O meu cenário era o seguinte: SO hospedeiro era o Windows 10, usando WSL com Ubuntu, VPN ativa e minikube para testes locais. Sempre que eu ativava um contexto em uma cloud e rodava o kubectl me deparava com essa mensagem de falha.

Desativa o proxy resolve o problema em alguns casos.

unset http_proxy

unset https_proxy

No meu caso, essa ação não foi suficiente, no entanto eu sabia que era um problema envolvendo redes. Pesquisando em alguns foruns comentários sobre MTU e com o comando seguinte eu testei a alteração da taxa:

sudo ifconfig eth0 mtu 1350

MTU (Maximum Transmission Unit) está relacionado à rede TCP/IP em sistemas Linux/BSD/UNIX. Refere-se ao tamanho (em bytes) do maior datagrama que uma determinada camada de um protocolo de comunicação pode passar por vez.

More Details
fev 22, 2022
Aprenda a Programar Programando

Aprenda a Programar Programando é um curso e mentoria criado para ajudar pessoas que estão saindo da faculdade, mas ainda não possuem experiência de projeto. É também para pessoas que estão afim de mudar de área profissional e estão querendo conhecer como é um projeto de software na vida real. Nada melhor do que participar de um projeto real para ter certeza se é isso que você quer para sua vida.

O curso é completamente voltado para o mercado de trabalho. Sendo assim, nós usamos linguagens de mercado, como Java, Python ou Go, ou alguma outra que tenha alta demanda por profissionais. Podemos usar frameworks. A escolha da linguagem e do framework vai depender da necessidade do projeto.

Abordamos conceitos chaves importantes para a construção do projeto. Não é só hands-on. Além de tudo que já foi falado, trabalhamos com Scrum, Git, Banco de Dados e API.

Quem participa desse projeto não chega em entrevistas com as mãos vazias ou sem ter o que dizer. É muito mais que um curso, é uma mentoria.

Se você quiser saber mais acesse https://mesavirtual.com. Siga esse projeto também nas redes sociais: Instagram https://www.instagram.com/mesavirtual/ e Twitter https://twitter.com/mesavirtual.

O que é a Mesa Virtual

É uma empresa de informática focada em preparar pessoas para o mercado de trabalho na área de Tecnologia da Informação. Os cursos e mentorias são online.

More Details
jun 28, 2021
Domain, model, entity: vamos falar de arquitetura

Este é um post para o programador ou analista de sistemas que busca algo além do simplesmente escrever códigos. É para aquele que se preocupa com os detalhes mais importantes do software, que prefere investir em planejamento do que ter que refazer as coisas.

Nos projetos mais complexos o desafio de desenhar soluções de sistemas tecnológicos fica por conta do arquiteto ou do engenheiro de software. O programador é o responsável pela execução. Aquele loop padrão: codificar, testar e commitar. No entanto, muitas vezes esse cara é único na empresa ou a função dele é única no departamento, ou seja, o programador é responsável por TUDO e nesses casos muitas vezes o sistemas não tem uma arquitetura definida.

Por outro lado, olhando agora para o software e não para o sistema, a arquitetura deste é definida pela escolha do framework. Flask, Spring Boot, Symfony, só para citar alguns. Geralmente o famigerado MVC(Model, View e Controller) é a primeira opção. Seguindo as documentações muitas vezes se consegue algo com qualidade no mínimo razoável. O problema é que em muitos casos o entendimento dessa arquitetura é negligenciado. As responsabilidades são confundidas e a benefícios dessa ou outra arquitetura não é atingido: baixo acoplamento, testabilidade, manutenibilidade, coesão, entre outras.

O objetivo deste post não é explicar a arquitetura MVC, mas simplesmente entender o M do MVC e encontrá-lo dentro de outras arquiteturas. Apenas decorar definições leva a uma zona de conforto que impede o analista/programador de extrair detalhes de negócios em conversas com não programadores, obter informações importantes e definir corretamente quais são as entidades da aplicação. Entender o domínio do negócio é essencial para uma modelagem apropriada.

Se você leu até aqui já deve ter percebido que quando falo de Model, de Domain e de Entidade, parece que estou falando da mesma coisa. São conceitos relacionados a modelos arquiteturais que na verdade tratam do mesmo assunto(ou objeto).

Model: em MVC a camada Model representa os dados e fornece as regras de acesso aos mesmos. Além disso é camada responsável pela lógica e regras de negócio.

Domain: em uma arquitetura hexagonal a camada chamada de domain ou de domínio trata simplesmente da lógica de negócio. Essa camada não provê o acesso aos dados, apenas as regras.

Entities: em Clean Architecture é a camada responsável pelas regras de negócio. Assim como na Hexagonal Architecture não faz o acesso aos dados.

Para se aprofundar no assunto, recomendo dois excelentes livros, seguem os links abaixo, em português e inglês.

Clean Architecture (Uncle Bob)

Domain Driven Design (Eric Evans)

More Details
abr 23, 2021
docker.service: Scheduled restart job, restart counter is at 3

Vez ou outra é possível que o administrador de sistemas, ao rodar um comando docker start ou docker status, se depare com um erro como esse do título. Segue a mensagem completa abaixo:

Essa mensagem é muito genérica e o que nós precisamos a partir daí é de mais informações, por isso o próximo passo deve ser o seguinte comando:

$ sudo dockerd –debug

A partir desse passo a mensagem de erro do seu servidor pode ser diferente da que eu tive no meu. No meu caso, evidenciado o seguinte erro:

O próximo comando foi o seguinte:

$ firewall-cmd –get-active-zones

E seu resultado:

Ele me mostra a interface docker0 em uma zona confiável, porém mostra que há uma outra zona chamada docker. Nesse caso, o que eu fiz foi adicionar a interface docker0 a zona docker.

$ sudo firewall-cmd –zone=docker –change-interface=docker0

Depois disso eu rodo o comando anterior:

$ firewall-cmd –get-active-zones

Vejo o seguinte resultado:

Após isso eu puder iniciar o docker normalmente. Agora quando dou o comando docker status vejo o seguinte:

De volta a normalidade.

More Details