Sei que muitos se deparam com esse problema, então vou deixar essa dica rápida.
Quando estamos testando algo em desenvolvimento, ou seja, no localhost, raramente temos um certificado HTTPS instalado, mas o Chrome teima em redirecionar as requestes HTTP para HTTPS.
A solução é uma configuração no próprio browser. Acesse a seguinte URL:
chrome://net-internals/#hsts
Na tela de configuração, procure a seção “Delete domain security policies” e no campo “Domain” insira o domínio, no caso, “localhost”, conforme mostra a imagem abaixo.
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.
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.
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.
É 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.
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.
