Criando cluster com Openshift

0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 0 Flares ×

O que a Red Hat diz sobre o Openshift ?

Openshift é um projeto de código aberto que mantém uma plataforma de aplicações baseados em contêiner, utilizando Docker, Kubernetes e Atomic.

Ok! Mas o que é de fato o OpenShift?

O OpenShift Origin é uma versão do Kubernetes otimizada para desenvolvimento contínuo de aplicações, o mesmo adiciona ferramentas para desenvolvedores e operações centralizadas nas ferramentas do Kubernetes, permitindo um rápido desenvolvimento de aplicativos, fácil implantação, escalabilidade e manutenção do ciclo de vida à longo prazo para pequenas e grandes equipes!

Introdução

Esse post tem como objetivo criar um cluster de OpenShift com um master e dois nós, a fim de fazer o deploy automático e definir o fluxo de integração contínua e entrega contínua para aplicações.

Cenário

3 máquinas virtuais rodando CentOS 7:

Máquina 1 – IP 192.168.1.100 – Master

Máquina 2 – IP 192.168.1.101 – Node1

Máquina 3 – IP 192.168.1.102 – Node2

Criando um cluster, através do método “Advanced” com ansible.

No master:

O arquivo /etc/ansible/hosts, deve ter o seguinte conteúdo.

Gerar par de chaves ssh.

Garantir acesso entre o master e os nodes sem pedir senha, para nao gerar erros na execução do playbook.

Executar o playbook para criação do cluster.

Pode-se ver quantos nodes existem no cluster, com o comando:

Após a execução do playbook ansible, ele fará as configurações iniciais do cluster, e mostrará que existem 2 nós, logo em seguida, será adicionado mais nó no cluster, colocando o ip do mesmo na tag [nodes] do playbook, e alterando o valor de “zone”.

Executar novamente o playbook:

Em seguida, ele terá adicionado mais um nó, para validar:

Após isso o frontend estará disponível no endereço “https://192.168.1.100:8443/console”

Por padrão, ele vem com dois usuários (system e developer), ambos com a senha “admin”, e também não há bloqueios de acesso, aceitando qualquer usuário e senha, caso haja necessidade de alterar o gerenciador de identidades, é necessário fazer as configurações no arquivo “Master Configuration File”, “/etc/origin/master/master-config.yaml”.

Existem três maneiras de fazer deploy de aplicações:

– Usando por base algum template já criado na CLI, que pode ser personalizado.

– Usando alguma imagem docker previamente criada, ou buscando alguma no docker hub.

– Importando o arquivo YAML ou JSON.

Para fazer o deploy da nossa aplicação de teste “newapp”, foi necessário criar um template do zero, pois se trata de uma aplicação nova e não existe esse template por default.

O template no Openshift é apenas uma lista de objetos arbitrários, ou seja, a ordem dos objetos não influencia na execução, elas apenas precisam existir no mesmo. Ele usa o formato JSON e é divido em “Blocos”, onde cada bloco tem uma função especifica, conforme explicado abaixo:

Bloco “template”:

“name” = Nome único para cada template,

“description” = Breve descrição do template,

“tags” = tags para agrupar o template no frontend,

“iconClass” = ícone que aparecerá no frontend para o template,

“labels” = Rotulo que outros blocos do template poderão usar como referencia.

Bloco “objects” (lista de objetos, usados no buildconfig)

“Secret” = Objeto usado para criar dentro do container um arquivo,

“name” = Nome do arquivo a ser criado,

“data” = Valor desse arquivo (nesse caso, a chave privada para clonar o projeto do nosso gitlab),

“Service” = Objeto usado para criar uma regra de redirecionamento de portas para o container,

“name” = Nesse caso foi usado o nome como parâmetro (caso haja necessidade de alteração do nome em diferentes situações), se esse valor for omitido, o OpenShift definirá um valor por default,

“spec” = Especificações desse objeto,

“ports” = Informações das portas,

“name” = Nome do encaminhamento,

“port” = Porta do host (maquina definida como “router”, no caso o próprio master),

“targetPort” = Porta do container, nesse caso foi criado um alias para a mesma, pois isso será declarado no BuildConfig.

“route” = Faz a criação da rota no node definido como master (haproxy),

“host” = Definido como variável, permitindo a personalização do domínio Ex: (newapp-hom.teste.com.br),

“tls” = Sessão onde são tratados os certificados e regras de rewrite (por default vem como Allow, permitindo o http),

“ImageStream” = Gera log da imagem utilizada, a cada alteração feita.

Bloco BuildConfig:

“BuildConfig” = O objeto do template responsável por criar uma imagem docker já com a aplicação, ou seja, pega uma imagem no docker hub Ex: openshift/php-55-centos7 (Centos com php5) e adiciona a nossa aplicação que o mesmo irá buscar no Gitlab,

“Source” = Local onde conterá o último commit da App,

“git” = informações referentes ao Git para garantir o build correto, na branch correta, etc.

“uri” = Nome do recurso que será feito o clone,

“ref” = Branch onde estará o recurso,

“sourceSecret” = Chave que será utilizada para baixar o código,

From

“ImageStreamTag” = Recebe o namespace da imagem, nome da linguagem e versão,

Output

“ImageStreamTag” = Nome que será atribuído a essa nova imagem (com o código),

OBS: Esse bloco utiliza em background o comando s2i, portanto caso haja a necessidade de testes prévios, ele é será muito útil, segue um exemplo de utilização do mesmo.

Triggers:

“type” = Especifica de quem esse template receberá triggers Ex: (git, Gitlab, Github), a genérica geralmente é usada para git e gitlab, existe uma especifica para o Github,

“secret” = qual secret será usada quando essa trigger for acionada,

“allowEnv” = Permite o uso de variáveis de ambientes do container.

OBS: Para funcionar corretamente as “Secrets”, será necessário gerar a chave primaria no node master, conforme os passos abaixo e colocar a pública no Gitlab.

Permitir que o builder do OpenShift use a chave

Exportar a chave para todos os namespaces

Bloco “DeploymentConfig”

Tipos de strategy:

“Rolling” = Tipo de estratégia que mantém o ciclo de vida do container quando receber a webhook,

“Recreate” = Não mantém o clico de vida após receber a webhook ,

“trigger” = Ao receber a webhook (aviso de alteração na imagem) automaticamente ele aplicará a ação de acordo com a strategy, e garantirá que a última versão estará em produção,

“Replicas” = Número de replicas que serão criadas por default ao fazer deploy dessa imagem template,

“containers” = Lista de informações passadas para criação e recriação dessa imagem,

“name” = alias para a porta do container,

“containerPort” = porta do container que a aplicação estará ouvindo,

“protocol” = protocolo que a mesma trabalha,

Bloco de parâmetros:

“parameters” = Esse bloco é responsável por definir todas as variáveis utilizadas no template, caso haja necessidade de fazer deploy da mesma aplicação com diferentes parametros se torna possível com o mesmo template,

“name” = Nome do parametro, utilizado no template com ${},

“description” = aparecerá no frontend como exemplo de preenchimento,

“value” = valor que será usado por default.

Após finalizar a escrita do template, podemos criar um diretório para os templates personalizados dentro de “/usr/share/openshift/”

Para adicionar o template criado ao cluster, no namespace openshift

Nesse momento, o template “newapp”, estará pronto para ser usado no frontend. Após selecionar, podemos fazer alteração dos parametros.

No frontend, podemos criar um novo projeto com o nome de deploy-newapp:

Logo em seguida, ele retornará todos os templates que existem no namespace “openshift”, podemos fazer um filtro pelo nosso template.

Após clicar no nosso template, ele irá mostras todas as opções passadas como parametro (variáveis).

Caso nenhuma alteração seja feita, ele utilizará os valores default.

Após a criação, podemos clicar em “Go to overview”, para verificar  via web o status do nosso build.

No menu a esquerda, podemos verificar cada parte do nosso template.

– Deployments (alterações no campo “Deploymentconfig”)

– Pods (Verificar os containers ou replicas dos mesmos)

– Services (Obter informações da aplicação como ip, porta, name, etc)

– Routes (Verificar as rotas criadas pelo próprio Openshift (haproxy) ex: https://newapp.com.br)

– Ciclo de vida dos builds (versionamento a cada nova webhook)

– Limitação de recursos no projeto

– Alterações de quais usuários podem editar e ou verificar o projeto

– Gerenciar os objetos “secrets” do projeto

– Gerenciar algum outro recurso que haja no template

Storage

– Verificar os volumes criados nesse projeto

Monitoring

– Verificar os logs do projeto

Na documentação oficial da Red Hat, é recomendado que a instalação seja feita com o SELinux em modo “enforcing” e o selinux type em modo “targeted”, caso esteja diferente disso, a execução do playbook falhará.

Com isso temos um cluster de OpenShift em produção e também uma aplicação criada. Em breve farei outro post explicando como aumentar o número de réplicas, criar o “autoscaller”, utilizar certificado para tls e criar entradas DNS com “rewrite”.

Conclusão

O cluster de Openshift é muito simples de se configurar. E após entender cada campo do template, fica muito fácil criar e personalizar os templates de acordo com a aplicação, linguagem e etc.

Por isso espero que este post lhe seja útil e que te ajude a compreender de forma fácil como funciona o Openshift. 😀

Mais informações sobre o Openshift podem ser obtidas diretamente em sua documentação oficial: https://docs.openshift.org/

Edgar da Silva Costa Filho é um sysadmin apaixonado por Linux, com foco na cultura DevOps, Formado em Redes de Computadores pela FIAP. Com 4 anos de experiência profissional em Tecnologia da Informação, atualmente atuando com desenvolvimento em python, infra ágil(Docker, Puppet, Ansible, Git, Jenkins e Rundeck), NoSQL (MongoDB) e também atuando como instrutor, ministrando cursos de Linux e suas mais diversas tecnologias, capacitando equipes de TI em sistemas Linux e soluções Open Source.

edgarsilva948

Edgar da Silva Costa Filho é um sysadmin apaixonado por Linux, com foco na cultura DevOps, Formado em Redes de Computadores pela FIAP. Com 4 anos de experiência profissional em Tecnologia da Informação, atualmente atuando com desenvolvimento em python, infra ágil(Docker, Puppet, Ansible, Git, Jenkins e Rundeck), NoSQL (MongoDB) e também atuando como instrutor, ministrando cursos de Linux e suas mais diversas tecnologias, capacitando equipes de TI em sistemas Linux e soluções Open Source.