OpenShift - Conceito Básico

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 a partir 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 nos quais 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 escalonar 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.

Construir estratégias

  • 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 Docker run.

  • 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 que são 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 terminais 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 localizar 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 para o 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 essa 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
ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved