OpenShift - Grundkonzept

Bevor wir mit der eigentlichen Einrichtung und Bereitstellung von Anwendungen beginnen, müssen wir einige grundlegende Begriffe und Konzepte verstehen, die in OpenShift V3 verwendet werden.

Container und Bilder

Bilder

Dies sind die Grundbausteine ​​von OpenShift, die aus Docker-Images bestehen. In jedem Pod unter OpenShift werden im Cluster eigene Images ausgeführt. Wenn wir einen Pod konfigurieren, haben wir ein Feld, das aus der Registrierung gepoolt wird. Diese Konfigurationsdatei ruft das Image ab und stellt es auf dem Clusterknoten bereit.

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

Führen Sie den folgenden Befehl aus, um ein Bild daraus zu ziehen und zu erstellen. OC ist der Client, der nach der Anmeldung mit der OpenShift-Umgebung kommuniziert.

$ oc create –f Tesing_for_Image_pull

Container

Dies wird erstellt, wenn das Docker-Image im OpenShift-Cluster bereitgestellt wird. Beim Definieren einer Konfiguration definieren wir den Containerabschnitt in der Konfigurationsdatei. In einem Container können mehrere Images ausgeführt werden, und alle auf dem Clusterknoten ausgeführten Container werden von OpenShift Kubernetes verwaltet.

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

Im Folgenden finden Sie die Spezifikationen zum Definieren eines Containers, in dem mehrere Bilder ausgeführt werden.

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

In der obigen Konfiguration haben wir einen Multi-Container-Pod mit zwei Bildern von Tomcat und MongoDB definiert.

Pods und Services

Pods

Pod kann als Sammlung von Containern und deren Speicherung in einem Knoten des OpenShift-Clusters (Kubernetes) definiert werden. Im Allgemeinen gibt es zwei Arten von Pods, angefangen von einem Einzelcontainer-Pod bis hin zu einem Mehrcontainer-Pod.

Single Container Pod - Diese können einfach mit dem Befehl OC oder mit einer Grundkonfigurations-XML-Datei erstellt werden.

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

Erstellen Sie es mit einer einfachen Yaml-Datei wie folgt.

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

Sobald die obige Datei erstellt wurde, wird ein Pod mit dem folgenden Befehl generiert.

$ oc create –f apache.yml

Multi-Container Pod- Multi-Container-Pods sind solche, in denen mehr als ein Container läuft. Sie werden wie folgt mit yaml-Dateien erstellt.

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

Nach dem Erstellen dieser Dateien können wir einfach dieselbe Methode wie oben verwenden, um einen Container zu erstellen.

Service- Da in einem Pod eine Reihe von Containern ausgeführt wird, verfügen wir auf die gleiche Weise über einen Dienst, der als logische Gruppe von Pods definiert werden kann. Es ist eine abstrahierte Ebene über dem Pod, die einen einzelnen IP- und DNS-Namen bereitstellt, über den auf Pods zugegriffen werden kann. Der Service hilft bei der Verwaltung der Lastausgleichskonfiguration und beim einfachen Skalieren des Pods. In OpenShift ist ein Service ein REST-Objekt, dessen Deifikation auf apiService auf dem OpenShift-Master veröffentlicht werden kann, um eine neue Instanz zu erstellen.

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

Builds und Streams

Builds

In OpenShift wird beim Erstellen von Bildern Bilder in Container umgewandelt. Es ist die Verarbeitung, die den Quellcode in ein Bild konvertiert. Dieser Erstellungsprozess arbeitet mit einer vordefinierten Strategie zum Erstellen von Quellcode für das Image.

Der Build verarbeitet mehrere Strategien und Quellen.

Strategien entwickeln

  • Source to Image- Dies ist im Grunde ein Werkzeug, das beim Erstellen reproduzierbarer Bilder hilft. Diese Images sind immer bereit, mit dem Docker-Befehl run ausgeführt zu werden.

  • Docker Build - Dies ist der Prozess, bei dem die Images mithilfe der Docker-Datei erstellt werden, indem der einfache Docker-Build-Befehl ausgeführt wird.

  • Custom Build - Dies sind die Builds, die zum Erstellen von Basis-Docker-Images verwendet werden.

Quellen erstellen

Git- Diese Quelle wird verwendet, wenn das Git-Repository zum Erstellen von Images verwendet wird. Die Docker-Datei ist optional. Die Konfigurationen aus dem Quellcode sehen wie folgt aus.

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 - Die Docker-Datei wird als Eingabe in die Konfigurationsdatei verwendet.

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

Image Streams- Bildströme werden nach dem Ziehen der Bilder erstellt. Der Vorteil eines Bildstroms besteht darin, dass nach Updates für die neue Version eines Bildes gesucht wird. Dies wird verwendet, um eine beliebige Anzahl von Docker-formatierten Container-Bildern zu vergleichen, die durch Tags gekennzeichnet sind.

Bildströme können automatisch eine Aktion ausführen, wenn ein neues Bild erstellt wird. Alle Builds und Bereitstellungen können auf Image-Aktionen achten und eine entsprechende Aktion ausführen. Im Folgenden wird beschrieben, wie Sie einen Stream erstellen.

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

Routen und Vorlagen

Routen

In OpenShift ist Routing eine Methode, um den Dienst der Außenwelt zugänglich zu machen, indem ein extern erreichbarer Hostname erstellt und konfiguriert wird. Routen und Endpunkte werden verwendet, um den Dienst der Außenwelt zugänglich zu machen, von wo aus der Benutzer die Namenskonnektivität (DNS) verwenden kann, um auf definierte Anwendungen zuzugreifen.

In OpenShift werden Routen mithilfe von Routern erstellt, die vom OpenShift-Administrator im Cluster bereitgestellt werden. Router werden verwendet, um HTTP (80) - und https (443) -Ports an externe Anwendungen zu binden.

Im Folgenden sind die verschiedenen Arten von Protokollen aufgeführt, die von Routen unterstützt werden:

  • HTTP
  • HTTPS
  • TSL und Web Socket

Bei der Konfiguration des Dienstes werden Selektoren verwendet, um den Dienst zu konfigurieren und den Endpunkt mithilfe dieses Dienstes zu finden. Im Folgenden finden Sie ein Beispiel dafür, wie wir einen Dienst und das Routing für diesen Dienst mithilfe eines geeigneten Protokolls erstellen.

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

Führen Sie als Nächstes den folgenden Befehl aus, und der Dienst wird erstellt.

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

So sieht der Service nach der Erstellung aus.

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

Erstellen Sie ein Routing für den Dienst mit dem folgenden Code.

{
   "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"}
   }
}

Wenn der OC-Befehl zum Erstellen einer Route verwendet wird, wird eine neue Instanz der Routenressource erstellt.

Vorlagen

Vorlagen werden in OpenShift als Standardobjekt definiert, das mehrfach verwendet werden kann. Es wird mit einer Liste von Platzhaltern parametrisiert, mit denen mehrere Objekte erstellt werden. Dies kann verwendet werden, um alles zu erstellen, angefangen von einem Pod bis hin zum Netzwerk, für das Benutzer die Berechtigung zum Erstellen haben. Eine Liste von Objekten kann erstellt werden, wenn die Vorlage von der CLI- oder GUI-Oberfläche im Bild in das Projektverzeichnis hochgeladen wird.

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>

Authentifizierung und Autorisierung

Authentifizierung

In OpenShift verfügt Master beim Konfigurieren der Master- und Client-Struktur über eine integrierte Funktion des OAuth-Servers. Der OAuth-Server wird zum Generieren von Token verwendet, die zur Authentifizierung bei der API verwendet werden. Da OAuth als Standardeinstellung für Master geliefert wird, wird standardmäßig der Identitätsanbieter Alle zulassen verwendet. Es sind verschiedene Identitätsanbieter vorhanden, die unter konfiguriert werden können/etc/openshift/master/master-config.yaml.

In OAuth gibt es verschiedene Arten von Identitätsanbietern.

  • Alles erlauben
  • Alles verweigern
  • HTPasswd
  • LDAP
  • Grundlegende Authentifizierung

Alles erlauben

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

Alles verweigern

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

Um HTPasswd verwenden zu können, müssen wir zuerst die Httpd-Tools auf dem Master-Computer einrichten und dann auf die gleiche Weise wie für andere konfigurieren.

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

Genehmigung

Die Autorisierung ist eine Funktion von OpenShift Master, mit der die Validierung für die Validierung eines Benutzers verwendet wird. Dies bedeutet, dass der Benutzer, der versucht, eine Aktion auszuführen, überprüft wird, ob der Benutzer berechtigt ist, diese Aktion für ein bestimmtes Projekt auszuführen. Dies hilft dem Administrator, den Zugriff auf die Projekte zu steuern.

Autorisierungsrichtlinien werden gesteuert mit -

  • Rules
  • Roles
  • Bindings

Die Bewertung der Genehmigung erfolgt mit -

  • Identity
  • Action
  • Bindings

Richtlinien verwenden -

  • Clusterrichtlinie
  • Lokale Politik
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