ઓપનશિફ્ટ પર આધુનિક એપ્લિકેશન્સ, ભાગ 2: સાંકળો બિલ્ડ્સ

કેમ છો બધા! આ અમારી શ્રેણીની બીજી પોસ્ટ છે જેમાં અમે Red Hat OpenShift પર આધુનિક વેબ એપ્લિકેશનને કેવી રીતે જમાવવી તે બતાવીએ છીએ.

અગાઉની પોસ્ટમાં, અમે નવી S2I (સ્રોત-થી-ઇમેજ) બિલ્ડર ઇમેજની ક્ષમતાઓ પર સહેજ સ્પર્શ કર્યો હતો, જે OpenShift પ્લેટફોર્મ પર આધુનિક વેબ એપ્લિકેશન બનાવવા અને જમાવટ કરવા માટે ડિઝાઇન કરવામાં આવી છે. પછી અમને એપ્લિકેશનને ઝડપથી જમાવવાના વિષયમાં રસ હતો, અને આજે આપણે "શુદ્ધ" બિલ્ડર ઇમેજ તરીકે S2I ઇમેજનો ઉપયોગ કેવી રીતે કરવો અને તેને સંબંધિત OpenShift એસેમ્બલીઓ સાથે કેવી રીતે જોડવું તે જોઈશું.

સ્વચ્છ બિલ્ડરની છબી

આપણે ભાગ XNUMX માં ઉલ્લેખ કર્યો છે તેમ, મોટા ભાગની આધુનિક વેબ એપ્લિકેશન્સમાં કહેવાતા બિલ્ડ સ્ટેજ હોય ​​છે, જે સામાન્ય રીતે કોડ ટ્રાન્સપિલેશન, બહુવિધ ફાઇલ જોડાણ અને મિનિફિકેશન જેવી કામગીરી કરે છે. આ કામગીરીના પરિણામે મેળવેલ ફાઇલો - અને આ સ્ટેટિક HTML, JavaScript અને CSS છે - આઉટપુટ ફોલ્ડરમાં સંગ્રહિત થાય છે. આ ફોલ્ડરનું સ્થાન સામાન્ય રીતે કયા બિલ્ડ ટૂલ્સનો ઉપયોગ કરવામાં આવે છે તેના પર આધાર રાખે છે, અને પ્રતિક્રિયા માટે આ ./build ફોલ્ડર હશે (અમે નીચે વધુ વિગતવાર આ પર પાછા આવીશું).

સોર્સ-ટુ-ઇમેજ (S2I)

આ પોસ્ટમાં અમે "S2I શું છે અને તેનો ઉપયોગ કેવી રીતે કરવો" વિષયને સ્પર્શતા નથી (તમે આ વિશે વધુ વાંચી શકો છો અહીં), પરંતુ વેબ એપ બિલ્ડર ઇમેજ શું કરે છે તે સમજવા માટે આ પ્રક્રિયાના બે પગલાઓ વિશે સ્પષ્ટ હોવું મહત્વપૂર્ણ છે.

વિધાનસભા તબક્કો

જ્યારે તમે ડોકર બિલ્ડ ચલાવો છો અને નવી ડોકર ઇમેજ સાથે સમાપ્ત કરો છો ત્યારે શું થાય છે તે એસેમ્બલીનો તબક્કો પ્રકૃતિમાં ખૂબ સમાન છે. તદનુસાર, ઓપનશિફ્ટ પ્લેટફોર્મ પર બિલ્ડ શરૂ કરતી વખતે આ તબક્કો થાય છે.

વેબ એપ્લિકેશન બિલ્ડર ઇમેજના કિસ્સામાં, તે તમારી એપ્લિકેશનની નિર્ભરતાને ઇન્સ્ટોલ કરવા અને બિલ્ડ ચલાવવા માટે જવાબદાર છે. સ્ક્રિપ્ટ એસેમ્બલ કરો. મૂળભૂત રીતે, બિલ્ડર ઇમેજ npm રન બિલ્ડ કન્સ્ટ્રક્ટનો ઉપયોગ કરે છે, પરંતુ આ NPM_BUILD પર્યાવરણ વેરીએબલ દ્વારા ઓવરરાઇડ કરી શકાય છે.

જેમ આપણે અગાઉ કહ્યું તેમ, સમાપ્ત થયેલ, પહેલેથી જ બનાવેલ એપ્લિકેશનનું સ્થાન તમે કયા સાધનોનો ઉપયોગ કરો છો તેના પર આધાર રાખે છે. ઉદાહરણ તરીકે, પ્રતિક્રિયાના કિસ્સામાં આ ./build ફોલ્ડર હશે, અને કોણીય એપ્લિકેશન માટે તે પ્રોજેક્ટ_નામ/ડિસ્ટ ફોલ્ડર હશે. અને, અગાઉની પોસ્ટમાં પહેલેથી જ બતાવ્યા પ્રમાણે, આઉટપુટ ડિરેક્ટરીનું સ્થાન, જે ડિફોલ્ટ રૂપે બિલ્ડ કરવા માટે સેટ છે, તે OUTPUT_DIR પર્યાવરણ વેરીએબલ દ્વારા ઓવરરાઇડ કરી શકાય છે. ઠીક છે, કારણ કે આઉટપુટ ફોલ્ડરનું સ્થાન ફ્રેમવર્કથી ફ્રેમવર્કમાં અલગ છે, તમે જનરેટ કરેલા આઉટપુટને ઈમેજના સ્ટાન્ડર્ડ ફોલ્ડરમાં કૉપિ કરો, એટલે કે /opt/apt-root/output. આ લેખના બાકીના ભાગને સમજવા માટે આ મહત્વપૂર્ણ છે, પરંતુ હમણાં માટે ચાલો ઝડપથી આગળના તબક્કા - રનનો તબક્કો જોઈએ.

રન તબક્કો

આ તબક્કો ત્યારે થાય છે જ્યારે એસેમ્બલી સ્ટેજ દરમિયાન બનાવેલી નવી ઈમેજ પર ડોકર રન માટે કોલ કરવામાં આવે છે. OpenShift પ્લેટફોર્મ પર જમાવટ કરતી વખતે તે જ થાય છે. ડિફૉલ્ટ સ્ક્રિપ્ટ ચલાવો ઉપયોગ કરે છે મોડ્યુલ સર્વ કરો ઉપરોક્ત માનક આઉટપુટ ડિરેક્ટરીમાં સ્થિત સ્થિર સામગ્રીને સેવા આપવા માટે.

એપ્લિકેશનને ઝડપથી જમાવવા માટે આ પદ્ધતિ સારી છે, પરંતુ સામાન્ય રીતે સ્થિર સામગ્રીને આ રીતે સેવા આપવા માટે ભલામણ કરવામાં આવતી નથી. ઠીક છે, કારણ કે વાસ્તવમાં અમે ફક્ત સ્થિર સામગ્રી જ આપીએ છીએ, અમને અમારી છબીની અંદર ઇન્સ્ટોલ કરેલ Node.js ની જરૂર નથી - એક વેબ સર્વર પૂરતું હશે.

બીજા શબ્દોમાં કહીએ તો, એસેમ્બલ કરતી વખતે આપણને એક વસ્તુની જરૂર હોય છે, જ્યારે એક્ઝિક્યુટ કરતી વખતે આપણને બીજી વસ્તુની જરૂર હોય છે. આ પરિસ્થિતિમાં, સાંકળો બાંધો હાથમાં આવે છે.

સાંકળો બાંધે છે

આ વિશે તેઓ લખે છે સાંકળો બાંધો OpenShift દસ્તાવેજીકરણમાં:

"બે એસેમ્બલીઓને એકસાથે જોડી શકાય છે, જેમાં એક સંકલિત એન્ટિટી જનરેટ કરે છે અને બીજી તે એન્ટિટીને અલગ ઈમેજમાં હોસ્ટ કરે છે જેનો ઉપયોગ તે એન્ટિટીને ચલાવવા માટે થાય છે."

બીજા શબ્દોમાં કહીએ તો, અમે અમારા બિલ્ડને ચલાવવા માટે વેબ એપ બિલ્ડર ઇમેજનો ઉપયોગ કરી શકીએ છીએ, અને પછી અમારી સામગ્રીને સેવા આપવા માટે વેબ સર્વર ઇમેજ, સમાન NGINX નો ઉપયોગ કરી શકીએ છીએ.

આમ, અમે વેબ એપ બિલ્ડર ઈમેજનો ઉપયોગ "શુદ્ધ" બિલ્ડર તરીકે કરી શકીએ છીએ અને તે જ સમયે નાની રનટાઈમ ઈમેજ ધરાવી શકીએ છીએ.

હવે આને ચોક્કસ ઉદાહરણ સાથે જોઈએ.

તાલીમ માટે અમે ઉપયોગ કરીશું સરળ પ્રતિક્રિયા એપ્લિકેશન, create-react-app કમાન્ડ લાઇન ટૂલનો ઉપયોગ કરીને બનાવેલ છે.

તે અમને બધું એકસાથે રાખવામાં મદદ કરશે OpenShift ટેમ્પલેટ ફાઇલ.

ચાલો આ ફાઇલને વધુ વિગતમાં જોઈએ, અને પરિમાણો વિભાગથી પ્રારંભ કરીએ.

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

અહીં બધું એકદમ સ્પષ્ટ છે, પરંતુ OUTPUT_DIR પેરામીટર પર ધ્યાન આપવું યોગ્ય છે. અમારા ઉદાહરણમાં રીએક્ટ એપ્લિકેશન માટે, ચિંતા કરવાની કોઈ વાત નથી, કારણ કે રીએક્ટ આઉટપુટ ફોલ્ડર તરીકે ડિફોલ્ટ મૂલ્યનો ઉપયોગ કરે છે, પરંતુ કોણીય અથવા અન્ય કોઈ બાબતના કિસ્સામાં, આ પરિમાણને આવશ્યકતા મુજબ બદલવાની જરૂર પડશે.

હવે ચાલો 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'

ત્રીજી અને ચોથી છબીઓ પર એક નજર નાખો. તે બંનેને ડોકર છબીઓ તરીકે વ્યાખ્યાયિત કરવામાં આવે છે, અને તમે સ્પષ્ટપણે જોઈ શકો છો કે તેઓ ક્યાંથી આવે છે.

ત્રીજી ઇમેજ વેબ-એપ-બિલ્ડર છે અને તે nodeshift/ubi8-s2i-web-app 10.x પર ટૅગ કરેલી છે. ડોકર હબ.

ચોથું એક NGINX ઇમેજ (સંસ્કરણ 1.12) છે જેમાં નવીનતમ ટેગ ચાલુ છે ડોકર હબ.

હવે પ્રથમ બે ઈમેજ જોઈએ. તે બંને શરૂઆતમાં ખાલી હોય છે અને માત્ર બિલ્ડ તબક્કા દરમિયાન જ બનાવવામાં આવે છે. પ્રથમ ઇમેજ, રિએક્ટ-વેબ-એપ-બિલ્ડર, એસેમ્બલી સ્ટેપનું પરિણામ હશે જે વેબ-એપ-બિલ્ડર-રનટાઇમ ઈમેજ અને અમારા સોર્સ કોડને જોડશે. તેથી જ અમે આ છબીના નામમાં "-બિલ્ડર" ઉમેર્યું છે.

બીજી ઇમેજ - react-web-app-runtime - nginx-image-runtime અને react-web-app-builder ઇમેજમાંથી કેટલીક ફાઇલોને સંયોજિત કરવાનું પરિણામ હશે. આ છબીનો ઉપયોગ જમાવટ દરમિયાન પણ કરવામાં આવશે અને તેમાં ફક્ત વેબ સર્વર અને અમારી એપ્લિકેશનનું સ્ટેટિક HTML, JavaScript, CSS હશે.

મૂંઝવણમાં? હવે ચાલો બિલ્ડ રૂપરેખાંકનો પર એક નજર કરીએ અને તે થોડું સ્પષ્ટ થઈ જશે.

અમારા નમૂનામાં બે બિલ્ડ રૂપરેખાંકનો છે. અહીં પ્રથમ છે, અને તે ખૂબ પ્રમાણભૂત છે:

  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

જેમ તમે જોઈ શકો છો, લેબલ 1 સાથેની લાઇન કહે છે કે આ બિલ્ડનું પરિણામ એ જ રિએક્ટ-વેબ-એપ-બિલ્ડર ઇમેજમાં મૂકવામાં આવશે જે અમે ઇમેજસ્ટ્રીમ્સ વિભાગમાં થોડું અગાઉ જોયું હતું.

2 લેબલવાળી લાઇન તમને કહે છે કે કોડ ક્યાંથી મેળવવો. અમારા કિસ્સામાં, આ એક ગિટ રીપોઝીટરી છે, અને સ્થાન, સંદર્ભ અને સંદર્ભ ફોલ્ડર એ પરિમાણો દ્વારા નિર્ધારિત કરવામાં આવે છે જે આપણે પહેલાથી જ ઉપર જોયું છે.

3 લેબલવાળી લાઇન એ છે જે આપણે પહેલાથી જ પરિમાણો વિભાગમાં જોયું છે. તે OUTPUT_DIR પર્યાવરણ ચલ ઉમેરે છે, જે અમારા ઉદાહરણમાં બિલ્ડ છે.
4 લેબલવાળી લાઇન વેબ-એપ-બિલ્ડર-રનટાઇમ ઇમેજનો ઉપયોગ કરવા માટે કહે છે, જે આપણે ઇમેજસ્ટ્રીમ વિભાગમાં પહેલાથી જ જોઈ છે.

5 લેબલવાળી લાઇન કહે છે કે જો S2I ઇમેજ તેને સપોર્ટ કરે અને વેબ એપ બિલ્ડર ઇમેજ કરે તો અમે ઇન્ક્રીમેન્ટલ બિલ્ડનો ઉપયોગ કરવા માંગીએ છીએ. પ્રથમ લોન્ચ સમયે, એસેમ્બલી સ્ટેજ પૂર્ણ કર્યા પછી, છબી node_modules ફોલ્ડરને આર્કાઇવ ફાઇલમાં સાચવશે. પછી, અનુગામી રન પર, બિલ્ડ ટાઈમ ઘટાડવા માટે ઈમેજ આ ફોલ્ડરને ખાલી અનઝિપ કરશે.

અને છેલ્લે, 6 લેબલવાળી લાઇન એ અમુક ટ્રિગર્સ છે જે બિલ્ડને આપોઆપ ચલાવવા માટે, મેન્યુઅલ હસ્તક્ષેપ વિના, જ્યારે કંઈક બદલાય છે.

એકંદરે આ એક સુંદર પ્રમાણભૂત બિલ્ડ રૂપરેખાંકન છે.

હવે ચાલો બીજા બિલ્ડ કન્ફિગરેશન પર એક નજર કરીએ. તે પ્રથમ એક જેવું જ છે, પરંતુ એક મહત્વપૂર્ણ તફાવત છે.

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

તેથી બીજું બિલ્ડ રૂપરેખાંકન પ્રતિક્રિયા-વેબ-એપ-રનટાઇમ છે, અને તે ખૂબ પ્રમાણભૂત રીતે શરૂ થાય છે.

1 લેબલવાળી લાઇન કંઈ નવી નથી - તે ફક્ત કહે છે કે બિલ્ડ પરિણામ પ્રતિક્રિયા-વેબ-એપ-રનટાઇમ ઈમેજમાં મૂકવામાં આવે છે.

અગાઉના રૂપરેખાંકનની જેમ 2 લેબલવાળી લાઇન સૂચવે છે કે સ્રોત કોડ ક્યાંથી મેળવવો. પરંતુ નોંધ લો કે અહીં અમે કહી રહ્યા છીએ કે તે છબી પરથી લેવામાં આવ્યું છે. વધુમાં, અમે હમણાં જ બનાવેલ ઈમેજમાંથી - પ્રતિક્રિયા-વેબ-એપ-બિલ્ડર (3 લેબલવાળી લીટીમાં દર્શાવેલ). અમે જે ફાઈલોનો ઉપયોગ કરવા માંગીએ છીએ તે ઈમેજની અંદર છે અને તેમનું સ્થાન 4 લેબલવાળી લાઈનમાં સેટ છે, અમારા કિસ્સામાં તે /opt/app-root/output/ છે. જો તમને યાદ હોય, તો આ તે છે જ્યાં અમારી એપ્લિકેશન બનાવવાના પરિણામોના આધારે જનરેટ થયેલ ફાઇલો સંગ્રહિત થાય છે.

લેબલ 5 સાથે શબ્દમાં નિર્દિષ્ટ કરેલ ગંતવ્ય ફોલ્ડર ફક્ત વર્તમાન ડિરેક્ટરી છે (આ બધું છે, યાદ રાખો, ઓપનશિફ્ટ નામની જાદુઈ વસ્તુની અંદર ચાલી રહ્યું છે, અને તમારા સ્થાનિક કમ્પ્યુટર પર નહીં).

વ્યૂહરચના વિભાગ - લાઇન લેબલ 6 - પણ પ્રથમ બિલ્ડ રૂપરેખાંકન સમાન છે. માત્ર આ વખતે આપણે nginx-image-runtime નો ઉપયોગ કરવા જઈ રહ્યા છીએ, જે આપણે ઈમેજસ્ટ્રીમ વિભાગમાં જોઈ ચૂક્યા છીએ.

છેલ્લે, 7 લેબલવાળી લાઇન એ ટ્રિગર્સનો એક વિભાગ છે જે દર વખતે પ્રતિક્રિયા-વેબ-એપ-બિલ્ડર ઇમેજ બદલાય ત્યારે આ બિલ્ડને સક્રિય કરશે.

નહિંતર, આ ટેમ્પલેટમાં સુંદર પ્રમાણભૂત જમાવટ ગોઠવણી, તેમજ સેવાઓ અને માર્ગો સાથે સંબંધિત વસ્તુઓ છે, પરંતુ અમે તે વધુ વિગતમાં જઈશું નહીં. મહેરબાની કરીને નોંધ કરો કે જે ઇમેજ જમાવવામાં આવશે તે રિએક્ટ-વેબ-એપ-રનટાઇમ ઇમેજ છે.

એપ્લિકેશન જમાવટ

તો હવે અમે ટેમ્પ્લેટ જોઈ લીધું છે, ચાલો જોઈએ કે એપ્લીકેશન જમાવવા માટે તેનો ઉપયોગ કેવી રીતે કરવો.

અમે અમારા નમૂનાને જમાવવા માટે oc નામના OpenShift ક્લાયંટ ટૂલનો ઉપયોગ કરી શકીએ છીએ:

$ 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

ઉપરના સ્ક્રીનશોટમાંનો પ્રથમ આદેશ ટેમ્પલેટ./openshiftio/application.yaml શોધવાની ઇરાદાપૂર્વકની એન્જિનિયરિંગ રીત છે.

બીજો આદેશ ફક્ત આ નમૂનાના આધારે નવી એપ્લિકેશન બનાવે છે.

આ આદેશો કામ કર્યા પછી, આપણે જોઈશું કે આપણી પાસે બે એસેમ્બલી છે:

અને ઓવરવ્યુ સ્ક્રીન પર પાછા ફરીને, અમે લોન્ચ કરેલ પોડ જોશું:

લિંક પર ક્લિક કરો અને અમને અમારી એપ્લિકેશન પર લઈ જવામાં આવશે, જે ડિફોલ્ટ પ્રતિક્રિયા એપ્લિકેશન પૃષ્ઠ છે:

પૂરક 1

કોણીય પ્રેમીઓ માટે અમારી પાસે પણ છે ઉદાહરણ એપ્લિકેશન.

OUTPUT_DIR વેરીએબલ સિવાય અહીંની પેટર્ન સમાન છે.

પૂરક 2

આ લેખમાં અમે વેબ સર્વર તરીકે NGINX નો ઉપયોગ કર્યો છે, પરંતુ તેને Apache સાથે બદલવું એકદમ સરળ છે, ફક્ત ફાઇલમાં ટેમ્પલેટ બદલો. NGINX છબી પર અપાચે છબી.

નિષ્કર્ષ

આ શ્રેણીના પહેલા ભાગમાં, અમે OpenShift પ્લેટફોર્મ પર આધુનિક વેબ એપ્લિકેશનને ઝડપથી કેવી રીતે જમાવવી તે બતાવ્યું. આજે આપણે જોયું કે વેબ એપ ઈમેજ શું કરે છે અને તેને વધુ પ્રોડક્શન-રેડી એપ્લીકેશન બિલ્ડ બનાવવા માટે ચેઈન બિલ્ડનો ઉપયોગ કરીને NGINX જેવા શુદ્ધ વેબ સર્વર સાથે કેવી રીતે જોડી શકાય છે. આ શ્રેણીના આગલા અને અંતિમ લેખમાં, અમે OpenShift પર તમારી એપ્લિકેશન માટે ડેવલપમેન્ટ સર્વર કેવી રીતે ચલાવવું અને સ્થાનિક અને રિમોટ ફાઇલોનું સિંક્રનાઇઝેશન સુનિશ્ચિત કરીશું તે બતાવીશું.

લેખોની આ શ્રેણીની સામગ્રી

• ભાગ 1: આધુનિક વેબ એપ્લિકેશનને માત્ર થોડા પગલામાં કેવી રીતે જમાવવા;
• ભાગ 2: હાલની HTTP સર્વર ઈમેજ સાથે નવી S2I ઈમેજનો ઉપયોગ કેવી રીતે કરવો, જેમ કે NGINX, પ્રોડક્શન ડિપ્લોયમેન્ટ માટે સંકળાયેલ ઓપનશિફ્ટ એસેમ્બલીનો ઉપયોગ કરીને;
• ભાગ 3: ઓપનશિફ્ટ પ્લેટફોર્મ પર તમારી એપ્લિકેશન માટે ડેવલપમેન્ટ સર્વર કેવી રીતે ચલાવવું અને તેને સ્થાનિક ફાઇલ સિસ્ટમ સાથે સિંક્રનાઇઝ કરવું.

વધારાના સંસાધનો

• મફત ઈ-બુક OpenShift પર જમાવવું.
• પર માહિતી OpenShift અને Kubernetes.

સોર્સ: www.habr.com