Esta postagem foi escrita porque nossos funcionários conversaram bastante com clientes sobre o desenvolvimento de aplicativos no Kubernetes e as especificidades desse desenvolvimento no OpenShift.
Geralmente começamos com a tese de que Kubernetes é apenas Kubernetes, e OpenShift já é uma plataforma Kubernetes, como Microsoft AKS ou Amazon EKS. Cada uma dessas plataformas tem suas vantagens, voltadas para um determinado público-alvo. E depois disso, a conversa passa a comparar os pontos fortes e fracos de plataformas específicas.
Em geral, pensamos em escrever este post com uma conclusão como “Ouça, não importa onde executar o código, no OpenShift ou no AKS, no EKS, em algum Kubernetes customizado ou em qualquer Kubernetes (para resumir, vamos chamá-lo de KUK) “É muito simples, tanto ali como ali.”
Então planejamos pegar o “Hello World” mais simples e usar seu exemplo para mostrar o que é comum e qual é a diferença entre o KUC e o Red Hat OpenShift Container Platform (doravante denominado OCP ou simplesmente OpenShift).
No entanto, ao escrevermos este post, percebemos que estávamos tão acostumados a usar o OpenShift há tanto tempo que simplesmente não percebemos como ele havia crescido e se transformado em uma plataforma incrível que se tornou muito mais do que apenas uma distribuição Kubernetes. Tendemos a considerar a maturidade e a simplicidade do OpenShift como garantidas e perder de vista o seu brilho.
Em geral, chegou a hora do arrependimento ativo, e agora compararemos passo a passo o comissionamento do nosso “Hello World” no KUK e no OpenShift, e faremos isso da forma mais objetiva possível (bem, exceto às vezes mostrando um atitude pessoal em relação ao assunto). Se você estiver interessado em uma opinião puramente subjetiva sobre este assunto, poderá lê-la . E neste post vamos nos ater aos fatos e somente aos fatos.
Clusters
Portanto, nosso “Hello World” requer clusters. Diremos imediatamente “não” a quaisquer nuvens públicas, para não pagar por servidores, registros, redes, transferência de dados, etc. Assim, escolhemos um cluster simples de nó único em (para KUK) e (para cluster OpenShift). Ambas as opções são realmente fáceis de instalar, mas exigirão muitos recursos do seu laptop.
Montagem em KUK-e
Então, vamos.
Passo 1 – construindo nossa imagem de contêiner
Vamos começar implantando nosso “Hello World” no minikube. Para fazer isso você precisará de:
- 1. Docker instalado.
- 2. Git instalado.
- 3. Maven instalado (na verdade, este projeto usa o binário mvnw, então você pode ficar sem ele).
- 4. Na verdade, a própria fonte, ou seja, clone do repositório
O primeiro passo é criar um projeto Quarkus. Não se assuste se você nunca trabalhou com Quarkus.io – é fácil. Basta selecionar os componentes que deseja usar no projeto (RestEasy, Hibernate, Amazon SQS, Camel, etc.), e então o próprio Quarkus, sem qualquer participação sua, configura o arquétipo maven e coloca tudo no github. Ou seja, literalmente um clique do mouse e pronto. É por isso que amamos Quarkus.
A maneira mais fácil de construir nosso “Hello World” em uma imagem de contêiner é usar as extensões quarkus-maven para Docker, que farão todo o trabalho necessário. Com o advento do Quarkus, isso se tornou muito fácil e simples: adicione a extensão container-image-docker e você poderá criar imagens usando comandos maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Finalmente, construímos nossa imagem usando Maven. Como resultado, nosso código-fonte se transforma em uma imagem de contêiner pronta que já pode ser executada no ambiente de execução do contêiner.
./mvnw -X clean package -Dquarkus.container-image.build=true
Só isso, agora você pode iniciar o container com o comando docker run, mapeando nosso serviço para a porta 8080 para que possa ser acessado.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Depois que a instância do contêiner for iniciada, tudo o que resta é verificar com o comando curl se nosso serviço está em execução:
Então tudo funcionou e foi muito fácil e simples.
Passo 2 – envie nosso contêiner para o repositório de imagens de contêiner
Por enquanto, a imagem que criamos está armazenada localmente, em nosso contêiner local. Se quisermos usar esta imagem em nosso ambiente COOK, ela deverá ser colocada em algum outro repositório. O Kubernetes não possui esses recursos, então usaremos o dockerhub. Porque, em primeiro lugar, é gratuito e, em segundo lugar, (quase) toda a gente o faz.
Isso também é muito simples e tudo que você precisa é de uma conta dockerhub.
Então, instalamos o dockerhub e enviamos nossa imagem para lá.
Etapa 3 – iniciar o Kubernetes
Existem muitas maneiras de montar a configuração do kubernetes para rodar nosso “Hello World”, mas usaremos a mais simples delas, é assim que somos...
Primeiro, vamos iniciar o cluster minikube:
minikube start
Etapa 4 – implantar nossa imagem de contêiner
Agora precisamos converter nosso código e imagem de contêiner em configurações de Kubernetes. Em outras palavras, precisamos de um pod e uma definição de implantação apontando para nossa imagem de contêiner no dockerhub. Uma das maneiras mais fáceis de fazer isso é executar o comando create deploy apontando para nossa imagem:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Com este comando, instruímos nosso COO a criar uma configuração de implantação, que deve conter a especificação do pod para nossa imagem de contêiner. Este comando também aplicará esta configuração ao nosso cluster minikube e criará uma implantação que fará download da nossa imagem de contêiner e iniciará o pod no cluster.
Passo 5 – acesso aberto ao nosso serviço
Agora que temos uma imagem de contêiner implantada, é hora de pensar em como configurar o acesso externo a esse serviço Restful, que, na verdade, está programado em nosso código.
Existem muitas maneiras aqui. Por exemplo, você pode usar o comando expor para criar automaticamente os componentes apropriados do Kubernetes, como serviços e endpoints. Na verdade, isso é o que faremos executando o comando de exposição para nosso objeto de implantação:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Vamos dar uma olhada na opção “-type” do comando expor.
Quando expomos e criamos os componentes necessários para executar nosso serviço, precisamos, entre outras coisas, ser capazes de nos conectar externamente ao serviço hello-quarkus, que fica dentro de nossa rede definida por software. E parâmetro tipo nos permite criar e conectar coisas como balanceadores de carga para rotear o tráfego para esta rede.
Por exemplo, escrevendo tipo = LoadBalancer, provisionamos automaticamente um balanceador de carga na nuvem pública para conectar-se ao nosso cluster Kubernetes. Isso, claro, é ótimo, mas você precisa entender que tal configuração estará estritamente vinculada a uma nuvem pública específica e será mais difícil de transferir entre instâncias do Kubernetes em ambientes diferentes.
Em nosso exemplo tipo=NodePort, ou seja, nosso serviço é acessado pelo endereço IP e número da porta do nó. Esta opção permite que você não use nuvens públicas, mas requer uma série de etapas adicionais. Em primeiro lugar, você precisa de seu próprio balanceador de carga, por isso implantaremos o balanceador de carga NGINX em nosso cluster.
Etapa 6 – instalar um balanceador de carga
O minikube possui diversas funções de plataforma que facilitam a criação de componentes acessíveis externamente, como controladores de entrada. O Minikube vem com o controlador de entrada Nginx e tudo o que precisamos fazer é habilitá-lo e configurá-lo.
minikube addons enable ingress
Agora criaremos um controlador de ingresso Nginx com apenas um comando, que funcionará dentro de nosso cluster minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Passo 7 – Configurando a entrada
Agora precisamos configurar o controlador de ingresso Nginx para que ele aceite solicitações hello-quarkus.
E finalmente, precisamos aplicar esta configuração.
kubectl apply -f ingress.yml
Como estamos fazendo tudo isso em nosso próprio computador, simplesmente adicionamos o endereço IP do nosso nó ao arquivo /etc/hosts para rotear solicitações http do nosso minikube para o balanceador de carga NGINX.
192.168.99.100 hello-quarkus.info
É isso, agora nosso serviço minikube está acessível externamente através do controlador de ingresso Nginx.
Bem, isso foi fácil, certo? Ou não?
Executando em OpenShift (contêineres prontos para código)
Agora vamos ver como tudo isso é feito no Red Hat OpenShift Container Platform (OCP).
Tal como acontece com o minikube, escolhemos um design de cluster OpenShift de nó único na forma de Code Ready Containers (CRC). Anteriormente, era chamado de minishift e era baseado no projeto OpenShift Origin, mas agora é CRC e construído na OpenShift Container Platform da Red Hat.
Aqui nós, desculpe, não podemos deixar de dizer: “OpenShift é maravilhoso!”
Inicialmente, pensamos em escrever que o desenvolvimento no OpenShift não é diferente do desenvolvimento no Kubernetes. E em essência é assim que as coisas são. Mas no processo de escrever este post, lembramos de quantos movimentos extras você tem que fazer quando não tem o OpenShift, e é por isso que, novamente, é maravilhoso. Adoramos quando tudo é feito com facilidade, e a facilidade de implantação e execução do nosso exemplo no OpenShift em comparação com o minikube foi o que nos levou a escrever este post.
Vamos passar pelo processo e ver o que precisamos fazer.
Então, no exemplo do minikube, começamos com o Docker... Espere, não precisamos mais do Docker instalado na máquina.
E não precisamos de git local.
E Maven não é necessário.
E você não precisa criar uma imagem de contêiner com as mãos.
E você não precisa procurar nenhum repositório de imagens de contêiner.
E não há necessidade de instalar um controlador de ingresso.
E você também não precisa configurar o ingresso.
Você entende, certo? Para implantar e executar nosso aplicativo no OpenShift, você não precisa de nenhuma das opções acima. E o processo em si é assim.
Etapa 1 – Inicie seu cluster OpenShift
Usamos Code Ready Containers da Red Hat, que é essencialmente o mesmo Minikube, mas apenas com um cluster Openshift completo de nó único.
crc start
Etapa 2 – Construir e implementar o aplicativo no cluster OpenShift
É nesta etapa que a simplicidade e a conveniência do OpenShift são reveladas em toda a sua glória. Tal como acontece com todas as distribuições do Kubernetes, temos muitas maneiras de executar uma aplicação em um cluster. E, como no caso do KUK, escolhemos especificamente o mais simples.
OpenShift sempre foi construído como uma plataforma para criar e executar aplicativos em contêineres. A construção de contêineres sempre foi parte integrante desta plataforma, portanto, há muitos recursos adicionais do Kubernetes para tarefas relacionadas.
Usaremos o processo Source 2 Image (S2I) do OpenShift, que tem várias maneiras diferentes de pegar nosso código-fonte (código ou binários) e transformá-lo em uma imagem em contêiner que é executada em um cluster OpenShift.
Para fazer isso precisamos de duas coisas:
- Nosso código fonte está no repositório git
- Imagem do construtor com base na qual a construção será executada.
Existem muitas dessas imagens mantidas tanto pela Red Hat quanto no nível da comunidade, e usaremos a imagem OpenJDK, pois estou construindo um aplicativo Java.
É possível executar a construção S2I no console gráfico do OpenShift Developer ou na linha de comando. Usaremos o comando new-app, informando onde obter a imagem do construtor e nosso código-fonte.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
É isso, nosso aplicativo está criado. Ao fazer isso, o processo S2I fez o seguinte:
- Criou um pod de construção de serviço para todos os tipos de coisas relacionadas à construção do aplicativo.
- Criou a configuração do OpenShift Build.
- Baixei a imagem do construtor para o registro interno do Docker do OpenShift.
- Clonou "Hello World" no repositório local.
- Eu vi que havia um maven pom lá, então compilei o aplicativo usando o maven.
- Criou uma nova imagem de contêiner contendo o aplicativo Java compilado e colocou essa imagem no registro de contêiner interno.
- Criou a implantação do Kubernetes com especificações para pod, serviço, etc.
- Comecei a implantar a imagem do contêiner.
- O pod de compilação de serviço foi removido.
Há muita coisa nesta lista, mas o principal é que toda a construção acontece exclusivamente dentro do OpenShift, o registro interno do Docker está dentro do OpenShift e o processo de construção cria todos os componentes do Kubernetes e os executa no cluster.
Se você monitorar visualmente a inicialização do S2I no console, poderá ver como o pod de compilação é iniciado quando a compilação for concluída.
Agora vamos dar uma olhada nos logs do pod do construtor: primeiro, ele mostra como o maven faz seu trabalho e baixa dependências para construir nosso aplicativo java.
Após a conclusão da construção do maven, a construção da imagem do contêiner é iniciada e, em seguida, essa imagem construída é enviada para o repositório interno.
É isso, o processo de construção está completo. Agora vamos ter certeza de que os pods e serviços do nosso aplicativo estão sendo executados no cluster.
oc get service
Isso é tudo. E apenas uma equipe. Basta expor este serviço para acesso externo.
Passo 3 – expor o serviço para acesso externo
Assim como no caso do KUC, na plataforma OpenShift nosso “Hello World” também precisa de um roteador para direcionar o tráfego externo para o serviço dentro do cluster. OpenShift torna isso muito fácil. Primeiramente, o componente de roteamento HAProxy é instalado no cluster por padrão (pode ser alterado para o mesmo NGINX). Em segundo lugar, existem recursos especiais e altamente configuráveis chamados Rotas e que lembram os objetos Ingress do bom e velho Kubernetes (na verdade, as Rotas do OpenShift influenciaram muito o design dos objetos Ingress, que agora podem ser usados no OpenShift), mas para o nosso “Hello World” , e em quase todos os outros casos, a rota padrão é suficiente para nós sem configuração adicional.
Para criar um FQDN roteável para “Hello World” (sim, o OpenShiift tem seu próprio DNS para roteamento por nomes de serviço), simplesmente exporemos nosso serviço:
oc expose service quarkus-hello-world
Se você observar a rota recém-criada, poderá encontrar o FQDN e outras informações de roteamento:
oc get route
E por fim, acessamos nosso serviço pelo navegador:
Mas agora foi muito fácil!
Amamos o Kubernetes e tudo o que essa tecnologia nos permite fazer, e também amamos a simplicidade e a facilidade. O Kubernetes foi criado para simplificar incrivelmente a operação de contêineres distribuídos e escalonáveis, mas sua simplicidade não é mais suficiente para colocar aplicativos em produção hoje. É aqui que entra o OpenShift, acompanhando os tempos e oferecendo Kubernetes, voltado principalmente para o desenvolvedor. Muito esforço foi investido para adaptar a plataforma OpenShift especificamente para o desenvolvedor, incluindo a criação de ferramentas como S2I, ODI, Portal do Desenvolvedor, OpenShift Operator Framework, integração IDE, Catálogos do Desenvolvedor, integração Helm, monitoramento e muitos outros.
Esperamos que este artigo tenha sido interessante e útil para você. Você pode encontrar recursos adicionais, materiais e outras coisas úteis para o desenvolvimento na plataforma OpenShift no portal .
Fonte: habr.com