{"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\/sv\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","title":{"rendered":"Moderna applikationer p\u00e5 OpenShift, del 2: Kedjade byggen (chained builds)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej alla! H\u00e4r \u00e4r det andra inl\u00e4gget i v\u00e5r serie d\u00e4r vi visar hur man distribuerar moderna webbapplikationer p\u00e5 Red Hat OpenShift. <\/p>\n

\"Moderna
\n
\nI det tidigare inl\u00e4gget ber\u00f6rde vi n\u00e5got av de nya m\u00f6jligheterna med builder-bilden S2I (source-to-image), som \u00e4r avsedd f\u00f6r byggande och distribution av moderna webbapplikationer p\u00e5 OpenShift-plattformen. D\u00e5 fokuserade vi p\u00e5 snabb distribution av applikationen, och idag ska vi se hur man anv\u00e4nder S2I-bilden som en \"ren\" builder-bild och kombinera den med relaterade OpenShift-byggnader.
\n<\/a><\/noindex><\/p>\n

Ren builder-bild<\/h3>\n

\nSom vi n\u00e4mnde i den f\u00f6rsta delen har de flesta moderna webbapplikationer en s\u00e5 kallad byggfas d\u00e4r operationer som kodtranspilering, konkatenering av flera filer och minifiering normalt utf\u00f6rs. De resulterande filerna \u2013 det vill s\u00e4ga statisk HTML, JavaScript och CSS \u2013 placeras i output-mappen. Platsen f\u00f6r denna mapp beror vanligtvis p\u00e5 vilka byggverktyg som anv\u00e4nds, och f\u00f6r React kommer det att vara mappen . \/build (vi \u00e5terkommer till denna fr\u00e5ga l\u00e4ngre ner).<\/p>\n

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

\nI detta inl\u00e4gg ber\u00f6r vi inte alls \u00e4mnet \"vad \u00e4r S2I och hur man anv\u00e4nder det\" (mer om detta kan l\u00e4sas h\u00e4r<\/a><\/noindex>), men det \u00e4r viktigt att tydligt ha en f\u00f6rst\u00e5else f\u00f6r de tv\u00e5 stegen i denna process f\u00f6r att f\u00f6rst\u00e5 vad Web App Builder-bilden g\u00f6r.<\/p>\n

Assemblagefasen (assemble phase)<\/h4>\n

\nAssemblagefasen liknar i grunden vad som h\u00e4nder n\u00e4r du k\u00f6r docker build och f\u00e5r en ny Docker-bild som resultat. D\u00e4rf\u00f6r intr\u00e4ffar detta steg n\u00e4r en byggprocess startas p\u00e5 OpenShift-plattformen.<\/p>\n

I fallet med Web App Builder-bilden ansvarar assemble script<\/a><\/noindex>. Som standard anv\u00e4nder builder-bilden kommandot npm run build, men det kan \u00f6verskridas via milj\u00f6variabeln NPM_BUILD.<\/p>\n

Som vi n\u00e4mnde tidigare beror platsen f\u00f6r den f\u00e4rdiga, redan byggda applikationen p\u00e5 vilka verktyg som anv\u00e4nds. I fallet med React kommer detta att vara mappen .\/build, och f\u00f6r Angular-applikationer \u2013 mappen project_name\/dist. Och som redan visats i det tidigare inl\u00e4gget kan platsen f\u00f6r output-katalogen, som som standard \u00e4r angiven som build, \u00f6verskrivas via milj\u00f6variabeln OUTPUT_DIR. Eftersom platsen f\u00f6r output-mappen skiljer sig fr\u00e5n ramverk till ramverk kopierar du helt enkelt den genererade outputen till standardmappen i bilden, n\u00e4mligen i \/opt\/apt-root\/output. Detta \u00e4r viktigt f\u00f6r att f\u00f6rst\u00e5 den fortsatta delen av denna artikel, men l\u00e5t oss snabbt g\u00e5 igenom n\u00e4sta steg \u2013 k\u00f6rning (run phase).<\/p>\n

K\u00f6rningssteget (run phase)<\/h4>\n

\nDetta steg intr\u00e4ffar n\u00e4r det nya objektet som skapats under assembleringssteget anropas med docker run. Det intr\u00e4ffar ocks\u00e5 vid distribution p\u00e5 OpenShift-plattformen. Som standard k\u00f6r skript<\/a><\/noindex> anv\u00e4nder betj\u00e4ningsmodul<\/a><\/noindex> f\u00f6r att servera statiskt inneh\u00e5ll som ligger i den angivna standardoutput-katalogen.<\/p>\n

Denna metod \u00e4r bra f\u00f6r snabb distribution av applikationer, men det rekommenderas egentligen inte att servera statiskt inneh\u00e5ll p\u00e5 detta s\u00e4tt. Eftersom vi faktiskt endast serverar statiskt inneh\u00e5ll beh\u00f6vs inte Node.js som \u00e4r installerat i v\u00e5r bild \u2013 en webbserver r\u00e4cker.<\/p>\n

Med andra ord, vi beh\u00f6ver en sak vid byggandet och en annan vid k\u00f6rningen. I en s\u00e5dan situation \u00e4r relaterade byggen (chained builds) anv\u00e4ndbara.<\/p>\n

Relaterade byggen (chained builds)<\/h3>\n

\nH\u00e4r \u00e4r vad som s\u00e4gs om chained builds<\/a><\/noindex> i dokumentationen f\u00f6r OpenShift:<\/p>\n

\u201eTv\u00e5 byggen kan l\u00e4nkas samman, d\u00e4r det ena genererar en kompilerad entitet och det andra placerar denna entitet i en separat bild som anv\u00e4nds f\u00f6r att k\u00f6ra denna entitet.\u201d\n<\/p><\/blockquote>\n

\nMed andra ord kan vi anv\u00e4nda bilden Web App Builder f\u00f6r att k\u00f6ra v\u00e5r byggprocess, och sedan anv\u00e4nda bilden av webbservern, samma NGINX, f\u00f6r att betj\u00e4na v\u00e5rt inneh\u00e5ll.<\/p>\n

S\u00e5ledes kan vi anv\u00e4nda bilden Web App Builder som en 'ren' byggare och fortfarande ha en liten storlek p\u00e5 runtime-bilden.<\/p>\n

L\u00e5t oss nu g\u00e5 igenom detta med ett konkret exempel.<\/p>\n

F\u00f6r tr\u00e4ning kommer vi att anv\u00e4nda en enkel React-applikation<\/a><\/noindex>, som skapats med verktyget create-react-app.<\/p>\n

Att samla allt i ett kan hj\u00e4lpa oss med OpenShift-mallfilen<\/a><\/noindex>.<\/p>\n

L\u00e5t oss titta n\u00e4rmare p\u00e5 den h\u00e4r filen, och b\u00f6rja med avsnittet f\u00f6r parametrar.<\/p>\n

parametrar:\n  - namn: SOURCE_REPOSITORY_URL\n    beskrivning: K\u00e4ll-URL f\u00f6r applikationen\n    visaNamn: K\u00e4ll-URL\n    kr\u00e4vs: true\n  - namn: SOURCE_REPOSITORY_REF\n    beskrivning: Grennamn f\u00f6r applikationen\n    visaNamn: K\u00e4llgren\n    v\u00e4rde: master\n    kr\u00e4vs: true\n  - namn: SOURCE_REPOSITORY_DIR\n    beskrivning: Platsen inom k\u00e4llrepo f\u00f6r applikationen\n    visaNamn: K\u00e4llkatalog\n    v\u00e4rde: .\n    kr\u00e4vs: true\n  - namn: OUTPUT_DIR\n    beskrivning: Platsen f\u00f6r de kompilerade statiska filerna fr\u00e5n din webbapps byggare\n    visaNamn: Utdata-katalog\n    v\u00e4rde: build\n    kr\u00e4vs: false\n<\/code><\/pre>\n
\nH\u00e4r \u00e4r allt ganska tydligt, men det \u00e4r viktigt att uppm\u00e4rksamma parameter OUTPUT_DIR. F\u00f6r React-applikationen i v\u00e5rt exempel beh\u00f6ver man inte oroa sig, eftersom React anv\u00e4nder som utdata-mapp det f\u00f6rinst\u00e4llda v\u00e4rdet, men i fallet med Angular eller n\u00e5got annat, beh\u00f6ver denna parameter justeras p\u00e5 r\u00e4tt s\u00e4tt.<\/p>\n
Nu l\u00e5t oss ta en titt p\u00e5 avsnittet f\u00f6r ImageStreams.<\/p>\n
- apiVersion: v1\n  typ: ImageStream\n  metadata:\n    namn: react-web-app-builder  \/\/ 1 \n  specifikation: {}\n- apiVersion: v1\n  typ: ImageStream\n  metadata:\n    namn: react-web-app-runtime  \/\/ 2 \n  specifikation: {}\n- apiVersion: v1\n  typ: ImageStream\n  metadata:\n    namn: web-app-builder-runtime \/\/ 3\n  specifikation:\n    taggar:\n    - namn: latest\n      fr\u00e5n:\n        typ: DockerImage\n        namn: nodeshift\/ubi8-s2i-web-app:10.x\n- apiVersion: v1\n  typ: ImageStream\n  metadata:\n    namn: nginx-image-runtime \/\/ 4\n  specifikation:\n    taggar:\n    - namn: latest\n      fr\u00e5n:\n        typ: DockerImage\n        namn: 'centos\/nginx-112-centos7:latest'\n<\/code><\/pre>\n
\nTitta p\u00e5 den tredje och fj\u00e4rde bilden. De definieras b\u00e5da som Docker-bilder, och det \u00e4r tydligt var de kommer ifr\u00e5n.<\/p>\n
Den tredje bilden \u00e4r web-app-builder, och den h\u00e4mtas fr\u00e5n nodeshift\/ubi8-s2i-web-app med taggen 10.x p\u00e5 Docker hub<\/a><\/noindex>.<\/p>\n
Den fj\u00e4rde bilden \u00e4r en NGINX-bild (version 1.12) med taggen latest p\u00e5 Docker hub<\/a><\/noindex>.<\/p>\n
Nu tar vi en titt p\u00e5 de tv\u00e5 f\u00f6rsta bilderna. De \u00e4r b\u00e5da tomma i b\u00f6rjan och skapas endast under byggfasen. Den f\u00f6rsta bilden \u2013 react-web-app-builder \u2013 kommer att bli resultatet av assemblage-steget, som kommer att kombinera bilden web-app-builder-runtime och v\u00e5r k\u00e4llkod. Det \u00e4r d\u00e4rf\u00f6r vi har skrivit \"-builder\" i namnet p\u00e5 den h\u00e4r bilden.<\/p>\n
Den andra bilden \u2013 react-web-app-runtime \u2013 kommer att bli resultatet av kombinationen av nginx-image-runtime och vissa filer fr\u00e5n bilden react-web-app-builder. Denna bild kommer ocks\u00e5 att anv\u00e4ndas vid distribution och kommer endast att inneh\u00e5lla webbservern och den statiska HTML, JavaScript, CSS f\u00f6r v\u00e5r applikation.<\/p>\n
F\u00f6rvirrat? L\u00e5t oss titta p\u00e5 byggkonfigurationerna, s\u00e5 blir det lite klarare.<\/p>\n
I v\u00e5r mall finns det tv\u00e5 byggkonfigurationer. H\u00e4r \u00e4r den f\u00f6rsta, och den \u00e4r ganska 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
\nSom vi ser, s\u00e4ger raden med etikett 1 att resultatet av denna byggprocess kommer att placeras i den bild som heter react-web-app-builder, som vi tidigare s\u00e5g i avsnittet om ImageStreams.<\/p>\n
Raden med etikett 2 s\u00e4ger varifr\u00e5n koden ska h\u00e4mtas. I v\u00e5rt fall handlar det om ett git-repo, och plats, ref och kontextmapp definieras av parametrar som vi redan har sett ovan.<\/p>\n
Raden med etikett 3 \u00e4r n\u00e5got vi redan har sett i avsnittet om parametrar. Den l\u00e4gger till en milj\u00f6variabel OUTPUT_DIR, som i v\u00e5rt exempel \u00e4r lika med build.
\nRaden med etikett 4 s\u00e4ger att vi ska anv\u00e4nda bilden web-app-builder-runtime, som vi redan har sett i avsnittet om ImageStreams.<\/p>\n
Raden med etikett 5 s\u00e4ger att vi vill anv\u00e4nda en inkrementell byggnad, om S2I-bilden st\u00f6djer det, och bilden Web App Builder g\u00f6r det. Vid f\u00f6rsta k\u00f6rningen, efter att byggprocessen \u00e4r klar, kommer bilden att spara mappen node_modules i en arkivfil. D\u00e4refter vid efterf\u00f6ljande k\u00f6rningar kommer bilden helt enkelt att packa upp den mappen f\u00f6r att f\u00f6rkorta byggtiden.<\/p>\n
Och slutligen, raden med etikett 6 \u00e4r bara n\u00e5gra triggers s\u00e5 att byggnaden startas automatiskt, utan manuell intervention, n\u00e4r n\u00e5got f\u00f6r\u00e4ndras.<\/p>\n
Sammanfattningsvis \u00e4r detta en ganska standard byggkonfiguration.<\/p>\n
L\u00e5t oss nu ta en titt p\u00e5 den andra byggkonfigurationen. Den liknar mycket den f\u00f6rsta, men det finns en viktig skillnad.<\/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
\nS\u00e5, den andra byggkonfigurationen \u00e4r react-web-app-runtime, och den b\u00f6rjar ganska standardm\u00e4ssigt.<\/p>\n
I raden med etikett 1 finns det inget nytt \u2013 den s\u00e4ger bara att resultatet av byggprocessen sparas i bilden react-web-app-runtime.<\/p>\n
Raden med etikett 2, precis som i den f\u00f6reg\u00e5ende konfigurationen, anger var k\u00e4llkoden ska h\u00e4mtas ifr\u00e5n. Men observera att h\u00e4r s\u00e4ger vi att den kommer fr\u00e5n en bild. Faktum \u00e4r att den kommer fr\u00e5n den bild vi just har skapat \u2013 fr\u00e5n react-web-app-builder (anges i raden med etikett 3). Filerna som vi vill anv\u00e4nda finns inuti bilden och deras plats d\u00e4r anges i raden med etikett 4, i v\u00e5rt fall \u00e4r det \/opt\/app-root\/output\/. Om ni minns, \u00e4r det dit filer som genereras som resultat av v\u00e5r applikationsbyggnad hamnar.<\/p>\n
Mappen som anges i raden med etikett 5 \u00e4r helt enkelt den aktuella katalogen (detta, l\u00e5t oss p\u00e5minna, k\u00f6rs inom ett slags magiskt system som heter OpenShift, och inte p\u00e5 din lokala dator).<\/p>\n
Sektionen strategy \u2013 raden med etikett 6 \u2013 liknar \u00e4ven den f\u00f6rsta byggkonfigurationen. Men den h\u00e4r g\u00e5ngen planerar vi att anv\u00e4nda nginx-image-runtime, som vi redan har sett i avsnittet ImageStream.<\/p>\n
Slutligen, raden med etikett 7 \u2013 detta \u00e4r triggersavsnittet som aktiverar denna byggprocess varje g\u00e5ng bilden react-web-app-builder \u00e4ndras.<\/p>\n
I \u00f6vrigt inneh\u00e5ller denna mall en ganska standard konfiguration f\u00f6r distribution, samt olika saker som r\u00f6r tj\u00e4nster och rutter, men vi kommer inte att g\u00e5 djupare in i det. Observera att bilden som kommer att distribueras \u00e4r bilden react-web-app-runtime.<\/p>\n
Distribution av applikation<\/h3>\n
\nS\u00e5, efter att ha sett p\u00e5 mallen, l\u00e5t oss titta p\u00e5 hur vi kan anv\u00e4nda den f\u00f6r att distribuera applikationen.<\/p>\n
Vi kan anv\u00e4nda klientverktyget OpenShift som kallas oc f\u00f6r att distribuera v\u00e5r mall:<\/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
\nDen f\u00f6rsta kommandot p\u00e5 sk\u00e4rmen ovan \u00e4r ett avsiktligt tekniskt s\u00e4tt att hitta mallen .\/openshiftio\/application.yaml.<\/p>\n
Den andra kommandot skapar helt enkelt en ny applikation baserad p\u00e5 denna mall.<\/p>\n
N\u00e4r dessa kommandon har k\u00f6rts, kommer vi att se att vi har tv\u00e5 byggprocesser:<\/p>\n
\"Moderna<\/p>\n
Och n\u00e4r vi g\u00e5r tillbaka till Overview-sk\u00e4rmen, ser vi den startade podden:<\/p>\n
\"Moderna<\/p>\n
Ett klick p\u00e5 l\u00e4nken \u2013 och vi g\u00e5r till v\u00e5r applikation, som utg\u00f6r en standard React App-sida:<\/p>\n
\"Moderna<\/p>\n
Bilaga 1<\/h3>\n
\nF\u00f6r Angular-\u00e4lskare har vi ocks\u00e5 ett exempel p\u00e5 en applikation<\/a><\/noindex>.<\/p>\n
Mallen h\u00e4r \u00e4r densamma, f\u00f6rutom variabeln OUTPUT_DIR.<\/p>\n
Till\u00e4gg 2<\/h3>\n
\nI denna artikel har vi anv\u00e4nt NGINX som webbserver, men det \u00e4r ganska enkelt att byta till Apache genom att bara \u00e4ndra i mallfilen. nginx-avbildning<\/a><\/noindex> till apache-avbildning<\/a><\/noindex>.<\/p>\n
Slutsats<\/h3>\n
\nI den f\u00f6rsta delen av denna serie visade vi hur man snabbt distribuerar moderna webbapplikationer p\u00e5 OpenShift-plattformen. Idag tittade vi p\u00e5 vad som g\u00f6r Web App-avbildningen och hur den kan kombineras med en ren webbserver av typen NGINX med hj\u00e4lp av kedjade byggen (chained build) f\u00f6r att organisera en mer produktionsanpassad byggen f\u00f6r applikationer. I n\u00e4sta och sista artikel i denna serie kommer vi att visa hur man k\u00f6r en utvecklingsserver f\u00f6r sin applikation p\u00e5 OpenShift och s\u00e4kerst\u00e4ller synkronisering av lokala och fj\u00e4rrfiler.<\/p>\n
Inneh\u00e5ll i denna artikelserie<\/h3>\n
<\/p>\n