Xin chào tất cả mọi người trên blog này! Đây là bài đăng thứ ba trong loạt bài trình bày cách triển khai các ứng dụng web hiện đại trên Red Hat OpenShift.
Trong hai bài đăng trước, chúng tôi đã trình bày cách triển khai các ứng dụng web hiện đại chỉ trong vài bước và cách sử dụng hình ảnh S2I mới cùng với hình ảnh máy chủ HTTP có sẵn, chẳng hạn như NGINX, sử dụng các bản dựng theo chuỗi để điều phối việc triển khai sản xuất .
Hôm nay chúng tôi sẽ trình bày cách chạy máy chủ phát triển cho ứng dụng của bạn trên nền tảng OpenShift và đồng bộ hóa nó với hệ thống tệp cục bộ, đồng thời nói về Đường ống OpenShift là gì và cách chúng có thể được sử dụng thay thế cho các tập hợp được liên kết.
OpenShift là môi trường phát triển
Quy trình phát triển
Như đã nêu trong , quy trình phát triển điển hình cho các ứng dụng web hiện đại chỉ đơn giản là một loại “máy chủ phát triển” nào đó theo dõi các thay đổi đối với các tệp cục bộ. Khi chúng xảy ra, quá trình xây dựng ứng dụng sẽ được kích hoạt và sau đó nó được cập nhật lên trình duyệt.
Trong hầu hết các khung công tác hiện đại, một “máy chủ phát triển” như vậy được tích hợp vào các công cụ dòng lệnh tương ứng.
Ví dụ địa phương
Trước tiên, hãy xem cách này hoạt động khi chạy các ứng dụng cục bộ. Hãy lấy ứng dụng này làm ví dụ từ các bài viết trước, mặc dù hầu hết các khái niệm quy trình làm việc tương tự đều được áp dụng trong tất cả các khung hiện đại khác.
Vì vậy, để khởi động "máy chủ dev" trong ví dụ React của chúng tôi, chúng tôi sẽ nhập lệnh sau:
$ npm run start
Sau đó trong cửa sổ terminal chúng ta sẽ thấy một cái gì đó như thế này:
Và ứng dụng của chúng tôi sẽ mở trong trình duyệt mặc định:
Bây giờ, nếu chúng ta thực hiện thay đổi đối với tệp, ứng dụng sẽ cập nhật trong trình duyệt.
Được rồi, mọi thứ đều rõ ràng khi phát triển ở chế độ cục bộ, nhưng làm cách nào để đạt được điều tương tự trên OpenShift?
Máy chủ phát triển trên OpenShift
Nếu bạn còn nhớ, trong , chúng tôi đã xem xét cái gọi là giai đoạn chạy của hình ảnh S2I và thấy rằng theo mặc định, mô-đun phục vụ chịu trách nhiệm phục vụ ứng dụng web của chúng tôi.
Tuy nhiên, nếu bạn xem xét kỹ hơn từ ví dụ đó, nó chứa biến môi trường $NPM_RUN, cho phép bạn thực thi lệnh của mình.
Ví dụ: chúng ta có thể sử dụng mô-đun nodeshift để triển khai ứng dụng của mình:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Lưu ý: Ví dụ trên được viết tắt để minh họa cho ý tưởng chung.
Ở đây, chúng tôi đã thêm biến môi trường NPM_RUN vào quá trình triển khai của mình, biến này yêu cầu bộ thực thi chạy lệnh bắt đầu sợi, lệnh này khởi động máy chủ phát triển React bên trong nhóm OpenShift của chúng tôi.
Nếu bạn nhìn vào nhật ký của một nhóm đang chạy, nó sẽ trông giống như thế này:
Tất nhiên, tất cả điều này sẽ chẳng là gì cho đến khi chúng ta có thể đồng bộ hóa mã cục bộ với mã, mã này cũng được theo dõi các thay đổi nhưng tồn tại trên một máy chủ từ xa.
Đồng bộ hóa mã từ xa và cục bộ
May mắn thay, nodeshift có thể dễ dàng trợ giúp đồng bộ hóa và bạn có thể sử dụng lệnh watch để theo dõi các thay đổi.
Vì vậy, sau khi chạy lệnh triển khai máy chủ phát triển cho ứng dụng của mình, chúng ta có thể sử dụng lệnh sau một cách an toàn:
$ npx nodeshift watch
Do đó, một kết nối sẽ được thực hiện với nhóm đang chạy mà chúng tôi đã tạo trước đó một chút, quá trình đồng bộ hóa các tệp cục bộ của chúng tôi với cụm từ xa sẽ được kích hoạt và các tệp trên hệ thống cục bộ của chúng tôi sẽ bắt đầu được theo dõi các thay đổi.
Do đó, nếu bây giờ chúng ta cập nhật tệp src/App.js, hệ thống sẽ phản ứng với những thay đổi này, sao chép chúng vào cụm từ xa và khởi động máy chủ phát triển, sau đó sẽ cập nhật ứng dụng của chúng ta trong trình duyệt.
Để hoàn thành bức tranh, hãy cho thấy toàn bộ lệnh này trông như thế nào:
$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000
$ npx nodeshift watch --strictSSL=false
Lệnh watch là một bản tóm tắt bên trên lệnh oc rsync, bạn có thể tìm hiểu thêm về cách hoạt động của nó .
Đây là một ví dụ cho React, nhưng phương pháp tương tự có thể được sử dụng với các khung công tác khác, chỉ cần đặt biến môi trường NPM_RUN nếu cần.
Đường ống Openshift
Tiếp theo, chúng ta sẽ nói về một công cụ như OpenShift Pipelines và cách sử dụng nó như một giải pháp thay thế cho các bản dựng theo chuỗi.
Đường ống OpenShift là gì
OpenShift Pipelines là hệ thống phân phối và tích hợp liên tục CI/CD gốc đám mây được thiết kế để tổ chức các quy trình bằng Tekton. Tekton là khung CI/CD gốc Kubernetes mã nguồn mở linh hoạt cho phép bạn tự động triển khai trên nhiều nền tảng khác nhau (Kubernetes, serverless, máy ảo, v.v.) bằng cách trừu tượng hóa từ lớp bên dưới.
Để hiểu bài viết này đòi hỏi một số kiến thức về Pipelines, vì vậy chúng tôi thực sự khuyên bạn nên đọc trước .
Thiết lập môi trường làm việc của bạn
Để chơi với các ví dụ trong bài viết này, trước tiên bạn cần chuẩn bị môi trường làm việc của mình:
- Cài đặt và định cấu hình cụm OpenShift 4. Các ví dụ của chúng tôi sử dụng CodeReady Containers (CRD) cho việc này, bạn có thể tìm thấy hướng dẫn cài đặt cho cụm này .
- Sau khi cụm đã sẵn sàng, bạn cần cài đặt Pipeline Operator trên đó. Đừng sợ, hướng dẫn cài đặt rất dễ dàng .
- Tải về (tkn) .
- Chạy công cụ dòng lệnh create-react-app để tạo một ứng dụng mà sau đó bạn sẽ triển khai (đây là một ứng dụng đơn giản ).
- (Tùy chọn) Sao chép kho lưu trữ để chạy ứng dụng mẫu cục bộ bằng cài đặt npm và sau đó bắt đầu npm.
Kho lưu trữ ứng dụng cũng sẽ có thư mục k8s, thư mục này sẽ chứa Kubernetes/OpenShift YAML được sử dụng để triển khai ứng dụng. Sẽ có Nhiệm vụ, Nhiệm vụ cụm, Tài nguyên và Quy trình mà chúng tôi sẽ tạo trong phần này .
Bắt đầu nào
Bước đầu tiên trong ví dụ của chúng tôi là tạo một dự án mới trong cụm OpenShift. Hãy gọi dự án này là webapp-pipeline và tạo nó bằng lệnh sau:
$ oc new-project webapp-pipeline
Tên dự án này sẽ xuất hiện trong mã sau này, vì vậy nếu bạn quyết định đặt tên khác cho nó, đừng quên chỉnh sửa mã ví dụ cho phù hợp. Bắt đầu từ thời điểm này, chúng ta sẽ không đi từ trên xuống mà là từ dưới lên: nghĩa là trước tiên chúng ta sẽ tạo tất cả các thành phần của băng tải, sau đó mới đến chính băng tải.
Vì vậy, trước hết...
Nhiệm vụ
Hãy tạo một vài nhiệm vụ, sau đó sẽ giúp triển khai ứng dụng trong quy trình của chúng tôi. Tác vụ đầu tiên - apply_manifests_task - chịu trách nhiệm áp dụng YAML của các tài nguyên Kubernetes đó (dịch vụ, triển khai và tuyến đường) nằm trong thư mục k8s của ứng dụng của chúng ta. Nhiệm vụ thứ hai – update_deployment_task – chịu trách nhiệm cập nhật hình ảnh đã được triển khai thành hình ảnh được tạo bởi đường dẫn của chúng tôi.
Đừng lo lắng nếu nó vẫn chưa rõ ràng lắm. Trên thực tế, những tác vụ này giống như các tiện ích và chúng ta sẽ xem xét chúng chi tiết hơn sau. Bây giờ, hãy tạo chúng:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml
Sau đó, bằng cách sử dụng lệnh tkn CLI, chúng ta sẽ kiểm tra xem các tác vụ đã được tạo chưa:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Lưu ý: Đây là những nhiệm vụ cục bộ cho dự án hiện tại của bạn.
Nhiệm vụ cụm
Nhiệm vụ cụm về cơ bản giống như nhiệm vụ đơn giản. Nghĩa là, nó là một tập hợp các bước có thể tái sử dụng được kết hợp theo cách này hay cách khác khi chạy một tác vụ cụ thể. Sự khác biệt là tác vụ cụm có sẵn ở mọi nơi trong cụm. Để xem danh sách các tác vụ cụm được tạo tự động khi thêm Toán tử đường ống, chúng ta sẽ lại sử dụng lệnh tkn CLI:
$ tkn clustertask ls
NAME AGE
buildah 1 day ago
buildah-v0-10-0 1 day ago
jib-maven 1 day ago
kn 1 day ago
maven 1 day ago
openshift-client 1 day ago
openshift-client-v0-10-0 1 day ago
s2i 1 day ago
s2i-go 1 day ago
s2i-go-v0-10-0 1 day ago
s2i-java-11 1 day ago
s2i-java-11-v0-10-0 1 day ago
s2i-java-8 1 day ago
s2i-java-8-v0-10-0 1 day ago
s2i-nodejs 1 day ago
s2i-nodejs-v0-10-0 1 day ago
s2i-perl 1 day ago
s2i-perl-v0-10-0 1 day ago
s2i-php 1 day ago
s2i-php-v0-10-0 1 day ago
s2i-python-3 1 day ago
s2i-python-3-v0-10-0 1 day ago
s2i-ruby 1 day ago
s2i-ruby-v0-10-0 1 day ago
s2i-v0-10-0 1 day ago
Bây giờ hãy tạo hai nhiệm vụ cụm. Đầu tiên sẽ tạo hình ảnh S2I và gửi nó đến sổ đăng ký OpenShift nội bộ; thứ hai là xây dựng hình ảnh của chúng tôi dựa trên NGINX, sử dụng ứng dụng mà chúng tôi đã xây dựng làm nội dung.
Tạo và gửi hình ảnh
Khi tạo tác vụ đầu tiên, chúng ta sẽ lặp lại những gì chúng ta đã làm trong bài viết trước về các tập hợp được liên kết. Hãy nhớ lại rằng chúng tôi đã sử dụng hình ảnh S2I (ubi8-s2i-web-app) để “xây dựng” ứng dụng của mình và kết thúc bằng một hình ảnh được lưu trữ trong sổ đăng ký nội bộ OpenShift. Bây giờ chúng ta sẽ sử dụng hình ảnh ứng dụng web S2I này để tạo DockerFile cho ứng dụng của mình, sau đó sử dụng Buildah để thực hiện quá trình xây dựng thực tế và đẩy hình ảnh kết quả vào sổ đăng ký nội bộ OpenShift, vì đó chính xác là những gì OpenShift thực hiện khi bạn triển khai ứng dụng của mình bằng NodeShift .
Làm thế nào chúng tôi biết tất cả những điều này, bạn hỏi? Từ , chúng tôi vừa sao chép và sửa đổi nó cho chính mình.
Vì vậy, bây giờ hãy tạo tác vụ cụm s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Chúng tôi sẽ không phân tích chi tiết điều này mà chỉ tập trung vào tham số OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Theo mặc định, tham số này bằng với build, đây là nơi React đặt nội dung đã được lắp ráp. Các khung công tác khác sử dụng các đường dẫn khác nhau, ví dụ: trong Ember, nó là dist. Đầu ra của tác vụ cụm đầu tiên của chúng tôi sẽ là một hình ảnh chứa HTML, JavaScript và CSS mà chúng tôi đã thu thập.
Xây dựng hình ảnh dựa trên NGINX
Đối với nhiệm vụ cụm thứ hai của chúng tôi, nó sẽ xây dựng hình ảnh dựa trên NGINX cho chúng tôi, sử dụng nội dung của ứng dụng mà chúng tôi đã xây dựng. Về cơ bản, đây là phần trước mà chúng ta đã xem xét các bản dựng theo chuỗi.
Để thực hiện việc này, chúng tôi - giống hệt như ở trên - sẽ tạo một tác vụ cụm webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Nếu bạn nhìn vào mã của các tác vụ cụm này, bạn có thể thấy rằng nó không chỉ định kho Git mà chúng tôi đang làm việc hoặc tên của các hình ảnh chúng tôi đang tạo. Chúng tôi chỉ xác định chính xác những gì chúng tôi đang chuyển sang Git hoặc một hình ảnh nhất định nơi hình ảnh cuối cùng sẽ được xuất ra. Đó là lý do tại sao các tác vụ cụm này có thể được sử dụng lại khi làm việc với các ứng dụng khác.
Và ở đây chúng ta duyên dáng chuyển sang điểm tiếp theo...
Tài nguyên
Vì vậy, như chúng ta vừa nói, các tác vụ cụm phải càng chung chung càng tốt, nên chúng ta cần tạo các tài nguyên sẽ được sử dụng làm đầu vào (kho Git) và làm đầu ra (hình ảnh cuối cùng). Tài nguyên đầu tiên chúng ta cần là Git, nơi chứa ứng dụng của chúng ta, đại loại như thế này:
# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: web-application-repo
spec:
type: git
params:
- name: url
value: https://github.com/nodeshift-starters/react-pipeline-example
- name: revision
value: master
Ở đây PipelineResource thuộc loại git. Khóa url trong phần thông số trỏ đến một kho lưu trữ cụ thể và chỉ định nhánh chính (điều này là tùy chọn, nhưng chúng tôi viết nó cho đầy đủ).
Bây giờ chúng ta cần tạo một tài nguyên cho hình ảnh để lưu kết quả của tác vụ s2i-web-app, việc này được thực hiện như sau:
# This resource is the result of running "npm run build", the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: built-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest
Ở đây, PipelineResource thuộc loại hình ảnh và giá trị của tham số url trỏ đến Sổ đăng ký hình ảnh OpenShift bên trong, cụ thể là giá trị nằm trong không gian tên webapp-pipeline. Đừng quên thay đổi cài đặt này nếu bạn đang sử dụng một không gian tên khác.
Và cuối cùng, tài nguyên cuối cùng chúng ta cần cũng sẽ là loại hình ảnh và đây sẽ là hình ảnh NGINX cuối cùng sẽ được sử dụng trong quá trình triển khai:
# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: runtime-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest
Một lần nữa, hãy lưu ý rằng tài nguyên này lưu trữ hình ảnh trong sổ đăng ký OpenShift nội bộ trong không gian tên webapp-pipeline.
Để tạo tất cả các tài nguyên này cùng một lúc, chúng tôi sử dụng lệnh tạo:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Bạn có thể đảm bảo rằng các tài nguyên đã được tạo như thế này:
$ tkn resource ls
Đường ống băng tải
Bây giờ chúng ta đã có tất cả các thành phần cần thiết, hãy tập hợp một quy trình từ chúng bằng cách tạo nó bằng lệnh sau:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Nhưng trước khi chạy lệnh này, chúng ta hãy xem xét các thành phần này. Đầu tiên là cái tên:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Sau đó, trong phần thông số kỹ thuật, chúng ta thấy dấu hiệu về các tài nguyên mà chúng ta đã tạo trước đó:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Sau đó, chúng tôi tạo ra các nhiệm vụ mà quy trình của chúng tôi cần hoàn thành. Trước hết, nó phải thực thi tác vụ s2i-web-app mà chúng ta đã tạo:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Tác vụ này lấy các tham số đầu vào (tài nguyên gir) và đầu ra (tài nguyên hình ảnh ứng dụng web). Chúng tôi cũng chuyển cho nó một tham số đặc biệt để nó không xác minh TLS vì chúng tôi đang sử dụng chứng chỉ tự ký:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Nhiệm vụ tiếp theo gần như giống nhau, chỉ có điều ở đây nhiệm vụ cụm webapp-build-runtime mà chúng tôi đã tạo được gọi là:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Giống như nhiệm vụ trước, chúng tôi chuyển vào một tài nguyên, nhưng bây giờ nó là hình ảnh ứng dụng web được xây dựng sẵn (đầu ra của nhiệm vụ trước đó của chúng tôi). Và ở đầu ra, chúng tôi lại thiết lập hình ảnh. Vì tác vụ này phải được thực thi sau tác vụ trước nên chúng tôi thêm trường runAfter:
resources:
inputs:
- name: image
resource: built-web-application-image
outputs:
- name: image
resource: runtime-web-application-image
params:
- name: TLSVERIFY
value: "false"
runAfter:
- build-web-application
Hai tác vụ tiếp theo chịu trách nhiệm sử dụng dịch vụ, định tuyến và triển khai các tệp YAML nằm trong thư mục k8s của ứng dụng web của chúng tôi, đồng thời cập nhật hoạt động triển khai này khi tạo hình ảnh mới. Chúng tôi đã xác định hai nhiệm vụ cụm này ở đầu bài viết.
Khởi động băng tải
Vì vậy, tất cả các phần trong quy trình của chúng tôi đã được tạo và chúng tôi sẽ chạy nó bằng lệnh sau:
$ tkn pipeline start build-and-deploy-react
Ở giai đoạn này, dòng lệnh được sử dụng một cách tương tác và bạn cần chọn các tài nguyên thích hợp để đáp ứng từng yêu cầu của nó: đối với tài nguyên git, chọn web-application-repo, sau đó đối với tài nguyên hình ảnh đầu tiên, ứng dụng web được xây dựng -image, và cuối cùng, đối với tài nguyên hình ảnh thứ hai –runtime-web-application-image:
? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr
Bây giờ hãy kiểm tra trạng thái của đường ống bằng lệnh sau:
$ tkn pipeline logs -f
Khi quy trình đã bắt đầu và ứng dụng đã được triển khai, chúng tôi có thể yêu cầu lộ trình đã xuất bản bằng lệnh sau:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Để hình dung rõ hơn, bạn có thể xem quy trình của chúng tôi ở chế độ Nhà phát triển của bảng điều khiển web trong phần Đường ống, như thể hiện trong hình. 1.
Hình.1. Xem xét các đường ống đang chạy.
Nhấp vào một đường ống đang chạy sẽ hiển thị các chi tiết bổ sung, như trong Hình 2.
Cơm. 2. Thông tin bổ sung về đường ống.
Sau khi biết thêm thông tin, bạn có thể thấy các ứng dụng đang chạy trong giao diện topology, như thể hiện trong hình 3.
Hình 3. Đã khởi động nhóm.
Nhấp vào vòng tròn ở góc trên bên phải của biểu tượng sẽ mở ứng dụng của chúng tôi, như trong Hình 4.
Cơm. 4. Chạy ứng dụng React.
Kết luận
Vì vậy, chúng tôi đã hướng dẫn cách chạy máy chủ phát triển cho ứng dụng của bạn trên OpenShift và đồng bộ hóa nó với hệ thống tệp cục bộ. Chúng tôi cũng đã xem xét cách mô phỏng mẫu xây dựng theo chuỗi bằng cách sử dụng Đường ống OpenShift. Tất cả các mã ví dụ từ bài viết này có thể được tìm thấy .
Tài nguyên bổ sung (EN)
- Sách điện tử miễn phí
- Xem thêm bài viết trên trên trang web Red Hat
Thông báo về hội thảo trực tuyến sắp tới
Chúng tôi đang bắt đầu một loạt hội thảo trực tuyến vào thứ Sáu về trải nghiệm gốc bằng cách sử dụng Nền tảng vùng chứa OpenShift của Red Hat và Kubernetes:
Nguồn: www.habr.com