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
การใช้นโยบาย -
- นโยบายคลัสเตอร์
- นโยบายท้องถิ่น