Alura > Cursos de Programação > Cursos de Kotlin > Conteúdos de Kotlin > Primeiras aulas do curso Kotlin e Spring: segurança e infraestrutura

Kotlin e Spring: segurança e infraestrutura

Falando sobre DevOps - Apresentação

Olá, tudo bom? Meu nome é Joao Victor e eu serei o seu instrutor no curso de Infraestrutura e Segurança com o Kotlin.

Nesse curso, vamos ter a oportunidade e aprender sobre como utilizar o Spring Security com o Kotlin. O Spring Security é um framework do Spring voltado para a segurança que vai nos fornecer várias ferramentas para nos facilitar trabalharmos com parte de autenticação e de autorização.

Então, em vez de termos que desenvolver algo manual, o Sprign Security já vai entregar isso para nós de uma forma bem mais tranquila e que fique fácil para desenvolvermos.

Uma vez que já entendamos o funcionamento do Spring Security, vamos poder trabalhar com o JWT. O JWT é o Jason Web Token, que é um padrão da indústria.

Hoje, quando falamos em autenticação e autorização com token, sempre estamos falando sobre o JWT. Vamos entender como fucniona um token no sentido de autenticar e autorizar usuários a acessar a nossa apliacação.

É como nós podemos ver aqui. Se esse código ainda é desconhecido para você, nós vamos ter a oportunidade de entender e criar os nossos próprios tokens no decorrer do curso.

Tendo a nossa implementação de segurança e todo o conhecimento sobre autenticação e autorização da nossa aplicação com e sem token, vai chegar o momento de nós criarmos as imagens da nossa aplicação para que elas rodem em container.

Vamos ver aqui que vamos utilizar no curso o Docker. O Docker é a ferramenta de criação e execução de container mais famosa que temos hoje no mercado. Tendo esse container, nós vamos ter uma facilidade muito grande em fazer o deploy da nossa aplicação nos diversos ambientes que podemos ter na nossa empresa.

Se eu tenho um ambiente de TI, de Teste Integrado, se tenho um ambiente de homologação, até um ambiente de produção, vamos ver que com o container essa nossa aplicação fica muito mais fácil de passar em cada um desses ambientes.

E, uma vez que eu tenha esse meu container, que eu tenha essa imagem do meu container, que eu tenha a possibilidade de deployar essa nossa aplicação em um ambiente produtivo, vamos chegar até aqui, no Heroku.

Que é um provedor de cloud 100% gratuito – até um certo limite – e vamos conseguir subir o nosso container e fazer o acesso à nossa aplicação diretamente em produção.

Então, para você que ficou interessado nesse curso e acha que vai agregar na sua carreira, vem comigo e vamos dar toda essa volta nesse mundo de novidades que temos na parte de infraestrutura e na parte de deploy da nossa aplicação. Vejo você no próximo vídeo, obrigado.

Falando sobre DevOps - Um pouco de DevOps

Olá, tudo bom? Vamos prosseguir com o nosso curso. O objetivo é falar da infraestrutura da nossa aplicação.

Sempre que falamos sobre a infraestrutura, parece que estamos falando de um curso que não é para desenvolvedores, que só o pessoal de operações de infraestrutura que poderá fazer.

Só que essa não é mais a realidade. Nesse curso, nós vamos trazer a infra pensando em containers, em ferramentas de build, pensando no deploy da nossa aplicação, e se vocês forem pensar, isso hoje está muito próximo entre equipe de desenvolvimento de software e equipe de operações/infraestrutura.

Para deixar isso bem claro, e nós vemos que esse é um curso tanto para Dev quanto para pessoas de infra e operações, temos que pensar como é comumente visto o processo de entrega das nossas aplicações para ser deployed em ambientes de teste, de homologação, de produção.

Geralmente, o que acontece? Temos aqui uma pessoa desenvolvedora, essa pessoa é responsável por desenvolver o código, e o que ela faz é entregar um sistema, um entregável para outra pessoa responsável pela equipe de infra.

Vamos ter o nosso entregável, que é o nosso software, o nosso sistema que nós desenvolvemos, e tem uma pessoa de infraestrutura que vai ser o responsável por deployar a nossa aplicação nos servidores.

Só para ficar mais claro, aqui eu vou ter o “Actor Dev” e aqui vou ter o “Actor Infra”, responsável pela infra do nosso projeto. Vamos fazendo um desenho com calma para entendermos o processo que as pessoas costumam seguir.

Essa pessoa de infra consegue colocar esse sistema, esse meu entregável em um ambiente de teste, onde podemos ter analistas de sistemas testando a aplicação, analistas de produtos.

Ele vai fazer o deploy da nossa aplicação para a homologação. Aqui já estou pensando em uma equipe específica de teste que vai ter a documentação dada pelo time que desenvolveu o produto para testar as regras de negócio, para saber se realmente o que está na documentação está sendo refletido no sistema.

E temos também esse deploy em produção. Basicamente, o que temos é um modelo tradicional de deploy onde temos equipes totalmente diferentes, temos equipes desacopladas. O desenvolvedor desenvolve, infra faz o deploy de aplicação.

Só que essa abordagem parece ser totalmente ok, tenho cada um no seu quadrado, não há mistura entre as equipes, a equipe de homologação homologa o projeto, dando tudo certo, nós subimos para a produção, e fechou.

Qual problema essa abordagem começou a apresentar? Eu, desenvolvedor, quando estou criando a aplicação, estou testando na minha máquina local e ok, estou usando recursos da minha máquina, estou usando o banco de dados local na minha máquina, onde eu tenho uma massa de dados muito pequena.

E, quando faço os testes locais e o sistema está todo ok, eu entrego para a minha equipe de infra e vimos como esse processo é feito, esse entregável é distribuído entre os ambientes.

Mas, qual é o problema? A equipe de homologação tem um banco de dados que, às vezes, tem mais massa de dados do que tinha na minha máquina local, isso é muito comum.

E também pode ter uma diferença entre configurações. Vamos supor, o meu entregável funcionou na minha máquina, funcionou na máquina de teste, mas na homologação não funcionou.

Aí começa aquela confusão. Vamos perguntar para o desenvolvimento por que está tendo aquele erro, o desenvolvimento vai jogar aquele velho jargão, “na minha máquina funcionou, então não é culpa minha”.

Você que começa a ter uma série de problemas, porque os ambientes são diferentes. O meu banco de dados de homologação é diferente do meu banco de dados de testes, é diferente do meu banco de dados local.

E isso começou a causar muita dificuldade nas entregas, porque comecei a ter um atraso, porque a homologação falava que não ia homologar enquanto o desenvolvimento não arrumasse, e o desenvolvimento falava que não ia arrumar porque não era problema de desenvolvimento, mas de domínio de homologação, e acabava que ninguém assumiu a culpa.

Qual era o problema? Desculpa, não é “culpa”, às vezes nem era culpa, às vezes eram só esses problemas de configuração. Mas qual era o problema de toda essa confusão que gerava entre as equipes? Era o atraso na demanda.

Então, surgiu-se a necessidade de mudar, isso não poderia mais acontecer. Tínhamos de ter uma forma que nós aproximássemos mais as equipes – talvez seja a palavra mais correta.

Onde o desenvolvimento estivesse próximo da pessoa de infra que, por sua vez, estivesse perto da pessoa de homologação, e tivéssemos cenários onde tudo estaria funcionando da mesma forma.

Então, os meus ambientes deveriam ser mais homogêneos, não poderiam ter tanta diferença. Foram pensando “como posso ter entregas mais ágeis?”.

Se vou deixar meus ambientes mais homogêneos, como posso deixar minhas entregas mais rápidas? Que ferramentas posso usar para que isso seja possível, para que meus ambientes estejam todos homogêneos e, assim, eu tenha essa agilidade na entrega, se não tenho nenhuma barreira para a minha entrega?

Foi pensando nessa série de recursos que precisaríamos ter de aproximação das equipes, de agilidade nas entregas, de ambientes homogêneos, é que começou a surgir uma nova cultura na área de desenvolvimento/operações, que foi o DevOps.

O DevOps, como podemos ver aqui no site da Red Hat, a metodologia DevOps, a cultura DevOps, “é uma abordagem de cultura” – então você vê que é uma cultura, estamos falando sobre cultura de empresa –, “automação” – automação para que isso não seja feito de forma manual, para que evitemos esses problemas que tínhamos entre as equipes.

E “design de plataforma que tem como objetivo agregar mais valor aos negócios e aumentar sua capacidade de resposta às mudanças por meio de entregas de serviços rápidas e de alta qualidade.”

“Tudo isso é possível por meio da disponibilização de serviços de TI rápidos e interativos. Adotar o DevOps significa conectar aplicações legadas a uma infraestrutura e aplicações modernas e nativas em nuvem”.

Então, vimos aqui que, com esses problemas que nós tínhamos na forma tradicional de deploy, acabamos tendo que nos movimentar para que tivesse mais agilidade, e com isso surgiu o DevOps.

Agora, com o DevOps, eu tenho a minha equipe de operação, a minha equipe de infraestrutura mais próxima da minha equipe de desenvolvimento, cada uma ainda fazendo atividade específicas da sua alçada, só que de uma forma que seja mais integrada, de uma forma que os times sejam integrados para dar mais agilidade para a nossa entrega.

Isso vai ser feito com ferramentas que vamos ver ao longo do curso, como containers e deploy em provedores de cloud, então não precisamos mais ter aquele tanto de servidores, de metal nos CPDs específicos.

Enfim, vamos conseguir ver como aplicar essas ferramentas de automação e extrair disso a maior facilidade para entrega dos nossos sistemas.

A ideia dessa aula era ser mais introdutória para podermos saber aonde queremos chegar, e a motivação do porquê que precisamos chegar nesse ponto de automação, de agilidade, e agora a ideia é que vamos, passo a passo, aprendendo como podemos fazer isso da maneira mais eficiente.

Espero que vocês tenham gostado dessa aula mais introdutória. Nos encontramos no próximo vídeo para continuarmos o estudo da infra e da nossa equipe de desenvolvimento trabalhando em perfeita sintonia para melhores resultados nas nossas entregas. Vejo você no próximo vídeo, obrigado.

Falando sobre DevOps - Infra da aplicação

Agora que nós aprendemos como funciona, o que é o conceito de DevOps, e sabemos que é um conjunto ferramental com agilidade mais integração de times, chegou o momento de darmos um passo adiante e observarmos o que podemos pegar desse conceito e usarmos na aplicação que desenvolvemos ao longo dos cursos de Kotlin.

Basicamente, o que estávamos fazendo até agora? Nós desenvolvemos toda a nossa aplicação e, para testar, para podermos fazer requisições para essa aplicação, nós estávamos subindo localmente na nossa IDE – no caso, estou usando IntelliJ, mas pode ser no NetBeans, no Eclipse, desde que tenha plugin para o Kotlin.

Quando queríamos fazer requisição, nós usávamos alguma ferramenta para a requisição HTTP. Estou usando o SoapUI, mas você pode usar o PostMan, que acho que é o mais famoso, ou até mesmo podemos usar o nosso navegador para fazermos requisições do tipo get.

Então, eu vinha aqui, acessava o http://localhost:8080 e fazia uma chamada para o endpoint nosso, que no caso era “/tópicos”. Fazendo isso, eu precisava só escolher o método. Quero fazer um “GET” mesmo só para listar os tópicos, se tiver.

Aí, nós constatávamos o resultado da nossa aplicação. No nosso caso, o conteúdo está vazio porque não temos nenhum conteúdo no nosso banco de dados, mas, enfim, aqui foi só para mostrar o que estávamos fazendo até então.

Mas, qual é o problema dessa abordagem? Tudo aquilo que tínhamos falado anteriormente. o que acontece? Eu estou usando a minha máquina local, subindo a aplicação, posso ter um banco de dados local onde não tenho a mesma possibilidade de uso da minha máquina local dos demais ambientes.

Então, vamos pensar, se eu gerar um entregável, se eu gerar o build da minha aplicação e entregar para a minha equipe de infra para ela fazer o deploy nos outros servidores, eu não vou ter o mesmo potencial na minha máquina do que tem nos servidores.

Mas os servidores também podem ser diferentes entre eles. Posso ter uma configuração X no servidor de homologação, Y no servidor de teste, e começa a confusão.

Vimos que as equipes começam a ter problemas porque roda na minha máquina, mas não roda em homologação; roda em teste, mas não roda em homologação. Olha só, aquela confusão que vimos no vídeo passado.

Então, precisamos extrair, daqueles conceitos de DevOps, as ferramentas necessárias para que isso não seja mais um problema para nós. O primeiro recurso que vamos utilizar para extrair uma vantagem do DevOps de fato e faça uma entrega com maior qualidade referente ao meu software, é o container.

Para entendermos melhor o container, eu vou usar um diagrama. Assim como os containers que são levados por embarcações ou linhas ferroviárias, vamos ter um conceito semelhante na TI.

Assim como no container há uma caixa metálica que colocamos coisas e trafegamos de um lugar para outro, vamos ter algo semelhante na TI – lógico que não vamos trafegar isso em vias terrestres. Mas, por exemplo, qual é a nossa ideia?

Hoje, eu tenho a minha “Aplicação” que podemos considerar um ponto “jar”, vamos supor que o nosso entregável vai ser um “jar”. E já vimos, novamente, que temos nossos ambientes em que a nossa aplicação deve ser deployada.

Vamos ter “Teste”, vamos ter “Homol” e vamos ter “Prod”. Cada um desses caras vai ter acesso a um banco de dados que vamos fazer requisições para que a nossa aplicação funcione corretamente. Chegamos no nosso ambiente.

Não vou repetir sobre o problema dessa abordagem para não ser repetitivo, mas agora eu quero entrar com o conceito de container.

O container é exatamente uma caixa, podemos pensar nele como uma caixa invisível, onde eu posso colocar a minha aplicação, e tudo isso aqui é autocontido.

Então, o meu container vai ter a minha aplicação e tudo que ela precisa para rodar. Se eu precisar das dependências da minha aplicação, de configurações da minha aplicação, tudo vai estar autocontido nesse meu container.

O mais interessante é que eu não aproveito esse container só para a minha aplicação. Eu posso usar um container para o banco de dados. Por exemplo, posso colocar aqui um banco de dados com todas as configurações necessárias para aquela aplicação.

Se eu preciso de uma base X para a minha aplicação, eu configuro no meu container essa base X e faço essa comunicação de um container para o outro.

Você pode estar confuso, “o que isso tem a ver com os ambientes? o que isso tem a ver com o que temos de problema?”. Hoje, com isso aqui, eu consigo levar esses dois containers para todos os meus ambientes.

Então, a aplicação que roda local vai rodar igualmente no ambiente de teste porque ela está encapsulada, ela está autocontida dentro de um container que tem todas as configurações, assim como o meu banco de dados.

Eu não preciso ficar acessando o banco de dados de “Homol”, ou então fazendo updates, fazendo alter tables no meu ambiente de “Homol” para que a minha aplicação esteja funcionando como estaria no local.

Eu simplesmente levo tudo isso para cada um desses ambientes, o que é mais comum estarmos fazendo isso na cloud, mas nada impede de termos ambientes locais. “Locais” que eu digo não se referindo próprio, em servidores de metal que muitas empresas ainda possuem.

Dessa maneira, eu vou ter um comportamento para a minha aplicação de teste. Uma vez que realmente eu vi que está testado – isso posso jogar fora –, eu posso levar esses dois containers para um ambiente de “Homol”.

Tenho que garantir que vai funcionar perfeitamente porque não tive mudanças, não tive configurações diferentes, não tive uma base de dados diferente. Tudo que estou replicando de um ambiente, desde local até produção, vai ser o mesmo.

Dessa forma aqui, eu tenho um ambiente homogêneo. Foi o que nós falamos: para eu ter agilidade nas minhas entregas, eu tenho que ter ambientes homogêneos, e o container faz com que isso seja possível.

Agora, saímos daquele método de sair deployando em cada um dos ambientes e torcendo para que eles sejam o mais homogêneo possível, para um ambiente que é 100% homogêneo, eu garanto isso.

Porque eu que criei os meus containers e eu que deployei esses containers nos meus ambientes que são necessários na minha empresa e que vão depender da necessidade e tamanho das empresas.

Você pode estar se perguntando “mas container, com isso funciona, como que executa?”, aí que é a parte interessante. Vamos ter executores de containers, são ambientes de execução de containers que vão fazer com que toda essa mágica seja possível.

Apenas meu ambiente tendo um executor, que o mais famoso é o Doc – não vamos entrar muito em profundidade do executor em específico porque vamos ver isso mais para frente –, mas é o mais famoso.

Então, eu tendo esse Doc nos meus ambientes, quando eu jogar o meu container com a minha aplicação, com o meu banco de dados – pode ser um Kafka, uma mensageria – ele vai executar e minha aplicação vai funcionar igual em todos os ambientes.

Mais uma vez, eu decidi fazer uma aula um pouco mais teórica para entendermos aonde vamos chegar com a nossa aplicação, e também para já começarmos a introduzir esse conceito de containers para vocês que vai ser algo que, de fato, vai nos auxiliar, e muito.

E vai nos facilitar na nossa entrega, porque agora vamos ter os ambientes homogêneos, vamos ter um ferramental que vai nos auxiliar realmente nessa entrega com maior qualidade e com maior agilidade.

Então, a partir de agora, vamos, de fato, parar um pouco com as aulas teóricas e vamos começar a colocar a mão na massa e ver realmente como vai funcionar a nossa aplicação com containers, com uma infra mais elaborada para estrearmos o melhor dessa cultura DevOps. Vou ficando por aqui, espero que vocês tenham gostado e vejo vocês no próximo vídeo. Obrigado.

Sobre o curso Kotlin e Spring: segurança e infraestrutura

O curso Kotlin e Spring: segurança e infraestrutura possui 293 minutos de vídeos, em um total de 55 atividades. Gostou? Conheça nossos outros cursos de Kotlin em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Kotlin acessando integralmente esse e outros cursos, comece hoje!

Plus

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$85
à vista R$1.020
Matricule-se

Pro

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$120
à vista R$1.440
Matricule-se
Conheça os Planos para Empresas

Acesso completo
durante 1 ano

Estude 24h/dia
onde e quando quiser

Novos cursos
todas as semanas