Herkese selam! Bu, modern web uygulamalarının Red Hat OpenShift'te nasıl dağıtılacağını gösterdiğimiz serimizin ikinci yazısıdır.
Önceki gönderide, OpenShift platformunda modern web uygulamaları oluşturmak ve dağıtmak için tasarlanan yeni S2I (kaynaktan görüntüye) oluşturucu görüntüsünün yeteneklerine biraz değinmiştik. Daha sonra bir uygulamayı hızla dağıtma konusuyla ilgilendik ve bugün bir S2I görüntüsünün "saf" oluşturucu görüntüsü olarak nasıl kullanılacağına ve onu ilgili OpenShift derlemeleriyle nasıl birleştireceğimize bakacağız.
Temiz inşaatçı resmi
Bölüm XNUMX'de bahsettiğimiz gibi çoğu modern web uygulaması, genellikle kod aktarma, çoklu dosya birleştirme ve küçültme gibi işlemleri gerçekleştiren, oluşturma aşaması adı verilen bir aşamaya sahiptir. Bu işlemler sonucunda elde edilen dosyalar (ki bu statik HTML, JavaScript ve CSS'dir) çıktı klasöründe saklanır. Bu klasörün konumu genellikle hangi derleme araçlarının kullanıldığına bağlıdır ve React için bu ./build klasörü olacaktır (buna aşağıda daha ayrıntılı olarak geri döneceğiz).
Kaynaktan Görüntüye (S2I)
Bu yazıda “S2I nedir ve nasıl kullanılır” konusuna değinmiyoruz (bununla ilgili daha fazlasını okuyabilirsiniz) ), ancak bir Web App Builder görüntüsünün ne yaptığını anlamak için bu süreçteki iki adım hakkında net olmak önemlidir.
Montaj aşaması
Montaj aşaması, doğası gereği docker build'i çalıştırdığınızda ve yeni bir Docker görüntüsü elde ettiğinizde olanlara çok benzer. Buna göre bu aşama OpenShift platformunda bir yapıya başlarken gerçekleşir.
Web App Builder görüntüsü söz konusu olduğunda, uygulamanızın bağımlılıklarını yüklemekten ve derlemeyi çalıştırmaktan sorumludur. . Varsayılan olarak oluşturucu görüntüsü, npm run build yapısını kullanır, ancak bu, NPM_BUILD ortam değişkeni aracılığıyla geçersiz kılınabilir.
Daha önce de söylediğimiz gibi, bitmiş, önceden oluşturulmuş uygulamanın konumu, hangi araçları kullandığınıza bağlıdır. Örneğin, React durumunda bu ./build klasörü olacaktır ve Angular uygulamaları için bu proje_adı/dist klasörü olacaktır. Ve önceki gönderide de gösterildiği gibi, varsayılan olarak oluşturulacak şekilde ayarlanan çıktı dizininin konumu, OUTPUT_DIR ortam değişkeni aracılığıyla geçersiz kılınabilir. Çıktı klasörünün konumu çerçeveden çerçeveye farklılık gösterdiğinden, oluşturulan çıktıyı görüntüdeki standart klasöre, yani /opt/apt-root/output'a kopyalamanız yeterlidir. Bu, bu makalenin geri kalanını anlamak için önemlidir, ancak şimdilik bir sonraki aşamaya, yani çalıştırma aşamasına hızlıca bakalım.
çalıştırma aşaması
Bu aşama, montaj aşamasında oluşturulan yeni görüntü üzerinde docker çalıştırmasına çağrı yapıldığında meydana gelir. OpenShift platformunda dağıtım yaparken de aynı şey olur. Varsayılan использует Yukarıdaki standart çıktı dizininde bulunan statik içeriği sunmak için.
Bu yöntem, uygulamaların hızla dağıtılması için iyidir ancak statik içeriğin bu şekilde sunulması genellikle önerilmez. Gerçekte yalnızca statik içerik sunduğumuz için imajımızın içinde Node.js'nin kurulu olmasına ihtiyacımız yok; bir web sunucusu yeterli olacaktır.
Başka bir deyişle, montaj yaparken bir şeye ihtiyacımız var, yürütürken ise başka bir şeye ihtiyacımız var. Bu durumda zincirleme yapılar kullanışlı olur.
Zincirleme yapılar
Bu onların hakkında yazdıkları şey OpenShift belgelerinde:
"İki derleme birbirine bağlanabilir; biri derlenmiş bir varlık oluşturur, diğeri ise bu varlığı, o varlığı çalıştırmak için kullanılan ayrı bir görüntüde barındırır."
Başka bir deyişle, derlememizi çalıştırmak için Web App Builder görüntüsünü kullanabiliriz ve ardından içeriğimizi sunmak için aynı NGINX olan web sunucusu görüntüsünü kullanabiliriz.
Böylece Web App Builder imajını “saf” builder olarak kullanabilir ve aynı zamanda küçük bir çalışma zamanı imajına sahip olabiliriz.
Şimdi buna spesifik bir örnekle bakalım.
Eğitim için kullanacağımız create-react-app komut satırı aracı kullanılarak oluşturulmuştur.
Her şeyi bir araya getirmemize yardımcı olacak .
Bu dosyaya daha detaylı bakalım ve parametreler bölümüyle başlayalım.
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
Burada her şey oldukça açık ancak OUTPUT_DIR parametresine dikkat etmekte fayda var. Örneğimizdeki React uygulaması için endişelenecek bir şey yoktur, çünkü React çıktı klasörü olarak varsayılan değeri kullanır, ancak Angular veya başka bir durumda bu parametrenin gerektiği gibi değiştirilmesi gerekecektir.
Şimdi ImageStreams bölümüne bir göz atalım.
- 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'
Üçüncü ve dördüncü resimlere bir göz atın. Her ikisi de Docker görselleri olarak tanımlanıyor ve nereden geldiklerini net bir şekilde görebiliyorsunuz.
Üçüncü resim web-app-builder'dır ve 8.x etiketli nodeshift/ubi2-s10i-web-app'ten gelir. .
Dördüncüsü, en son etiketin açık olduğu bir NGINX görüntüsüdür (sürüm 1.12). .
Şimdi ilk iki resme bakalım. Her ikisi de başlangıçta boştur ve yalnızca yapım aşamasında oluşturulur. İlk görüntü, react-web-app-builder, web-app-builder-çalışma zamanı görüntüsünü ve kaynak kodumuzu birleştirecek bir montaj adımının sonucu olacaktır. Bu yüzden bu görselin ismine “-builder” ekledik.
İkinci görüntü - react-web-app-runtime - nginx-image-runtime ve react-web-app-builder görüntüsündeki bazı dosyaların birleştirilmesinin sonucu olacaktır. Bu görüntü dağıtım sırasında da kullanılacak ve yalnızca uygulamamızın web sunucusunu ve statik HTML'sini, JavaScript'ini, CSS'sini içerecektir.
Kafası karışmış? Şimdi yapı konfigürasyonlarına bir göz atalım ve her şey biraz daha netleşecektir.
Şablonumuzun iki yapı konfigürasyonu var. İşte ilki ve oldukça standart:
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
Gördüğünüz gibi 1 etiketli satır, bu yapının sonucunun, biraz önce ImageStreams bölümünde gördüğümüz aynı react-web-app-builder görüntüsüne yerleştirileceğini söylüyor.
2 etiketli satır size kodu nereden alacağınızı söyler. Bizim durumumuzda bu bir git deposudur ve konum, ref ve bağlam klasörü yukarıda gördüğümüz parametrelere göre belirlenir.
3 etiketli satır zaten parametreler bölümünde gördüğümüz satırdır. Örneğimizde build olan OUTPUT_DIR ortam değişkenini ekler.
4 etiketli satır, ImageStream bölümünde zaten gördüğümüz web-app-builder-runtime görüntüsünün kullanılacağını söylüyor.
5 etiketli satır, S2I görüntüsünün ve Web App Builder görüntüsünün desteklemesi durumunda artımlı bir yapı kullanmak istediğimizi söylüyor. İlk başlatmada, montaj aşamasını tamamladıktan sonra görüntü, node_modules klasörünü bir arşiv dosyasına kaydedecektir. Daha sonra, sonraki çalıştırmalarda görüntü, derleme süresini kısaltmak için bu klasörün sıkıştırmasını açacaktır.
Ve son olarak, 6 etiketli satır, bir şeyler değiştiğinde yapının manuel müdahaleye gerek kalmadan otomatik olarak çalışmasını sağlayan birkaç tetikleyicidir.
Genel olarak bu oldukça standart bir yapı yapılandırmasıdır.
Şimdi ikinci yapı konfigürasyonuna bir göz atalım. İlkine çok benziyor ama önemli bir fark var.
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
Yani ikinci yapı konfigürasyonu react-web-app-runtime'dır ve oldukça standart bir şekilde başlar.
1 etiketli satır yeni bir şey değil; yalnızca derleme sonucunun react-web-app-runtime görüntüsüne yerleştirildiğini söylüyor.
2 etiketli satır önceki konfigürasyonda olduğu gibi kaynak kodunun nereden alınacağını belirtir. Ama dikkat edin burada görüntüden alındığını söylüyoruz. Üstelik, reaksiyon-web-app-builder'dan (3 numaralı satırda belirtilmiştir) yeni oluşturduğumuz görüntüden. Kullanmak istediğimiz dosyalar görüntünün içindedir ve buradaki konumları 4 numaralı satırda belirtilmiştir, bizim durumumuzda /opt/app-root/output/ şeklindedir. Hatırlarsanız uygulamamızı oluşturma sonuçlarına göre oluşturulan dosyaların saklandığı yer burasıdır.
Terimde 5 etiketiyle belirtilen hedef klasör, yalnızca geçerli dizindir (unutmayın, hepsi bu, yerel bilgisayarınızda değil, OpenShift adı verilen sihirli bir şeyin içinde çalışıyor).
Strateji bölümü (6 etiketli satır) da ilk yapı konfigürasyonuna benzer. Ancak bu sefer ImageStream bölümünde gördüğümüz nginx-image-runtime'ı kullanacağız.
Son olarak, 7 etiketli satır, react-web-app-builder görüntüsü her değiştiğinde bu yapıyı etkinleştirecek tetikleyicilerin bir bölümüdür.
Aksi takdirde, bu şablon oldukça standart dağıtım yapılandırmasının yanı sıra hizmetler ve rotalarla ilgili şeyleri de içerir, ancak bu kadar fazla ayrıntıya girmeyeceğiz. Dağıtılacak görüntünün react-web-app-runtime görüntüsü olduğunu lütfen unutmayın.
Uygulama Dağıtımı
Artık şablona baktığımıza göre, bir uygulamayı dağıtmak için onu nasıl kullanacağımızı görelim.
Şablonumuzu dağıtmak için oc adlı OpenShift istemci aracını kullanabiliriz:
$ 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
Yukarıdaki ekran görüntüsündeki ilk komut, bir şablon bulmanın kasıtlı bir mühendislik yoludur./openshiftio/application.yaml.
İkinci komut basitçe bu şablonu temel alan yeni bir uygulama oluşturur.
Bu komutlar çalıştıktan sonra iki derlememiz olduğunu göreceğiz:
Genel Bakış ekranına döndüğümüzde başlatılan bölmeyi göreceğiz:
Bağlantıya tıkladığınızda varsayılan React Uygulama sayfası olan uygulamamıza yönlendirileceğiz:
Ek 1
Açısal sevenler için ayrıca .
OUTPUT_DIR değişkeni dışında buradaki kalıp aynıdır.
Ek 2
Bu yazıda NGINX'i web sunucusu olarak kullandık ancak Apache ile değiştirmek oldukça kolaydır, sadece dosyadaki şablonu değiştirmeniz yeterlidir. üzerinde .
Sonuç
Bu serinin ilk bölümünde modern web uygulamalarının OpenShift platformunda nasıl hızlı bir şekilde dağıtılacağını gösterdik. Bugün bir Web Uygulaması görüntüsünün ne yaptığına ve üretime daha hazır bir uygulama yapısı oluşturmak için zincirleme yapılar kullanılarak NGINX gibi saf bir web sunucusuyla nasıl birleştirilebileceğine baktık. Bu serinin bir sonraki ve son makalesinde, OpenShift üzerinde uygulamanız için bir geliştirme sunucusunun nasıl çalıştırılacağını ve yerel ve uzak dosyaların senkronizasyonunun nasıl sağlanacağını göstereceğiz.
Bu yazı serisinin içeriği
- 1’in bir parçası: ;
- Bölüm 2: Yeni bir S2I görüntüsünün, üretim dağıtımı için ilişkili OpenShift derlemelerini kullanarak NGINX gibi mevcut bir HTTP sunucusu görüntüsüyle nasıl kullanılacağı;
- Bölüm 3: OpenShift platformunda uygulamanız için bir geliştirme sunucusunun nasıl çalıştırılacağı ve yerel dosya sistemiyle nasıl senkronize edileceği.
Ek kaynaklar
- Ücretsiz e-kitap .
- hakkında bilgi .
Kaynak: habr.com