OpenShift - podstawowa koncepcja

Zanim zaczniemy od właściwej konfiguracji i wdrażania aplikacji, musimy zrozumieć podstawowe pojęcia i pojęcia używane w OpenShift V3.

Kontenery i obrazy

Obrazy

To są podstawowe bloki konstrukcyjne OpenShift, które są tworzone z obrazów Dockera. W każdym pod OpenShift klaster ma swoje własne obrazy działające w nim. Kiedy konfigurujemy pod, mamy pole, które zostanie zebrane z rejestru. Ten plik konfiguracyjny pobierze obraz i wdroży go w węźle klastra.

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

Aby wyciągnąć i utworzyć z niego obraz, uruchom następujące polecenie. OC to klient, który komunikuje się ze środowiskiem OpenShift po zalogowaniu.

$ oc create –f Tesing_for_Image_pull

Pojemnik

Jest to tworzone, gdy obraz platformy Docker zostanie wdrożony w klastrze OpenShift. Definiując dowolną konfigurację, w pliku konfiguracyjnym definiujemy sekcję kontenera. Jeden kontener może mieć wiele uruchomionych obrazów, a wszystkie kontenery działające w węźle klastra są zarządzane przez 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

Poniżej znajdują się specyfikacje dotyczące definiowania kontenera, w którym działa wiele obrazów.

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

W powyższej konfiguracji zdefiniowaliśmy kapsułę wielokontenerową z dwoma obrazami Tomcat i MongoDB w środku.

Strąki i usługi

Strąki

Pod można zdefiniować jako zbiór kontenerów i ich przechowywania w węźle klastra OpenShift (Kubernetes). Ogólnie rzecz biorąc, mamy dwa rodzaje kapsuły, zaczynając od pojedynczego pojemnika na pojemnik na wiele pojemników.

Single Container Pod - Można je łatwo utworzyć za pomocą polecenia OC lub za pomocą podstawowego pliku konfiguracyjnego yml.

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

Utwórz go za pomocą prostego pliku yaml w następujący sposób.

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

Po utworzeniu powyższego pliku wygeneruje pod za pomocą następującego polecenia.

$ oc create –f apache.yml

Multi-Container Pod- Strąki wielokontenerowe to takie, w których mamy więcej niż jeden uruchomiony kontener. Są tworzone przy użyciu plików yaml w następujący sposób.

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

Po utworzeniu tych plików możemy po prostu użyć tej samej metody co powyżej, aby utworzyć kontener.

Service- Ponieważ mamy zestaw kontenerów działających w zasobniku, w ten sam sposób mamy usługę, którą można zdefiniować jako logiczny zestaw zasobników. Jest to abstrakcyjna warstwa na górze kapsuły, która zapewnia pojedynczy adres IP i nazwę DNS, przez które można uzyskać dostęp do zasobników. Usługa pomaga w zarządzaniu konfiguracją równoważenia obciążenia i bardzo łatwym skalowaniu poda. W OpenShift, usługa jest obiektem REST, którego deifikacja może zostać wysłana do apiService w OpenShift master w celu utworzenia nowej instancji.

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

Kompilacje i strumienie

Buduje

W OpenShift kompilacja to proces przekształcania obrazów w kontenery. To przetwarzanie konwertuje kod źródłowy na obraz. Ten proces kompilacji działa na wstępnie zdefiniowanej strategii budowania kodu źródłowego do obrazu.

Kompilacja przetwarza wiele strategii i źródeł.

Buduj strategie

Source to Image- To w zasadzie narzędzie, które pomaga w budowaniu powtarzalnych obrazów. Te obrazy są zawsze gotowe do uruchomienia za pomocą polecenia uruchamiania platformy Docker.
Docker Build - Jest to proces, w którym obrazy są budowane przy użyciu pliku Docker, uruchamiając proste polecenie kompilacji platformy Docker.
Custom Build - To są kompilacje, które są używane do tworzenia podstawowych obrazów Dockera.

Buduj źródła

Git- To źródło jest używane, gdy repozytorium git jest używane do tworzenia obrazów. Plik Dockerfile jest opcjonalny. Konfiguracje z kodu źródłowego wyglądają następująco.

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 - Plik Dockerfile jest używany jako dane wejściowe w pliku konfiguracyjnym.

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

Image Streams- Strumienie obrazów są tworzone po ściągnięciu obrazów. Zaletą strumienia obrazów jest to, że wyszukuje aktualizacje nowej wersji obrazu. Służy do porównywania dowolnej liczby obrazów kontenerów w formacie Docker zidentyfikowanych za pomocą tagów.

Strumienie obrazów mogą automatycznie wykonywać akcję po utworzeniu nowego obrazu. Wszystkie kompilacje i wdrożenia mogą obserwować działanie obrazu i odpowiednio wykonywać akcję. Poniżej opisano, jak definiujemy strumień kompilacji.

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

Trasy i szablony

Trasy

W OpenShift routing jest metodą ujawniania usługi światu zewnętrznemu poprzez tworzenie i konfigurowanie nazwy hosta osiągalnego zewnętrznie. Trasy i punkty końcowe służą do udostępniania usługi światu zewnętrznemu, z którego użytkownik może korzystać z połączenia nazw (DNS) w celu uzyskania dostępu do określonej aplikacji.

W OpenShift trasy są tworzone przy użyciu routerów, które są wdrażane przez administratora OpenShift w klastrze. Routery służą do wiązania portów HTTP (80) i https (443) z aplikacjami zewnętrznymi.

Poniżej przedstawiono różne rodzaje protokołów obsługiwanych przez trasy -

HTTP
HTTPS
TSL i gniazdo sieciowe

Podczas konfigurowania usługi selektory służą do konfigurowania usługi i znajdowania punktu końcowego przy użyciu tej usługi. Poniżej znajduje się przykład tego, jak tworzymy usługę i wyznaczamy trasy dla tej usługi przy użyciu odpowiedniego protokołu.

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

Następnie uruchom następujące polecenie, a usługa zostanie utworzona.

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

Tak wygląda usługa po stworzeniu.

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

Utwórz trasę dla usługi przy użyciu następującego kodu.

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

Gdy do utworzenia trasy używana jest komenda OC, tworzona jest nowa instancja zasobu trasy.

Szablony

Szablony są zdefiniowane jako standardowy obiekt w OpenShift, którego można używać wielokrotnie. Jest sparametryzowany za pomocą listy symboli zastępczych, które są używane do tworzenia wielu obiektów. Można to wykorzystać do stworzenia wszystkiego, od poda do sieci, do której użytkownicy mają uprawnienia do tworzenia. Listę obiektów można utworzyć, jeśli szablon z interfejsu CLI lub GUI w obrazie zostanie załadowany do katalogu projektu.

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>

Uwierzytelnianie i autoryzacja

Poświadczenie

W OpenShift, podczas konfigurowania struktury głównej i klienta, master oferuje wbudowaną funkcję serwera OAuth. Serwer OAuth służy do generowania tokenów, które służą do uwierzytelniania w API. Ponieważ OAuth jest domyślną konfiguracją dla mastera, domyślnie używamy dostawcy tożsamości Allow All. Obecni są różni dostawcy tożsamości, których można skonfigurować pod adresem/etc/openshift/master/master-config.yaml.

W OAuth są obecne różne typy dostawców tożsamości.

Pozwól wszystkim
Zaprzeczać wszystkiemu
HTPasswd
LDAP
Uwierzytelnianie podstawowe

Pozwól wszystkim

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

Zaprzeczać wszystkiemu

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

Aby korzystać z HTPasswd, musimy najpierw ustawić narzędzia Httpd na maszynie głównej, a następnie skonfigurować je w taki sam sposób, jak to zrobiliśmy dla innych.

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

Upoważnienie

Autoryzacja to funkcja mastera OpenShift, która służy do sprawdzania poprawności użytkownika. Oznacza to, że sprawdza użytkownika, który próbuje wykonać akcję, aby zobaczyć, czy użytkownik jest upoważniony do wykonania tej akcji w danym projekcie. Pomaga to administratorowi kontrolować dostęp do projektów.

Zasady autoryzacji są kontrolowane za pomocą -