{"id":90874,"date":"2020-08-07T01:42:20","date_gmt":"2020-08-06T23:42:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds"},"modified":"2020-08-07T01:42:20","modified_gmt":"2020-08-06T23:42:20","slug":"sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","title":{"rendered":"Applicazioni moderne su OpenShift, parte 2: build collegate chained builds","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao a tutti! Ecco il secondo post della nostra serie in cui mostriamo come distribuire applicazioni web moderne su Red Hat OpenShift. <\/p>\n

\"Applicazioni
\n
\nNel post precedente abbiamo accennato alle capacit\u00e0 della nuova immagine builder S2I (source-to-image), progettata per costruire e distribuire applicazioni web moderne sulla piattaforma OpenShift. In quella occasione ci siamo concentrati sulla rapida distribuzione dell'applicazione, mentre oggi vedremo come utilizzare l'immagine S2I come immagine builder 'pulita' e combinarla con build collegate di OpenShift.
\n<\/a><\/noindex><\/p>\n

Builder immagine pulita<\/h3>\n

\nCome abbiamo accennato nella prima parte, la maggior parte delle applicazioni web moderne ha una cosiddetta fase di assemblaggio, in cui vengono generalmente eseguite operazioni come la trascrizione del codice, la concatenazione di vari file e la minificazione. I file risultanti da queste operazioni \u2013 ovvero HTML statico, JavaScript e CSS \u2013 vengono collocati nella cartella output. La posizione di questa cartella dipende generalmente dagli strumenti di assemblaggio utilizzati, e per React sar\u00e0 la cartella .\/build (torneremo su questo argomento pi\u00f9 avanti).<\/p>\n

Source-to-Image (S2I)<\/h4>\n

\nIn questo post non trattiamo affatto il tema di 'cos'\u00e8 S2I e come utilizzarlo' (puoi leggere ulteriori dettagli qui<\/a><\/noindex>), ma \u00e8 importante avere chiara l'idea delle due fasi di questo processo per comprendere cosa fa l'immagine Web App Builder.<\/p>\n

Fase di assemblaggio<\/h4>\n

\nLa fase di assemblaggio \u00e8 di fatto molto simile a ci\u00f2 che accade quando esegui un docker build e ottieni una nuova immagine Docker. Pertanto, questa fase si verifica quando avvii il build sulla piattaforma OpenShift.<\/p>\n

Nel caso dell'immagine Web App Builder, l'installazione delle dipendenze della tua applicazione e l'avvio del build sono gestiti dallo assemble script<\/a><\/noindex>. Di default, l'immagine builder utilizza la struttura npm run build, ma pu\u00f2 essere sovrascritta tramite la variabile d'ambiente NPM_BUILD.<\/p>\n

Come accennato in precedenza, la posizione dell'applicazione gi\u00e0 assemblata dipende dagli strumenti utilizzati. Ad esempio, nel caso di React sar\u00e0 la cartella .\/build, mentre per le applicazioni Angular sar\u00e0 la cartella project_name\/dist. E, come mostrato nel post precedente, la posizione della cartella output, impostata di default come build, pu\u00f2 essere sovrascritta tramite la variabile d'ambiente OUTPUT_DIR. Poich\u00e9 la posizione della cartella output varia a seconda del framework, \u00e8 sufficiente copiare l'output generato nella cartella standard all'interno dell'immagine, precisamente in \/opt\/apt-root\/output. Questo \u00e8 importante per comprendere la parte successiva di questo articolo, ma per ora diamo un'occhiata rapida alla fase successiva \u2013 fase di esecuzione.<\/p>\n

Fase di esecuzione<\/h4>\n

\nQuesta fase si verifica quando viene eseguito un docker run per la nuova immagine creata nella fase di assemblaggio. Si verifica anche durante il deployment sulla piattaforma OpenShift. Di default, il script di esecuzione<\/a><\/noindex> utilizza serve module<\/a><\/noindex> gestisce i contenuti statici che si trovano nella suddetta cartella output standard.<\/p>\n

Questo metodo \u00e8 buono per la rapida distribuzione delle applicazioni, ma in realt\u00e0 non \u00e8 consigliabile gestire contenuti statici in questo modo. Poich\u00e9 in effetti stiamo solo servendo contenuti statici, l'installazione di Node.js all'interno della nostra immagine non \u00e8 necessaria: un semplice server web \u00e8 sufficiente.<\/p>\n

In altre parole, abbiamo bisogno di una cosa in fase di costruzione e di un'altra in fase di esecuzione. In questa situazione, le build collegate (chained builds) possono risultare utili.<\/p>\n

Build collegate<\/h3>\n

\nEcco cosa dice la documentazione di OpenShift riguardo alle chained builds<\/a><\/noindex> :<\/p>\n

\"Due build possono essere collegate tra loro, in cui una genera un'entit\u00e0 compilata e l'altra colloca questa entit\u00e0 in un'immagine separata, utilizzata per eseguire questa entit\u00e0.\"\n<\/p><\/blockquote>\n

\nIn altre parole, possiamo utilizzare l'immagine Web App Builder per eseguire la nostra build, e quindi utilizzare l'immagine del server web, come NGINX, per gestire il nostro contenuto.<\/p>\n

In questo modo, possiamo utilizzare l'immagine Web App Builder come builder 'pulita' e avere un'immagine runtime di dimensioni contenute.<\/p>\n

Ora esaminiamo un esempio concreto.<\/p>\n

Per fare pratica, utilizzeremo un semplice applicazione React<\/a><\/noindex>, creata utilizzando il tool da riga di comando create-react-app.<\/p>\n

Per unire tutto, il file template di OpenShift<\/a><\/noindex>.<\/p>\n

ci aiuter\u00e0. Analizziamo questo file pi\u00f9 nel dettaglio, partendo dalla sezione dei parametri.<\/p>\n

parameters:\n  - name: SOURCE_REPOSITORY_URL\n    description: The source URL for the application\n    displayName: Source URL\n    required: true\n  - name: SOURCE_REPOSITORY_REF\n    description: The branch name for the application\n    displayName: Source Branch\n    value: master\n    required: true\n  - name: SOURCE_REPOSITORY_DIR\n    description: The location within the source repo of the application\n    displayName: Source Directory\n    value: .\n    required: true\n  - name: OUTPUT_DIR\n    description: The location of the compiled static files from your web apps builder\n    displayName: Output Directory\n    value: build\n    required: false\n<\/code><\/pre>\n
\nQui tutto \u00e8 abbastanza chiaro, ma \u00e8 necessario prestare attenzione al parametro OUTPUT_DIR. Per l'applicazione React del nostro esempio non c'\u00e8 nulla di cui preoccuparsi, poich\u00e9 React utilizza come cartella di output il valore predefinito, ma nel caso di Angular o di qualcos'altro, questo parametro dovr\u00e0 essere modificato di conseguenza.<\/p>\n
Ora diamo un'occhiata alla sezione degli ImageStream.<\/p>\n
- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-builder  \/\/ 1 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-runtime  \/\/ 2 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: web-app-builder-runtime \/\/ 3\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: nodeshift\/ubi8-s2i-web-app:10.x\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: nginx-image-runtime \/\/ 4\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: 'centos\/nginx-112-centos7:latest'\n<\/code><\/pre>\n
\nGuarda le terze e quarte immagini. Entrambe sono definite come immagini Docker ed \u00e8 evidente da dove provengono.<\/p>\n
La terza immagine \u00e8 web-app-builder, e proviene da nodeshift\/ubi8-s2i-web-app con il tag 10.x su Docker hub<\/a><\/noindex>.<\/p>\n
La quarta \u00e8 l'immagine NGINX (versione 1.12) con il tag latest su Docker hub<\/a><\/noindex>.<\/p>\n
Ora diamo un'occhiata alle prime due immagini. Entrambe sono vuote all'inizio e vengono create solo nella fase di build. La prima immagine, react-web-app-builder, sar\u00e0 il risultato della fase di assemblaggio, che unir\u00e0 l'immagine web-app-builder-runtime e il nostro codice sorgente. \u00c8 per questo che abbiamo aggiunto \u00ab-builder\u00bb nel nome di quest'immagine.<\/p>\n
La seconda immagine, react-web-app-runtime, sar\u00e0 il risultato della combinazione dell'immagine nginx-image-runtime e di alcuni file dall'immagine react-web-app-builder. Quest'immagine sar\u00e0 utilizzata anche per il deployment e conterr\u00e0 solo il server web e il codice statico HTML, JavaScript, CSS della nostra applicazione.<\/p>\n
Complicato? Ora diamo un'occhiata alle configurazioni di build e diventer\u00e0 un po' pi\u00f9 chiaro.<\/p>\n
Nel nostro template ci sono due configurazioni di build. Ecco la prima, che \u00e8 piuttosto standard:<\/p>\n
  apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-builder\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-builder:latest \/\/ 1\n    source:   \/\/ 2 \n      git:\n        uri: ${SOURCE_REPOSITORY_URL}\n        ref: ${SOURCE_REPOSITORY_REF}\n      contextDir: ${SOURCE_REPOSITORY_DIR}\n      type: Git\n    strategy:\n      sourceStrategy:\n        env:\n          - name: OUTPUT_DIR \/\/ 3 \n            value: ${OUTPUT_DIR}\n        from:\n          kind: ImageStreamTag\n          name: web-app-builder-runtime:latest \/\/ 4\n        incremental: true \/\/ 5\n      type: Source\n    triggers: \/\/ 6\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - imageChange: {}\n      type: ImageChange\n<\/code><\/pre>\n
\nCome vediamo, la riga contrassegnata con 1 indica che il risultato di questa build sar\u00e0 inserito nell'immagine react-web-app-builder che abbiamo visto prima nella sezione degli ImageStream.<\/p>\n
La riga contrassegnata con 2 indica da dove prendere il codice. Nel nostro caso, questo \u00e8 un repository git, e la posizione, il ref e la cartella di contesto sono definiti da parametri che abbiamo gi\u00e0 visto sopra.<\/p>\n
La riga contrassegnata con 3 \u00e8 quella che abbiamo gi\u00e0 visto nella sezione dei parametri. Aggiunge la variabile d'ambiente OUTPUT_DIR, che nel nostro esempio \u00e8 uguale a build.
\nLa riga contrassegnata con 4 indica di utilizzare l'immagine web-app-builder-runtime che abbiamo gi\u00e0 visto nella sezione degli ImageStream.<\/p>\n
La riga contrassegnata con 5 indica che vogliamo utilizzare un build incrementale, se l'immagine S2I lo supporta, e l'immagine Web App Builder lo fa. Al primo avvio, dopo il completamento della fase di assemblaggio, l'immagine salver\u00e0 la cartella node_modules in un file zip. Poi, nei successivi avvi, l'immagine semplicemente decomprimer\u00e0 questa cartella per ridurre il tempo di build.<\/p>\n
E infine, la riga contrassegnata con 6 \u00e8 solo qualche trigger per avviare automaticamente la build, senza intervento manuale, quando qualcosa cambia.<\/p>\n
In generale, questa \u00e8 una configurazione di build piuttosto standard.<\/p>\n
Ora diamo un'occhiata alla seconda configurazione di build. \u00c8 molto simile alla prima, ma c'\u00e8 una differenza importante.<\/p>\n
apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-runtime\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-runtime:latest \/\/ 1\n    source: \/\/ 2\n      type: Image\n      images:                              \n        - from:\n            kind: ImageStreamTag\n            name: react-web-app-builder:latest \/\/ 3\n          paths:\n            - sourcePath: \/opt\/app-root\/output\/.  \/\/ 4\n              destinationDir: .  \/\/ 5\n             \n    strategy: \/\/ 6\n      sourceStrategy:\n        from:\n          kind: ImageStreamTag\n          name: nginx-image-runtime:latest\n        incremental: true\n      type: Source\n    triggers:\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - type: ImageChange\n      imageChange: {}\n    - type: ImageChange\n      imageChange:\n        from:\n          kind: ImageStreamTag\n          name: react-web-app-builder:latest \/\/ 7\n<\/code><\/pre>\n
\nQuindi, la seconda configurazione di build \u00e8 react-web-app-runtime, e inizia in modo piuttosto standard.<\/p>\n
Nella riga contrassegnata con 1 non c'\u00e8 nulla di nuovo: dice semplicemente che il risultato della build verr\u00e0 inserito nell'immagine react-web-app-runtime.<\/p>\n
La riga con l'etichetta 2, come nella configurazione precedente, indica da dove prelevare il codice sorgente. Ma attenzione, qui diciamo che proviene dall'immagine. Inoltre, dall'immagine che abbiamo appena creato - da react-web-app-builder (indicata nella riga con l'etichetta 3). I file che vogliamo utilizzare si trovano all'interno dell'immagine e la loro posizione \u00e8 specificata nella riga con l'etichetta 4, nel nostro caso \u00e8 \/opt\/app-root\/output\/. Se ricordate, proprio l\u00ec vengono salvati i file generati al termine della compilazione della nostra applicazione.<\/p>\n
La cartella di destinazione, specificata nella riga con l'etichetta 5, \u00e8 semplicemente la directory corrente (tutto ci\u00f2, ricordiamolo, si svolge all'interno di una sorta di magia chiamata OpenShift, e non sul vostro computer locale).<\/p>\n
La sezione strategy - la riga con l'etichetta 6 - \u00e8 simile alla prima configurazione di compilazione. Solo che questa volta abbiamo intenzione di utilizzare nginx-image-runtime, che abbiamo gi\u00e0 visto nella sezione ImageStream.<\/p>\n
Infine, la riga con l'etichetta 7 \u00e8 la sezione dei trigger, che attivano questa compilazione ogni volta che l'immagine react-web-app-builder cambia.<\/p>\n
A parte questo, questo modello contiene una configurazione di deployment piuttosto standard, oltre ad elementi relativi ai servizi e ai percorsi, ma non approfondiremo questo aspetto. Notate che l'immagine che verr\u00e0 distribuita \u00e8 l'immagine react-web-app-runtime.<\/p>\n
Distribuzione dell'applicazione<\/h3>\n
\nQuindi, dopo aver esaminato il modello, vediamo come utilizzarlo per distribuire un'applicazione.<\/p>\n
Possiamo utilizzare lo strumento client OpenShift chiamato oc, per distribuire il nostro modello:<\/p>\n
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f\n\n$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https:\/\/github.com\/lholmquist\/react-web-app\n<\/code><\/pre>\n
\nIl primo comando nello screenshot sopra \u00e8 un modo ingegneristico per trovare il modello .\/openshiftio\/application.yaml.<\/p>\n
Il secondo comando semplicemente crea una nuova applicazione basata su questo modello.<\/p>\n
Dopo che questi comandi sono stati eseguiti, vedremo che sono state create due compilazioni:<\/p>\n
\"Applicazioni<\/p>\n
E tornando alla schermata Overview, vedremo il pod avviato:<\/p>\n
\"Applicazioni<\/p>\n
Un clic sul link ci porter\u00e0 alla nostra applicazione, che \u00e8 una pagina dell'applicazione React App per impostazione predefinita:<\/p>\n
\"Applicazioni<\/p>\n
Supplemento 1<\/h3>\n
\nPer gli amanti di Angular abbiamo anche un esempio di applicazione<\/a><\/noindex>.<\/p>\n
Il modello \u00e8 lo stesso, eccetto per la variabile OUTPUT_DIR.<\/p>\n
Appendice 2<\/h3>\n
\nIn questo articolo abbiamo usato NGINX come server web, ma \u00e8 abbastanza facile sostituirlo con Apache, basta cambiare nel file modello immagine NGINX<\/a><\/noindex> con immagine Apache<\/a><\/noindex>.<\/p>\n
Conclusione<\/h3>\n
\nNella prima parte di questa serie abbiamo mostrato come distribuire rapidamente applicazioni web moderne sulla piattaforma OpenShift. Oggi abbiamo esaminato cosa fa l'immagine Web App e come pu\u00f2 essere combinata con un server web come NGINX attraverso build collegate (chained build) per organizzare una compilazione pi\u00f9 adatta alle condizioni di produzione. Nell'ultimo articolo di questa serie, mostreremo come eseguire un server di sviluppo per la nostra applicazione su OpenShift e mantenere la sincronizzazione tra i file locali e remoti.<\/p>\n
Contenuto di questa serie di articoli<\/h3>\n
<\/p>\n