OpenShift - Guia rápido

OpenShift é uma plataforma de desenvolvimento como serviço (PaaS) hospedada pela Red Hat. É uma plataforma amigável e baseada em nuvem de código aberto usada para criar, testar e executar aplicativos e, finalmente, implantá-los na nuvem.

OpenShift é capaz de gerenciar aplicativos escritos em diferentes linguagens, como Node.js, Ruby, Python, Perl e Java. Um dos principais recursos do OpenShift é que ele é extensível, o que ajuda os usuários a oferecer suporte ao aplicativo escrito em outras linguagens.

O OpenShift vem com vários conceitos de virtualização como sua camada de abstração. O conceito subjacente do OpenShift é baseado na virtualização.

Virtualização

Em geral, a virtualização pode ser definida como a criação de um sistema virtual, em vez da versão física ou real de qualquer coisa, começando com o sistema, armazenamento ou sistema operacional. O principal objetivo da virtualização é tornar a infraestrutura de TI mais escalonável e confiável. O conceito de virtualização existe há décadas e, com a evolução da indústria de TI hoje, pode ser aplicado a uma ampla gama de camadas, desde o nível de sistema, nível de hardware, até virtualização de nível de servidor.

Como funciona

Ele pode ser descrito como uma tecnologia na qual qualquer aplicativo ou sistema operacional é abstraído de sua camada física real. Um uso importante da tecnologia de virtualização é a virtualização de servidor, que usa um software chamado hipervisor para abstrair a camada do hardware subjacente. O desempenho de um sistema operacional rodando em virtualização é tão bom quanto quando rodando no hardware físico. No entanto, o conceito de virtualização é popular, pois a maior parte do sistema e do aplicativo em execução não exige o uso do hardware subjacente.

Arquitetura Física vs Virtual

Tipos de virtualização

• Application Virtualization- Neste método, o aplicativo é abstraído do sistema operacional subjacente. Esse método é muito útil no qual o aplicativo pode ser executado isoladamente, sem depender do sistema operacional subjacente.

• Desktop Virtualization- Este método é usado para reduzir a carga da estação de trabalho na qual se pode acessar a área de trabalho remotamente, usando um cliente fino na mesa. Neste método, os desktops são executados principalmente em um datacenter. Um exemplo clássico pode ser uma Virtual Desktop Image (VDI) que é usada na maioria das organizações.

• Data Virtualization - É um método de abstrair e fugir do método tradicional de gerenciamento de dados e dados.

• Server Virtualization- Neste método, os recursos relacionados ao servidor são virtualizados, o que inclui o servidor físico, o processo e o sistema operacional. O software que permite essa abstração costuma ser chamado de hipervisor.

• Storage Virtualization - É o processo de agrupar vários dispositivos de armazenamento em um único dispositivo de armazenamento gerenciado a partir de um único console central.

• Network Virtualization - É o método em que todos os recursos de rede disponíveis são combinados, dividindo a largura de banda e os canais disponíveis, cada um independente um do outro.

OpenShift

OpenShift é um aplicativo Platform as a Service (PaaS) habilitado para nuvem. É uma tecnologia de código aberto que ajuda as organizações a mover sua infraestrutura e plataforma de aplicativos tradicionais de meios físicos virtuais para a nuvem.

O OpenShift oferece suporte a uma grande variedade de aplicativos, que podem ser facilmente desenvolvidos e implantados na plataforma de nuvem OpenShift. O OpenShift suporta basicamente três tipos de plataformas para desenvolvedores e usuários.

Infraestrutura como serviço (IaaS)

Nesse formato, o provedor de serviços fornece máquinas virtuais de nível de hardware com algumas configurações de hardware virtual predefinidas. Existem vários concorrentes neste espaço, começando pela nuvem AWS Google, Rackspace e muitos mais.

A principal desvantagem de ter IaaS após um longo procedimento de configuração e investimento é que, ainda se é responsável pela instalação e manutenção do sistema operacional e pacotes de servidores, gerenciando a rede de infraestrutura e cuidando da administração básica do sistema.

Software as a Service (SaaS)

Com SaaS, é o que menos se preocupa com a infraestrutura subjacente. É tão simples quanto plug and play, em que o usuário só precisa se inscrever para os serviços e começar a usá-los. A principal desvantagem dessa configuração é que só se pode realizar uma quantidade mínima de personalização, que é permitida pelo provedor de serviços. Um dos exemplos mais comuns de SaaS é o Gmail, onde o usuário só precisa fazer o login e começar a usá-lo. O usuário também pode fazer algumas pequenas modificações em sua conta. No entanto, não é muito útil do ponto de vista do desenvolvedor.

Plataforma como serviço (PaaS)

Pode ser considerado uma camada intermediária entre SaaS e IaaS. O alvo principal da avaliação de PaaS é para desenvolvedores nos quais o ambiente de desenvolvimento pode ser ativado com alguns comandos. Esses ambientes são projetados de forma que possam atender a todas as necessidades de desenvolvimento, desde um servidor de aplicação web com banco de dados. Para fazer isso, você só precisa de um único comando e o provedor de serviços faz o trabalho por você.

Por que usar o OpenShift?

O OpenShift fornece uma plataforma comum para unidades corporativas hospedar seus aplicativos na nuvem sem se preocupar com o sistema operacional subjacente. Isso torna muito fácil usar, desenvolver e implantar aplicativos na nuvem. Um dos principais recursos é que ele fornece recursos de rede e hardware gerenciados para todos os tipos de desenvolvimento e teste. Com o OpenShift, o desenvolvedor de PaaS tem a liberdade de projetar seu ambiente requerido com especificações.

O OpenShift oferece diferentes tipos de acordo de nível de serviço quando se trata de planos de serviço.

Free - Este plano é limitado a três anos com 1 GB de espaço para cada um.

Bronze - Este plano inclui 3 anos e se expande até 16 anos com 1GB de espaço por ano.

Sliver - Este é o plano de bronze de 16 anos, porém, tem capacidade de armazenamento de 6GB sem custo adicional.

Além dos recursos acima, o OpenShift também oferece uma versão local conhecida como OpenShift Enterprise. No OpenShift, os desenvolvedores têm a vantagem de projetar aplicativos escalonáveis ​​e não escaláveis, e esses designs são implementados usando servidores HAproxy.

Características

Existem vários recursos suportados pelo OpenShift. Poucos deles são -

• Suporte a vários idiomas
• Suporte a múltiplos bancos de dados
• Sistema de cartucho extensível
• Gerenciamento de versão do código fonte
• Implantação com um clique
• Suporte a vários ambientes
• Fluxo de trabalho do desenvolvedor padronizado
• Dependência e gerenciamento de compilação
• Dimensionamento automático de aplicativos
• Console da Web responsivo
• Conjunto de ferramentas de linha de comando rico
• Login SSH remoto para aplicativos
• Suporte API Rest
• Pilha de aplicativos de autoatendimento sob demanda
• Serviços de banco de dados integrados
• Integração Contínua e Gerenciamento de Liberação
• Integração IDE
• Depuração remota de aplicativos

O OpenShift surgiu a partir de sua base chamada OpenShift V2, que era baseada principalmente no conceito de ano e cartuchos, onde cada componente tem suas especificações desde a criação da máquina até a implantação do aplicativo, desde a construção até a implantação do aplicativo.

Cartridges - Eles foram o ponto focal da construção de um novo aplicativo a partir do tipo de aplicativo que o ambiente requer para executá-los e todas as dependências satisfeitas nesta seção.

year- Pode ser definido como a máquina de metal de urso ou servidor com certas especificações em relação aos recursos, memória e CPU. Eles foram considerados como uma unidade fundamental para executar um aplicativo.

Application - Simplesmente se referem ao aplicativo ou qualquer aplicativo de integração que será implantado e executado no ambiente OpenShift.

À medida que avançamos na seção, discutiremos os diferentes formatos e ofertas do OpenShift. Nos primeiros dias, o OpenShift tinha três versões principais.

OpenShift Origin- Esta foi a adição da comunidade ou versão de código aberto do OpenShift. Também era conhecido como projeto upstream para outras duas versões.

OpenShift Online - É uma PaaS pública como um serviço hospedado na AWS.

OpenShift Enterprise - é a versão reforçada do OpenShift com ISV ​​e licenças de fornecedores.

OpenShift Online

OpenShift online é uma oferta da comunidade OpenShift usando a qual é possível construir, implantar e dimensionar aplicativos em contêineres rapidamente na nuvem pública. É a plataforma de hospedagem e desenvolvimento de aplicativos em nuvem pública da Red Hat, que permite provisionamento, gerenciamento e escalonamento automatizados de aplicativos, o que ajuda o desenvolvedor a se concentrar na escrita da lógica do aplicativo.

Configurando uma conta no Red Hat OpenShift Online

Step 1 - Vá para o navegador e visite o site https://manage.openshift.com/

Step 2 - Se você tiver uma conta Red Hat, faça login na conta OpenShift usando o ID de login e senha da Red Hat usando a seguinte URL. https://developers.redhat.com

Step 3 - Se você não possui um login de conta Red Hat, então cadastre-se no serviço online OpenShift usando o seguinte link.

https://developers.redhat.com/auth/realms/rhd/login-actions/registration?code=G4w-myLd3GCH_QZCqMUmIOQlU7DIf_gfIvGu38nnzZQ.cb229a9d-3cff-4c58-b7f6-7b2c9eb17926

Após o login, você verá a seguinte página.

Assim que você tiver tudo pronto, o Red Hat mostrará alguns detalhes básicos da conta, conforme mostrado na imagem a seguir.

Finalmente, quando você estiver logado, você verá a seguinte página.

Plataforma de contêiner OpenShift

A plataforma de contêiner OpenShift é uma plataforma corporativa que ajuda várias equipes, como equipes de desenvolvimento e operações de TI, a construir e implantar infraestrutura em contêineres. Todos os contêineres construídos no OpenShift usam uma tecnologia de contêiner Docker muito confiável, que pode ser implantada em qualquer data center de plataformas em nuvem hospedadas publicamente.

A plataforma de contêiner OpenShift era formalmente conhecida como OpenShift Enterprises. É uma plataforma privada local da Red Hat como serviço, construída com base no conceito central de contêineres de aplicativos com tecnologia Docker, onde a orquestração e a administração são gerenciadas pelo Kubernetes.

Em outras palavras, o OpenShift traz o Docker e o Kubernetes juntos para o nível empresarial. É um software de plataforma de contêiner para unidades corporativas para implantar e gerenciar candidatos em uma infraestrutura de sua escolha. Por exemplo, hospedar instâncias OpenShift em instâncias AWS.

A plataforma de contêiner OpenShift está disponível em two package levels.

OpenShift Container Local- Destina-se aos desenvolvedores que desejam implantar e testar aplicativos na máquina local. Este pacote é usado principalmente por equipes de desenvolvimento para desenvolver e testar aplicativos.

OpenShift Container Lab - Isso é projetado para avaliação estendida do aplicativo, começando do desenvolvimento até a implantação no ambiente de pré-produção.

OpenShift Dedicated

Esta é outra oferta adicionada ao portfólio do OpenShift, em que o cliente pode optar por hospedar uma plataforma em contêiner em qualquer nuvem pública de sua escolha. Isso dá ao usuário final uma verdadeira sensação de oferta de várias nuvens, onde ele pode usar o OpenShift em qualquer nuvem que satisfaça suas necessidades.

Esta é uma das mais novas ofertas da Red Hat, onde o usuário final pode usar o OpenShift para construir, testar, implantar e executar seu aplicativo no OpenShift, que está hospedado na nuvem.

Recursos do OpenShift Dedicated

OpenShift dedicado oferece plataforma de aplicação de solução personalizada em nuvem pública e é herdada da tecnologia OpenShift 3.

• Extensible and Open - Isso se baseia no conceito aberto do Docker e implantado na nuvem, por causa do qual pode ser expandido como e quando necessário.

• Portability - Como é construído usando o Docker, os aplicativos em execução no Docker podem ser facilmente enviados de um lugar para outro, onde o Docker é compatível.

• Orchestration - Com o OpenShift 3, um dos principais recursos da orquestração de contêineres e gerenciamento de cluster é compatível com o Kubernetes, que veio a ser oferecido com o OpenShift versão 3.

• Automation - Esta versão do OpenShift é habilitada com o recurso de gerenciamento de código-fonte, automação de build e automação de implantação, o que o torna muito popular no mercado como um provedor de plataforma como serviço.

Concorrentes do OpenShift

Google App Engine- Esta é a plataforma gratuita do Google para desenvolver e hospedar aplicativos da web. O app engine do Google oferece uma plataforma de desenvolvimento e implantação rápida.

Microsoft Azure - A nuvem Azure é hospedada pela Microsoft em seus data centers.

Amazon Elastic Cloud Compute - São serviços integrados fornecidos pela Amazon, que ajudam no desenvolvimento e hospedagem de aplicativos da web escaláveis ​​na nuvem.

Cloud Foundry - é uma plataforma PaaS de código aberto para aplicativos Java, Ruby, Python e Node.js.

CloudStack - CloudStack da Apache é um projeto desenvolvido pela Citrix e foi projetado para se tornar um concorrente direto do OpenShift e do OpenStack.

OpenStack - Outra tecnologia de nuvem fornecida pela Red Hat para computação em nuvem.

Kubernetes - É uma orquestração direta e tecnologia de gerenciamento de cluster desenvolvida para gerenciar o contêiner Docker.

OpenShift é um sistema em camadas em que cada camada é fortemente vinculada à outra usando o cluster Kubernetes e Docker. A arquitetura do OpenShift é projetada de forma que possa dar suporte e gerenciar contêineres Docker, que são hospedados na parte superior de todas as camadas usando Kubernetes. Ao contrário da versão anterior do OpenShift V2, a nova versão do OpenShift V3 oferece suporte à infraestrutura em contêiner. Neste modelo, o Docker ajuda na criação de contêineres leves baseados em Linux e o Kubernetes oferece suporte à tarefa de orquestrar e gerenciar contêineres em vários hosts.

Componentes do OpenShift

Um dos principais componentes da arquitetura OpenShift é gerenciar a infraestrutura em contêineres no Kubernetes. O Kubernetes é responsável pela implantação e gerenciamento da infraestrutura. Em qualquer cluster Kubernetes, podemos ter mais de um nó mestre e vários nós, o que garante que não haja ponto de falha na configuração.

Componentes da máquina mestre do Kubernetes

Etcd- Armazena as informações de configuração, que podem ser utilizadas por cada um dos nós do cluster. É um armazenamento de valor de chave de alta disponibilidade que pode ser distribuído entre vários nós. Ele só deve ser acessível pelo servidor da API Kubernetes, pois pode conter informações confidenciais. É uma Loja de valores-chave distribuída acessível a todos.

API Server- Kubernetes é um servidor de API que fornece todas as operações no cluster usando a API. O servidor API implementa uma interface que significa que diferentes ferramentas e bibliotecas podem se comunicar prontamente com ele. Um kubeconfig é um pacote junto com as ferramentas do lado do servidor que podem ser usadas para comunicação. Ele expõe a API Kubernetes ”.

Controller Manager- Este componente é responsável pela maioria dos coletores que regulam o estado do cluster e executam uma tarefa. Ele pode ser considerado um daemon que é executado em um loop sem fim e é responsável por coletar e enviar informações para o servidor API. Ele trabalha para obter o estado compartilhado do cluster e, em seguida, faz alterações para trazer o status atual do servidor para o estado desejado. Os controladores principais são controlador de replicação, controlador de terminal, controlador de namespace e controlador de conta de serviço. O gerenciador de controlador executa diferentes tipos de controladores para lidar com nós, endpoint, etc.

Scheduler- É um componente-chave do mestre Kubernetes. É um serviço em master responsável pela distribuição da carga de trabalho. Ele é responsável por rastrear a utilização da carga de trabalho nos nós do cluster e, em seguida, colocar a carga de trabalho na qual os recursos estão disponíveis e aceitar a carga de trabalho. Em outras palavras, esse é o mecanismo responsável por alocar pods aos nós disponíveis. O agendador é responsável pela utilização da carga de trabalho e alocação de um pod para um novo nó.

Componentes de nó do Kubernetes

A seguir estão os principais componentes do servidor Node, que são necessários para se comunicar com o mestre Kubernetes.

Docker - O primeiro requisito de cada nó é o Docker, que ajuda a executar os contêineres de aplicativos encapsulados em um ambiente operacional relativamente isolado, mas leve.

Kubelet Service- Este é um pequeno serviço em cada nó, que é responsável por retransmitir informações de e para o serviço do plano de controle. Ele interage com o armazenamento etcd para ler os detalhes de configuração e valores Wright. Este se comunica com o componente mestre para receber comandos e trabalhar. O processo kubelet, então, assume a responsabilidade por manter o estado de trabalho e o servidor de nó. Ele gerencia regras de rede, encaminhamento de porta, etc.

Kubernetes Proxy Service- Este é um serviço de proxy que roda em cada nó e ajuda a disponibilizar os serviços para o host externo. Ajuda a encaminhar a solicitação para contêineres corretos. O serviço Kubernetes Proxy é capaz de realizar balanceamento de carga primitivo. Ele garante que o ambiente de rede seja previsível e acessível, mas, ao mesmo tempo, também isolado. Ele gerencia pods em nós, volumes, segredos, criando novos contêineres, verificação de integridade etc.

OpenShift Container Registry integrado

O registro de contêiner OpenShift é uma unidade de armazenamento embutida do Red Hat, que é usada para armazenar imagens Docker. Com a última versão integrada do OpenShift, surgiu com uma interface de usuário para visualizar imagens no armazenamento interno do OpenShift. Esses registros são capazes de conter imagens com tags especificadas, que mais tarde são usadas para construir contêineres a partir deles.

Termos usados ​​com frequência

Image- As imagens do Kubernetes (Docker) são os principais blocos de construção da infraestrutura em contêiner. A partir de agora, o Kubernetes oferece suporte apenas a imagens Docker. Cada contêiner em um pod tem sua imagem Docker em execução dentro dele. Ao configurar um pod, a propriedade da imagem no arquivo de configuração tem a mesma sintaxe do comando Docker.

Project - Eles podem ser definidos como a versão renomeada do domínio que estava presente na versão anterior do OpenShift V2.

Container - Eles são criados depois que a imagem é implantada em um nó de cluster do Kubernetes.

Node- Um nó é uma máquina em funcionamento no cluster Kubernetes, também conhecido como subordinado do mestre. Eles são unidades de trabalho que podem ser uma instância física, VM ou nuvem.

Pod- Um pod é uma coleção de contêineres e seu armazenamento dentro de um nó de um cluster Kubernetes. É possível criar um pod com vários contêineres dentro dele. Por exemplo, mantendo o contêiner do banco de dados e o contêiner do servidor da web dentro do pod.

Neste capítulo, aprenderemos sobre a configuração do ambiente do OpenShift.

Requisitos do sistema

Para configurar o OpenShift empresarial, é necessário ter uma conta Red Hat ativa. Como o OpenShift funciona na arquitetura mestre e de nó do Kubernetes, precisamos configurá-los em máquinas separadas, em que uma máquina atua como mestre e a outra funciona no nó. Para configurar ambos, existem requisitos mínimos de sistema.

Configuração da Máquina Mestre

A seguir estão os requisitos mínimos do sistema para a configuração da máquina mestre.

• Uma máquina base hospedada em ambiente físico, virtual ou em qualquer ambiente de nuvem.

• Pelo menos Linux 7 com os pacotes necessários nessa instância.

• 2 núcleos de CPU.

• Pelo menos 8 GB de RAM.

• 30 GB de memória interna do disco rígido.

Configuração de Máquina Nó

• Imagem de base física ou virtual conforme fornecida para a máquina mestre.
• Pelo menos Linux 7 na máquina.
• Docker instalado com versão não inferior a 1.6.
• 1 núcleo de CPU.
• 8 GB de RAM.
• Disco rígido de 15 GB para hospedar imagens e 15 GB para armazenar imagens.

Guia passo a passo para a configuração do OpenShift

Na descrição a seguir, vamos configurar o ambiente de laboratório OpenShift, que pode ser estendido posteriormente para um cluster maior. Como o OpenShift requer configuração de mestre e nó, precisaríamos de pelo menos duas máquinas hospedadas em nuvem, física ou virtual.

Step 1- Instale primeiro o Linux em ambas as máquinas, onde o Linux 7 deve ser a versão mínima. Isso pode ser feito usando os seguintes comandos se alguém tiver uma assinatura Red Hat ativa.

# subscription-manager repos --disable = "*"

# subscription-manager repos --enable = "rhel-7-server-rpms"

# subscription-manager repos --enable = "rhel-7-server-extras-rpms"

# subscription-manager repos --enable = "rhel-7-server-optional-rpms"

# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install python-virtualenv

# yum install gcc

# yum install httpd-tools

# yum install docker

# yum update

Assim que tivermos todos os pacotes básicos acima instalados em ambas as máquinas, a próxima etapa seria configurar o Docker nas respectivas máquinas.

Step 2- Configure o Docker para permitir a comunicação insegura apenas na rede local. Para isso, edite o arquivo Docker dentro de / etc / sysconfig. Se o arquivo não estiver presente, você precisará criá-lo manualmente.

# vi /etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

Depois de configurar o Docker na máquina mestre, precisamos configurar uma comunicação sem senha entre as duas máquinas. Para isso, usaremos autenticação de chave pública e privada.

Step 3 - Gere chaves na máquina mestre e, em seguida, copie a chave id_rsa.pub para o arquivo de chave autorizado da máquina do nó, o que pode ser feito usando o seguinte comando.

# ssh-keygen

# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

Depois de ter todas as configurações acima definidas, o próximo passo é configurar o OpenShift versão 3 na máquina mestre.

Step 4 - Na máquina mestre, execute o seguinte comando curl.

# sh <(curl -s https://install.openshift.com/ose)

O comando acima colocará a configuração em vigor para OSV3. A próxima etapa seria configurar o OpenShift V3 na máquina.

Se você não puder fazer o download diretamente da Internet, pode ser feito o download em https://install.openshift.com/portable/oo-install-ose.tgz como um pacote tar a partir do qual o instalador pode ser executado na máquina master local.

Assim que tivermos a configuração pronta, precisamos começar com a configuração real do OSV3 nas máquinas. Esta configuração é muito específica para testar o ambiente de produção real, temos o LDAP e outras coisas no lugar.

Step 5 - Na máquina mestre, configure o seguinte código localizado em /etc/openshift/master/master-config.yaml

# vi /etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /root/users.htpasswd
routingConfig:
subdomain: testing.com

Em seguida, crie um usuário padrão para administração padrão.

# htpasswd -c /root/users.htpasswd admin

Step 6- Como o OpenShift usa o registro Docker para configurar imagens, precisamos configurar o registro Docker. Isso é usado para criar e armazenar as imagens do Docker após a construção.

Crie um diretório na máquina do nó OpenShift usando o seguinte comando.

# mkdir /images

Em seguida, faça login na máquina master usando as credenciais de administrador padrão, que são criadas durante a configuração do registro.

# oc login
Username: system:admin

Mude para o projeto padrão criado.

# oc project default

Step 7 - Crie um Docker Registry.

#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -

Edite os privilégios do usuário.

#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry

Crie e edite o registro de imagens.

#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images

Step 8 - Crie um roteamento padrão.

Por padrão, OpenShift usa OpenVswitch como rede de software. Use o seguinte comando para criar um roteamento padrão. Isso é usado para balanceamento de carga e roteamento de proxy. O roteador é semelhante ao registro do Docker e também é executado em um registro.

# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -

Em seguida, edite os privilégios do usuário.

#oc edit scc privileged
users:
   - system:serviceaccount:openshift-infra:build-controller
   - system:serviceaccount:default:registry
   - system:serviceaccount:default:router

#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'

Step 9 - Configure o DNS.

Para lidar com a solicitação de URL, o OpenShift precisa de um ambiente DNS funcional. Essa configuração DNS é necessária para criar um curinga, que é necessário para criar um curinga DNS que aponta para um roteador.

# yum install bind-utils bind

# systemctl start named

# systemctl enable named

vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
   10.38.55.13;
   ;
};

zone "lab.com" IN {
   type master;
   file "/var/named/dynamic/test.com.zone";
   allow-update { none; };
};

Step 10- A etapa final seria configurar o servidor github na máquina mestre OpenShift V3, que é opcional. Isso pode ser feito facilmente usando a seguinte seqüência de comandos.

#yum install curl openssh-server

#systemctl enable sshd

# systemctl start sshd

# firewall-cmd --permanent --add-service = http

# systemctl reload firewalld

#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-

#yum install gitlab-ce

# gitlab-ctl reconfigure

Assim que a configuração acima estiver concluída, você pode verificar testando e implantando aplicativos, sobre os quais saberemos mais nos capítulos subsequentes.

Antes de começar com a configuração e implementação reais dos aplicativos, precisamos entender alguns termos e conceitos básicos usados ​​no OpenShift V3.

Recipientes e imagens

Imagens

Esses são os blocos de construção básicos do OpenShift, que são formados por imagens Docker. Em cada pod do OpenShift, o cluster tem suas próprias imagens em execução dentro dele. Quando configuramos um pod, temos um campo que será agrupado do registro. Este arquivo de configuração puxará a imagem e a implantará no nó do cluster.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> Name of Pod
      spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull

Para extrair e criar uma imagem dele, execute o seguinte comando. OC é o cliente para se comunicar com o ambiente OpenShift após o login.

$ oc create –f Tesing_for_Image_pull

Recipiente

Isso é criado quando a imagem Docker é implantada no cluster OpenShift. Ao definir qualquer configuração, definimos a seção do contêiner no arquivo de configuração. Um contêiner pode ter várias imagens em execução dentro e todos os contêineres em execução no nó do cluster são gerenciados pelo OpenShift Kubernetes.

spec:
   containers:
   - name: py ------------------------> Name of the container
   image: python----------> Image going to get deployed on container
   command: [“python”, “SUCCESS”]
   restartPocliy: Never --------> Restart policy of container

A seguir estão as especificações para definir um contêiner com várias imagens em execução dentro dele.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
   - containerPort: 7500
      imagePullPolicy: Always
      -name: Database
      Image: mongoDB
      Ports:
      - containerPort: 7501
imagePullPolicy: Always

Na configuração acima, definimos um pod de vários contêineres com duas imagens de Tomcat e MongoDB dentro dele.

Pods e serviços

Pods

O pod pode ser definido como uma coleção de contêineres e seu armazenamento dentro de um nó do cluster OpenShift (Kubernetes). Em geral, temos dois tipos de pod, começando de um pod de contêiner único a pod de vários contêineres.

Single Container Pod - Eles podem ser facilmente criados com o comando OC ou por um arquivo yml de configuração básica.

$ oc run <name of pod> --image = <name of the image from registry>

Crie-o com um arquivo yaml simples da seguinte maneira.

apiVersion: v1
kind: Pod
metadata:
   name: apache
spec:
   containers:
   - name: apache
   image: apache: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always

Depois que o arquivo acima for criado, ele gerará um pod com o seguinte comando.

$ oc create –f apache.yml

Multi-Container Pod- Os pods de vários contêineres são aqueles em que temos mais de um contêiner em execução. Eles são criados usando arquivos yaml da seguinte maneira.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
      - containerPort: 7501
imagePullPolicy: Always

Depois de criar esses arquivos, podemos simplesmente usar o mesmo método acima para criar um contêiner.

Service- Como temos um conjunto de containers rodando dentro de um pod, da mesma forma temos um serviço que pode ser definido como um conjunto lógico de pods. É uma camada abstrata no topo do pod, que fornece um único IP e nome DNS por meio do qual os pods podem ser acessados. O serviço ajuda a gerenciar a configuração de balanceamento de carga e a dimensionar o pod com muita facilidade. No OpenShift, um serviço é um objeto REST cuja deificação pode ser postada no apiService no mestre OpenShift para criar uma nova instância.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
      - port: 8080
         targetPort: 31999

Builds e streams

Builds

No OpenShift, construir é um processo de transformar imagens em contêineres. É o processamento que converte o código-fonte em uma imagem. Este processo de construção funciona em uma estratégia pré-definida de construção de código-fonte para imagem.

A construção processa várias estratégias e fontes.

Estratégias de construção

• Source to Image- Esta é basicamente uma ferramenta que auxilia na construção de imagens reproduzíveis. Essas imagens estão sempre em um estágio pronto para execução usando o comando run do Docker.

• Docker Build - Este é o processo no qual as imagens são construídas usando o arquivo Docker, executando um comando simples de construção do Docker.

• Custom Build - Estas são as compilações usadas para criar imagens base do Docker.

Fontes de compilação

Git- Esta fonte é usada quando o repositório git é usado para construir imagens. O Dockerfile é opcional. As configurações do código-fonte se parecem com o seguinte.

source:
type: "Git"
git:
   uri: "https://github.com/vipin/testing.git"
   ref: "master"
contextDir: "app/dir"
dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"

Dockerfile - O Dockerfile é usado como uma entrada no arquivo de configuração.

source:
   type: "Dockerfile"
   dockerfile: "FROM ubuntu: latest
   RUN yum install -y httpd"

Image Streams- Os fluxos de imagem são criados após puxar as imagens. A vantagem de um fluxo de imagem é que ele procura por atualizações na nova versão de uma imagem. Isso é usado para comparar qualquer número de imagens de contêiner formatadas do Docker identificadas por tags.

Os fluxos de imagens podem executar uma ação automaticamente quando uma nova imagem é criada. Todas as compilações e implantações podem observar a ação da imagem e executar uma ação de acordo. A seguir, definimos como construir um fluxo.

apiVersion: v1
kind: ImageStream
metadata:
   annotations:
      openshift.io/generated-by: OpenShiftNewApp
   generation: 1
   labels:
      app: ruby-sample-build
   selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
   uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
   dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
   tags:
   - items:
      - created: 2016-01-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
      generation: 1
      image: vklnld908.int.clsa.com/vipin/test
   tag: latest

Rotas e modelos

Rotas

No OpenShift, o roteamento é um método de expor o serviço ao mundo externo, criando e configurando um nome de host acessível externamente. Rotas e endpoints são usados ​​para expor o serviço ao mundo externo, de onde o usuário pode usar a conectividade de nome (DNS) para acessar o aplicativo definido.

No OpenShift, as rotas são criadas usando roteadores que são implantados pelo administrador do OpenShift no cluster. Os roteadores são usados ​​para vincular as portas HTTP (80) e https (443) a aplicativos externos.

A seguir estão os diferentes tipos de protocolo suportados por rotas -

• HTTP
• HTTPS
• TSL e web socket

Ao configurar o serviço, os seletores são usados ​​para configurar o serviço e encontrar o ponto de extremidade usando esse serviço. A seguir está um exemplo de como criamos um serviço e o roteamento para esse serviço usando um protocolo apropriado.

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-Rservice"},
   "spec": {
      "selector": {"name":"RService-openshift"},
      "ports": [
         {
            "protocol": "TCP",
            "port": 8888,
            "targetPort": 8080
         }
      ]
   }
}

Em seguida, execute o seguinte comando e o serviço é criado.

$ oc create -f ~/training/content/Openshift-Rservice.json

É assim que o serviço fica após a criação.

$ oc describe service Openshift-Rservice

Name:              Openshift-Rservice
Labels:            <none>
Selector:          name = RService-openshift
Type:              ClusterIP
IP:                172.30.42.80
Port:              <unnamed> 8080/TCP
Endpoints:         <none>
Session Affinity:  None
No events.

Crie um roteamento para serviço usando o código a seguir.

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-service-route"},
   "spec": {
      "host": "hello-openshift.cloudapps.example.com",
      "to": {
         "kind": "Service",
         "name": "OpenShift-route-service"
      },
      "tls": {"termination": "edge"}
   }
}

Quando o comando OC é usado para criar uma rota, uma nova instância do recurso de rota é criada.

Modelos

Os modelos são definidos como um objeto padrão no OpenShift que pode ser usado várias vezes. É parametrizado com uma lista de espaços reservados que são usados ​​para criar vários objetos. Isso pode ser usado para criar qualquer coisa, desde um pod até uma rede, para o qual os usuários têm autorização para criar. Uma lista de objetos pode ser criada, se o modelo da interface CLI ou GUI na imagem for carregado no diretório do projeto.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Autenticação e autorização

Autenticação

No OpenShift, enquanto configura a estrutura mestre e cliente, o mestre surge com um recurso embutido do servidor OAuth. O servidor OAuth é usado para gerar tokens, que são usados ​​para autenticação na API. Como o OAuth vem como uma configuração padrão para mestre, temos o provedor de identidade Permitir tudo usado por padrão. Diferentes provedores de identidade estão presentes, os quais podem ser configurados em/etc/openshift/master/master-config.yaml.

Existem diferentes tipos de provedores de identidade presentes no OAuth.

• Permitir todos
• Negar tudo
• HTPasswd
• LDAP
• Autenticação Básica

Permitir todos

apiVersion: v1
   kind: Pod
   metadata:
      name: redis-master
   spec:
      containers:
         image: dockerfile/redis
         name: master
      ports:
      - containerPort: 6379
         protocol: TCP
      oauthConfig:
      identityProviders:
      - name: my_allow_provider
         challenge: true
         login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Negar tudo

apiVersion: v1
kind: Pod
metadata:
   name: redis-master
spec:
   containers:
      image: dockerfile/redis
   name: master
   ports:
   - containerPort: 6379
      protocol: TCP
   oauthConfig:
   identityProviders:
   - name: my_allow_provider
      challenge: true
      login: true
   provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider

HTPasswd

Para usar o HTPasswd, precisamos primeiro configurar as ferramentas Httpd na máquina mestre e então configurá-lo da mesma forma que fizemos para os outros.

identityProviders:
   - name: my_htpasswd_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider

Autorização

A autorização é um recurso do mestre OpenShift, que é usado para validar para validar um usuário. Isso significa que ele verifica o usuário que está tentando executar uma ação para ver se o usuário está autorizado a executar aquela ação em um determinado projeto. Isso ajuda o administrador a controlar o acesso aos projetos.

As políticas de autorização são controladas usando -

• Rules
• Roles
• Bindings

A avaliação da autorização é feita usando -

• Identity
• Action
• Bindings

Usando políticas -

• Política de cluster
• Política local

O OpenShift consiste em dois tipos de meios para criar e implantar aplicativos, por GUI ou CLI. Neste capítulo, usaríamos a CLI para criar um novo aplicativo. Estaríamos usando o cliente OC para nos comunicarmos com o ambiente OpenShift.

Criação de um novo aplicativo

No OpenShift, existem três métodos de criação de um novo aplicativo.

• De um código-fonte
• De uma imagem
• De um modelo

De um código-fonte

Quando tentamos criar um aplicativo a partir do código-fonte, o OpenShift procura um arquivo Docker que deve estar presente dentro do repo, que define o fluxo de construção do aplicativo. Usaremos oc new-app para criar um aplicativo.

A primeira coisa a ter em mente ao usar um repo é que ele deve apontar para uma origem no repo de onde o OpenShift puxará o código e o construirá.

Se o repo for clonado na máquina Docker em que o cliente OC está instalado e o usuário estiver no mesmo diretório, ele poderá ser criado usando o comando a seguir.

$ oc new-app . <Hear. Denotes current working directory>

A seguir está um exemplo de tentativa de compilar a partir do repo remoto para um branch específico.

$ oc new-app https://github.com/openshift/Testing-deployment.git#test1

Aqui, test1 é o branch de onde estamos tentando criar um novo aplicativo em OpenShift.

Ao especificar um arquivo Docker no repositório, precisamos definir a estratégia de construção conforme mostrado abaixo.

$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git

De uma imagem

Ao construir um aplicativo usando imagens, as imagens estão presentes no servidor Docker local, no repositório Docker hospedado internamente ou no hub Docker. A única coisa que um usuário precisa ter certeza é que ele tem acesso para extrair imagens do hub sem nenhum problema.

O OpenShift tem a capacidade de determinar a fonte usada, se é uma imagem Docker ou um fluxo de origem. No entanto, se o usuário desejar, ele pode definir explicitamente se é um fluxo de imagem ou uma imagem Docker.

$ oc new-app - - docker-image tomcat

Usando um fluxo de imagem -

$ oc new-app tomcat:v1

De um modelo

Os modelos podem ser usados ​​para a criação de um novo aplicativo. Pode ser um modelo já existente ou criar um novo modelo.

O arquivo yaml a seguir é basicamente um modelo que pode ser usado para implantação.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Desenvolver e implantar um aplicativo da Web

Desenvolvendo um novo aplicativo em OpenShift

Para criar um novo aplicativo em OpenShift, temos que escrever um novo código de aplicativo e construí-lo usando comandos de construção OpenShift OC. Conforme discutido, temos várias maneiras de criar uma nova imagem. Aqui, estaremos usando um modelo para construir o aplicativo. Este modelo irá construir um novo aplicativo quando executado com o comando oc new-app.

O modelo a seguir será criado - Dois aplicativos front-end e um banco de dados. Junto com isso, ele criará dois novos serviços e esses aplicativos serão implantados no cluster OpenShift. Ao construir e implantar um aplicativo, inicialmente precisamos criar um namespace no OpenShift e implantar o aplicativo nesse namespace.

Create a new namespace

$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"

Modelo

{
   "kind": "Template",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-helloworld-sample",
      "creationTimestamp": null,
         "annotations": {
         "description": "This example shows how to create a simple openshift
         application in openshift origin v3",
         "iconClass": "icon-openshift",
         "tags": "instant-app,openshift,mysql"
      }
   }
},

Definições de objeto

Secret definition in a template

"objects": [
{
   "kind": "Secret",
   "apiVersion": "v1",
   "metadata": {"name": "dbsecret"},
   "stringData" : {
      "mysql-user" : "${MYSQL_USER}",
      "mysql-password" : "${MYSQL_PASSWORD}"
   }
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   },
   "spec": {
      "ports": [
         {
            "name": "web",
            "protocol": "TCP",
            "port": 5432,
            "targetPort": 8080,
            "nodePort": 0
         }
      ],
      "selector": {"name": "frontend"},
      "type": "ClusterIP",
      "sessionAffinity": "None"
   },
   "status": {
      "loadBalancer": {}
   }
},

Route definition in a template

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {
      "name": "route-edge",
      "creationTimestamp": null,
      "annotations": {
         "template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
      }
   },
   "spec": {
      "host": "www.example.com",
      "to": {
         "kind": "Service",
         "name": "frontend"
      },
      "tls": {
         "termination": "edge"
      }
   },
   "status": {}
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "origin-openshift-sample",
      "creationTimestamp": null
   },
   "spec": {},
   "status": {
      "dockerImageRepository": ""
   }
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-22-ubuntu7",
      "creationTimestamp": null 
   },
   "spec": {
      "dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
   },
   "status": {
      "dockerImageRepository": ""
   }
},

Build config definition in a template

{
   "kind": "BuildConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-sample-build",
      "creationTimestamp": null,
      "labels": {name": "openshift-sample-build"}
   },
   "spec": {
      "triggers": [
         { "type": "GitHub",
            "github": {
            "secret": "secret101" } 
         },
         {
            "type": "Generic",
            "generic": {
               "secret": "secret101",
               "allowEnv": true } 
         },
         { 
            "type": "ImageChange",
            "imageChange": {} 
         },
         { "type": "ConfigChange”}
      ],
      "source": {
         "type": "Git",
         "git": {
            "uri": https://github.com/openshift/openshift-hello-world.git } 
      },
      "strategy": {
         "type": "Docker",
         "dockerStrategy": {
            "from": {
               "kind": "ImageStreamTag",
               "name": "openshift-22-ubuntu7:latest” 
            },
            "env": [
               {
                  "name": "EXAMPLE",
                  "value": "sample-app"
               } 
            ]
         }
      },
      "output": {
         "to": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      },
      "postCommit": {
         "args": ["bundle", "exec", "rake", "test"]
      },
      "status": {
         "lastVersion": 0
      }
   }
},

Deployment config in a template

"status": {
   "lastVersion": 0
}
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   }
}, 
"spec": {
   "strategy": {
      "type": "Rolling",
      "rollingParams": {
         "updatePeriodSeconds": 1,
         "intervalSeconds": 1,
         "timeoutSeconds": 120,
         "pre": {
            "failurePolicy": "Abort",
            "execNewPod": {
               "command": [
                  "/bin/true"
               ],
               "env": [
                  { 
                     "name": "CUSTOM_VAR1",
                     "value": "custom_value1"
                  }
               ]
            }
         }
      }
   }
}
"triggers": [
   {
      "type": "ImageChange",
      "imageChangeParams": {
         "automatic": true,
         "containerNames": [
            "openshift-helloworld"
         ],
         "from": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      }
   },
   {
      "type": "ConfigChange"
   }
],
"replicas": 2,
"selector": {
   "name": "frontend"
},
"template": {
   "metadata": {
      "creationTimestamp": null,
      "labels": {
         "name": "frontend"
      }
   },
   "spec": {
      "containers": [
         {
            "name": "openshift-helloworld",
            "image": "origin-openshift-sample",
            "ports": [
               { 
                  "containerPort": 8080,
                  "protocol": "TCP” 
               }
            ],
            "env": [
               {
                  "name": "MYSQL_USER",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-user"
                     }
                  }
               },
               {
                  "name": "MYSQL_PASSWORD",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-password"
                     }
                  }
               },
               {
                  "name": "MYSQL_DATABASE",
                  "value": "${MYSQL_DATABASE}"
               }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "imagePullPolicy": "IfNotPresent",
            "securityContext": {
               "capabilities": {},
               "privileged": false
            }
         }
      ],
      "restartPolicy": "Always",
      "dnsPolicy": "ClusterFirst"
   },
   "status": {}
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null 
   },
   "spec": {
   "ports": [
      {
         "name": "db",
         "protocol": "TCP",
         "port": 5434,
         "targetPort": 3306,
         "nodePort": 0
      } 
   ],
   "selector": {
      "name": "database 
   },
   "type": "ClusterIP",
   "sessionAffinity": "None" },
   "status": {
      "loadBalancer": {}
   }
},

Deployment config definition in a template

{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null
   },
   "spec": {
      "strategy": {
         "type": "Recreate",
         "resources": {}
      },
      "triggers": [
         {
            "type": "ConfigChange"
         }
      ],
      "replicas": 1,
      "selector": {"name": "database"},
      "template": {
         "metadata": {
            "creationTimestamp": null,
            "labels": {"name": "database"}
         },
         "template": {
            "metadata": {
               "creationTimestamp": null,
               "labels": {
                  "name": "database"
               } 
            },
            "spec": {
               "containers": [
                  {
                     "name": "openshift-helloworld-database",
                     "image": "ubuntu/mysql-57-ubuntu7:latest",
                     "ports": [
                        {
                           "containerPort": 3306,
                           "protocol": "TCP" 
                        }
                     ],
                     "env": [
                        {
                           "name": "MYSQL_USER",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-user"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_PASSWORD",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-password"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_DATABASE",
                           "value": "${MYSQL_DATABASE}" 
                        } 
                     ],
                     "resources": {},
                     "volumeMounts": [
                        {
                           "name": "openshift-helloworld-data",
                           "mountPath": "/var/lib/mysql/data"
                        }
                     ],
                     "terminationMessagePath": "/dev/termination-log",
                     "imagePullPolicy": "Always",
                     "securityContext": {
                        "capabilities": {},
                        "privileged": false
                     } 
                  }
               ],
               "volumes": [
                  { 
                     "name": "openshift-helloworld-data",
                     "emptyDir": {"medium": ""} 
                  } 
               ],
               "restartPolicy": "Always",
               "dnsPolicy": "ClusterFirst” 
            } 
         }
      },
      "status": {} 
   },
   "parameters": [
      { 
         "name": "MYSQL_USER",
         "description": "database username",
         "generate": "expression",
         "from": "user[A-Z0-9]{3}",
         "required": true 
      },
      {
         "name": "MYSQL_PASSWORD",
         "description": "database password",
         "generate": "expression",
         "from": "[a-zA-Z0-9]{8}",
         "required": true
      }, 
      {
         "name": "MYSQL_DATABASE",
         "description": "database name",
         "value": "root",
         "required": true 
      } 
   ],
   "labels": {
      "template": "application-template-dockerbuild" 
   } 
}

O arquivo de modelo acima precisa ser compilado imediatamente. Precisamos primeiro copiar todo o conteúdo em um único arquivo e nomeá-lo como um arquivo yaml quando terminar.

Precisamos executar o seguinte comando para criar o aplicativo.

$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"

   openshift-helloworld-sample
   ---------
   This example shows how to create a simple ruby application in openshift origin v3
   * With parameters:
      * MYSQL_USER = userPJJ # generated
      * MYSQL_PASSWORD = cJHNK3se # generated
      * MYSQL_DATABASE = root

--> Creating resources with label app = ruby-helloworld-sample ...
   service "frontend" created
   route "route-edge" created
   imagestream "origin-ruby-sample" created
   imagestream "ruby-22-centos7" created
   buildconfig "ruby-sample-build" created
   deploymentconfig "frontend" created
   service "database" created
   deploymentconfig "database" created
   
--> Success
   Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
   Run 'oc status' to view your app.

Se quisermos monitorar a construção, isso pode ser feito usando -

$ oc get builds

NAME                        TYPE      FROM          STATUS     STARTED         DURATION
openshift-sample-build-1    Source   Git@bd94cbb    Running    7 seconds ago   7s

Podemos verificar os aplicativos implantados no OpenShift usando -

$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
database-1-le4wx                1/1     Running     0          1m
frontend-1-e572n                1/1     Running     0          27s
frontend-1-votq4                1/1     Running     0          31s
opeshift-sample-build-1-build   0/1     Completed   0          1m

Podemos verificar se os serviços de aplicativo são criados de acordo com a definição de serviço usando

$ oc get services
NAME        CLUSTER-IP      EXTERNAL-IP     PORT(S)      SELECTOR          AGE
database    172.30.80.39    <none>         5434/TCP     name=database      1m
frontend    172.30.17.4     <none>         5432/TCP     name=frontend      1m

No OpenShift, temos vários métodos para automatizar o pipeline de construção. Para fazer isso, precisamos criar um recurso BuildConfig para descrever o fluxo de construção. O fluxo em BuildConfig pode ser comparado com a definição de trabalho na definição de trabalho Jenkins. Ao criar o fluxo de construção, temos que escolher a estratégia de construção.

Arquivo BuildConfig

No OpenShift, BuildConfig é um objeto rest usado para se conectar à API e, em seguida, criar uma nova instância.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

No OpenShift, existem quatro tipos de estratégias de construção.

• Estratégia da fonte para a imagem
• Estratégia Docker
• Estratégia personalizada
• Estratégia de pipeline

Estratégia da fonte para a imagem

Permite a criação de imagens de container a partir do código fonte. Nesse fluxo, o código real é baixado primeiro no contêiner e, em seguida, compilado dentro dele. O código compilado é implantado dentro do mesmo contêiner e a imagem é construída a partir desse código.

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

Existem várias políticas de estratégia.

• Forcepull
• Construções incrementais
• Construções externas

Estratégia Docker

Neste fluxo, o OpenShift usa Dockerfile para construir a imagem e, em seguida, fazer upload das imagens criadas para o registro do Docker.

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

A opção de arquivo Docker pode ser usada em vários locais a partir do caminho do arquivo, sem cache e pull forçado.

• Da imagem
• Caminho do Dockerfile
• Sem cache
• Força de tração

Estratégia Personalizada

Este é um dos diferentes tipos de estratégia de construção, em que não há compulsão de que a saída da construção seja uma imagem. Pode ser comparado a um trabalho de estilo livre de Jenkins. Com isso, podemos criar Jar, rpm e outros pacotes.

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

Consiste em várias estratégias de construção.

• Expor o soquete Docker
• Secrets
• Força de tração

Estratégia de Pipeline

A estratégia de pipeline é usada para criar pipelines de construção personalizados. Isso é basicamente usado para implementar o fluxo de trabalho no pipeline. Este fluxo de construção usa o fluxo de pipeline de construção customizado usando a linguagem Groovy DSL. O OpenShift criará um trabalho de pipeline no Jenkins e o executará. Este fluxo de pipeline também pode ser usado no Jenkins. Nesta estratégia, usamos Jenkinsfile e o acrescentamos na definição buildconfig.

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

Using build pipeline

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>

OpenShift CLI é usado para gerenciar aplicativos OpenShift a partir da linha de comando. OpenShift CLI tem a capacidade de gerenciar o ciclo de vida do aplicativo de ponta a ponta. Em geral, usaríamos o OC, que é um cliente OpenShift para nos comunicarmos com o OpenShift.

Configuração da CLI OpenShift

Para configurar o cliente OC em um sistema operacional diferente, precisamos seguir uma sequência diferente de etapas.

Cliente OC para Windows

Step 1 - Baixe o oc cli no link a seguir https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Step 2 - Descompacte o pacote em um caminho de destino na máquina.

Step 3 - Edite a variável de ambiente do caminho do sistema.

C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%

C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files 
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files 
(x86)\ATI Technologies\ATI.ACE\C

ore-Static;C:\Program Files\Intel\Intel(R) Management Engine 
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine 
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;

Step 4 - Valide a configuração do OC no Windows.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

Cliente OC para Mac OS X

Podemos baixar os binários de configuração do Mac OS para o mesmo local do Windows e depois descompactá-los em um local e definir um caminho do executável na variável de ambiente PATH.

Alternatively

Podemos usar Home brew e configurá-lo usando o seguinte comando.

$ brew install openshift-cli

Cliente OC para Linux

Na mesma página, temos o arquivo tar para instalação do Linux que pode ser usado para instalação. Posteriormente, uma variável de caminho pode ser definida apontando para aquele local específico do executável.

https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Descompacte o arquivo tar usando o seguinte comando.

$ tar –xf < path to the OC setup tar file >

Execute o seguinte comando para verificar a autenticação.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server [https://localhost:8443]:

Arquivos de configuração CLI

O arquivo de configuração OC CLI é usado para gerenciar várias conexões de servidor OpenShift e mecanismo de autenticação. Este arquivo de configuração também é usado para armazenar e gerenciar vários perfis e para alternar entre eles. Um arquivo de configuração normal se parece com o seguinte.

$ oc config view
apiVersion: v1
clusters:
   - cluster:
      server: https://vklnld908.int.example.com
   name: openshift
   
contexts:
- context:
   cluster: openshift
   namespace: testproject
   user: alice
   name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
   user:
      token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Configurando o cliente CLI

Para definir a credencial do usuário

$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]

Para definir o cluster

$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]

Exemplo

$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Para definir o contexto

$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]

Perfis CLI

Em um único arquivo de configuração CLI, podemos ter vários perfis em que cada perfil tem uma configuração de servidor OpenShift diferente, que mais tarde pode ser usada para alternar entre diferentes perfis CLI.

apiVersion: v1
clusters: --→ 1
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld908.int.example.com:8443
   name: vklnld908.int.example.com:8443
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld1446.int.example.com:8443
   name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: openshift-project
   user: vipin/vklnld908.int.example.com:8443
   name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: testing-project
   user: alim/vklnld908.int.example.com:8443
   name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}

users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
   token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Na configuração acima, podemos ver que ela está dividida em quatro seções principais a partir do cluster que define duas instâncias de máquinas mestras OpenShift. A segunda seção de contexto define dois contextos chamados vipin e alim. O contexto atual define qual contexto está em uso. Ele pode ser alterado para outro contexto ou perfil, se alterarmos a definição aqui. Finalmente, a definição do usuário e seu token de autenticação são definidos, que em nosso caso é vipin.

Se quisermos verificar o perfil atual em uso, isso pode ser feito usando -

$ oc status oc status In project testing Project (testing-project) $ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".

Se quisermos mudar para outra CLI, isso pode ser feito a partir da linha de comando usando o seguinte comando.

$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".

Usando o comando acima, podemos alternar entre os perfis. A qualquer momento, se quisermos ver a configuração, podemos usar o comando $ oc config view.

OpenShift CLI é capaz de realizar todas as configurações básicas e avançadas, gerenciamento, adição e implantação de aplicativos.

Podemos realizar diferentes tipos de operações usando comandos OC. Este cliente ajuda você a desenvolver, construir, implantar e executar seus aplicativos em qualquer plataforma compatível com OpenShift ou Kubernetes. Ele também inclui os comandos administrativos para gerenciar um cluster sob o subcomando 'adm'.

Comandos Básicos

A tabela a seguir lista os comandos OC básicos.

Sr. Não.	Comandos e descrição
1	Types Uma introdução aos conceitos e tipo
2	Login Faça login em um servidor
3	new-project Solicite um novo projeto
4	new-app Criar uma nova aplicação
5	Status Mostra uma visão geral do projeto atual
6	Project Mudar para outro projeto
7	Projects Exibir projetos existentes
8	Explain Documentação de recursos
9	Cluster Iniciar e parar o cluster OpenShift

Conecte-se

Faça login em seu servidor e salve o login para uso posterior. Os usuários novos do cliente devem executar este comando para se conectar a um servidor, estabelecer uma sessão autenticada e salvar uma conexão com o arquivo de configuração. A configuração padrão será salva em seu diretório inicial em ".kube / config".

As informações necessárias para o login - como nome de usuário e senha, um token de sessão ou os detalhes do servidor podem ser fornecidos por meio de sinalizadores. Se não for fornecido, o comando solicitará a entrada do usuário conforme necessário.

Usage

oc login [URL] [options]

Example

# Log in interactively
oc login

# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority = /path/to/cert.crt

# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypass

Opções -

-p, --password = " - Senha, será exibida se não for fornecida

-u, --username = " - Nome de usuário, aparecerá se não for fornecido

--certificate-authority = "- Caminho para um certificado. arquivo para a autoridade de certificação

--insecure-skip-tls-verify = false- Se verdadeiro, o certificado do servidor não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras

--token = " - Token do portador para autenticação no servidor API

Para obter os detalhes completos sobre qualquer comando, use o oc <Command Name> --help comando.

Construir e implantar comandos

A tabela a seguir lista os comandos de construção e implantação.

Sr. Não.	Comandos e descrição
1	Rollout Gerenciar uma implantação do Kubernetes ou implantação do OpenShift
2	Deploy Visualize, inicie, cancele ou tente novamente uma implantação
3	Rollback Reverter parte de um aplicativo de volta ao estado anterior
4	new-build Crie uma nova configuração de construção
5	start-build Comece uma nova construção
6	cancel-build Cancelar execução, pendente ou novas compilações
7	import-image Importa imagens de um registro Docker
8	Tag Marque as imagens existentes em fluxos de imagens

Comandos de gerenciamento de aplicativos

A tabela a seguir lista os comandos de gerenciamento de aplicativos.

Sr. Não.	Comandos e descrição
1	Get Exibir um ou mais recursos
2	Describe Mostra os detalhes de um recurso específico ou grupo de recursos
3	Edit Editar um recurso no servidor
4	Set Comandos que ajudam a definir recursos específicos em objetos
5	Label Atualize os rótulos em um recurso
6	Annotate Atualize as anotações em um recurso
7	Expose Expor um aplicativo replicado como um serviço ou rota
8	Delete Exclua um ou mais recursos
9	Scale Alterar o número de pods em uma implantação
10	Autoscale Escale automaticamente uma configuração de implantação, implantação, replicação, controlador ou conjunto de réplicas
11	Secrets Gerenciar segredos
12	Serviceaccounts Gerenciar contas de serviço em seu projeto

Resolução de problemas e comandos de depuração

A tabela a seguir lista os comandos de solução de problemas e depuração.

Sr. Não.	Comandos e descrição
1	logs Imprimir os registros de um recurso
2	Rsh Iniciar uma sessão shell em um pod
3	Rsync Copie arquivos entre o sistema de arquivos local e um pod
4	port-forward Encaminhe uma ou mais portas locais para um pod
5	Debug Inicie uma nova instância de um pod para depuração
6	Exec Execute um comando em um contêiner
7	Procy Execute um proxy para o servidor da API Kubernetes
9	Attach Anexar a um contêiner em execução
10	Run Execute uma imagem específica no cluster
11	Cp Copie arquivos e diretórios de e para contêineres

Comandos Avançados

A tabela a seguir lista os comandos avançados.

Sr. Não.	Comandos e descrição
1	adm Ferramentas para gerenciar um cluster
2	create Crie um recurso por nome de arquivo ou stdin
3	replace Substitua um recurso por nome de arquivo ou stdin
4	apply Aplicar uma configuração a um recurso por nome de arquivo ou stdin
5	patch Atualizar campo (s) de um recurso usando patch de fusão estratégica
6	process Processe um modelo na lista de recursos
7	export Exportar recursos para que possam ser usados ​​em outro lugar
8	extract Extraia segredos ou mapas de configuração para o disco
9	idle Recursos escaláveis ​​ociosos
10	observe Observe as mudanças nos recursos e reaja a elas (experimental)
11	policy Gerenciar política de autorização
12	auth Inspecionar autorização
13	convert Converta arquivos de configuração entre diferentes versões de API
14	import Comandos que importam aplicativos

Configurando Comandos

A tabela a seguir lista os comandos de configuração.

Sr. Não.	Comandos e descrição
1	Logout Terminar a sessão atual do servidor
2	Config Altere os arquivos de configuração do cliente
3	Whoami Retornar informações sobre a sessão atual
4	Completion Código de conclusão de shell de saída para o shell especificado (bash ou zsh)

OpenShift usa dois métodos de instalação para configurar o cluster OpenShift.

• Método de instalação rápida
• Método de configuração avançada

Configurando Cluster

Método de instalação rápida

Este método é usado para executar uma configuração rápida de configuração de cluster inatingível. Para usar este método, precisamos primeiro instalar o instalador. Isso pode ser feito executando o seguinte comando.

Interactive method

$ atomic-openshift-installer install

Isso é útil quando se deseja executar uma configuração interativa.

Unattended installation method

Este método é usado quando se deseja configurar uma forma autônoma de método de instalação, em que o usuário pode definir um arquivo yaml de configuração e colocá-lo sob ~/.config/openshift/com o nome de installer.cfg.yml. Então, o seguinte comando pode ser executado para instalar o–u tag.

$ atomic-openshift-installer –u install

Por padrão, ele usa o arquivo de configuração localizado em ~/.config/openshift/. Por outro lado, o Ansible é usado como backup da instalação.

version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log

deployment:
   ansible_ssh_user: root
   hosts:
   - ip: 172.10.10.1
   hostname: vklnld908.int.example.com
   public_ip: 24.222.0.1
   public_hostname: master.example.com
   roles:
      - master
      - node
   containerized: true
   connect_to: 24.222.0.1
   
   - ip: 172.10.10.2
   hostname: vklnld1446.int.example.com
   public_ip: 24.222.0.2
   public_hostname: node1.example.com
   roles:
      - node
   connect_to: 10.0.0.2
   
   - ip: 172.10.10.3
   hostname: vklnld1447.int.example.com
   public_ip: 10..22.2.3
   public_hostname: node2.example.com
   roles:
      - node
   connect_to: 10.0.0.3

roles:
   master:
      <variable_name1>: "<value1>"
      <variable_name2>: "<value2>"
   node:
      <variable_name1>: "<value1>"

Aqui, temos a variável específica da função, que pode ser definida se alguém deseja configurar alguma variável específica.

Uma vez feito isso, podemos verificar a instalação usando o seguinte comando.

$ oc get nodes
NAME                    STATUS    AGE
master.example.com      Ready     10d
node1.example.com       Ready     10d
node2.example.com       Ready     10d

Instalação avançada

A instalação avançada é totalmente baseada na configuração do Ansible, em que a configuração completa do host e a definição das variáveis ​​em relação à configuração do mestre e do nó estão presentes. Contém todos os detalhes relativos à configuração.

Assim que tivermos a configuração e o manual estiver pronto, podemos simplesmente executar o seguinte comando para configurar o cluster.

$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml

Adicionando Hosts a um Cluster

Podemos adicionar um host ao cluster usando -

• Ferramenta de instalação rápida
• Método de configuração avançada

Quick installation toolfunciona em modo interativo e não interativo. Use o seguinte comando.

$ atomic-openshift-installer -u -c </path/to/file> scaleup

O formato de escala da aparência do arquivo de configuração do aplicativo pode ser usado para adicionar o mestre e o nó.

Método de Configuração Avançada

Neste método, atualizamos o arquivo host de Ansible e, em seguida, adicionamos um novo nó ou detalhes do servidor neste arquivo. O arquivo de configuração se parece com o seguinte.

[OSEv3:children]
masters
nodes
new_nodes
new_master

No mesmo arquivo de hosts Ansible, adicione detalhes de variáveis ​​em relação ao novo nó, conforme mostrado abaixo.

[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"

Finalmente, usando o arquivo host atualizado, execute a nova configuração e chame o arquivo de configuração para fazer a configuração usando o seguinte comando.

$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml

Gerenciando logs de cluster

O log do cluster OpenShift nada mais é do que os logs que são gerados a partir das máquinas mestre e do nó do cluster. Eles podem gerenciar qualquer tipo de registro, começando pelo registro do servidor, registro mestre, registro do contêiner, registro do pod, etc. Existem várias tecnologias e aplicativos para o gerenciamento do registro do contêiner.

Algumas das ferramentas estão listadas, o que pode ser implementado para gerenciamento de log.

• Fluentd
• ELK
• Kabna
• Nagios
• Splunk

ELK stack- Esta pilha é útil ao tentar coletar os logs de todos os nós e apresentá-los em um formato sistemático. A pilha ELK é dividida principalmente em três categorias principais.

ElasticSearch - Principalmente responsável por coletar informações de todos os containers e colocá-las em um local central.

Fluentd - Usado para alimentar os logs coletados para o mecanismo de contêiner do elasticsearch.

Kibana - Uma interface gráfica usada para apresentar os dados coletados como uma informação útil em uma interface gráfica.

Um ponto importante a ser observado é que, quando este sistema é implantado no cluster, ele começa a coletar logs de todos os nós.

Log de diagnóstico

OpenShift tem um embutido oc adm dignosticscomando com OC que pode ser usado para analisar várias situações de erro. Esta ferramenta pode ser usada a partir do mestre como administrador do cluster. Este utilitário é muito útil para solucionar e considerar problemas conhecidos. Isso é executado no cliente mestre e nos nós.

Se executado sem quaisquer agrumentos ou sinalizadores, ele irá procurar por arquivos de configuração do cliente, servidor e máquinas de nó, e os usará para diagnósticos. Pode-se executar o diagnóstico individualmente passando os seguintes argumentos -

• AggregatedLogging
• AnalyzeLogs
• ClusterRegistry
• ClusterRoleBindings
• ClusterRoles
• ClusterRouter
• ConfigContexts
• DiagnosticPod
• MasterConfigCheck
• MasterNode
• MetricsApiProxy
• NetworkCheck
• NodeConfigCheck
• NodeDefinitions
• ServiceExternalIPs
• UnitStatus

Pode-se simplesmente executá-los com o seguinte comando.

$ oc adm diagnostics <DiagnosticName>

Atualizando um Cluster

A atualização do cluster envolve a atualização de várias coisas dentro do cluster e a atualização do cluster com novos componentes e upgrdes. Isso envolve -

• Atualização de componentes principais
• Atualização de componentes do nó
• Atualização de políticas
• Atualização de rotas
• Atualização do fluxo de imagem

Para realizar todas essas atualizações, primeiro precisamos ter instaladores ou utilitários rápidos no lugar. Para isso, precisamos atualizar os seguintes utilitários -

• atomic-openshift-utils
• atomic-openshift-excluder
• atomic-openshift-docker-excluder
• pacote etcd

Antes de iniciar a atualização, precisamos fazer backup do etcd na máquina mestre, o que pode ser feito usando os seguintes comandos.

$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd
$ etcdctl backup \ --data-dir $ETCD_DATA_DIR \
   --backup-dir $ETCD_DATA_DIR.bak.<date>

Atualização de componentes principais

No mestre OpenShift, começamos a atualização atualizando o arquivo etcd e, em seguida, passando para o Docker. Por fim, executamos o executor automatizado para colocar o cluster na posição necessária. No entanto, antes de iniciar a atualização, precisamos primeiro ativar os pacotes atomic openshift em cada um dos mestres. Isso pode ser feito usando os seguintes comandos.

Step 1 - Remova os pacotes atomic-openshift

$ atomic-openshift-excluder unexclude

Step 2 - Atualize o etcd em todos os mestres.

$ yum update etcd

Step 3 - Reinicie o serviço etcd e verifique se ele foi iniciado com sucesso.

$ systemctl restart etcd
$ journalctl -r -u etcd

Step 4 - Atualize o pacote Docker.

$ yum update docker

Step 5 - Reinicie o serviço Docker e verifique se ele está funcionando corretamente.

$ systemctl restart docker $ journalctl -r -u docker

Step 6 - Uma vez feito isso, reinicie o sistema com os seguintes comandos.

$ systemctl reboot $ journalctl -r -u docker

Step 7 - Finalmente, execute o atomic-executer para colocar os pacotes de volta na lista de exclusões do yum.

$ atomic-openshift-excluder exclude

Não existe tal compulsão para atualizar a política, ela só precisa ser atualizada se recomendado, o que pode ser verificado com o seguinte comando.

$ oadm policy reconcile-cluster-roles

Na maioria dos casos, não precisamos atualizar a definição da política.

Atualização de componentes do nó

Assim que a atualização mestre for concluída, podemos começar a atualizar os nós. Uma coisa a ter em mente é que o período de atualização deve ser curto para evitar qualquer tipo de problema no cluster.

Step 1 - Remova todos os pacotes OpenShift atômicos de todos os nós onde você deseja realizar a atualização.

$ atomic-openshift-excluder unexclude

Step 2 - Em seguida, desative o agendamento do nó antes da atualização.

$ oadm manage-node <node name> --schedulable = false

Step 3 - Replica todo o nó do host atual para o outro host.

$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets

Step 4 - Atualize a configuração do Docker no host.

$ yum update docker

Step 5 - Reinicie o serviço Docker e, em seguida, inicie o nó de serviço Docker.

$systemctl restart docker $ systemctl restart atomic-openshift-node

Step 6 - Verifique se ambos começaram corretamente.

$ journalctl -r -u atomic-openshift-node

Step 7 - Após a conclusão da atualização, reinicie a máquina do nó.

$ systemctl reboot
$ journalctl -r -u docker

Step 8 - Reative o agendamento em nós.

$ oadm manage-node <node> --schedulable.

Step 9 - Execute o executor atomic-openshift para colocar o pacote OpenShift de volta no nó.

$ atomic-openshift-excluder exclude

Step 10 - Por fim, verifique se todos os nós estão disponíveis.

$ oc get nodes

NAME                 STATUS   AGE
master.example.com   Ready    12d
node1.example.com    Ready    12d
node2.example.com    Ready    12d

O escalonamento automático é um recurso do OpenShift em que os aplicativos implantados podem ser dimensionados e afundados conforme e quando necessário de acordo com certas especificações. No aplicativo OpenShift, o escalonamento automático também é conhecido como escalonamento automático de pod. São doistypes of application scaling do seguinte modo.

Dimensionamento Vertical

O dimensionamento vertical significa adicionar mais e mais potência a uma única máquina, o que significa adicionar mais CPU e disco rígido. O é um método antigo de OpenShift que agora não é suportado por versões do OpenShift.

Dimensionamento Horizontal

Este tipo de escalonamento é útil quando há necessidade de lidar com mais solicitações, aumentando o número de máquinas.

No OpenShift, existem two methods to enable the scaling feature.

• Usando o arquivo de configuração de implantação
• Durante a execução da imagem

Usando o arquivo de configuração de implantação

Neste método, o recurso de dimensionamento é ativado por meio de um arquivo yaml de configuração de deploymant. Para isso, o comando OC autoscale é usado com o número mínimo e máximo de réplicas, que precisam ser executadas em qualquer ponto do tempo no cluster. Precisamos de uma definição de objeto para a criação do autoescalador. A seguir está um exemplo de arquivo de definição do autoescalador de pod.

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

Assim que tivermos o arquivo no lugar, precisamos salvá-lo com o formato yaml e executar o seguinte comando para implantação.

$ oc create –f <file name>.yaml

Durante a execução da imagem

Também é possível escalonar automaticamente sem o arquivo yaml, usando o seguinte oc autoscale comando na linha de comando oc.

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

Este comando também irá gerar um tipo de arquivo semelhante que pode ser usado posteriormente para referência.

Estratégias de implantação em OpenShift

A estratégia de implantação no OpenShift define um fluxo de implantação com diferentes métodos disponíveis. No OpenShift, a seguir estão osimportant types of deployment strategies.

• Estratégia de rolamento
• Estratégia de recriação
• Estratégia personalizada

A seguir está um exemplo de arquivo de configuração de implantação, que é usado principalmente para implantação em nós OpenShift.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

No arquivo Deploymentconfig acima, temos a estratégia como Rolling.

Podemos usar o seguinte comando OC para implantação.

$ oc deploy <deployment_config> --latest

Estratégia de Rolling

A estratégia contínua é usada para atualizações contínuas ou implantação. Esse processo também oferece suporte a ganchos de ciclo de vida, que são usados ​​para injetar código em qualquer processo de implantação.

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

Estratégia de Recriação

Esta estratégia de implantação possui alguns dos recursos básicos da estratégia de implantação contínua e também oferece suporte ao gancho do ciclo de vida.

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

Estratégia Personalizada

Isso é muito útil quando se deseja fornecer seu próprio processo ou fluxo de implantação. Todas as personalizações podem ser feitas de acordo com o requisito.

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1

Neste capítulo, iremos cobrir tópicos como como gerenciar um nó, configurar uma conta de serviço, etc.

Configuração Mestre e Nó

No OpenShift, precisamos usar o comando start junto com OC para inicializar um novo servidor. Ao lançar um novo mestre, precisamos usar o mestre junto com o comando de início, enquanto ao iniciar o novo nó, precisamos usar o nó junto com o comando de início. Para fazer isso, precisamos criar arquivos de configuração para o mestre e também para os nós. Podemos criar um arquivo de configuração básica para o mestre e o nó usando o seguinte comando.

Para arquivo de configuração mestre

$ openshift start master --write-config = /openshift.local.config/master

Para arquivo de configuração de nó

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

Depois de executar os comandos a seguir, obteremos os arquivos de configuração básicos que podem ser usados ​​como ponto de partida para a configuração. Posteriormente, podemos ter o mesmo arquivo para inicializar os novos servidores.

apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
   logoutURL: ""
   masterPublicURL: https://172.10.12.1:7449
   publicURL: https://172.10.2.2:7449/console/
      servingInfo:
         bindAddress: 0.0.0.0:7449
         certFile: master.server.crt
         clientCA: ""
keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
   bindAddress: 0.0.0.0:53
etcdClientInfo:
   ca: ca.crt
   certFile: master.etcd-client.crt
   keyFile: master.etcd-client.key
   urls:
   - https://10.0.2.15:4001
etcdConfig:
   address: 10.0.2.15:4001
   peerAddress: 10.0.2.15:7001
   peerServingInfo:
      bindAddress: 0.0.0.0:7001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   servingInfo:
      bindAddress: 0.0.0.0:4001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
   kubernetesStoragePrefix: kubernetes.io
   kubernetesStorageVersion: v1
   openShiftStoragePrefix: openshift.io
   openShiftStorageVersion: v1
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: MasterConfig
kubeletClientInfo:
   ca: ca.crt
   certFile: master.kubelet-client.crt
   keyFile: master.kubelet-client.key
   port: 10250
kubernetesMasterConfig:
   apiLevels:
   - v1beta3
   - v1
   apiServerArguments: null
   controllerArguments: null
   masterCount: 1
   masterIP: 10.0.2.15
   podEvictionTimeout: 5m
   schedulerConfigFile: ""
   servicesNodePortRange: 30000-32767
   servicesSubnet: 172.30.0.0/16
   staticNodeNames: []
masterClients:
   externalKubernetesKubeConfig: ""
   openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
   clusterNetworkCIDR: 10.1.0.0/16
   hostSubnetLength: 8
   networkPluginName: ""
   serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
   assetPublicURL: https://172.10.2.2:7449/console/
   grantConfig:
      method: auto
   identityProviders:
   - challenge: true
   login: true
   name: anypassword
   provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
   masterPublicURL: https://172.10.2.2:7449/
   masterURL: https://172.10.2.2:7449/
   sessionConfig:
      sessionMaxAgeSeconds: 300
      sessionName: ssn
      sessionSecretsFile: ""
   tokenConfig:
      accessTokenMaxAgeSeconds: 86400
      authorizeTokenMaxAgeSeconds: 300
policyConfig:
   bootstrapPolicyFile: policy.json
   openshiftInfrastructureNamespace: openshift-infra
   openshiftSharedResourcesNamespace: openshift
projectConfig:
   defaultNodeSelector: ""
   projectRequestMessage: ""
   projectRequestTemplate: ""
   securityAllocator:
      mcsAllocatorRange: s0:/2
      mcsLabelsPerProject: 5
      uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
   subdomain: router.default.svc.cluster.local
serviceAccountConfig:
   managedNames:
   - default
   - builder
   - deployer
   
masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
servingInfo:
   bindAddress: 0.0.0.0:8443
   certFile: master.server.crt
   clientCA: ca.crt
   keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 3600

Arquivos de configuração de nó

allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
   execHandlerName: native
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
   mtu: 1450
   networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com

podManifestConfig:
   path: "/path/to/pod-manifest-file"
   fileCheckIntervalSeconds: 30
servingInfo:
   bindAddress: 0.0.0.0:10250
   certFile: server.crt
   clientCA: node-client-ca.crt
   keyFile: server.key
volumeDirectory: /root/openshift.local.volumes

Esta é a aparência dos arquivos de configuração do nó. Assim que tivermos esses arquivos de configuração no lugar, podemos executar o seguinte comando para criar o servidor mestre e de nó.

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

Gerenciando Nós

No OpenShift, temos o utilitário de linha de comando OC, que é usado principalmente para realizar todas as operações no OpenShift. Podemos usar os seguintes comandos para gerenciar os nós.

Para listar um nó

$ oc get nodes
NAME                             LABELS
node1.example.com     kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com     kubernetes.io/hostname = vklnld1447.int.example.com

Descrever detalhes sobre um nó

$ oc describe node <node name>

Excluindo um nó

$ oc delete node <node name>

Listagem de pods em um nó

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

Avaliação de pods em um nó

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Autenticação de configuração

No mestre OpenShift, há um servidor OAuth integrado, que pode ser usado para gerenciar a autenticação. Todos os usuários do OpenShift obtêm o token desse servidor, o que os ajuda a se comunicar com a API do OpenShift.

Existem diferentes tipos de nível de autenticação no OpenShift, que podem ser configurados junto com o arquivo de configuração principal.

• Permitir todos
• Negar tudo
• HTPasswd
• LDAP
• Autenticação básica
• Solicitar cabeçalho

Ao definir a configuração principal, podemos definir a política de identificação onde podemos definir o tipo de política que desejamos usar.

Permitir todos

Permitir todos

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Negar tudo

Isso negará o acesso a todos os nomes de usuário e senhas.

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd é usado para validar o nome de usuário e a senha em relação a uma senha de arquivo criptografada.

Para gerar um arquivo criptografado, a seguir está o comando.

$ htpasswd </path/to/users.htpasswd> <user_name>

Usando o arquivo criptografado.

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

Provedor de identidade LDAP

Isso é usado para autenticação LDAP, em que o servidor LDAP desempenha um papel fundamental na autenticação.

oauthConfig:
   ...
   identityProviders:
   - name: "ldap_authontication"
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: LDAPPasswordIdentityProvider
         attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
         bindDN: ""
         bindPassword: ""
         ca: my-ldap-ca-bundle.crt
         insecure: false
         url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"

Autenticação Básica

Isso é usado quando a validação de nome de usuário e senha é feita em uma autenticação de servidor para servidor. A autenticação é protegida no URL base e é apresentada no formato JSON.

oauthConfig:
   ...
   identityProviders:
   - name: my_remote_basic_auth_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: BasicAuthPasswordIdentityProvider
         url: https://www.vklnld908.int.example.com/remote-idp
         ca: /path/to/ca.file
         certFile: /path/to/client.crt
         keyFile: /path/to/client.key

Configurando uma conta de serviço

As contas de serviço fornecem uma maneira flexível de acessar a API OpenShift, expondo o nome de usuário e a senha para autenticação.

Habilitando uma conta de serviço

A conta de serviço usa um par de chaves pública e privada para autenticação. A autenticação na API é feita usando uma chave privada e validando-a com uma chave pública.

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

Criação de uma conta de serviço

Use o seguinte comando para criar uma conta de serviço

$ Openshift cli create service account <name of server account>

Trabalhando com Proxy HTTP

Na maior parte do ambiente de produção, o acesso direto à Internet é restrito. Eles não são expostos à Internet ou são expostos por meio de um proxy HTTP ou HTTPS. Em um ambiente OpenShift, esta definição de máquina proxy é definida como uma variável de ambiente.

Isso pode ser feito adicionando uma definição de proxy nos arquivos mestre e de nó localizados em /etc/sysconfig. Isso é semelhante ao que fazemos para qualquer outro aplicativo.

Máquina Mestre

/ etc / sysconfig / openshift-master

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Máquina de Nó

/ etc / sysconfig / openshift-node

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Uma vez feito isso, precisamos reiniciar as máquinas mestre e de nó.

Para Docker Pull

/ etc / sysconfig / docker

HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.com

Para fazer um pod funcionar em um ambiente de proxy, isso pode ser feito usando -

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

O comando do ambiente OC pode ser usado para atualizar o ambiente existente.

Armazenamento OpenShift com NFS

No OpenShift, o conceito de volume persistente e declarações de volume persistentes formam o armazenamento persistente. Este é um dos conceitos-chave em que primeiro o volume persistente é criado e depois o mesmo volume é reivindicado. Para isso, precisamos ter capacidade e espaço em disco suficientes no hardware subjacente.

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

Em seguida, usando o comando OC create, crie um Volume Persistente.

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

Reivindicando o volume criado.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

Crie a reivindicação.

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

Gerenciamento de usuários e funções

A administração de usuários e funções é usada para gerenciar usuários, seus acessos e controles em diferentes projetos.

Criação de um usuário

Modelos predefinidos podem ser usados ​​para criar novos usuários no OpenShift.

kind: "Template"
apiVersion: "v1"
parameters:
   - name: vipin
   required: true
objects:
   - kind: "User"
   apiVersion: "v1"
   metadata:
   name: "${email}" - kind: "Identity" apiVersion: "v1" metadata: name: "vipin:${email}"
   providerName: "SAML"
   providerUserName: "${email}" - kind: "UserIdentityMapping" apiVersion: "v1" identity: name: "vipin:${email}"
user:
   name: "${email}"

Use oc create –f <nome do arquivo> para criar usuários.

$ oc create –f vipin.yaml

Use o seguinte comando para excluir um usuário no OpenShift.

$ oc delete user <user name>

Limitando o acesso do usuário

ResourceQuotas e LimitRanges são usados ​​para limitar os níveis de acesso do usuário. Eles são usados ​​para limitar os pods e contêineres no cluster.

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

Criando a cotação usando a configuração acima

$ oc create -f resource-quota.yaml –n –Openshift-sample

Descrevendo a citação do recurso

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

Definir os limites do contêiner pode ser usado para limitar os recursos que serão usados ​​pelos contêineres implantados. Eles são usados ​​para definir as limitações máximas e mínimas de certos objetos.

Limitações do projeto do usuário

Isso é basicamente usado para o número de projetos que um usuário pode ter em qualquer ponto do tempo. Eles são feitos basicamente definindo os níveis de usuário em categorias de bronze, prata e ouro.

Precisamos primeiro definir um objeto que detém o valor de quantos projetos uma categoria bronze, prata e ouro pode ter. Isso precisa ser feito no arquivo master-confif.yaml.

admissionConfig:
   pluginConfig:
      ProjectRequestLimit:
         configuration:
            apiVersion: v1
            kind: ProjectRequestLimitConfig
            limits:
            - selector:
               level: platinum
            - selector:
               level: gold
            maxProjects: 15
            - selector:
               level: silver
            maxProjects: 10
            - selector:
               level: bronze
            maxProjects: 5

Reinicie o servidor mestre.

Atribuindo um usuário a um determinado nível.

$ oc label user vipin level = gold

Mover o usuário para fora da etiqueta, se necessário.

$ oc label user <user_name> level-

Adicionando funções a um usuário.

$ oadm policy add-role-to-user 
      
        <user_name> 
      

Removendo a função de um usuário.

$ oadm policy remove-role-from-user 
      
        <user_name> 
      

Adicionando uma função de cluster a um usuário.

$ oadm policy add-cluster-role-to-user 
      
        <user_name> 
      

Removendo uma função de cluster de um usuário.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name> 
      

Adicionando uma função a um grupo.

$ oadm policy add-role-to-user 
      
        <user_name> 
      

Removendo uma função de um grupo.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name> 
      

Adicionando uma função de cluster a um grupo.

$ oadm policy add-cluster-role-to-group 
      
        <groupname> 
      

Removendo uma função de cluster de um grupo.

$ oadm policy remove-cluster-role-from-group <role> <groupname>

Usuário para administração de cluster

Esta é uma das funções mais poderosas em que o usuário tem a capacidade de gerenciar um cluster completo, desde a criação até a exclusão de um cluster.

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

Usuário com poder máximo

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>

O OpenShift é baseado no Docker e no Kubernetes. Todos os contêineres são construídos em cima do cluster Docker, que é basicamente um serviço Kubernetes em cima de máquinas Linux, usando o recurso de orquestração Kubernetes.

Nesse processo, construímos o mestre Kubernetes, que controla todos os nós e implanta os contêineres em todos os nós. A principal função do Kubernetes é controlar o cluster OpenShift e o fluxo de implantação usando um tipo diferente de arquivo de configuração. Como no Kubernetes, usamos kubctl da mesma forma que usamos o utilitário de linha de comando OC para construir e implantar contêineres em nós de cluster.

A seguir estão os diferentes tipos de arquivos de configuração usados ​​para a criação de diferentes tipos de objetos no cluster.

• Images
• POD
• Service
• Controlador de Replicação
• Conjunto de réplicas
• Deployment

Imagens

As imagens do Kubernetes (Docker) são os principais blocos de construção da infraestrutura em contêiner. A partir de agora, o Kubernetes oferece suporte apenasDockerimagens. Cada contêiner em um pod tem sua imagem Docker em execução dentro dele.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
   containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5

POD

Um pod é uma coleção de contêineres e seu armazenamento dentro de um nó de um cluster do Kubernetes. É possível criar um pod com vários contêineres dentro dele. A seguir está um exemplo de como manter um contêiner de banco de dados e um contêiner de interface da web no mesmo pod.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
      image: tomcat: 8.0
      ports:
- containerPort: 7500
imagePullPolicy: Always

Serviço

Um serviço pode ser definido como um conjunto lógico de pods. Ele pode ser definido como uma abstração no topo do pod que fornece um único endereço IP e nome DNS pelo qual os pods podem ser acessados. Com o Service, é muito fácil gerenciar a configuração de balanceamento de carga. Ajuda a escalar os PODs com muita facilidade.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
      targetPort: 31999

Controlador de Replicação

O controlador de replicação é um dos principais recursos do Kubernetes, responsável por gerenciar o ciclo de vida do pod. Ele é responsável por garantir que um número especificado de réplicas de pod estejam em execução a qualquer momento.

apiVersion: v1
kind: ReplicationController
metadata:
   name: Tomcat-ReplicationController
spec:
   replicas: 3
   template:
   metadata:
      name: Tomcat-ReplicationController
   labels:
      app: App
      component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Conjunto de réplicas

O conjunto de réplicas garante quantas réplicas de pod devem estar em execução. Pode ser considerado uma substituição do controlador de replicação.

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
      tier: Backend
   matchExpression:
      - { key: tier, operation: In, values: [Backend]}
   
   app: App
   component: neo4j
spec:
   containers:
   - name: Tomcat-
image: tomcat: 8.0
   ports:
containerPort: 7474

Desdobramento, desenvolvimento

As implantações são atualizadas e versões superiores do controlador de replicação. Eles gerenciam a implantação de conjuntos de réplicas, que também são uma versão atualizada do controlador de replicação. Eles têm a capacidade de atualizar o conjunto de réplicas e também podem reverter para a versão anterior.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
lables:
   app: Tomcat-ReplicaSet
   tier: Backend
spec:
   containers:
name: Tomcat-
   image: tomcat: 8.0
   ports:
   - containerPort: 7474

Todos os arquivos de configuração podem ser usados ​​para criar seus respectivos objetos Kubernetes.

$ Kubectl create –f <file name>.yaml

Os comandos a seguir podem ser usados ​​para saber os detalhes e a descrição dos objetos Kubernetes.

For POD

$ Kubectl get pod <pod name> $ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>

For Replication Controller

$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name> $ kubectl describe rc <rc name>

For Service

$ Kubectl get svc <svc name> $ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>

Para obter mais detalhes sobre como trabalhar com Docker e Kubernetes, visite nosso tutorial Kubernetes usando o seguinte link kubernetes .

A segurança OpenShift é principalmente uma combinação de dois componentes que lidam principalmente com as restrições de segurança.

• Restrições de contexto de segurança (SCC)
• Conta de serviço

Restrições de contexto de segurança (SCC)

É basicamente usado para restrição de pod, o que significa que define as limitações de um pod, como em quais ações ele pode executar e quais todas as coisas que ele pode acessar no cluster.

O OpenShift fornece um conjunto de SCC predefinido que pode ser usado, modificado e estendido pelo administrador.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

Se alguém deseja usar qualquer scc predefinido, isso pode ser feito simplesmente adicionando o usuário ou o grupo ao grupo scc.

$ oadm policy add-user-to-scc <scc_name> <user_name> $ oadm policy add-group-to-scc <scc_name> <group_name>

Conta de serviço

As contas de serviço são basicamente usadas para controlar o acesso à API mestre do OpenShift, que é chamada quando um comando ou solicitação é disparado de qualquer máquina mestre ou de nó.

Sempre que um aplicativo ou processo exigir um recurso que não seja concedido pelo SCC restrito, você terá que criar uma conta de serviço específica e adicionar a conta ao respectivo SCC. No entanto, se um SCC não atender aos seus requisitos, é melhor criar um novo SCC específico para os seus requisitos, em vez de usar aquele que melhor se ajusta. No final, defina-o para a configuração de implantação.

$ oc create serviceaccount Cadmin $ oc adm policy add-scc-to-user vipin -z Cadmin

Segurança de contêiner

No OpenShift, a segurança de contêineres é baseada no conceito de quão segura é a plataforma de contêiner e onde os contêineres estão sendo executados. Existem várias coisas que aparecem quando falamos sobre segurança de contêineres e o que precisa ser cuidado.

Image Provenance - Um sistema de rotulagem seguro está em vigor que identifica exatamente e de forma incontestável de onde vieram os recipientes em execução no ambiente de produção.

Security Scanning - Um scanner de imagem verifica automaticamente todas as imagens em busca de vulnerabilidades conhecidas.

Auditing - O ambiente de produção é auditado regularmente para garantir que todos os contêineres sejam baseados em contêineres atualizados e que os hosts e os contêineres estejam configurados com segurança.

Isolation and Least Privilege- Os contêineres são executados com os recursos e privilégios mínimos necessários para funcionar com eficácia. Eles não podem interferir indevidamente no host ou em outros contêineres.

Runtime Threat Detection - Um recurso que detecta ameaças ativas contra aplicativos em contêineres em tempo de execução e responde automaticamente a elas.

Access Controls - Módulos de segurança do Linux, como AppArmor ou SELinux, são usados ​​para impor controles de acesso.

Existem alguns métodos principais pelos quais a segurança do contêiner é arquivada.

• Controle de acesso via oAuth
• Via console da web de autoatendimento
• Por certificados de plataforma

Controle de acesso via OAuth

Neste método, a autenticação para acesso de controle de API é arquivada obtendo um token seguro para autenticação por meio de servidores OAuth, que vem embutido na máquina mestre OpenShift. Como administrador, você tem a capacidade de modificar a configuração do servidor OAuth.

Para obter mais detalhes sobre a configuração do servidor OAuth, consulte o Capítulo 5 deste tutorial.

Via console da web de autoatendimento

Este recurso de segurança do console da web está embutido no console da web OpenShift. Este console garante que todas as equipes que trabalham juntas não tenham acesso a outros ambientes sem autenticação. O mestre multi-telnet no OpenShift possui os seguintes recursos de segurança -

• A camada TCL está habilitada
• Usa certificado x.509 para autenticação
• Protege a configuração do etcd na máquina mestre

Por certificados de plataforma

Nesse método, os certificados para cada host são configurados durante a instalação por meio do Ansible. Como ele usa o protocolo de comunicação HTTPS via Rest API, precisamos de uma conexão segura TCL para diferentes componentes e objetos. Esses são certificados predefinidos, no entanto, pode-se até ter um certificado personalizado instalado no cluster de mestre para acesso. Durante a configuração inicial do mestre, os certificados personalizados podem ser configurados substituindo os certificados existentes usandoopenshift_master_overwrite_named_certificates parâmetro.

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Para obter mais detalhes sobre como gerar certificados personalizados, visite o seguinte link -

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

Segurança de rede

No OpenShift, o Software Defined Networking (SDN) é usado para comunicação. O namespace de rede é usado para cada pod no cluster, em que cada pod obtém seu próprio IP e um intervalo de portas para obter o tráfego de rede nele. Por este método, pode-se isolar pods por causa dos quais não pode se comunicar com pods no outro projeto.

Isolando um Projeto

Isso pode ser feito pelo administrador do cluster usando o seguinte oadm command da CLI.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

Isso significa que os projetos definidos acima não podem se comunicar com outros projetos no cluster.

Segurança de Volume

A segurança de volume significa claramente proteger o PV e o PVC de projetos no cluster OpenShift. Existem principalmente quatro seções para controlar o acesso a volumes no OpenShift.

• Grupos Suplementares
• fsGroup
• runAsUser
• seLinuxOptions

Grupos suplementares - grupos suplementares são grupos regulares do Linux. Quando um processo é executado no sistema, ele é executado com um ID de usuário e um ID de grupo. Esses grupos são usados ​​para controlar o acesso ao armazenamento compartilhado.

Verifique a montagem NFS usando o seguinte comando.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Verifique os detalhes do NFS no servidor de montagem usando o seguinte comando.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

O / opt / nfs / export é acessível por UID454265 e o grupo 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup significa o grupo do sistema de arquivos que é usado para adicionar grupos suplementares de contêineres. O ID do grupo de suplemento é usado para armazenamento compartilhado e fsGroup é usado para armazenamento de bloco.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser usa o ID do usuário para comunicação. Isso é usado para definir a imagem do contêiner na definição do pod. Um único usuário de ID pode ser usado em todos os contêineres, se necessário.

Ao executar o contêiner, o ID definido é correspondido com o ID do proprietário na exportação. Se o ID especificado for definido externamente, ele se tornará global para todos os contêineres do pod. Se for definido com um pod específico, ele se tornará específico para um único contêiner.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265