Di postingan sebelumnya, kami sedikit menyinggung tentang kemampuan image builder S2I (source-to-image) baru, yang dirancang untuk membangun dan menerapkan aplikasi web modern pada platform OpenShift. Kemudian kami tertarik pada topik penerapan aplikasi cepat, tetapi hari ini kami akan melihat cara menggunakan gambar S2I sebagai gambar pembuat "bersih" dan menggabungkannya dengan rakitan OpenShift terkait.
Gambar pembangun bersih
Seperti yang kami sebutkan di bagian pertama, sebagian besar aplikasi web modern memiliki apa yang disebut tahap build, yang biasanya melakukan operasi seperti transpilasi kode, penggabungan beberapa file, dan minifikasi. File yang dihasilkan - HTML statis, JavaScript, dan CSS - ditambahkan ke folder output. Lokasi folder ini biasanya bergantung pada alat build apa yang digunakan, dan untuk React ini adalah folder ./build (kita akan membahasnya lebih detail di bawah).
Sumber-ke-Gambar (S2I)
Dalam posting ini, kita sama sekali tidak tentang topik "apa itu S2I dan bagaimana menggunakannya" (Anda dapat membaca lebih lanjut tentang itu di sini ), tetapi penting untuk memperjelas tentang dua tahap proses ini untuk memahami apa yang dilakukan gambar Pembuat Aplikasi Web.
Fase perakitan
Langkah perakitan secara inheren sangat mirip dengan apa yang terjadi ketika Anda menjalankan pembuatan buruh pelabuhan dan berakhir dengan image Docker baru. Karenanya, tahap ini terjadi saat memulai build di platform OpenShift.
Dalam kasus image Pembuat Aplikasi Web, skrip assemble bertanggung jawab untuk menginstal dependensi aplikasi Anda dan menjalankan build . Secara default, gambar pembuat menggunakan konstruksi npm run build, tetapi dapat diganti melalui variabel lingkungan NPM_BUILD.
Seperti yang kami katakan sebelumnya, lokasi aplikasi yang sudah selesai dan sudah dibangun tergantung pada alat mana yang Anda gunakan. Misalnya, dalam kasus React, ini akan menjadi folder. / Build, dan untuk aplikasi Angular, folder project_name / dist. Dan, seperti yang ditunjukkan di posting terakhir, lokasi direktori output, yang ditetapkan untuk dibangun secara default, dapat diganti melalui variabel lingkungan OUTPUT_DIR. Nah, karena lokasi folder output berbeda dari satu framework ke framework lainnya, Anda cukup menyalin output yang dihasilkan ke folder standar pada gambar, yaitu / opt / apt-root / output. Ini penting untuk memahami sisa artikel ini, tetapi untuk saat ini mari kita lihat sekilas ke tahap selanjutnya - run (tahap proses).
Jalankan fase
Tahap ini terjadi ketika buruh pelabuhan dipanggil pada gambar baru yang dibuat selama tahap perakitan. Itu juga terjadi saat menerapkan di platform OpenShift. Secara default, skrip run menggunakan modul serve untuk menyajikan konten statis yang terletak di direktori keluaran standar di atas.
Metode ini bagus untuk menerapkan aplikasi dengan cepat, tetapi umumnya tidak disarankan untuk menyajikan konten statis dengan cara ini. Nah, karena kami benar-benar hanya menyajikan konten statis, Node.js yang dipasang di dalam gambar kami tidak diperlukan - server web sudah cukup.
Dengan kata lain, kita membutuhkan satu hal selama perakitan, dan satu lagi selama eksekusi. Di sinilah build berantai berguna.
Bangunan dirantai
Inilah yang mereka tulis tentang build berantai di dokumentasi OpenShift:
"Dua rakitan dapat dihubungkan satu sama lain, dengan satu menghasilkan entitas yang dikompilasi, dan yang lainnya menghosting entitas dalam gambar terpisah yang digunakan untuk menjalankan entitas itu."
Dengan kata lain, kita dapat menggunakan image Pembuat Aplikasi Web untuk menjalankan build kita dan kemudian menggunakan image server web, NGINX, untuk menyajikan konten kita.
Jadi, kita dapat menggunakan gambar Pembuat Aplikasi Web sebagai pembuat "murni" dan masih memiliki gambar waktu proses yang kecil.
Sekarang mari kita lihat ini dengan contoh spesifik.
Untuk tutorial ini, kita akan menggunakan aplikasi React sederhana yang dibuat dengan alat baris perintah create-react-app. File template OpenShift
akan membantu kita menggabungkan semuanya . Mari kita lihat lebih dekat file ini dan mulai dengan bagian parameter.
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
Semuanya cukup jelas di sini, tetapi Anda harus memperhatikan parameter OUTPUT_DIR. Untuk aplikasi React dari contoh kami, tidak ada yang perlu dikhawatirkan, karena React menggunakan nilai default sebagai folder output, tetapi dalam kasus Angular atau yang lainnya, parameter ini perlu diubah sesuai kebutuhan.
Sekarang mari kita lihat bagian 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'
Perhatikan gambar ketiga dan keempat. Keduanya didefinisikan sebagai image Docker, dan Anda dapat melihat dengan jelas dari mana asalnya.
Gambar ketiga adalah web-app-builder dan berasal dari nodeshift / ubi8-s2i-web-app dengan tag 10.x di hub Docker .
Yang keempat adalah gambar NGINX (versi 1.12) dengan tag terbaru di hub Docker .
Sekarang mari kita lihat dua gambar pertama. Keduanya kosong di awal dan hanya dibuat pada fase build. Gambar pertama, react-web-app-builder, akan menjadi hasil dari langkah perakitan yang akan menggabungkan gambar web-app-builder-runtime dan kode sumber kita. Itulah mengapa kami menempatkan "-builder" di nama gambar ini.
Gambar kedua - react-web-app-runtime - akan menjadi hasil dari menggabungkan nginx-image-runtime dan beberapa file dari image react-web-app-builder. Gambar ini juga akan digunakan selama penerapan dan hanya akan berisi server web dan HTML statis, JavaScript, CSS aplikasi kita.
Bingung? Sekarang mari kita lihat konfigurasi build dan itu akan menjadi sedikit lebih jelas.
Ada dua konfigurasi build di template kami. Ini yang pertama, dan ini cukup standar:
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
Seperti yang Anda lihat, baris berlabel 1 mengatakan bahwa hasil dari build ini akan ditempatkan di gambar react-web-app-builder yang sama seperti yang kita lihat sebelumnya di bagian ImageStreams.
Baris berlabel 2 memberi tahu Anda dari mana mendapatkan kode. Dalam kasus kami, ini adalah repositori git, dan lokasi, ref, dan folder konteks ditentukan oleh parameter yang telah kami lihat di atas.
Garis berlabel 3 sudah terlihat di bagian parameter. Ia menambahkan variabel lingkungan OUTPUT_DIR, yang dibangun dalam contoh kita.
Baris berlabel 4 mengatakan untuk menggunakan gambar web-app-builder-runtime yang sudah kita lihat di bagian ImageStream.
Baris berlabel 5 mengatakan kita ingin menggunakan build inkremental jika gambar S2I mendukungnya dan gambar Pembuat Aplikasi Web mendukungnya. Pada peluncuran pertama, setelah menyelesaikan tahap perakitan, gambar akan menyimpan folder node_modules ke file arsip. Kemudian, pada proses selanjutnya, gambar hanya akan mengekstrak folder itu untuk mempersingkat waktu pembuatan.
Dan terakhir, baris berlabel 6 hanyalah beberapa trigger sehingga build dimulai secara otomatis, tanpa intervensi manual, ketika ada perubahan.
Secara keseluruhan, ini adalah konfigurasi build yang cukup standar.
Sekarang mari kita lihat konfigurasi build kedua. Ini sangat mirip dengan yang pertama, tetapi ada satu perbedaan penting.
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
Jadi konfigurasi build kedua adalah react-web-app-runtime, dan ini dimulai dengan standar yang cukup.
Baris berlabel 1 bukanlah hal baru - hanya dikatakan bahwa hasil build sedang dimasukkan ke dalam gambar react-web-app-runtime.
Baris berlabel 2, seperti pada konfigurasi sebelumnya, menunjukkan dari mana mendapatkan kode sumber. Tetapi perhatikan bahwa di sini kami mengatakan bahwa itu berasal dari sebuah gambar. Selain itu, dari gambar yang baru saja kita buat - dari react-web-app-builder (ditunjukkan pada baris berlabel 3). File yang ingin kita gunakan terletak di dalam gambar dan lokasinya ditentukan di sana pada baris berlabel 4, dalam kasus kita itu adalah / opt / app-root / output /. Jika anda ingat, disinilah file-file yang dihasilkan dari hasil membangun aplikasi kita ditempatkan.
Folder tujuan, ditentukan dalam baris berlabel 5, hanyalah direktori saat ini (ingat, ini semua berputar di dalam beberapa hal ajaib yang disebut OpenShift, bukan di komputer lokal Anda).
Bagian strategi - baris berlabel 6 - juga mirip dengan konfigurasi build pertama. Hanya kali ini kita akan menggunakan nginx-image-runtime, yang telah kita lihat di bagian ImageStream.
Terakhir, baris berlabel 7 adalah bagian pemicu yang mengaktifkan build ini setiap kali gambar react-web-app-builder berubah.
Sisa dari template ini berisi konfigurasi penerapan yang cukup standar, serta hal-hal yang berhubungan dengan layanan dan rute, tetapi kami tidak akan membahasnya. Perhatikan bahwa gambar yang akan di-deploy adalah gambar react-web-app-runtime.
Terapkan aplikasi
Jadi, setelah melihat templatnya, mari kita lihat bagaimana menggunakannya untuk menerapkan aplikasi.
Kita dapat menggunakan alat klien OpenShift yang disebut oc untuk menerapkan template kita:
$ 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
Perintah pertama pada tangkapan layar di atas adalah cara rekayasa yang sengaja untuk menemukan templat. / Openshiftio / application.yaml.
Perintah kedua hanya membuat aplikasi baru berdasarkan template ini.
Setelah perintah ini dijalankan, kita akan melihat bahwa kita memiliki dua rakitan:
Dan kembali ke layar Ringkasan, kita akan melihat pod diluncurkan:
Klik pada link tersebut dan kita akan dibawa ke aplikasi kita, yang merupakan halaman Aplikasi React default:
Lampiran 1
Untuk pecinta Angular, kami juga memiliki aplikasi sampel .
Template di sini sama, kecuali untuk variabel OUTPUT_DIR.
Lampiran 2
Pada artikel kali ini kita telah menggunakan NGINX sebagai web server, selain itu cukup mudah untuk menggantinya dengan Apache, tinggal mengganti gambar template file NGINX di jalan Apache .
Kesimpulan
Di bagian pertama dari seri ini, kami menunjukkan kepada Anda cara menerapkan aplikasi web modern dengan cepat di platform OpenShift. Hari ini kita melihat apa yang membuat gambar Aplikasi Web dan bagaimana itu dapat dikombinasikan dengan server web murni seperti NGINX menggunakan build berantai untuk membuat build aplikasi yang lebih siap produksi. Pada artikel terakhir, artikel terakhir dalam seri ini, kami akan menunjukkan kepada Anda bagaimana menjalankan server pengembangan untuk aplikasi Anda di OpenShift dan menjaga file lokal dan jarak jauh tetap sinkron.
Isi dari seri artikel ini
- Bagian 1: cara menyebarkan aplikasi web modern hanya dalam beberapa langkah ;
- Bagian 2: cara menggunakan image S2I baru bersama dengan image server HTTP yang ada, misalnya, NGINX, menggunakan rakitan OpenShift terkait untuk mengatur penerapan produksi;
- 3: OpenShift .