2.3. Création d'intrants de construction

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.