Construits à l’aide de BuildConfig

La construction est le processus de transformation des paramètres d’entrée en un objet résultant. Le plus souvent, le processus est utilisé pour transformer les paramètres d’entrée ou le code source en une image exécutable. L’objet BuildConfig est la définition de l’ensemble du processus de construction.

La société OpenShift Dedicated utilise Kubernetes en créant des conteneurs à partir de la création d’images et en les poussant vers un registre d’images de conteneur.

Les objets de construction partagent des caractéristiques communes, y compris les entrées pour une construction, l’exigence de compléter un processus de construction, l’enregistrement du processus de construction, la publication de ressources provenant de constructions réussies et la publication du statut final de la construction. Les builds profitent des restrictions de ressources, spécifiant des limites sur les ressources telles que l’utilisation du CPU, l’utilisation de la mémoire et le temps d’exécution de la construction ou du pod.

L’objet résultant d’une construction dépend du constructeur utilisé pour la créer. Dans le cas des constructions docker et S2I, les objets qui en résultent sont des images exécutables. Dans le cas des constructions personnalisées, les objets résultants sont ce que l’auteur de l’image du constructeur a spécifié.

En outre, la stratégie de construction de pipelines peut être utilisée pour mettre en œuvre des flux de travail sophistiqués:

La configuration de build décrit une définition de build unique et un ensemble de déclencheurs pour le moment où une nouvelle construction est créée. Les configurations de build sont définies par un BuildConfig, qui est un objet REST qui peut être utilisé dans un POST vers le serveur API pour créer une nouvelle instance.

La configuration de build, ou BuildConfig, se caractérise par une stratégie de build et une ou plusieurs sources. La stratégie détermine le processus, tandis que les sources fournissent sa contribution.

En fonction de la façon dont vous choisissez de créer votre application en utilisant OpenShift Dedicated, un BuildConfig est généralement généré automatiquement pour vous si vous utilisez la console Web ou CLI, et il peut être modifié à tout moment. Comprendre les pièces qui composent un BuildConfig et leurs options disponibles peut vous aider si vous choisissez de modifier manuellement votre configuration plus tard.

L’exemple suivant BuildConfig se traduit par une nouvelle construction chaque fois qu’une balise d’image conteneur ou le code source change:

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: "ruby-sample-build" 
spec:
  runPolicy: "Serial" 
  triggers: 
    -
      type: "GitHub"
      github:
        secret: "secret101"
    - type: "Generic"
      generic:
        secret: "secret101"
    -
      type: "ImageChange"
  source: 
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy: 
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "ruby-20-centos7:latest"
  output: 
    to:
      kind: "ImageStreamTag"
      name: "origin-ruby-sample:latest"
  postCommit: 
      script: "bundle exec rake test"

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: "ruby-sample-build" 

spec:
  runPolicy: "Serial" 

  triggers: 

    -
      type: "GitHub"
      github:
        secret: "secret101"
    - type: "Generic"
      generic:
        secret: "secret101"
    -
      type: "ImageChange"
  source: 

    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy: 

    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "ruby-20-centos7:latest"
  output: 

    to:
      kind: "ImageStreamTag"
      name: "origin-ruby-sample:latest"
  postCommit: 

      script: "bundle exec rake test"

L’entrée de build fournit du contenu source sur lequel les builds peuvent fonctionner. Les entrées de build suivantes vous permettent de fournir des sources dans OpenShift Dedicated, listées par ordre de priorité:

Il est possible de combiner plusieurs entrées en une seule version. Cependant, comme le Dockerfile en ligne a préséance, il peut écraser n’importe quel autre fichier nommé Dockerfile fourni par une autre entrée. Les dépôts binaires (local) et Git sont des entrées mutuellement exclusives.

Il est possible d’utiliser des secrets d’entrée lorsque vous ne voulez pas que certaines ressources ou informations d’identification utilisées lors d’une construction soient disponibles dans l’image de l’application finale produite par la construction, ou que vous souhaitez consommer une valeur définie dans une ressource secrète. Des artefacts externes peuvent être utilisés pour extraire des fichiers supplémentaires qui ne sont pas disponibles comme l’un des autres types d’entrée de build.

Lorsque vous exécutez une construction:

L’exemple suivant d’une définition de source comprend plusieurs types d’entrée et une explication de la façon dont ils sont combinés. Consultez les sections spécifiques pour chaque type d’entrée pour plus de détails sur la façon dont chaque type d’entrée est défini.

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git 
    ref: "master"
  images:
  - from:
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths:
    - destinationDir: app/dir/injected/dir 
      sourcePath: /usr/lib/somefile.jar
  contextDir: "app/dir" 
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git 

    ref: "master"
  images:
  - from:
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths:
    - destinationDir: app/dir/injected/dir 

      sourcePath: /usr/lib/somefile.jar
  contextDir: "app/dir" 

  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 

Lorsque vous fournissez une valeur dockerfile, le contenu de ce champ est écrit sur le disque en tant que fichier nommé dockerfile. Cela se fait après le traitement d’autres sources d’entrée, donc si le référentiel source d’entrée contient un Dockerfile dans le répertoire racine, il est écrasé avec ce contenu.

La définition de la source fait partie de la section Spécification dans le BuildConfig:

source:
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 

source:
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 

Il est possible d’ajouter des fichiers supplémentaires au processus de construction avec des images. Les images d’entrée sont référencées de la même manière que les cibles From et To image sont définies. Cela signifie que les images de conteneur et les balises de flux d’images peuvent être référencées. En conjonction avec l’image, vous devez fournir une ou plusieurs paires de chemin pour indiquer le chemin des fichiers ou des répertoires pour copier l’image et la destination pour les placer dans le contexte de construction.

Le chemin source peut être n’importe quel chemin absolu dans l’image spécifiée. La destination doit être un chemin d’annuaire relatif. Au moment de la construction, l’image est chargée et les fichiers et répertoires indiqués sont copiés dans le répertoire contextuel du processus de construction. C’est le même répertoire dans lequel le contenu du référentiel source est cloné. Lorsque le chemin source se termine dans /. alors le contenu du répertoire est copié, mais le répertoire lui-même n’est pas créé à la destination.

Les entrées d’image sont spécifiées dans la définition source du BuildConfig:

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git
    ref: "master"
  images: 
  - from: 
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths: 
    - destinationDir: injected/dir 
      sourcePath: /usr/lib/somefile.jar 
  - from:
      kind: ImageStreamTag
      name: myotherinputimage:latest
      namespace: myothernamespace
    pullSecret: mysecret 
    paths:
    - destinationDir: injected/dir
      sourcePath: /usr/lib/somefile.jar

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git
    ref: "master"
  images: 

  - from: 

      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths: 

    - destinationDir: injected/dir 

      sourcePath: /usr/lib/somefile.jar 

  - from:
      kind: ImageStreamTag
      name: myotherinputimage:latest
      namespace: myothernamespace
    pullSecret: mysecret 

    paths:
    - destinationDir: injected/dir
      sourcePath: /usr/lib/somefile.jar

oc secrets link builder dockerhub

$ oc secrets link builder dockerhub

Lorsqu’il est spécifié, le code source est récupéré à partir de l’emplacement fourni.

Lorsque vous fournissez un Dockerfile en ligne, il écrase le Dockerfile dans le contexteDir du référentiel Git.

La définition de la source fait partie de la section Spécification dans le BuildConfig:

source:
  git: 
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir" 
  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 

source:
  git: 

    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir" 

  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 

Dans le cas où le champ ref indique une requête de traction, le système utilise une opération de récupération de git, puis la vérification FETCH_HEAD.

Lorsqu’aucune valeur réf n’est fournie, OpenShift Dedicated effectue un clone peu profond (--profondeur=1). Dans ce cas, seuls les fichiers associés au plus récent commit sur la branche par défaut (généralement maître) sont téléchargés. Cela se traduit par le téléchargement des dépôts plus rapidement, mais sans l’historique complet de l’engagement. Afin d’effectuer un clone git complet de la branche par défaut d’un référentiel spécifié, définissez ref au nom de la branche par défaut (par exemple principal).

source:
  git:
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
    httpProxy: http://proxy.example.com
    httpsProxy: https://proxy.example.com
    noProxy: somedomain.com, otherdomain.com

source:
  git:
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
    httpProxy: http://proxy.example.com
    httpsProxy: https://proxy.example.com
    noProxy: somedomain.com, otherdomain.com

oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'

kind: Secret
apiVersion: v1
metadata:
  name: matches-all-corporate-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
  ...
---
kind: Secret
apiVersion: v1
metadata:
  name: override-for-my-dev-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
  ...

kind: Secret
apiVersion: v1
metadata:
  name: matches-all-corporate-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
  ...
---
kind: Secret
apiVersion: v1
metadata:
  name: override-for-my-dev-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
  ...

apiVersion: "build.openshift.io/v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
    git:
      uri: "https://github.com/user/app.git"
    sourceSecret:
      name: "basicsecret"
  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "python-33-centos7:latest"

apiVersion: "build.openshift.io/v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
    git:
      uri: "https://github.com/user/app.git"
    sourceSecret:
      name: "basicsecret"
  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "python-33-centos7:latest"

oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>

$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>

[http]
        sslVerify=false

[http]
        sslVerify=false

Le contenu en streaming d’un système de fichiers local vers le constructeur est appelé une construction de type binaire. La valeur correspondante de BuildConfig.spec.source.type est binaire pour ces builds.

Ce type de source est unique en ce qu’il est exploité uniquement en fonction de votre utilisation de la construction de démarrage oc.

Afin d’utiliser des builds binaires, invoquez oc start-build avec l’une de ces options:

Dans chacun des cas énumérés précédemment:

Au lieu d’un nom de fichier, vous pouvez passer une URL avec un schéma HTTP ou HTTPS à --from-file et --from-archive. Lorsque vous utilisez --from-file avec une URL, le nom du fichier dans l’image du constructeur est déterminé par l’en-tête Content-Disposition envoyé par le serveur Web, ou le dernier composant du chemin d’URL si l’en-tête n’est pas présent. Aucune forme d’authentification n’est prise en charge et il n’est pas possible d’utiliser un certificat TLS personnalisé ou de désactiver la validation du certificat.

Lorsque vous utilisez oc new-build --binary=true, la commande veille à ce que les restrictions associées aux builds binaires soient appliquées. Le BuildConfig résultant a un type source de binaire, ce qui signifie que la seule façon valide d’exécuter une build pour ce BuildConfig est d’utiliser oc start-build avec l’une des options pour fournir les données binaires requises.

Les options source Dockerfile et contextDir ont une signification particulière avec les builds binaires.

Dockerfile peut être utilisé avec n’importe quelle source de construction binaire. Lorsque Dockerfile est utilisé et que le flux binaire est une archive, son contenu sert de Dockerfile de remplacement à n’importe quel Dockerfile dans l’archive. Lorsque Dockerfile est utilisé avec l’argument --from-file, et que l’argument de fichier est nommé Dockerfile, la valeur de Dockerfile remplace la valeur du flux binaire.

Dans le cas du flux binaire encapsulant le contenu d’archive extrait, la valeur du champ contextDir est interprétée comme un sous-répertoire dans l’archive, et, si elle est valide, le constructeur change dans ce sous-répertoire avant d’exécuter la build.

Dans certains scénarios, les opérations de construction nécessitent des informations d’identification ou d’autres données de configuration pour accéder aux ressources dépendantes, mais il est indésirable que ces informations soient placées dans le contrôle de la source. À cet effet, vous pouvez définir des secrets d’entrée et configurer des cartes d’entrée.

Lors de la création d’une application Java avec Maven, par exemple, vous pouvez configurer un miroir privé de Maven Central ou JCenter accessible par des clés privées. Afin de télécharger des bibliothèques à partir de ce miroir privé, vous devez fournir ce qui suit:

« pour des raisons de sécurité, vous ne voulez pas exposer vos informations d’identification dans l’image de l’application.

Cet exemple décrit une application Java, mais vous pouvez utiliser la même approche pour ajouter des certificats SSL dans le répertoire /etc/ssl/certs, les clés API ou les jetons, les fichiers de licence, et plus encore.

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 
data: 
  username: <username> 
  password: <password>
stringData: 
  hostname: myapp.mydomain.com 

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 

data: 

  username: <username> 

  password: <password>
stringData: 

  hostname: myapp.mydomain.com 

Il n’est pas recommandé de stocker des fichiers binaires dans un référentiel source. C’est pourquoi vous devez définir une version qui tire des fichiers supplémentaires, tels que les dépendances Java .jar, pendant le processus de construction. La façon dont cela est fait dépend de la stratégie de construction que vous utilisez.

Dans le cas d’une stratégie de création de source, vous devez mettre les commandes shell appropriées dans le script assembler:

#!/bin/sh
APP_VERSION=1.0
wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

#!/bin/sh
APP_VERSION=1.0
wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

#!/bin/sh
exec java -jar app.jar

#!/bin/sh
exec java -jar app.jar

Dans le cas d’une stratégie de construction Docker, vous devez modifier le Dockerfile et invoquer les commandes shell avec l’instruction RUN:

FROM jboss/base-jdk:8

ENV APP_VERSION 1.0
RUN wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

EXPOSE 8080
CMD [ "java", "-jar", "app.jar" ]

FROM jboss/base-jdk:8

ENV APP_VERSION 1.0
RUN wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

EXPOSE 8080
CMD [ "java", "-jar", "app.jar" ]

Dans la pratique, vous voudrez peut-être utiliser une variable d’environnement pour l’emplacement du fichier afin que le fichier spécifique à télécharger puisse être personnalisé à l’aide d’une variable d’environnement définie sur le BuildConfig, plutôt que de mettre à jour le fichier Dockerfile ou assembler le script.

Il est possible de choisir entre différentes méthodes de définition des variables d’environnement:

Il est possible de fournir des builds avec un fichier .docker/config.json avec des informations d’identification valides pour les registres de conteneurs privés. Cela vous permet de pousser l’image de sortie dans un registre d’image de conteneur privé ou de tirer une image de constructeur du registre d’image de conteneur privé qui nécessite une authentification.

Il est possible de fournir des informations d’identification pour plusieurs référentiels au sein d’un même registre, chacun avec des informations d’identification spécifiques à ce chemin de registre.

Le fichier .docker/config.json se trouve dans votre répertoire d’accueil par défaut et a le format suivant:

auths:
  index.docker.io/v1/: 
    auth: "YWRfbGzhcGU6R2labnRib21ifTE=" 
    email: "user@example.com" 
  docker.io/my-namespace/my-user/my-image: 
    auth: "GzhYWRGU6R2fbclabnRgbkSp=""
    email: "user@example.com"
  docker.io/my-namespace: 
    auth: "GzhYWRGU6R2deesfrRgbkSp=""
    email: "user@example.com"

auths:
  index.docker.io/v1/: 

    auth: "YWRfbGzhcGU6R2labnRib21ifTE=" 

    email: "user@example.com" 

  docker.io/my-namespace/my-user/my-image: 

    auth: "GzhYWRGU6R2fbclabnRgbkSp=""
    email: "user@example.com"
  docker.io/my-namespace: 

    auth: "GzhYWRGU6R2deesfrRgbkSp=""
    email: "user@example.com"

Il est possible de définir plusieurs registres d’images de conteneur ou de définir plusieurs référentiels dans le même registre. Alternativement, vous pouvez également ajouter des entrées d’authentification à ce fichier en exécutant la commande de connexion docker. Le fichier sera créé s’il n’existe pas.

Kubernetes fournit des objets secrets, qui peuvent être utilisés pour stocker la configuration et les mots de passe.

Comme pour les variables d’environnement de pod, les variables d’environnement de build peuvent être définies en termes de références à d’autres ressources ou variables à l’aide de l’API Downward. Il y a quelques exceptions, qui sont notées.

Il est également possible de gérer les variables d’environnement définies dans le BuildConfig avec la commande oc set env.

Les secrets de certificat de service sont destinés à prendre en charge les applications complexes de middleware qui ont besoin de certificats out-of-the-box. Il a les mêmes paramètres que les certificats de serveur générés par l’outil administrateur pour les nœuds et les maîtres.

D’autres pods peuvent faire confiance aux certificats créés en cluster, qui ne sont signés que pour les noms DNS internes, en utilisant le paquet d’autorité de certification (CA) dans le fichier /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt qui est automatiquement monté dans leur pod.

L’algorithme de signature de cette fonctionnalité est x509.SHA256WithRSA. Afin de tourner manuellement, supprimer le secret généré. Création d’un nouveau certificat.

Afin d’utiliser un secret, un pod doit faire référence au secret. Le secret peut être utilisé avec un pod de trois façons:

Les secrets de type de volume écrivent des données dans le conteneur en tant que fichier en utilisant le mécanisme de volume. imagePullSecrets utilise les comptes de service pour l’injection automatique du secret dans tous les pods dans un espace de noms.

Lorsqu’un modèle contient une définition secrète, la seule façon pour le modèle d’utiliser le secret fourni est de s’assurer que les sources de volume secrètes sont validées et que la référence d’objet spécifié pointe réellement vers un objet de type Secret. C’est pourquoi un secret doit être créé avant les pods qui en dépendent. Le moyen le plus efficace de s’assurer que cela est de le faire injecter automatiquement grâce à l’utilisation d’un compte de service.

Les objets API secrets résident dans un espace de noms. Ils ne peuvent être référencés que par des pods dans ce même espace de noms.

Les secrets individuels sont limités à 1 Mo de taille. C’est pour décourager la création de grands secrets qui épuiseraient la mémoire apiserver et kubelet. Cependant, la création d’un certain nombre de petits secrets pourrait également épuiser la mémoire.

Les constructions qui utilisent la stratégie source à image (S2I) aboutissent à la création d’une nouvelle image conteneur. L’image est ensuite poussée vers le registre d’image du conteneur spécifié dans la section de sortie de la spécification Build.

Lorsque le type de sortie est ImageStreamTag, l’image sera poussée vers le registre d’images OpenShift intégré et marquée dans le flux d’images spécifié. Lorsque la sortie est de type DockerImage, le nom de la référence de sortie sera utilisé comme spécification de poussée docker. La spécification peut contenir un registre ou sera par défaut à DockerHub si aucun registre n’est spécifié. Lorsque la section de sortie de la spécification de construction est vide, l’image ne sera pas poussée à la fin de la construction.

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"

spec:
  output:
    to:
      kind: "DockerImage"
      name: "my-registry.mycompany.com:5000/myimages/myimage:tag"

spec:
  output:
    to:
      kind: "DockerImage"
      name: "my-registry.mycompany.com:5000/myimages/myimage:tag"

la stratégie source à image (S2I) établit les variables d’environnement suivantes sur les images de sortie:

En outre, toute variable d’environnement définie par l’utilisateur, par exemple celles configurées avec les options de stratégie S2I, fera également partie de la liste des variables d’environnement d’image de sortie.

la source à l’image (S2I) crée les étiquettes suivantes sur les images de sortie:

Il est également possible d’utiliser le champ BuildConfig.spec.output.imageLabels pour spécifier une liste d’étiquettes personnalisées qui seront appliquées à chaque image construite à partir de la configuration de construction.

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "my-image:latest"
    imageLabels:
    - name: "vendor"
      value: "MyCompany"
    - name: "authoritative-source-url"
      value: "registry.mycompany.com"

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "my-image:latest"
    imageLabels:
    - name: "vendor"
      value: "MyCompany"
    - name: "authoritative-source-url"
      value: "registry.mycompany.com"

Le logiciel OpenShift Dedicated utilise Buildah pour construire une image conteneur à partir d’un Dockerfile. Consultez la documentation de référence Dockerfile pour plus d’informations sur les images de conteneurs de construction avec Dockerfile.

dockerStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"

dockerStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"

La source à l’image (S2I) est un outil pour construire des images de conteneurs reproductibles. Il produit des images prêtes à l’emploi en injectant une source d’application dans une image de conteneur et en assemblant une nouvelle image. La nouvelle image intègre l’image de base, le constructeur et la source construite et est prête à être utilisée avec la commande buildah run. Le S2I prend en charge les constructions incrémentielles, qui réutilisent des dépendances précédemment téléchargées, des artefacts précédemment construits, et ainsi de suite.

restore build artifacts
move the application source
build application artifacts
install the artifacts

#!/bin/bash

# restore build artifacts
if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then
    mv /tmp/s2i/artifacts/* $HOME/.
fi

# move the application source
mv /tmp/s2i/src $HOME/src

# build application artifacts
pushd ${HOME}
make all

# install the artifacts
make install
popd

run the application

#!/bin/bash

# run the application
/opt/application/run.sh

#!/bin/bash

pushd ${HOME}
if [ -d deps ]; then
    # all deps contents to tar stream
    tar cf - deps
fi
popd

#!/bin/bash

pushd ${HOME}
if [ -d deps ]; then
    # all deps contents to tar stream
    tar cf - deps
fi
popd

inform the user how to use the image

#!/bin/bash

# inform the user how to use the image
cat <<EOF
This is a S2I sample builder image, to use it, install
https://github.com/openshift/source-to-image
EOF

La stratégie de construction Pipeline permet aux développeurs de définir un pipeline Jenkins pour une utilisation par le plugin pipeline Jenkins. La construction peut être démarrée, surveillée et gérée par OpenShift Dedicated de la même manière que n’importe quel autre type de construction.

Les flux de travail de pipeline sont définis dans un fichier jenkins, soit intégrés directement dans la configuration de construction, soit fournis dans un référentiel Git et référencés par la configuration de construction.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        node('agent') {
          stage 'build'
          openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true')
          stage 'deploy'
          openshiftDeploy(deploymentConfig: 'frontend')
        }

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        node('agent') {
          stage 'build'
          openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true')
          stage 'deploy'
          openshiftDeploy(deploymentConfig: 'frontend')
        }

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  source:
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfilePath: some/repo/dir/filename 

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  source:
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfilePath: some/repo/dir/filename 

Ajoutez un secret à votre configuration de build afin qu’il puisse accéder à un référentiel privé.

Il est possible de tirer sur un registre privé en réglant le secret d’attraction et en poussant en plaçant le secret de poussée dans la configuration de la construction.

Afin d’activer la poussée:

Dans votre projet actuel, vous pouvez démarrer manuellement une nouvelle construction à partir d’une configuration de construction existante.

Il est possible d’annuler une construction à l’aide de la console Web ou de la commande CLI suivante.

Afin de modifier vos configurations de build, vous utilisez l’option Edit BuildConfig dans la vue Builds de la perspective Développeur.

Il est possible d’utiliser l’une ou l’autre des vues suivantes pour modifier un BuildConfig:

Il est possible de basculer entre la vue Formulaire et YAML sans perdre de données. Les données de la vue Formulaire sont transférées à la vue YAML et vice versa.

Il est possible de supprimer un BuildConfig à l’aide de la commande suivante.

Il est possible d’afficher les détails de construction avec la console Web ou en utilisant la commande CLI de description d’oc.

Ceci affiche des informations, y compris:

Dans le cas où la construction utilise la stratégie Source, la sortie décrit oc inclut également des informations sur la révision de la source utilisée pour la construction, y compris l’ID de commit, l’auteur, le committer et le message.

Il est possible d’accéder aux journaux de construction à l’aide de la console Web ou du CLI.

Lorsque vous définissez un BuildConfig, vous pouvez définir des déclencheurs pour contrôler les circonstances dans lesquelles le BuildConfig doit être exécuté. Les déclencheurs de build suivants sont disponibles:

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

type: "GitLab"
gitlab:
  secretReference:
    name: "mysecret"

type: "GitLab"
gitlab:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

type: "Bitbucket"
bitbucket:
  secretReference:
    name: "mysecret"

type: "Bitbucket"
bitbucket:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 

oc describe bc <name>

$ oc describe bc <name>

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"

type: "ImageChange"
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
  paused: true

type: "ImageChange"
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
  paused: true

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: bc-ict-example
  namespace: bc-ict-example-namespace
spec:

# ...

  triggers:
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input:latest
        namespace: bc-ict-example-namespace
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input2:latest
        namespace: bc-ict-example-namespace
    type: ImageChange
status:
  imageChangeTriggers:
  - from:
      name: input:latest
      namespace: bc-ict-example-namespace
    lastTriggerTime: "2021-06-30T13:47:53Z"
    lastTriggeredImageID: image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input@sha256:0f88ffbeb9d25525720bfa3524cb1bf0908b7f791057cf1acfae917b11266a69
  - from:
      name: input2:latest
      namespace: bc-ict-example-namespace
    lastTriggeredImageID:  image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input2@sha256:0f88ffbeb9d25525720bfa3524cb2ce0908b7f791057cf1acfae917b11266a69

  lastVersion: 1

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: bc-ict-example
  namespace: bc-ict-example-namespace
spec:

# ...

  triggers:
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input:latest
        namespace: bc-ict-example-namespace
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input2:latest
        namespace: bc-ict-example-namespace
    type: ImageChange
status:
  imageChangeTriggers:
  - from:
      name: input:latest
      namespace: bc-ict-example-namespace
    lastTriggerTime: "2021-06-30T13:47:53Z"
    lastTriggeredImageID: image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input@sha256:0f88ffbeb9d25525720bfa3524cb1bf0908b7f791057cf1acfae917b11266a69
  - from:
      name: input2:latest
      namespace: bc-ict-example-namespace
    lastTriggeredImageID:  image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input2@sha256:0f88ffbeb9d25525720bfa3524cb2ce0908b7f791057cf1acfae917b11266a69

  lastVersion: 1

  type: "ConfigChange"

  type: "ConfigChange"

oc set triggers --help

$ oc set triggers --help

Les crochets de construction permettent d’injecter le comportement dans le processus de construction.

Le champ postCommit d’un objet BuildConfig exécute des commandes à l’intérieur d’un conteneur temporaire qui exécute l’image de sortie de build. Le crochet est exécuté immédiatement après que la dernière couche de l’image a été commise et avant que l’image ne soit poussée à un registre.

Le répertoire de travail actuel est défini sur le WORKDIR de l’image, qui est le répertoire de travail par défaut de l’image conteneur. Dans la plupart des images, c’est là que se trouve le code source.

Le crochet échoue si le script ou la commande renvoie un code de sortie non nul ou si le démarrage du conteneur temporaire échoue. Lorsque le crochet échoue, il marque la construction comme ayant échoué et l’image n’est pas poussée vers un registre. La raison de l’échec peut être inspectée en regardant les journaux de construction.

Les crochets de construction peuvent être utilisés pour exécuter des tests unitaires pour vérifier l’image avant que la construction ne soit marquée et que l’image soit disponible dans un registre. Lorsque tous les tests passent et que le coureur d’essai retourne avec le code de sortie 0, la construction est marquée avec succès. En cas de défaillance du test, la construction est marquée comme ayant échoué. Dans tous les cas, le journal de construction contient la sortie du coureur de test, qui peut être utilisé pour identifier les tests échoués.

Le crochet postCommit est non seulement limité à l’exécution de tests, mais peut également être utilisé pour d’autres commandes. Comme il fonctionne dans un conteneur temporaire, les modifications apportées par le crochet ne persistent pas, ce qui signifie que l’exécution du crochet ne peut pas affecter l’image finale. Ce comportement permet, entre autres, l’installation et l’utilisation de dépendances de test qui sont automatiquement éliminées et ne sont pas présentes dans l’image finale.

Les builds par défaut sont complétés par des pods utilisant des ressources non liées, telles que la mémoire et le CPU. Ces ressources peuvent être limitées.

Lors de la définition d’un objet BuildConfig, vous pouvez définir sa durée maximale en définissant le champ CompleteDeadlineSeconds. Il est spécifié en secondes et n’est pas défini par défaut. Lorsqu’il n’est pas défini, il n’y a pas de durée maximale appliquée.

La durée maximale est comptée à partir du moment où un groupe de construction est programmé dans le système, et définit combien de temps il peut être actif, y compris le temps nécessaire pour tirer l’image du constructeur. Après avoir atteint le délai spécifié, la construction est terminée par OpenShift Dedicated.

Les builds peuvent être ciblés pour s’exécuter sur des nœuds spécifiques en spécifiant les étiquettes dans le champ nodeSelector d’une configuration de build. La valeur nodeSelector est un ensemble de paires clé-valeur qui sont appariées aux étiquettes Node lors de la planification de la gousse de construction.

La valeur nodeSelector peut également être contrôlée par des valeurs par défaut et outrepassées à l’échelle du cluster. Les valeurs par défaut ne seront appliquées que si la configuration de build ne définit pas de paires clé-valeur pour le nodeSelector et ne définit pas non plus une valeur cartographique explicitement vide de nodeSelector:{}. Les valeurs de dépassement remplaceront les valeurs dans la configuration de build sur une base clé par clé.

Dans le cas des langages compilés tels que Go, C++ et Java, y compris les dépendances nécessaires à la compilation dans l’image de l’application, pourraient augmenter la taille de l’image ou introduire des vulnérabilités qui peuvent être exploitées.

Afin d’éviter ces problèmes, deux constructions peuvent être enchaînées ensemble. D’une construction qui produit l’artefact compilé, et une seconde qui place cet artéfact dans une image séparée qui exécute l’artefact.

Les constructions qui ont terminé leur cycle de vie sont maintenues indéfiniment. Il est possible de limiter le nombre de versions précédentes qui sont conservées.

Les constructions sont triées par leur horodatage de création avec les plus anciennes constructions élaguées en premier.

La stratégie d’exécution de construction décrit l’ordre dans lequel les builds créés à partir de la configuration de construction doivent s’exécuter. Cela peut être fait en modifiant la valeur du champ runPolicy dans la section Spécifications de la spécification Build.

Il est également possible de modifier la valeur runPolicy pour les configurations de build existantes, en:

Afin d’installer les paquets Red Hat Enterprise Linux (RHEL) dans une version, vous pouvez créer une balise de flux d’images pour faire référence à l’image de base universelle Red Hat (UBI).

Afin de rendre l’UBI disponible dans chaque projet du cluster, ajoutez la balise flux d’image à l’espace de noms openshift. Dans le cas contraire, pour le rendre disponible dans un projet spécifique, ajoutez la balise flux d’image à ce projet.

Les balises de flux d’images permettent l’accès à l’UBI en utilisant les identifiants Registry.redhat.io qui sont présents dans le secret d’installation, sans exposer le secret d’attraction à d’autres utilisateurs. Cette méthode est plus pratique que d’exiger que chaque développeur installe des secrets de traction avec des identifiants Registry.redhat.io dans chaque projet.

Les builds qui utilisent des abonnements Red Hat pour installer du contenu doivent inclure les clés de droit comme secret de construction.

En cas de refus de votre demande d’accès aux ressources:

requested access to the resource is denied

requested access to the resource is denied

oc describe quota

$ oc describe quota

En cas de refus de votre demande d’accès aux ressources:

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60