Halo semua! Ini adalah postingan kedua dalam seri kami yang menunjukkan cara menerapkan aplikasi web modern di Red Hat OpenShift.
Pada postingan sebelumnya, kami sedikit menyinggung kemampuan image pembangun S2I (source-to-image) baru, yang dirancang untuk membangun dan menerapkan aplikasi web modern pada platform OpenShift. Kemudian kami tertarik pada topik penerapan aplikasi dengan cepat, dan hari ini kami akan melihat cara menggunakan gambar S2I sebagai gambar pembuat "murni" dan menggabungkannya dengan rakitan OpenShift terkait.
Bersihkan gambar pembangun
Seperti yang kami sebutkan di Bagian XNUMX, 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 diperoleh dari operasi ini - dan ini adalah HTML statis, JavaScript, dan CSS - disimpan di folder keluaran. Lokasi folder ini biasanya bergantung pada alat build apa yang digunakan, dan untuk React, folder ini adalah folder ./build (kami akan membahasnya lebih detail di bawah).
Sumber-ke-Gambar (S2I)
Pada postingan kali ini kami tidak menyentuh topik “apa itu S2I dan bagaimana cara menggunakannya” (Anda dapat membaca lebih lanjut tentang ini ), namun penting untuk memperjelas dua langkah dalam proses ini untuk memahami fungsi gambar Pembuat Aplikasi Web.
Fase perakitan
Fase perakitan sangat mirip dengan apa yang terjadi ketika Anda menjalankan docker build dan berakhir dengan image Docker baru. Oleh karena itu, tahap ini terjadi ketika memulai pembangunan pada platform OpenShift.
Dalam kasus image Web App Builder, ia bertanggung jawab untuk menginstal dependensi aplikasi Anda dan menjalankan build. . Secara default, gambar pembuat menggunakan konstruk npm run build, tetapi ini dapat diganti melalui variabel lingkungan NPM_BUILD.
Seperti yang kami katakan sebelumnya, lokasi aplikasi yang sudah jadi dan sudah dibangun bergantung pada alat apa yang Anda gunakan. Misalnya, dalam kasus React, folder ini adalah folder ./build, dan untuk aplikasi Angular, folder tersebut adalah folder project_name/dist. Dan, seperti yang telah ditunjukkan pada postingan sebelumnya, lokasi direktori keluaran, yang disetel ke build secara default, dapat diganti melalui variabel lingkungan OUTPUT_DIR. Nah, karena lokasi folder keluaran berbeda dari satu kerangka kerja ke kerangka lainnya, Anda cukup menyalin keluaran yang dihasilkan ke folder standar pada gambar, yaitu /opt/apt-root/output. Hal ini penting untuk memahami sisa artikel ini, tapi untuk saat ini mari kita lihat tahap berikutnya - fase lari.
fase berjalan
Tahap ini terjadi ketika panggilan ke docker run dilakukan pada image baru yang dibuat selama tahap perakitan. Hal yang sama terjadi ketika diterapkan pada platform OpenShift. Bawaan menggunakan untuk menyajikan konten statis yang terletak di direktori keluaran standar di atas.
Metode ini bagus untuk menyebarkan aplikasi dengan cepat, namun umumnya tidak disarankan untuk menyajikan konten statis dengan cara ini. Karena pada kenyataannya kami hanya menyajikan konten statis, kami tidak perlu menginstal Node.js di dalam gambar kami - server web saja sudah cukup.
Dengan kata lain, saat merakit kita membutuhkan satu hal, saat mengeksekusi kita membutuhkan hal lain. Dalam situasi ini, bangunan berantai akan berguna.
Bangunan yang dirantai
Inilah yang mereka tulis dalam dokumentasi OpenShift:
“Dua rakitan dapat dihubungkan bersama, yang satu menghasilkan entitas yang dikompilasi dan yang lainnya menampung entitas tersebut dalam gambar terpisah yang digunakan untuk menjalankan entitas tersebut.”
Dengan kata lain, kita dapat menggunakan image Web App Builder untuk menjalankan build kita, lalu menggunakan image server web, NGINX yang sama, untuk menyajikan konten kita.
Dengan demikian, kita dapat menggunakan image Web App Builder sebagai pembuat "murni" dan pada saat yang sama memiliki image runtime yang kecil.
Sekarang mari kita lihat ini dengan contoh spesifik.
Untuk pelatihan kami akan menggunakan , dibuat menggunakan alat baris perintah create-react-app.
Ini akan membantu kita menyatukan semuanya .
Mari kita lihat file ini lebih detail, 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 di sini cukup jelas, tetapi perlu diperhatikan parameter OUTPUT_DIR. Untuk aplikasi React dalam contoh kita, tidak ada yang perlu dikhawatirkan, karena React menggunakan nilai default sebagai folder keluaran, tetapi dalam kasus Angular atau yang lainnya, parameter ini perlu diubah seperlunya.
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'
Lihatlah 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 yang diberi tag 10.x aktif .
Yang keempat adalah gambar NGINX (versi 1.12) dengan tag terbaru aktif .
Sekarang mari kita lihat dua gambar pertama. Keduanya kosong di awal dan dibuat hanya selama fase pembuatan. Gambar pertama, react-web-app-builder, akan menjadi hasil dari langkah perakitan yang akan menggabungkan gambar runtime web-app-builder- dan kode sumber kita. Itu sebabnya kami menambahkan “-builder” pada nama gambar ini.
Gambar kedua - react-web-app-runtime - akan menjadi hasil penggabungan nginx-image-runtime dan beberapa file dari gambar 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 ini akan menjadi sedikit lebih jelas.
Templat kami memiliki dua konfigurasi build. 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 dengan label 1 mengatakan bahwa hasil build ini akan ditempatkan di gambar react-web-app-builder yang sama seperti yang kita lihat sebelumnya di bagian ImageStreams.
Baris berlabel 2 memberitahu Anda dari mana mendapatkan kode tersebut. 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 adalah apa yang telah kita lihat di bagian parameter. Ia menambahkan variabel lingkungan OUTPUT_DIR, yang dalam contoh kita adalah build.
Baris berlabel 4 mengatakan untuk menggunakan gambar runtime pembuat aplikasi web, yang telah kita lihat di bagian ImageStream.
Baris berlabel 5 mengatakan bahwa kita ingin menggunakan build inkremental jika image S2I mendukungnya, dan image Web App Builder mendukungnya. Pada peluncuran pertama, setelah tahap perakitan selesai, gambar akan menyimpan folder node_modules ke dalam file arsip. Kemudian, pada proses berikutnya, gambar akan mengekstrak folder ini untuk mengurangi waktu pembuatan.
Dan terakhir, baris berlabel 6 hanyalah beberapa pemicu untuk membuat build berjalan 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 awalnya cukup standar.
Baris berlabel 1 bukanlah hal baru - baris ini hanya mengatakan bahwa hasil build dimasukkan ke dalam gambar react-web-app-runtime.
Baris berlabel 2, seperti pada konfigurasi sebelumnya, menunjukkan dari mana mendapatkan kode sumber. Namun perhatikan bahwa di sini kita mengatakan bahwa itu diambil dari gambar. Apalagi dari gambar yang baru saja kita buat - dari react-web-app-builder (ditunjukkan pada baris berlabel 3). File yang ingin kita gunakan ada di dalam gambar dan lokasinya diatur pada baris berlabel 4, dalam kasus kita adalah /opt/app-root/output/. Jika anda ingat, disinilah disimpan file-file yang dihasilkan berdasarkan hasil pembangunan aplikasi kita.
Folder tujuan yang ditentukan dalam istilah dengan label 5 hanyalah direktori saat ini (ingat, ini semua berjalan di dalam sesuatu yang ajaib bernama OpenShift, dan bukan di komputer lokal Anda).
Bagian strategi – baris berlabel 6 – juga mirip dengan konfigurasi build pertama. Hanya saja kali ini kita akan menggunakan nginx-image-runtime, yang telah kita lihat di bagian ImageStream.
Terakhir, baris berlabel 7 adalah bagian pemicu yang akan mengaktifkan build ini setiap kali gambar react-web-app-builder berubah.
Jika tidak, templat ini berisi konfigurasi penerapan yang cukup standar, serta hal-hal yang berhubungan dengan layanan dan rute, namun kami tidak akan membahasnya terlalu detail. Perlu diketahui bahwa image yang akan di-deploy adalah image react-web-app-runtime.
Penerapan Aplikasi
Jadi sekarang kita telah melihat templatenya, mari kita lihat bagaimana menggunakannya untuk menyebarkan 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 yang sengaja direkayasa untuk menemukan template./openshiftio/application.yaml.
Perintah kedua hanya membuat aplikasi baru berdasarkan template ini.
Setelah perintah ini berfungsi, kita akan melihat bahwa kita memiliki dua rakitan:
Dan kembali ke layar Ikhtisar, kita akan melihat pod yang diluncurkan:
Klik link tersebut dan kita akan dibawa ke aplikasi kita, yang merupakan halaman default React App:
Tambahan 1
Untuk pecinta Angular kami juga punya .
Polanya disini sama, kecuali variabel OUTPUT_DIR.
Tambahan 2
Pada artikel kali ini kami menggunakan NGINX sebagai web servernya, namun untuk menggantinya dengan Apache cukup mudah cukup dengan mengganti template yang ada pada file tersebut. pada .
Kesimpulan
Di bagian pertama seri ini, kami menunjukkan cara menerapkan aplikasi web modern dengan cepat di platform OpenShift. Hari ini kita melihat apa yang dilakukan gambar Aplikasi Web dan bagaimana gambar tersebut dapat digabungkan dengan server web murni seperti NGINX menggunakan build berantai untuk membuat build aplikasi yang lebih siap produksi. Pada artikel berikutnya dan terakhir dalam seri ini, kami akan menunjukkan cara menjalankan server pengembangan untuk aplikasi Anda di OpenShift dan memastikan sinkronisasi file lokal dan jarak jauh.
Isi dari rangkaian artikel ini
- Bagian 1: ;
- Bagian 2: Cara menggunakan image S2I baru dengan image server HTTP yang sudah ada, seperti NGINX, menggunakan rakitan OpenShift terkait untuk penerapan produksi;
- Bagian 3: cara menjalankan server pengembangan untuk aplikasi Anda pada platform OpenShift dan menyinkronkannya dengan sistem file lokal.
Sumber daya tambahan
- Buku elektronik gratis .
- Informasi tentang .
Sumber: www.habr.com