OpenShift - buduj automatyzację

W OpenShift mamy wiele metod automatyzacji potoku kompilacji. Aby to zrobić, musimy utworzyć zasób BuildConfig, aby opisać przepływ kompilacji. Przepływ w BuildConfig można porównać z definicją zadania w definicji zadania Jenkins. Tworząc przepływ kompilacji, musimy wybrać strategię kompilacji.

Plik BuildConfig

W OpenShift BuildConfig jest obiektem odpoczynku używanym do łączenia się z API, a następnie tworzenia nowej instancji.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

W OpenShift istnieją cztery typy strategii kompilacji.

  • Strategia od źródła do obrazu
  • Strategia Dockera
  • Strategia niestandardowa
  • Strategia rurociągów

Strategia od źródła do obrazu

Umożliwia tworzenie obrazów kontenerów zaczynając od kodu źródłowego. W tym przepływie rzeczywisty kod jest najpierw pobierany w kontenerze, a następnie kompilowany w nim. Skompilowany kod jest wdrażany w tym samym kontenerze, a obraz jest budowany na podstawie tego kodu.

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

Istnieje wiele zasad strategii.

  • Forcepull
  • Kompilacje przyrostowe
  • Kompilacje zewnętrzne

Strategia Dockera

W tym przepływie OpenShift używa Dockerfile do kompilowania obrazu, a następnie przekazuje utworzone obrazy do rejestru Docker.

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

Opcja pliku Docker może być używana w wielu lokalizacjach, zaczynając od ścieżki pliku, bez pamięci podręcznej i wymuszonego ściągania.

  • Z obrazu
  • Ścieżka Dockerfile
  • Brak pamięci podręcznej
  • Siła przyciągania

Strategia niestandardowa

Jest to jeden z różnych rodzajów strategii budowania, w których nie ma takiego przymusu, aby wynikiem kompilacji był obraz. Można to porównać do wolnej pracy Jenkinsa. Dzięki temu możemy tworzyć pakiety Jar, rpm i inne.

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

Składa się z wielu strategii kompilacji.

  • Odsłoń gniazdo Dockera
  • Secrets
  • Siła przyciągania

Strategia rurociągów

Strategia potoków służy do tworzenia niestandardowych potoków kompilacji. Jest to zasadniczo używane do implementacji przepływu pracy w potoku. Ten przepływ kompilacji używa niestandardowego przepływu potoku kompilacji przy użyciu języka Groovy DSL. OpenShift utworzy zadanie potoku w Jenkins i wykona je. Ten przepływ potoku może być również używany w Jenkins. W tej strategii używamy Jenkinsfile i dodajemy go do definicji buildconfig.

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

Using build pipeline

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>