• Ràng buộc về ngữ cảnh bảo mật (SCC)
• Tài khoản dịch vụ

Ràng buộc về ngữ cảnh bảo mật (SCC)

Về cơ bản, nó được sử dụng để hạn chế nhóm, có nghĩa là nó xác định các giới hạn cho nhóm, như những hành động mà nó có thể thực hiện và tất cả những thứ nó có thể truy cập trong cụm. OpenShift cung cấp một tập hợp SCC được xác định trước có thể được quản trị viên sử dụng, sửa đổi và mở rộng.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

Nếu một người muốn sử dụng bất kỳ scc nào được xác định trước, điều đó có thể được thực hiện bằng cách chỉ cần thêm người dùng hoặc nhóm vào nhóm scc.

$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>

Tài khoản dịch vụ

Tài khoản dịch vụ về cơ bản được sử dụng để kiểm soát quyền truy cập vào API chính OpenShift, được gọi khi lệnh hoặc yêu cầu được kích hoạt từ bất kỳ máy chủ hoặc máy nút nào. Bất kỳ lúc nào một ứng dụng hoặc một quy trình yêu cầu khả năng không được cấp bởi SCC hạn chế, bạn sẽ phải tạo một tài khoản dịch vụ cụ thể và thêm tài khoản vào SCC tương ứng. Tuy nhiên, nếu một SCC không phù hợp với yêu cầu của bạn, thì tốt hơn là tạo một SCC mới cụ thể cho yêu cầu của bạn hơn là sử dụng một SCC phù hợp nhất. Cuối cùng, hãy đặt nó cho cấu hình triển khai.

$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin

An ninh vùng chứa

Trong OpenShift, bảo mật của các vùng chứa dựa trên khái niệm về mức độ an toàn của nền tảng vùng chứa và các vùng chứa đang chạy ở đâu. Có rất nhiều điều xuất hiện khi chúng ta nói về an ninh vùng chứa và những gì cần được quan tâm.

Image Provenance – Hệ thống ghi nhãn an toàn được thiết lập để xác định chính xác và không thể kiểm soát được nguồn gốc của các thùng chứa chạy trong môi trường sản xuất.

Quét bảo mật – Máy quét hình ảnh tự động kiểm tra tất cả các hình ảnh để tìm các lỗ hổng đã biết.

Kiểm toán – Môi trường sản xuất thường xuyên được kiểm tra để đảm bảo tất cả các thùng chứa đều dựa trên các thùng chứa cập nhật và cả máy chủ và thùng chứa đều được định cấu hình an toàn.

Cách ly và Đặc quyền Ít nhất – Các vùng chứa chạy với các tài nguyên và đặc quyền tối thiểu cần thiết để hoạt động hiệu quả. Chúng không thể can thiệp quá mức vào máy chủ hoặc các vùng chứa khác.

Runtime Threat Detection – Một khả năng phát hiện các mối đe dọa đang hoạt động chống lại ứng dụng được chứa trong thời gian chạy và tự động phản hồi nó.

Kiểm soát truy cập – Các mô-đun bảo mật của Linux, chẳng hạn như AppArmor hoặc SELinux, được sử dụng để thực thi các kiểm soát truy cập.

Có một số phương pháp chính để lưu trữ bảo mật vùng chứa.

• Kiểm soát quyền truy cập qua oAuth
• Qua bảng điều khiển web tự phục vụ
• Bằng chứng nhận của nền tảng

Kiểm soát quyền truy cập qua OAuth

Trong phương pháp này, xác thực đối với quyền truy cập điều khiển API được lưu trữ bằng cách nhận mã thông báo bảo mật để xác thực thông qua máy chủ OAuth, có sẵn trong máy chủ OpenShift. Với tư cách là quản trị viên, bạn có khả năng sửa đổi cấu hình cấu hình máy chủ OAuth.

Để biết thêm chi tiết về cấu hình máy chủ OAuth, hãy tham khảo Chương 5 của hướng dẫn này.

Qua Bảng điều khiển Web Tự phục vụ

Tính năng bảo mật bảng điều khiển web này được tích hợp sẵn trong bảng điều khiển web OpenShift. Bảng điều khiển này đảm bảo rằng tất cả các nhóm làm việc cùng nhau không có quyền truy cập vào các môi trường khác mà không có xác thực. Master multi-telnet trong OpenShift có các tính năng bảo mật sau:

• Lớp TCL được bật
• Sử dụng chứng chỉ x.509 để xác thực
• Bảo mật cấu hình etcd trên máy chủ

Bằng chứng nhận của nền tảng

Trong phương pháp này, các chứng chỉ cho từng máy chủ được cấu hình trong quá trình cài đặt thông qua Ansible. Vì nó sử dụng giao thức truyền thông HTTPS thông qua Rest API, chúng tôi cần kết nối bảo mật TCL với các thành phần và đối tượng khác nhau. Đây là những chứng chỉ được xác định trước, tuy nhiên, người ta thậm chí có thể cài đặt chứng chỉ tùy chỉnh trên cluster master để truy cập. Trong quá trình thiết lập ban đầu của cái chính, các chứng chỉ tùy chỉnh có thể được định cấu hình bằng cách ghi đè các chứng chỉ hiện có bằng cách sử dụng thông số openshift_master_overwrite_name_certificates .Thí dụ

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Để biết thêm chi tiết về cách tạo chứng chỉ tùy chỉnh, hãy truy cập liên kết sau:

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

An ninh mạng

Trong OpenShift, Mạng do Phần mềm Xác định (SDN) được sử dụng để liên lạc. Không gian tên mạng được sử dụng cho mỗi nhóm trong cụm, trong đó mỗi nhóm có IP riêng và một loạt các cổng để nhận lưu lượng mạng trên đó. Bằng phương pháp này, người ta có thể cô lập các nhóm vì nó không thể giao tiếp với các nhóm trong dự án khác.

Cô lập một dự án

Điều này có thể được thực hiện bởi quản trị viên cụm bằng cách sử dụng lệnh oadm sau đây từ CLI.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

Điều này có nghĩa là các dự án được xác định ở trên không thể giao tiếp với các dự án khác trong cụm.

Bảo mật số lượng

Bảo mật khối lượng rõ ràng có nghĩa là bảo mật PV và PVC của các dự án trong cụm OpenShift. Chủ yếu có bốn phần để kiểm soát quyền truy cập vào các ổ đĩa trong OpenShift.

• Nhóm bổ sung
• fsGroup
• runAsUser
• seLinuxOptions

Nhóm bổ sung – Nhóm bổ sung là các nhóm Linux thông thường. Khi một tiến trình chạy trong hệ thống, nó sẽ chạy với ID người dùng và ID nhóm. Các nhóm này được sử dụng để kiểm soát quyền truy cập vào bộ nhớ dùng chung. Kiểm tra gắn kết NFS bằng lệnh sau

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Kiểm tra chi tiết NFS trên máy chủ gắn kết bằng lệnh sau.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

Các / opt / nfs / xuất khẩu có thể truy cập bằng cách UID 454.265 và nhóm 2325 .

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup là viết tắt của nhóm hệ thống tệp được sử dụng để thêm các nhóm bổ sung vùng chứa. ID nhóm bổ sung được sử dụng để lưu trữ chia sẻ và fsGroup được sử dụng để lưu trữ khối.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser sử dụng ID người dùng để giao tiếp. Điều này được sử dụng để xác định hình ảnh vùng chứa trong định nghĩa nhóm. Một người dùng ID duy nhất có thể được sử dụng trong tất cả các vùng chứa, nếu được yêu cầu. Trong khi chạy vùng chứa, ID đã xác định được khớp với ID chủ sở hữu khi xuất. Nếu ID được chỉ định được xác định bên ngoài, thì nó sẽ trở thành chung cho tất cả các vùng chứa trong nhóm. Nếu nó được xác định với một nhóm cụ thể, thì nó sẽ trở thành cụ thể cho một vùng chứa duy nhất.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265

The post OpenShift – Bảo mật appeared first on Dongthoigian.net.

Sau đây là các loại tệp cấu hình khác nhau được sử dụng để tạo các loại đối tượng khác nhau trong cụm.

• Hình ảnh
• DƯỚI
• Dịch vụ
• Bộ điều khiển sao chép
• Bộ bản sao
• Triển khai

Hình ảnh

Hình ảnh Kubernetes (Docker) là các khối xây dựng chính của Cơ sở hạ tầng được chứa đựng. Hiện tại, Kubernetes chỉ hỗ trợ hình ảnh Docker . Mỗi vùng chứa trong một nhóm có hình ảnh Docker của nó chạy bên trong nó.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
   containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5

DƯỚI

Một nhóm là tập hợp các vùng chứa và bộ lưu trữ của nó bên trong một nút của một cụm Kubernetes. Có thể tạo một nhóm với nhiều vùng chứa bên trong nó. Sau đây là một ví dụ về việc giữ một vùng chứa cơ sở dữ liệu và vùng chứa giao diện web trong cùng một nhóm.

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

Dịch vụ

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ý. Nó có thể được định nghĩa là một phần trừu tượng trên đầu nhóm cung cấp một địa chỉ IP và tên DNS duy nhất mà các nhóm có thể được truy cập. Với Service, rất dễ dàng quản lý cấu hình cân bằng tải. Nó giúp POD mở rộng quy mô rất dễ dàng.

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

Bộ điều khiển sao chép

Bộ điều khiển nhân bản là một trong những tính năng chính của Kubernetes, chịu trách nhiệm quản lý vòng đời nhóm. Nó chịu trách nhiệm đảm bảo rằng số lượng bản sao nhóm được chỉ định đang chạy tại bất kỳ thời điểm nào.

apiVersion: v1
kind: ReplicationController
metadata:
   name: Tomcat-ReplicationController
spec:
   replicas: 3
   template:
   metadata:
      name: Tomcat-ReplicationController
   labels:
      app: App
      component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Bộ bản sao

Tập hợp bản sao đảm bảo có bao nhiêu bản sao của nhóm sẽ được chạy. Nó có thể được coi là một sự thay thế của bộ điều khiển nhân bản.

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
      tier: Backend
   matchExpression:
      - { key: tier, operation: In, values: [Backend]}
   
   app: App
   component: neo4j
spec:
   containers:
   - name: Tomcat-
image: tomcat: 8.0
   ports:
containerPort: 7474

Triển khai

Các triển khai được nâng cấp và các phiên bản cao hơn của bộ điều khiển nhân rộng. Họ quản lý việc triển khai các tập hợp bản sao, đây cũng là một phiên bản nâng cấp của bộ điều khiển nhân bản. Chúng có khả năng cập nhật tập hợp bản sao và chúng cũng có khả năng quay trở lại phiên bản trước đó.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
lables:
   app: Tomcat-ReplicaSet
   tier: Backend
spec:
   containers:
name: Tomcat-
   image: tomcat: 8.0
   ports:
   - containerPort: 7474

Tất cả các tệp cấu hình có thể được sử dụng để tạo các đối tượng Kubernetes tương ứng của chúng.

$ Kubectl create –f <file name>.yaml

Các lệnh sau có thể được sử dụng để biết chi tiết và mô tả của các đối tượng Kubernetes.

Đối với POD

$ Kubectl get pod <pod name>
$ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>

Đối với bộ điều khiển nhân rộng

$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name>
$ kubectl describe rc <rc name>

Đối với dịch vụ

$ Kubectl get svc <svc name>
$ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>

Để biết thêm chi tiết về cách làm việc với Docker và Kubernetes, vui lòng truy cập hướng dẫn Kubernetes của chúng tôi bằng cách sử dụng kubernetes liên kết sau .

OpenShift – Security

 Openshift Bảo mật Xem Thêm

The post OpenShift – Docker and Kubernetes appeared first on Dongthoigian.net.

Tỷ lệ theo chiều dọc

Chia tỷ lệ dọc là tất cả về việc tăng thêm ngày càng nhiều năng lượng cho một máy duy nhất, có nghĩa là thêm nhiều CPU và đĩa cứng. Đây là một phương pháp cũ của OpenShift hiện không được các bản phát hành OpenShift hỗ trợ.

Chia tỷ lệ ngang

Kiểu chia tỷ lệ này rất hữu ích khi có nhu cầu xử lý nhiều yêu cầu hơn bằng cách tăng số lượng máy.

Trong OpenShift, có hai phương pháp để bật tính năng mở rộng quy mô .

• Sử dụng tệp cấu hình triển khai
• Trong khi chạy hình ảnh

Sử dụng tệp cấu hình triển khai

Trong phương pháp này, tính năng chia tỷ lệ được bật thông qua tệp yaml cấu hình của người triển khai. Đối với điều này, lệnh OC tự động tỷ lệ được sử dụng với số lượng bản sao tối thiểu và tối đa, lệnh này cần chạy tại bất kỳ thời điểm nhất định nào trong cụm. Chúng ta cần một định nghĩa đối tượng để tạo autoscaler. Sau đây là một ví dụ về tệp định nghĩa pod autoscaler.

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

Khi chúng ta đã có tệp tại chỗ, chúng ta cần lưu nó với định dạng yaml và chạy lệnh sau để triển khai.

$ oc create –f <file name>.yaml

Trong khi chạy hình ảnh

Người ta cũng có thể chỉnh tỷ lệ tự động mà không cần tệp yaml, bằng cách sử dụng lệnh oc tự động tỷ lệ sau trong dòng lệnh oc.

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

Lệnh này cũng sẽ tạo ra một loại tệp tương tự mà sau này có thể được sử dụng để tham khảo.

Chiến lược triển khai trong OpenShift

Chiến lược triển khai trong OpenShift xác định luồng triển khai với các phương pháp có sẵn khác nhau. Trong OpenShift, sau đây là các loại chiến lược triển khai quan trọng .

• Chiến lược cuộn
• Tạo lại chiến lược
• Chiến lược tùy chỉnh

Sau đây là một ví dụ về tệp cấu hình triển khai, được sử dụng chủ yếu để triển khai trên các nút OpenShift.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

Trong tệp Deploymentconfig ở trên, chúng ta có chiến lược là Rolling.

Chúng ta có thể sử dụng lệnh OC sau để triển khai.

$ oc deploy <deployment_config> --latest

Chiến lược lăn bánh

Chiến lược cuộn được sử dụng để cập nhật hoặc triển khai luân phiên. Quá trình này cũng hỗ trợ các móc vòng đời, được sử dụng để đưa mã vào bất kỳ quá trình triển khai nào.

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

Tạo lại chiến lược

Chiến lược triển khai này có một số tính năng cơ bản của chiến lược triển khai cuốn chiếu và nó cũng hỗ trợ móc vòng đời.

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

Chiến lược tùy chỉnh

Điều này rất hữu ích khi một người muốn cung cấp quy trình hoặc luồng triển khai của riêng mình. Tất cả các tùy chỉnh có thể được thực hiện theo yêu cầu.

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1

OpenShift – Administration  Quản trị

Trong chương này, chúng tôi sẽ đề cập đến các chủ đề như cách quản lý một nút, cấu hình tài khoản dịch vụ, v.v.

Cấu hình chính và nút

Trong OpenShift, chúng ta cần sử dụng lệnh start cùng với OC để khởi động một máy chủ mới. Trong khi khởi chạy một cái chính mới, chúng ta cần sử dụng cái chính cùng với lệnh bắt đầu, trong khi khi khởi động nút mới, chúng ta cần sử dụng nút cùng với lệnh bắt đầu. Để làm được điều này, chúng ta cần tạo các tệp cấu hình cho cái chính cũng như cho các nút. Chúng ta có thể tạo một tệp cấu hình cơ bản cho nút chính và nút bằng cách sử dụng lệnh sau.

Đối với tệp cấu hình chính

$ openshift start master --write-config = /openshift.local.config/master

Đối với tệp cấu hình nút

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

Khi chúng tôi chạy các lệnh sau, chúng tôi sẽ nhận được các tệp cấu hình cơ sở có thể được sử dụng làm điểm bắt đầu cho cấu hình. Sau đó, chúng ta có thể có cùng một tệp để khởi động các máy chủ mới.

apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
   logoutURL: ""
   masterPublicURL: https://172.10.12.1:7449
   publicURL: https://172.10.2.2:7449/console/
      servingInfo:
         bindAddress: 0.0.0.0:7449
         certFile: master.server.crt
         clientCA: ""
keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
   bindAddress: 0.0.0.0:53
etcdClientInfo:
   ca: ca.crt
   certFile: master.etcd-client.crt
   keyFile: master.etcd-client.key
   urls:
   - https://10.0.2.15:4001
etcdConfig:
   address: 10.0.2.15:4001
   peerAddress: 10.0.2.15:7001
   peerServingInfo:
      bindAddress: 0.0.0.0:7001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   servingInfo:
      bindAddress: 0.0.0.0:4001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
   kubernetesStoragePrefix: kubernetes.io
   kubernetesStorageVersion: v1
   openShiftStoragePrefix: openshift.io
   openShiftStorageVersion: v1
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: MasterConfig
kubeletClientInfo:
   ca: ca.crt
   certFile: master.kubelet-client.crt
   keyFile: master.kubelet-client.key
   port: 10250
kubernetesMasterConfig:
   apiLevels:
   - v1beta3
   - v1
   apiServerArguments: null
   controllerArguments: null
   masterCount: 1
   masterIP: 10.0.2.15
   podEvictionTimeout: 5m
   schedulerConfigFile: ""
   servicesNodePortRange: 30000-32767
   servicesSubnet: 172.30.0.0/16
   staticNodeNames: []
masterClients:
   externalKubernetesKubeConfig: ""
   openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
   clusterNetworkCIDR: 10.1.0.0/16
   hostSubnetLength: 8
   networkPluginName: ""
   serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
   assetPublicURL: https://172.10.2.2:7449/console/
   grantConfig:
      method: auto
   identityProviders:
   - challenge: true
   login: true
   name: anypassword
   provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
   masterPublicURL: https://172.10.2.2:7449/
   masterURL: https://172.10.2.2:7449/
   sessionConfig:
      sessionMaxAgeSeconds: 300
      sessionName: ssn
      sessionSecretsFile: ""
   tokenConfig:
      accessTokenMaxAgeSeconds: 86400
      authorizeTokenMaxAgeSeconds: 300
policyConfig:
   bootstrapPolicyFile: policy.json
   openshiftInfrastructureNamespace: openshift-infra
   openshiftSharedResourcesNamespace: openshift
projectConfig:
   defaultNodeSelector: ""
   projectRequestMessage: ""
   projectRequestTemplate: ""
   securityAllocator:
      mcsAllocatorRange: s0:/2
      mcsLabelsPerProject: 5
      uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
   subdomain: router.default.svc.cluster.local
serviceAccountConfig:
   managedNames:
   - default
   - builder
   - deployer
   
masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
servingInfo:
   bindAddress: 0.0.0.0:8443
   certFile: master.server.crt
   clientCA: ca.crt
   keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 3600

Tệp cấu hình nút

allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
   execHandlerName: native
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
   mtu: 1450
   networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com

podManifestConfig:
   path: "/path/to/pod-manifest-file"
   fileCheckIntervalSeconds: 30
servingInfo:
   bindAddress: 0.0.0.0:10250
   certFile: server.crt
   clientCA: node-client-ca.crt
   keyFile: server.key
volumeDirectory: /root/openshift.local.volumes

Đây là cách các tệp cấu hình nút trông như thế nào. Khi chúng ta đã có các tệp cấu hình này, chúng ta có thể chạy lệnh sau để tạo máy chủ chính và máy chủ nút.

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

Quản lý các nút

Trong OpenShift, chúng ta có tiện ích dòng lệnh OC, tiện ích này chủ yếu được sử dụng để thực hiện tất cả các hoạt động trong OpenShift. Chúng ta có thể sử dụng các lệnh sau để quản lý các nút.

Để liệt kê một nút

$ oc get nodes
NAME                             LABELS
node1.example.com     kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com     kubernetes.io/hostname = vklnld1447.int.example.com

Mô tả chi tiết về một nút

$ oc describe node <node name>

Xóa một nút

$ oc delete node <node name>

Liệt kê các nhóm trên một nút

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

Đánh giá nhóm trên một nút

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Xác thực cấu hình

Trong OpenShift master, có một máy chủ OAuth tích hợp, có thể được sử dụng để quản lý xác thực. Tất cả người dùng OpenShift đều nhận được mã thông báo từ máy chủ này, giúp họ giao tiếp với API OpenShift.

Có nhiều loại cấp độ xác thực khác nhau trong OpenShift, có thể được định cấu hình cùng với tệp cấu hình chính.

• Chấp nhận tất cả
• Phủ nhận tất cả
• HTPasswd
• LDAP
• Xác thực cơ bản
• Tiêu đề yêu cầu

Trong khi xác định cấu hình chính, chúng ta có thể xác định chính sách nhận dạng nơi chúng ta có thể xác định loại chính sách mà chúng ta muốn sử dụng.

Chấp nhận tất cả

Chấp nhận tất cả

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Phủ nhận tất cả

Điều này sẽ từ chối quyền truy cập vào tất cả tên người dùng và mật khẩu.

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd được sử dụng để xác thực tên người dùng và mật khẩu so với mật khẩu tệp được mã hóa.

Để tạo một tệp được mã hóa, sau đây là lệnh.

$ htpasswd </path/to/users.htpasswd> <user_name>

Sử dụng tệp được mã hóa.

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

Nhà cung cấp danh tính LDAP

Điều này được sử dụng để xác thực LDAP trong đó máy chủ LDAP đóng một vai trò quan trọng trong xác thực.

oauthConfig:
   ...
   identityProviders:
   - name: "ldap_authontication"
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: LDAPPasswordIdentityProvider
         attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
         bindDN: ""
         bindPassword: ""
         ca: my-ldap-ca-bundle.crt
         insecure: false
         url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"

Xác thực cơ bản

Điều này được sử dụng khi xác thực tên người dùng và mật khẩu được thực hiện dựa trên xác thực từ máy chủ đến máy chủ. Xác thực được bảo vệ trong URL cơ sở và được trình bày ở định dạng JSON.

oauthConfig:
   ...
   identityProviders:
   - name: my_remote_basic_auth_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: BasicAuthPasswordIdentityProvider
         url: https://www.vklnld908.int.example.com/remote-idp
         ca: /path/to/ca.file
         certFile: /path/to/client.crt
         keyFile: /path/to/client.key

Định cấu hình tài khoản dịch vụ

Tài khoản dịch vụ cung cấp một cách linh hoạt để truy cập API OpenShift, làm lộ tên người dùng và mật khẩu để xác thực.

Kích hoạt tài khoản dịch vụ

Tài khoản dịch vụ sử dụng một cặp khóa công khai và khóa riêng tư để xác thực. Xác thực API được thực hiện bằng cách sử dụng khóa riêng tư và xác thực nó dựa trên khóa công khai.

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
- ...

Tạo tài khoản dịch vụ

Sử dụng lệnh sau để tạo tài khoản dịch vụ

$ Openshift cli create service account <name of server account>

Làm việc với HTTP Proxy

Trong hầu hết các môi trường sản xuất, truy cập trực tiếp vào Internet bị hạn chế. Chúng không được tiếp xúc với Internet hoặc chúng được hiển thị qua proxy HTTP hoặc HTTPS. Trong môi trường OpenShift, định nghĩa máy proxy này được đặt làm biến môi trường.

Điều này có thể được thực hiện bằng cách thêm định nghĩa proxy trên tệp chính và tệp nút nằm trong / etc / sysconfig . Điều này tương tự như chúng tôi làm đối với bất kỳ ứng dụng nào khác.

Máy chủ

/ etc / sysconfig / openshift-master
HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/
HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/
NO_PROXY=master.vklnld908.int.example.com

Máy nút

/ etc / sysconfig / openshift-node
HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/
HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/
NO_PROXY=master.vklnld908.int.example.com

Sau khi thực hiện xong, chúng ta cần khởi động lại máy chủ và máy nút.Đối với Docker Pull

/ etc / sysconfig / docker
HTTP_PROXY = http://USERNAME:PASSWORD@172.10.10.1:8080/
HTTPS_PROXY = https://USERNAME:PASSWORD@172.10.10.1:8080/
NO_PROXY = master.vklnld1446.int.example.com

Để làm cho một nhóm chạy trong môi trường proxy, nó có thể được thực hiện bằng cách sử dụng:

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

Lệnh OC môi trường có thể được sử dụng để cập nhật env hiện có.

OpenShift Storage với NFS

Trong OpenShift, khái niệm khối lượng liên tục và yêu cầu khối lượng liên tục tạo thành bộ nhớ liên tục. Đây là một trong những khái niệm chính trong đó tập liên tục đầu tiên được tạo ra và sau đó là tập tương tự được xác nhận. Đối với điều này, chúng ta cần có đủ dung lượng và không gian đĩa trên phần cứng bên dưới.

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

Tiếp theo, sử dụng lệnh OC create, tạo Ổ đĩa liên tục.

$ oc create -f storage-unit1.yaml

Yêu cầu khối lượng đã tạo.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

Tạo xác nhận quyền sở hữu

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

Quản lý Người dùng và Vai trò

Quản trị vai trò và người dùng được sử dụng để quản lý người dùng, quyền truy cập và kiểm soát của họ trên các dự án khác nhau.

Tạo người dùng

Các mẫu được xác định trước có thể được sử dụng để tạo người dùng mới trong OpenShift.

kind: "Template"
apiVersion: "v1"
parameters:
   - name: vipin
   required: true
objects:
   - kind: "User"
   apiVersion: "v1"
   metadata:
   name: "${email}"
   
- kind: "Identity"
   apiVersion: "v1"
   metadata:
      name: "vipin:${email}"
   providerName: "SAML"
   providerUserName: "${email}"
- kind: "UserIdentityMapping"
apiVersion: "v1"
identity:
   name: "vipin:${email}"
user:
   name: "${email}"

Sử dụng oc create –f <tên tệp> để tạo người dùng

$ oc create –f vipin.yaml

Sử dụng lệnh sau để xóa người dùng trong OpenShift.

$ oc delete user <user name>

Giới hạn quyền truy cập của người dùng

ResourceQuotas và LimitRanges được sử dụng để giới hạn mức độ truy cập của người dùng. Chúng được sử dụng để giới hạn các vỏ và thùng chứa trên cụm.

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

Tạo báo giá bằng cách sử dụng cấu hình trên

$ oc create -f resource-quota.yaml –n –Openshift-sample

Mô tả báo giá tài nguyên

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

Việc xác định giới hạn vùng chứa có thể được sử dụng để giới hạn tài nguyên sẽ được sử dụng bởi các vùng chứa đã triển khai. Chúng được sử dụng để xác định các giới hạn tối đa và tối thiểu của các đối tượng nhất định.

Giới hạn dự án của người dùng

Điều này về cơ bản được sử dụng cho số lượng dự án mà người dùng có thể có tại bất kỳ thời điểm nào. Về cơ bản, chúng được thực hiện bằng cách xác định cấp độ người dùng trong các danh mục đồng, bạc và vàng. Trước tiên, chúng ta cần xác định một đối tượng có giá trị bao nhiêu dự án mà một loại đồng, bạc và vàng có thể có. Chúng cần được thực hiện trong tệp master-confif.yaml.

admissionConfig:
   pluginConfig:
      ProjectRequestLimit:
         configuration:
            apiVersion: v1
            kind: ProjectRequestLimitConfig
            limits:
            - selector:
               level: platinum
            - selector:
               level: gold
            maxProjects: 15
            - selector:
               level: silver
            maxProjects: 10
            - selector:
               level: bronze
            maxProjects: 5

Khởi động lại máy chủ chính.

Chỉ định người dùng cho một cấp cụ thể.

$ oc label user vipin level = gold

Di chuyển người dùng ra khỏi nhãn, nếu được yêu cầu.

$ oc label user <user_name> level-

Thêm vai trò cho người dùng.

$ oadm policy add-role-to-user  <user_name>

Xóa vai trò khỏi người dùng.

$ oadm policy remove-role-from-user  <user_name>

Thêm vai trò cụm cho người dùng

$ oadm policy add-cluster-role-to-user  <user_name>

Xóa vai trò cụm khỏi người dùng.

$ oadm policy remove-cluster-role-from-user  <user_name>

Thêm một vai trò vào một nhóm.

$ oadm policy add-role-to-user  <user_name>

Xóa vai trò khỏi nhóm.

$ oadm policy remove-cluster-role-from-user  <user_name>

Thêm vai trò cụm vào một nhóm.

$ oadm policy add-cluster-role-to-group  <groupname>

Xóa vai trò cụm khỏi một nhóm.

$ oadm policy remove-cluster-role-from-group <role> <groupname>

Người dùng quản trị cụm

Đây là một trong những vai trò mạnh mẽ nhất mà người dùng có khả năng quản lý một cụm hoàn chỉnh bắt đầu từ khi tạo cho đến khi xóa một cụm.

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

Người dùng có sức mạnh tối thượng

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>

OpenShift – Docker and Kubernetes (xem thêm)

The post OpenShift – Mở rộng quy mô ứng dụng appeared first on Dongthoigian.net.

Chúng tôi có thể thực hiện các loại hoạt động khác nhau bằng cách sử dụng các lệnh OC. Ứng dụng khách này giúp bạn phát triển, xây dựng, triển khai và chạy các ứng dụng của mình trên bất kỳ nền tảng tương thích OpenShift hoặc Kubernetes nào. Nó cũng bao gồm các lệnh quản trị để quản lý một cụm trong lệnh con ‘adm’.

Các lệnh cơ bản

Bảng sau liệt kê các lệnh OC cơ bản.

Đăng nhập

Đăng nhập vào máy chủ của bạn và lưu thông tin đăng nhập để sử dụng tiếp theo. Người dùng lần đầu tiên của máy khách nên chạy lệnh này để kết nối với máy chủ, thiết lập phiên được xác thực và lưu kết nối vào tệp cấu hình. Cấu hình mặc định sẽ được lưu vào thư mục chính của bạn trong “.kube / config”.

Thông tin cần thiết để đăng nhập – như tên người dùng và mật khẩu, mã thông báo phiên hoặc chi tiết máy chủ có thể được cung cấp thông qua cờ. Nếu không được cung cấp, lệnh sẽ nhắc người dùng nhập khi cần.

Sử dụng

oc login [URL] [options]

Thí dụ

# Log in interactively
oc login

# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority = /path/to/cert.crt

# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypass

Tùy chọn

-p, –password = “ – Mật khẩu, sẽ nhắc nếu không được cung cấp

-u, –username = “ – Tên người dùng, sẽ nhắc nếu không được cung cấp

–certificate-Authority = “ – Đường dẫn đến tệp cert. cho tổ chức phát hành chứng chỉ

–insecure-ignore-tls-verify = false – Nếu đúng, chứng chỉ của máy chủ sẽ không được kiểm tra tính hợp lệ. Điều này sẽ làm cho các kết nối HTTPS của bạn không an toàn

–token = “ – Mã thông báo mang để xác thực máy chủ API

Để biết chi tiết đầy đủ về bất kỳ lệnh nào, hãy sử dụng lệnh oc <Tên lệnh> –help .

Xây dựng và triển khai lệnh

Bảng sau liệt kê các lệnh xây dựng và triển khai.

Lệnh quản lý ứng dụng

Bảng sau liệt kê các lệnh quản lý ứng dụng.

Các lệnh khắc phục sự cố và gỡ lỗi

Bảng sau liệt kê các lệnh khắc phục sự cố và gỡ lỗi.

Lệnh nâng cao

Bảng sau liệt kê các lệnh nâng cao.

Đặt lệnh

Bảng sau liệt kê các lệnh cài đặt.

OpenShift – Clusters

OpenShift sử dụng hai phương pháp cài đặt để thiết lập cụm OpenShift.

• Phương pháp cài đặt nhanh chóng
• Phương pháp cấu hình nâng cao

Thiết lập cụm

Phương pháp cài đặt nhanh

Phương pháp này được sử dụng để chạy cấu hình thiết lập cụm nhanh chóng. Để sử dụng phương pháp này, trước tiên chúng ta cần cài đặt trình cài đặt. Điều này có thể được thực hiện bằng cách chạy lệnh sau.

Phương pháp tương tác

$ atomic-openshift-installer install

Điều này rất hữu ích khi một người muốn chạy một thiết lập tương tác.

Phương pháp cài đặt không cần giám sát Phương pháp này được sử dụng khi một người muốn thiết lập một phương thức cài đặt không cần giám sát, trong đó người dùng có thể xác định một tệp yaml cấu hình và đặt nó dưới ~ / .config / openshift / với tên là installer.cfg.yml. Sau đó, có thể chạy lệnh sau để cài đặt thẻ –u

$ atomic-openshift-installer –u install

Theo mặc định, nó sử dụng tệp cấu hình nằm dưới ~ / .config / openshift / . Mặt khác, Ansible được sử dụng như một bản sao lưu cài đặt.

version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log

deployment:
   ansible_ssh_user: root
   hosts:
   - ip: 172.10.10.1
   hostname: vklnld908.int.example.com
   public_ip: 24.222.0.1
   public_hostname: master.example.com
   roles:
      - master
      - node
   containerized: true
   connect_to: 24.222.0.1
   
   - ip: 172.10.10.2
   hostname: vklnld1446.int.example.com
   public_ip: 24.222.0.2
   public_hostname: node1.example.com
   roles:
      - node
   connect_to: 10.0.0.2
   
   - ip: 172.10.10.3
   hostname: vklnld1447.int.example.com
   public_ip: 10..22.2.3
   public_hostname: node2.example.com
   roles:
      - node
   connect_to: 10.0.0.3

roles:
   master:
      <variable_name1>: "<value1>"
      <variable_name2>: "<value2>"
   node:
      <variable_name1>: "<value1>"

Ở đây, chúng ta có một biến cụ thể theo vai trò, có thể được xác định nếu một người muốn thiết lập một số biến cụ thể. Sau khi hoàn tất, chúng ta có thể xác minh cài đặt bằng lệnh sau.

$ oc get nodes
NAME                    STATUS    AGE
master.example.com      Ready     10d
node1.example.com       Ready     10d
node2.example.com       Ready     10d

Cài đặt nâng cao

Cài đặt nâng cao hoàn toàn dựa trên cấu hình Ansible, trong đó cấu hình máy chủ hoàn chỉnh và định nghĩa các biến liên quan đến cấu hình chính và nút có sẵn. Điều này chứa tất cả các chi tiết liên quan đến cấu hình.

Khi chúng tôi đã thiết lập xong và playbook đã sẵn sàng, chúng tôi có thể chỉ cần chạy lệnh sau để thiết lập cụm.

$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml

Thêm máy chủ vào một cụm

Chúng ta có thể thêm một máy chủ vào cụm bằng cách sử dụng –

• Công cụ cài đặt nhanh
• Phương pháp cấu hình nâng cao

Công cụ cài đặt nhanh hoạt động ở cả chế độ tương tác và không tương tác. Sử dụng lệnh sau

$ atomic-openshift-installer -u -c </path/to/file> scaleup

Định dạng chia tỷ lệ giao diện tệp cấu hình ứng dụng có thể được sử dụng để thêm cả nút chính cũng như nút.

Phương pháp cấu hình nâng cao

Trong phương pháp này, chúng tôi cập nhật tệp máy chủ của Ansible và sau đó thêm một nút hoặc chi tiết máy chủ mới trong tệp này. Tệp cấu hình trông giống như sau.

[OSEv3:children]
masters
nodes
new_nodes
new_master

Trong cùng một tệp máy chủ Ansible, hãy thêm các chi tiết biến liên quan đến nút mới như được hiển thị bên dưới.

[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"

Cuối cùng, sử dụng tệp máy chủ đã cập nhật, chạy cấu hình mới và gọi tệp cấu hình để hoàn tất thiết lập bằng lệnh sau

$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml

Quản lý nhật ký cụm

Nhật ký cụm OpenShift không là gì ngoài các nhật ký được tạo từ máy chủ và máy nút của cụm. Chúng có thể quản lý bất kỳ loại nhật ký nào, bắt đầu từ nhật ký máy chủ, nhật ký chính, nhật ký vùng chứa, nhật ký nhóm, v.v. Có nhiều công nghệ và ứng dụng hiện có để quản lý nhật ký vùng chứa.

Một số công cụ như được liệt kê có thể được triển khai để quản lý nhật ký.

• Fluentd
• ELK
• Kabna
• Nagios
• Splunk

Ngăn xếp ELK – Ngăn xếp này hữu ích khi cố gắng thu thập nhật ký từ tất cả các nút và trình bày chúng ở định dạng có hệ thống. Ngăn xếp ELK chủ yếu được chia thành ba loại chính.

ElasticSearch – Chủ yếu có trách nhiệm thu thập thông tin từ tất cả các vùng chứa và đưa nó vào vị trí trung tâm.

Fluentd – Được sử dụng để cung cấp các bản ghi đã thu thập vào động cơ chứa co giãn tìm kiếm.

Kibana – Giao diện đồ họa được sử dụng để trình bày dữ liệu thu thập được dưới dạng thông tin hữu ích trong giao diện đồ họa.

Một điểm chính cần lưu ý là, khi hệ thống này được triển khai trên cụm, nó bắt đầu thu thập nhật ký từ tất cả các nút.

Chẩn đoán nhật ký

OpenShift có một lệnh số hóa oc adm có sẵn với OC có thể được sử dụng để phân tích nhiều tình huống lỗi. Công cụ này có thể được sử dụng từ chính với tư cách là quản trị viên cụm. Tiện ích này rất hữu ích trong việc khắc phục sự cố và xác định các vấn đề đã biết. Điều này chạy trên máy khách chính và các nút.

Nếu chạy mà không có bất kỳ agruments hoặc cờ nào, nó sẽ tìm kiếm các tệp cấu hình của máy khách, máy chủ và nút machnies và sử dụng chúng để chẩn đoán. Người ta có thể chạy chẩn đoán riêng lẻ bằng cách chuyển các đối số sau:

• AggregatedLogging
• AnalyzeLogs
• ClusterRegistry
• ClusterRoleBindings
• ClusterRoles
• ClusterRouter
• ConfigContexts
• DiagnosticPod
• MasterConfigCheck
• MasterNode
• MetricsApiProxy
• Kiểm tra mạng
• NodeConfigCheck
• NodeDefinitions
• ServiceExternalIPs
• UnitStatus

Người ta có thể đơn giản chạy chúng bằng lệnh sau.

$ oc adm diagnostics <DiagnosticName>

Nâng cấp một cụm

Nâng cấp cụm liên quan đến việc nâng cấp nhiều thứ bên trong cụm và định vị địa lý cho cụm được cập nhật với các thành phần và gói nâng cấp mới. Điều này liên quan đến –

• Nâng cấp các thành phần chính
• Nâng cấp các thành phần nút
• Nâng cấp các chính sách
• Nâng cấp các tuyến đường
• Nâng cấp luồng hình ảnh

Để thực hiện tất cả các nâng cấp này, trước tiên chúng ta cần phải có các trình cài đặt nhanh hoặc các utils tại chỗ. Để làm được điều đó, chúng tôi cần cập nhật các tiện ích sau:

• nguyên tử-openshift-utils
• nguyên tử-openshift-loại trừ
• nguyên tử-openshift-docker-loại trừ
• gói etcd

Trước khi bắt đầu nâng cấp, chúng ta cần sao lưu etcd trên máy chủ, có thể thực hiện bằng các lệnh sau.

$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd
$ etcdctl backup \
   --data-dir $ETCD_DATA_DIR \
   --backup-dir $ETCD_DATA_DIR.bak.<date>

Nâng cấp các thành phần chính

Trong OpenShift master, chúng tôi bắt đầu nâng cấp bằng cách cập nhật tệp etcd và sau đó chuyển sang Docker. Cuối cùng, chúng tôi chạy trình thực thi tự động để đưa cụm vào vị trí cần thiết. Tuy nhiên, trước khi bắt đầu nâng cấp, trước tiên chúng ta cần kích hoạt các gói openshift nguyên tử trên mỗi bản chính. Điều này có thể được thực hiện bằng cách sử dụng các lệnh sau.

Bước 1 – Loại bỏ các gói mở nguyên tử

$ atomic-openshift-excluder unexclude

Bước 2 – Nâng cấp etcd trên tất cả các bản chính.

$ yum update etcd

Bước 3 – Khởi động lại dịch vụ của etcd và kiểm tra xem nó đã bắt đầu thành công chưa.

$ systemctl restart etcd
$ journalctl -r -u etcd

Bước 4 – Nâng cấp gói Docker

$ yum update docker

Bước 5 – Khởi động lại dịch vụ Docker và kiểm tra xem nó đã được khởi động chính xác chưa.

$ systemctl restart docker
$ journalctl -r -u docker

Bước 6 – Sau khi hoàn tất, khởi động lại hệ thống bằng các lệnh sau.

$ systemctl reboot
$ journalctl -r -u docker

Bước 7 – Cuối cùng, chạy trình thực thi nguyên tử để đưa các gói trở lại danh sách loại trừ yum.

$ atomic-openshift-excluder exclude

Không có sự bắt buộc nào như vậy đối với việc nâng cấp chính sách, nó chỉ cần được nâng cấp nếu được khuyến nghị, có thể kiểm tra bằng lệnh sau.

$ oadm policy reconcile-cluster-roles

Trong hầu hết các trường hợp, chúng tôi không cần cập nhật định nghĩa chính sách.

Nâng cấp các thành phần nút

Sau khi cập nhật chính hoàn tất, chúng tôi có thể bắt đầu nâng cấp các nút. Một điều cần lưu ý là thời gian nâng cấp phải ngắn để tránh bất kỳ loại vấn đề nào trong cụm.

Bước 1 – Xóa tất cả các gói OpenShift nguyên tử khỏi tất cả các nút mà bạn muốn thực hiện nâng cấp.

$ atomic-openshift-excluder unexclude

Bước 2 – Tiếp theo, tắt lập lịch nút trước khi nâng cấp.

$ oadm manage-node <node name> --schedulable = false

Bước 3 – Sao chép tất cả các nút từ máy chủ hiện tại sang máy chủ khác.

$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets

Bước 4 – Nâng cấp thiết lập Docker trên máy chủ.

$ yum update docker

Bước 5 – Khởi động lại dịch vụ Docker và sau đó khởi động nút dịch vụ Docke

$systemctl restart docker
$ systemctl restart atomic-openshift-node

Bước 6 – Kiểm tra xem cả hai đều đã khởi động chính xác chưa.

$ journalctl -r -u atomic-openshift-node

Bước 7 – Sau khi nâng cấp xong, khởi động lại máy nút.

$ systemctl reboot
$ journalctl -r -u docker

Bước 8 – Bật lại lập lịch trên các nút.

$ oadm manage-node <node> --schedulable.

Bước 9 – Chạy trình thực thi nguyên tử-openshift để lấy lại gói OpenShift trên nút.

$ atomic-openshift-excluder exclude

Bước 10 – Cuối cùng, kiểm tra xem tất cả các nút có sẵn hay không.

$ oc get nodes

NAME                 STATUS   AGE
master.example.com   Ready    12d
node1.example.com    Ready    12d
node2.example.com    Ready    12d

OpenShift – Mở rộng quy mô ứng dụng (xem thêm)

The post OpenShift – Hoạt động CLI appeared first on Dongthoigian.net.

Trong OpenShift, chúng tôi có nhiều phương pháp tự động hóa quá trình xây dựng. Để làm được điều đó, chúng ta cần tạo tài nguyên BuildConfig để mô tả luồng xây dựng. Luồng trong BuildConfig có thể được so sánh với định nghĩa công việc trong định nghĩa công việc của Jenkins. Trong khi tạo luồng xây dựng, chúng ta phải chọn chiến lược xây dựng.

Tệp BuildConfig

Trong OpenShift, BuildConfig là một đối tượng còn lại được sử dụng để kết nối với API và sau đó tạo một phiên bản mới.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

Trong OpenShift, có bốn loại chiến lược xây dựng.

• Chiến lược từ nguồn thành hình ảnh
• Chiến lược Docker
• Chiến lược tùy chỉnh
• Chiến lược đường ống

Chiến lược từ nguồn thành hình ảnh

Cho phép tạo hình ảnh vùng chứa bắt đầu từ mã nguồn. Trong luồng này, mã thực được tải xuống đầu tiên trong vùng chứa và sau đó được biên dịch bên trong nó. Mã đã biên dịch được triển khai bên trong cùng một vùng chứa và hình ảnh được xây dựng từ mã đó.

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

Có nhiều chính sách chiến lược.

• Forcepull
• Công trình tăng dần
• Công trình bên ngoài

Chiến lược Docker

Trong luồng này, OpenShift sử dụng Dockerfile để xây dựng hình ảnh và sau đó tải các hình ảnh đã tạo lên sổ đăng ký Docker.

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

Tùy chọn tệp Docker có thể được sử dụng ở nhiều vị trí bắt đầu từ đường dẫn tệp, không có bộ nhớ cache và lực kéo.

• Từ bức ảnh
• Đường dẫn tệp Docker
• Không có bộ nhớ cache
• Lực kéo

Chiến lược tùy chỉnh

Đây là một trong những loại chiến lược xây dựng khác nhau, trong đó không có sự ép buộc nào đến mức đầu ra của việc xây dựng sẽ là một hình ảnh. Nó có thể được so sánh với một công việc phong cách tự do của Jenkins. Với điều này, chúng ta có thể tạo Jar, rpm và các gói khác.

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

Nó bao gồm nhiều chiến lược xây dựng.

• Phơi bày ổ cắm Docker
• Bí mật
• Lực kéo

Chiến lược đường ống

Chiến lược đường ống được sử dụng để tạo đường ống xây dựng tùy chỉnh. Điều này về cơ bản được sử dụng để thực hiện quy trình làm việc trong đường ống. Luồng xây dựng này sử dụng luồng xây dựng tùy chỉnh sử dụng ngôn ngữ Groovy DSL. OpenShift sẽ tạo một công việc đường ống trong Jenkins và thực thi nó. Luồng đường ống này cũng có thể được sử dụng trong Jenkins. Trong chiến lược này, chúng tôi sử dụng Jenkinsfile và thêm nó vào định nghĩa buildconfig.

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

Sử dụng đường ống xây dựng

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>

OpenShift – CLI

OpenShift CLI được sử dụng để quản lý các ứng dụng OpenShift từ dòng lệnh. OpenShift CLI có khả năng quản lý vòng đời ứng dụng từ đầu đến cuối. Nói chung, chúng tôi sẽ sử dụng OC, một ứng dụng khách OpenShift để giao tiếp với OpenShift.

Thiết lập OpenShift CLI

Để thiết lập OC client trên một hệ điều hành khác, chúng ta cần thực hiện các bước theo trình tự khác nhau.

OC Client dành cho Windows

Bước 1 – Tải xuống cli oc từ liên kết sau https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Bước 2 – Giải nén gói trên đường dẫn đích trên máy.

Bước 3 – Chỉnh sửa biến môi trường đường dẫn của hệ thống.

C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%

C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files 
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files 
(x86)\ATI Technologies\ATI.ACE\C

ore-Static;C:\Program Files\Intel\Intel(R) Management Engine 
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine 
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;

Bước 4 – Xác thực thiết lập OC trên Windows.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

OC Client dành cho Mac OS X

Chúng tôi có thể tải xuống các tệp nhị phân thiết lập Mac OS cho cùng một vị trí như cho Windows và sau đó giải nén nó tại một vị trí và đặt đường dẫn có thể thực thi trong biến môi trường PATH.

Ngoài ra Chúng ta có thể sử dụng Home brew và thiết lập nó bằng lệnh sau.

$ brew install openshift-cli

OC Client dành cho Linux

Trong cùng một trang, chúng tôi có tệp tar để cài đặt Linux có thể được sử dụng để cài đặt. Sau đó, một biến đường dẫn có thể được đặt trỏ đến vị trí thực thi cụ thể đó.

https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Giải nén tệp tar bằng lệnh sau.

$ tar –xf < path to the OC setup tar file >

Chạy lệnh sau để kiểm tra xác thực.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server [https://localhost:8443]:

Tệp cấu hình CLI

Tệp cấu hình OC CLI được sử dụng để quản lý nhiều cơ chế xác thực và kết nối máy chủ OpenShift. Tệp cấu hình này cũng được sử dụng để lưu trữ và quản lý nhiều cấu hình và để chuyển đổi giữa chúng. Tệp cấu hình bình thường trông giống như sau.

$ oc config view
apiVersion: v1
clusters:
   - cluster:
      server: https://vklnld908.int.example.com
   name: openshift
   
contexts:
- context:
   cluster: openshift
   namespace: testproject
   user: alice
   name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
   user:
      token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg23223

Thiết lập ứng dụng khách CLI

Để thiết lập thông tin đăng nhập của người dùng

$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]

Đối với cụm thiết lập

$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]

Thí dụ

$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Để thiết lập ngữ cảnh

$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]

Hồ sơ CLI

Trong một tệp cấu hình CLI duy nhất, chúng ta có thể có nhiều cấu hình trong đó mỗi cấu hình có một cấu hình máy chủ OpenShift khác nhau, sau này có thể được sử dụng để chuyển đổi giữa các cấu hình CLI khác nhau.

apiVersion: v1
clusters: --→ 1
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld908.int.example.com:8443
   name: vklnld908.int.example.com:8443
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld1446.int.example.com:8443
   name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: openshift-project
   user: vipin/vklnld908.int.example.com:8443
   name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: testing-project
   user: alim/vklnld908.int.example.com:8443
   name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}

users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
   token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Trong cấu hình trên, chúng ta có thể thấy nó được chia thành bốn phần chính bắt đầu từ cụm xác định hai phiên bản của máy chủ OpenShift. Phần ngữ cảnh thứ hai xác định hai ngữ cảnh có tên là vipin và alim. Ngữ cảnh hiện tại xác định ngữ cảnh nào hiện đang được sử dụng. Nó có thể được thay đổi thành ngữ cảnh hoặc hồ sơ khác, nếu chúng ta thay đổi định nghĩa ở đây. Cuối cùng, định nghĩa người dùng và mã thông báo xác thực của nó được xác định mà trong trường hợp của chúng tôi là vipin. Nếu chúng ta muốn kiểm tra cấu hình hiện tại đang được sử dụng, nó có thể được thực hiện bằng cách sử dụng –

$ oc status
oc status
In project testing Project (testing-project)
$ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".

Nếu chúng ta muốn chuyển sang CLI khác, nó có thể được thực hiện từ dòng lệnh bằng cách sử dụng lệnh sau.

$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".

Sử dụng lệnh trên, chúng ta có thể chuyển đổi giữa các cấu hình. Tại bất kỳ thời điểm nào, nếu chúng ta muốn xem cấu hình, chúng ta có thể sử dụng lệnh $ oc config view view.

OpenShift – Hoạt động CLI (xem thêm)

The post OpenShift – Build Automation appeared first on Dongthoigian.net.

Tạo một ứng dụng mới

Trong OpenShift, có ba phương pháp tạo một ứng dụng mới.

• Từ một mã nguồn
• Từ một hình ảnh
• Từ một mẫu

Từ một mã nguồn

Khi chúng tôi cố gắng tạo một ứng dụng từ mã nguồn, OpenShift sẽ tìm kiếm tệp Docker sẽ có bên trong repo, tệp này xác định quy trình xây dựng ứng dụng. Chúng tôi sẽ sử dụng ứng dụng mới oc để tạo ứng dụng.

Điều đầu tiên cần ghi nhớ khi sử dụng repo là nó phải trỏ đến một nguồn gốc trong repo từ đó OpenShift sẽ kéo mã và xây dựng nó.

Nếu repo được sao chép trên máy Docker nơi cài đặt ứng dụng khách OC và người dùng đang ở trong cùng một thư mục, thì nó có thể được tạo bằng lệnh sau.

$ oc new-app . <Hear. Denotes current working directory>

Sau đây là một ví dụ về việc cố gắng xây dựng từ kho lưu trữ từ xa cho một chi nhánh cụ thể.

$ oc new-app https://github.com/openshift/Testing-deployment.git#test1

Ở đây, test1 là nhánh mà chúng tôi đang cố gắng tạo một ứng dụng mới trong OpenShift.

Khi chỉ định tệp Docker trong kho lưu trữ, chúng ta cần xác định chiến lược xây dựng như hình dưới đây.

$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git

Từ một hình ảnh

Trong khi xây dựng ứng dụng bằng hình ảnh, hình ảnh hiện diện trong máy chủ Docker cục bộ, trong kho lưu trữ Docker được lưu trữ nội bộ hoặc trên trung tâm Docker. Điều duy nhất mà người dùng cần đảm bảo là anh ta có quyền truy cập để lấy hình ảnh từ trung tâm mà không gặp bất kỳ vấn đề gì. OpenShift có khả năng xác định nguồn được sử dụng, cho dù đó là hình ảnh Docker hay một luồng nguồn. Tuy nhiên, nếu người dùng muốn, anh ta có thể xác định rõ ràng đó là luồng hình ảnh hay hình ảnh Docker.

$ oc new-app - - docker-image tomcat

Sử dụng luồng hình ảnh

$ oc new-app tomcat:v1

Từ một mẫu

Các mẫu có thể được sử dụng để tạo một ứng dụng mới. Nó có thể là một mẫu đã có sẵn hoặc tạo một mẫu mới.

Tệp sau yaml về cơ bản là một mẫu có thể được sử dụng để triển khai.

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>

Phát triển và triển khai ứng dụng web

Phát triển một ứng dụng mới trong OpenShift

Để tạo một ứng dụng mới trong OpenShift, chúng ta phải viết một mã ứng dụng mới và xây dựng nó bằng các lệnh xây dựng OpenShift OC. Như đã thảo luận, chúng ta có nhiều cách để tạo một hình ảnh mới. Ở đây, chúng tôi sẽ sử dụng một mẫu để xây dựng ứng dụng. Mẫu này sẽ tạo một ứng dụng mới khi chạy bằng lệnh oc new-app.

Mẫu sau sẽ tạo – Hai ứng dụng front-end và một cơ sở dữ liệu. Cùng với đó, nó sẽ tạo ra hai dịch vụ mới và các ứng dụng đó sẽ được triển khai vào cụm OpenShift. Trong khi xây dựng và triển khai một ứng dụng, ban đầu chúng ta cần tạo một không gian tên trong OpenShift và triển khai ứng dụng dưới không gian tên đó.Tạo một không gian tên mới

$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"

Bản mẫu

{
   "kind": "Template",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-helloworld-sample",
      "creationTimestamp": null,
         "annotations": {
         "description": "This example shows how to create a simple openshift
         application in openshift origin v3",
         "iconClass": "icon-openshift",
         "tags": "instant-app,openshift,mysql"
      }
   }
},

Định nghĩa đối tượng

Định nghĩa bí mật trong một mẫu

"objects": [
{
   "kind": "Secret",
   "apiVersion": "v1",
   "metadata": {"name": "dbsecret"},
   "stringData" : {
      "mysql-user" : "${MYSQL_USER}",
      "mysql-password" : "${MYSQL_PASSWORD}"
   }
},

Định nghĩa dịch vụ trong một mẫu

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   },
   "spec": {
      "ports": [
         {
            "name": "web",
            "protocol": "TCP",
            "port": 5432,
            "targetPort": 8080,
            "nodePort": 0
         }
      ],
      "selector": {"name": "frontend"},
      "type": "ClusterIP",
      "sessionAffinity": "None"
   },
   "status": {
      "loadBalancer": {}
   }
},

Định nghĩa tuyến đường trong một mẫu

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {
      "name": "route-edge",
      "creationTimestamp": null,
      "annotations": {
         "template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
      }
   },
   "spec": {
      "host": "www.example.com",
      "to": {
         "kind": "Service",
         "name": "frontend"
      },
      "tls": {
         "termination": "edge"
      }
   },
   "status": {}
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "origin-openshift-sample",
      "creationTimestamp": null
   },
   "spec": {},
   "status": {
      "dockerImageRepository": ""
   }
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-22-ubuntu7",
      "creationTimestamp": null 
   },
   "spec": {
      "dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
   },
   "status": {
      "dockerImageRepository": ""
   }
},

Xây dựng định nghĩa cấu hình trong một mẫu

{
   "kind": "BuildConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-sample-build",
      "creationTimestamp": null,
      "labels": {name": "openshift-sample-build"}
   },
   "spec": {
      "triggers": [
         { "type": "GitHub",
            "github": {
            "secret": "secret101" } 
         },
         {
            "type": "Generic",
            "generic": {
               "secret": "secret101",
               "allowEnv": true } 
         },
         { 
            "type": "ImageChange",
            "imageChange": {} 
         },
         { "type": "ConfigChange”}
      ],
      "source": {
         "type": "Git",
         "git": {
            "uri": https://github.com/openshift/openshift-hello-world.git } 
      },
      "strategy": {
         "type": "Docker",
         "dockerStrategy": {
            "from": {
               "kind": "ImageStreamTag",
               "name": "openshift-22-ubuntu7:latest” 
            },
            "env": [
               {
                  "name": "EXAMPLE",
                  "value": "sample-app"
               }
            ]					
         }
      },
      "output": {
         "to": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      },
      "postCommit": {
         "args": ["bundle", "exec", "rake", "test"]
      },
      "status": {
         "lastVersion": 0
      }
   }
},

Cấu hình triển khai trong một mẫu

"status": {
   "lastVersion": 0
}
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   }
}, 
"spec": {
   "strategy": {
      "type": "Rolling",
      "rollingParams": {
         "updatePeriodSeconds": 1,
         "intervalSeconds": 1,
         "timeoutSeconds": 120,
         "pre": {
            "failurePolicy": "Abort",
            "execNewPod": {
               "command": [
                  "/bin/true"
               ],
               "env": [
                  { 
                     "name": "CUSTOM_VAR1",
                     "value": "custom_value1"
                  }
               ]						
            }
         }
      }
   }
}
"triggers": [
   {
      "type": "ImageChange",
      "imageChangeParams": {
         "automatic": true,
         "containerNames": [
            "openshift-helloworld"
         ],
         "from": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      }
   },
   {
      "type": "ConfigChange"
   }
],
"replicas": 2,
"selector": {
   "name": "frontend"
},
"template": {
   "metadata": {
      "creationTimestamp": null,
      "labels": {
         "name": "frontend"
      }
   },
   "spec": {
      "containers": [
         {
            "name": "openshift-helloworld",
            "image": "origin-openshift-sample",
            "ports": [
               { 
                  "containerPort": 8080,
                  "protocol": "TCP” 
               }
            ],
            "env": [
               {
                  "name": "MYSQL_USER",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-user"
                     }
                  }
               },
               {
                  "name": "MYSQL_PASSWORD",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-password"
                     }
                  }
               },
               {
                  "name": "MYSQL_DATABASE",
                  "value": "${MYSQL_DATABASE}"
               }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "imagePullPolicy": "IfNotPresent",
            "securityContext": {
               "capabilities": {},
               "privileged": false
            }
         }
      ],
      "restartPolicy": "Always",
      "dnsPolicy": "ClusterFirst"
   },
   "status": {}
},
Định nghĩa dịch vụ trong một mẫu
{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null 
   },
   "spec": {
   "ports": [
      {
         "name": "db",
         "protocol": "TCP",
         "port": 5434,
         "targetPort": 3306,
         "nodePort": 0
      } 
   ],
   "selector": {
      "name": "database 
   },
   "type": "ClusterIP",
   "sessionAffinity": "None" },
   "status": {
      "loadBalancer": {}
   }
},
Định nghĩa cấu hình triển khai trong một mẫu
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null
   },
   "spec": {
      "strategy": {
         "type": "Recreate",
         "resources": {}
      },
      "triggers": [
         {
            "type": "ConfigChange"
         }
      ],
      "replicas": 1,
      "selector": {"name": "database"},
      "template": {
         "metadata": {
            "creationTimestamp": null,
            "labels": {"name": "database"}
         },
         "template": {
            "metadata": {
               "creationTimestamp": null,
               "labels": {
                  "name": "database"
               } 
            },
            "spec": {
               "containers": [
                  {
                     "name": "openshift-helloworld-database",
                     "image": "ubuntu/mysql-57-ubuntu7:latest",
                     "ports": [
                        {
                           "containerPort": 3306,
                           "protocol": "TCP" 
                        }
                     ],
                     "env": [
                        {
                           "name": "MYSQL_USER",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-user"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_PASSWORD",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-password"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_DATABASE",
                           "value": "${MYSQL_DATABASE}" 
                        } 
                     ],
                     "resources": {},
                     "volumeMounts": [
                        {
                           "name": "openshift-helloworld-data",
                           "mountPath": "/var/lib/mysql/data"
                        }
                     ],
                     "terminationMessagePath": "/dev/termination-log",
                     "imagePullPolicy": "Always",
                     "securityContext": {
                        "capabilities": {},
                        "privileged": false
                     } 
                  }
               ],
               "volumes": [
                  { 
                     "name": "openshift-helloworld-data",
                     "emptyDir": {"medium": ""} 
                  } 
               ],
               "restartPolicy": "Always",
               "dnsPolicy": "ClusterFirst” 
            } 
         }
      },
      "status": {} 
   },
   "parameters": [
      { 
         "name": "MYSQL_USER",
         "description": "database username",
         "generate": "expression",
         "from": "user[A-Z0-9]{3}",
         "required": true 
      },
      {
         "name": "MYSQL_PASSWORD",
         "description": "database password",
         "generate": "expression",
         "from": "[a-zA-Z0-9]{8}",
         "required": true
      }, 
      {
         "name": "MYSQL_DATABASE",
         "description": "database name",
         "value": "root",
         "required": true 
      } 
   ],
   "labels": {
      "template": "application-template-dockerbuild" 
   } 
}

Tệp mẫu trên cần được biên dịch cùng một lúc. Trước tiên, chúng ta cần sao chép tất cả nội dung vào một tệp duy nhất và đặt tên là tệp yaml sau khi hoàn tất. Chúng ta cần chạy lệnh sau để tạo ứng dụng.

$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"

   openshift-helloworld-sample
   ---------
   This example shows how to create a simple ruby application in openshift origin v3
   * With parameters:
      * MYSQL_USER = userPJJ # generated
      * MYSQL_PASSWORD = cJHNK3se # generated
      * MYSQL_DATABASE = root

--> Creating resources with label app = ruby-helloworld-sample ...
   service "frontend" created
   route "route-edge" created
   imagestream "origin-ruby-sample" created
   imagestream "ruby-22-centos7" created
   buildconfig "ruby-sample-build" created
   deploymentconfig "frontend" created
   service "database" created
   deploymentconfig "database" created
   
--> Success
   Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
   Run 'oc status' to view your app.

Nếu chúng ta muốn giám sát quá trình xây dựng, nó có thể được thực hiện bằng cách sử dụng –

$ oc get builds

NAME                        TYPE      FROM          STATUS     STARTED         DURATION
openshift-sample-build-1    Source   Git@bd94cbb    Running    7 seconds ago   7s

Chúng tôi có thể kiểm tra các ứng dụng đã triển khai trên OpenShift bằng cách sử dụng

$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
database-1-le4wx                1/1     Running     0          1m
frontend-1-e572n                1/1     Running     0          27s
frontend-1-votq4                1/1     Running     0          31s
opeshift-sample-build-1-build   0/1     Completed   0          1m

Chúng tôi có thể kiểm tra xem các dịch vụ ứng dụng có được tạo theo định nghĩa dịch vụ hay không bằng cách sử dụng

$ oc get services
NAME        CLUSTER-IP      EXTERNAL-IP     PORT(S)      SELECTOR          AGE
database    172.30.80.39    <none>         5434/TCP     name=database      1m
frontend    172.30.17.4     <none>         5432/TCP     name=frontend      1m

OpenShift – Build Automation

Tự động hóa xây dựng (xem thêm)

The post OpenShift – Bắt đầu appeared first on Dongthoigian.net.

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)

The post OpenShift – Basic Concept  Khái niệm cơ bản appeared first on Dongthoigian.net.

Các thành phần của OpenShift

Một trong những thành phần quan trọng của kiến ​​trúc OpenShift là quản lý cơ sở hạ tầng container trong Kubernetes. Kubernetes chịu trách nhiệm Triển khai và Quản lý cơ sở hạ tầng. Trong bất kỳ cụm Kubernetes nào, chúng ta có thể có nhiều nút chính và nhiều nút, điều này đảm bảo không có điểm nào bị lỗi trong quá trình thiết lập.

Kubernetes Master Machine Linh kiện

Etcd – Nó lưu trữ thông tin cấu hình, có thể được sử dụng bởi từng nút trong cụm. Nó là một kho lưu trữ giá trị khóa có tính khả dụng cao có thể được phân phối giữa nhiều nút. Nó chỉ có thể được truy cập bởi máy chủ Kubernetes API vì nó có thể có thông tin nhạy cảm. Nó là một Kho lưu trữ giá trị khóa phân phối mà tất cả mọi người đều có thể truy cập được.

Máy chủ API – Kubernetes là một máy chủ API cung cấp tất cả hoạt động trên cụm bằng cách sử dụng API. Máy chủ API triển khai một giao diện có nghĩa là các công cụ và thư viện khác nhau có thể dễ dàng giao tiếp với nó. Kubeconfig là một gói cùng với các công cụ phía máy chủ có thể được sử dụng để giao tiếp. Nó làm lộ API Kubernetes ”.

Trình quản lý bộ điều khiển – Thành phần này chịu trách nhiệm cho hầu hết các bộ thu thập điều chỉnh trạng thái của cụm và thực hiện một nhiệm vụ. Nó có thể được coi là một daemon chạy trong một vòng lặp không kết thúc và chịu trách nhiệm thu thập và gửi thông tin đến máy chủ API. Nó hoạt động theo hướng nhận trạng thái được chia sẻ của cụm và sau đó thực hiện các thay đổi để đưa trạng thái hiện tại của máy chủ đến trạng thái mong muốn. Các bộ điều khiển chính là bộ điều khiển sao chép, bộ điều khiển điểm cuối, bộ điều khiển không gian tên và bộ điều khiển tài khoản dịch vụ. Trình quản lý bộ điều khiển chạy các loại bộ điều khiển khác nhau để xử lý các nút, điểm cuối, v.v.

Bộ lập lịch – Nó là một thành phần chính của Kubernetes master. Nó là một dịch vụ tổng thể chịu trách nhiệm phân phối khối lượng công việc. Nó chịu trách nhiệm theo dõi việc sử dụng tải làm việc trên các nút cụm và sau đó đặt khối lượng công việc vào tài nguyên nào có sẵn và chấp nhận khối lượng công việc. Nói cách khác, đây là cơ chế chịu trách nhiệm phân bổ nhóm cho các nút có sẵn. Bộ lập lịch chịu trách nhiệm sử dụng khối lượng công việc và phân bổ nhóm cho một nút mới.

Các thành phần nút Kubernetes

Sau đây là các thành phần chính của máy chủ Node, cần thiết để giao tiếp với Kubernetes master.

Docker – Yêu cầu đầu tiên của mỗi nút là Docker giúp chạy các vùng chứa ứng dụng được đóng gói trong một môi trường hoạt động tương đối cô lập nhưng nhẹ.

Dịch vụ Kubelet – Đây là một dịch vụ nhỏ trong mỗi nút, có nhiệm vụ chuyển tiếp thông tin đến và đi từ dịch vụ máy bay điều khiển. Nó tương tác với cửa hàng etcd để đọc chi tiết cấu hình và giá trị Wright. Điều này giao tiếp với thành phần chủ để nhận lệnh và hoạt động. Sau đó, quy trình kubelet đảm nhận trách nhiệm duy trì trạng thái công việc và máy chủ nút. Nó quản lý các quy tắc mạng, chuyển tiếp cổng, v.v.

Kubernetes Proxy Service – Đây là một dịch vụ proxy chạy trên mỗi nút và giúp cung cấp các dịch vụ cho máy chủ bên ngoài. Nó giúp chuyển tiếp yêu cầu sửa vùng chứa. Kubernetes Proxy Service có khả năng thực hiện cân bằng tải nguyên thủy. Nó đảm bảo rằng môi trường mạng có thể dự đoán được và có thể truy cập được nhưng đồng thời nó cũng bị cô lập. Nó quản lý các nhóm trên nút, khối lượng, bí mật, tạo kiểm tra sức khỏe vùng chứa mới, v.v.

Tích hợp OpenShift Container Registry

Đăng ký vùng chứa OpenShift là một đơn vị lưu trữ sẵn có của Red Hat, được sử dụng để lưu trữ hình ảnh Docker. Với phiên bản tích hợp mới nhất của OpenShift, nó đã đi kèm với giao diện người dùng để xem hình ảnh trong bộ nhớ trong của OpenShift. Các cơ quan đăng ký này có khả năng lưu giữ hình ảnh với các thẻ được chỉ định, sau này được sử dụng để xây dựng các vùng chứa từ nó.

Các điều khoản thường được sử dụng

Hình ảnh – Hình ảnh Kubernetes (Docker) là khối xây dựng chính của Cơ sở hạ tầng được chứa đựng. Hiện tại, Kubernetes chỉ hỗ trợ hình ảnh Docker. Mỗi vùng chứa trong một nhóm có hình ảnh Docker của nó chạy bên trong nó. Khi định cấu hình nhóm, thuộc tính hình ảnh trong tệp cấu hình có cùng cú pháp với lệnh Docker.

Dự án – Chúng có thể được định nghĩa là phiên bản được đổi tên của miền đã có trong phiên bản OpenShift V2 trước đó.

Vùng chứa – Chúng là những vùng được tạo sau khi hình ảnh được triển khai trên một nút cụm Kubernetes.

Node – Node là một máy làm việc trong Kubernetes cluster, còn được gọi là minion cho master. Chúng là các đơn vị làm việc có thể là một phiên bản vật lý, máy ảo hoặc đám mây.Pod – Một nhóm là một tập hợp các vùng chứa và bộ lưu trữ của nó bên trong một nút của một cụm Kubernetes. Có thể tạo một nhóm với nhiều vùng chứa bên trong nó. Ví dụ: giữ vùng chứa cơ sở dữ liệu và vùng chứa máy chủ web bên trong nhóm.

OpenShift – Thiết lập môi trường

Trong chương này, chúng ta sẽ tìm hiểu về thiết lập môi trường của OpenShift.

Yêu cầu hệ thống

Để thiết lập OpenShift doanh nghiệp, một người cần phải có tài khoản Red Hat đang hoạt động. Vì OpenShift hoạt động trên kiến ​​trúc nút và chủ Kubernetes, chúng ta cần thiết lập cả hai trên các máy riêng biệt, trong đó một máy hoạt động như một máy chủ và các máy khác hoạt động trên nút. Để thiết lập cả hai, cần có các yêu cầu hệ thống tối thiểu.

Cấu hình máy chính

Sau đây là các yêu cầu hệ thống tối thiểu cho cấu hình máy chủ.

• Máy cơ sở được lưu trữ trên vật lý, ảo hoặc trên bất kỳ môi trường đám mây nào.
• Ít nhất là Linux 7 với các gói bắt buộc trên phiên bản đó.
• 2 nhân CPU.
• RAM ít nhất 8 GB.
• Bộ nhớ đĩa cứng bên trong 30 GB.

Cấu hình máy nút

• Hình ảnh cơ sở vật lý hoặc ảo như được cung cấp cho máy chủ.
• Ít nhất Linux 7 trên máy.
• Docker được cài đặt với phiên bản không dưới 1.6.
• 1 nhân CPU.
• RAM 8 GB.
• Đĩa cứng 15 GB để lưu trữ hình ảnh và 15 GB để lưu trữ hình ảnh.

Hướng dẫn từng bước để thiết lập OpenShift

Trong mô tả sau đây, chúng tôi sẽ thiết lập môi trường phòng thí nghiệm OpenShift, sau này có thể được mở rộng thành một cụm lớn hơn. Vì OpenShift yêu cầu thiết lập nút chính và nút, chúng tôi sẽ cần ít nhất hai máy được lưu trữ trên đám mây, máy vật lý hoặc máy ảo.

Bước 1 – Đầu tiên hãy cài đặt Linux trên cả hai máy, trong đó Linux 7 phải là phiên bản ít nhất. Điều này có thể được thực hiện bằng cách sử dụng các lệnh sau nếu một người có đăng ký Red Hat đang hoạt động.

# subscription-manager repos --disable = "*"
# subscription-manager repos --enable = "rhel-7-server-rpms"
# subscription-manager repos --enable = "rhel-7-server-extras-rpms"
# subscription-manager repos --enable = "rhel-7-server-optional-rpms"
# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"
# yum install wget git net-tools bind-utils iptables-services bridge-utils
# yum install wget git net-tools bind-utils iptables-services bridge-utils
# yum install python-virtualenv
# yum install gcc
# yum install httpd-tools
# yum install docker
# yum update

Khi chúng ta đã cài đặt tất cả các gói cơ sở trên trong cả hai máy, bước tiếp theo sẽ là thiết lập Docker trên các máy tương ứng.

Bước 2 – Định cấu hình Docker để nó chỉ cho phép giao tiếp không an toàn trên mạng cục bộ. Đối với điều này, hãy chỉnh sửa tệp Docker bên trong / etc / sysconfig. Nếu tệp không có thì bạn cần phải tạo nó theo cách thủ công.

# vi /etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

Sau khi định cấu hình Docker trên máy chủ, chúng ta cần thiết lập giao tiếp không cần mật khẩu giữa cả hai máy. Đối với điều này, chúng tôi sẽ sử dụng xác thực khóa công khai và riêng tư.

Bước 3 – Tạo khóa trên máy chủ và sau đó sao chép khóa id_rsa.pub vào tệp khóa được ủy quyền của máy nút, có thể thực hiện bằng lệnh sau.

# ssh-keygen
# ssh-copy-id -i .ssh/id_rsa.pub root@ose3-node.test.com

Khi bạn đã có tất cả các thiết lập trên, tiếp theo là thiết lập OpenShift phiên bản 3 trên máy chủ.

Bước 4 – Từ máy chủ, chạy lệnh curl sau.

# sh <(curl -s https://install.openshift.com/ose)

Lệnh trên sẽ đặt thiết lập cho OSV3. Bước tiếp theo sẽ là cấu hình OpenShift V3 trên máy.

Nếu bạn không thể tải xuống trực tiếp từ Internet, thì có thể tải xuống từ https://install.openshift.com/portable/oo-install-ose.tgz dưới dạng gói tar mà từ đó trình cài đặt có thể chạy trên máy chủ cục bộ.

Khi chúng ta đã thiết lập sẵn sàng, thì chúng ta cần bắt đầu với cấu hình thực của OSV3 trên máy. Thiết lập này rất cụ thể để kiểm tra môi trường cho quá trình sản xuất thực tế, chúng tôi có sẵn LDAP và những thứ khác.

Bước 5 – Trên máy chủ, hãy định cấu hình mã sau nằm trong /etc/openshift/master/master-config.yaml

# vi /etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /root/users.htpasswd
routingConfig:
subdomain: testing.com

Tiếp theo, tạo một người dùng tiêu chuẩn để quản trị mặc định.

# htpasswd -c /root/users.htpasswd admin

Bước 6 – Vì OpenShift sử dụng sổ đăng ký Docker để định cấu hình hình ảnh, chúng ta cần phải định cấu hình sổ đăng ký Docker. Điều này được sử dụng để tạo và lưu trữ các hình ảnh Docker sau khi xây dựng.

Tạo một thư mục trên máy nút OpenShift bằng lệnh sau.

# mkdir /images

Tiếp theo, đăng nhập vào máy chủ bằng thông tin đăng nhập quản trị viên mặc định, được tạo trong khi thiết lập sổ đăng ký.

# oc login
Username: system:admin

Chuyển sang dự án được tạo mặc định.

# oc project default 

Bước 7 – Tạo Sổ đăng ký Docker.

#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -

Chỉnh sửa các đặc quyền của người dùng.

#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry
Tạo và chỉnh sửa sổ đăng ký hình ảnh.
#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images

Bước 8 – Tạo một định tuyến mặc định.

Theo mặc định, OpenShift sử dụng OpenVswitch làm mạng phần mềm. Sử dụng lệnh sau để tạo định tuyến mặc định. Điều này được sử dụng để cân bằng tải và định tuyến proxy. Bộ định tuyến tương tự như sổ đăng ký Docker và cũng chạy trong một sổ đăng ký.

# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -

Tiếp theo, chỉnh sửa các đặc quyền của người dùng.

#oc edit scc privileged
users:
   - system:serviceaccount:openshift-infra:build-controller
   - system:serviceaccount:default:registry
   - system:serviceaccount:default:router

#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'

Bước 9 – Định cấu hình DNS.

Để xử lý yêu cầu URL, OpenShift cần một môi trường DNS hoạt động. Cấu hình DNS này được yêu cầu để tạo thẻ đại diện, thẻ này được yêu cầu để tạo thẻ đại diện DNS trỏ đến bộ định tuyến.

# yum install bind-utils bind
# systemctl start named
# systemctl enable named
vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
   10.38.55.13;
   ;
};

zone "lab.com" IN {
   type master;
   file "/var/named/dynamic/test.com.zone";
   allow-update { none; };
};

Bước 10 – Bước cuối cùng sẽ là thiết lập máy chủ github trên máy chủ OpenShift V3, đây là tùy chọn. Điều này có thể được thực hiện dễ dàng bằng cách sử dụng chuỗi lệnh sau.

#yum install curl openssh-server
#systemctl enable sshd
# systemctl start sshd
# firewall-cmd --permanent --add-service = http
# systemctl reload firewalld
#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-
#yum install gitlab-ce
# gitlab-ctl reconfigure

Khi quá trình thiết lập ở trên hoàn tất, bạn có thể xác minh bằng cách kiểm tra và triển khai ứng dụng, điều này chúng ta sẽ biết thêm trong các chương tiếp theo.

OpenShift – Khái niệm cơ bản (xem thêm)

The post OpenShift – Kiến trúc appeared first on Dongthoigian.net.

Hướng dẫn này đã được chuẩn bị cho những ai muốn hiểu các tính năng và chức năng của OpenShift cũng như tìm hiểu cách nó có thể trợ giúp trong việc xây dựng các dịch vụ và ứng dụng hỗ trợ đám mây.

Sau khi hoàn thành hướng dẫn này, người đọc sẽ hiểu được ở mức độ vừa phải về OpenShift và khối xây dựng chính của nó. Nó cũng sẽ đưa ra một ý tưởng hợp lý về cách cấu hình OpenShift trong một cơ sở hạ tầng được cấu hình sẵn và sử dụng nó.

Người đọc muốn hiểu và học OpenShift nên có kiến ​​thức cơ bản về Docker và Kubernetes. Người đọc cũng cần có một số hiểu biết về quản trị hệ thống, cơ sở hạ tầng và giao tiếp giao thức mạng.

OpenShift – Tổng quan

OpenShift là một Nền tảng phát triển đám mây dưới dạng Dịch vụ (PaaS) được lưu trữ bởi Red Hat. Đó là một nền tảng thân thiện với người dùng dựa trên đám mây mã nguồn mở được sử dụng để tạo, thử nghiệm và chạy các ứng dụng và cuối cùng là triển khai chúng trên đám mây.

OpenShift có khả năng quản lý các ứng dụng được viết bằng các ngôn ngữ khác nhau, chẳng hạn như Node.js, Ruby, Python, Perl và Java. Một trong những tính năng chính của OpenShift là nó có thể mở rộng, giúp người dùng hỗ trợ ứng dụng được viết bằng các ngôn ngữ khác.

OpenShift đi kèm với các khái niệm ảo hóa khác nhau như là lớp trừu tượng của nó. Khái niệm cơ bản đằng sau OpenShift dựa trên ảo hóa.

Ảo hóa

Nói chung, ảo hóa có thể được định nghĩa là việc tạo ra một hệ thống ảo chứ không phải là phiên bản vật lý hoặc thực tế của bất kỳ thứ gì bắt đầu từ hệ thống, bộ nhớ hoặc hệ điều hành. Mục tiêu chính của ảo hóa là làm cho cơ sở hạ tầng CNTT có khả năng mở rộng và đáng tin cậy hơn. Khái niệm ảo hóa đã có từ nhiều thập kỷ trước và với sự phát triển của ngành CNTT ngày nay, nó có thể được áp dụng cho nhiều tầng khác nhau, bắt đầu từ mức hệ thống, mức phần cứng cho đến ảo hóa mức máy chủ.

Làm thế nào nó hoạt động

Nó có thể được mô tả như một công nghệ trong đó bất kỳ ứng dụng hoặc hệ điều hành nào được trừu tượng hóa từ lớp vật lý thực tế của nó. Một công dụng chính của công nghệ ảo hóa là ảo hóa máy chủ, sử dụng một phần mềm gọi là hypervisor để trừu tượng hóa lớp khỏi phần cứng bên dưới. Hiệu suất của hệ điều hành chạy trên nền ảo hóa cũng tốt như khi nó đang chạy trên phần cứng vật lý. Tuy nhiên, khái niệm ảo hóa phổ biến vì hầu hết hệ thống và ứng dụng đang chạy không yêu cầu sử dụng phần cứng bên dưới.

Kiến trúc vật lý và ảo

Các loại ảo hóa

• Ảo hóa ứng dụng – Trong phương pháp này, ứng dụng được trừu tượng hóa từ hệ điều hành cơ bản. Phương pháp này rất hữu ích trong đó ứng dụng có thể được chạy một cách riêng biệt mà không bị phụ thuộc vào hệ điều hành bên dưới.
• Ảo hóa máy tính để bàn – Phương pháp này được sử dụng để giảm tải máy trạm trong đó người ta có thể truy cập máy tính để bàn từ xa, sử dụng một máy khách mỏng tại bàn làm việc. Trong phương pháp này, các máy tính để bàn chủ yếu được chạy trong một trung tâm dữ liệu. Một ví dụ cổ điển có thể là Hình ảnh máy tính để bàn ảo (VDI) được sử dụng trong hầu hết các tổ chức.
• Ảo hóa dữ liệu – Đây là một phương pháp trừu tượng hóa và tách khỏi phương pháp quản lý dữ liệu và dữ liệu truyền thống.
• Ảo hóa máy chủ – Trong phương pháp này, các tài nguyên liên quan đến máy chủ được ảo hóa bao gồm máy chủ vật lý, quy trình và hệ điều hành. Phần mềm cho phép trừu tượng hóa này thường được gọi là hypervisor.
• Ảo hóa bộ nhớ – Là quá trình gộp nhiều thiết bị lưu trữ vào một thiết bị lưu trữ duy nhất được quản lý từ một bảng điều khiển trung tâm duy nhất.
• Ảo hóa mạng – Đây là phương pháp trong đó tất cả các tài nguyên mạng có sẵn được kết hợp bằng cách chia nhỏ băng thông và kênh khả dụng, mỗi kênh đều độc lập với nhau.

OpenShift

OpenShift là một nền tảng ứng dụng hỗ trợ đám mây như một Dịch vụ (PaaS). Đó là một công nghệ mã nguồn mở giúp các tổ chức di chuyển cơ sở hạ tầng và nền tảng ứng dụng truyền thống của họ từ các phương tiện vật lý, ảo sang đám mây.

OpenShift hỗ trợ rất nhiều ứng dụng khác nhau, có thể dễ dàng phát triển và triển khai trên nền tảng đám mây OpenShift. OpenShift về cơ bản hỗ trợ ba loại nền tảng cho các nhà phát triển và người dùng.

Cơ sở hạ tầng như một dịch vụ (IaaS)

Ở định dạng này, nhà cung cấp dịch vụ cung cấp các máy ảo cấp phần cứng với một số cấu hình phần cứng ảo được xác định trước. Có nhiều đối thủ cạnh tranh trong không gian này, bắt đầu từ đám mây AWS Google, Rackspace và nhiều đối thủ khác.

Hạn chế chính của việc có IaaS sau một quá trình thiết lập và đầu tư lâu dài là người ta vẫn phải chịu trách nhiệm cài đặt và bảo trì hệ điều hành và gói máy chủ, quản lý mạng cơ sở hạ tầng và quản trị hệ thống cơ bản.

Phần mềm như một dịch vụ (SaaS)

Với SaaS, người ta ít phải lo lắng nhất về cơ sở hạ tầng bên dưới. Nó đơn giản như plug and play, trong đó người dùng chỉ cần đăng ký dịch vụ và bắt đầu sử dụng. Hạn chế chính của thiết lập này là, người ta chỉ có thể thực hiện số lượng tùy chỉnh tối thiểu được nhà cung cấp dịch vụ cho phép. Một trong những ví dụ phổ biến nhất của SaaS là ​​Gmail, nơi người dùng chỉ cần đăng nhập và bắt đầu sử dụng nó. Người dùng cũng có thể thực hiện một số sửa đổi nhỏ đối với tài khoản của mình. Tuy nhiên, nó không hữu ích lắm theo quan điểm của nhà phát triển.

Nền tảng như một dịch vụ (PaaS)

Có thể coi đây là lớp trung gian giữa SaaS và IaaS. Mục tiêu chính của đánh giá PaaS là ​​dành cho các nhà phát triển trong đó môi trường phát triển có thể được tạo ra với một vài lệnh. Các môi trường này được thiết kế theo cách mà chúng có thể đáp ứng tất cả các nhu cầu phát triển, ngay từ khi có một máy chủ ứng dụng web với cơ sở dữ liệu. Để làm điều này, bạn chỉ cần một lệnh duy nhất và nhà cung cấp dịch vụ sẽ thực hiện công việc cho bạn.

Tại sao sử dụng OpenShift?

OpenShift cung cấp một nền tảng chung cho các đơn vị doanh nghiệp lưu trữ các ứng dụng của họ trên đám mây mà không cần lo lắng về hệ điều hành bên dưới. Điều này giúp bạn dễ dàng sử dụng, phát triển và triển khai các ứng dụng trên đám mây. Một trong những tính năng chính là, nó cung cấp phần cứng được quản lý và tài nguyên mạng cho tất cả các loại phát triển và thử nghiệm. Với OpenShift, nhà phát triển PaaS có quyền tự do thiết kế môi trường yêu cầu của họ với các thông số kỹ thuật.

OpenShift cung cấp các loại thỏa thuận mức dịch vụ khác nhau khi nói đến các gói dịch vụ.

Miễn phí – Gói này được giới hạn trong ba năm với dung lượng 1GB cho mỗi gói.

Đồng – Gói này bao gồm 3 năm và mở rộng lên đến 16 năm với dung lượng 1GB mỗi năm.

Sliver – Đây là gói đồng 16 năm, tuy nhiên, có dung lượng lưu trữ 6GB mà không tính thêm phí.

Ngoài các tính năng trên, OpenShift cũng cung cấp phiên bản tại chỗ được gọi là OpenShift Enterprise. Trong OpenShift, các nhà phát triển có đòn bẩy để thiết kế các ứng dụng có thể mở rộng và không thể mở rộng và những thiết kế này được thực hiện bằng cách sử dụng máy chủ HAproxy.

Đặc trưng

Có nhiều tính năng được hỗ trợ bởi OpenShift. Một số ít trong số họ –

• Hỗ trợ nhiều ngôn ngữ
• Hỗ trợ nhiều cơ sở dữ liệu
• Hệ thống hộp mực mở rộng
• Quản lý phiên bản mã nguồn
• Triển khai một cú nhấp chuột
• Hỗ trợ đa môi trường
• Quy trình làm việc của Nhà phát triển được chuẩn hóa
• Quản lý phụ thuộc và xây dựng
• Mở rộng ứng dụng tự động
• Bảng điều khiển web đáp ứng
• Bộ công cụ dòng lệnh phong phú
• Đăng nhập SSH từ xa vào ứng dụng
• Hỗ trợ API còn lại
• Ngăn xếp ứng dụng tự phục vụ theo yêu cầu
• Dịch vụ cơ sở dữ liệu tích hợp
• Quản lý tích hợp và phát hành liên tục
• Tích hợp IDE
• Gỡ lỗi ứng dụng từ xa

OpenShift – Các loại

OpenShift ra đời từ cơ sở có tên OpenShift V2, chủ yếu dựa trên khái niệm bánh răng và hộp mực, trong đó mỗi thành phần đều có các thông số kỹ thuật bắt đầu từ khi tạo máy cho đến khi triển khai ứng dụng, ngay từ khi xây dựng đến triển khai ứng dụng.

Cartridges – Chúng là tâm điểm của việc xây dựng một ứng dụng mới bắt đầu từ loại ứng dụng mà môi trường yêu cầu để chạy chúng và tất cả các phụ thuộc được thỏa mãn trong phần này.

Gear – Nó có thể được định nghĩa là máy hoặc máy chủ bằng kim loại chịu lực với các thông số kỹ thuật nhất định liên quan đến tài nguyên, bộ nhớ và CPU. Chúng được coi là một đơn vị cơ bản để chạy một ứng dụng.

Ứng dụng – Đây chỉ đơn giản là đề cập đến ứng dụng hoặc bất kỳ ứng dụng tích hợp nào sẽ được triển khai và chạy trên môi trường OpenShift.

Khi đi sâu hơn vào phần này, chúng ta sẽ thảo luận về các định dạng và dịch vụ khác nhau của OpenShift. Trong những ngày trước đó, OpenShift có ba phiên bản chính.

OpenShift Origin – Đây là phần bổ sung cộng đồng hoặc phiên bản nguồn mở của OpenShift. Nó còn được gọi là dự án ngược dòng cho hai phiên bản khác.

OpenShift Online – Đây là một PaaS công khai như một dịch vụ được lưu trữ trên AWS.

OpenShift Enterprise – là phiên bản cứng của OpenShift với ISV và giấy phép của nhà cung cấp.

OpenShift trực tuyến

OpenShift trực tuyến là một sản phẩm của cộng đồng OpenShift sử dụng cộng đồng này có thể nhanh chóng xây dựng, triển khai và mở rộng quy mô các ứng dụng được container hóa trên đám mây công cộng. Đây là nền tảng lưu trữ và phát triển ứng dụng đám mây công cộng của Red Hat, cho phép cung cấp, quản lý và mở rộng ứng dụng tự động, giúp nhà phát triển tập trung vào việc viết logic ứng dụng.

Thiết lập tài khoản trên Red Hat OpenShift Online

Bước 1 – Truy cập trình duyệt và truy cập trang web https://manage.openshift.com/

Bước 2 – Nếu bạn có tài khoản Red Hat, hãy đăng nhập vào tài khoản OpenShift bằng ID và mật khẩu đăng nhập Red Hat bằng URL sau. https://developers.redhat.com

Bước 3 – Nếu bạn chưa đăng nhập tài khoản Red Hat, hãy đăng ký dịch vụ trực tuyến OpenShift bằng liên kết sau. : https://developers.redhat.com/

Sau khi đăng nhập, bạn sẽ thấy trang sau.

Khi bạn đã có tất cả mọi thứ, Red Hat sẽ hiển thị một số chi tiết tài khoản cơ bản như được hiển thị trong ảnh chụp màn hình sau.

Cuối cùng, khi bạn đã đăng nhập, bạn sẽ thấy trang sau.

Nền tảng thùng chứa OpenShift

Nền tảng container OpenShift là một nền tảng doanh nghiệp giúp nhiều nhóm như nhóm phát triển và hoạt động CNTT xây dựng và triển khai cơ sở hạ tầng container. Tất cả các vùng chứa được xây dựng trong OpenShift sử dụng công nghệ chứa Docker rất đáng tin cậy, có thể được triển khai trên bất kỳ trung tâm dữ liệu nào của các nền tảng đám mây được lưu trữ công khai.

Nền tảng thùng chứa OpenShift chính thức được gọi là OpenShift Enterprises. Đây là một nền tảng riêng tư tại chỗ của Red Hat dưới dạng dịch vụ, được xây dựng dựa trên khái niệm cốt lõi về các vùng chứa ứng dụng được cung cấp bởi Docker, nơi mà Kubernetes quản lý và điều phối.

Nói cách khác, OpenShift mang Docker và Kubernetes lại với nhau ở cấp độ doanh nghiệp. Nó là một phần mềm nền tảng vùng chứa cho các đơn vị doanh nghiệp để triển khai và quản lý các ứng viên trong một cơ sở hạ tầng do chính bạn lựa chọn. Ví dụ: lưu trữ các phiên bản OpenShift trên các phiên bản AWS.

Nền tảng thùng chứa OpenShift có sẵn ở hai cấp độ gói .

OpenShift Container Local – Phần mềm này dành cho những nhà phát triển muốn triển khai và thử nghiệm các ứng dụng trên máy cục bộ. Gói này chủ yếu được sử dụng bởi các nhóm phát triển để phát triển và thử nghiệm ứng dụng.

OpenShift Container Lab – Phòng thí nghiệm này được thiết kế để đánh giá mở rộng ứng dụng bắt đầu từ quá trình phát triển cho đến khi triển khai đến môi trường tiền sản xuất.

OpenShift Dedicated

Đây là một ưu đãi khác được thêm vào danh mục của OpenShift, trong đó khách hàng có thể lựa chọn lưu trữ một nền tảng được container hóa trên bất kỳ đám mây công cộng nào mà họ lựa chọn. Điều này mang lại cho người dùng cuối cảm giác thực sự về cung cấp đa đám mây, nơi họ có thể sử dụng OpenShift trên bất kỳ đám mây nào đáp ứng nhu cầu của họ.

Đây là một trong những ưu đãi mới nhất của Red Hat, nơi người dùng cuối có thể sử dụng OpenShift để xây dựng triển khai thử nghiệm và chạy ứng dụng của họ trên OpenShift được lưu trữ trên đám mây.

Các tính năng của OpenShift Dedicated

OpenShift dành riêng cung cấp nền tảng ứng dụng giải pháp tùy chỉnh trên đám mây công cộng và nó được kế thừa từ công nghệ OpenShift 3.

• Có thể mở rộng và mở – Điều này được xây dựng dựa trên khái niệm mở của Docker và được triển khai trên đám mây vì nó có thể tự sử dụng khi và khi được yêu cầu.
• Tính di động – Vì nó được xây dựng bằng Docker, các ứng dụng chạy trên Docker có thể dễ dàng được vận chuyển từ nơi này đến nơi khác, nơi Docker được hỗ trợ.
• Điều phối – Với OpenShift 3, một trong những tính năng chính của điều phối vùng chứa và quản lý cụm được hỗ trợ bằng cách sử dụng Kubernetes được cung cấp cùng với OpenShift phiên bản 3.
• Tự động hóa – Phiên bản OpenShift này được kích hoạt với tính năng quản lý mã nguồn, tự động hóa xây dựng và tự động hóa triển khai, điều này làm cho nó rất phổ biến trên thị trường với tư cách là một nền tảng như một nhà cung cấp dịch vụ.

Đối thủ của OpenShift

Google App Engine – Đây là nền tảng miễn phí của Google để phát triển và lưu trữ các ứng dụng web. Công cụ ứng dụng của Google cung cấp nền tảng triển khai và phát triển nhanh chóng.

Microsoft Azure – Đám mây Azure được Microsoft lưu trữ trên các trung tâm dữ liệu của họ.

Amazon Elastic Cloud Compute – Chúng là các dịch vụ tích hợp do Amazon cung cấp, giúp phát triển và lưu trữ các ứng dụng web có thể mở rộng trên đám mây.

Cloud Foundry – là một nền tảng PaaS mã nguồn mở cho các ứng dụng Java, Ruby, Python và Node.js.

CloudStack – CloudStack của Apache là một dự án được phát triển bởi Citrix và được thiết kế để trở thành đối thủ cạnh tranh trực tiếp của OpenShift và OpenStack.

OpenStack – Một công nghệ đám mây khác do Red Hat cung cấp cho điện toán đám mây.

Kubernetes – Đây là một công nghệ quản lý cụm và điều phối trực tiếp được xây dựng để quản lý vùng chứa Docker.

OpenShift – Kiến trúc (xem thêm)

The post Hướng dẫn OpenShift appeared first on Dongthoigian.net.