OpenShift - Concetto di base

Prima di iniziare con l'effettiva configurazione e distribuzione delle applicazioni, è necessario comprendere alcuni termini e concetti di base utilizzati in OpenShift V3.

Contenitori e immagini

immagini

Questi sono gli elementi costitutivi di base di OpenShift, formati da immagini Docker. In ogni pod su OpenShift, il cluster ha le proprie immagini in esecuzione al suo interno. Quando configuriamo un pod, abbiamo un campo che verrà raggruppato dal registro. Questo file di configurazione estrarrà l'immagine e la distribuirà sul nodo del 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

Per estrarre e creare un'immagine da esso, eseguire il seguente comando. OC è il client per comunicare con l'ambiente OpenShift dopo il login.

$ oc create –f Tesing_for_Image_pull

Contenitore

Questo viene creato quando l'immagine Docker viene distribuita sul cluster OpenShift. Durante la definizione di qualsiasi configurazione, definiamo la sezione contenitore nel file di configurazione. Un contenitore può avere più immagini in esecuzione all'interno e tutti i contenitori in esecuzione sul nodo del cluster sono gestiti da 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

Di seguito sono riportate le specifiche per la definizione di un contenitore con più immagini in esecuzione al suo interno.

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

Nella configurazione precedente, abbiamo definito un pod multi-container con due immagini di Tomcat e MongoDB al suo interno.

Pod e servizi

Pod

Il pod può essere definito come una raccolta di container e il relativo spazio di archiviazione all'interno di un nodo del cluster OpenShift (Kubernetes). In generale, abbiamo due tipi di pod a partire da un pod contenitore singolo fino a un pod multi-contenitore.

Single Container Pod - Questi possono essere facilmente creati con il comando OC o da un file yml di configurazione di base.

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

Crealo con un semplice file yaml come segue.

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

Una volta creato il file sopra, genererà un pod con il seguente comando.

$ oc create –f apache.yml

Multi-Container Pod- I pod multi-container sono quelli in cui abbiamo più di un container in esecuzione al suo interno. Vengono creati utilizzando i file yaml come segue.

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

Dopo aver creato questi file, possiamo semplicemente usare lo stesso metodo di cui sopra per creare un contenitore.

Service- Poiché abbiamo un insieme di contenitori in esecuzione all'interno di un pod, allo stesso modo abbiamo un servizio che può essere definito come un insieme logico di pod. È un livello astratto sopra il pod, che fornisce un singolo IP e nome DNS attraverso il quale è possibile accedere ai pod. Il servizio aiuta nella gestione della configurazione del bilanciamento del carico e nel ridimensionare il pod molto facilmente. In OpenShift, un servizio è un oggetto REST la cui deificazione può essere inviata a apiService sul master OpenShift per creare una nuova istanza.

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

Build e flussi

Costruisce

In OpenShift, la compilazione è un processo di trasformazione delle immagini in contenitori. È l'elaborazione che converte il codice sorgente in un'immagine. Questo processo di compilazione funziona su una strategia predefinita di creazione di codice sorgente per l'immagine.

La build elabora molteplici strategie e fonti.

Costruisci strategie

Source to Image- Questo è fondamentalmente uno strumento che aiuta a costruire immagini riproducibili. Queste immagini sono sempre in una fase pronta per essere eseguite utilizzando il comando di esecuzione Docker.
Docker Build - Questo è il processo in cui le immagini vengono create utilizzando il file Docker eseguendo un semplice comando di build Docker.
Custom Build - Queste sono le build utilizzate per creare immagini Docker di base.

Costruisci sorgenti

Git- Questa sorgente viene utilizzata quando il repository git viene utilizzato per la creazione di immagini. Il Dockerfile è facoltativo. Le configurazioni dal codice sorgente hanno il seguente aspetto.

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 - Il Dockerfile viene utilizzato come input nel file di configurazione.

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

Image Streams- I flussi di immagini vengono creati dopo aver estratto le immagini. Il vantaggio di un flusso di immagini è che cerca gli aggiornamenti sulla nuova versione di un'immagine. Viene utilizzato per confrontare un numero qualsiasi di immagini del contenitore formattate Docker identificate dai tag.

I flussi di immagini possono eseguire automaticamente un'azione quando viene creata una nuova immagine. Tutte le build e le distribuzioni possono osservare l'azione dell'immagine ed eseguire un'azione di conseguenza. Di seguito è riportato come definiamo una creazione di un flusso.

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

Percorsi e modelli

Itinerari

In OpenShift, il routing è un metodo per esporre il servizio al mondo esterno creando e configurando un hostname raggiungibile esternamente. Percorsi ed endpoint vengono utilizzati per esporre il servizio al mondo esterno, da cui l'utente può utilizzare la connettività del nome (DNS) per accedere all'applicazione definita.

In OpenShift, le rotte vengono create utilizzando i router distribuiti dall'amministratore di OpenShift sul cluster. I router vengono utilizzati per collegare le porte HTTP (80) e https (443) ad applicazioni esterne.

Di seguito sono riportati i diversi tipi di protocollo supportati dalle rotte:

HTTP
HTTPS
TSL e web socket

Quando si configura il servizio, i selettori vengono utilizzati per configurare il servizio e trovare l'endpoint utilizzando quel servizio. Di seguito è riportato un esempio di come creiamo un servizio e il routing per quel servizio utilizzando un protocollo appropriato.

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

Quindi, esegui il seguente comando e il servizio viene creato.

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

Ecco come appare il servizio dopo la creazione.

$ 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.

Crea un instradamento per il servizio utilizzando il codice seguente.

{
   "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 il comando OC viene utilizzato per creare una rotta, viene creata una nuova istanza della risorsa della rotta.

Modelli

I modelli sono definiti come un oggetto standard in OpenShift che può essere utilizzato più volte. È parametrizzato con un elenco di segnaposto che vengono utilizzati per creare più oggetti. Questo può essere utilizzato per creare qualsiasi cosa, a partire da un pod al networking, per cui gli utenti hanno l'autorizzazione a creare. È possibile creare un elenco di oggetti, se il modello dall'interfaccia CLI o GUI nell'immagine viene caricato nella directory del progetto.

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>

Autenticazione e autorizzazione

Autenticazione

In OpenShift, durante la configurazione della struttura master e client, master presenta una funzionalità incorporata del server OAuth. Il server OAuth viene utilizzato per la generazione di token, che viene utilizzato per l'autenticazione all'API. Poiché OAuth viene fornito come configurazione predefinita per il master, abbiamo il provider di identità Consenti tutto utilizzato per impostazione predefinita. Sono presenti diversi provider di identità che possono essere configurati in/etc/openshift/master/master-config.yaml.

Esistono diversi tipi di provider di identità presenti in OAuth.

Permettere tutto
Nega tutto
HTPasswd
LDAP
Autenticazione di base

Permettere tutto

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

Nega tutto

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

Per poter usare HTPasswd, dobbiamo prima impostare Httpd-tools sulla macchina master e poi configurarlo come abbiamo fatto per gli altri.

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

Autorizzazione

L'autorizzazione è una funzionalità di OpenShift master, che viene utilizzata per convalidare un utente. Ciò significa che controlla l'utente che sta tentando di eseguire un'azione per vedere se l'utente è autorizzato a eseguire quell'azione su un determinato progetto. Questo aiuta l'amministratore a controllare l'accesso ai progetti.

I criteri di autorizzazione sono controllati utilizzando: