{"id":97254,"date":"2020-10-17T02:42:32","date_gmt":"2020-10-17T00:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe"},"modified":"2020-10-17T02:42:32","modified_gmt":"2020-10-17T00:42:32","slug":"prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","title":{"rendered":"Desculpe, OpenShift, n\u00e3o te valorizamos o suficiente e tomamos voc\u00ea como certo.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Este post foi escrito porque nossos colaboradores tiveram muitas conversas com clientes sobre o desenvolvimento de aplica\u00e7\u00f5es no Kubernetes e as especificidades desse tipo de desenvolvimento no OpenShift.<\/p>\n

\"Desculpe,
\n
\nGeralmente come\u00e7amos com a tese de que Kubernetes \u00e9 apenas Kubernetes, enquanto OpenShift \u00e9 uma plataforma Kubernetes, assim como Microsoft AKS ou Amazon EKS. Cada uma dessas plataformas tem suas vantagens, voltadas para diferentes p\u00fablicos-alvo. E ap\u00f3s isso, a conversa flui para a compara\u00e7\u00e3o dos pontos fortes e fracos de cada plataforma espec\u00edfica.
\n<\/a><\/noindex>
\nEm geral, est\u00e1vamos pensando em escrever este post com uma conclus\u00e3o do tipo: \"Olha, n\u00e3o importa onde executar o c\u00f3digo, no OpenShift ou no AKS, no EKS, em um Kubernetes personalizado, em qualquer Kubernetes\". (para abreviar, chamaremos de KUK)<\/i> \u2013 \u00e9 realmente simples, tanto l\u00e1 quanto c\u00e1.<\/p>\n

Depois, planej\u00e1vamos pegar o simples \"Hello World\" e, a partir dele, mostrar o que \u00e9 comum e quais s\u00e3o as diferen\u00e7as entre KUK e a Red Hat OpenShift Container Platform (daqui em diante, OCP ou apenas OpenShift).<\/p>\n

No entanto, ao longo da reda\u00e7\u00e3o deste post, percebemos que nos acostumamos tanto a usar o OpenShift que simplesmente n\u00e3o reconhecemos como ele cresceu e se transformou em uma plataforma incr\u00edvel, que se tornou muito mais do que apenas uma distribui\u00e7\u00e3o do Kubernetes. Nos acostumamos a considerar a maturidade e a simplicidade do OpenShift como garantidas, esquecendo de seu esplendor.<\/p>\n

Em geral, chegou a hora do arrependimento ativo, e agora vamos comparar passo a passo a implanta\u00e7\u00e3o do nosso \"Hello World\" no KUK e no OpenShift, e faremos isso da forma mais objetiva poss\u00edvel (exceto por, \u00e0s vezes, expressar nosso sentimento sobre o assunto). Se voc\u00ea est\u00e1 interessado em uma opini\u00e3o puramente subjetiva sobre isso, pode l\u00ea-la aqui (EN)<\/a><\/noindex>. E neste post, nos manteremos nos fatos e apenas nos fatos.<\/p>\n

Clusters<\/h3>\n

\nEnt\u00e3o, para o nosso \"Hello World\", precisamos de clusters. Vamos logo dizer \"n\u00e3o\" a qualquer nuvem p\u00fablica, para n\u00e3o pagarmos por servidores, registros, redes, transfer\u00eancia de dados, etc. Portanto, escolhemos um simples cluster de um \u00fanico n\u00f3 em Minikube<\/a><\/noindex> (para o KUK) e Code Ready Containers<\/a><\/noindex> (para o cluster OpenShift). Ambas as op\u00e7\u00f5es s\u00e3o realmente simples de instalar, mas exigir\u00e3o muitos recursos no seu laptop.<\/p>\n

\"Desculpe,<\/p>\n

Compila\u00e7\u00e3o no KUK<\/h3>\n

\nEnt\u00e3o, vamos l\u00e1.<\/p>\n

Passo 1 \u2013 vamos compilar nossa imagem de cont\u00eainer<\/h4>\n

\nCome\u00e7aremos por implantar nosso \"Hello World\" no Minikube. Para isso, precisaremos de:<\/p>\n

    \n
  1. 1. Docker instalado.<\/li>\n
  2. 2. Git instalado.<\/li>\n
  3. 3. Maven instalado (na verdade, neste projeto, usamos o bin\u00e1rio mvnw, ent\u00e3o n\u00e3o \u00e9 necess\u00e1rio).<\/li>\n
  4. 4. O c\u00f3digo-fonte propriamente dito, ou seja, o clone do reposit\u00f3rio github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nPrimeiramente, precisamos criar um projeto Quarkus. N\u00e3o se preocupe se voc\u00ea nunca trabalhou com o site Quarkus.io \u2013 \u00e9 f\u00e1cil. Basta escolher os componentes que deseja usar no projeto (RestEasy, Hibernate, Amazon SQS, Camel, etc.), e o Quarkus ir\u00e1 configurar automaticamente o archetype do maven e disponibilizar tudo no GitHub. Ent\u00e3o, literalmente, \u00e9 um clique do mouse \u2013 e est\u00e1 pronto. \u00c9 por isso que amamos o Quarkus.<\/p>\n

    \"Desculpe,<\/p>\n

    A maneira mais simples de compilar nosso 'Hello World' em uma imagem de cont\u00eainer \u00e9 usar a extens\u00e3o quarkus-maven para Docker, que far\u00e1 todo o trabalho necess\u00e1rio. Com a chegada do Quarkus, isso se tornou realmente f\u00e1cil: voc\u00ea adiciona a extens\u00e3o container-image-docker e pode criar imagens com comandos do maven.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \nE, finalmente, compilamos nossa imagem usando o Maven. Como resultado, nosso c\u00f3digo-fonte se transforma em uma imagem de cont\u00eainer pronta para ser executada no ambiente de execu\u00e7\u00e3o de cont\u00eaineres.<\/p>\n
    \"Desculpe,<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nE isso \u00e9 tudo, agora podemos iniciar o cont\u00eainer com o comando docker run, mapeando nosso servi\u00e7o para a porta 8080, para que possa ser acessado.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"Desculpe,<\/p>\n
    Depois que a inst\u00e2ncia do cont\u00eainer for iniciada, resta apenas verificar com o comando curl se nosso servi\u00e7o est\u00e1 funcionando:<\/p>\n
    \"Desculpe,<\/p>\n
    Assim, tudo est\u00e1 funcionando e foi realmente f\u00e1cil.<\/p>\n
    Passo 2 \u2013 enviamos nosso cont\u00eainer para o reposit\u00f3rio de imagens de cont\u00eainer<\/h4>\n
    \nAt\u00e9 agora, a imagem que criamos est\u00e1 armazenada localmente, em nosso reposit\u00f3rio local de cont\u00eaineres. Se quisermos usar essa imagem em nosso ambiente K8s, precisamos coloc\u00e1-la em algum outro reposit\u00f3rio. No Kubernetes, n\u00e3o h\u00e1 tais funcionalidades, ent\u00e3o usaremos o dockerhub. Porque, em primeiro lugar, \u00e9 gratuito, e em segundo lugar, (quase) todos fazem isso.<\/p>\n
    Isso tamb\u00e9m \u00e9 muito simples, e s\u00f3 precisamos de uma conta no dockerhub.<\/p>\n
    Ent\u00e3o, configuramos o dockerhub e enviamos nossa imagem para l\u00e1.<\/p>\n
    \"Desculpe,<\/p>\n
    Passo 3 \u2013 iniciamos o Kubernetes<\/h4>\n
    \nExistem muitas maneiras de montar a configura\u00e7\u00e3o do Kubernetes para executar nosso 'Hello World', mas usaremos a mais simples, somos assim...<\/p>\n
    Para come\u00e7ar, iniciamos o cluster minikube:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Passo 4 \u2013 implantamos nossa imagem de cont\u00eainer<\/h4>\n
    \nAgora precisamos converter nosso c\u00f3digo e a imagem do cont\u00eainer em configura\u00e7\u00f5es do Kubernetes. Em outras palavras, precisamos da defini\u00e7\u00e3o de pod e deployment, apontando para nossa imagem de cont\u00eainer no Docker Hub. Uma das maneiras mais simples de fazer isso \u00e9 rodar o comando create deployment, especificando nossa imagem:<\/p>\n
    \"Desculpe,<\/p>\n
    kubectl create deployment hello-quarkus --image=gcolman\/quarkus-hello-world:1.0.0-SNAPSHOT\n<\/code><\/pre>\n
    \nCom este comando, dissemos ao nosso K8S para criar uma configura\u00e7\u00e3o de deployment que deve conter a especifica\u00e7\u00e3o do pod para nossa imagem de cont\u00eainer. Este comando tamb\u00e9m aplicar\u00e1 essa configura\u00e7\u00e3o ao nosso cluster minikube, criando um deployment que baixar\u00e1 nossa imagem de cont\u00eainer e iniciar\u00e1 o pod no cluster.<\/p>\n
    Passo 5 \u2013 abrindo o acesso ao nosso servi\u00e7o<\/h4>\n
    \nAgora que temos a imagem de cont\u00eainer implantada, \u00e9 hora de pensar em como configurar o acesso externo a este servi\u00e7o Restful, que est\u00e1, na verdade, programado em nosso c\u00f3digo.<\/p>\n
    Existem v\u00e1rias maneiras de fazer isso. Por exemplo, podemos usar o comando expose para criar automaticamente os componentes do Kubernetes necess\u00e1rios, como services e endpoints. E \u00e9 exatamente isso que faremos, executando o comando expose para nosso objeto de deployment:<\/p>\n
    kubectl expose deployment hello-quarkus --type=NodePort --port=8080\n<\/code><\/pre>\n
    \nVamos parar um momento para discutir a op\u00e7\u00e3o \"--type\" do comando expose.<\/p>\n
    Quando fazemos o expose e criamos os componentes necess\u00e1rios para executar nosso servi\u00e7o, precisamos que, entre outras coisas, seja poss\u00edvel acessar o servi\u00e7o hello-quarkus que est\u00e1 dentro da nossa rede program\u00e1vel. E o par\u00e2metro tipo<\/b> nos permite criar e conectar coisas como balanceadores de carga para direcionar o tr\u00e1fego para essa rede.<\/p>\n
    Por exemplo, especificando type=LoadBalancer<\/b>, automaticamente inicializamos um balanceador de carga na nuvem p\u00fablica, para nos conectar ao nosso cluster Kubernetes. Isso, claro, \u00e9 \u00f3timo, mas precisamos entender que essa configura\u00e7\u00e3o ficar\u00e1 rigidamente presa a uma nuvem p\u00fablica espec\u00edfica e ser\u00e1 mais dif\u00edcil de migrar entre inst\u00e2ncias de Kubernetes em diferentes ambientes.<\/p>\n
    No nosso exemplo type=NodePort<\/b>, ou seja, a chamada ao nosso servi\u00e7o \u00e9 feita pelo IP do n\u00f3 e pelo n\u00famero da porta. Esta op\u00e7\u00e3o permite n\u00e3o usar nenhuma nuvem p\u00fablica, mas requer uma s\u00e9rie de etapas adicionais. Primeiro, voc\u00ea precisa do seu pr\u00f3prio balanceador de carga, ent\u00e3o vamos implementar um balanceador de carga NGINX em nosso cluster.<\/p>\n
    Passo 6 \u2013 Instalando o balanceador de carga<\/h4>\n
    \nO minikube possui uma s\u00e9rie de funcionalidades de plataforma que facilitam a cria\u00e7\u00e3o dos componentes necess\u00e1rios para acesso externo, como os controladores de ingress. O Minikube vem com um controlador de ingress Nginx, e s\u00f3 precisamos ativ\u00e1-lo e configur\u00e1-lo.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nAgora, com um \u00fanico comando, criaremos o controlador de ingress Nginx que funcionar\u00e1 dentro do nosso cluster minikube:<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 Rodando 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    Passo 7 \u2013 Configurando o ingress<\/h4>\n
    \nAgora precisamos configurar o controlador de ingress Nginx para que ele possa processar as requisi\u00e7\u00f5es hello-quarkus.<\/p>\n
    \"Desculpe,<\/p>\n
    \"Desculpe,<\/p>\n
    E, finalmente, precisamos aplicar essa configura\u00e7\u00e3o.<\/p>\n
    \"Desculpe,<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"Desculpe,<\/p>\n
    Como estamos fazendo tudo isso em nosso computador, basta adicionar o IP do seu n\u00f3 ao arquivo \/etc\/hosts, para direcionar as requisi\u00e7\u00f5es http ao nosso minikube no balanceador de carga NGINX.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nPronto! Agora nosso servi\u00e7o minikube est\u00e1 acess\u00edvel externamente atrav\u00e9s do controlador de ingress Nginx.<\/p>\n
    \"Desculpe,<\/p>\n
    Ent\u00e3o, foi f\u00e1cil, n\u00e3o? Ou n\u00e3o t\u00e3o f\u00e1cil assim?<\/h3>\n
    \"Desculpe,<\/p>\n
    Executando no OpenShift (Code Ready Containers)<\/h3>\n
    \nAgora vamos ver como isso \u00e9 feito na Red Hat OpenShift Container Platform (OCP).<\/p>\n
    Assim como no caso do minikube, escolhemos o esquema de um cluster de n\u00f3 \u00fanico OpenShift na forma de Code Ready Containers (CRC). Antes, isso era conhecido como minishift e era baseado no projeto OpenShift Origin, agora \u00e9 CRC e constru\u00eddo na plataforma OpenShift da Red Hat.<\/p>\n
    Aqui, desculpe, n\u00e3o podemos deixar de dizer: \"OpenShift \u00e9 maravilhoso!\"<\/p>\n
    Inicialmente, pensamos em escrever que o desenvolvimento no OpenShift n\u00e3o \u00e9 diferente do desenvolvimento no Kubernetes. E, em ess\u00eancia, \u00e9 verdade. Mas, ao escrever este post, lembramos quantas etapas desnecess\u00e1rias s\u00e3o necess\u00e1rias quando voc\u00ea n\u00e3o tem o OpenShift, e por isso, reafirmamos, ele \u00e9 maravilhoso. N\u00f3s adoramos quando tudo \u00e9 f\u00e1cil, e a maneira como nosso exemplo \u00e9 implantado e iniciado no OpenShift em compara\u00e7\u00e3o com o minikube \u00e9, na verdade, o que nos motivou a escrever este post.<\/p>\n
    Vamos dar uma olhada no processo e ver o que precisaremos fazer.<\/p>\n
    Ent\u00e3o, no exemplo com minikube, come\u00e7amos com o Docker... Espere, n\u00e3o precisamos mais que o Docker esteja instalado na m\u00e1quina.<\/p>\n
    E o git local n\u00e3o \u00e9 necess\u00e1rio.
    \nE o Maven tamb\u00e9m n\u00e3o \u00e9 necess\u00e1rio.
    \nE n\u00e3o \u00e9 necess\u00e1rio criar manualmente a imagem do container.
    \nE n\u00e3o \u00e9 preciso procurar por algum reposit\u00f3rio de imagens de containers.
    \nE n\u00e3o \u00e9 necess\u00e1rio instalar o controlador de ingress.
    \nE tamb\u00e9m n\u00e3o \u00e9 preciso configurar o ingress.<\/b><\/p>\n
    Voc\u00eas entenderam, certo? Para implantar e executar nosso aplicativo no OpenShift, n\u00e3o \u00e9 necess\u00e1rio nada do que foi mencionado acima. E o processo \u00e9 o seguinte.<\/p>\n
    Passo 1 \u2013 Inicie seu cluster OpenShift<\/h4>\n
    \nEstamos usando o Code Ready Containers da Red Hat, que na verdade \u00e9 o mesmo Minikube, mas com um cluster OpenShift de n\u00f3 \u00fanico completo.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Passo 2 \u2013 Realize a constru\u00e7\u00e3o e implanta\u00e7\u00e3o do aplicativo no cluster OpenShift<\/h4>\n
    \n\u00c9 neste passo que a simplicidade e conveni\u00eancia do OpenShift se manifestam plenamente. Assim como em todas as distribui\u00e7\u00f5es do Kubernetes, temos v\u00e1rias maneiras de iniciar um aplicativo no cluster. E, como no caso do K8S, escolhemos deliberadamente a abordagem mais simples.<\/p>\n
    O OpenShift sempre foi constru\u00eddo como uma plataforma para criar e executar aplicativos em containers. A constru\u00e7\u00e3o de containers sempre foi uma parte essencial dessa plataforma, portanto, aqui existem muitos recursos adicionais do Kubernetes para as tarefas correspondentes.<\/p>\n
    Vamos usar o processo Source 2 Image (S2I) do OpenShift, que possui v\u00e1rias maneiras de pegar nosso c\u00f3digo-fonte (c\u00f3digo ou arquivos bin\u00e1rios) e transform\u00e1-lo em uma imagem de cont\u00eainer que pode ser executada em um cluster OpenShift.<\/p>\n
    Para isso, precisaremos de duas coisas:<\/p>\n