CI/CD

Une compilation 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. Un objet BuildConfig est la définition de l'ensemble du processus de construction.

OpenShift Container Platform utilise Kubernetes en créant des conteneurs à partir d'images de construction et en les poussant vers un registre d'images de conteneurs.

Les objets de construction partagent des caractéristiques communes, notamment les entrées pour une construction, la nécessité d'achever un processus de construction, l'enregistrement du processus de construction, la publication des ressources des constructions réussies et la publication de l'état final de la construction. Les constructions tirent parti des restrictions de ressources, en spécifiant des limites sur les ressources telles que l'utilisation de l'unité centrale, l'utilisation de la mémoire et le temps d'exécution de la construction ou du pod.

Le système de construction d'OpenShift Container Platform fournit un support extensible pour les stratégies de construction qui sont basées sur des types sélectionnables spécifiés dans l'API de construction. Il existe trois stratégies de construction principales :

Par défaut, les constructions docker et les constructions S2I sont prises en charge.

L'objet résultant d'une compilation dépend du constructeur utilisé pour la créer. Pour les constructions docker et S2I, les objets résultants sont des images exécutables. Pour les 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 pipeline peut être utilisée pour mettre en œuvre des flux de travail sophistiqués :

Une configuration de construction décrit une définition de construction unique et un ensemble de déclencheurs pour la création d'une nouvelle construction. Les configurations de construction sont définies par un BuildConfig, qui est un objet REST pouvant être utilisé dans un POST au serveur API pour créer une nouvelle instance.

Une configuration de construction, ou BuildConfig, est caractérisée par une stratégie de construction et une ou plusieurs sources. La stratégie détermine le processus, tandis que les sources fournissent les données d'entrée.

Selon la façon dont vous choisissez de créer votre application avec OpenShift Container Platform, un BuildConfig est généralement généré automatiquement pour vous si vous utilisez la console web ou le CLI, et il peut être modifié à tout moment. Comprendre les éléments qui composent un BuildConfig et leurs options disponibles peut vous aider si vous choisissez de modifier manuellement votre configuration ultérieurement.

L'exemple suivant BuildConfig entraîne une nouvelle compilation chaque fois qu'une balise d'image de conteneur ou le code source est modifié :

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"

Une entrée de construction fournit un contenu source sur lequel les constructions peuvent opérer. Vous pouvez utiliser les entrées de construction suivantes pour fournir des sources dans OpenShift Container Platform, listées par ordre de priorité :

Vous pouvez combiner plusieurs entrées dans une seule compilation. Cependant, comme le fichier Dockerfile en ligne est prioritaire, il peut écraser tout autre fichier nommé Dockerfile fourni par une autre entrée. Les entrées binaires (locales) et les dépôts Git sont des entrées mutuellement exclusives.

Vous pouvez utiliser les secrets d'entrée lorsque vous ne souhaitez pas que certaines ressources ou informations d'identification utilisées pendant la construction soient disponibles dans l'image finale de l'application produite par la construction, ou lorsque vous souhaitez consommer une valeur définie dans une ressource secrète. Les artefacts externes peuvent être utilisés pour récupérer des fichiers supplémentaires qui ne sont pas disponibles dans l'un des autres types d'entrée de compilation.

Lorsque vous exécutez une compilation :

L'exemple suivant de définition d'une source comprend plusieurs types d'entrée et une explication de la manière dont ils sont combinés. Pour plus de détails sur la définition de chaque type d'entrée, voir les sections spécifiques à chaque type d'entrée.

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 dans un fichier nommé dockerfile. Cette opération est effectuée après le traitement des autres sources d'entrée, donc si le référentiel de la source d'entrée contient un Dockerfile dans le répertoire racine, il est remplacé par ce contenu.

La définition de la source fait partie de la section spec du site BuildConfig:

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

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

Vous pouvez 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 d'image From et To sont définies. Cela signifie que les images de conteneurs 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 chemins 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 d'accès source peut être n'importe quel chemin d'accès absolu dans l'image spécifiée. La destination doit être un chemin de répertoire 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. Il s'agit du même répertoire dans lequel le contenu du référentiel source est cloné. Si le chemin source se termine par /., le contenu du répertoire est copié, mais le répertoire lui-même n'est pas créé à la destination.

Les entrées d'images sont spécifiées dans la définition de source de 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 extrait de l'emplacement fourni.

Si vous fournissez un fichier Docker en ligne, il écrase le fichier Docker qui se trouve à l'adresse contextDir du dépôt Git.

La définition de la source fait partie de la section spec du site 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" 

Si le champ ref indique une demande d'extraction, le système utilise une opération git fetch et ensuite la caisse FETCH_HEAD.

Si aucune valeur ref n'est fournie, OpenShift Container Platform effectue un clone superficiel (--depth=1). Dans ce cas, seuls les fichiers associés au commit le plus récent sur la branche par défaut (généralement master) sont téléchargés. Les dépôts se téléchargent ainsi plus rapidement, mais sans l'historique complet des livraisons. Pour effectuer un git clone complet de la branche par défaut d'un dépôt spécifié, définissez ref comme étant le nom de la branche par défaut (par exemple master).

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: "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: "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

La diffusion de contenu à partir d'un système de fichiers local vers le constructeur est appelée construction de type Binary. La valeur correspondante de BuildConfig.spec.source.type est Binary pour ces constructions.

Ce type de source est unique en ce sens qu'il est utilisé uniquement en fonction de l'utilisation que vous faites du site oc start-build.

Pour utiliser les constructions 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 transmettre 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 par le dernier composant du chemin 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.

Lors de l'utilisation de oc new-build --binary=true, la commande s'assure que les restrictions associées aux constructions binaires sont appliquées. Le résultat BuildConfig a un type de source de Binary, ce qui signifie que la seule façon valide d'exécuter une compilation pour ce BuildConfig est d'utiliser oc start-build avec l'une des options --from pour fournir les données binaires requises.

Les options Dockerfile et contextDir source ont une signification particulière pour les constructions binaires.

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

Dans le cas du flux binaire encapsulant le contenu extrait de l'archive, la valeur du champ contextDir est interprétée comme un sous-répertoire de l'archive et, s'il est valide, le constructeur passe à ce sous-répertoire avant d'exécuter la construction.

Dans certains cas, 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 n'est pas souhaitable que ces informations soient placées dans le contrôle de la source. Vous pouvez définir des secrets d'entrée et des cartes de configuration d'entrée à cette fin.

Par exemple, lorsque vous construisez une application Java avec Maven, vous pouvez mettre en place un miroir privé de Maven Central ou JCenter auquel vous accédez par des clés privées. Pour télécharger des bibliothèques à partir de ce miroir privé, vous devez fournir les éléments suivants :

Pour des raisons de sécurité, vous ne souhaitez 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, des clés ou des jetons d'API, des fichiers de licence, etc.

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

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

data: 

  username: dmFsdWUtMQ0K 

  password: dmFsdWUtMg0KDQo=
stringData: 

  hostname: myapp.mydomain.com 

oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn” \
    --build-config-map "settings-mvn"

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn” \
    --build-config-map "settings-mvn"

source:
  git:
    uri: https://github.com/wildfly/quickstart.git
  contextDir: helloworld
  configMaps:
    - configMap:
        name: settings-mvn
      destinationDir: ".m2"
  secrets:
    - secret:
        name: secret-mvn
      destinationDir: ".ssh"

source:
  git:
    uri: https://github.com/wildfly/quickstart.git
  contextDir: helloworld
  configMaps:
    - configMap:
        name: settings-mvn
      destinationDir: ".m2"
  secrets:
    - secret:
        name: secret-mvn
      destinationDir: ".ssh"

oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn:.ssh” \
    --build-config-map "settings-mvn:.m2"

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn:.ssh” \
    --build-config-map "settings-mvn:.m2"

FROM centos/ruby-22-centos7

USER root
COPY ./secret-dir /secrets
COPY ./config /

# Create a shell script that will output secrets and ConfigMaps when the image is run
RUN echo '#!/bin/sh' > /input_report.sh
RUN echo '(test -f /secrets/secret1 && echo -n "secret1=" && cat /secrets/secret1)' >> /input_report.sh
RUN echo '(test -f /config && echo -n "relative-configMap=" && cat /config)' >> /input_report.sh
RUN chmod 755 /input_report.sh

CMD ["/bin/sh", "-c", "/input_report.sh"]

FROM centos/ruby-22-centos7

USER root
COPY ./secret-dir /secrets
COPY ./config /

# Create a shell script that will output secrets and ConfigMaps when the image is run
RUN echo '#!/bin/sh' > /input_report.sh
RUN echo '(test -f /secrets/secret1 && echo -n "secret1=" && cat /secrets/secret1)' >> /input_report.sh
RUN echo '(test -f /config && echo -n "relative-configMap=" && cat /config)' >> /input_report.sh
RUN chmod 755 /input_report.sh

CMD ["/bin/sh", "-c", "/input_report.sh"]

Il n'est pas recommandé de stocker des fichiers binaires dans un référentiel de sources. Par conséquent, vous devez définir une construction qui extrait des fichiers supplémentaires, tels que les dépendances Java .jar, au cours du processus de construction. La manière de procéder dépend de la stratégie de compilation que vous utilisez.

Pour une stratégie de construction de Source, vous devez insérer les commandes shell appropriées dans le script assemble:

#!/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

Pour une stratégie de construction Docker, vous devez modifier le fichier Docker et invoquer des commandes shell avec l'instructionRUN :

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 souhaiterez 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 site BuildConfig, plutôt que de mettre à jour le fichier Dockerfile ou le script assemble.

Vous avez le choix entre différentes méthodes pour définir les variables d'environnement :

Vous pouvez fournir aux constructions 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'images de conteneurs privé ou de tirer une image de construction du registre d'images de conteneurs privé qui nécessite une authentification.

Vous pouvez fournir des informations d'identification pour plusieurs référentiels dans le même registre, chacun avec des informations d'identification spécifiques à ce chemin d'accès au registre.

Le fichier .docker/config.json se trouve par défaut dans votre répertoire personnel 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"

Vous pouvez définir plusieurs registres d'images de conteneurs ou plusieurs référentiels dans le même registre. Vous pouvez également ajouter des entrées d'authentification à ce fichier en exécutant la commande docker login. Le fichier sera créé s'il n'existe pas.

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

Comme pour les variables d'environnement pod, les variables d'environnement 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.

Vous pouvez également gérer les variables d'environnement définies dans le site BuildConfig à l'aide de la commande oc set env.

Les secrets de certificats de service sont destinés à prendre en charge des applications intergicielles complexes qui nécessitent des certificats prêts à l'emploi. Ils ont les mêmes paramètres que les certificats de serveur générés par l'outil d'administration pour les nœuds et les maîtres.

Les autres pods peuvent faire confiance aux certificats créés par le cluster, qui ne sont signés que pour les noms DNS internes, en utilisant le bundle de l'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 pour cette fonctionnalité est x509.SHA256WithRSA. Pour effectuer une rotation manuelle, supprimez le secret généré. Un nouveau certificat est créé.

Pour utiliser un secret, un module doit faire référence au secret. Un secret peut être utilisé avec un module de trois façons :

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

Lorsqu'un modèle contient une définition de secret, le seul moyen pour le modèle d'utiliser le secret fourni est de s'assurer que les sources de volume du secret sont validées et que la référence d'objet spécifiée pointe effectivement vers un objet de type Secret. Par conséquent, un secret doit être créé avant tous les pods qui en dépendent. Le moyen le plus efficace de s'en assurer est de l'injecter automatiquement par l'intermédiaire 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 les pods de ce même espace de noms.

La taille des secrets individuels est limitée à 1 Mo. Il s'agit de décourager la création de secrets volumineux qui épuiseraient la mémoire de l'apiserver et du kubelet. Cependant, la création d'un certain nombre de secrets plus petits pourrait également épuiser la mémoire.

Les constructions qui utilisent la stratégie docker ou source-to-image (S2I) aboutissent à la création d'une nouvelle image de conteneur. L'image est ensuite poussée vers le registre d'images de conteneurs spécifié dans la section output de la spécification Build.

Si le type de sortie est ImageStreamTag, alors l'image sera poussée vers le registre d'images intégré d'OpenShift et étiquetée dans le flux d'images spécifié. Si la sortie est de type DockerImage, alors le nom de la référence de sortie sera utilisé comme spécification docker push. La spécification peut contenir un registre ou sera par défaut DockerHub si aucun registre n'est spécifié. Si la section output de la spécification de construction est vide, alors 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"

docker et la stratégie source-to-image (S2I) définissent les variables d'environnement suivantes sur les images de sortie :

De plus, toute variable d'environnement définie par l'utilisateur, par exemple celles configurées avec les options S2I] ou docker strategy, fera également partie de la liste des variables d'environnement de l'image de sortie.

docker et les constructions source-to-image (S2I)` définissent les étiquettes suivantes sur les images de sortie :

Vous pouvez également 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"

OpenShift Container Platform utilise Buildah pour construire une image de conteneur à partir d'un fichier Docker. Pour plus d'informations sur la construction d'images de conteneurs avec des Dockerfiles, voir la documentation de référence Dockerfile.

strategy:
  dockerStrategy:
    from:
      kind: "ImageStreamTag"
      name: "debian:latest"

strategy:
  dockerStrategy:
    from:
      kind: "ImageStreamTag"
      name: "debian:latest"

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

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

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

dockerStrategy:
...
  buildArgs:
    - name: "foo"
      value: "bar"

dockerStrategy:
...
  buildArgs:
    - name: "foo"
      value: "bar"

Source-to-image (S2I) est un outil permettant de créer des images de conteneurs reproductibles. Il produit des images prêtes à l'emploi en injectant la source d'une application dans une image de conteneur et en assemblant une nouvelle image. La nouvelle image incorpore l'image de base, le constructeur et la source construite et est prête à être utilisée avec la commande buildah run. S2I prend en charge les constructions incrémentielles, qui réutilisent les dépendances téléchargées précédemment, les artefacts construits précédemment, etc.

#!/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

#!/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

#!/bin/bash

run the application
/opt/application/run.sh

#!/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

#!/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

#!/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 personnalisée permet aux développeurs de définir une image de constructeur spécifique responsable de l'ensemble du processus de construction. L'utilisation de votre propre image de constructeur vous permet de personnaliser votre processus de construction.

Une image de construction personnalisée est une image conteneur simple incorporant la logique du processus de construction, par exemple pour construire des RPM ou des images de base.

Les builds personnalisés sont exécutés avec un niveau de privilège élevé et ne sont pas accessibles aux utilisateurs par défaut. Seuls les utilisateurs à qui l'on peut faire confiance en leur accordant des autorisations d'administration de cluster doivent avoir accès à l'exécution des builds personnalisés.

La stratégie de construction Pipeline permet aux développeurs de définir un pipeline Jenkins qui sera utilisé par le plugin Jenkins pipeline. Le build peut être démarré, surveillé et géré par OpenShift Container Platform de la même manière que n'importe quel autre type de build.

Les flux de travail du pipeline sont définis dans un site jenkinsfile, soit directement intégré dans la configuration de construction, soit fourni dans un dépôt Git et référencé 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 

Vous pouvez ajouter un secret à votre configuration de construction afin qu'elle puisse accéder à un dépôt privé.

Vous pouvez activer l'extraction vers un registre privé en définissant le secret d'extraction et la poussée en définissant le secret de poussée dans la configuration de la construction.

Pour activer la poussée :

Vous devez créer l'image que vous souhaitez utiliser comme image de construction personnalisée.

Vous pouvez utiliser OpenShift Container Platform pour construire et pousser des images de constructeur personnalisées à utiliser dans une stratégie personnalisée.

Vous pouvez définir un objet BuildConfig qui utilise la stratégie personnalisée en conjonction avec votre image de constructeur personnalisé pour exécuter votre logique de construction personnalisée.

Vous pouvez lancer manuellement une nouvelle compilation à partir d'une configuration de compilation existante dans votre projet actuel.

oc start-build <buildconfig_name>

oc start-build <buildconfig_name>