Tự động hóa xây dựng
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.