Kotlin: preparando a aplicação para Cloud

Docker - Apresentação

Olá! Me chamo João Victor e serei o seu instrutor ao longo deste curso de Kotlin: preparando a aplicação para Cloud.

João Victor é uma pessoa de pele clara, olhos castanhos escuros e cabelos pretos curtos, usa bigode e cavanhaque. Veste um moletom branco com a sombra de um felino, em preto. Está sentado em uma cadeira e, ao fundo, há uma parede branca com uma iluminação azul gradiente com dois quadros, à direita.

Caso tenha curiosidade em saber como fazer o deploy da nossa aplicação em um ambiente clusterizado, você está no curso certo.

Neste curso, vamos aprender desde a dockerização da aplicação até o momento de executar o deploy na cloud, em um provedor de cloud usado por grandes empresas.

No projeto, criaremos o Dockerfile da aplicação para conseguirmos criar uma imagem para subirmos a aplicação em um Container Docker.

Dockerfile: criação de imagem para subir aplicação em container Docker.

Além de dockerizar a aplicação, vamos orquestrar os Containers. Isso porque trabalharemos com uma aplicação que se comunica com o Redis que, por sua vez, se comunica com o MySQL. Tudo isso deve ser orquestrado através do Kubernetes.

Também criaremos um cluster Kubernetes localmente, ou seja, na nossa máquina. Não vamos precisar subir a aplicação e os containers direto para um provedor de cloud. Conseguiremos fazer todo o teste local, isto é, fazer o acesso à aplicação e garantir que está seguro para subir para a cloud.

Quando estiver pronto, subiremos a aplicação para o OpenShift. Nele, conseguimos visualizar a nossa aplicação com os recursos sendo executados na cloud por uma topologia que fica interessante ao ser finalizada.

Além disso, vamos visualizar a nossa aplicação com toda parte de observabilidade. Para isso, trabalharemos com Spring Actuator, com Grafana e com o Prometheus.

É um curso completo para quem quiser se atualizar para o mercado de trabalho usando ferramentas que grandes empresas usam para seus produtos e serviços.

Caso tenha se interessado, te espero nos próximos vídeos. Até mais!

Docker - Criando Dockerfile

Finalizamos a parte de desenvolvimento da aplicação, conseguimos fazer a requisição HTTP usando o Retrofit, usamos Coroutines para requisições assíncronas e criamos os testes de unidade com o Co-Teste. Agora, vamos preparar a aplicação para o deploy no ambiente de produção.

Atualmente, na arquitetura de microsserviços e aplicações em cloud, é comum mencionar Aplicações Cloud Native.

A Cloud Native Computing Foundation, é um projeto fundado em 2015 pela Linux Foundation, para contribuir com o avanço da tecnologia de containers e alinhar o setor de tecnologia em torno de sua evolução Wikipédia - Cloud Native Computing Foundation .

Ou seja, é uma fundação que traz recursos que uma aplicação de microsserviço precisa ter para ser considerada uma aplicação implantada com as melhores práticas na cloud.

Um conceito sobre o que é a Cloud Native Computing Foundation que gostaríamos de destacar, é sobre a tecnologia de contêineres.

Na atualidade, falamos bastante em boas práticas, mas não conseguimos ter uma aplicação implantada de forma eficiente na cloud sem usar contêineres.

Há diversas maneiras de criarmos contêineres, temos vários recursos que fornecem tecnologias para gerar contêineres. O mais popular dentre eles, é o Docker .

Muitos confundem o Docker com um contêiner. Porém, ele é um ambiente que auxilia na criação e execução de contêineres. Assim como o Docker, temos outras ferramentas que podem substituí-lo para ser um ambiente de criação e execução de contêineres.

Já usamos o Docker na nossa aplicação para subir os recursos, como o Redis e o MySQL. Isto é, ao invés de instalar o MySQL na máquina, subimos um contêiner rodando um Docker e, com isso, comunicamos a nossa aplicação com esses recursos.

Introduzimos todo esse conteúdo porque, para termos um deploy eficiente da aplicação em produção, precisamos criar o contêiner da aplicação.

Apesar de usarmos o MySQL e o Redis como contêiner, a aplicação em si, continua sendo rodada localmente através do botão de play "▶" da IDE. Assim, fazemos a comunicação com os contêineres. O ideal é termos um contêiner da aplicação, para conseguirmos subir para produção.

Fazemos isso gerando uma imagem da nossa aplicação. Para isso, criamos um arquivo descritivo, em que inserimos uma série de comandos. Assim, depois conseguimos construir essa imagem para ela posteriormente virar um contêiner e a implantarmos em um ambiente produtivo.

Agora, vamos iniciar a construção do arquivo descritivo para conseguirmos construir a imagem da aplicação. Para tal, do lado esquerdo do projeto, selecionaremos a pasta car-service e clicaremos com o botão direito do mouse. Será exibido um menu com algumas opções, clicaremos nas opções "New > File".

No pop-up seguinte, intitulado "New File", temos um campo para digitarmos o nome. No caso, o nome do arquivo descritivo será "Dockerfile". Após escrever o nome, selecionaremos a tecla "Enter" para criar.

Perceba que já foi gerado um arquivo Dockerfile do lado esquerdo, na raiz do projeto. No arquivo que acabamos de criar, vamos descrever os comandos que ele precisa executar.

Ao nos referirmos a uma imagem Docker, estamos nos referindo ao arquivo que vai ser executado para criar o nosso contêiner. Este, deve ser auto-contido.

Por exemplo, é necessário que a aplicação car-service esteja em um contêiner e, dentro dele, é preciso termos tudo o que a aplicação precisa. Ou seja, o JDK (Java Development Kit), os comandos que serão rodados no momento de subir o contêiner, entre outras instruções.

Por precisarmos do JDK, vamos definir o ponto de partida do arquivo Dockerfile usando uma imagem que vai ser a imagem do OpenJDK. É importante essa imagem estar no contêiner para conseguirmos rodar a aplicação.

Por isso, iniciaremos o arquivo usando o comando from para definir esse ponto de partida da imagem, e criarmos o dockerfile. Utilizaremos uma imagem em Java já existente na imagem da aplicação.

Assim, no momento de construirmos o contêiner, essa imagem do JDK já estará junto com a imagem da aplicação. Consequentemente, a aplicação será executada com sucesso. Como precisamos usar a imagem JDK e estamos com o Java na versão 17 para a aplicação, usaremos o JDK também na versão 17.

O instrutor já possui a imagem JDK copiada. Mais adiante no curso, ele irá mostrar onde encontrar essa informação.

Dockerfile

FROM openjdk:17-jdk-slim-buster

Com isso, estamos pegando uma imagem do openJDK, sendo a 17 jdk slim buster. Na linha seguinte, definiremos o expose na porta 8080. Nesse comando, não estamos especificando que a aplicação está rodando no contêiner da porta 8080 ou, que estamos deixando essa porta disponível para o contêiner.

O comando expose é uma forma de documentar que a aplicação está rodando na porta 8080. Portanto, a ideia não é publicar a porta, e sim fazer a comunicação entre quem escreveu a imagem Docker e quem vai usar essa imagem para rodar o contêiner. Isto é, não significa que estamos expondo a porta 8080.

A partir disso, precisamos capturar o jar da aplicação car-service para colocá-la dentro do contêiner. Isso porque temos o JDK e a aplicação, e agora precisamos inserir a aplicação, que será o jar.

Ao rodarmos um mvn clean install, o jar é gerado na pasta target. Por isso, usaremos o comando ADD com o caminho /target/car-service-0.0.1-SNAPSHOT.jar.

Dockerfile

FROM openjdk:17-jdk-slim-buster
EXPOSE 8080
ADD /target/car-service-0.0.1-SNAPSHOT.jar car-service.jar

Com o comando add, estamos copiando da pasta target um arquivo .jar chamado car-service-0.0.1-SNAPSHOT.jar, para um repositório car-service.jar. Ou seja, estamos copiando o arquivo .jar com outro nome para dentro do contêiner.

Mais para frente, vamos aprender quais comandos precisamos usar para executar esse arquivo .jar no contêiner.

Após o add, incluiremos o comando que será executado ao subirmos o contêiner. Ao criarmos a imagem que gerará o contêiner, o que ele precisará executar para a aplicação rodar no contêiner? Conseguimos fazer isso, usando o comando entrypoint[].

No colchete, incluímos o comando que será rodado ao subirmos a aplicação. No entrypoint, há uma diferença na sintaxe, precisamos colocar cada comando entre aspas duplas e separado por vírgula.

Logo, podemos colocar ENTRYPOINT ["java",] e, como estamos trabalhando com o conceito de profiles, e deixamos o profile de dev como padrão, sempre que inicializamos a aplicação localmente, ele sobe com as configurações do application.properties do desenvolvimento, sendo que tudo está apontando para o localhost.

Para o ambiente produtivo, é necessário apontarmos para o profile de produção, em que temos as configurações do banco de dados disponível para acessar, qual o Redis em produção, entre outras informações. Não é mais o localhost.

Dockerfile

//código omitido

ENTRYPOINT ["java",]

Portanto, após o "java" passaremos a flag do Spring que ativa o profile de prod.

Dockerfile

// código omitido

ENTRYPOINT ["java", "-Dspring.profiles.active=prod",]

Em seguida, colocamos mais uma vírgula e abrimos aspas para incluir o próximo comando a ser rodado, no caso o -jar e depois informamos qual o jar que ele irá executar car-service.jar.

Obs: como copiamos o arquivo jar para o car-service.jar, usamos ele.

Dockerfile

ENTRYPOINT ["java", "-Dspring.profiles.active=prod", "-jar", "car-service.jar"]

Ao lermos esse comando, temos a seguinte lingua de raciocínio: temos o Java, ativando o profile de produção, o -jar e o car-service.jar, sendo o que será executado.

Assim, ficamos com o seguinte arquivo Dockerfile:

FROM openjdk:17-jdk-slim-buster
EXPOSE 8080
ADD /target/car-service-0.0.1-SNAPSHOT.jar car-service.jar
ENTRYPOINT ["java", "-Dspring.profiles.active=prod", "-jar", "car-service.jar"]

Ao construirmos essa imagem para criar o contêiner, será executado o passo a passo dos comandos descritos no arquivo, e teremos a aplicação rodando.

Com isso, temos o arquivo Dockerfile criado. Agora, precisamos disponibilizá-lo em algum lugar de fácil acesso na Web. Isso porque não adianta termos uma imagem local, sendo que o objetivo com contêineres é termos acesso a essa imagem e executá-la em qualquer ambiente, seja no produtivo, na cloud ou localmente.

Porém, a ideia desta aula era mostrar como construir o primeiro arquivo. Na sequência, aprenderemos como disponibilizar o arquivo para conseguirmos acessá-lo na web e criarmos os contêineres em vários ambientes.

Te espero no próximo vídeo!

Docker - Cadastro no Docker Hub

Com o arquivo Dockerfile, conseguimos visualizar o que vamos precisar construir para gerar a imagem e, posteriormente, o contêiner. Mas verificamos que para gerar a imagem, precisamos disponibilizá-la em algum local que temos fácil acesso.

Por exemplo, como damos acesso à imagem construída na máquina localmente, se posteriormente subiremos ela em um ambiente da cloud? Não tem como fazer isso.

Como disponibilizar a imagem de forma que qualquer pessoa possa baixar e rodá-la no contêiner da própria máquina? Para isso, é necessário algum repositório em que conseguimos construir a imagem localmente. No entanto, que seja possível subirmos a imagem para que qualquer um que quiser fazer o deploy da aplicação tenha acesso.

O Docker possui uma ferramenta similar ao GitHub, chamado Docker Hub , para imagens Docker. Imagens que vamos gerar a partir do arquivo Dockerfile.

Ao entrarmos no site do Docker Hub, na parte superior direita, temos quatro opções, sendo elas: explore, pricing, sign in e register. Clicaremos no botão "Register".

Será mostrada uma tela com alguns campos para preenchermos, como username, email e password. Abaixo, dois checkboxes perguntando se concordamos com os termos e, em seguida, um botão azul "Sign Up".

Para criar uma conta do Docker Hub, basta preencher os dados solicitados, concordar com os termos, informar que não é um robô e clicar no botão "Sign Up".

O usuário precisa ser um não usado ainda, porque ele será utilizado para referenciar o nosso ambiente para subirmos as imagens para o repositório.

Caso já possua um usuário, basta ir em "Sign In", preencher as credenciais e clicar no botão azul "Continue".

Ao logarmos, somos redirecionados para o Dashboard. Caso já tenha imagens, elas serão listadas já na página inicial.

O instrutor já possui a imagem car-service, mas o passo a passo para subir essa imagem para o Docker Hub será feito em aulas posteriores.

O importante entender é que no Docker Hub temos a estrutura das nossas imagens que ficaram disponíveis para outras pessoas. Por exemplo, no campo de busca na parte superior, podemos pesquisar pela imagem que usamos como ponto de partida do Dockerfile, sendo a openjdk.

openjdk

Pesquisando por essa imagem no Docker Hub, serão exibidas algumas possibilidades, dentre elas temos uma opção com a tag oficial "DOCKER OFFICIAL IMAGE". Clicando nesse openjdk oficial, e depois na aba "Tags", podemos pesquisar pela versão 17, nos devolve o 17.0.2-jdk-oracle.

Estamos com uma versão diferente, mas podemos usar a tag 17.0.2-jdk-oracle ou usar somente a 17.0.2. Portanto, o Docker Hub é um repositório de imagens, em que qualquer pessoa que tenha acesso à internet pode pegá-las. Podemos usar as imagens já existentes no arquivo para gerarmos a imagem, como no openjdk ou, podemos subir a imagem no Docker Hub.

Na sequência, seguimos essa última opção de subirmos a imagem para o Docker Hub.

Após entendermos os objetivos do Docker Hub, o próximo passo é construirmos a imagem da aplicação pelo Dockerfile e subir a aplicação com os comandos Docker que aprenderemos.

Te espero na próxima aula, para fazermos o push da imagem da aplicação no Docker Hub.

Até mais!

Sobre o curso Kotlin: preparando a aplicação para Cloud

O curso Kotlin: preparando a aplicação para Cloud possui 146 minutos de vídeos, em um total de 36 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:

• Docker
• Kubernetes
• Deploy no Openshift
• Observabilidade