Chào mọi người! Đây là bài đăng thứ hai 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 bài đăng trước, chúng tôi đã đề cập một chút đến các khả năng của hình ảnh trình tạo S2I (nguồn-hình ảnh) mới, được thiết kế để xây dựng và triển khai các ứng dụng web hiện đại trên nền tảng OpenShift. Sau đó, chúng ta quan tâm đến chủ đề triển khai nhanh một ứng dụng và hôm nay chúng ta sẽ xem cách sử dụng hình ảnh S2I làm hình ảnh trình tạo “thuần túy” và kết hợp nó với các tập hợp OpenShift có liên quan.
Hình ảnh trình xây dựng sạch sẽ
Như chúng tôi đã đề cập trong Phần XNUMX, hầu hết các ứng dụng web hiện đại đều có cái gọi là giai đoạn xây dựng, giai đoạn này thường thực hiện các hoạt động như dịch mã, nối nhiều tệp và thu nhỏ. Các tệp thu được từ các hoạt động này - và đây là HTML, JavaScript và CSS tĩnh - được lưu trữ trong thư mục đầu ra. Vị trí của thư mục này thường phụ thuộc vào công cụ xây dựng nào đang được sử dụng và đối với React, đây sẽ là thư mục ./build (chúng ta sẽ quay lại vấn đề này chi tiết hơn bên dưới).
Nguồn-hình ảnh (S2I)
Trong bài đăng này, chúng tôi không đề cập đến chủ đề “S2I là gì và cách sử dụng nó” (bạn có thể đọc thêm về chủ đề này ), nhưng điều quan trọng là phải hiểu rõ về hai bước trong quy trình này để hiểu chức năng của hình ảnh Web App Builder.
Giai đoạn lắp ráp
Giai đoạn lắp ráp có bản chất rất giống với những gì xảy ra khi bạn chạy docker build và kết thúc bằng một hình ảnh Docker mới. Theo đó, giai đoạn này xảy ra khi bắt đầu xây dựng trên nền tảng OpenShift.
Trong trường hợp hình ảnh Trình tạo ứng dụng web, nó chịu trách nhiệm cài đặt các phần phụ thuộc của ứng dụng của bạn và chạy bản dựng. . Theo mặc định, hình ảnh trình xây dựng sử dụng cấu trúc npm run build, nhưng điều này có thể bị ghi đè thông qua biến môi trường NPM_BUILD.
Như chúng tôi đã nói trước đó, vị trí của ứng dụng đã hoàn thiện, đã được xây dựng phụ thuộc vào công cụ bạn sử dụng. Ví dụ: trong trường hợp React, đây sẽ là thư mục ./build và đối với các ứng dụng Angular, nó sẽ là thư mục project_name/dist. Và, như đã trình bày trong bài trước, vị trí của thư mục đầu ra, được đặt thành xây dựng theo mặc định, có thể được ghi đè thông qua biến môi trường OUTPUT_DIR. Chà, vì vị trí của thư mục đầu ra khác nhau giữa các khung, bạn chỉ cần sao chép đầu ra được tạo vào thư mục tiêu chuẩn trong ảnh, cụ thể là /opt/apt-root/output. Điều này rất quan trọng để hiểu phần còn lại của bài viết này, nhưng bây giờ chúng ta hãy xem nhanh giai đoạn tiếp theo - giai đoạn chạy.
giai đoạn chạy
Giai đoạn này xảy ra khi lệnh gọi docker run được thực hiện trên hình ảnh mới được tạo trong giai đoạn lắp ráp. Điều tương tự cũng xảy ra khi triển khai trên nền tảng OpenShift. Mặc định sử dụng để phục vụ nội dung tĩnh nằm trong thư mục đầu ra tiêu chuẩn ở trên.
Phương pháp này phù hợp để triển khai nhanh các ứng dụng, nhưng nhìn chung không nên phân phát nội dung tĩnh theo cách này. Chà, vì trên thực tế, chúng tôi chỉ phục vụ nội dung tĩnh nên chúng tôi không cần cài đặt Node.js bên trong hình ảnh của mình - một máy chủ web là đủ.
Nói cách khác, khi lắp ráp chúng ta cần một thứ, khi thực thi chúng ta cần một thứ khác. Trong tình huống này, các bản dựng theo chuỗi sẽ có ích.
Xây dựng theo chuỗi
Đây là những gì họ viết về trong tài liệu OpenShift:
“Hai tập hợp có thể được liên kết với nhau, trong đó một tập hợp tạo ra một thực thể được biên dịch và tập hợp còn lại lưu trữ thực thể đó trong một hình ảnh riêng biệt được sử dụng để chạy thực thể đó.”
Nói cách khác, chúng ta có thể sử dụng hình ảnh Web App Builder để chạy bản dựng của mình, sau đó sử dụng hình ảnh máy chủ web, cùng NGINX, để phân phát nội dung của chúng ta.
Do đó, chúng ta có thể sử dụng hình ảnh Web App Builder làm trình tạo "thuần túy" và đồng thời có một hình ảnh thời gian chạy nhỏ.
Bây giờ hãy xem xét điều này với một ví dụ cụ thể.
Để đào tạo, chúng tôi sẽ sử dụng , được tạo bằng công cụ dòng lệnh create-react-app.
Nó sẽ giúp chúng ta kết hợp mọi thứ lại với nhau .
Hãy xem tệp này chi tiết hơn và bắt đầu với phần tham số.
parameters:
- name: SOURCE_REPOSITORY_URL
description: The source URL for the application
displayName: Source URL
required: true
- name: SOURCE_REPOSITORY_REF
description: The branch name for the application
displayName: Source Branch
value: master
required: true
- name: SOURCE_REPOSITORY_DIR
description: The location within the source repo of the application
displayName: Source Directory
value: .
required: true
- name: OUTPUT_DIR
description: The location of the compiled static files from your web apps builder
displayName: Output Directory
value: build
required: false
Mọi thứ ở đây khá rõ ràng, nhưng cần chú ý đến tham số OUTPUT_DIR. Đối với ứng dụng React trong ví dụ của chúng tôi, không có gì phải lo lắng, vì React sử dụng giá trị mặc định làm thư mục đầu ra, nhưng trong trường hợp Angular hoặc thứ gì khác, tham số này sẽ cần được thay đổi nếu cần.
Bây giờ chúng ta hãy xem phần ImageStreams.
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-builder // 1
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-runtime // 2
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: web-app-builder-runtime // 3
spec:
tags:
- name: latest
from:
kind: DockerImage
name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
kind: ImageStream
metadata:
name: nginx-image-runtime // 4
spec:
tags:
- name: latest
from:
kind: DockerImage
name: 'centos/nginx-112-centos7:latest'
Hãy nhìn vào hình ảnh thứ ba và thứ tư. Cả hai đều được định nghĩa là Docker image và bạn có thể thấy rõ chúng đến từ đâu.
Hình ảnh thứ ba là web-app-builder và nó xuất phát từ nodeshift/ubi8-s2i-web-app được gắn thẻ 10.x trên .
Thứ tư là hình ảnh NGINX (phiên bản 1.12) với thẻ mới nhất trên .
Bây giờ chúng ta hãy nhìn vào hai hình ảnh đầu tiên. Cả hai đều trống khi bắt đầu và chỉ được tạo trong giai đoạn xây dựng. Hình ảnh đầu tiên, Reac-web-app-builder, sẽ là kết quả của bước lắp ráp sẽ kết hợp hình ảnh thời gian chạy của trình tạo ứng dụng web và mã nguồn của chúng tôi. Đó là lý do tại sao chúng tôi thêm “-builder” vào tên của hình ảnh này.
Hình ảnh thứ hai - Reac-web-app-runtime - sẽ là kết quả của việc kết hợp nginx-image-runtime và một số tệp từ hình ảnh Reac-web-app-builder. Hình ảnh này cũng sẽ được sử dụng trong quá trình triển khai và sẽ chỉ chứa máy chủ web và HTML, JavaScript, CSS tĩnh của ứng dụng của chúng tôi.
Bối rối? Bây giờ chúng ta hãy xem cấu hình bản dựng và nó sẽ trở nên rõ ràng hơn một chút.
Mẫu của chúng tôi có hai cấu hình xây dựng. Đây là cái đầu tiên và nó khá chuẩn:
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-builder
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-builder:latest // 1
source: // 2
git:
uri: ${SOURCE_REPOSITORY_URL}
ref: ${SOURCE_REPOSITORY_REF}
contextDir: ${SOURCE_REPOSITORY_DIR}
type: Git
strategy:
sourceStrategy:
env:
- name: OUTPUT_DIR // 3
value: ${OUTPUT_DIR}
from:
kind: ImageStreamTag
name: web-app-builder-runtime:latest // 4
incremental: true // 5
type: Source
triggers: // 6
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- imageChange: {}
type: ImageChange
Như bạn có thể thấy, dòng có nhãn 1 cho biết kết quả của bản dựng này sẽ được đặt trong cùng một hình ảnh trình tạo ứng dụng web phản ứng mà chúng ta đã thấy trước đó một chút trong phần ImageStreams.
Dòng có nhãn 2 cho bạn biết nơi lấy mã. Trong trường hợp của chúng tôi, đây là kho lưu trữ git và thư mục vị trí, ref và ngữ cảnh được xác định bởi các tham số chúng tôi đã thấy ở trên.
Dòng có nhãn 3 là dòng chúng ta đã thấy trong phần thông số. Nó thêm biến môi trường OUTPUT_DIR, trong ví dụ của chúng tôi là build.
Dòng có nhãn 4 cho biết sử dụng hình ảnh thời gian chạy của trình tạo ứng dụng web mà chúng ta đã thấy trong phần ImageStream.
Dòng có nhãn 5 cho biết rằng chúng tôi muốn sử dụng bản dựng tăng dần nếu hình ảnh S2I hỗ trợ nó và hình ảnh Trình tạo ứng dụng web cũng hỗ trợ. Ở lần khởi chạy đầu tiên, sau khi giai đoạn lắp ráp hoàn tất, image sẽ lưu thư mục node_modules vào file lưu trữ. Sau đó, trong những lần chạy tiếp theo, hình ảnh sẽ chỉ giải nén thư mục này để giảm thời gian xây dựng.
Và cuối cùng, dòng có nhãn 6 chỉ là một vài kích hoạt để làm cho bản dựng chạy tự động mà không cần can thiệp thủ công khi có gì đó thay đổi.
Nhìn chung đây là một cấu hình build khá chuẩn.
Bây giờ chúng ta hãy xem cấu hình bản dựng thứ hai. Nó rất giống với cái đầu tiên, nhưng có một điểm khác biệt quan trọng.
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-runtime
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-runtime:latest // 1
source: // 2
type: Image
images:
- from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 3
paths:
- sourcePath: /opt/app-root/output/. // 4
destinationDir: . // 5
strategy: // 6
sourceStrategy:
from:
kind: ImageStreamTag
name: nginx-image-runtime:latest
incremental: true
type: Source
triggers:
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- type: ImageChange
imageChange: {}
- type: ImageChange
imageChange:
from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 7
Vì vậy, cấu hình bản dựng thứ hai là Reac-web-app-runtime và nó bắt đầu khá chuẩn.
Dòng có nhãn 1 không có gì mới - nó chỉ đơn giản nói rằng kết quả xây dựng được đưa vào hình ảnh thời gian chạy ứng dụng web phản ứng.
Dòng có nhãn 2, như trong cấu hình trước đó, cho biết nơi lấy mã nguồn. Nhưng lưu ý rằng ở đây chúng ta đang nói rằng nó được lấy từ hình ảnh. Hơn nữa, từ hình ảnh mà chúng ta vừa tạo - từ Reac-web-app-builder (được biểu thị ở dòng có nhãn 3). Các tệp chúng tôi muốn sử dụng nằm bên trong hình ảnh và vị trí của chúng được đặt ở dòng có nhãn 4, trong trường hợp của chúng tôi là /opt/app-root/output/. Nếu bạn còn nhớ, đây là nơi lưu trữ các tệp được tạo dựa trên kết quả xây dựng ứng dụng của chúng tôi.
Thư mục đích được chỉ định trong thuật ngữ có nhãn 5 chỉ đơn giản là thư mục hiện tại (hãy nhớ rằng đây là tất cả, chạy bên trong một thứ kỳ diệu nào đó có tên là OpenShift chứ không phải trên máy tính cục bộ của bạn).
Phần chiến lược – dòng có nhãn 6 – cũng tương tự như cấu hình bản dựng đầu tiên. Chỉ lần này chúng ta sẽ sử dụng nginx-image-runtime mà chúng ta đã thấy trong phần ImageStream.
Cuối cùng, dòng có nhãn 7 là một phần của trình kích hoạt sẽ kích hoạt bản dựng này mỗi khi hình ảnh trình tạo ứng dụng web phản ứng thay đổi.
Mặt khác, mẫu này chứa cấu hình triển khai khá chuẩn cũng như những thứ liên quan đến dịch vụ và tuyến đường, nhưng chúng tôi sẽ không đi sâu vào chi tiết đó. Xin lưu ý rằng hình ảnh sẽ được triển khai là hình ảnh thời gian chạy ứng dụng web phản ứng.
Triển khai ứng dụng
Vì vậy, bây giờ chúng ta đã xem mẫu, hãy xem cách sử dụng nó để triển khai một ứng dụng.
Chúng ta có thể sử dụng công cụ máy khách OpenShift có tên oc để triển khai mẫu của mình:
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f
$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app
Lệnh đầu tiên trong ảnh chụp màn hình ở trên là một cách kỹ thuật có chủ ý để tìm mẫu./openshiftio/application.yaml.
Lệnh thứ hai chỉ đơn giản là tạo một ứng dụng mới dựa trên mẫu này.
Sau khi các lệnh này hoạt động, chúng ta sẽ thấy rằng chúng ta có hai tập hợp:
Và quay lại màn hình Tổng quan, chúng ta sẽ thấy pod đã khởi chạy:
Nhấp vào liên kết và chúng ta sẽ được đưa đến ứng dụng của mình, đây là trang Ứng dụng React mặc định:
Bổ sung năm 1
Đối với những người yêu thích Angular, chúng tôi cũng có .
Mẫu ở đây giống nhau, ngoại trừ biến OUTPUT_DIR.
Bổ sung năm 2
Trong bài viết này chúng tôi sử dụng NGINX làm web server nhưng việc thay thế nó bằng Apache khá dễ dàng, chỉ cần thay đổi template trong file trên .
Kết luận
Trong phần đầu tiên của loạt bài này, chúng tôi đã giới thiệu cách triển khai nhanh chóng các ứng dụng web hiện đại trên nền tảng OpenShift. Hôm nay chúng ta đã xem xét chức năng của hình ảnh Ứng dụng Web và cách kết hợp nó với một máy chủ web thuần túy như NGINX bằng cách sử dụng các bản dựng theo chuỗi để tạo ra một bản dựng ứng dụng sẵn sàng sản xuất hơn. Trong bài viết tiếp theo và cuối cùng của loạt bài này, chúng tôi sẽ 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à đảm bảo đồng bộ hóa các tệp cục bộ và từ xa.
Nội dung của loạt bài này
- Một phần của 1: ;
- Phần 2: Cách sử dụng hình ảnh S2I mới với hình ảnh máy chủ HTTP hiện có, chẳng hạn như NGINX, sử dụng các tập hợp OpenShift được liên kết để triển khai sản xuất;
- Phần 3: 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ộ.
Tôi là người nước ngoài
- Sách điện tử miễn phí .
- Thông tin về .
Nguồn: www.habr.com