OpenShift - แนวคิดพื้นฐาน

ก่อนที่จะเริ่มการตั้งค่าและการใช้งานแอปพลิเคชันจริงเราจำเป็นต้องเข้าใจคำศัพท์และแนวคิดพื้นฐานบางประการที่ใช้ใน OpenShift V3

ภาชนะและรูปภาพ

รูปภาพ

สิ่งเหล่านี้เป็นส่วนประกอบพื้นฐานของ OpenShift ซึ่งประกอบขึ้นจากอิมเมจ Docker ในแต่ละพ็อดบน OpenShift คลัสเตอร์จะมีอิมเมจของตัวเองที่ทำงานอยู่ภายใน เมื่อเรากำหนดค่าพ็อดเราจะมีฟิลด์ที่จะรวบรวมจากรีจิสทรี ไฟล์คอนฟิกูเรชันนี้จะดึงอิมเมจและปรับใช้บนโหนดคลัสเตอร์

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

ในการดึงและสร้างภาพออกมาให้เรียกใช้คำสั่งต่อไปนี้ OC เป็นไคลเอนต์ในการสื่อสารกับสภาพแวดล้อม OpenShift หลังจากเข้าสู่ระบบ

$ oc create –f Tesing_for_Image_pull

คอนเทนเนอร์

สิ่งนี้ถูกสร้างขึ้นเมื่ออิมเมจ Docker ถูกปรับใช้บนคลัสเตอร์ OpenShift ในขณะที่กำหนดการกำหนดค่าใด ๆ เรากำหนดส่วนคอนเทนเนอร์ในไฟล์กำหนดค่า คอนเทนเนอร์เดียวสามารถมีหลายภาพที่ทำงานอยู่ภายในและคอนเทนเนอร์ทั้งหมดที่ทำงานบนโหนดคลัสเตอร์ได้รับการจัดการโดย 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

ต่อไปนี้เป็นข้อกำหนดสำหรับการกำหนดคอนเทนเนอร์ที่มีรูปภาพหลายรูปทำงานอยู่ภายใน

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

ในการกำหนดค่าข้างต้นเราได้กำหนดพ็อดหลายคอนเทนเนอร์ที่มีภาพ Tomcat และ MongoDB สองภาพอยู่ภายใน

พ็อดและบริการ

พ็อด

Pod สามารถกำหนดเป็นคอลเล็กชันของคอนเทนเนอร์และที่เก็บข้อมูลภายในโหนดของคลัสเตอร์ OpenShift (Kubernetes) โดยทั่วไปเรามีพ็อดสองประเภทโดยเริ่มจากพ็อดคอนเทนเนอร์เดียวไปจนถึงพ็อดหลายคอนเทนเนอร์

Single Container Pod - สิ่งเหล่านี้สามารถสร้างได้อย่างง่ายดายด้วยคำสั่ง OC หรือโดยไฟล์ yml การกำหนดค่าพื้นฐาน

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

สร้างด้วยไฟล์ yaml ง่ายๆดังนี้

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

เมื่อสร้างไฟล์ด้านบนแล้วไฟล์จะสร้างพ็อดด้วยคำสั่งต่อไปนี้

$ oc create –f apache.yml

Multi-Container Pod- พ็อดหลายคอนเทนเนอร์คือพ็อดที่เรามีคอนเทนเนอร์มากกว่าหนึ่งตู้ที่ทำงานอยู่ภายในนั้น สร้างขึ้นโดยใช้ไฟล์ yaml ดังต่อไปนี้

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

หลังจากสร้างไฟล์เหล่านี้แล้วเราสามารถใช้วิธีเดียวกับด้านบนเพื่อสร้างคอนเทนเนอร์

Service- เนื่องจากเรามีชุดคอนเทนเนอร์ที่ทำงานอยู่ภายในพ็อดในทำนองเดียวกันเราจึงมีบริการที่สามารถกำหนดเป็นชุดพ็อดเชิงตรรกะได้ เป็นเลเยอร์นามธรรมที่ด้านบนของพ็อดซึ่งมีชื่อ IP และ DNS เดียวที่สามารถเข้าถึงพ็อดได้ บริการช่วยในการจัดการการกำหนดค่าการจัดสรรภาระงานและปรับขนาดพ็อดได้อย่างง่ายดาย ใน OpenShift เซอร์วิสคืออ็อบเจ็กต์ REST ซึ่งสามารถโพสต์ deification ไปยัง apiService บน OpenShift master เพื่อสร้างอินสแตนซ์ใหม่

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

สร้างและสตรีม

สร้าง

ใน OpenShift บิลด์เป็นกระบวนการเปลี่ยนรูปภาพเป็นคอนเทนเนอร์ เป็นการประมวลผลที่แปลงซอร์สโค้ดเป็นรูปภาพ กระบวนการสร้างนี้ทำงานบนกลยุทธ์ที่กำหนดไว้ล่วงหน้าในการสร้างซอร์สโค้ดเป็นรูปภาพ

การสร้างประมวลผลกลยุทธ์และแหล่งที่มาต่างๆ

สร้างกลยุทธ์

  • Source to Image- โดยพื้นฐานแล้วเป็นเครื่องมือที่ช่วยในการสร้างภาพที่ทำซ้ำได้ อิมเมจเหล่านี้อยู่ในขั้นตอนที่พร้อมสำหรับการรันโดยใช้คำสั่ง Docker run เสมอ

  • Docker Build - นี่คือกระบวนการที่สร้างภาพโดยใช้ไฟล์ Docker โดยเรียกใช้คำสั่ง Docker build แบบง่าย

  • Custom Build - นี่คืองานสร้างที่ใช้สำหรับสร้างอิมเมจ Docker พื้นฐาน

สร้างแหล่งที่มา

Git- แหล่งที่มานี้ถูกใช้เมื่อใช้ที่เก็บ git สำหรับการสร้างอิมเมจ Dockerfile เป็นทางเลือก การกำหนดค่าจากซอร์สโค้ดมีลักษณะดังต่อไปนี้

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 - Dockerfile ใช้เป็นอินพุตในไฟล์กำหนดค่า

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

Image Streams- สตรีมภาพถูกสร้างขึ้นหลังจากดึงภาพ ข้อได้เปรียบของสตรีมรูปภาพคือการค้นหาการอัปเดตเกี่ยวกับเวอร์ชันใหม่ของรูปภาพ ใช้เพื่อเปรียบเทียบอิมเมจคอนเทนเนอร์ที่จัดรูปแบบ Docker จำนวนเท่าใดก็ได้ที่ระบุโดยแท็ก

สตรีมรูปภาพสามารถดำเนินการได้โดยอัตโนมัติเมื่อสร้างภาพใหม่ การสร้างและการปรับใช้ทั้งหมดสามารถรับชมการทำงานของภาพและดำเนินการตามนั้น ต่อไปนี้เป็นวิธีที่เรากำหนดสร้างสตรีม

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

เส้นทางและเทมเพลต

เส้นทาง

ใน OpenShift การกำหนดเส้นทางเป็นวิธีการเปิดเผยบริการไปยังโลกภายนอกโดยการสร้างและกำหนดค่าชื่อโฮสต์ที่เข้าถึงได้จากภายนอก เส้นทางและจุดสิ้นสุดถูกใช้เพื่อเปิดเผยบริการสู่โลกภายนอกซึ่งผู้ใช้สามารถใช้ชื่อการเชื่อมต่อ (DNS) เพื่อเข้าถึงแอปพลิเคชันที่กำหนด

ใน OpenShift เส้นทางถูกสร้างขึ้นโดยใช้เราเตอร์ซึ่งปรับใช้โดยผู้ดูแลระบบ OpenShift บนคลัสเตอร์ เราเตอร์ใช้เพื่อผูกพอร์ต HTTP (80) และ https (443) กับแอปพลิเคชันภายนอก

ต่อไปนี้เป็นโปรโตคอลประเภทต่างๆที่เส้นทางรองรับ -

  • HTTP
  • HTTPS
  • TSL และเว็บซ็อกเก็ต

เมื่อกำหนดค่าบริการตัวเลือกจะใช้เพื่อกำหนดค่าบริการและค้นหาจุดสิ้นสุดโดยใช้บริการนั้น ต่อไปนี้เป็นตัวอย่างวิธีที่เราสร้างบริการและการกำหนดเส้นทางสำหรับบริการนั้นโดยใช้โปรโตคอลที่เหมาะสม

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

จากนั้นรันคำสั่งต่อไปนี้และบริการจะถูกสร้างขึ้น

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

นี่คือลักษณะของบริการหลังการสร้าง

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

สร้างเส้นทางสำหรับบริการโดยใช้รหัสต่อไปนี้

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

เมื่อใช้คำสั่ง OC เพื่อสร้างเส้นทางระบบจะสร้างอินสแตนซ์ใหม่ของทรัพยากรเส้นทาง

เทมเพลต

เทมเพลตถูกกำหนดให้เป็นวัตถุมาตรฐานใน OpenShift ซึ่งสามารถใช้ได้หลายครั้ง มีการกำหนดพารามิเตอร์ด้วยรายการตัวยึดตำแหน่งซึ่งใช้ในการสร้างวัตถุหลายชิ้น สิ่งนี้สามารถใช้เพื่อสร้างอะไรก็ได้ตั้งแต่พ็อดไปจนถึงระบบเครือข่ายซึ่งผู้ใช้มีสิทธิ์ในการสร้าง สามารถสร้างรายการวัตถุได้หากเทมเพลตจากอินเทอร์เฟซ CLI หรือ GUI ในอิมเมจถูกอัปโหลดไปยังไดเร็กทอรีโปรเจ็กต์

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>

การรับรองความถูกต้องและการอนุญาต

การรับรองความถูกต้อง

ใน OpenShift ในขณะที่กำหนดค่าโครงสร้างหลักและไคลเอ็นต์ต้นแบบจะมาพร้อมกับคุณสมบัติที่สร้างขึ้นของเซิร์ฟเวอร์ OAuth เซิร์ฟเวอร์ OAuth ใช้สำหรับสร้างโทเค็นซึ่งใช้สำหรับการตรวจสอบสิทธิ์กับ API เนื่องจาก OAuth มาเป็นการตั้งค่าเริ่มต้นสำหรับต้นแบบเราจึงมีการใช้ผู้ให้บริการข้อมูลประจำตัวอนุญาตทั้งหมดเป็นค่าเริ่มต้น มีผู้ให้บริการข้อมูลประจำตัวที่แตกต่างกันซึ่งสามารถกำหนดค่าได้ที่/etc/openshift/master/master-config.yaml.

มีผู้ให้บริการข้อมูลประจำตัวประเภทต่างๆที่มีอยู่ใน OAuth

  • อนุญาตทั้งหมด
  • ปฏิเสธทั้งหมด
  • HTPasswd
  • LDAP
  • การรับรองความถูกต้องขั้นพื้นฐาน

อนุญาตทั้งหมด

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

ปฏิเสธทั้งหมด

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

ในการใช้ HTPasswd เราต้องตั้งค่า Httpd-tools บนเครื่องหลักก่อนจากนั้นกำหนดค่าในลักษณะเดียวกับที่เราทำกับเครื่องอื่น

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

การอนุญาต

การอนุญาตเป็นคุณสมบัติของ OpenShift master ซึ่งใช้ในการตรวจสอบความถูกต้องของผู้ใช้ ซึ่งหมายความว่าจะตรวจสอบผู้ใช้ที่พยายามดำเนินการเพื่อดูว่าผู้ใช้ได้รับอนุญาตให้ดำเนินการกับโปรเจ็กต์นั้น ๆ หรือไม่ สิ่งนี้ช่วยให้ผู้ดูแลระบบสามารถควบคุมการเข้าถึงโครงการ

นโยบายการอนุญาตถูกควบคุมโดยใช้ -

  • Rules
  • Roles
  • Bindings

การประเมินการอนุญาตทำได้โดยใช้ -

  • Identity
  • Action
  • Bindings

การใช้นโยบาย -

  • นโยบายคลัสเตอร์
  • นโยบายท้องถิ่น