é muito comum achar que colocando a sua aplicação no kubernetes vai rodar tudo de forma escalável e sem problema nenhum Mas você sabia que a sua aplicação precisa ter alguns requisitos para isso realmente acontecer e que sem eles o sonho de ter aplicações escaláveis e de grande porte no kubernetes pode acabar virando um pesadelo Então nesse vídeo eu vou te mostrar cinco itens para você checar na sua aplicação para você saber se ela tá pronta ou não para ser executada de forma correta e eficiente no kubernetes Então bora [Aplausos] [Música] lá Fala aí beleza seja
bem-vindo seja bem-vinda a mais esse vídeo aqui no canal eu sou Fabrício Veronez e eu tô aqui para ajudar você a desenvolver aplicações escaláveis e de grande porte utilizando Cloud devops então se você quer saber mais sobre esse assunto se inscreve aí no canal aciona o sininho que toda semana tem conteúdo como esse aqui e não esquece de dar um like pro vídeo pro YouTube entender que esse conteúdo é de qualidade e Vale a Pena Ser distribuído e conheça também o devops pro o meu treinamento para você ser capaz de criar aplicações escaláveis e de
grande porte utilizando Cloud devops eu vou deixar o link aí embaixo para você preencher com as suas informações que a minha equipe vai entrar em contato com você para entender o seu momento e te ajudar certo bom então a gente vai falar aqui agora sobre um assunto que é importante muitas vezes é ignorado que é preparar a sua aplicação para ser executada no cluster kubernetes hoje quando a gente quer colocar a nossa aplicação para ser executada de forma escalável resiliente e principalmente em ambientes de alta disponibilidade aplicações de grande porte de cara vem o kubernetes
né e muitas vezes a gente acha que pegar a aplicação colocar lá cutar um Cub CTL Aleluia cara a aplicação vai rodar ali perfeitamente garantindo todos esses requisitos mas não é bem assim a sua aplicação ela precisa tá pronta para ser executada nesse tipo de ambiente e eu não tô falando aqui só do kubernetes não serviços de gerenciamento de aplicações nos Cloud providers também vão precisar desses requisitos então se você quer colocar a sua aplicação num ambiente da aws do do Google da Oracle não importa essas práticas vão ajudar você não só a garantir esses
requisitos de escalabilidade e resiliência mas Vai facilitar também a configuração da sua aplicação E é isso que faz você desenvolvedor você desenvolvedora se destacar no mercado não só saber codificar a aplicação mas deixar ela pronta para ser executada em ambientes escaláveis e de grande porte então eu separei aqui alguns itens que eu quero explicar para você que você deve fazer E porque você deve fazer para executar nesses ambientes e eu espero que você pegue cada um desses itens coloque aí no seu checklist e Garanta que isso tá sendo implementado antes de colocar para rodar no
ambiente de produção Independente se vai ser no kubernetes se vai ser num SS se vai ser num aure apps num Cloud Run não importa pega essa lista marca aí verifica se sua aplicação tá atendendo esses requisitos certo então vamos lá bom primeiro item aqui é configuração separada do código Pode até parecer meio Óbvio algumas pessoas vão falar assim ah pô legal Fabrício pô configuração separada do código mas muitas vezes a gente por est ali com pressa ou achar que essa configuração não vai mudar a gente pega ali uma Connection string ou uma chave de acesso
ou endereço de um um serviço externo que a gente tá trabalhando e coloca direto lá no código coloca lá hard code no código e isso não só é um problema de vulnerabilidade porque muitas vezes esses dados são sensíveis são informações que podem ser pegadas ali do código e utilizadas para outros fins mas também configurar o seu ambiente fica muito mais complexo porque muitas vezes essa chave ou esse endereço ele vai ser utilizado em diversos lugares da aplicação e muitas vezes a galera pega lá faz um copy pasting de cada parâmetro ali coloca onde precisa e
quando tem que mudar brother é uma dor de cabeça porque tem que ir em diversos lugares diferentes Então você pegar toda essa configuração de Connection string chave de acesso endereço de um serviço externo e colocar desacoplado da sua aplicação como elemento de configuração dela vai simplificar não só a execução da sua aplicação num ambiente mas também vai garantir muito mais segurança confiabilidade e Vai facilitar a sua manutenção e eu não tirei isso aqui da minha cabeça não se você verificar lá no tel Factor apps que são 12 fatores 12 práticas que são recomendadas para se
criar aplicações baseadas em microsserviços aplicações modernas escaláveis e de grande porte você vai verá tá que o terceiro fator terceiro item ele fala justamente sobre isso sobre pegar sua configuração e colocar de forma desacoplada na sua aplicação Mas beleza como é que a gente pode fazer isso né como é que a gente separa a configuração da nossa aplicação eu tenho duas formas de fazer isso certo normalmente a primeira forma é utilizando um arquivo de configuração pode ser um arquivo pon env pode ser ali um arquivo Jon um arquivo emou XML tanto faz mas a gente
normalmente pega um arquivo com todos esses parâmetros e coloca ali junto com a aplicação e toda vez que precisa alterar essas configurações vai lá altera no arquivo e executa a aplicação essa forma ela funciona né a gente não pode falar que não funciona você consegue desacoplar essas configurações da sua aplicação porque assim simplesmente alterar um arquivo mas eu tenho um problema em relação a isso você primeiro você vai ter problemas de padronização que muitas vezes você vai utilizar ali arquivo json arquivo XML vai utilizar ali um outro formato de arquivo não existe ali um formato
padrão para fazer essas configurações fora que esse tipo de configuração ele não é agnóstico ele não funciona em diversas aplicações diferentes porque você tem que cuidar desse tipo de formatação e um outro problema que eu vou ter aqui é que sempre quando eu trabalho com arquivos e contes o que que vai acontecer ou eu pego e crio uma nova imagem quando eu altero essa configuração da minha aplicação e isso vai me dar um esforço a mais porque eu vou ter que fazer ali a criação de uma nova imagem e aí eu vou ter que fazer
todo o versionamento enfim como também eu vou ter que eu não optar por utilizar o o a criação de imagem eu vou ter que trabalhar com volume eu vou ter que mapear um volume no meu ambiente e apontar lá pro contêiner para ele pegar essas configurações então quando eu trabalho com arquivo eu vou ter que ou criar uma imagem nova que vai me dar aí um esforço maior não só de criação da imagem como também de versionamento dessa imagem ou vou ter que trabalhar com volume isso me dá muito mais Complex cidade então Eh você
utilizar arquivos de configuração não necessariamente vai ser a melhor forma inclusive isso tá também no tril Factor apps a melhor forma de você fazer as suas configurações na aplicação é utilizando variáveis de ambiente né onde você configura uma variável de ambiente no seu sistema operacional e a aplicação pega essa variável e configura a aplicação essa forma é é interessante porque você consegue trabalhar de uma forma agnóstica porque todo o sistema operacional tem variável de ambiente e fica padronizado ali a forma de não só configurar mas também da aplicação e capturar essas variáveis e cara configurar
isso em um ambiente de contêiner em ambiente de nuvem cara ó é molezinha de fazer isso então se você quer fazer com que a sua aplicação ela seja muito mais fácil de configurar para executar em ambientes de nuvem Independente de ser kubernetes ou não Você deve utilizar sim variáveis de ambiente é uma boa prática e você deve conferir aí se hoje a sua aplicação trabalha dessa forma se você consegue trabalhar é de forma configurável na sua aplicação desacoplando toda a configuração do código e utilizando variáveis de ambiente para isso então Já tem aí o primeiro
item para você conferir bom o segundo item aqui parece até meio óbvio mas é importante sim você pensar nisso que é a aplicação ela precisa est sendo executada precisa est rodando em contêiners E aí você pode estar pensando pô Fabrício mas se eu vou botar no kubernetes a aplicação ela precisa est sendo executada em contêiners sim mas muitos profissionais pulam a etapa de aprendizado de docker de contêiners para utilizar o kubernetes E aí muitas vezes você tá tentando entender como kubernetes funciona fica perdido fica perdido medida ficar pensando que ah eu não sou bom eu
não sei não conheço cara é porque você tá pulando uma etapa básica que é aprender contêiners principalmente docker que é a principal é ferramenta hoje para se executar e criar contêiners hoje no mercado para depois você ir lá e aprender como trabalhar com o kubernetes e para você criar as suas aplicações em containers O que que você vai utilizar você vai utilizar a imagem você vai criar a imagem que é a base de todo o contêiner no docker você vai fazer isso com o docker Fire você vai criar ali a sua receita de criação de
imagem para depois poder utilizar essa imagem e executar o seu contêiner no kubernet e quanto melhor você criar a sua imagem quanto mais enxuta ela for Quanto mais otimizada ela for seguindo as boas práticas de criação de imagem melhor ela vai rodar no ambiente kubernetes então Prepara sua aplicação para ser executada em contêiners segue as boas práticas de construção de imagem que cara você vai ver a diferença que isso faz quando você vai executar no seu ambiente de cloud com kubernetes algumas práticas que eu vou te falar aqui é você sempre utilizar tags né você
sempre versionar a imagem que você tá criando você sempre também definir a versão da imagem que você tá utilizando como base colocar apenas o que é essencial dentro da imagem não coloca ali todos os pacotes que você conhece que muitas vezes você não utiliza na aplicação na sua solução coloca estritamente o necessário somente o necessário pra sua aplicação ser executada dentro da imagem para que ela seja ali o menor possível E é claro utilizar Dock ignor enfim seguir as boas práticas do docker é eu vou colocar aí embaixo uma playlist sobre docker para você dar
uma olhada caso você ainda não conheça docker mas se você tá tentando aprender kubernetes direto sem antes chegar no docker cara não faça isso você vai ter grandes problemas principalmente em relação à base de conhecimento certo então marca aí mais esse item no checklist e vamos pro próximo vamos lá próximo item aqui ó não usar Rot para executar os seus contêiners pô pode parecer assim também meio Óbvio mas muita gente quando vai rodar as suas aplicações ou até vai utilizar o sistema operacional e Linux utiliza o usuário Rot para desenvolver para executar e até no
seu dia a dia e isso é uma má prática uma falha de segurança porque o usuário Rot ele é o super usuário do Linux ele pode fazer eh qualquer coisa dentro do sistema operacional Então você Executar a sua aplicação com esse usuário vai fazer com que você possa ter problema de vulnerabilidade Porque caso alguém invada ali o seu ambiente seja ambiente de contêiner seja ambiente de virtualização com máquinas virtuais ou até a sua máquina Esse Cara essa pessoa vai conseguir fazer o que quiser no seu ambiente então é importante você não utilizar o usuário Rot
para desenvolver e executar as suas aplicações Então sempre que você for criar ali a imagem de contêiner da sua aplicação Define um usuário diferente do Rot é claro dá para você fazer ali a execução de um outro usuário utilizando contêiners fazendo essa definição direto no seu cluster kubernetes na especificação do seu Deploy você pode utilizar lá o Security context e mudar o usuário que vai ser utilizado no contêiner mas se você desenvolver a sua ap ação utilizando usuário root é você pode acabar tendo problemas de permissionamento de arquivos ou até de operações que você vai
fazer no contêiner porque você desenvolveu você criou a imagem com o usuário root Então você trabalhou sempre com root e aí quando define o usuário direto no kubernetes utilizando Security context acaba dando erro ali de permissão muitas vezes de acesso de arquivo ou até de alguma operação que você precisa fazer então sempre Desenvolva a sua aplicação com um usuário diferente do rot e cria essa imagem também você pode definir isso utilizando o user no docker File é uma outra prática importante na hora de construir a imagem eu não coloquei no segundo item porque eu quero
reforçar isso para você né Não só definir um usuário diferente do Rot na hora de criar a imagem mas também na hora de desenvolver para você ver se todas as permissões já acesso ao arquivo ou de operações tão corretas ali e você não vai ter problema nenhum utilizando esse usuário Então sempre que você tiver desenvolvendo verifica lá as permissões Verifica tudo se vai ser executado corretamente então a partir de agora você não vai mais utilizar o root tanto para desenvolver quanto para fazer Deploy da sua aplicação no ambiente kubernetes fechado então vamos lá próximo vamos
lá quarto item aqui ó ter um end Point de Health Check e de de check o que que é isso Fabrício Sabe aquele endp que muitas vezes a galera de arquitetura fala para você colocar na aplicação para retornar ali um status 200 e verificar a saúde da aplicação verificar se tudo tá funcionando corretamente você muitas vezes pensa Ah para que que eu vou criar um endp que simplesmente retorna 200 né então é esse cara aqui é muito importante para executar a aplicação no kubernetes porque o que que acontece o kubernetes ele tem tem recurso de
self hiig né de autor recuperação das suas aplicações mas você precisa ensinar o kubernetes a ele verificar essa saúde da sua aplicação e o endp de Health check ele é fundamental para isso porque o kubernetes ele tem o liveness probe que é uma configuração que você vai fazer no Deploy da sua aplicação onde você vai definir ali um endp que aí vai fazer verificação via http ou executar um comando ou pingar ali numa porta TCP E aí sempre que essa verificação retornar positivo beleza ele sabe que a aplicação tá saudável ele vai continuar executando ali
Sem problema nenhum agora deu um erro nesse endp na execução do comando ou pingando lá na porta TCP ele vai entender que a aplicação não tá saudável e ele vai fazer ali o possível para recuperar vai restartar ali o contêiner E aí a aplicação vai conseguir ser executada vai continuar sendo e executada Sem problema nenhum então o endp de Health check ele vai ser utilizado nesse momento e aí você pode colocar no endp tudo que é necessário para verificar a saúde da sua aplicação verificar se a aplicação tá se comunicando com o banco de dados
se tá se comunicando com o redis com El De Cash com algum serviço externo é importante você fazer essas verificações de dependência e você pode ter e também níveis diferentes de Health check Você pode ter o nível saudável onde tá realmente saudável onde ele tá com alguns recursos comprometidos mas a aplicação continua e funcionando ou ele realmente não tá funcionando e aí o kubernetes ele vai fazer ali o Restart E aí junto com o h check eu tenho também o redit check que faz a verificação se a aplicação ela tá pronta para ser utilizada e
é importante você entender o seguinte é tá saudável a aplicação tá saudável diferente dela tá pronta Porque a aplicação ela pode estar funcionando corretamente está saudável mas ela pode tá em um momento de recuperação ou o processamento Como por exemplo o load inicial das informações ou pode est ali num período de aprendizado quando a gente fala em aplicações de machine learning e ela tá funcionando mas não pode processar nada nesse momento então qualquer coisa que possa impedir a sua aplicação de processar informações ou receber requisições você tem que colocar no redit check e uma falha
aqui um erro muito comum de quem começa a utilizar esses recursos no kubernetes é pegar o end Point de Health check colocar no read check também que no caso no kubernetes a gente chama de redness probe que é a verificação se a aplicação ela tá pronta ou não então são end points diferentes e tem objetivos diferentes Então você deve implementar os dois criar o Health check para configurar no liveness probe para verificar a saúde da aplicação e criar um end Point de Ready para colocar no Red Ness prob para verificar se a aplicação tá pronta
ou não para a processar ali requisições ou receber ali processos certo então implementa esses dois que são fundamentais para fazer bom uso do kubernetes e garantir a sua aplicação funcionando da melhor forma possível no ambiente vamos lá quinto e último item esse cara aqui também é importante ajuda muito quando a gente fala em observabilidade que é a inserção dos logs no STD out e no stdr o que que acontece a gente lá atrás tinha o costume de trabalhar com arquivos P log para armazenar os logs das nossas aplicações ia lá no arquivo é para consultar
as informações muitas vezes não conseguia né consultar nenhuma informação só tinha lá o arquivo para realmente armazenar ali e ocupar espaço mas agora quando a gente fala em ambientes como o kubernetes ou ambientes de em soluções modernas e fazer isso é uma má prática por quê Porque eu preciso ter um elemento adicional no kubernetes para coletar essas métricas no arquivo lembrando Putz eu tô trabalhando com contêiners toda vez que eu vou trabalhar com contêiners eu preciso acessar um arquivo no meio externo eu preciso trabalhar com volume então é mais uma configuração que eu tenho que
fazer é mais um elemento mais um processo que eu tenho que inserir para pegar desse volume e armazenar esse log num centralizador de log como um elastic search ou um grafana Lock da vida então quando você faz isso você trabalha com arquivos log na sua aplicação em containers você acaba tendo esse problema a mais e quando você insere os seus logs no STD Alt ou no stdr que é a saída padrão do do contêiner ali no caso o kubernetes ele consegue e pegar essas informações armazenar dentro do kubernetes e você consegue ter uma ferramenta centralizada
para coletar essas informações direto do kubernetes e colocar num elastic search num grafana loock mas com uma implementação e muito mais Nativa e agnóstica onde você consegue coletar o log de todas as aplicações de tudo que tá rodando do kubernetes com uma implementação única você não precisa PR ter essa particularidade de volume coletar lá do arquivo específico então colocar todos os seus logs no STD out no stdr Vai facilitar o gerenciamento não só da da coleta de logs da sua aplicação mas de todas as soluções no seu ambiente inclusive é também Um dos fatores do
TR Factor apps né se eu não me engano acho que é o 11º fator que é você armar arenar ou melhor enviar os seus logs utilizando o stdout o stdr certo então Último Ponto aí do seu checklist show de bola então eu espero que esse conteúdo tenha ajudado você muitas dessas práticas você provavelmente já tá implementando nas suas soluções se você ainda não implementa cara corre atrás monta aí o seu checklist para verificar e se tá tudo sendo implementado Porque por mais que pareçam simples essas impl ações fazem toda a diferença no ambiente kubernetes e
é isso que eu quero para você eu quero que você seja aquele profissional que não só sabe codificar aplicações mas que você sabe entregar da melhor forma de maneira escalável e sendo utilizado em aplicações de grande porte eu espero que esse vídeo tenha te ajudado Não esquece de comentar aí embaixo colocando aí #roma Elite se esse conteúdo te ajudou e não deixa também de se inscr inscrever no canal se você ainda não é inscrito se você não é inscrito Porque toda semana tem conteúdo como esse dá um like no vídeo e eu vou deixar aí
o formulário para você preencher para conhecer mais sobre a formação devops pro o meu treinamento que ajuda você junto com um acompanhamento ali próximo a mim a criar soluções escaláveis e de Grand grande porte utilizando Cloud devops coloca todas as suas informações que a minha equipe vai entrar em contato com você para te ajudar certo bom um abraço Isso aí até o próximo vídeo valeu
