OpenShift – Basic Concept  Khái niệm cơ bản

Trước khi bắt đầu thiết lập và triển khai ứng dụng thực tế, chúng ta cần hiểu một số thuật ngữ và khái niệm cơ bản được sử dụng trong OpenShift V3.

Vùng chứa và Hình ảnh

Hình ảnh

Đây là các khối xây dựng cơ bản của OpenShift, được hình thành từ các hình ảnh Docker. Trong mỗi nhóm trên OpenShift, cụm có các hình ảnh riêng chạy bên trong nó. Khi chúng tôi định cấu hình một nhóm, chúng tôi có một trường sẽ được gộp chung từ sổ đăng ký. Tệp cấu hình này sẽ kéo hình ảnh và triển khai nó trên nút cụm.

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

Để kéo và tạo một hình ảnh từ nó, hãy chạy lệnh sau. OC là máy khách để giao tiếp với môi trường OpenShift sau khi đăng nhập.

$ oc create –f Tesing_for_Image_pull

Thùng đựng hàng

Điều này được tạo khi hình ảnh Docker được triển khai trên cụm OpenShift. Trong khi xác định bất kỳ cấu hình nào, chúng tôi xác định phần vùng chứa trong tệp cấu hình. Một vùng chứa có thể có nhiều hình ảnh chạy bên trong và tất cả các vùng chứa chạy trên nút cụm đều do OpenShift Kubernetes quản lý.

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

Sau đây là các thông số kỹ thuật để xác định một vùng chứa có nhiều hình ảnh chạy bên trong nó.

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

Trong cấu hình trên, chúng ta đã xác định một nhóm đa vùng chứa với hai hình ảnh Tomcat và MongoDB bên trong nó.

Nhóm và Dịch vụ

Vỏ

Pod có thể được định nghĩa là một tập hợp các vùng chứa và lưu trữ của nó bên trong một nút của cụm OpenShift (Kubernetes). Nói chung, chúng ta có hai loại nhóm bắt đầu từ một nhóm chứa một thùng chứa đến nhóm nhiều thùng chứa.

Hộp chứa đơn – Chúng có thể dễ dàng được tạo bằng lệnh OC hoặc bằng tệp yml cấu hình cơ bản.

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

Tạo nó bằng một tệp yaml đơn giản như sau.

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

Khi tệp ở trên được tạo, nó sẽ tạo một nhóm bằng lệnh sau.

$ oc create –f apache.yml

Multi-Container Pod – Multi-Container Pod là những nhóm trong đó chúng ta có nhiều hơn một container chạy bên trong nó. Chúng được tạo bằng cách sử dụng các tệp yaml như sau.

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

Sau khi tạo các tệp này, chúng ta chỉ cần sử dụng phương pháp tương tự như trên để tạo vùng chứa.Dịch vụ – Vì chúng ta có một tập hợp các vùng chứa chạy bên trong một nhóm, theo cách tương tự, chúng ta có một dịch vụ có thể được định nghĩa là một tập hợp các nhóm hợp lý. Đó là một lớp được trừu tượng hóa trên đầu nhóm, cung cấp một IP và tên DNS duy nhất mà thông qua đó, các nhóm có thể được truy cập. Dịch vụ giúp quản lý cấu hình cân bằng tải và chia tỷ lệ nhóm rất dễ dàng. Trong OpenShift, một dịch vụ là một đối tượng REST mà định danh của nó có thể được đăng lên apiService trên OpenShift master để tạo một phiên bản mới.

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

Công trình và Luồng

Công trình

Trong OpenShift, xây dựng là một quá trình chuyển đổi hình ảnh thành các vùng chứa. Đây là quá trình chuyển đổi mã nguồn thành hình ảnh. Quá trình xây dựng này hoạt động dựa trên chiến lược xây dựng mã nguồn thành hình ảnh được xác định trước.

Quá trình xây dựng nhiều chiến lược và nguồn.

Xây dựng chiến lược

• Source to Image – Về cơ bản, đây là một công cụ giúp xây dựng hình ảnh có thể tái tạo. Những hình ảnh này luôn trong giai đoạn sẵn sàng để chạy bằng lệnh Docker run.
• Docker Build – Đây là quá trình trong đó hình ảnh được tạo bằng cách sử dụng tệp Docker bằng cách chạy lệnh xây dựng Docker đơn giản.
• Bản dựng tùy chỉnh – Đây là các bản dựng được sử dụng để tạo hình ảnh Docker cơ bản.

Tạo nguồn

Git – Nguồn này được sử dụng khi kho lưu trữ git được sử dụng để xây dựng hình ảnh. Dockerfile là tùy chọn. Các cấu hình từ mã nguồn trông giống như sau.

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 được sử dụng làm đầu vào trong tệp cấu hình.

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

Luồng hình ảnh – Luồng hình ảnh được tạo sau khi kéo hình ảnh. Ưu điểm của luồng hình ảnh là nó tìm kiếm các cập nhật về phiên bản mới của hình ảnh. Điều này được sử dụng để so sánh bất kỳ số lượng hình ảnh vùng chứa có định dạng Docker nào được xác định bằng thẻ. Luồng hình ảnh có thể tự động thực hiện một hành động khi một hình ảnh mới được tạo. Tất cả các bản dựng và triển khai có thể theo dõi hành động của hình ảnh và thực hiện một hành động cho phù hợp. Sau đây là cách chúng tôi xác định một luồng xây dựng.

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

Định tuyến và Mẫu

Các tuyến đường

Trong OpenShift, định tuyến là một phương pháp hiển thị dịch vụ với thế giới bên ngoài bằng cách tạo và định cấu hình tên máy chủ có thể truy cập bên ngoài. Các tuyến và điểm cuối được sử dụng để hiển thị dịch vụ với thế giới bên ngoài, từ đó người dùng có thể sử dụng kết nối tên (DNS) để truy cập ứng dụng đã xác định.

Trong OpenShift, các tuyến được tạo bằng cách sử dụng các bộ định tuyến được triển khai bởi quản trị viên OpenShift trên cụm. Bộ định tuyến được sử dụng để liên kết các cổng HTTP (80) và https (443) với các ứng dụng bên ngoài.

Sau đây là các loại giao thức khác nhau được hỗ trợ bởi các tuyến đường:

• HTTP
• HTTPS
• TSL và ổ cắm web

Khi định cấu hình dịch vụ, các bộ chọn được sử dụng để định cấu hình dịch vụ và tìm điểm cuối bằng dịch vụ đó. Sau đây là một ví dụ về cách chúng tôi tạo một dịch vụ và định tuyến cho dịch vụ đó bằng cách sử dụng một giao thức thích hợp.

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

Tiếp theo, chạy lệnh sau và dịch vụ được tạo.

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

Đây là cách dịch vụ trông như thế nào sau khi tạo.

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

Tạo một định tuyến cho dịch vụ bằng cách sử dụng mã sau.

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

Khi lệnh OC được sử dụng để tạo một tuyến, một thể hiện mới của tài nguyên tuyến sẽ được tạo.

Mẫu

Các mẫu được định nghĩa là một đối tượng tiêu chuẩn trong OpenShift có thể được sử dụng nhiều lần. Nó được tham số hóa với danh sách các trình giữ chỗ được sử dụng để tạo nhiều đối tượng. Điều này có thể được sử dụng để tạo bất kỳ thứ gì, bắt đầu từ nhóm đến mạng mà người dùng có quyền tạo. Danh sách các đối tượng có thể được tạo, nếu mẫu từ giao diện CLI hoặc GUI trong hình ảnh được tải lên thư mục dự án.

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>

Xác thực và Ủy quyền

Xác thực

Trong OpenShift, trong khi định cấu hình chính và cấu trúc máy khách, chủ đưa ra một tính năng có sẵn của máy chủ OAuth. Máy chủ OAuth được sử dụng để tạo mã thông báo, được sử dụng để xác thực API. Vì OAuth xuất hiện như một thiết lập mặc định cho chính, chúng tôi có sử dụng Cho phép tất cả nhà cung cấp danh tính theo mặc định. Có các nhà cung cấp danh tính khác nhau có thể được định cấu hình tại /etc/openshift/master/master-config.yaml .

Có nhiều loại nhà cung cấp danh tính khác nhau hiện diện trong OAuth.

• Chấp nhận tất cả
• Phủ nhận tất cả
• HTPasswd
• LDAP
• Xác thực cơ bản

Chấp nhận tất cả

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

Phủ nhận tất cả

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

Để sử dụng HTPasswd, trước tiên chúng ta cần thiết lập Httpd-tools trên máy chủ và sau đó cấu hình nó theo cách tương tự như chúng ta đã làm cho những người khác.

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

Ủy quyền

Ủy quyền là một tính năng của OpenShift master, được sử dụng để xác nhận việc xác thực người dùng. Điều này có nghĩa là nó kiểm tra người dùng đang cố gắng thực hiện một hành động để xem liệu người dùng có được ủy quyền để thực hiện hành động đó trên một dự án nhất định hay không. Điều này giúp quản trị viên kiểm soát quyền truy cập vào các dự án.

Chính sách ủy quyền được kiểm soát bằng cách sử dụng –

• Quy tắc
• Vai trò
• Ràng buộc

Đánh giá ủy quyền được thực hiện bằng cách sử dụng –

• Danh tính
• Hoạt động
• Ràng buộc

Sử dụng chính sách –

• Chính sách cụm
• Chính sách địa phương

OpenShift – Bắt đầu (xem thêm)