თანამედროვე აპლიკაციები OpenShift-ზე, ნაწილი 2: ჯაჭვური კონსტრუქციები

Სალამი ყველას! ეს არის ჩვენი სერიის მეორე პოსტი, რომელშიც ჩვენ ვაჩვენებთ, თუ როგორ უნდა განვათავსოთ თანამედროვე ვებ აპლიკაციები Red Hat OpenShift-ზე.

წინა პოსტში ოდნავ შევეხეთ ახალი S2I (source-to-image) შემქმნელის იმიჯის შესაძლებლობებს, რომელიც განკუთვნილია OpenShift პლატფორმაზე თანამედროვე ვებ აპლიკაციების შესაქმნელად და განსათავსებლად. შემდეგ ჩვენ დავინტერესდით აპლიკაციის სწრაფად განლაგების თემით, დღეს კი განვიხილავთ, თუ როგორ გამოვიყენოთ S2I სურათი, როგორც „სუფთა“ მშენებლის სურათი და გავაერთიანოთ იგი დაკავშირებულ OpenShift ასამბლეებთან.

მშენებლის სუფთა სურათი

როგორც პირველ ნაწილში აღვნიშნეთ, თანამედროვე ვებ აპლიკაციების უმეტესობას აქვს ეგრეთ წოდებული მშენებლობის ეტაპი, რომელიც, როგორც წესი, ასრულებს ოპერაციებს, როგორიცაა კოდის ტრანსპილაცია, მრავალჯერადი ფაილების შეერთება და მინიფიკაცია. ამ ოპერაციების შედეგად მიღებული ფაილები - და ეს არის სტატიკური HTML, JavaScript და CSS - ინახება გამომავალი საქაღალდეში. ამ საქაღალდის მდებარეობა ჩვეულებრივ დამოკიდებულია იმაზე, თუ რა build ინსტრუმენტები გამოიყენება, ხოლო React-ისთვის ეს იქნება ./build საქაღალდე (ამას უფრო დეტალურად დავუბრუნდებით ქვემოთ).

წყარო-სურათი (S2I)

ამ პოსტში ჩვენ არ შევეხებით თემას "რა არის S2I და როგორ გამოვიყენოთ იგი" (შეგიძლიათ მეტი წაიკითხოთ ამის შესახებ აქ), მაგრამ მნიშვნელოვანია ვიცოდეთ ამ პროცესის ორი ნაბიჯი, რათა გაიგოთ რას აკეთებს Web App Builder სურათი.

შეკრების ეტაპი

ასამბლეის ფაზა ბუნებით ძალიან ჰგავს იმას, რაც ხდება, როდესაც თქვენ აწარმოებთ docker build-ს და მთავრდება ახალი Docker სურათით. შესაბამისად, ეს ეტაპი ხდება OpenShift პლატფორმაზე build-ის დაწყებისას.

Web App Builder სურათის შემთხვევაში, ის პასუხისმგებელია თქვენი აპლიკაციის დამოკიდებულებების დაყენებაზე და build-ის გაშვებაზე. სკრიპტის აწყობა. ნაგულისხმევად, აღმშენებლის სურათი იყენებს npm run build კონსტრუქციას, მაგრამ მისი გადაფარვა შესაძლებელია NPM_BUILD გარემოს ცვლადის მეშვეობით.

როგორც ადრე ვთქვით, დასრულებული, უკვე აშენებული აპლიკაციის მდებარეობა დამოკიდებულია იმაზე, თუ რა ინსტრუმენტებს იყენებთ. მაგალითად, React-ის შემთხვევაში ეს იქნება ./build საქაღალდე, ხოლო Angular აპლიკაციებისთვის ეს იქნება project_name/dist საქაღალდე. და, როგორც უკვე ნაჩვენებია წინა პოსტში, გამომავალი დირექტორიას მდებარეობა, რომელიც დაყენებულია ნაგულისხმევად ასაგებად, შეიძლება გადაიწეროს OUTPUT_DIR გარემოს ცვლადის მეშვეობით. კარგად, რადგან გამომავალი საქაღალდის მდებარეობა განსხვავდება ჩარჩოდან ჩარჩოში, თქვენ უბრალოდ დააკოპირებთ გამომუშავებულ გამომავალს გამოსახულების სტანდარტულ საქაღალდეში, კერძოდ /opt/apt-root/output. ეს მნიშვნელოვანია ამ სტატიის დანარჩენი გასაგებად, მაგრამ ახლა მოდით სწრაფად გადავხედოთ შემდეგ ეტაპზე - გაშვების ფაზას.

გაშვების ფაზა

ეს ეტაპი ხდება მაშინ, როდესაც გამოძახება ხდება დოკერის გაშვებაზე ახალ სურათზე, რომელიც შეიქმნა ასამბლეის ეტაპზე. იგივე ხდება OpenShift პლატფორმაზე განლაგებისას. ნაგულისხმევი სკრიპტის გაშვება იყენებს სერვისის მოდული ზემოაღნიშნულ სტანდარტულ გამომავალ დირექტორიაში მდებარე სტატიკური შინაარსის მოსამსახურებლად.

ეს მეთოდი კარგია აპლიკაციების სწრაფად განსათავსებლად, მაგრამ ზოგადად არ არის რეკომენდებული სტატიკური შინაარსის ამ გზით გამოყენება. ისე, რადგან სინამდვილეში ჩვენ მხოლოდ სტატიკურ შინაარსს ვემსახურებით, არ გვჭირდება Node.js დაინსტალირებული ჩვენი სურათის შიგნით - საკმარისი იქნება ვებ სერვერი.

სხვა სიტყვებით რომ ვთქვათ, აწყობისას გვჭირდება ერთი რამ, შესრულებისას - მეორე. ამ სიტუაციაში, ჯაჭვური ნაგებობები გამოდგება.

მიჯაჭვული ნაგებობები

ამაზე წერენ მიჯაჭვული ნაგებობები OpenShift დოკუმენტაციაში:

„ორი ასამბლეა შეიძლება ერთმანეთთან იყოს დაკავშირებული, ერთი ქმნის შედგენილ ერთეულს, ხოლო მეორე მასპინძლობს ამ ერთეულს ცალკეულ სურათში, რომელიც გამოიყენება ამ ერთეულის გასაშვებად.

სხვა სიტყვებით რომ ვთქვათ, ჩვენ შეგვიძლია გამოვიყენოთ Web App Builder-ის სურათი ჩვენი build-ის გასაშვებად და შემდეგ გამოვიყენოთ ვებ სერვერის სურათი, იგივე NGINX, ჩვენი შინაარსის მოსამსახურებლად.

ამრიგად, ჩვენ შეგვიძლია გამოვიყენოთ Web App Builder სურათი, როგორც „სუფთა“ მშენებელი და ამავე დროს გვქონდეს მცირე გაშვების სურათი.

ახლა მოდით შევხედოთ ამას კონკრეტული მაგალითით.

ტრენინგისთვის გამოვიყენებთ მარტივი React აპლიკაცია, შექმნილია 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 პარამეტრს. ჩვენს მაგალითში React აპლიკაციისთვის სანერვიულო არაფერია, რადგან React იყენებს ნაგულისხმევ მნიშვნელობას, როგორც გამომავალი საქაღალდე, მაგრამ Angular-ის ან სხვა რამის შემთხვევაში, ეს პარამეტრი საჭიროებისამებრ უნდა შეიცვალოს.

ახლა მოდით გადავხედოთ 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'

გადახედეთ მესამე და მეოთხე სურათებს. ისინი ორივე განისაზღვრება, როგორც Docker სურათები და თქვენ ნათლად ხედავთ, საიდან მოდის ისინი.

მესამე სურათი არის web-app-builder და ის მოდის nodeshift/ubi8-s2i-web-app-დან, რომელიც მონიშნულია 10.x-ზე. დოკერ კერა.

მეოთხე არის NGINX სურათი (ვერსია 1.12) უახლესი ტეგით დოკერ კერა.

ახლა მოდით შევხედოთ პირველ ორ სურათს. ისინი ორივე ცარიელია დასაწყისში და იქმნება მხოლოდ მშენებლობის ფაზაში. პირველი სურათი, react-web-app-builder, იქნება ასამბლეის ნაბიჯის შედეგი, რომელიც გააერთიანებს ვებ-აპლიკაციის შემქმნელ-გაშვების სურათს და ჩვენს წყაროს კოდს. ამიტომ ამ სურათის სახელს დავამატეთ "-builder".

მეორე სურათი - react-web-app-runtime - იქნება nginx-image-runtime და ზოგიერთი ფაილის გაერთიანების შედეგი react-web-app-builder სურათიდან. ეს სურათი ასევე გამოყენებული იქნება განლაგების დროს და შეიცავს მხოლოდ ვებ სერვერს და ჩვენი აპლიკაციის სტატიკურ HTML, JavaScript, CSS.

დაბნეული? ახლა მოდით შევხედოთ build-ის კონფიგურაციებს და ცოტა უფრო ნათელი გახდება.

ჩვენს შაბლონს აქვს ორი build კონფიგურაცია. აქ არის პირველი და საკმაოდ სტანდარტულია:

  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-ლი ეტიკეტის ხაზი ამბობს, რომ ამ კონსტრუქციის შედეგი განთავსდება იმავე react-web-app-builder სურათზე, რომელიც ცოტა ადრე ვნახეთ ImageStreams განყოფილებაში.

ხაზი, სახელწოდებით 2, გეტყვით, საიდან მიიღოთ კოდი. ჩვენს შემთხვევაში, ეს არის git საცავი და მდებარეობა, ref და კონტექსტური საქაღალდე განისაზღვრება იმ პარამეტრებით, რომლებიც უკვე ვნახეთ ზემოთ.

3-იანი ხაზი არის ის, რაც უკვე ვნახეთ პარამეტრების განყოფილებაში. ის ამატებს OUTPUT_DIR გარემოს ცვლადს, რომელიც ჩვენს მაგალითში არის build.
ხაზი, სახელწოდებით 4, ამბობს, რომ გამოიყენოს ვებ-აპლიკაციის შემქმნელი-გაშვების სურათი, რომელიც უკვე ვნახეთ ImageStream განყოფილებაში.

მე-5 სტრიქონში ნათქვამია, რომ ჩვენ გვინდა გამოვიყენოთ დამატებითი კონსტრუქცია, თუ S2I გამოსახულება მხარს უჭერს მას და Web App Builder-ის სურათს. პირველი გაშვებისას, ასამბლეის ეტაპის დასრულების შემდეგ, სურათი შეინახავს 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

ასე რომ, მეორე build კონფიგურაცია არის react-web-app-runtime და ის საკმაოდ სტანდარტულად იწყება.

ხაზი, სახელწოდებით 1, ახალი არაფერია - ის უბრალოდ ამბობს, რომ build-ის შედეგი მოთავსებულია react-web-app-runtime სურათში.

ხაზი წარწერით 2, როგორც წინა კონფიგურაციაში, მიუთითებს საიდან უნდა მიიღოთ წყაროს კოდი. მაგრამ ყურადღება მიაქციეთ, რომ აქ ჩვენ ვამბობთ, რომ ეს სურათიდან არის აღებული. უფრო მეტიც, იმ სურათიდან, რომელიც ჩვენ ახლახან შევქმენით - react-web-app-builder-ისგან (მითითებულია 3-ის ხაზში). ფაილები, რომლებიც გვინდა გამოვიყენოთ, არის გამოსახულების შიგნით და მათი მდებარეობა იქ არის მითითებული 4-ით, ჩვენს შემთხვევაში ეს არის /opt/app-root/output/. თუ გახსოვთ, სწორედ აქ ინახება ჩვენი აპლიკაციის შექმნის შედეგების საფუძველზე გენერირებული ფაილები.

დანიშნულების საქაღალდე, რომელიც მითითებულია ტერმინში ეტიკეტით 5, არის უბრალოდ მიმდინარე დირექტორია (ეს ყველაფერი, გახსოვდეთ, მუშაობს რაღაც ჯადოსნურ ნივთში, სახელწოდებით OpenShift, და არა თქვენს ადგილობრივ კომპიუტერზე).

სტრატეგიის განყოფილება - ხაზი 6-ით - ასევე მსგავსია პირველი build კონფიგურაციის. მხოლოდ ამჯერად ვაპირებთ გამოვიყენოთ nginx-image-runtime, რომელიც უკვე ვნახეთ ImageStream განყოფილებაში.

დაბოლოს, ხაზი, სახელწოდებით 7, არის ტრიგერების განყოფილება, რომელიც ააქტიურებს ამ build-ს ყოველ ჯერზე, როდესაც იცვლება react-web-app-builder სურათი.

წინააღმდეგ შემთხვევაში, ეს შაბლონი შეიცავს საკმაოდ სტანდარტული განლაგების კონფიგურაციას, ისევე როგორც მომსახურებებს და მარშრუტებს, მაგრამ ჩვენ ამ ზედმეტ დეტალებს არ შევეხებით. გთხოვთ გაითვალისწინოთ, რომ გამოსახულება, რომელიც განლაგდება არის react-web-app-runtime სურათი.

აპლიკაციის განლაგება

ახლა, როდესაც ჩვენ გადავხედეთ შაბლონს, ვნახოთ, როგორ გამოვიყენოთ იგი აპლიკაციის განსათავსებლად.

ჩვენ შეგვიძლია გამოვიყენოთ OpenShift კლიენტის ინსტრუმენტი, სახელწოდებით oc ჩვენი შაბლონის გამოსაყენებლად:

$ 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.

მეორე ბრძანება უბრალოდ ქმნის ახალ აპლიკაციას ამ შაბლონის საფუძველზე.

ამ ბრძანებების მუშაობის შემდეგ, ჩვენ დავინახავთ, რომ გვაქვს ორი ასამბლეა:

და დავბრუნდებით მიმოხილვის ეკრანზე, ჩვენ დავინახავთ გაშვებულ პოდს:

დააწკაპუნეთ ბმულზე და ჩვენ გადავიყვანთ ჩვენს აპლიკაციაში, რომელიც არის ნაგულისხმევი React App გვერდი:

დანამატი 1 წ

Angular-ის მოყვარულებისთვისაც გვაქვს განაცხადის მაგალითი.

ნიმუში აქაც იგივეა, გარდა OUTPUT_DIR ცვლადისა.

დანამატი 2 წ

ამ სტატიაში ჩვენ გამოვიყენეთ NGINX, როგორც ვებ სერვერი, მაგრამ მისი ჩანაცვლება Apache-ით საკმაოდ მარტივია, უბრალოდ შეცვალეთ შაბლონი ფაილში NGINX სურათი on აპაჩის სურათი.

დასკვნა

ამ სერიის პირველ ნაწილში ჩვენ ვაჩვენეთ, თუ როგორ სწრაფად განვათავსოთ თანამედროვე ვებ აპლიკაციები OpenShift პლატფორმაზე. დღეს ჩვენ შევხედეთ რას აკეთებს ვებ აპლიკაციის სურათი და როგორ შეიძლება მისი შერწყმა სუფთა ვებ სერვერთან, როგორიცაა NGINX, ჯაჭვური კონსტრუქციების გამოყენებით, უფრო წარმოებისთვის მზა აპლიკაციის შესაქმნელად. ამ სერიის შემდეგ და ბოლო სტატიაში ჩვენ გაჩვენებთ, თუ როგორ უნდა გაუშვათ განვითარების სერვერი თქვენი აპლიკაციისთვის OpenShift-ზე და უზრუნველვყოთ ლოკალური და დისტანციური ფაილების სინქრონიზაცია.

სტატიების ამ სერიის შინაარსი

• ნაწილი X: როგორ განათავსოთ თანამედროვე ვებ აპლიკაციები მხოლოდ რამდენიმე ნაბიჯით;
• ნაწილი 2: როგორ გამოვიყენოთ ახალი S2I სურათი არსებული HTTP სერვერის იმიჯით, როგორიცაა NGINX, ასოცირებული OpenShift ასამბლეის გამოყენებით წარმოების განსათავსებლად;
• ნაწილი 3: როგორ გაუშვათ განვითარების სერვერი თქვენი აპლიკაციისთვის OpenShift პლატფორმაზე და სინქრონიზაცია მოახდინოს ადგილობრივ ფაილურ სისტემასთან.

Დამატებითი რესურსები

• უფასო ელექტრონული წიგნი განლაგება OpenShift-ზე.
• Ინფორმაცია OpenShift და Kubernetes.

წყარო: www.habr.com