CI/CD

Plate-forme de conteneurs OpenShift 4.12

Contient des informations sur les builds, les pipelines et GitOps pour OpenShift Container Platform

Red Hat OpenShift Documentation Team

Résumé

CI/CD pour la plateforme de conteneurs OpenShift

Chapitre 1. Présentation de la plateforme OpenShift Container Platform CI/CD

OpenShift Container Platform est une plateforme Kubernetes prête à l'emploi pour les développeurs, qui permet aux organisations d'automatiser le processus de livraison d'applications grâce aux pratiques DevOps, telles que l'intégration continue (CI) et la livraison continue (CD). Pour répondre aux besoins de votre organisation, OpenShift Container Platform propose les solutions CI/CD suivantes :

  • Builds OpenShift
  • OpenShift Pipelines
  • OpenShift GitOps

1.1. Builds OpenShift

Avec OpenShift Builds, vous pouvez créer des applications cloud-natives en utilisant un processus de construction déclaratif. Vous pouvez définir le processus de construction dans un fichier YAML que vous utilisez pour créer un objet BuildConfig. Cette définition inclut des attributs tels que les déclencheurs de construction, les paramètres d'entrée et le code source. Lors du déploiement, l'objet BuildConfig construit généralement une image exécutable et l'envoie dans un registre d'images de conteneurs.

OpenShift Builds fournit le support extensible suivant pour les stratégies de construction :

  • Construction Docker
  • Construction de la source à l'image (S2I)
  • Construction sur mesure

Pour plus d'informations, voir Comprendre les constructions d'images

1.2. OpenShift Pipelines

OpenShift Pipelines fournit un cadre CI/CD natif Kubernetes pour concevoir et exécuter chaque étape du pipeline CI/CD dans son propre conteneur. Il peut évoluer de manière indépendante pour répondre aux pipelines à la demande avec des résultats prévisibles.

Pour plus d'informations, voir Comprendre les pipelines OpenShift

1.3. OpenShift GitOps

OpenShift GitOps est un opérateur qui utilise Argo CD comme moteur déclaratif de GitOps. Il permet de mettre en place des flux de travail GitOps sur des infrastructures OpenShift et Kubernetes multicluster. En utilisant OpenShift GitOps, les administrateurs peuvent configurer et déployer de manière cohérente l'infrastructure et les applications basées sur Kubernetes à travers les clusters et les cycles de développement.

Pour plus d'informations, voir Comprendre OpenShift GitOps

1.4. Jenkins

Jenkins automatise le processus de construction, de test et de déploiement des applications et des projets. OpenShift Developer Tools fournit une image Jenkins qui s'intègre directement à OpenShift Container Platform. Jenkins peut être déployé sur OpenShift en utilisant les modèles Samples Operator ou la carte certifiée Helm.

Chapitre 2. Constructions

2.1. Comprendre les constructions d'images

2.1.1. Constructions

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 :

  • Construction Docker
  • Construction de la source à l'image (S2I)
  • Construction sur mesure

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 :

  • Intégration continue
  • Déploiement continu

2.1.1.1. Construction Docker

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.

Astuce

Si vous définissez les arguments de construction de Docker en utilisant le tableau buildArgs, voir Comprendre comment ARG et FROM interagissent dans la documentation de référence de Dockerfile.

2.1.1.2. Construction de la source à l'image

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.

2.1.1.3. Construction sur mesure

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.

2.1.1.4. Construction d'un pipeline

Important

La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.

Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile dans un travail ou le stocker dans un système de gestion du contrôle de la source.

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.

2.2. Comprendre les configurations de construction

Les sections suivantes définissent le concept de compilation, la configuration de la compilation et décrivent les principales stratégies de compilation disponibles.

2.2.1. BuildConfigs

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

BuildConfig définition de l'objet

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

1
Cette spécification crée un nouveau site BuildConfig nommé ruby-sample-build.
2
Le champ runPolicy indique si les constructions créées à partir de cette configuration de construction peuvent être exécutées simultanément. La valeur par défaut est Serial, ce qui signifie que les nouvelles constructions sont exécutées séquentiellement et non simultanément.
3
Vous pouvez spécifier une liste de déclencheurs qui entraînent la création d'une nouvelle version.
4
La section source définit la source de la construction. Le type de source détermine la source primaire d'entrée, et peut être soit Git, pour pointer vers un dépôt de code, Dockerfile, pour construire à partir d'un fichier Docker en ligne, ou Binary, pour accepter des charges utiles binaires. Il est possible d'avoir plusieurs sources à la fois. Voir la documentation de chaque type de source pour plus de détails.
5
La section strategy décrit la stratégie de construction utilisée pour exécuter la construction. Vous pouvez spécifier une stratégie Source, Docker, ou Custom ici. Cet exemple utilise l'image du conteneur ruby-20-centos7 que Source-to-image (S2I) utilise pour la construction de l'application.
6
Une fois que l'image du conteneur est construite avec succès, elle est poussée dans le référentiel décrit dans la section output.
7
La section postCommit définit un crochet de construction optionnel.

2.3. Création d'intrants de construction

Les sections suivantes présentent une vue d'ensemble des entrées de compilation, des instructions sur la manière d'utiliser les entrées pour fournir du contenu source aux compilations, et sur la manière d'utiliser les environnements de compilation et de créer des secrets.

2.3.1. Construire des intrants

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

  • Définitions de fichiers Docker en ligne
  • Contenu extrait d'images existantes
  • Dépôts Git
  • Entrées binaires (locales)
  • Secrets d'entrée
  • Artéfacts externes

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 :

  1. Un répertoire de travail est construit et tout le contenu d'entrée est placé dans le répertoire de travail. Par exemple, le dépôt Git d'entrée est cloné dans le répertoire de travail, et les fichiers spécifiés dans les images d'entrée sont copiés dans le répertoire de travail en utilisant le chemin cible.
  2. Le processus de construction change les répertoires en contextDir, s'il y en a un de défini.
  3. Le fichier Docker en ligne, s'il existe, est écrit dans le répertoire courant.
  4. Le contenu du répertoire actuel est fourni au processus de construction pour référence par le fichier Docker, la logique de construction personnalisée ou le script assemble. Cela signifie que tout contenu d'entrée qui réside en dehors de contextDir est ignoré par le processus de construction.

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 1
    ref: "master"
  images:
  - from:
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths:
    - destinationDir: app/dir/injected/dir 2
      sourcePath: /usr/lib/somefile.jar
  contextDir: "app/dir" 3
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 4
1
Le référentiel à cloner dans le répertoire de travail pour la construction.
2
/usr/lib/somefile.jar de myinputimage est stockée dans <workingdir>/app/dir/injected/dir.
3
Le répertoire de travail pour la construction devient <original_workingdir>/app/dir.
4
Un fichier Docker contenant ce contenu est créé à l'adresse <original_workingdir>/app/dir, remplaçant tout fichier existant portant ce nom.

2.3.2. Source du fichier Docker

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" 1
1
Le champ dockerfile contient un fichier Docker en ligne qui est construit.

Ressources complémentaires

  • L'utilisation typique de ce champ est de fournir un Dockerfile à une stratégie de construction de docker.

2.3.3. Source de l'image

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: 1
  - from: 2
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths: 3
    - destinationDir: injected/dir 4
      sourcePath: /usr/lib/somefile.jar 5
  - from:
      kind: ImageStreamTag
      name: myotherinputimage:latest
      namespace: myothernamespace
    pullSecret: mysecret 6
    paths:
    - destinationDir: injected/dir
      sourcePath: /usr/lib/somefile.jar
1
Un tableau contenant une ou plusieurs images et fichiers d'entrée.
2
Une référence à l'image contenant les fichiers à copier.
3
Un tableau de chemins source/destination.
4
Le répertoire relatif à la racine de construction où le processus de construction peut accéder au fichier.
5
Emplacement du fichier à copier à partir de l'image référencée.
6
Un secret facultatif fourni si des informations d'identification sont nécessaires pour accéder à l'image d'entrée.
Note

Si votre cluster utilise un objet ImageContentSourcePolicy pour configurer la mise en miroir du référentiel, vous ne pouvez utiliser que des secrets d'extraction globaux pour les registres mis en miroir. Vous ne pouvez pas ajouter un secret d'extraction à un projet.

Images nécessitant des secrets de tirage

Lorsque vous utilisez une image d'entrée qui nécessite un secret d'extraction, vous pouvez lier le secret d'extraction au compte de service utilisé par la compilation. Par défaut, les builds utilisent le compte de service builder. Le secret d'extraction est automatiquement ajouté à la compilation si le secret contient un identifiant qui correspond au référentiel hébergeant l'image d'entrée. Pour lier un secret d'extraction au compte de service utilisé par la compilation, exécutez :

$ oc secrets link builder dockerhub
Note

Cette fonctionnalité n'est pas prise en charge pour les constructions utilisant la stratégie personnalisée.

Images sur des registres en miroir nécessitant des secrets d'extraction

Lorsque vous utilisez une image d'entrée provenant d'un registre en miroir, si vous obtenez un message build error: failed to pull image, vous pouvez résoudre l'erreur en utilisant l'une des méthodes suivantes :

  • Créez un secret d'entrée contenant les informations d'authentification pour le référentiel de l'image du constructeur et tous les miroirs connus. Dans ce cas, créez un secret d'extraction pour les informations d'identification du registre d'images et de ses miroirs.
  • Utiliser le secret d'entrée comme secret de sortie sur l'objet BuildConfig.

2.3.4. Source Git

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: 1
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir" 2
  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 3
1
Le champ git contient l'URI du dépôt Git distant du code source. En option, le champ ref permet d'extraire une référence Git spécifique. Un champ ref valide peut être une balise SHA1 ou un nom de branche.
2
Le champ contextDir vous permet de remplacer l'emplacement par défaut dans le référentiel du code source où la compilation recherche le code source de l'application. Si votre application existe dans un sous-répertoire, vous pouvez remplacer l'emplacement par défaut (le dossier racine) à l'aide de ce champ.
3
Si le champ facultatif dockerfile est fourni, il doit s'agir d'une chaîne contenant un Dockerfile qui écrase tout Dockerfile existant dans le référentiel source.

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

Avertissement

Les opérations de clonage de Git qui passent par un proxy qui effectue un détournement TLS ou un recryptage de la connexion proxy par l'homme du milieu (MITM) ne fonctionnent pas.

2.3.4.1. Utilisation d'un proxy

Si votre dépôt Git n'est accessible qu'à l'aide d'un proxy, vous pouvez définir le proxy à utiliser dans la section source de la configuration de construction. Vous pouvez configurer un proxy HTTP et HTTPS à utiliser. Les deux champs sont facultatifs. Les domaines pour lesquels aucun proxy ne doit être utilisé peuvent également être spécifiés dans le champ NoProxy.

Note

Votre URI source doit utiliser le protocole HTTP ou HTTPS pour que cela fonctionne.

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
Note

Pour les constructions de la stratégie Pipeline, étant donné les restrictions actuelles du plugin Git pour Jenkins, toutes les opérations Git via le plugin Git n'utilisent pas le proxy HTTP ou HTTPS défini dans le site BuildConfig. Le plugin Git utilise uniquement le proxy configuré dans l'interface utilisateur de Jenkins, dans le panneau Plugin Manager. Ce proxy est ensuite utilisé pour toutes les interactions Git dans Jenkins, pour tous les travaux.

Ressources complémentaires

  • Vous trouverez des instructions sur la manière de configurer les proxys via l'interface utilisateur de Jenkins à l'adresse JenkinsBehindProxy.

2.3.4.2. Source Clone Secrets

Les modules de construction ont besoin d'accéder à tous les dépôts Git définis comme source pour une construction. Les secrets de clone de source sont utilisés pour fournir au pod constructeur un accès auquel il n'aurait normalement pas accès, comme les dépôts privés ou les dépôts avec des certificats SSL auto-signés ou non fiables.

Les configurations suivantes de clone secret de source sont prises en charge :

  • fichier .gitconfig
  • Authentification de base
  • Authentification par clé SSH
  • Autorités de certification de confiance
Note

Vous pouvez également utiliser des combinaisons de ces configurations pour répondre à vos besoins spécifiques.

2.3.4.2.1. Ajout automatique d'un secret de clone de source à une configuration de construction

Lorsqu'un BuildConfig est créé, OpenShift Container Platform peut automatiquement remplir sa référence de secret de clone source. Ce comportement permet aux builds résultants d'utiliser automatiquement les informations d'identification stockées dans le secret référencé pour s'authentifier auprès d'un dépôt Git distant, sans nécessiter de configuration supplémentaire.

Pour utiliser cette fonctionnalité, un secret contenant les informations d'identification du dépôt Git doit exister dans l'espace de noms dans lequel le site BuildConfig est créé ultérieurement. Ce secret doit inclure une ou plusieurs annotations préfixées par build.openshift.io/source-secret-match-uri-. La valeur de chacune de ces annotations est un modèle d'identifiant de ressource uniforme (URI), défini comme suit. Lorsqu'un BuildConfig est créé sans référence à un secret de clone source et que son URI de source Git correspond à un modèle d'URI dans une annotation de secret, OpenShift Container Platform insère automatiquement une référence à ce secret dans le BuildConfig.

Conditions préalables

Un modèle d'URI doit être composé de

  • Un système valide : *://, git://, http://, https:// ou ssh://
  • Un hôte : *` ou un nom d'hôte ou une adresse IP valide précédé(e) éventuellement de *.
  • Un chemin d'accès : /* ou / suivi de caractères quelconques comprenant éventuellement des caractères *

Dans tous les cas ci-dessus, le caractère * est interprété comme un joker.

Important

Les modèles d'URI doivent correspondre aux URI de la source Git, qui sont conformes à la norme RFC3986. Ne pas inclure de nom d'utilisateur (ou de mot de passe) dans un modèle d'URI.

Par exemple, si vous utilisez ssh://git@bitbucket.atlassian.com:7999/ATLASSIAN jira.git pour l'URL d'un dépôt git, le secret de la source doit être spécifié comme ssh://bitbucket.atlassian.com:7999/* (et non ssh://git@bitbucket.atlassian.com:7999/*).

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

Procédure

Si plusieurs secrets correspondent à l'URI Git d'une BuildConfig particulière, OpenShift Container Platform sélectionne le secret dont la correspondance est la plus longue. Cela permet une surcharge de base, comme dans l'exemple suivant.

Le fragment suivant montre deux secrets de clone source partiels, le premier correspondant à tout serveur du domaine mycorp.com accédé par HTTPS, et le second surpassant l'accès aux serveurs mydev1.mycorp.com et mydev2.mycorp.com:

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:
  ...
  • Ajouter une annotation build.openshift.io/source-secret-match-uri- à un secret préexistant en utilisant :

    $ oc annotate secret mysecret \
        'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'
2.3.4.2.2. Ajout manuel d'un secret de clone source

Les secrets de clone de source peuvent être ajoutés manuellement à une configuration de compilation en ajoutant un champ sourceSecret à la section source à l'intérieur de BuildConfig et en lui attribuant le nom du secret que vous avez créé. Dans cet exemple, il s'agit de basicsecret.

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"

Procédure

Vous pouvez également utiliser la commande oc set build-secret pour définir le secret du clone source sur une configuration de construction existante.

  • Pour définir le secret du clone source sur une configuration de compilation existante, entrez la commande suivante :

    $ oc set build-secret --source bc/sample-build basicsecret
2.3.4.2.3. Création d'un secret à partir d'un fichier .gitconfig

Si le clonage de votre application dépend d'un fichier .gitconfig, vous pouvez créer un secret qui le contient. Ajoutez-le au compte de service builder, puis à votre fichier BuildConfig.

Procédure

  • Pour créer un secret à partir d'un fichier .gitconfig:
$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>
Note

La vérification SSL peut être désactivée si sslVerify=false est défini pour la section http dans votre fichier .gitconfig:

[http]
        sslVerify=false
2.3.4.2.4. Création d'un secret à partir d'un fichier .gitconfig pour Git sécurisé

Si votre serveur Git est sécurisé par un protocole SSL bidirectionnel et un nom d'utilisateur avec mot de passe, vous devez ajouter les fichiers de certificats à votre compilation de sources et ajouter des références aux fichiers de certificats dans le fichier .gitconfig.

Conditions préalables

  • Vous devez avoir des informations d'identification Git.

Procédure

Ajoutez les fichiers de certificats à votre version source et ajoutez des références aux fichiers de certificats dans le fichier .gitconfig.

  1. Ajoutez les fichiers client.crt, cacert.crt, et client.key au dossier /var/run/secrets/openshift.io/source/ dans le code source de l'application.
  2. Dans le fichier .gitconfig du serveur, ajoutez la section [http] comme indiqué dans l'exemple suivant :

    # cat .gitconfig

    Exemple de sortie

    [user]
            name = <name>
            email = <email>
    [http]
            sslVerify = false
            sslCert = /var/run/secrets/openshift.io/source/client.crt
            sslKey = /var/run/secrets/openshift.io/source/client.key
            sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crt

  3. Créer le secret :

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \ 1
    --from-literal=password=<password> \ 2
    --from-file=.gitconfig=.gitconfig \
    --from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \
    --from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \
    --from-file=client.key=/var/run/secrets/openshift.io/source/client.key
    1
    Le nom d'utilisateur Git de l'utilisateur.
    2
    Le mot de passe de cet utilisateur.
Important

Pour éviter d'avoir à saisir à nouveau votre mot de passe, veillez à spécifier l'image source-image (S2I) dans vos constructions. Cependant, si vous ne pouvez pas cloner le référentiel, vous devez toujours spécifier votre nom d'utilisateur et votre mot de passe pour promouvoir la compilation.

Ressources complémentaires

  • /var/run/secrets/openshift.io/source/ dans le code source de l'application.
2.3.4.2.5. Création d'un secret à partir du code source authentification de base

L'authentification de base nécessite soit une combinaison de --username et --password, soit un jeton pour s'authentifier auprès du serveur de gestion de la configuration logicielle (SCM).

Conditions préalables

  • Nom d'utilisateur et mot de passe pour accéder au référentiel privé.

Procédure

  1. Créez d'abord le secret avant d'utiliser les adresses --username et --password pour accéder au dépôt privé :

    $ oc create secret generic <secret_name> \
        --from-literal=username=<user_name> \
        --from-literal=password=<password> \
        --type=kubernetes.io/basic-auth
  2. Créer un secret d'authentification de base avec un jeton :

    $ oc create secret generic <secret_name> \
        --from-literal=password=<token> \
        --type=kubernetes.io/basic-auth
2.3.4.2.6. Création d'un secret à partir du code source Authentification par clé SSH

L'authentification basée sur une clé SSH nécessite une clé SSH privée.

Les clés du référentiel sont généralement situées dans le répertoire $HOME/.ssh/ et sont nommées par défaut id_dsa.pub, id_ecdsa.pub, id_ed25519.pub ou id_rsa.pub.

Procédure

  1. Générer les informations d'identification de la clé SSH :

    $ ssh-keygen -t ed25519 -C "your_email@example.com"
    Note

    La création d'une phrase de passe pour la clé SSH empêche OpenShift Container Platform de se construire. Lorsque vous êtes invité à saisir une phrase de passe, laissez-la vide.

    Deux fichiers sont créés : la clé publique et la clé privée correspondante (l'une des clés suivantes : id_dsa, id_ecdsa, id_ed25519 ou id_rsa). Une fois ces deux fichiers en place, consultez le manuel de votre système de gestion du contrôle des sources (SCM) pour savoir comment télécharger la clé publique. La clé privée est utilisée pour accéder à votre dépôt privé.

  2. Avant d'utiliser la clé SSH pour accéder au référentiel privé, créez le secret :

    $ oc create secret generic <secret_name> \
        --from-file=ssh-privatekey=<path/to/ssh/private/key> \
        --from-file=<path/to/known_hosts> \ 1
        --type=kubernetes.io/ssh-auth
    1
    Facultatif : L'ajout de ce champ permet une vérification stricte de la clé d'hôte du serveur.
    Avertissement

    Le fait d'ignorer le fichier known_hosts lors de la création du secret rend la construction vulnérable à une attaque potentielle de type "man-in-the-middle" (MITM).

    Note

    Assurez-vous que le fichier known_hosts contient une entrée pour l'hôte de votre code source.

2.3.4.2.7. Création d'un secret à partir d'un code source autorités de certification de confiance

L'ensemble des autorités de certification (CA) Transport Layer Security (TLS) qui sont approuvées lors d'une opération de clonage Git sont intégrées dans les images d'infrastructure OpenShift Container Platform. Si votre serveur Git utilise un certificat auto-signé ou signé par une autorité non approuvée par l'image, vous pouvez créer un secret qui contient le certificat ou désactiver la vérification TLS.

Si vous créez un secret pour le certificat CA, OpenShift Container Platform l'utilise pour accéder à votre serveur Git pendant l'opération de clonage Git. L'utilisation de cette méthode est nettement plus sûre que la désactivation de la vérification SSL de Git, qui accepte tout certificat TLS présenté.

Procédure

Créer un secret avec un fichier de certificat CA.

  1. Si votre autorité de certification utilise des autorités de certification intermédiaires, combinez les certificats de toutes les autorités de certification dans un fichier ca.crt. Entrez la commande suivante :

    cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt
    1. Créer le secret :

      oc create secret generic mycert --from-file=ca.crt=</path/to/file> $ oc create secret generic mycert --from-file=ca.crt=</path/to/file> 1
      1
      Vous devez utiliser le nom de clé ca.crt.
2.3.4.2.8. Combinaisons secrètes de la source

Vous pouvez combiner les différentes méthodes de création de clones secrets de sources pour répondre à vos besoins spécifiques.

2.3.4.2.8.1. Création d'un secret d'authentification basé sur SSH avec un fichier .gitconfig

Vous pouvez combiner les différentes méthodes de création de secrets de clone source pour répondre à vos besoins spécifiques, par exemple un secret d'authentification basé sur SSH avec un fichier .gitconfig.

Conditions préalables

  • Authentification SSH
  • fichier .gitconfig

Procédure

  • Pour créer un secret d'authentification basé sur SSH avec un fichier .gitconfig, exécutez :

    $ oc create secret generic <secret_name> \
        --from-file=ssh-privatekey=<path/to/ssh/private/key> \
        --from-file=<path/to/.gitconfig> \
        --type=kubernetes.io/ssh-auth
2.3.4.2.8.2. Création d'un secret combinant un fichier .gitconfig et un certificat CA

Vous pouvez combiner les différentes méthodes de création de secrets de clone source pour répondre à vos besoins spécifiques, par exemple un secret combinant un fichier .gitconfig et un certificat d'autorité de certification (CA).

Conditions préalables

  • fichier .gitconfig
  • Certificat CA

Procédure

  • Pour créer un secret combinant un fichier .gitconfig et un certificat d'autorité de certification, exécutez la commande suivante :

    $ oc create secret generic <secret_name> \
        --from-file=ca.crt=<path/to/certificate> \
        --from-file=<path/to/.gitconfig>
2.3.4.2.8.3. Création d'un secret d'authentification de base avec un certificat d'autorité de certification

Vous pouvez combiner les différentes méthodes de création de secrets de clone source pour répondre à vos besoins spécifiques, par exemple un secret combinant une authentification de base et un certificat d'autorité de certification (CA).

Conditions préalables

  • Données d'authentification de base
  • Certificat CA

Procédure

  • Créer un secret d'authentification de base avec un certificat CA, exécuter :

    $ oc create secret generic <secret_name> \
        --from-literal=username=<user_name> \
        --from-literal=password=<password> \
        --from-file=ca-cert=</path/to/file> \
        --type=kubernetes.io/basic-auth
2.3.4.2.8.4. Création d'un secret d'authentification de base avec un fichier .gitconfig

Vous pouvez combiner les différentes méthodes de création de secrets de clone source pour répondre à vos besoins spécifiques, par exemple un secret combinant une authentification de base et un fichier .gitconfig.

Conditions préalables

  • Données d'authentification de base
  • .gitconfig fichier

Procédure

  • Pour créer un secret d'authentification de base avec un fichier .gitconfig, exécutez :

    $ oc create secret generic <secret_name> \
        --from-literal=username=<user_name> \
        --from-literal=password=<password> \
        --from-file=</path/to/.gitconfig> \
        --type=kubernetes.io/basic-auth
2.3.4.2.8.5. Création d'un secret d'authentification de base avec un fichier .gitconfig et un certificat CA

Vous pouvez combiner les différentes méthodes de création de secrets de clone source pour répondre à vos besoins spécifiques, par exemple un secret combinant une authentification de base, un fichier .gitconfig et un certificat d'autorité de certification (CA).

Conditions préalables

  • Données d'authentification de base
  • .gitconfig fichier
  • Certificat CA

Procédure

  • Pour créer un secret d'authentification de base avec un fichier .gitconfig et un certificat CA, exécutez :

    $ oc create secret generic <secret_name> \
        --from-literal=username=<user_name> \
        --from-literal=password=<password> \
        --from-file=</path/to/.gitconfig> \
        --from-file=ca-cert=</path/to/file> \
        --type=kubernetes.io/basic-auth

2.3.5. Source binaire (locale)

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.

Note

Les constructions de type binaire nécessitent que le contenu soit diffusé à partir du système de fichiers local. Il n'est donc pas possible de déclencher automatiquement une construction de type binaire, comme on le ferait avec un déclencheur de changement d'image. En effet, les fichiers binaires ne peuvent pas être fournis. De même, vous ne pouvez pas lancer de builds de type binaire à partir de la console web.

Pour utiliser les constructions binaires, invoquez oc start-build avec l'une de ces options :

  • --from-file: Le contenu du fichier que vous spécifiez est envoyé sous forme de flux binaire au constructeur. Vous pouvez également spécifier l'URL d'un fichier. Ensuite, le constructeur stocke les données dans un fichier portant le même nom en haut du contexte de construction.
  • --from-dir et --from-repo: Le contenu est archivé et envoyé sous forme de flux binaire au constructeur. Ensuite, le constructeur extrait le contenu de l'archive dans le répertoire du contexte de construction. Avec --from-dir, vous pouvez également spécifier l'URL d'une archive qui sera extraite.
  • --from-archive: L'archive que vous spécifiez est envoyée au constructeur, où elle est extraite dans le répertoire du contexte de construction. Cette option se comporte de la même manière que --from-dir; une archive est créée sur votre hôte en premier, lorsque l'argument de ces options est un répertoire.

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

  • Si votre BuildConfig a déjà un type de source Binary défini, il est effectivement ignoré et remplacé par ce que le client envoie.
  • Si votre BuildConfig a un type de source Git défini, il est dynamiquement désactivé, puisque Binary et Git s'excluent mutuellement et que les données du flux binaire fourni au constructeur sont prioritaires.

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.

2.3.6. Secrets d'entrée et cartes de configuration

Important

Pour éviter que le contenu des secrets d'entrée et des cartes de configuration n'apparaisse dans les images de conteneurs de sortie de la construction, utilisez des volumes de construction dans vos stratégies de construction Docker et de construction source-image.

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 :

  1. Un fichier settings.xml configuré avec l'URL du miroir et les paramètres de connexion.
  2. Une clé privée référencée dans le fichier de configuration, telle que ~/.ssh/id_rsa.

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.

2.3.6.1. Qu'est-ce qu'un secret ?

Le type d'objet Secret fournit un mécanisme pour contenir des informations sensibles telles que les mots de passe, les fichiers de configuration du client OpenShift Container Platform, les fichiers dockercfg, les informations d'identification du référentiel source privé, etc. Les secrets découplent le contenu sensible des pods. Vous pouvez monter des secrets dans des conteneurs à l'aide d'un plugin de volume ou le système peut utiliser des secrets pour effectuer des actions au nom d'un pod.

Définition de l'objet secret YAML

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

1
Indique la structure des noms et des valeurs des clés du secret.
2
Le format autorisé pour les clés du champ data doit respecter les directives de la valeur DNS_SUBDOMAIN dans le glossaire des identifiants Kubernetes.
3
La valeur associée aux clés de la carte data doit être encodée en base64.
4
Les entrées de la carte stringData sont converties en base64 et sont ensuite déplacées automatiquement vers la carte data. Ce champ est en écriture seule. La valeur n'est renvoyée que par le champ data.
5
La valeur associée aux clés de la carte stringData est constituée de chaînes de texte en clair.
2.3.6.1.1. Propriétés des secrets

Les principales propriétés sont les suivantes

  • Les données secrètes peuvent être référencées indépendamment de leur définition.
  • Les volumes de données secrètes sont sauvegardés par des installations de stockage de fichiers temporaires (tmpfs) et ne s'arrêtent jamais sur un nœud.
  • Les données secrètes peuvent être partagées au sein d'un espace de noms.
2.3.6.1.2. Types de secrets

La valeur du champ type indique la structure des noms et des valeurs des clés du secret. Le type peut être utilisé pour imposer la présence de noms d'utilisateur et de clés dans l'objet secret. Si vous ne souhaitez pas de validation, utilisez le type opaque, qui est le type par défaut.

Indiquez l'un des types suivants pour déclencher une validation minimale côté serveur afin de garantir la présence de noms de clés spécifiques dans les données secrètes :

  • kubernetes.io/service-account-token. Utilise un jeton de compte de service.
  • kubernetes.io/dockercfg. Utilise le fichier .dockercfg pour les informations d'identification Docker requises.
  • kubernetes.io/dockerconfigjson. Utilise le fichier .docker/config.json pour les informations d'identification Docker requises.
  • kubernetes.io/basic-auth. A utiliser avec l'authentification de base.
  • kubernetes.io/ssh-auth. A utiliser avec l'authentification par clé SSH.
  • kubernetes.io/tls. A utiliser avec les autorités de certification TLS.

Indiquez type= Opaque si vous ne souhaitez pas de validation, ce qui signifie que le secret ne prétend pas se conformer à une convention pour les noms de clés ou les valeurs. Un secret opaque permet d'utiliser des paires key:value non structurées pouvant contenir des valeurs arbitraires.

Note

Vous pouvez spécifier d'autres types arbitraires, tels que example.com/my-secret-type. Ces types ne sont pas appliqués côté serveur, mais ils indiquent que le créateur du secret avait l'intention de se conformer aux exigences clé/valeur de ce type.

2.3.6.1.3. Mises à jour des secrets

Lorsque vous modifiez la valeur d'un secret, la valeur utilisée par un module déjà en cours d'exécution ne change pas dynamiquement. Pour modifier un secret, vous devez supprimer le module original et en créer un nouveau, dans certains cas avec un PodSpec identique.

La mise à jour d'un secret suit le même processus que le déploiement d'une nouvelle image de conteneur. Vous pouvez utiliser la commande kubectl rolling-update.

La valeur resourceVersion d'un secret n'est pas spécifiée lorsqu'il est référencé. Par conséquent, si un secret est mis à jour au moment où les modules démarrent, la version du secret utilisée pour le module n'est pas définie.

Note

Actuellement, il n'est pas possible de vérifier la version de la ressource d'un objet secret qui a été utilisée lors de la création d'un pod. Il est prévu que les modules communiquent cette information, de sorte qu'un contrôleur puisse redémarrer ceux qui utilisent un ancien resourceVersion. Dans l'intervalle, ne mettez pas à jour les données des secrets existants, mais créez-en de nouveaux avec des noms distincts.

2.3.6.2. Créer des secrets

Vous devez créer un secret avant de créer les modules qui dépendent de ce secret.

Lors de la création de secrets :

  • Créer un objet secret avec des données secrètes.
  • Mettre à jour le compte de service pod pour autoriser la référence au secret.
  • Créer un pod, qui consomme le secret en tant que variable d'environnement ou en tant que fichier à l'aide d'un volume secret.

Procédure

  • La commande create permet de créer un objet secret à partir d'un fichier JSON ou YAML :

    $ oc create -f <filename>

    Par exemple, vous pouvez créer un secret à partir de votre fichier local .docker/config.json:

    $ oc create secret generic dockerhub \
        --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
        --type=kubernetes.io/dockerconfigjson

    Cette commande génère une spécification JSON du secret nommé dockerhub et crée l'objet.

    Définition de l'objet secret opaque YAML

    apiVersion: v1
    kind: Secret
    metadata:
      name: mysecret
    type: Opaque 1
    data:
      username: dXNlci1uYW1l
      password: cGFzc3dvcmQ=

    1
    Spécifie un secret opaque.

    Fichier JSON de configuration Docker Définition de l'objet secret

    apiVersion: v1
    kind: Secret
    metadata:
      name: aregistrykey
      namespace: myapps
    type: kubernetes.io/dockerconfigjson 1
    data:
      .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 2

    1
    Spécifie que le secret utilise un fichier JSON de configuration de docker.
    2
    La sortie d'un fichier JSON de configuration de docker encodé en base64

2.3.6.3. Utiliser les secrets

Après avoir créé des secrets, vous pouvez créer un pod pour référencer votre secret, obtenir des journaux et supprimer le pod.

Procédure

  1. Créez le pod pour référencer votre secret :

    oc create -f <votre_fichier_yaml_>.yaml
  2. Obtenir les journaux :

    $ oc logs secret-example-pod
  3. Supprimer le pod :

    $ oc delete pod secret-example-pod

Ressources complémentaires

  • Exemples de fichiers YAML contenant des données secrètes :

    Secret YAML qui crée quatre fichiers

    apiVersion: v1
    kind: Secret
    metadata:
      name: test-secret
    data:
      username: dmFsdWUtMQ0K     1
      password: dmFsdWUtMQ0KDQo= 2
    stringData:
      hostname: myapp.mydomain.com 3
      secret.properties: |-     4
        property1=valueA
        property2=valueB

    1
    Le fichier contient des valeurs décodées.
    2
    Le fichier contient des valeurs décodées.
    3
    Le fichier contient la chaîne de caractères fournie.
    4
    Le fichier contient les données fournies.

    YAML d'un pod remplissant les fichiers d'un volume avec des données secrètes

    apiVersion: v1
    kind: Pod
    metadata:
      name: secret-example-pod
    spec:
      containers:
        - name: secret-test-container
          image: busybox
          command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
          volumeMounts:
              # name must match the volume name below
              - name: secret-volume
                mountPath: /etc/secret-volume
                readOnly: true
      volumes:
        - name: secret-volume
          secret:
            secretName: test-secret
      restartPolicy: Never

    YAML d'un pod remplissant les variables d'environnement avec des données secrètes

    apiVersion: v1
    kind: Pod
    metadata:
      name: secret-example-pod
    spec:
      containers:
        - name: secret-test-container
          image: busybox
          command: [ "/bin/sh", "-c", "export" ]
          env:
            - name: TEST_SECRET_USERNAME_ENV_VAR
              valueFrom:
                secretKeyRef:
                  name: test-secret
                  key: username
      restartPolicy: Never

    YAML d'une configuration de construction remplissant les variables d'environnement avec des données secrètes

    apiVersion: build.openshift.io/v1
    kind: BuildConfig
    metadata:
      name: secret-example-bc
    spec:
      strategy:
        sourceStrategy:
          env:
          - name: TEST_SECRET_USERNAME_ENV_VAR
            valueFrom:
              secretKeyRef:
                name: test-secret
                key: username

2.3.6.4. Ajout de secrets d'entrée et de cartes de configuration

Pour fournir des informations d'identification et d'autres données de configuration à une compilation sans les placer dans le contrôle du code source, vous pouvez définir des secrets d'entrée et des cartes de configuration d'entrée.

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. Pour rendre ces informations disponibles sans les placer dans le contrôle du code source, vous pouvez définir des secrets d'entrée et des cartes de configuration d'entrée.

Procédure

Pour ajouter un secret d'entrée, des cartes de configuration ou les deux à un objet BuildConfig existant :

  1. Créer l'objet ConfigMap, s'il n'existe pas :

    $ oc create configmap settings-mvn \
        --from-file=settings.xml=<path/to/settings.xml>

    Cela crée une nouvelle carte de configuration nommée settings-mvn, qui contient le contenu en texte brut du fichier settings.xml.

    Astuce

    Vous pouvez également appliquer le YAML suivant pour créer la carte de configuration :

    apiVersion: core/v1
    kind: ConfigMap
    metadata:
      name: settings-mvn
    data:
      settings.xml: |
        <settings>
        … # Insert maven settings here
        </settings>
  2. Créer l'objet Secret, s'il n'existe pas :

    $ oc create secret generic secret-mvn \
        --from-file=ssh-privatekey=<path/to/.ssh/id_rsa>
        --type=kubernetes.io/ssh-auth

    Cela crée un nouveau secret nommé secret-mvn, qui contient le contenu encodé en base64 de la clé privée id_rsa.

    Astuce

    Vous pouvez également appliquer le langage YAML suivant pour créer le secret d'entrée :

    apiVersion: core/v1
    kind: Secret
    metadata:
      name: secret-mvn
    type: kubernetes.io/ssh-auth
    data:
      ssh-privatekey: |
        # Insert ssh private key, base64 encoded
  3. Ajoutez la carte de configuration et le secret à la section source de l'objet BuildConfig existant :

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

Pour inclure le secret et la carte de configuration dans un nouvel objet BuildConfig, exécutez la commande suivante :

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

Pendant la construction, les fichiers settings.xml et id_rsa sont copiés dans le répertoire où se trouve le code source. Dans les images du constructeur S2I d'OpenShift Container Platform, il s'agit du répertoire de travail de l'image, qui est défini à l'aide de l'instruction WORKDIR dans le fichier Dockerfile. Si vous souhaitez spécifier un autre répertoire, ajoutez un destinationDir à la définition :

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"

Vous pouvez également spécifier le répertoire de destination lors de la création d'un nouvel objet BuildConfig:

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

Dans les deux cas, le fichier settings.xml est ajouté au répertoire ./.m2 de l'environnement de construction et la clé id_rsa est ajoutée au répertoire ./.ssh.

2.3.6.5. Stratégie de la source à l'image

Lors de l'utilisation d'une stratégie Source, tous les secrets d'entrée définis sont copiés dans leur destinationDir respectif. Si vous avez laissé destinationDir vide, les secrets sont placés dans le répertoire de travail de l'image du constructeur.

La même règle est utilisée lorsque destinationDir est un chemin relatif. Les secrets sont placés dans les chemins relatifs au répertoire de travail de l'image. Le dernier répertoire du chemin destinationDir est créé s'il n'existe pas dans l'image du constructeur. Tous les répertoires précédents dans le chemin destinationDir doivent exister, sinon une erreur se produit.

Note

Les secrets d'entrée sont ajoutés comme étant inscriptibles dans le monde, ont les permissions 0666 et sont tronqués à la taille zéro après l'exécution du script assemble. Cela signifie que les fichiers secrets existent dans l'image résultante, mais qu'ils sont vides pour des raisons de sécurité.

Les cartes de configuration en entrée ne sont pas tronquées après la fin du script assemble.

2.3.6.6. Stratégie Docker

Lorsque vous utilisez une stratégie Docker, vous pouvez ajouter tous les secrets d'entrée définis dans votre image de conteneur en utilisant les instructions ADD et COPY dans votre fichier Docker.

Si vous ne spécifiez pas destinationDir pour un secret, les fichiers sont copiés dans le même répertoire que celui où se trouve le fichier Docker. Si vous spécifiez un chemin relatif comme destinationDir, alors les secrets sont copiés dans ce répertoire, par rapport à l'emplacement de votre Dockerfile. Cela rend les fichiers secrets disponibles pour l'opération de construction de Docker en tant que partie du répertoire de contexte utilisé pendant la construction.

Exemple de fichier Docker référençant les données des cartes secrètes et de configuration

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

Important

Les utilisateurs suppriment normalement leurs secrets d'entrée de l'image de l'application finale afin que les secrets ne soient pas présents dans le conteneur fonctionnant à partir de cette image. Cependant, les secrets existent toujours dans l'image elle-même, dans la couche où ils ont été ajoutés. Cette suppression fait partie du fichier Docker lui-même.

Pour éviter que le contenu des secrets d'entrée et des cartes de configuration n'apparaisse dans les images du conteneur de sortie de la construction et éviter ce processus de suppression, utilisez plutôt des volumes de construction dans votre stratégie de construction Docker.

2.3.6.7. Stratégie personnalisée

Lors de l'utilisation d'une stratégie personnalisée, tous les secrets d'entrée et les cartes de configuration définis sont disponibles dans le conteneur du constructeur, dans le répertoire /var/run/secrets/openshift.io/build. L'image de compilation personnalisée doit utiliser ces secrets et ces cartes de configuration de manière appropriée. Avec la stratégie personnalisée, vous pouvez définir des secrets comme décrit dans les options de la stratégie personnalisée.

Il n'y a pas de différence technique entre les secrets de stratégie existants et les secrets d'entrée. Cependant, votre image de constructeur peut les distinguer et les utiliser différemment, en fonction du cas d'utilisation de votre construction.

Les secrets d'entrée sont toujours montés dans le répertoire /var/run/secrets/openshift.io/build, ou votre constructeur peut analyser la variable d'environnement $BUILD, qui inclut l'objet de construction complet.

Important

Si un secret d'extraction pour le registre existe à la fois dans l'espace de noms et dans le nœud, les constructions utilisent par défaut le secret d'extraction de l'espace de noms.

2.3.7. Artéfacts externes

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:

.s2i/bin/assemble Fichier

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

.s2i/bin/run Fichier

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

Extrait de Dockerfile

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 :

  • Utilisation du fichier .s2i/environment ] (uniquement pour une stratégie de construction de source)
  • Mise en place BuildConfig
  • Fournir explicitement en utilisant oc start-build --env (uniquement pour les constructions qui sont déclenchées manuellement)

2.3.8. Utilisation des identifiants Docker pour les registres privés

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.

Note

Pour le registre d'images de conteneurs d'OpenShift Container Platform, cela n'est pas nécessaire car les secrets sont générés automatiquement pour vous par OpenShift Container Platform.

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/: 1
    auth: "YWRfbGzhcGU6R2labnRib21ifTE=" 2
    email: "user@example.com" 3
  docker.io/my-namespace/my-user/my-image: 4
    auth: "GzhYWRGU6R2fbclabnRgbkSp=""
    email: "user@example.com"
  docker.io/my-namespace: 5
    auth: "GzhYWRGU6R2deesfrRgbkSp=""
    email: "user@example.com"
1
URL du registre.
2
Mot de passe crypté.
3
Adresse électronique pour la connexion.
4
URL et informations d'identification pour une image spécifique dans un espace de noms.
5
URL et informations d'identification pour un espace de noms du registre.

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.

Conditions préalables

  • Vous devez disposer d'un fichier .docker/config.json.

Procédure

  1. Créez le secret à partir de votre fichier local .docker/config.json:

    $ oc create secret generic dockerhub \
        --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
        --type=kubernetes.io/dockerconfigjson

    Cette opération génère une spécification JSON du secret nommé dockerhub et crée l'objet.

  2. Ajoutez un champ pushSecret dans la section output de BuildConfig et attribuez-lui le nom du secret que vous avez créé, c'est-à-dire dockerhub dans l'exemple précédent :

    spec:
      output:
        to:
          kind: "DockerImage"
          name: "private.registry.com/org/private-image:latest"
        pushSecret:
          name: "dockerhub"

    Vous pouvez utiliser la commande oc set build-secret pour définir le secret de poussée sur la configuration de construction :

    $ oc set build-secret --push bc/sample-build dockerhub

    Vous pouvez également lier le secret push au compte de service utilisé par le build au lieu de spécifier le champ pushSecret. Par défaut, les builds utilisent le compte de service builder. Le secret de poussée est automatiquement ajouté à la compilation si le secret contient un identifiant qui correspond au référentiel hébergeant l'image de sortie de la compilation.

    $ oc secrets link builder dockerhub
  3. Tirer l'image du conteneur constructeur d'un registre privé d'images de conteneurs en spécifiant le champ pullSecret, qui fait partie de la définition de la stratégie de construction :

    strategy:
      sourceStrategy:
        from:
          kind: "DockerImage"
          name: "docker.io/user/private_repository"
        pullSecret:
          name: "dockerhub"

    Vous pouvez utiliser la commande oc set build-secret pour définir le secret d'extraction sur la configuration de construction :

    $ oc set build-secret --pull bc/sample-build dockerhub
    Note

    Cet exemple utilise pullSecret dans une version Source, mais il est également applicable dans les versions Docker et Custom.

    Vous pouvez également lier le secret d'extraction au compte de service utilisé par la compilation au lieu de spécifier le champ pullSecret. Par défaut, les builds utilisent le compte de service builder. Le secret d'extraction est automatiquement ajouté à la compilation si le secret contient un identifiant qui correspond au référentiel hébergeant l'image d'entrée de la compilation. Pour lier le secret d'extraction au compte de service utilisé par la compilation au lieu de spécifier le champ pullSecret, exécutez :

    $ oc secrets link builder dockerhub
    Note

    Vous devez spécifier une image from dans la spécification BuildConfig pour bénéficier de cette fonctionnalité. Les constructions de stratégie Docker générées par oc new-build ou oc new-app peuvent ne pas le faire dans certaines situations.

2.3.9. Construire des environnements

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.

Note

Le référencement des ressources du conteneur à l'aide de valueFrom dans les variables d'environnement de construction n'est pas pris en charge, car les références sont résolues avant la création du conteneur.

2.3.9.1. Utiliser les champs de compilation comme variables d'environnement

Vous pouvez injecter des informations sur l'objet de construction en définissant la variable d'environnement fieldPath source à l'adresse JsonPath du champ dont vous souhaitez obtenir la valeur.

Note

La stratégie Jenkins Pipeline ne prend pas en charge la syntaxe valueFrom pour les variables d'environnement.

Procédure

  • Définissez la source de la variable d'environnement fieldPath à l'adresse JsonPath du champ dont vous souhaitez obtenir la valeur :

    env:
      - name: FIELDREF_ENV
        valueFrom:
          fieldRef:
            fieldPath: metadata.name

2.3.9.2. Utiliser des secrets comme variables d'environnement

Vous pouvez rendre les valeurs clés des secrets disponibles en tant que variables d'environnement à l'aide de la syntaxe valueFrom.

Important

Cette méthode affiche les secrets en texte brut dans la sortie de la console du pod de construction. Pour éviter cela, utilisez plutôt des secrets d'entrée et des cartes de configuration.

Procédure

  • Pour utiliser un secret comme variable d'environnement, définissez la syntaxe valueFrom:

    apiVersion: build.openshift.io/v1
    kind: BuildConfig
    metadata:
      name: secret-example-bc
    spec:
      strategy:
        sourceStrategy:
          env:
          - name: MYVAL
            valueFrom:
              secretKeyRef:
                key: myval
                name: mysecret

2.3.10. Service servant les secrets de certificat

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.

Procédure

Pour sécuriser la communication avec votre service, demandez au cluster de générer un couple certificat/clé de service signé dans un secret de votre espace de noms.

  • Définissez l'annotation service.beta.openshift.io/serving-cert-secret-name sur votre service avec la valeur fixée au nom que vous voulez utiliser pour votre secret.

    Ensuite, votre PodSpec peut monter ce secret. Lorsqu'il est disponible, votre pod s'exécute. Le certificat est bon pour le nom DNS du service interne, <service.name>.<service.namespace>.svc.

    Le certificat et la clé sont au format PEM et sont stockés respectivement dans tls.crt et tls.key. La paire certificat/clé est automatiquement remplacée lorsqu'elle est proche de l'expiration. La date d'expiration est indiquée dans l'annotation service.beta.openshift.io/expiry sur le secret, qui est au format RFC3339.

Note

Dans la plupart des cas, le nom DNS du service <service.name>.<service.namespace>.svc n'est pas routable de l'extérieur. L'utilisation principale de <service.name>.<service.namespace>.svc est pour la communication à l'intérieur d'un cluster ou d'un service, et avec des itinéraires de re-cryptage.

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

2.3.11. Restrictions en matière de secrets

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 :

  • Pour remplir les variables d'environnement des conteneurs.
  • En tant que fichiers dans un volume monté sur un ou plusieurs de ses conteneurs.
  • Par kubelet lors de l'extraction des images pour le pod.

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.

2.4. Gestion des résultats de la compilation

Les sections suivantes présentent une vue d'ensemble et des instructions pour la gestion des résultats de la compilation.

2.4.1. Production d'un bâtiment

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.

Sortie vers un ImageStreamTag

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

Sortie vers une spécification docker Push

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

2.4.2. Variables d'environnement de l'image de sortie

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

VariableDescription

OPENSHIFT_BUILD_NAME

Nom de la construction

OPENSHIFT_BUILD_NAMESPACE

Espace de noms de la construction

OPENSHIFT_BUILD_SOURCE

L'URL source de la construction

OPENSHIFT_BUILD_REFERENCE

La référence Git utilisée dans la construction

OPENSHIFT_BUILD_COMMIT

Source commit utilisé dans la construction

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.

2.4.3. Étiquettes de l'image de sortie

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

ÉtiquetteDescription

io.openshift.build.commit.author

Auteur du commit source utilisé dans le build

io.openshift.build.commit.date

Date du commit source utilisé dans le build

io.openshift.build.commit.id

Hash du commit source utilisé dans le build

io.openshift.build.commit.message

Message du commit source utilisé dans la construction

io.openshift.build.commit.ref

Branche ou référence spécifiée dans la source

io.openshift.build.source-location

URL source pour la construction

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.

Étiquettes personnalisées à appliquer aux images construites

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

2.5. Utiliser des stratégies de construction

Les sections suivantes définissent les principales stratégies de construction prises en charge et expliquent comment les utiliser.

2.5.1. Construction Docker

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.

Astuce

Si vous définissez les arguments de construction de Docker en utilisant le tableau buildArgs, voir Comprendre comment ARG et FROM interagissent dans la documentation de référence de Dockerfile.

2.5.1.1. Remplacer le fichier Dockerfile de l'image

Vous pouvez remplacer l'instruction FROM du fichier Docker par l'instruction from de l'objet BuildConfig. Si le fichier Docker utilise des constructions en plusieurs étapes, l'image de la dernière instruction FROM sera remplacée.

Procédure

Pour remplacer l'instruction FROM du fichier Docker par l'instruction from du fichier BuildConfig.

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

2.5.1.2. Utilisation du chemin d'accès au fichier Docker

Par défaut, les constructions Docker utilisent un Dockerfile situé à la racine du contexte spécifié dans le champ BuildConfig.spec.source.contextDir.

Le champ dockerfilePath permet au build d'utiliser un chemin différent pour localiser votre Dockerfile, par rapport au champ BuildConfig.spec.source.contextDir. Il peut s'agir d'un nom de fichier différent du Dockerfile par défaut, comme MyDockerfile, ou d'un chemin vers un Dockerfile dans un sous-répertoire, comme dockerfiles/app1/Dockerfile.

Procédure

Pour utiliser le champ dockerfilePath afin que le build utilise un chemin différent pour localiser votre Dockerfile, définissez :

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

2.5.1.3. Utiliser les variables d'environnement de Docker

Pour rendre les variables d'environnement disponibles au processus de construction de docker et à l'image résultante, vous pouvez ajouter des variables d'environnement à la définition dockerStrategy de la configuration de construction.

Les variables d'environnement qui y sont définies sont insérées sous la forme d'une seule instruction ENV Dockerfile juste après l'instruction FROM, de sorte qu'elles puissent être référencées ultérieurement dans le Dockerfile.

Procédure

Les variables sont définies lors de la construction et restent dans l'image de sortie, elles seront donc également présentes dans tout conteneur qui exécute cette image.

Par exemple, la définition d'un proxy HTTP personnalisé à utiliser lors de la construction et de l'exécution :

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

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

2.5.1.4. Ajouter des arguments de construction de docker

Vous pouvez définir les arguments de construction de docker en utilisant le tableau buildArgs. Les arguments de construction sont transmis à docker lorsqu'une construction est lancée.

Astuce

Voir Comprendre comment ARG et FROM interagissent dans la documentation de référence Dockerfile.

Procédure

Pour définir les arguments de construction de docker, ajoutez des entrées au tableau buildArgs, qui se trouve dans la définition dockerStrategy de l'objet BuildConfig. Par exemple :

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

Seuls les champs name et value sont pris en charge. Les paramètres du champ valueFrom sont ignorés.

2.5.1.5. La réduction des couches avec les constructions de dockers

Les constructions Docker créent normalement une couche représentant chaque instruction dans un Dockerfile. En définissant imageOptimizationPolicy sur SkipLayers, on fusionne toutes les instructions en une seule couche au-dessus de l'image de base.

Procédure

  • Réglez le site imageOptimizationPolicy sur SkipLayers:

    strategy:
      dockerStrategy:
        imageOptimizationPolicy: SkipLayers

2.5.1.6. Utilisation des volumes de construction

Vous pouvez monter des volumes de construction pour permettre aux constructions en cours d'accéder aux informations que vous ne souhaitez pas conserver dans l'image du conteneur de sortie.

Les volumes de construction fournissent des informations sensibles, telles que les références du référentiel, dont l'environnement de construction ou la configuration n'a besoin qu'au moment de la construction. Les volumes de construction sont différents des entrées de construction, dont les données peuvent persister dans l'image du conteneur de sortie.

Les points de montage des volumes de construction, à partir desquels la construction en cours lit les données, sont fonctionnellement similaires aux montages des volumes de pods.

Procédure

  • Dans la définition dockerStrategy de l'objet BuildConfig, ajoutez tous les volumes de construction au tableau volumes. Par exemple :

    spec:
      dockerStrategy:
        volumes:
          - name: secret-mvn 1
            mounts:
            - destinationPath: /opt/app-root/src/.ssh 2
            source:
              type: Secret 3
              secret:
                secretName: my-secret 4
          - name: settings-mvn 5
            mounts:
            - destinationPath: /opt/app-root/src/.m2  6
            source:
              type: ConfigMap 7
              configMap:
                name: my-config 8
          - name: my-csi-volume 9
            mounts:
            - destinationPath: /opt/app-root/src/some_path  10
            source:
              type: CSI 11
              csi:
                driver: csi.sharedresource.openshift.io 12
                readOnly: true 13
                volumeAttributes: 14
                  attribute: value
    1 5 9
    Obligatoire. Un nom unique.
    2 6 10
    Obligatoire. Le chemin absolu du point de montage. Il ne doit pas contenir .. ou : et ne doit pas entrer en conflit avec le chemin de destination généré par le constructeur. /opt/app-root/src est le répertoire d'accueil par défaut pour de nombreuses images Red Hat S2I.
    3 7 11
    Obligatoire. Le type de source, ConfigMap, Secret, ou CSI.
    4 8
    Obligatoire. Le nom de la source.
    12
    Nécessaire. Le pilote qui fournit le volume CSI éphémère.
    13
    Obligatoire. Cette valeur doit être définie sur true. Fournit un volume en lecture seule.
    14
    Facultatif. Les attributs de volume du volume CSI éphémère. Consultez la documentation du pilote CSI pour connaître les clés et les valeurs des attributs pris en charge.
Note

Le pilote CSI pour ressources partagées est pris en charge en tant que fonction d'aperçu technologique.

2.5.2. Construction de la source à l'image

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.

2.5.2.1. Effectuer des constructions incrémentielles de source à image

Source-to-image (S2I) peut effectuer des constructions incrémentielles, ce qui signifie qu'il réutilise les artefacts des images construites précédemment.

Procédure

  • Pour créer une construction incrémentielle, créez une stratégie avec la modification suivante de la définition de la stratégie :

    strategy:
      sourceStrategy:
        from:
          kind: "ImageStreamTag"
          name: "incremental-image:latest" 1
        incremental: true 2
    1
    Spécifiez une image qui prend en charge les constructions incrémentielles. Consultez la documentation de l'image du constructeur pour savoir si elle prend en charge ce comportement.
    2
    Cette option permet de contrôler si une construction incrémentale est tentée. Si l'image du constructeur ne prend pas en charge les constructions incrémentielles, la construction réussira quand même, mais vous obtiendrez un message indiquant que la construction incrémentielle n'a pas réussi à cause d'un script save-artifacts manquant.

Ressources complémentaires

  • Voir les exigences S2I pour des informations sur la façon de créer une image de constructeur prenant en charge les constructions incrémentielles.

2.5.2.2. Remplacer les scripts d'image du constructeur de sources par des scripts d'image du constructeur d'images

Vous pouvez remplacer les scripts source-image (S2I) assemble, run et save-artifacts fournis par l'image de construction.

Procédure

Pour remplacer les scripts S2I assemble, run, et save-artifacts fournis par l'image du constructeur, il faut soit :

  • Fournissez un script assemble, run ou save-artifacts dans le répertoire .s2i/bin du référentiel des sources de votre application.
  • Fournir l'URL d'un répertoire contenant les scripts dans le cadre de la définition de la stratégie. Par exemple :

    strategy:
      sourceStrategy:
        from:
          kind: "ImageStreamTag"
          name: "builder-image:latest"
        scripts: "http://somehost.com/scripts_directory" 1
    1
    Ce chemin sera complété par run, assemble, et save-artifacts. Si l'un ou tous les scripts sont trouvés, ils seront utilisés à la place des scripts du même nom fournis dans l'image.
Note

Les fichiers situés à l'URL scripts sont prioritaires sur les fichiers situés à l'URL .s2i/bin du référentiel source.

2.5.2.3. Variables d'environnement source-image

Il existe deux façons de mettre les variables d'environnement à la disposition du processus de compilation des sources et de l'image qui en résulte. Les fichiers d'environnement et les valeurs d'environnement BuildConfig. Les variables fournies seront présentes lors du processus de construction et dans l'image de sortie.

2.5.2.3.1. Utilisation de fichiers d'environnement source-image

Source build vous permet de définir des valeurs d'environnement, une par ligne, à l'intérieur de votre application, en les spécifiant dans un fichier .s2i/environment dans le dépôt de sources. Les variables d'environnement spécifiées dans ce fichier sont présentes pendant le processus de construction et dans l'image de sortie.

Si vous fournissez un fichier .s2i/environment dans votre dépôt de sources, source-to-image (S2I) lit ce fichier pendant la construction. Cela permet de personnaliser le comportement de la compilation, car le script assemble peut utiliser ces variables.

Procédure

Par exemple, pour désactiver la compilation des actifs pour votre application Rails pendant la construction :

  • Ajouter DISABLE_ASSET_COMPILATION=true dans le fichier .s2i/environment.

En plus des builds, les variables d'environnement spécifiées sont également disponibles dans l'application en cours d'exécution. Par exemple, pour que l'application Rails démarre en mode development au lieu de production:

  • Ajouter RAILS_ENV=development au fichier .s2i/environment.

La liste complète des variables d'environnement prises en charge est disponible dans la section "Utilisation des images" pour chaque image.

2.5.2.3.2. Utilisation de l'environnement de configuration de la construction source-image

Vous pouvez ajouter des variables d'environnement à la définition sourceStrategy de la configuration de construction. Les variables d'environnement définies à cet endroit sont visibles lors de l'exécution du script assemble et seront définies dans l'image de sortie, ce qui les rend également disponibles pour le script run et le code de l'application.

Procédure

  • Par exemple, pour désactiver la compilation des actifs pour votre application Rails :

    sourceStrategy:
    ...
      env:
        - name: "DISABLE_ASSET_COMPILATION"
          value: "true"

Ressources complémentaires

  • La section sur l'environnement de construction fournit des instructions plus avancées.
  • Vous pouvez également gérer les variables d'environnement définies dans la configuration de construction à l'aide de la commande oc set env.

2.5.2.4. Ignorer les fichiers source à image

Source-to-image (S2I) prend en charge un fichier .s2iignore, qui contient une liste de modèles de fichiers à ignorer. Les fichiers du répertoire de travail de la compilation, tels qu'ils sont fournis par les différentes sources d'entrée, qui correspondent à un modèle trouvé dans le fichier .s2iignore ne seront pas mis à la disposition du script assemble.

2.5.2.5. Créer des images à partir du code source avec source-to-image

Source-to-image (S2I) est un cadre qui facilite l'écriture d'images qui prennent le code source d'une application en entrée et produisent une nouvelle image qui exécute l'application assemblée en sortie.

Le principal avantage de l'utilisation de S2I pour la construction d'images de conteneurs reproductibles est la facilité d'utilisation pour les développeurs. En tant qu'auteur d'une image de construction, vous devez comprendre deux concepts de base pour que vos images offrent les meilleures performances S2I : le processus de construction et les scripts S2I.

2.5.2.5.1. Comprendre le processus de construction de la source à l'image

Le processus de construction se compose des trois éléments fondamentaux suivants, qui sont combinés pour former une image finale du conteneur :

  • Sources d'information
  • Scripts source-image (S2I)
  • Image du constructeur

S2I génère un Dockerfile avec l'image du constructeur comme première instruction FROM. Le fichier Docker généré par S2I est ensuite transmis à Buildah.

2.5.2.5.2. Comment écrire des scripts source-image ?

Vous pouvez écrire des scripts source-image (S2I) dans n'importe quel langage de programmation, à condition que les scripts soient exécutables dans l'image du constructeur. S2I prend en charge plusieurs options fournissant des scripts assemble/run/save-artifacts. Tous ces emplacements sont vérifiés lors de chaque compilation dans l'ordre suivant :

  1. Un script spécifié dans la configuration de la construction.
  2. Un script trouvé dans le répertoire source de l'application .s2i/bin.
  3. Un script trouvé à l'URL de l'image par défaut avec l'étiquette io.openshift.s2i.scripts-url.

L'étiquette io.openshift.s2i.scripts-url spécifiée dans l'image et le script spécifié dans une configuration de compilation peuvent prendre l'une des formes suivantes :

  • image:///path_to_scripts_dirchemin absolu à l'intérieur de l'image vers un répertoire où se trouvent les scripts S2I.
  • file:///path_to_scripts_dirchemin d'accès : chemin relatif ou absolu vers un répertoire de l'hôte où se trouvent les scripts S2I.
  • http(s)://path_to_scripts_dir: URL d'un répertoire où se trouvent les scripts S2I.

Tableau 2.1. Scénarios S2I

Le scénarioDescription

assemble

Le script assemble construit les artefacts de l'application à partir d'une source et les place dans les répertoires appropriés à l'intérieur de l'image. Ce script est obligatoire. Le flux de travail pour ce script est le suivant :

  1. Optionnel : Restaurer les artefacts de construction. Si vous souhaitez prendre en charge les constructions incrémentielles, veillez à définir également save-artifacts.
  2. Placez la source d'application à l'endroit souhaité.
  3. Construire les artefacts de l'application.
  4. Installer les artefacts dans des endroits appropriés pour qu'ils fonctionnent.

run

Le script run exécute votre application. Ce script est nécessaire.

save-artifacts

Le script save-artifacts rassemble toutes les dépendances qui peuvent accélérer les processus de construction qui suivent. Ce script est facultatif. Par exemple :

  • Pour Ruby, gems installé par Bundler.
  • Pour Java, .m2 contents.

Ces dépendances sont rassemblées dans un fichier tar et transmises à la sortie standard.

usage

Le script usage vous permet d'informer l'utilisateur sur la manière d'utiliser correctement votre image. Ce script est facultatif.

test/run

Le script test/run vous permet de créer un processus pour vérifier si l'image fonctionne correctement. Ce script est facultatif. Le flux proposé pour ce processus est le suivant

  1. Construire l'image.
  2. Exécutez l'image pour vérifier le script usage.
  3. Exécutez s2i build pour vérifier le script assemble.
  4. Facultatif : Exécutez à nouveau s2i build pour vérifier que les scripts save-artifacts et assemble sauvegardent et restaurent les artefacts.
  5. Exécutez l'image pour vérifier que l'application de test fonctionne.
Note

L'emplacement suggéré pour placer l'application de test construite par votre script test/run est le répertoire test/test-app de votre référentiel d'images.

Example S2I scripts

Les exemples de scripts S2I suivants sont écrits en Bash. Chaque exemple suppose que le contenu de tar est décompressé dans le répertoire /tmp/s2i.

assemble le scénario :

#!/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 le scénario :

#!/bin/bash

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

save-artifacts le scénario :

#!/bin/bash

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

usage le scénario :

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

Ressources complémentaires

2.5.2.6. Utilisation des volumes de construction

Vous pouvez monter des volumes de construction pour permettre aux constructions en cours d'accéder aux informations que vous ne souhaitez pas conserver dans l'image du conteneur de sortie.

Les volumes de construction fournissent des informations sensibles, telles que les références du référentiel, dont l'environnement de construction ou la configuration n'a besoin qu'au moment de la construction. Les volumes de construction sont différents des entrées de construction, dont les données peuvent persister dans l'image du conteneur de sortie.

Les points de montage des volumes de construction, à partir desquels la construction en cours lit les données, sont fonctionnellement similaires aux montages des volumes de pods.

Procédure

  • Dans la définition sourceStrategy de l'objet BuildConfig, ajoutez tous les volumes de construction au tableau volumes. Par exemple :

    spec:
      sourceStrategy:
        volumes:
          - name: secret-mvn 1
            mounts:
            - destinationPath: /opt/app-root/src/.ssh 2
            source:
              type: Secret 3
              secret:
                secretName: my-secret 4
          - name: settings-mvn 5
            mounts:
            - destinationPath: /opt/app-root/src/.m2 6
            source:
              type: ConfigMap 7
              configMap:
                name: my-config 8
          - name: my-csi-volume 9
            mounts:
            - destinationPath: /opt/app-root/src/some_path  10
            source:
              type: CSI 11
              csi:
                driver: csi.sharedresource.openshift.io 12
                readOnly: true 13
                volumeAttributes: 14
                  attribute: value
1 5 9
Obligatoire. Un nom unique.
2 6 10
Obligatoire. Le chemin absolu du point de montage. Il ne doit pas contenir .. ou : et ne doit pas entrer en conflit avec le chemin de destination généré par le constructeur. /opt/app-root/src est le répertoire d'accueil par défaut pour de nombreuses images Red Hat S2I.
3 7 11
Obligatoire. Le type de source, ConfigMap, Secret, ou CSI.
4 8
Obligatoire. Le nom de la source.
12
Nécessaire. Le pilote qui fournit le volume CSI éphémère.
13
Obligatoire. Cette valeur doit être définie sur true. Fournit un volume en lecture seule.
14
Facultatif. Les attributs de volume du volume CSI éphémère. Consultez la documentation du pilote CSI pour connaître les clés et les valeurs des attributs pris en charge.
Note

Le pilote CSI pour ressources partagées est pris en charge en tant que fonction d'aperçu technologique.

2.5.3. Construction sur mesure

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.

2.5.3.1. Utilisation de l'image FROM pour des constructions personnalisées

Vous pouvez utiliser la section customStrategy.from pour indiquer l'image à utiliser pour la construction personnalisée

Procédure

  • Définir la section customStrategy.from:

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

2.5.3.2. Utilisation des secrets dans les constructions personnalisées

Outre les secrets pour les sources et les images qui peuvent être ajoutés à tous les types de construction, les stratégies personnalisées permettent d'ajouter une liste arbitraire de secrets au module de construction.

Procédure

  • Pour monter chaque secret à un emplacement spécifique, modifiez les champs secretSource et mountPath du fichier YAML strategy:

    strategy:
      customStrategy:
        secrets:
          - secretSource: 1
              name: "secret1"
            mountPath: "/tmp/secret1" 2
          - secretSource:
              name: "secret2"
            mountPath: "/tmp/secret2"
    1
    secretSource est une référence à un secret dans le même espace de noms que la construction.
    2
    mountPath est le chemin d'accès à l'intérieur du constructeur personnalisé où le secret doit être monté.

2.5.3.3. Utilisation de variables d'environnement pour des constructions personnalisées

Pour mettre les variables d'environnement à la disposition du processus de compilation personnalisé, vous pouvez ajouter des variables d'environnement à la définition customStrategy de la configuration de compilation.

Les variables d'environnement qui y sont définies sont transmises au pod qui exécute la construction personnalisée.

Procédure

  1. Définir un proxy HTTP personnalisé à utiliser lors de la construction :

    customStrategy:
    ...
      env:
        - name: "HTTP_PROXY"
          value: "http://myproxy.net:5187/"
  2. Pour gérer les variables d'environnement définies dans la configuration de la compilation, entrez la commande suivante :

    oc set env <enter_variables> $ oc set env <enter_variables>

2.5.3.4. Utilisation des images personnalisées du constructeur

La stratégie de construction personnalisée d'OpenShift Container Platform vous permet de définir une image de construction spécifique responsable de l'ensemble du processus de construction. Lorsque vous avez besoin d'un build pour produire des artefacts individuels tels que des packages, des JAR, des WAR, des ZIP installables ou des images de base, utilisez une image de constructeur personnalisée à l'aide de la stratégie de build personnalisée.

Une image de construction personnalisée est une image de conteneur simple incorporant la logique du processus de construction, qui est utilisée pour construire des artefacts tels que des RPM ou des images de conteneur de base.

En outre, le constructeur personnalisé permet de mettre en œuvre n'importe quel processus de construction étendu, tel qu'un flux CI/CD qui exécute des tests unitaires ou d'intégration.

2.5.3.4.1. Image personnalisée du constructeur

Lors de son invocation, une image de constructeur personnalisé reçoit les variables d'environnement suivantes avec les informations nécessaires pour procéder à la construction :

Tableau 2.2. Variables d'environnement du Custom Builder

Nom de la variableDescription

BUILD

L'intégralité du JSON sérialisé de la définition de l'objet Build. Si vous devez utiliser une version spécifique de l'API pour la sérialisation, vous pouvez définir le paramètre buildAPIVersion dans la spécification de la stratégie personnalisée de la configuration de construction.

SOURCE_REPOSITORY

L'URL d'un dépôt Git contenant les sources à construire.

SOURCE_URI

Utilise la même valeur que SOURCE_REPOSITORY. L'un ou l'autre peut être utilisé.

SOURCE_CONTEXT_DIR

Spécifie le sous-répertoire du dépôt Git à utiliser lors de la construction. Uniquement présent s'il est défini.

SOURCE_REF

La référence Git à construire.

ORIGIN_VERSION

La version du master OpenShift Container Platform qui a créé cet objet de construction.

OUTPUT_REGISTRY

Le registre de l'image du conteneur dans lequel l'image doit être transférée.

OUTPUT_IMAGE

Le nom de l'étiquette de l'image du conteneur pour l'image en cours de construction.

PUSH_DOCKERCFG_PATH

Chemin d'accès aux informations d'identification du registre des conteneurs pour l'exécution d'une opération podman push.

2.5.3.4.2. Flux de travail des constructeurs personnalisés

Bien que les auteurs d'images de construction personnalisées aient une certaine flexibilité dans la définition du processus de construction, votre image de construction doit respecter les étapes suivantes nécessaires à l'exécution d'une construction au sein d'OpenShift Container Platform :

  1. La définition de l'objet Build contient toutes les informations nécessaires sur les paramètres d'entrée de la construction.
  2. Exécuter le processus de construction.
  3. Si votre compilation produit une image, poussez-la dans l'emplacement de sortie de la compilation s'il est défini. D'autres emplacements de sortie peuvent être passés avec des variables d'environnement.

2.5.4. Construction d'un pipeline

Important

La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.

Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile dans un travail ou le stocker dans un système de gestion du contrôle de la source.

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.

2.5.4.1. Comprendre les pipelines de la plateforme de conteneurs OpenShift

Important

La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.

Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile dans un travail ou le stocker dans un système de gestion du contrôle de la source.

Les pipelines vous permettent de contrôler la construction, le déploiement et la promotion de vos applications sur OpenShift Container Platform. En combinant la stratégie de construction Jenkins Pipeline, jenkinsfiles, et le langage spécifique au domaine OpenShift Container Platform (DSL) fourni par le plugin client Jenkins, vous pouvez créer des pipelines avancés de construction, de test, de déploiement et de promotion pour n'importe quel scénario.

OpenShift Container Platform Jenkins Sync Plugin

Le plugin Jenkins Sync d'OpenShift Container Platform maintient la configuration et les objets de construction synchronisés avec les travaux et les constructions Jenkins, et fournit les éléments suivants :

  • Création dynamique de tâches et d'exécutions dans Jenkins.
  • Création dynamique de modèles de pods d'agents à partir de flux d'images, de balises de flux d'images ou de cartes de configuration.
  • Injection de variables d'environnement.
  • Visualisation du pipeline dans la console web de OpenShift Container Platform.
  • Intégration avec le plugin Jenkins Git, qui transmet les informations de commit des builds d'OpenShift Container Platform au plugin Jenkins Git.
  • Synchronisation des secrets dans les entrées de justificatifs Jenkins.

OpenShift Container Platform Jenkins Client Plugin

Le plugin client Jenkins d'OpenShift Container Platform est un plugin Jenkins qui vise à fournir une syntaxe de pipeline Jenkins lisible, concise, complète et fluide pour des interactions riches avec un serveur API d'OpenShift Container Platform. Le plugin utilise l'outil de ligne de commande d'OpenShift Container Platform, oc, qui doit être disponible sur les nœuds exécutant le script.

Le plugin Jenkins Client doit être installé sur votre master Jenkins afin que le DSL OpenShift Container Platform soit disponible pour être utilisé dans le site jenkinsfile pour votre application. Ce plugin est installé et activé par défaut lors de l'utilisation de l'image Jenkins d'OpenShift Container Platform.

Pour les Pipelines OpenShift Container Platform dans votre projet, vous devez utiliser la stratégie de construction de Pipeline Jenkins. Cette stratégie utilise par défaut une adresse jenkinsfile à la racine de votre référentiel source, mais fournit également les options de configuration suivantes :

  • Un champ en ligne jenkinsfile dans votre configuration de construction.
  • Un champ jenkinsfilePath dans votre configuration de construction qui référence l'emplacement de jenkinsfile à utiliser par rapport à la source contextDir.
Note

Le champ facultatif jenkinsfilePath indique le nom du fichier à utiliser, par rapport à la source contextDir. Si contextDir est omis, la valeur par défaut est la racine du référentiel. Si jenkinsfilePath est omis, la valeur par défaut est jenkinsfile.

2.5.4.2. Fournir le fichier Jenkins pour les constructions de pipelines

Important

La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.

Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile dans un travail ou le stocker dans un système de gestion du contrôle de la source.

Le site jenkinsfile utilise la syntaxe standard du langage groovy pour permettre un contrôle précis de la configuration, de la construction et du déploiement de votre application.

Vous pouvez fournir le site jenkinsfile de l'une des manières suivantes :

  • Un fichier situé dans votre dépôt de code source.
  • Intégrée dans votre configuration de construction à l'aide du champ jenkinsfile.

Si vous utilisez la première option, le site jenkinsfile doit être inclus dans le dépôt du code source de vos applications à l'un des endroits suivants :

  • Un fichier nommé jenkinsfile à la racine de votre référentiel.
  • Un fichier nommé jenkinsfile à la racine de la source contextDir de votre référentiel.
  • Un nom de fichier spécifié via le champ jenkinsfilePath de la section JenkinsPipelineStrategy de votre BuildConfig, qui est relatif à la source contextDir si elle est fournie, sinon il prend par défaut la racine du référentiel.

Le site jenkinsfile est exécuté sur le pod d'agent Jenkins, qui doit disposer des binaires du client OpenShift Container Platform si vous avez l'intention d'utiliser le DSL OpenShift Container Platform.

Procédure

Pour fournir le fichier Jenkins, vous pouvez soit

  • Intégrer le fichier Jenkins dans la configuration de construction.
  • Inclure dans la configuration de construction une référence au dépôt Git qui contient le fichier Jenkins.

Définition de l'intégration

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')
        }

Référence au dépôt Git

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 1

1
Le champ facultatif jenkinsfilePath indique le nom du fichier à utiliser, par rapport à la source contextDir. Si contextDir est omis, la valeur par défaut est la racine du référentiel. Si jenkinsfilePath est omis, la valeur par défaut est jenkinsfile.

2.5.4.3. Utilisation de variables d'environnement pour la construction de pipelines

Important

La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.

Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile dans un travail ou le stocker dans un système de gestion du contrôle de la source.

Pour mettre les variables d'environnement à la disposition du processus de construction de Pipeline, vous pouvez ajouter des variables d'environnement à la définition jenkinsPipelineStrategy de la configuration de construction.

Une fois définies, les variables d'environnement seront définies comme paramètres pour tout travail Jenkins associé à la configuration de construction.

Procédure

  • Pour définir les variables d'environnement à utiliser lors de la construction, éditez le fichier YAML :

    jenkinsPipelineStrategy:
    ...
      env:
        - name: "FOO"
          value: "BAR"

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

2.5.4.3.1. Mapping entre les variables d'environnement BuildConfig et les paramètres des jobs Jenkins

Lorsqu'un travail Jenkins est créé ou mis à jour en fonction des modifications apportées à la configuration de construction d'une stratégie Pipeline, toutes les variables d'environnement de la configuration de construction sont mises en correspondance avec les définitions des paramètres du travail Jenkins, les valeurs par défaut des définitions des paramètres du travail Jenkins étant les valeurs actuelles des variables d'environnement associées.

Après la création initiale du job Jenkins, vous pouvez encore ajouter des paramètres supplémentaires au job à partir de la console Jenkins. Les noms des paramètres diffèrent des noms des variables d'environnement dans la configuration de la construction. Les paramètres sont pris en compte lors du lancement des builds pour ces travaux Jenkins.

La façon dont vous démarrez la construction d'une tâche Jenkins détermine la façon dont les paramètres sont définis.

  • Si vous démarrez avec oc start-build, les valeurs des variables d'environnement dans la configuration de construction sont les paramètres définis pour l'instance de travail correspondante. Toute modification apportée aux valeurs par défaut des paramètres à partir de la console Jenkins est ignorée. Les valeurs de la configuration de construction sont prioritaires.
  • Si vous commencez par oc start-build -e, les valeurs des variables d'environnement spécifiées dans l'option -e sont prioritaires.

    • Si vous spécifiez une variable d'environnement qui ne figure pas dans la configuration de la construction, elle sera ajoutée en tant que définition des paramètres du travail de Jenkins.
    • Toute modification apportée aux paramètres correspondant aux variables d'environnement à partir de la console Jenkins est ignorée. La configuration de construction et ce que vous spécifiez avec oc start-build -e sont prioritaires.
  • Si vous démarrez le travail Jenkins avec la console Jenkins, vous pouvez alors contrôler le réglage des paramètres avec la console Jenkins dans le cadre du lancement d'une compilation pour le travail.
Note

Il est recommandé de spécifier dans la configuration de la construction toutes les variables d'environnement possibles à associer aux paramètres du travail. Cela permet de réduire les entrées/sorties sur disque et d'améliorer les performances lors du traitement par Jenkins.

2.5.4.4. Tutoriel de construction d'un pipeline

Important

La stratégie de construction Pipeline est obsolète dans OpenShift Container Platform 4. Des fonctionnalités équivalentes et améliorées sont présentes dans les Pipelines d'OpenShift Container Platform basés sur Tekton.

Les images Jenkins sur OpenShift Container Platform sont entièrement prises en charge et les utilisateurs doivent suivre la documentation utilisateur de Jenkins pour définir leur jenkinsfile dans un travail ou le stocker dans un système de gestion du contrôle de la source.

Cet exemple montre comment créer un pipeline OpenShift Container Platform qui construira, déploiera et vérifiera une application Node.js/MongoDB en utilisant le modèle nodejs-mongodb.json.

Procédure

  1. Créer le master Jenkins :

      $ oc project <project_name>

    Sélectionnez le projet que vous souhaitez utiliser ou créez un nouveau projet à l'aide de oc new-project <project_name>.

      $ oc new-app jenkins-ephemeral 1

    Si vous souhaitez utiliser un stockage persistant, utilisez plutôt jenkins-persistent.

  2. Créez un fichier nommé nodejs-sample-pipeline.yaml avec le contenu suivant :

    Note

    Cela crée un objet BuildConfig qui utilise la stratégie du pipeline Jenkins pour construire, déployer et mettre à l'échelle l'application d'exemple Node.js/MongoDB.

    kind: "BuildConfig"
    apiVersion: "v1"
    metadata:
      name: "nodejs-sample-pipeline"
    spec:
      strategy:
        jenkinsPipelineStrategy:
          jenkinsfile: <pipeline content from below>
        type: JenkinsPipeline
  3. Après avoir créé un objet BuildConfig à l'aide d'un objet jenkinsPipelineStrategy, vous indiquez au pipeline ce qu'il doit faire à l'aide d'un objet inline jenkinsfile:

    Note

    Cet exemple ne met pas en place un dépôt Git pour l'application.

    Le contenu suivant jenkinsfile est écrit en Groovy en utilisant le DSL OpenShift Container Platform. Pour cet exemple, incluez du contenu en ligne dans l'objet BuildConfig en utilisant le style littéral YAML, bien que l'inclusion d'un jenkinsfile dans votre référentiel source soit la méthode préférée.

    def templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json' 1
    def templateName = 'nodejs-mongodb-example' 2
    pipeline {
      agent {
        node {
          label 'nodejs' 3
        }
      }
      options {
        timeout(time: 20, unit: 'MINUTES') 4
      }
      stages {
        stage('preamble') {
            steps {
                script {
                    openshift.withCluster() {
                        openshift.withProject() {
                            echo "Using project: ${openshift.project()}"
                        }
                    }
                }
            }
        }
        stage('cleanup') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      openshift.selector("all", [ template : templateName ]).delete() 5
                      if (openshift.selector("secrets", templateName).exists()) { 6
                        openshift.selector("secrets", templateName).delete()
                      }
                    }
                }
            }
          }
        }
        stage('create') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      openshift.newApp(templatePath) 7
                    }
                }
            }
          }
        }
        stage('build') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      def builds = openshift.selector("bc", templateName).related('builds')
                      timeout(5) { 8
                        builds.untilEach(1) {
                          return (it.object().status.phase == "Complete")
                        }
                      }
                    }
                }
            }
          }
        }
        stage('deploy') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      def rm = openshift.selector("dc", templateName).rollout()
                      timeout(5) { 9
                        openshift.selector("dc", templateName).related('pods').untilEach(1) {
                          return (it.object().status.phase == "Running")
                        }
                      }
                    }
                }
            }
          }
        }
        stage('tag') {
          steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                      openshift.tag("${templateName}:latest", "${templateName}-staging:latest") 10
                    }
                }
            }
          }
        }
      }
    }
    1
    Chemin du modèle à utiliser.
    1 2
    Nom du modèle qui sera créé.
    3
    Créer un pod d'agent node.js sur lequel exécuter ce build.
    4
    Définir un délai de 20 minutes pour ce pipeline.
    5
    Supprimer tout ce qui porte l'étiquette de ce modèle.
    6
    Supprimez tous les secrets portant cette étiquette de modèle.
    7
    Créez une nouvelle application à partir du site templatePath.
    8
    Attendez jusqu'à cinq minutes que la construction soit terminée.
    9
    Attendez jusqu'à cinq minutes que le déploiement soit terminé.
    10
    Si tout le reste a réussi, marquez l'image $ {templateName}:latest comme $ {templateName}-staging:latest. Une configuration de construction de pipeline pour l'environnement de mise à l'essai peut surveiller la modification de l'image $ {templateName}-staging:latest et la déployer ensuite dans l'environnement de mise à l'essai.
    Note

    L'exemple précédent a été écrit en utilisant le style de pipeline déclaratif, mais l'ancien style de pipeline scripté est également pris en charge.

  4. Créez le Pipeline BuildConfig dans votre cluster OpenShift Container Platform :

    $ oc create -f nodejs-sample-pipeline.yaml
    1. Si vous ne souhaitez pas créer votre propre fichier, vous pouvez utiliser l'exemple du référentiel Origin en exécutant :

      $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml
  5. Démarrer le pipeline :

    $ oc start-build nodejs-sample-pipeline
    Note

    Vous pouvez également démarrer votre pipeline avec la console web d'OpenShift Container Platform en naviguant vers la section Builds → Pipeline et en cliquant sur Start Pipeline, ou en visitant la console Jenkins, en naviguant vers le pipeline que vous avez créé et en cliquant sur Build Now.

    Une fois le pipeline lancé, vous devriez voir les actions suivantes se dérouler dans votre projet :

    • Une instance de travail est créée sur le serveur Jenkins.
    • Un module d'agent est lancé, si votre pipeline en nécessite un.
    • Le pipeline s'exécute sur le pod agent, ou sur le master si aucun agent n'est requis.

      • Toutes les ressources créées précédemment avec l'étiquette template=nodejs-mongodb-example seront supprimées.
      • Une nouvelle application et toutes ses ressources associées seront créées à partir du modèle nodejs-mongodb-example.
      • Une compilation sera lancée à l'aide de nodejs-mongodb-example BuildConfig .

        • Le pipeline attendra que la construction soit terminée pour déclencher l'étape suivante.
      • Un déploiement sera lancé à l'aide de la configuration de déploiement nodejs-mongodb-example.

        • Le pipeline attendra que le déploiement soit terminé pour déclencher l'étape suivante.
      • Si la construction et le déploiement sont réussis, l'image nodejs-mongodb-example:latest sera étiquetée comme nodejs-mongodb-example:stage.
    • Le pod de l'agent est supprimé, s'il était nécessaire pour le pipeline.

      Note

      La meilleure façon de visualiser l'exécution du pipeline est de l'afficher dans la console web d'OpenShift Container Platform. Vous pouvez visualiser vos pipelines en vous connectant à la console web et en naviguant vers Builds → Pipelines.

2.5.5. Ajouter des secrets avec la console web

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

Procédure

Pour ajouter un secret à votre configuration de construction afin qu'elle puisse accéder à un dépôt privé à partir de la console web d'OpenShift Container Platform :

  1. Créez un nouveau projet OpenShift Container Platform.
  2. Créez un secret contenant les informations d'identification permettant d'accéder à un dépôt de code source privé.
  3. Créer une configuration de construction.
  4. Sur la page de l'éditeur de configuration de la construction ou sur la page create app from builder image de la console web, définissez le paramètre Source Secret.
  5. Cliquez sur Save.

2.5.6. Permettre de tirer et de pousser

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.

Procédure

Pour permettre l'extraction vers un registre privé :

  • Définir le secret d'extraction dans la configuration de la construction.

Pour activer la poussée :

  • Définir le secret de poussée dans la configuration de la construction.

2.6. Constructions d'images personnalisées avec Buildah

Avec OpenShift Container Platform 4.12, un docker socket ne sera pas présent sur les nœuds hôtes. Cela signifie que l'option mount docker socket d'une construction personnalisée n'est pas garantie pour fournir un socket docker accessible pour une utilisation dans une image de construction personnalisée.

Si vous avez besoin de cette capacité pour construire et pousser des images, ajoutez l'outil Buildah à votre image de construction personnalisée et utilisez-le pour construire et pousser l'image dans votre logique de construction personnalisée. Voici un exemple d'exécution de constructions personnalisées à l'aide de Buildah.

Note

L'utilisation de la stratégie de construction personnalisée nécessite des autorisations que les utilisateurs normaux n'ont pas par défaut, car elle permet à l'utilisateur d'exécuter du code arbitraire à l'intérieur d'un conteneur privilégié fonctionnant sur le cluster. Ce niveau d'accès peut être utilisé pour compromettre le cluster et ne doit donc être accordé qu'à des utilisateurs disposant de privilèges administratifs sur le cluster.

2.6.1. Conditions préalables

2.6.2. Création d'artefacts de construction personnalisés

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

Procédure

  1. En partant d'un répertoire vide, créez un fichier nommé Dockerfile avec le contenu suivant :

    FROM registry.redhat.io/rhel8/buildah
    # In this example, `/tmp/build` contains the inputs that build when this
    # custom builder image is run. Normally the custom builder image fetches
    # this content from some location at build time, by using git clone as an example.
    ADD dockerfile.sample /tmp/input/Dockerfile
    ADD build.sh /usr/bin
    RUN chmod a+x /usr/bin/build.sh
    # /usr/bin/build.sh contains the actual custom build logic that will be run when
    # this custom builder image is run.
    ENTRYPOINT ["/usr/bin/build.sh"]
  2. Dans le même répertoire, créez un fichier nommé dockerfile.sample. Ce fichier est inclus dans l'image de construction personnalisée et définit l'image produite par la construction personnalisée :

    FROM registry.access.redhat.com/ubi8/ubi
    RUN touch /tmp/build
  3. Dans le même répertoire, créez un fichier nommé build.sh. Ce fichier contient la logique qui est exécutée lors de l'exécution de la version personnalisée :

    #!/bin/sh
    # Note that in this case the build inputs are part of the custom builder image, but normally this
    # is retrieved from an external source.
    cd /tmp/input
    # OUTPUT_REGISTRY and OUTPUT_IMAGE are env variables provided by the custom
    # build framework
    TAG="${OUTPUT_REGISTRY}/${OUTPUT_IMAGE}"
    
    
    # performs the build of the new image defined by dockerfile.sample
    buildah --storage-driver vfs bud --isolation chroot -t ${TAG} .
    
    
    # buildah requires a slight modification to the push secret provided by the service
    # account to use it for pushing the image
    cp /var/run/secrets/openshift.io/push/.dockercfg /tmp
    (echo "{ \"auths\": " ; cat /var/run/secrets/openshift.io/push/.dockercfg ; echo "}") > /tmp/.dockercfg
    
    
    # push the new image to the target for the build
    buildah --storage-driver vfs push --tls-verify=false --authfile /tmp/.dockercfg ${TAG}

2.6.3. Construire une image personnalisée du constructeur

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

Conditions préalables

  • Définissez toutes les données qui seront utilisées pour créer votre nouvelle image de constructeur personnalisé.

Procédure

  1. Définissez un objet BuildConfig qui construira votre image de constructeur personnalisée :

    $ oc new-build --binary --strategy=docker --name custom-builder-image
  2. Depuis le répertoire dans lequel vous avez créé votre image de compilation personnalisée, exécutez la compilation :

    $ oc start-build custom-builder-image --from-dir . -F

    Une fois la construction terminée, votre nouvelle image de constructeur personnalisé est disponible dans votre projet dans une balise de flux d'images nommée custom-builder-image:latest.

2.6.4. Utiliser l'image personnalisée du constructeur

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.

Conditions préalables

  • Définir toutes les entrées requises pour la nouvelle image du constructeur personnalisé.
  • Créez votre image de constructeur personnalisée.

Procédure

  1. Créez un fichier nommé buildconfig.yaml. Ce fichier définit l'objet BuildConfig qui est créé dans votre projet et exécuté :

    kind: BuildConfig
    apiVersion: build.openshift.io/v1
    metadata:
      name: sample-custom-build
      labels:
        name: sample-custom-build
      annotations:
        template.alpha.openshift.io/wait-for-ready: 'true'
    spec:
      strategy:
        type: Custom
        customStrategy:
          forcePull: true
          from:
            kind: ImageStreamTag
            name: custom-builder-image:latest
            namespace: <yourproject> 1
      output:
        to:
          kind: ImageStreamTag
          name: sample-custom:latest
    1
    Indiquez le nom de votre projet.
  2. Créer le site BuildConfig:

    $ oc create -f buildconfig.yaml
  3. Créez un fichier nommé imagestream.yaml. Ce fichier définit le flux d'images vers lequel la compilation poussera l'image :

    kind: ImageStream
    apiVersion: image.openshift.io/v1
    metadata:
      name: sample-custom
    spec: {}
  4. Créer le flux d'images :

    $ oc create -f imagestream.yaml
  5. Exécutez votre construction personnalisée :

    $ oc start-build sample-custom-build -F

    Lorsque la construction s'exécute, elle lance un pod qui exécute l'image du constructeur personnalisé qui a été construite précédemment. Le pod exécute la logique build.sh qui est définie comme le point d'entrée de l'image du constructeur personnalisé. La logique build.sh invoque Buildah pour construire le site dockerfile.sample qui a été intégré dans l'image de construction personnalisée, puis utilise Buildah pour pousser la nouvelle image vers le site sample-custom image stream.

2.7. Effectuer et configurer des constructions de base

Les sections suivantes fournissent des instructions pour les opérations de construction de base, y compris le démarrage et l'annulation des constructions, l'édition de BuildConfigs, la suppression de BuildConfigs, l'affichage des détails de la construction et l'accès aux journaux de construction.

2.7.1. Démarrer une construction

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

Procédure

Pour lancer manuellement une compilation, entrez la commande suivante :

oc start-build <buildconfig_name>

2.7.1.1. Réexécution d'une compilation

Vous pouvez relancer manuellement une compilation en utilisant l'option --from-build.

Procédure

  • Pour réexécuter manuellement une compilation, entrez la commande suivante :

    oc start-build --from-build=<nom_de_la_construction>

2.7.1.2. Journaux de construction en continu

Vous pouvez spécifier l'option --follow pour que les journaux de la compilation soient transmis à stdout.

Procédure

  • Pour diffuser manuellement les journaux d'une compilation dans stdout, entrez la commande suivante :

    oc start-build <buildconfig_name> --follow

2.7.1.3. Définition de variables d'environnement lors du lancement d'une compilation

Vous pouvez spécifier l'option --env pour définir toute variable d'environnement souhaitée pour la construction.

Procédure

  • Pour spécifier une variable d'environnement souhaitée, entrez la commande suivante :

    $ oc start-build <buildconfig_name> --env=<key>=<value>

2.7.1.4. Démarrer une compilation avec les sources

Plutôt que de s'appuyer sur une extraction de source Git ou un fichier Docker pour une construction, vous pouvez également démarrer une construction en poussant directement votre source, qui peut être le contenu d'un répertoire de travail Git ou SVN, un ensemble d'artefacts binaires préconstruits que vous souhaitez déployer, ou un simple fichier. Ceci peut être fait en spécifiant l'une des options suivantes pour la commande start-build:

OptionDescription

--from-dir=<directory>

Spécifie un répertoire qui sera archivé et utilisé comme entrée binaire pour la construction.

--from-file=<file>

Spécifie un fichier unique qui sera le seul fichier dans la source de construction. Le fichier est placé à la racine d'un répertoire vide avec le même nom de fichier que le fichier original fourni.

--from-repo=<local_source_repo>

Spécifie un chemin vers un dépôt local à utiliser comme entrée binaire pour une compilation. Ajoutez l'option --commit pour contrôler quelle branche, balise ou commit est utilisé pour la compilation.

Si vous passez l'une de ces options directement à la compilation, le contenu est transmis à la compilation et remplace les paramètres actuels de la source de la compilation.

Note

Les reconstructions déclenchées par une entrée binaire ne préserveront pas la source sur le serveur, de sorte que les reconstructions déclenchées par des modifications de l'image de base utiliseront la source spécifiée dans la configuration de la construction.

Procédure

  • Lancez une compilation à partir d'une source en utilisant la commande suivante pour envoyer le contenu d'un dépôt Git local sous forme d'archive à partir de la balise v2:

    $ oc start-build hello-world --from-repo=../hello-world --commit=v2

2.7.2. Annulation d'une construction

Vous pouvez annuler une construction à l'aide de la console web ou de la commande CLI suivante.

Procédure

  • Pour annuler manuellement une construction, entrez la commande suivante :

    oc cancel-build <build_name>

2.7.2.1. Annulation de plusieurs constructions

Vous pouvez annuler plusieurs constructions à l'aide de la commande CLI suivante.

Procédure

  • Pour annuler manuellement plusieurs constructions, entrez la commande suivante :

    oc cancel-build <build1_name> <build2_name> <build3_name> $ oc cancel-build <build1_name> <build2_name>

2.7.2.2. Annulation de toutes les constructions

Vous pouvez annuler toutes les constructions à partir de la configuration de la construction avec la commande CLI suivante.

Procédure

  • Pour annuler toutes les constructions, entrez la commande suivante :

    oc cancel-build bc/<buildconfig_name>

2.7.2.3. Annulation de toutes les constructions dans un état donné

Vous pouvez annuler toutes les constructions dans un état donné, tel que new ou pending, tout en ignorant les constructions dans d'autres états.

Procédure

  • Pour annuler tout ce qui se trouve dans un état donné, entrez la commande suivante :

    oc cancel-build bc/<buildconfig_name>

2.7.3. Modifier une BuildConfig

Pour modifier vos configurations de construction, vous utilisez l'option Edit BuildConfig dans la vue Builds de la perspective Developer.

Vous pouvez utiliser l'une des vues suivantes pour modifier un site BuildConfig:

  • Le site Form view vous permet de modifier votre site BuildConfig à l'aide des champs de formulaire et des cases à cocher standard.
  • Le site YAML view vous permet d'éditer votre site BuildConfig avec un contrôle total sur les opérations.

Vous pouvez passer de Form view à YAML view sans perdre de données. Les données contenues dans le site Form view sont transférées vers le site YAML view et vice versa.

Procédure

  1. Dans la vue Builds de la perspective Developer, cliquez sur le menu kebab pour voir l'option Edit BuildConfig.
  2. Cliquez sur Edit BuildConfig pour voir l'option Form view.
  3. Dans la section Git, entrez l'URL du dépôt Git pour la base de code que vous souhaitez utiliser pour créer une application. L'URL est ensuite validée.

    • Optionnel : Cliquez sur Show Advanced Git Options pour ajouter des détails tels que

      • Git Reference pour spécifier une branche, une balise ou un commit qui contient le code que vous voulez utiliser pour construire l'application.
      • Context Dir pour spécifier le sous-répertoire qui contient le code que vous voulez utiliser pour construire l'application.
      • Source Secret pour créer un site Secret Name avec des informations d'identification permettant d'extraire votre code source d'un dépôt privé.
  4. Dans la section Build from, sélectionnez l'option à partir de laquelle vous souhaitez construire. Vous pouvez utiliser les options suivantes :

    • Image Stream tag référence une image pour un flux d'images et une balise donnés. Saisissez le projet, le flux d'images et la balise de l'emplacement à partir duquel vous souhaitez construire et pousser.
    • Image Stream image référence une image pour un flux d'images et un nom d'image donnés. Saisissez l'image du flux d'images à partir duquel vous souhaitez construire. Saisissez également le projet, le flux d'images et la balise à utiliser.
    • Docker image: L'image Docker est référencée par le biais d'un dépôt d'images Docker. Vous devrez également entrer le projet, le flux d'image et le tag pour faire référence à l'endroit où vous souhaitez pousser.
  5. Facultatif : dans la section Environment Variables, ajoutez les variables d'environnement associées au projet en utilisant les champs Name et Value. Pour ajouter d'autres variables d'environnement, utilisez Add Value, ou Add from ConfigMap et Secret.
  6. Facultatif : Pour personnaliser davantage votre application, utilisez les options avancées suivantes :

    Déclencheur
    Déclenche la construction d'une nouvelle image lorsque l'image du constructeur change. Ajoutez d'autres déclencheurs en cliquant sur Add Trigger et en sélectionnant Type et Secret.
    Secrets
    Ajoute des secrets pour votre application. Ajoutez d'autres secrets en cliquant sur Add secret et en sélectionnant Secret et Mount point.
    Politique
    Cliquez sur Run policy pour sélectionner la politique d'exécution de la construction. La politique sélectionnée détermine l'ordre dans lequel les builds créés à partir de la configuration de build doivent être exécutés.
    Crochets
    Sélectionnez Run build hooks after image is built pour exécuter des commandes à la fin de la construction et vérifier l'image. Ajoutez Hook type, Command, et Arguments à la commande.
  7. Cliquez sur Save pour enregistrer l'adresse BuildConfig.

2.7.4. Suppression d'une BuildConfig

Vous pouvez supprimer un site BuildConfig à l'aide de la commande suivante.

Procédure

  • Pour supprimer un site BuildConfig, entrez la commande suivante :

    oc delete bc <BuildConfigName> $ oc delete bc <BuildConfigName>

    Cette opération supprime également toutes les constructions qui ont été instanciées à partir de ce site BuildConfig.

  • Pour supprimer un site BuildConfig et conserver les constructions installées à partir du site BuildConfig, spécifiez l'indicateur --cascade=false lorsque vous entrez la commande suivante :

    oc delete --cascade=false bc <BuildConfigName>

2.7.5. Voir les détails de la construction

Vous pouvez afficher les détails de la construction à l'aide de la console Web ou de la commande CLI oc describe.

Cette fonction permet d'afficher des informations telles que

  • La source de construction.
  • La stratégie de construction.
  • La destination de la sortie.
  • Digest de l'image dans le registre de destination.
  • Comment la construction a été créée.

Si la compilation utilise la stratégie Docker ou Source, la sortie oc describe inclut également des informations sur la révision des sources utilisée pour la compilation, y compris l'ID du commit, l'auteur, le committer et le message.

Procédure

  • Pour afficher les détails de la construction, entrez la commande suivante :

    oc describe build <nom_de_la_construction>

2.7.6. Accès aux journaux de construction

Vous pouvez accéder aux journaux de construction à l'aide de la console web ou de l'interface de programmation.

Procédure

  • Pour diffuser les journaux en utilisant directement la compilation, entrez la commande suivante :

    oc describe build <nom_de_la_construction>

2.7.6.1. Accès aux journaux de BuildConfig

Vous pouvez accéder aux journaux de BuildConfig à l'aide de la console Web ou de la CLI.

Procédure

  • Pour diffuser les journaux de la dernière version pour une BuildConfig, entrez la commande suivante :

    oc logs -f bc/<buildconfig_name>

2.7.6.2. Accès aux journaux BuildConfig pour une version donnée de la construction

Vous pouvez accéder aux journaux d'une version donnée pour une BuildConfig en utilisant la console web ou le CLI.

Procédure

  • Pour diffuser les journaux d'une version donnée pour une BuildConfig, entrez la commande suivante :

    oc logs --version=<number> bc/<buildconfig_name>

2.7.6.3. Activation de la verbosité des journaux

Vous pouvez activer une sortie plus verbeuse en transmettant la variable d'environnement BUILD_LOGLEVEL dans le cadre de sourceStrategy ou dockerStrategy dans BuildConfig.

Note

Un administrateur peut définir la verbosité de construction par défaut pour l'ensemble de l'instance d'OpenShift Container Platform en configurant env/BUILD_LOGLEVEL. Cette valeur par défaut peut être remplacée en spécifiant BUILD_LOGLEVEL dans un BuildConfig donné. Vous pouvez spécifier une priorité plus élevée sur la ligne de commande pour les constructions non binaires en passant --build-loglevel à oc start-build.

Les niveaux de journalisation disponibles pour les compilations de sources sont les suivants :

Niveau 0

Produit la sortie des conteneurs exécutant le script assemble et toutes les erreurs rencontrées. Il s'agit de la valeur par défaut.

Niveau 1

Produit des informations de base sur le processus exécuté.

Niveau 2

Produit des informations très détaillées sur le processus exécuté.

Niveau 3

Produit des informations très détaillées sur le processus exécuté, ainsi qu'une liste du contenu de l'archive.

Niveau 4

Produit actuellement les mêmes informations que le niveau 3.

Niveau 5

Produit tout ce qui est mentionné dans les niveaux précédents et fournit en plus des messages docker push.

Procédure

  • Pour obtenir une sortie plus verbeuse, transmettez la variable d'environnement BUILD_LOGLEVEL à l'adresse sourceStrategy ou dockerStrategy à l'adresse BuildConfig:

    sourceStrategy:
    ...
      env:
        - name: "BUILD_LOGLEVEL"
          value: "2" 1
    1
    Ajustez cette valeur au niveau d'enregistrement souhaité.

2.8. Déclenchement et modification des constructions

Les sections suivantes décrivent comment déclencher des builds et modifier des builds à l'aide de crochets de build.

2.8.1. Construire des déclencheurs

Lors de la définition d'un site BuildConfig, vous pouvez définir des déclencheurs pour contrôler les circonstances dans lesquelles le site BuildConfig doit être exécuté. Les déclencheurs de construction suivants sont disponibles :

  • Crochet Web
  • Changement d'image
  • Changement de configuration

2.8.1.1. Déclencheurs de webhook

Les déclencheurs Webhook vous permettent de déclencher une nouvelle construction en envoyant une demande au point d'extrémité API de OpenShift Container Platform. Vous pouvez définir ces déclencheurs en utilisant GitHub, GitLab, Bitbucket ou Generic webhooks.

Actuellement, les webhooks d'OpenShift Container Platform ne supportent que les versions analogues de l'événement push pour chacun des systèmes de gestion de code source (SCM) basés sur Git. Tous les autres types d'événements sont ignorés.

Lorsque les événements push sont traités, l'hôte du plan de contrôle d'OpenShift Container Platform confirme si la référence de la branche à l'intérieur de l'événement correspond à la référence de la branche dans le BuildConfig correspondant. Si c'est le cas, il vérifie alors la référence exacte du commit noté dans l'événement webhook sur le build d'OpenShift Container Platform. S'ils ne correspondent pas, aucun build n'est déclenché.

Note

oc new-app et oc new-build créent automatiquement les déclencheurs GitHub et Generic webhook, mais tous les autres déclencheurs webhook nécessaires doivent être ajoutés manuellement. Vous pouvez ajouter manuellement des déclencheurs en définissant des déclencheurs.

Pour tous les webhooks, vous devez définir un secret avec une clé nommée WebHookSecretKey et la valeur à fournir lors de l'invocation du webhook. La définition du webhook doit ensuite faire référence au secret. Le secret garantit l'unicité de l'URL, empêchant ainsi d'autres personnes de déclencher la construction. La valeur de la clé est comparée au secret fourni lors de l'invocation du webhook.

Par exemple, voici un webhook GitHub avec une référence à un secret nommé mysecret:

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

Le secret est alors défini comme suit. Notez que la valeur du secret est codée en base64, comme c'est le cas pour tout champ data d'un objet Secret.

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx
2.8.1.1.1. Utiliser les webhooks de GitHub

Les webhooks de GitHub gèrent l'appel fait par GitHub lorsqu'un dépôt est mis à jour. Lors de la définition du déclencheur, vous devez spécifier un secret, qui fait partie de l'URL que vous fournissez à GitHub lors de la configuration du webhook.

Exemple de définition d'un webhook GitHub :

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

Le secret utilisé dans la configuration du déclencheur du webhook n'est pas le même que le champ secret que vous rencontrez lors de la configuration du webhook dans l'interface utilisateur de GitHub. Le premier sert à rendre l'URL du webhook unique et difficile à prédire, le second est un champ de chaîne optionnel utilisé pour créer un condensé hexagonal HMAC du corps, qui est envoyé en tant qu'en-tête X-Hub-Signature.

L'URL du payload est renvoyée en tant qu'URL du Webhook GitHub par la commande oc describe (voir Afficher les URL du Webhook), et est structurée comme suit :

Exemple de sortie

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

Conditions préalables

  • Créer un site BuildConfig à partir d'un dépôt GitHub.

Procédure

  1. Pour configurer un GitHub Webhook :

    1. Après avoir créé un site BuildConfig à partir d'un dépôt GitHub, exécutez :

      $ oc describe bc/<name-of-your-BuildConfig>

      Cela génère un webhook GitHub URL qui ressemble à :

      Exemple de sortie

      <https://api.starter-us-east-1.openshift.com:443/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

    2. Copiez et collez cette URL dans GitHub, à partir de la console web de GitHub.
    3. Dans votre dépôt GitHub, sélectionnez Add Webhook à partir de Settings → Webhooks.
    4. Collez l'URL dans le champ Payload URL.
    5. Changez le Content Type de la valeur par défaut de GitHub application/x-www-form-urlencoded à application/json.
    6. Cliquez sur Add webhook.

      Vous devriez voir un message de GitHub indiquant que votre webhook a été configuré avec succès.

      Désormais, lorsque vous apportez une modification à votre dépôt GitHub, une nouvelle construction démarre automatiquement, et une fois la construction réussie, un nouveau déploiement démarre.

      Note

      Gogs supporte le même format de charge utile de webhook que GitHub. Par conséquent, si vous utilisez un serveur Gogs, vous pouvez définir un déclencheur webhook GitHub sur votre BuildConfig et le déclencher également par votre serveur Gogs.

  2. Avec un fichier contenant une charge utile JSON valide, tel que payload.json, vous pouvez déclencher manuellement le webhook avec curl:

    $ curl -H \N "X-GitHub-Event : push\N" -H "Content-Type : application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

    L'argument -k n'est nécessaire que si votre serveur API ne dispose pas d'un certificat correctement signé.

Ressources complémentaires

2.8.1.1.2. Utiliser les webhooks de GitLab

Les webhooks de GitLab gèrent l'appel fait par GitLab lorsqu'un dépôt est mis à jour. Comme pour les déclencheurs GitHub, vous devez spécifier un secret. L'exemple suivant est une définition YAML d'un déclencheur dans le fichier BuildConfig:

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

L'URL de la charge utile est renvoyée en tant qu'URL de GitLab Webhook par la commande oc describe, et est structurée comme suit :

Exemple de sortie

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

Procédure

  1. Pour configurer un GitLab Webhook :

    1. Décrire le site BuildConfig pour obtenir l'URL du webhook :

      $ oc describe bc <name>
    2. Copiez l'URL du webhook en remplaçant <secret> par votre valeur secrète.
    3. Suivez les instructions d'installation de GitLab pour coller l'URL du webhook dans les paramètres de votre dépôt GitLab.
  2. Avec un fichier contenant une charge utile JSON valide, tel que payload.json, vous pouvez déclencher manuellement le webhook avec curl:

    $ curl -H "X-GitLab-Event : Push Hook" -H "Content-Type : application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

    L'argument -k n'est nécessaire que si votre serveur API ne dispose pas d'un certificat correctement signé.

2.8.1.1.3. Utiliser les webhooks Bitbucket

Les webhooks Bitbucket gèrent l'appel fait par Bitbucket lorsqu'un référentiel est mis à jour. Comme pour les triggers précédents, vous devez spécifier un secret. L'exemple suivant est une définition YAML d'un déclencheur dans le fichier BuildConfig:

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

L'URL de la charge utile est renvoyée en tant qu'URL de Bitbucket Webhook par la commande oc describe, et est structurée comme suit :

Exemple de sortie

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

Procédure

  1. Pour configurer un Webhook Bitbucket :

    1. Décrivez le "BuildConfig" pour obtenir l'URL du webhook :

      $ oc describe bc <name>
    2. Copiez l'URL du webhook en remplaçant <secret> par votre valeur secrète.
    3. Suivez les instructions de configuration de Bitbucket pour coller l'URL du webhook dans les paramètres de votre référentiel Bitbucket.
  2. Avec un fichier contenant une charge utile JSON valide, tel que payload.json, vous pouvez déclencher manuellement le webhook avec curl:

    $ curl -H \N "X-Event-Key : repo:push" -H "Content-Type : application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

    L'argument -k n'est nécessaire que si votre serveur API ne dispose pas d'un certificat correctement signé.

2.8.1.1.4. Utilisation de webhooks génériques

Les webhooks génériques sont invoqués à partir de n'importe quel système capable de faire une requête web. Comme pour les autres webhooks, vous devez spécifier un secret, qui fait partie de l'URL que l'appelant doit utiliser pour déclencher la compilation. Le secret garantit l'unicité de l'URL, empêchant ainsi d'autres personnes de déclencher la création. Voici un exemple de définition de déclencheur YAML dans BuildConfig:

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 1
1
La valeur true permet à un webhook générique de transmettre des variables d'environnement.

Procédure

  1. Pour configurer l'appelant, fournissez au système appelant l'URL du point de terminaison générique du webhook pour votre construction :

    Exemple de sortie

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

    L'appelant doit invoquer le webhook en tant qu'opération POST.

  2. Pour invoquer manuellement le webhook, vous pouvez utiliser curl:

    $ curl -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

    Le verbe HTTP doit être défini sur POST. L'indicateur insecure -k est spécifié pour ignorer la validation du certificat. Ce deuxième indicateur n'est pas nécessaire si votre cluster dispose de certificats correctement signés.

    Le point d'accès peut accepter une charge utile facultative au format suivant :

    git:
      uri: "<url to git repository>"
      ref: "<optional git reference>"
      commit: "<commit hash identifying a specific git commit>"
      author:
        name: "<author name>"
        email: "<author e-mail>"
      committer:
        name: "<committer name>"
        email: "<committer e-mail>"
      message: "<commit message>"
    env: 1
       - name: "<variable name>"
         value: "<variable value>"
    1
    Comme pour les variables d'environnement de BuildConfig, les variables d'environnement définies ici sont mises à la disposition de votre compilation. Si ces variables entrent en conflit avec les variables d'environnement de BuildConfig, ces dernières sont prioritaires. Par défaut, les variables d'environnement transmises par webhook sont ignorées. Définissez le champ allowEnv à true dans la définition du webhook pour activer ce comportement.
  3. Pour transmettre cette charge utile à l'aide de curl, définissez-la dans un fichier nommé payload_file.yaml et exécutez :

    $ curl -H "Content-Type : application/yaml" --data-binary @payload_file.yaml -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

    Les arguments sont les mêmes que dans l'exemple précédent, avec l'ajout d'un en-tête et d'une charge utile. L'argument -H définit l'en-tête Content-Type en application/yaml ou application/json en fonction du format de votre charge utile. L'argument --data-binary est utilisé pour envoyer une charge utile binaire avec les nouvelles lignes intactes avec la requête POST.

Note

OpenShift Container Platform permet aux builds d'être déclenchées par le webhook générique même si une charge utile de requête invalide est présentée, par exemple, un type de contenu invalide, un contenu non analysable ou invalide, et ainsi de suite. Ce comportement est maintenu pour des raisons de compatibilité ascendante. Si une charge utile non valide est présentée, OpenShift Container Platform renvoie un avertissement au format JSON dans le cadre de sa réponse HTTP 200 OK.

2.8.1.1.5. Affichage des URL des webhooks

Vous pouvez utiliser la commande suivante pour afficher les URL de webhook associées à une configuration de construction. Si la commande n'affiche aucune URL de webhook, aucun déclencheur de webhook n'est défini pour cette configuration.

Procédure

  • Pour afficher les URL des webhooks associés à un site BuildConfig, exécutez :
$ oc describe bc <name>

2.8.1.2. Utilisation des déclencheurs de changement d'image

En tant que développeur, vous pouvez configurer votre compilation pour qu'elle s'exécute automatiquement chaque fois qu'une image de base est modifiée.

Vous pouvez utiliser des déclencheurs de changement d'image pour lancer automatiquement votre compilation lorsqu'une nouvelle version d'une image en amont est disponible. Par exemple, si une compilation est basée sur une image RHEL, vous pouvez déclencher l'exécution de cette compilation chaque fois que l'image RHEL change. Ainsi, l'image de l'application s'exécute toujours sur la dernière image de base RHEL.

Note

Les flux d'images qui pointent vers des images de conteneurs dans les registres de conteneurs v1 ne déclenchent une compilation qu'une seule fois, lorsque la balise du flux d'images devient disponible, et non lors des mises à jour ultérieures de l'image. Cela est dû à l'absence d'images identifiables de manière unique dans les registres de conteneurs v1.

Procédure

  1. Définissez une adresse ImageStream qui pointe vers l'image en amont que vous souhaitez utiliser comme déclencheur :

    kind: "ImageStream"
    apiVersion: "v1"
    metadata:
      name: "ruby-20-centos7"

    Cela définit le flux d'images lié à un référentiel d'images de conteneurs situé à l'adresse <system-registry>/<namespace>/ruby-20-centos7. Le site <system-registry> est défini comme un service portant le nom docker-registry et fonctionnant dans OpenShift Container Platform.

  2. Si un flux d'images est l'image de base pour la compilation, définissez le champ from dans la stratégie de compilation pour qu'il pointe vers l'image ImageStream:

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

    Dans ce cas, la définition sourceStrategy consomme la balise latest du flux d'images nommé ruby-20-centos7 situé dans cet espace de noms.

  3. Définir une construction avec un ou plusieurs déclencheurs qui pointent vers ImageStreams:

    type: "ImageChange" 1
    imageChange: {}
    type: "ImageChange" 2
    imageChange:
      from:
        kind: "ImageStreamTag"
        name: "custom-image:latest"
    1
    Un déclencheur de changement d'image qui surveille les objets ImageStream et Tag tels que définis par le champ from de la stratégie de construction. L'objet imageChange doit être vide.
    2
    Un déclencheur de changement d'image qui surveille un flux d'images arbitraire. La partie imageChange, dans ce cas, doit inclure un champ from qui fait référence au ImageStreamTag à surveiller.

Lors de l'utilisation d'un déclencheur de changement d'image pour le flux d'image de la stratégie, le build généré est fourni avec un tag docker immuable qui pointe vers la dernière image correspondant à ce tag. Cette nouvelle référence d'image est utilisée par la stratégie lorsqu'elle s'exécute pour la construction.

Pour les autres déclencheurs de changement d'image qui ne font pas référence au flux d'images de la stratégie, une nouvelle construction est lancée, mais la stratégie de construction n'est pas mise à jour avec une référence d'image unique.

Comme cet exemple comporte un déclencheur de changement d'image pour la stratégie, la compilation résultante est la suivante :

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

Cela garantit que la construction déclenchée utilise la nouvelle image qui vient d'être poussée dans le dépôt, et que la construction peut être relancée à tout moment avec les mêmes données.

Vous pouvez mettre en pause un déclencheur de changement d'image pour permettre plusieurs changements sur le flux d'images référencé avant qu'une compilation ne soit lancée. Vous pouvez également attribuer la valeur true à l'attribut paused lors de l'ajout initial d'un ImageChangeTrigger à un BuildConfig afin d'empêcher le déclenchement immédiat d'une compilation.

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

En plus de définir le champ image pour tous les types Strategy, pour les constructions personnalisées, la variable d'environnement OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE est vérifiée. Si elle n'existe pas, elle est créée avec la référence d'image immuable. Si elle existe, elle est mise à jour avec la référence d'image immuable.

Si une compilation est déclenchée par un webhook ou une demande manuelle, la compilation créée utilise le <immutableid> résolu à partir du ImageStream référencé par le Strategy. Cela garantit que les compilations sont effectuées en utilisant des balises d'image cohérentes pour faciliter la reproduction.

Ressources complémentaires

2.8.1.3. Identifier l'élément déclencheur d'un changement d'image lors d'une construction

En tant que développeur, si vous avez des déclencheurs de changement d'image, vous pouvez identifier le changement d'image qui a déclenché la dernière compilation. Cela peut s'avérer utile pour le débogage ou le dépannage des constructions.

Exemple BuildConfig

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

Note

Cet exemple omet les éléments qui ne sont pas liés aux déclencheurs de changement d'image.

Conditions préalables

  • Vous avez configuré plusieurs déclencheurs de changement d'image. Ces déclencheurs ont déclenché une ou plusieurs constructions.

Procédure

  1. Dans buildConfig.status.imageChangeTriggers pour identifier le site lastTriggerTime qui a l'horodatage le plus récent.

    Le présent ImageChangeTriggerStatus

    Ensuite, vous utilisez le `name` et le `namespace` de cette compilation pour trouver le trigger de changement d'image correspondant dans `buildConfig.spec.triggers`.
  2. Sous imageChangeTriggers, comparez les horodatages pour identifier le dernier

Déclencheurs de changement d'image

Dans votre configuration de construction, buildConfig.spec.triggers est un tableau de politiques de déclenchement de construction, BuildTriggerPolicy.

Chaque site BuildTriggerPolicy possède un champ type et un ensemble de champs pointeurs. Chaque champ pointeur correspond à l'une des valeurs autorisées pour le champ type. Ainsi, vous ne pouvez attribuer à BuildTriggerPolicy qu'un seul champ de pointeurs.

Pour les déclencheurs de changement d'image, la valeur de type est ImageChange. Ensuite, le champ imageChange est le pointeur vers un objet ImageChangeTrigger, qui possède les champs suivants :

  • lastTriggeredImageID: Ce champ, qui n'apparaît pas dans l'exemple, est obsolète dans OpenShift Container Platform 4.8 et sera ignoré dans une prochaine version. Il contient la référence de l'image résolue pour le ImageStreamTag lorsque le dernier build a été déclenché à partir de ce BuildConfig.
  • paused: Vous pouvez utiliser ce champ, qui n'apparaît pas dans l'exemple, pour désactiver temporairement ce déclencheur de changement d'image particulier.
  • from: Ce champ permet de référencer le site ImageStreamTag qui pilote ce déclencheur de changement d'image. Son type est le type de base de Kubernetes, OwnerReference.

The from field has the following fields of note: kind: For image change triggers, the only supported value is ImageStreamTag. namespace: You use this field to specify the namespace of the ImageStreamTag. ** name: You use this field to specify the ImageStreamTag.

Statut du déclencheur de changement d'image

Dans votre configuration de construction, buildConfig.status.imageChangeTriggers est un tableau d'éléments ImageChangeTriggerStatus. Chaque élément ImageChangeTriggerStatus comprend les éléments from, lastTriggeredImageID et lastTriggerTime présentés dans l'exemple précédent.

Le site ImageChangeTriggerStatus qui contient la version la plus récente de lastTriggerTime a déclenché la version la plus récente. Vous utilisez ses name et namespace pour identifier le déclencheur de changement d'image dans buildConfig.spec.triggers qui a déclenché la compilation.

Le site lastTriggerTime dont l'horodatage est le plus récent correspond au site ImageChangeTriggerStatus de la dernière version. Ce ImageChangeTriggerStatus a les mêmes name et namespace que le déclencheur de changement d'image dans buildConfig.spec.triggers qui a déclenché la construction.

Ressources complémentaires

2.8.1.4. Déclencheurs de changement de configuration

Un déclencheur de changement de configuration permet de lancer automatiquement une compilation dès qu'un nouveau site BuildConfig est créé.

Voici un exemple de définition de déclencheur YAML dans la base de données BuildConfig:

  type: "ConfigChange"
Note

Les déclencheurs de changement de configuration ne fonctionnent actuellement que lors de la création d'un nouveau site BuildConfig. Dans une prochaine version, les déclencheurs de changement de configuration pourront également lancer une construction à chaque fois qu'un site BuildConfig sera mis à jour.

2.8.1.4.1. Réglage manuel des déclencheurs

Les déclencheurs peuvent être ajoutés et supprimés des configurations de construction à l'aide de oc set triggers.

Procédure

  • Pour définir un déclencheur GitHub webhook sur une configuration de construction, utilisez :

    $ oc set triggers bc <name> --from-github
  • Pour définir un déclencheur de changement d'image, utilisez :

    $ oc set triggers bc <name> --from-image='<image>'
  • Pour supprimer un déclencheur, ajoutez --remove:

    $ oc set triggers bc <name> --from-bitbucket --remove
Note

Lorsqu'un déclencheur de webhook existe déjà, le fait de l'ajouter à nouveau régénère le secret du webhook.

Pour plus d'informations, consultez la documentation d'aide avec en exécutant :

$ oc set triggers --help

2.8.2. Construire des crochets

Les crochets de construction permettent d'injecter un 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 la compilation. Le hook est exécuté immédiatement après que la dernière couche de l'image a été validée et avant que l'image ne soit poussée vers un registre.

Le répertoire de travail actuel est défini comme étant le répertoire de l'image WORKDIR, qui est le répertoire de travail par défaut de l'image du conteneur. Pour la plupart des images, c'est là que se trouve le code source.

Le hook é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 hook échoue, il marque la compilation comme ayant échoué et l'image n'est pas poussée vers un registre. La raison de l'échec peut être vérifiée en consultant les journaux de construction.

Les crochets de construction peuvent être utilisés pour exécuter des tests unitaires afin de vérifier l'image avant que la construction ne soit considérée comme terminée et que l'image ne soit mise à disposition dans un registre. Si tous les tests réussissent et que le programme d'exécution des tests renvoie le code de sortie 0, la compilation est considérée comme réussie. En cas d'échec d'un test, la compilation est considérée comme un échec. Dans tous les cas, le journal de construction contient la sortie du programme d'essai, qui peut être utilisée pour identifier les tests qui ont échoué.

Le hook postCommit n'est pas seulement limité à l'exécution de tests, mais peut également être utilisé pour d'autres commandes. Comme il s'exécute 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 supprimées et ne sont pas présentes dans l'image finale.

2.8.2.1. Configurer les crochets de compilation après livraison

Il existe différentes façons de configurer le crochet de post-construction. Tous les formulaires des exemples suivants sont équivalents et s'exécutent à l'adresse bundle exec rake test --verbose.

Procédure

  • Script shell :

    postCommit:
      script: "bundle exec rake test --verbose"

    La valeur script est un script shell à exécuter avec /bin/sh -ic. Utilisez cette valeur lorsqu'un script shell est approprié pour exécuter le crochet de compilation. Par exemple, pour exécuter des tests unitaires comme ci-dessus. Pour contrôler le point d'entrée de l'image, ou si l'image n'a pas /bin/sh, utilisez command et/ou args.

    Note

    Le drapeau supplémentaire -i a été introduit pour améliorer l'expérience de travail avec les images CentOS et RHEL, et pourrait être supprimé dans une prochaine version.

  • Comme point d'entrée de l'image :

    postCommit:
      command: ["/bin/bash", "-c", "bundle exec rake test --verbose"]

    Dans cette forme, command est la commande à exécuter, qui remplace le point d'entrée de l'image dans la forme exec, comme documenté dans la référence Dockerfile. Ceci est nécessaire si l'image n'a pas /bin/sh, ou si vous ne voulez pas utiliser un shell. Dans tous les autres cas, l'utilisation de script peut être plus pratique.

  • Commande avec arguments :

    postCommit:
      command: ["bundle", "exec", "rake", "test"]
      args: ["--verbose"]

    Cette forme est équivalente à l'ajout des arguments à command.

Note

Fournir simultanément script et command crée un crochet de construction invalide.

2.8.2.2. Utiliser l'interface de commande pour définir les crochets de compilation après livraison

La commande oc set build-hook peut être utilisée pour définir le crochet de compilation pour une configuration de compilation.

Procédure

  1. Pour définir une commande comme crochet de construction post-commit :

    $ oc set build-hook bc/mybc \
        --post-commit \
        --command \
        -- bundle exec rake test --verbose
  2. Pour définir un script comme crochet de compilation post-commit :

    $ oc set build-hook bc/mybc --post-commit --script="bundle exec rake test --verbose"

2.9. Effectuer des constructions avancées

Les sections suivantes fournissent des instructions pour les opérations de construction avancées, notamment la définition des ressources de construction et de la durée maximale, l'affectation des constructions aux nœuds, l'enchaînement des constructions, l'élagage des constructions et les stratégies d'exécution des constructions.

2.9.1. Définition des ressources de construction

Par défaut, les constructions sont réalisées par des pods utilisant des ressources non liées, telles que la mémoire et le processeur. Ces ressources peuvent être limitées.

Procédure

Vous pouvez limiter l'utilisation des ressources de deux manières :

  • Limiter l'utilisation des ressources en spécifiant des limites de ressources dans les limites du conteneur par défaut d'un projet.
  • Limit resource use by specifying resource limits as part of the build configuration. ** In the following example, each of the resources, cpu, and memory parameters are optional:

    apiVersion: "v1"
    kind: "BuildConfig"
    metadata:
      name: "sample-build"
    spec:
      resources:
        limits:
          cpu: "100m" 1
          memory: "256Mi" 2
    1
    cpu is in CPU units: 100m represents 0.1 CPU units (100 * 1e-3).
    2
    memory is in bytes: 256Mi represents 268435456 bytes (256 * 2 ^ 20).

    Toutefois, si un quota a été défini pour votre projet, l'un des deux éléments suivants est nécessaire :

    • Un ensemble de sections resources avec un requests explicite :

      resources:
        requests: 1
          cpu: "100m"
          memory: "256Mi"
      1
      L'objet requests contient la liste des ressources correspondant à la liste des ressources du quota.
    • Une plage de limites définie dans votre projet, où les valeurs par défaut de l'objet LimitRange s'appliquent aux pods créés pendant le processus de construction.

      Dans le cas contraire, la création d'un build pod échouera, car le quota n'aura pas été atteint.

2.9.2. Définition de la durée maximale

Lors de la définition d'un objet BuildConfig, vous pouvez définir sa durée maximale en définissant le champ completionDeadlineSeconds. Ce champ est spécifié en secondes et n'est pas défini par défaut. S'il n'est pas défini, aucune durée maximale n'est imposée.

La durée maximale est calculée à partir du moment où un pod de construction est planifié dans le système, et définit la durée pendant laquelle il peut être actif, y compris le temps nécessaire à l'extraction de l'image du constructeur. Après avoir atteint le délai spécifié, la construction est interrompue par OpenShift Container Platform.

Procédure

  • Pour définir la durée maximale, spécifiez completionDeadlineSeconds dans votre BuildConfig. L'exemple suivant montre la partie d'un BuildConfig spécifiant le champ completionDeadlineSeconds pour 30 minutes :

    spec:
      completionDeadlineSeconds: 1800
Note

Ce paramètre n'est pas pris en charge par l'option Stratégie de pipeline.

2.9.3. Assigner des constructions à des nœuds spécifiques

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

La valeur nodeSelector peut également être contrôlée par des valeurs par défaut et des valeurs de remplacement à l'échelle du cluster. Les valeurs par défaut ne seront appliquées que si la configuration de construction ne définit aucune paire clé-valeur pour nodeSelector et ne définit pas non plus une valeur de carte explicitement vide pour nodeSelector:{}. Les valeurs de remplacement remplaceront les valeurs dans la configuration de construction sur une base clé par clé.

Note

Si l'adresse NodeSelector spécifiée ne peut être associée à un nœud portant ces étiquettes, la construction reste indéfiniment dans l'état Pending.

Procédure

  • Attribuez des builds à exécuter sur des nœuds spécifiques en attribuant des étiquettes dans le champ nodeSelector de l'adresse BuildConfig, par exemple :

    apiVersion: "v1"
    kind: "BuildConfig"
    metadata:
      name: "sample-build"
    spec:
      nodeSelector:1
        key1: value1
        key2: value2
    1
    Les constructions associées à cette configuration de construction ne s'exécuteront que sur les nœuds portant les étiquettes key1=value2 et key2=value2.

2.9.4. Constructions en chaîne

Pour les langages compilés tels que Go, C, C et Java, l'inclusion des dépendances nécessaires à la compilation dans l'image de l'application peut augmenter la taille de l'image ou introduire des vulnérabilités qui peuvent être exploitées.

Pour éviter ces problèmes, il est possible d'enchaîner deux compilations. Une compilation qui produit l'artefact compilé, et une seconde qui place cet artefact dans une image séparée qui exécute l'artefact.

Dans l'exemple suivant, une compilation source-image (S2I) est combinée avec une compilation docker pour compiler un artefact qui est ensuite placé dans une image d'exécution séparée.

Note

Bien que cet exemple enchaîne une construction S2I et une construction docker, la première construction peut utiliser n'importe quelle stratégie qui produit une image contenant les artefacts souhaités, et la seconde construction peut utiliser n'importe quelle stratégie qui peut consommer du contenu d'entrée à partir d'une image.

La première compilation prend la source de l'application et produit une image contenant un fichier WAR. L'image est poussée vers le flux d'images artifact-image. Le chemin de l'artefact de sortie dépend du script assemble du constructeur S2I utilisé. Dans le cas présent, l'artefact est envoyé à /wildfly/standalone/deployments/ROOT.war.

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: artifact-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: artifact-image:latest
  source:
    git:
      uri: https://github.com/openshift/openshift-jee-sample.git
      ref: "master"
  strategy:
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: wildfly:10.1
        namespace: openshift

La deuxième version utilise l'image source avec un chemin vers le fichier WAR à l'intérieur de l'image de sortie de la première version. Une page dockerfile copie le fichier WAR dans une image d'exécution.

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: image-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: image-build:latest
  source:
    dockerfile: |-
      FROM jee-runtime:latest
      COPY ROOT.war /deployments/ROOT.war
    images:
    - from: 1
        kind: ImageStreamTag
        name: artifact-image:latest
      paths: 2
      - sourcePath: /wildfly/standalone/deployments/ROOT.war
        destinationDir: "."
  strategy:
    dockerStrategy:
      from: 3
        kind: ImageStreamTag
        name: jee-runtime:latest
  triggers:
  - imageChange: {}
    type: ImageChange
1
from spécifie que la construction de docker doit inclure la sortie de l'image du flux d'images artifact-image, qui était la cible de la construction précédente.
2
paths spécifie les chemins de l'image cible à inclure dans la construction actuelle de Docker.
3
L'image d'exécution est utilisée comme image source pour la construction de docker.

Le résultat de cette configuration est que l'image de sortie de la deuxième compilation n'a pas besoin de contenir les outils de compilation nécessaires pour créer le fichier WAR. De plus, comme la deuxième compilation contient un déclencheur de changement d'image, chaque fois que la première compilation est exécutée et produit une nouvelle image avec l'artefact binaire, la deuxième compilation est automatiquement déclenchée pour produire une image d'exécution qui contient cet artefact. Par conséquent, les deux compilations se comportent comme une seule compilation avec deux étapes.

2.9.5. Taille des constructions

Par défaut, les versions qui ont terminé leur cycle de vie sont conservées indéfiniment. Vous pouvez limiter le nombre de versions antérieures conservées.

Procédure

  1. Limitez le nombre de constructions précédentes qui sont conservées en fournissant une valeur entière positive pour successfulBuildsHistoryLimit ou failedBuildsHistoryLimit dans votre BuildConfig, par exemple :

    apiVersion: "v1"
    kind: "BuildConfig"
    metadata:
      name: "sample-build"
    spec:
      successfulBuildsHistoryLimit: 2 1
      failedBuildsHistoryLimit: 2 2
    1
    successfulBuildsHistoryLimit conservera jusqu'à deux constructions avec un statut de completed.
    2
    failedBuildsHistoryLimit retiendra jusqu'à deux constructions avec un statut de failed, canceled, ou error.
  2. Déclencher l'élagage de la construction par l'une des actions suivantes :

    • Mise à jour d'une configuration de construction.
    • Attente de la fin du cycle de vie d'une construction.

Les constructions sont triées en fonction de leur date de création, les plus anciennes étant élaguées en premier.

Note

Les administrateurs peuvent élaguer manuellement les constructions à l'aide de la commande d'élagage d'objets 'oc adm'.

2.9.6. Politique d'exécution de la construction

La politique d'exécution de la construction décrit l'ordre dans lequel les constructions créées à partir de la configuration de la construction doivent être exécutées. Pour ce faire, il suffit de modifier la valeur du champ runPolicy dans la section spec de la spécification Build.

Il est également possible de modifier la valeur de runPolicy pour les configurations de construction existantes :

  • Si l'on remplace Parallel par Serial ou SerialLatestOnly et que l'on déclenche une nouvelle construction à partir de cette configuration, la nouvelle construction attendra que toutes les constructions parallèles soient terminées, car la construction en série ne peut s'exécuter que seule.
  • Changer Serial en SerialLatestOnly et déclencher un nouveau build provoque l'annulation de tous les builds existants dans la file d'attente, à l'exception du build en cours d'exécution et du build créé le plus récemment. La version la plus récente s'exécute ensuite.

2.10. Utilisation des abonnements Red Hat dans les constructions

Utilisez les sections suivantes pour exécuter des builds intitulés sur OpenShift Container Platform.

2.10.1. Création d'une balise de flux d'images pour l'image de base universelle de Red Hat

Pour utiliser les abonnements Red Hat dans une compilation, vous créez une balise de flux d'images pour référencer l'image de base universelle (UBI).

Pour que l'UBI soit disponible à l'adresse in every project dans le cluster, vous devez ajouter la balise de flux d'images à l'espace de noms openshift. Sinon, pour le rendre disponible à l'adresse in a specific project, vous devez ajouter la balise de flux d'images à ce projet.

L'avantage d'utiliser des balises de flux d'images de cette manière est que cela permet d'accéder à l'UBI sur la base des informations d'identification registry.redhat.io dans le secret d'installation sans exposer le secret d'installation à d'autres utilisateurs. C'est plus pratique que de demander à chaque développeur d'installer des secrets d'installation avec des informations d'identification registry.redhat.io dans chaque projet.

Procédure

  • Pour créer un site ImageStreamTag dans l'espace de noms openshift, afin qu'il soit disponible pour les développeurs de tous les projets, entrez :

    $ oc tag --source=docker registry.redhat.io/ubi8/ubi:latest ubi:latest -n openshift
    Astuce

    Vous pouvez également appliquer le YAML suivant pour créer un ImageStreamTag dans l'espace de noms openshift:

    apiVersion: image.openshift.io/v1
    kind: ImageStream
    metadata:
      name: ubi
      namespace: openshift
    spec:
      tags:
      - from:
          kind: DockerImage
          name: registry.redhat.io/ubi8/ubi:latest
        name: latest
        referencePolicy:
          type: Source
  • Pour créer un site ImageStreamTag dans un seul projet, entrez :

    $ oc tag --source=docker registry.redhat.io/ubi8/ubi:latest ubi:latest
    Astuce

    Vous pouvez également appliquer le YAML suivant pour créer un site ImageStreamTag dans un seul projet :

    apiVersion: image.openshift.io/v1
    kind: ImageStream
    metadata:
      name: ubi
    spec:
      tags:
      - from:
          kind: DockerImage
          name: registry.redhat.io/ubi8/ubi:latest
        name: latest
        referencePolicy:
          type: Source

2.10.2. Ajouter des droits d'abonnement en tant que secret de construction

Les constructions qui utilisent les abonnements Red Hat pour installer le contenu doivent inclure les clés de droits en tant que secret de construction.

Conditions préalables

Vous devez avoir accès aux droits de Red Hat par le biais de votre abonnement. Le secret des droits est automatiquement créé par l'opérateur Insights.

Astuce

Lorsque vous effectuez un Entitlement Build à l'aide de Red Hat Enterprise Linux (RHEL) 7, vous devez avoir les instructions suivantes dans votre Dockerfile avant d'exécuter les commandes yum:

RUN rm /etc/rhsm-host

Procédure

  1. Ajouter le secret etc-pki-entitlement comme volume de construction dans la stratégie Docker de la configuration de construction :

    strategy:
      dockerStrategy:
        from:
          kind: ImageStreamTag
          name: ubi:latest
        volumes:
        - name: etc-pki-entitlement
          mounts:
          - destinationPath: /etc/pki/entitlement
          source:
            type: Secret
            secret:
              secretName: etc-pki-entitlement

2.10.3. Exécuter des builds avec le gestionnaire d'abonnements

2.10.3.1. Constructions Docker à l'aide du gestionnaire d'abonnement

Les constructions de stratégies Docker peuvent utiliser le gestionnaire d'abonnement pour installer le contenu de l'abonnement.

Conditions préalables

Les clés de droits doivent être ajoutées en tant que volumes de stratégie de construction.

Procédure

Utilisez le fichier Docker suivant comme exemple pour installer du contenu avec le gestionnaire d'abonnement :

FROM registry.redhat.io/ubi8/ubi:latest
RUN dnf search kernel-devel --showduplicates && \
        dnf install -y kernel-devel

2.10.4. Exécuter des builds avec des abonnements Red Hat Satellite

2.10.4.1. Ajout de configurations Red Hat Satellite aux constructions

Les constructions qui utilisent Red Hat Satellite pour installer du contenu doivent fournir des configurations appropriées pour obtenir du contenu à partir des dépôts Satellite.

Conditions préalables

  • Vous devez fournir ou créer un fichier de configuration du dépôt compatible avec yum qui télécharge le contenu de votre instance Satellite.

    Exemple de configuration du référentiel

    [test-<name>]
    name=test-<number>
    baseurl = https://satellite.../content/dist/rhel/server/7/7Server/x86_64/os
    enabled=1
    gpgcheck=0
    sslverify=0
    sslclientkey = /etc/pki/entitlement/...-key.pem
    sslclientcert = /etc/pki/entitlement/....pem

Procédure

  1. Créez un site ConfigMap contenant le fichier de configuration du référentiel Satellite :

    $ oc create configmap yum-repos-d --from-file /path/to/satellite.repo
  2. Ajouter la configuration du référentiel satellite et la clé d'habilitation en tant que volumes de construction :

    strategy:
      dockerStrategy:
        from:
          kind: ImageStreamTag
          name: ubi:latest
        volumes:
        - name: yum-repos-d
          mounts:
          - destinationPath: /etc/yum.repos.d
          source:
            type: ConfigMap
            configMap:
              name: yum-repos-d
        - name: etc-pki-entitlement
          mounts:
          - destinationPath: /etc/pki/entitlement
          source:
            type: Secret
            secret:
              secretName: etc-pki-entitlement

2.10.4.2. Constructions Docker à l'aide d'abonnements Red Hat Satellite

Les constructions de stratégie Docker peuvent utiliser les dépôts Red Hat Satellite pour installer le contenu de l'abonnement.

Conditions préalables

  • Vous avez ajouté les clés d'habilitation et les configurations du référentiel satellite en tant que volumes de construction.

Procédure

Utilisez le fichier Docker suivant comme exemple pour installer du contenu avec Satellite :

FROM registry.redhat.io/ubi8/ubi:latest
RUN dnf search kernel-devel --showduplicates && \
        dnf install -y kernel-devel

2.10.5. Exécution de constructions intitulées à l'aide d'objets SharedSecret

Vous pouvez configurer et exécuter une construction dans un espace de noms qui utilise en toute sécurité les droits RHEL d'un objet Secret dans un autre espace de noms.

Vous pouvez toujours accéder aux droits RHEL à partir d'OpenShift Builds en créant un objet Secret avec vos informations d'identification d'abonnement dans le même espace de noms que votre objet Build. Cependant, dans OpenShift Container Platform 4.10 et les versions ultérieures, vous pouvez désormais accéder à vos informations d'identification et à vos certificats à partir d'un objet Secret dans l'un des espaces de noms du système OpenShift Container Platform. Vous exécutez des constructions intitulées avec un montage de volume CSI d'une instance de ressource personnalisée (CR) SharedSecret qui référence l'objet Secret.

Cette procédure s'appuie sur la nouvelle fonctionnalité Shared Resources CSI Driver, que vous pouvez utiliser pour déclarer des montages de volumes CSI dans les Builds d'OpenShift Container Platform. Elle s'appuie également sur l'opérateur Insights d'OpenShift Container Platform.

Important

Le pilote CSI des ressources partagées et les volumes CSI de construction sont tous deux des fonctionnalités de l'aperçu technologique, qui ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et qui peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information au cours du processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Les fonctionnalités Shared Resources CSI Driver et Build CSI Volumes appartiennent également à l'ensemble de fonctionnalités TechPreviewNoUpgrade, qui est un sous-ensemble des fonctionnalités de l'aperçu technologique actuel. Vous pouvez activer l'ensemble de fonctionnalités TechPreviewNoUpgrade sur les clusters de test, où vous pouvez les tester entièrement tout en laissant les fonctionnalités désactivées sur les clusters de production. L'activation de cet ensemble de fonctionnalités ne peut être annulée et empêche les mises à jour mineures de la version. Ce jeu de fonctionnalités n'est pas recommandé sur les clusters de production. Voir "Activation des fonctionnalités de l'aperçu technologique à l'aide des portes de fonctionnalités" dans la section suivante "Ressources supplémentaires".

Conditions préalables

  • Vous avez activé l'ensemble de fonctions TechPreviewNoUpgrade en utilisant les portes de fonctions.
  • Vous avez une instance de ressource personnalisée (CR) SharedSecret qui fait référence à l'objet Secret dans lequel l'opérateur Insights stocke les informations d'identification de l'abonnement.
  • Vous devez être autorisé à effectuer les actions suivantes :

    • Créer des configurations de construction et démarrer des constructions.
    • Découvrez quelles instances de SharedSecret CR sont disponibles en entrant la commande oc get sharedsecrets et en obtenant une liste non vide en retour.
    • Déterminez si le compte de service builder dont vous disposez dans votre espace de noms est autorisé à utiliser l'instance de CR SharedSecret donnée. En d'autres termes, vous pouvez exécuter oc adm policy who-can use <identifier of specific SharedSecret> pour voir si le compte de service builder de votre espace de noms est répertorié.
Note

Si aucune des deux dernières conditions préalables de cette liste n'est remplie, établissez, ou demandez à quelqu'un d'établir, le contrôle d'accès basé sur les rôles (RBAC) nécessaire pour découvrir les instances de SharedSecret CR et permettre aux comptes de service d'utiliser les instances de SharedSecret CR.

Procédure

  1. Accorder au compte de service builder les autorisations RBAC pour utiliser l'instance CR SharedSecret en utilisant oc apply avec un contenu YAML :

    Note

    Actuellement, kubectl et oc ont une logique de cas spécial codée en dur qui limite le verbe use aux rôles centrés sur la sécurité des pods. Par conséquent, vous ne pouvez pas utiliser oc create role …​ pour créer le rôle nécessaire à la consommation des instances CR SharedSecret.

    Exemple de commande oc apply -f avec définition de l'objet YAML Role

    $ oc apply -f - <<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: shared-resource-my-share
      namespace: my-namespace
    rules:
      - apiGroups:
          - sharedresource.openshift.io
        resources:
          - sharedsecrets
        resourceNames:
          - my-share
        verbs:
          - use
    EOF

  2. Créez le site RoleBinding associé au rôle en utilisant la commande oc:

    Exemple de commande oc create rolebinding

    $ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

  3. Créer un objet BuildConfig qui accède aux droits RHEL.

    Exemple de définition d'un objet YAML BuildConfig

    apiVersion: build.openshift.io/v1
    kind: BuildConfig
    metadata:
      name: my-csi-bc
      namespace: my-csi-app-namespace
    spec:
      runPolicy: Serial
      source:
        dockerfile: |
          FROM registry.redhat.io/ubi8/ubi:latest
          RUN ls -la /etc/pki/entitlement
          RUN rm /etc/rhsm-host
          RUN yum repolist --disablerepo=*
          RUN subscription-manager repos --enable rhocp-4.9-for-rhel-8-x86_64-rpms
          RUN yum -y update
          RUN yum install -y openshift-clients.x86_64
      strategy:
        type: Docker
        dockerStrategy:
          volumes:
            - mounts:
                - destinationPath: "/etc/pki/entitlement"
              name: my-csi-shared-secret
              source:
                csi:
                  driver: csi.sharedresource.openshift.io
                  readOnly: true
                  volumeAttributes:
                    sharedSecret: my-share-bc
                type: CSI

  4. Lancez une construction à partir de l'objet BuildConfig et suivez les journaux avec la commande oc.

    Exemple de commande oc start-build

    $ oc start-build my-csi-bc -F

    Exemple 2.1. Exemple de sortie de la commande oc start-build

    Note

    Certaines sections de l'édition suivante ont été remplacées par …​

    build.build.openshift.io/my-csi-bc-1 started
    Caching blobs under "/var/cache/blobs".
    
    Pulling image registry.redhat.io/ubi8/ubi:latest ...
    Trying to pull registry.redhat.io/ubi8/ubi:latest...
    Getting image source signatures
    Copying blob sha256:5dcbdc60ea6b60326f98e2b49d6ebcb7771df4b70c6297ddf2d7dede6692df6e
    Copying blob sha256:8671113e1c57d3106acaef2383f9bbfe1c45a26eacb03ec82786a494e15956c3
    Copying config sha256:b81e86a2cb9a001916dc4697d7ed4777a60f757f0b8dcc2c4d8df42f2f7edb3a
    Writing manifest to image destination
    Storing signatures
    Adding transient rw bind mount for /run/secrets/rhsm
    STEP 1/9: FROM registry.redhat.io/ubi8/ubi:latest
    STEP 2/9: RUN ls -la /etc/pki/entitlement
    total 360
    drwxrwxrwt. 2 root root 	80 Feb  3 20:28 .
    drwxr-xr-x. 10 root root	154 Jan 27 15:53 ..
    -rw-r--r--. 1 root root   3243 Feb  3 20:28 entitlement-key.pem
    -rw-r--r--. 1 root root 362540 Feb  3 20:28 entitlement.pem
    time="2022-02-03T20:28:32Z" level=warning msg="Adding metacopy option, configured globally"
    --> 1ef7c6d8c1a
    STEP 3/9: RUN rm /etc/rhsm-host
    time="2022-02-03T20:28:33Z" level=warning msg="Adding metacopy option, configured globally"
    --> b1c61f88b39
    STEP 4/9: RUN yum repolist --disablerepo=*
    Updating Subscription Management repositories.
    
    
    ...
    
    --> b067f1d63eb
    STEP 5/9: RUN subscription-manager repos --enable rhocp-4.9-for-rhel-8-x86_64-rpms
    Repository 'rhocp-4.9-for-rhel-8-x86_64-rpms' is enabled for this system.
    time="2022-02-03T20:28:40Z" level=warning msg="Adding metacopy option, configured globally"
    --> 03927607ebd
    STEP 6/9: RUN yum -y update
    Updating Subscription Management repositories.
    
    ...
    
    Upgraded:
      systemd-239-51.el8_5.3.x86_64      	systemd-libs-239-51.el8_5.3.x86_64
      systemd-pam-239-51.el8_5.3.x86_64
    Installed:
      diffutils-3.6-6.el8.x86_64           	libxkbcommon-0.9.1-1.el8.x86_64
      xkeyboard-config-2.28-1.el8.noarch
    
    Complete!
    time="2022-02-03T20:29:05Z" level=warning msg="Adding metacopy option, configured globally"
    --> db57e92ff63
    STEP 7/9: RUN yum install -y openshift-clients.x86_64
    Updating Subscription Management repositories.
    
    ...
    
    Installed:
      bash-completion-1:2.7-5.el8.noarch
      libpkgconf-1.4.2-1.el8.x86_64
      openshift-clients-4.9.0-202201211735.p0.g3f16530.assembly.stream.el8.x86_64
      pkgconf-1.4.2-1.el8.x86_64
      pkgconf-m4-1.4.2-1.el8.noarch
      pkgconf-pkg-config-1.4.2-1.el8.x86_64
    
    Complete!
    time="2022-02-03T20:29:19Z" level=warning msg="Adding metacopy option, configured globally"
    --> 609507b059e
    STEP 8/9: ENV "OPENSHIFT_BUILD_NAME"="my-csi-bc-1" "OPENSHIFT_BUILD_NAMESPACE"="my-csi-app-namespace"
    --> cab2da3efc4
    STEP 9/9: LABEL "io.openshift.build.name"="my-csi-bc-1" "io.openshift.build.namespace"="my-csi-app-namespace"
    COMMIT temp.builder.openshift.io/my-csi-app-namespace/my-csi-bc-1:edfe12ca
    --> 821b582320b
    Successfully tagged temp.builder.openshift.io/my-csi-app-namespace/my-csi-bc-1:edfe12ca
    821b582320b41f1d7bab4001395133f86fa9cc99cc0b2b64c5a53f2b6750db91
    Build complete, no image push requested

2.10.6. Ressources complémentaires

2.11. Sécuriser les constructions par la stratégie

Les builds dans OpenShift Container Platform sont exécutés dans des conteneurs privilégiés. En fonction de la stratégie de construction utilisée, si vous avez des privilèges, vous pouvez exécuter des constructions pour escalader leurs permissions sur le cluster et les nœuds hôtes. En tant que mesure de sécurité, elle limite les personnes autorisées à exécuter des builds et la stratégie utilisée pour ces builds. Les builds personnalisés sont intrinsèquement moins sûrs que les builds source, car ils peuvent exécuter n'importe quel code dans un conteneur privilégié, et sont désactivés par défaut. Accordez les permissions de construction de docker avec prudence, car une vulnérabilité dans la logique de traitement de Dockerfile pourrait entraîner l'octroi de privilèges sur le nœud hôte.

Par défaut, tous les utilisateurs qui peuvent créer des builds sont autorisés à utiliser les stratégies de build docker et Source-to-image (S2I). Les utilisateurs disposant de privilèges d'administrateur de cluster peuvent activer la stratégie de build personnalisée, comme indiqué dans la section restreignant les stratégies de build à un utilisateur de manière globale.

Vous pouvez contrôler qui peut construire et quelles stratégies de construction ils peuvent utiliser en utilisant une politique d'autorisation. Chaque stratégie de construction a une sous-ressource de construction correspondante. Un utilisateur doit avoir l'autorisation de créer un build et l'autorisation de créer sur la sous-ressource de la stratégie de build pour créer des builds utilisant cette stratégie. Des rôles par défaut sont fournis pour accorder l'autorisation de création sur la sous-ressource de la stratégie de construction.

Tableau 2.3. Stratégie de construction Sous-ressources et rôles

StratégieSous-ressourceRôle

Docker

builds/docker

system:build-strategy-docker

De la source à l'image

builds/source

system:build-strategy-source

Sur mesure

constructions/personnalisées

système:construire-stratégie-personnalisée

JenkinsPipeline

builds/jenkinspipeline

système:construire-stratégie-jenkinspipeline

2.11.1. Désactiver l'accès à une stratégie de construction au niveau mondial

Pour empêcher l'accès à une stratégie de construction particulière au niveau mondial, connectez-vous en tant qu'utilisateur disposant de privilèges d'administrateur de cluster, supprimez le rôle correspondant du groupe system:authenticated et appliquez l'annotation rbac.authorization.kubernetes.io/autoupdate: "false" pour les protéger contre les modifications entre les redémarrages de l'API. L'exemple suivant montre la désactivation de la stratégie de construction Docker.

Procédure

  1. Appliquez l'annotation rbac.authorization.kubernetes.io/autoupdate:

    $ oc edit clusterrolebinding system:build-strategy-docker-binding

    Exemple de sortie

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      annotations:
        rbac.authorization.kubernetes.io/autoupdate: "false" 1
      creationTimestamp: 2018-08-10T01:24:14Z
      name: system:build-strategy-docker-binding
      resourceVersion: "225"
      selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding
      uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bf
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: system:build-strategy-docker
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: Group
      name: system:authenticated

    1
    Changez la valeur de l'annotation rbac.authorization.kubernetes.io/autoupdate en "false".
  2. Supprimer le rôle :

    $ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated
  3. Assurez-vous que les sous-ressources de la stratégie de construction sont également supprimées de ces rôles :

    $ oc edit clusterrole admin
    $ oc edit clusterrole edit
  4. Pour chaque rôle, indiquez les sous-ressources qui correspondent à la ressource de la stratégie à désactiver.

    1. Désactiver la stratégie de construction de docker pour admin:

      kind: ClusterRole
      metadata:
        name: admin
      ...
      - apiGroups:
        - ""
        - build.openshift.io
        resources:
        - buildconfigs
        - buildconfigs/webhooks
        - builds/custom 1
        - builds/source
        verbs:
        - create
        - delete
        - deletecollection
        - get
        - list
        - patch
        - update
        - watch
      ...
      1
      Ajoutez builds/custom et builds/source pour désactiver globalement les constructions de dockers pour les utilisateurs ayant le rôle admin.

2.11.2. Restreindre les stratégies de construction aux utilisateurs au niveau mondial

Vous pouvez autoriser un ensemble d'utilisateurs spécifiques à créer des builds avec une stratégie particulière.

Conditions préalables

  • Désactiver l'accès global à la stratégie de construction.

Procédure

  • Attribuez le rôle correspondant à la stratégie de construction à un utilisateur spécifique. Par exemple, pour ajouter le rôle de cluster system:build-strategy-docker à l'utilisateur devuser:

    $ oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser
    Avertissement

    Accorder à un utilisateur l'accès au niveau du cluster à la sous-ressource builds/docker signifie que l'utilisateur peut créer des builds avec la stratégie docker dans n'importe quel projet dans lequel il peut créer des builds.

2.11.3. Restreindre les stratégies de construction à un utilisateur au sein d'un projet

De la même manière que vous attribuez le rôle de stratégie de construction à un utilisateur de manière globale, vous pouvez autoriser un ensemble d'utilisateurs spécifiques au sein d'un projet à créer des constructions à l'aide d'une stratégie particulière.

Conditions préalables

  • Désactiver l'accès global à la stratégie de construction.

Procédure

  • Attribuer le rôle correspondant à la stratégie de construction à un utilisateur spécifique au sein d'un projet. Par exemple, pour ajouter le rôle system:build-strategy-docker dans le projet devproject à l'utilisateur devuser:

    $ oc adm policy add-role-to-user system:build-strategy-docker devuser -n devproject

2.12. Construire des ressources de configuration

La procédure suivante permet de configurer les paramètres de construction.

2.12.1. Construire les paramètres de configuration du contrôleur

La ressource build.config.openshift.io/cluster offre les paramètres de configuration suivants.

ParamètresDescription

Build

Contient des informations à l'échelle du cluster sur la manière de gérer les builds. Le nom canonique, et le seul valide, est cluster.

spec: Contient des valeurs réglables par l'utilisateur pour la configuration du contrôleur de construction.

buildDefaults

Contrôle les informations par défaut pour les constructions.

defaultProxy: Contient les paramètres proxy par défaut pour toutes les opérations de construction, y compris l'extraction ou la poussée d'images et le téléchargement de sources.

Vous pouvez remplacer les valeurs en définissant les variables d'environnement HTTP_PROXY, HTTPS_PROXY et NO_PROXY dans la stratégie BuildConfig.

gitProxy: Contient les paramètres de proxy pour les opérations Git uniquement. S'ils sont définis, ils remplacent tous les paramètres de proxy pour toutes les commandes Git, telles que git clone.

Les valeurs qui ne sont pas définies ici sont héritées de DefaultProxy.

env: Un ensemble de variables d'environnement par défaut qui sont appliquées à la compilation si les variables spécifiées n'existent pas sur la compilation.

imageLabels: Une liste d'étiquettes qui sont appliquées à l'image résultante. Vous pouvez remplacer une étiquette par défaut en fournissant une étiquette portant le même nom dans l'adresse BuildConfig.

resources: Définit les ressources nécessaires à l'exécution de la construction.

ImageLabel

name: Définit le nom de l'étiquette. Il doit avoir une longueur non nulle.

buildOverrides

Contrôle les paramètres d'annulation des constructions.

imageLabels: Une liste d'étiquettes qui sont appliquées à l'image résultante. Si vous avez fourni une étiquette dans BuildConfig avec le même nom qu'une étiquette dans cette table, votre étiquette sera écrasée.

nodeSelector: Un sélecteur qui doit être vrai pour que le module de construction tienne sur un nœud.

tolerations: Une liste de tolérances qui remplace toutes les tolérances existantes définies sur un module de construction.

BuildList

items: Métadonnées de l'objet standard.

2.12.2. Configuration des paramètres de construction

Vous pouvez configurer les paramètres de construction en modifiant la ressource build.config.openshift.io/cluster.

Procédure

  • Modifier la ressource build.config.openshift.io/cluster:

    $ oc edit build.config.openshift.io/cluster

    Voici un exemple de ressource build.config.openshift.io/cluster:

    apiVersion: config.openshift.io/v1
    kind: Build1
    metadata:
      annotations:
        release.openshift.io/create-only: "true"
      creationTimestamp: "2019-05-17T13:44:26Z"
      generation: 2
      name: cluster
      resourceVersion: "107233"
      selfLink: /apis/config.openshift.io/v1/builds/cluster
      uid: e2e9cc14-78a9-11e9-b92b-06d6c7da38dc
    spec:
      buildDefaults:2
        defaultProxy:3
          httpProxy: http://proxy.com
          httpsProxy: https://proxy.com
          noProxy: internal.com
        env:4
        - name: envkey
          value: envvalue
        gitProxy:5
          httpProxy: http://gitproxy.com
          httpsProxy: https://gitproxy.com
          noProxy: internalgit.com
        imageLabels:6
        - name: labelkey
          value: labelvalue
        resources:7
          limits:
            cpu: 100m
            memory: 50Mi
          requests:
            cpu: 10m
            memory: 10Mi
      buildOverrides:8
        imageLabels:9
        - name: labelkey
          value: labelvalue
        nodeSelector:10
          selectorkey: selectorvalue
        tolerations:11
        - effect: NoSchedule
          key: node-role.kubernetes.io/builds
    operator: Exists
    1
    Build: Contient des informations à l'échelle du cluster sur la manière de gérer les builds. Le nom canonique, et le seul valide, est cluster.
    2
    buildDefaults: Contrôle les informations par défaut pour les constructions.
    3
    defaultProxy: Contient les paramètres proxy par défaut pour toutes les opérations de construction, y compris l'extraction ou la poussée d'images et le téléchargement de sources.
    4
    env: Un ensemble de variables d'environnement par défaut qui sont appliquées à la compilation si les variables spécifiées n'existent pas sur la compilation.
    5
    gitProxy: Contient les paramètres du proxy pour les opérations Git uniquement. S'ils sont définis, ils remplacent tous les paramètres de proxy pour toutes les commandes Git, telles que git clone.
    6
    imageLabels: Une liste d'étiquettes qui sont appliquées à l'image résultante. Vous pouvez remplacer une étiquette par défaut en fournissant une étiquette portant le même nom dans l'adresse BuildConfig.
    7
    resources: Définit les ressources nécessaires à l'exécution de la construction.
    8
    buildOverrides: Contrôle les paramètres d'annulation des constructions.
    9
    imageLabels: Une liste d'étiquettes qui sont appliquées à l'image résultante. Si vous avez fourni une étiquette dans BuildConfig avec le même nom qu'une étiquette dans cette table, votre étiquette sera écrasée.
    10
    nodeSelector: Un sélecteur qui doit être vrai pour que le module de construction tienne sur un nœud.
    11
    tolerations: Une liste de tolérances qui remplace toutes les tolérances existantes définies sur un module de construction.

2.13. Dépannage des constructions

Utilisez les éléments suivants pour résoudre les problèmes de construction.

2.13.1. Résoudre les refus d'accès aux ressources

Si votre demande d'accès aux ressources est refusée :

Enjeu
Une construction échoue avec :
requested access to the resource is denied
Résolution
Vous avez dépassé l'un des quotas d'images définis pour votre projet. Vérifiez votre quota actuel et vérifiez les limites appliquées et l'espace de stockage utilisé :
$ oc describe quota

2.13.2. Échec de la génération du certificat de service

Si votre demande d'accès aux ressources est refusée :

Enjeu
Si la génération d'un certificat de service échoue avec (l'annotation service.beta.openshift.io/serving-cert-generation-error du service contient) :

Exemple de sortie

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

Résolution
Le service qui a généré le certificat n'existe plus, ou a un autre serviceUID. Vous devez forcer la régénération des certificats en supprimant l'ancien secret et en effaçant les annotations suivantes sur le service : service.beta.openshift.io/serving-cert-generation-error et service.beta.openshift.io/serving-cert-generation-error-num:
oc delete secret <secret_name>
oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
Note

La commande de suppression d'une annotation comporte une adresse - après le nom de l'annotation à supprimer.

2.14. Mise en place d'autorités de certification de confiance supplémentaires pour les constructions

Utilisez les sections suivantes pour configurer des autorités de certification (AC) supplémentaires qui seront approuvées par les builds lors de l'extraction d'images à partir d'un registre d'images.

La procédure exige qu'un administrateur de cluster crée un site ConfigMap et ajoute des autorités de certification supplémentaires en tant que clés dans le site ConfigMap.

  • Le site ConfigMap doit être créé dans l'espace de noms openshift-config.
  • domain est la clé dans le site ConfigMap et value est le certificat codé en PEM.

    • Chaque autorité de certification doit être associée à un domaine. Le format du domaine est hostname[..port].
  • Le nom ConfigMap doit être défini dans le champ spec.additionalTrustedCA de la ressource image.config.openshift.io/cluster cluster scoped configuration.

2.14.1. Ajout d'autorités de certification au cluster

La procédure suivante permet d'ajouter des autorités de certification (AC) à la grappe afin de les utiliser lors de l'envoi et du retrait d'images.

Conditions préalables

  • Vous devez avoir accès aux certificats publics du registre, généralement un fichier hostname/ca.crt situé dans le répertoire /etc/docker/certs.d/.

Procédure

  1. Créez un site ConfigMap dans l'espace de noms openshift-config contenant les certificats approuvés pour les registres qui utilisent des certificats auto-signés. Pour chaque fichier CA, assurez-vous que la clé de ConfigMap est le nom d'hôte du registre au format hostname[..port]:

    $ oc create configmap registry-cas -n openshift-config \
    --from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \
    --from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt
  2. Mettre à jour la configuration de l'image du cluster :

    $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge

2.14.2. Ressources complémentaires

Chapitre 3. Pipelines

3.1. Notes de mise à jour de Red Hat OpenShift Pipelines

Red Hat OpenShift Pipelines est une expérience CI/CD cloud-native basée sur le projet Tekton qui fournit :

  • Définitions standard de pipeline natif Kubernetes (CRDs).
  • Pipelines sans serveur, sans frais de gestion des serveurs de CI.
  • Extensibilité pour construire des images en utilisant n'importe quel outil Kubernetes, comme S2I, Buildah, JIB et Kaniko.
  • Portabilité sur n'importe quelle distribution Kubernetes.
  • CLI puissant pour interagir avec les pipelines.
  • Expérience utilisateur intégrée avec la perspective Developer de la console web OpenShift Container Platform.

Pour une vue d'ensemble de Red Hat OpenShift Pipelines, voir Comprendre OpenShift Pipelines.

3.1.1. Matrice de compatibilité et de soutien

Certaines fonctionnalités de cette version sont actuellement en avant-première technologique. Ces fonctionnalités expérimentales ne sont pas destinées à être utilisées en production.

Dans le tableau, les caractéristiques sont marquées par les statuts suivants :

TP

Avant-première technologique

GA

Disponibilité générale

Tableau 3.1. Matrice de compatibilité et de soutien

Version de Red Hat OpenShift PipelinesVersion du composantVersion d'OpenShiftStatut de soutien

Opérateur

Pipelines

Déclencheurs

CLI

Catalogue

Chaînes

Hub

Les pipelines en tant que code

  

1.10

0.44.x

0.23.x

0.30.x

NA

0.15.x (TP)

1.12.x (TP)

0.17.x (GA)

4.11, 4.12, 4.13 (prévus)

GA

1.9

0.41.x

0.22.x

0.28.x

NA

0.13.x (TP)

1.11.x (TP)

0.15.x (GA)

4.11, 4.12, 4.13 (prévus)

GA

1.8

0.37.x

0.20.x

0.24.x

NA

0.9.0 (TP)

1.8.x (TP)

0.10.x (TP)

4.10, 4.11, 4.12

GA

1.7

0.33.x

0.19.x

0.23.x

0.33

0.8.0 (TP)

1.7.0 (TP)

0.5.x (TP)

4.9, 4.10, 4.11

GA

1.6

0.28.x

0.16.x

0.21.x

0.28

N/A

N/A

N/A

4.9

GA

1.5

0.24.x

0.14.x (TP)

0.19.x

0.24

N/A

N/A

N/A

4.8

GA

1.4

0.22.x

0.12.x (TP)

0.17.x

0.22

N/A

N/A

N/A

4.7

GA

En outre, la prise en charge de l'exécution de Red Hat OpenShift Pipelines sur du matériel ARM est dans l'aperçu technologique.

Pour toute question ou commentaire, vous pouvez envoyer un courriel à l'équipe produit à l'adresse pipelines-interest@redhat.com.

3.1.2. Rendre l'open source plus inclusif

Red Hat s'engage à remplacer les termes problématiques dans son code, sa documentation et ses propriétés Web. Nous commençons par ces quatre termes : master, slave, blacklist et whitelist. En raison de l'ampleur de cette entreprise, ces changements seront mis en œuvre progressivement au cours de plusieurs versions à venir. Pour plus de détails, voir le message de notre directeur technique Chris Wright.

3.1.3. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.10

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.10 est disponible sur OpenShift Container Platform 4.11 et les versions ultérieures.

3.1.3.1. Nouvelles fonctionnalités

En plus des corrections et des améliorations de stabilité, les sections suivantes mettent en évidence les nouveautés de Red Hat OpenShift Pipelines 1.10.

3.1.3.1.1. Pipelines
  • Avec cette mise à jour, vous pouvez spécifier des variables d'environnement dans un modèle de pod PipelineRun ou TaskRun pour remplacer ou ajouter les variables configurées dans une tâche ou une étape. Vous pouvez également spécifier des variables d'environnement dans un modèle de module par défaut afin d'utiliser ces variables globalement pour tous les modules PipelineRuns et TaskRuns. Cette mise à jour ajoute également une nouvelle configuration par défaut nommée forbidden-envs pour filtrer les variables d'environnement lors de la propagation à partir des modèles de pods.
  • Avec cette mise à jour, les tâches personnalisées dans les pipelines sont activées par défaut.

    Note

    Pour désactiver cette mise à jour, définissez l'indicateur enable-custom-tasks sur false dans la ressource personnalisée feature-flags config.

  • Cette mise à jour prend en charge la version de l'API v1beta1.CustomRun pour les tâches personnalisées.
  • Cette mise à jour ajoute la prise en charge du rapprochement PipelineRun pour la création d'une exécution personnalisée. Par exemple, la version personnalisée de TaskRuns créée à partir de PipelineRuns peut désormais utiliser la version de l'API v1beta1.CustomRun au lieu de v1alpha1.Run, si l'indicateur de fonctionnalité custom-task-version est défini sur v1beta1, au lieu de la valeur par défaut v1alpha1.

    Note

    Vous devez mettre à jour le contrôleur de tâches personnalisé pour qu'il écoute la version de l'API *v1beta1.CustomRun au lieu de *v1alpha1.Run afin de répondre aux demandes v1beta1.CustomRun.

  • Cette mise à jour ajoute un nouveau champ retries aux spécifications v1beta1.TaskRun et v1.TaskRun.
3.1.3.1.2. Déclencheurs
  • Avec cette mise à jour, les déclencheurs prennent en charge la création des objets Pipelines, Tasks, PipelineRuns, et TaskRuns de la version v1 de l'API ainsi que des objets CustomRun de la version v1beta1 de l'API.
  • Avec cette mise à jour, GitHub Interceptor bloque l'exécution d'un déclencheur de demande d'extraction à moins qu'il ne soit invoqué par un propriétaire ou accompagné d'un commentaire configurable de la part d'un propriétaire.

    Note

    Pour activer ou désactiver cette mise à jour, définissez la valeur du paramètre githubOwners sur true ou false dans le fichier de configuration de GitHub Interceptor.

  • Avec cette mise à jour, GitHub Interceptor a la possibilité d'ajouter une liste délimitée par des virgules de tous les fichiers qui ont été modifiés pour les événements push et pull request. La liste des fichiers modifiés est ajoutée à la propriété changed_files de la charge utile de l'événement dans le champ des extensions de premier niveau.
  • Cette mise à jour modifie le site MinVersion de TLS en tls.VersionTLS12 afin que les déclencheurs s'exécutent sur OpenShift Container Platform lorsque le mode Federal Information Processing Standards (FIPS) est activé.
3.1.3.1.3. CLI
  • Cette mise à jour ajoute la possibilité de transmettre un fichier CSI (Container Storage Interface) en tant qu'espace de travail au moment du démarrage d'une application Task, ClusterTask ou Pipeline.
  • Cette mise à jour ajoute la prise en charge de l'API v1 à toutes les commandes CLI associées aux ressources task, pipeline, pipeline run et task run. Tekton CLI fonctionne avec les API v1beta1 et v1 pour ces ressources.
  • Cette mise à jour ajoute la prise en charge d'un paramètre de type d'objet dans les commandes start et describe.
3.1.3.1.4. Opérateur
  • Cette mise à jour ajoute un paramètre default-forbidden-env dans les propriétés optionnelles du pipeline. Ce paramètre inclut des variables d'environnement interdites qui ne doivent pas être propagées si elles sont fournies par des modèles de pods.
  • Cette mise à jour ajoute la prise en charge des logos personnalisés dans l'interface utilisateur du Tekton Hub. Pour ajouter un logo personnalisé, définissez la valeur du paramètre customLogo à l'URI codée en base64 du logo dans le Tekton Hub CR.
  • Cette mise à jour augmente le numéro de version de la tâche git-clone à 0.9.
3.1.3.1.5. Chaînes Tekton
  • Cette mise à jour ajoute des annotations et des étiquettes aux attestations PipelineRun et TaskRun.
  • Cette mise à jour ajoute un nouveau format appelé slsa/v1, qui génère la même provenance que celle générée lors d'une demande au format in-toto.
  • Avec cette mise à jour, les fonctionnalités de Sigstore sont retirées des fonctionnalités expérimentales.
  • Avec cette mise à jour, la fonction predicate.materials inclut l'URI de l'image et les informations de résumé de toutes les étapes et barres latérales d'un objet TaskRun.
3.1.3.1.6. Hub Tekton
  • Cette mise à jour prend en charge l'installation, la mise à niveau ou la rétrogradation des ressources Tekton de la version de l'API v1 sur le cluster.
  • Cette mise à jour permet d'ajouter un logo personnalisé à la place du logo du Tekton Hub dans l'interface utilisateur.
  • Cette mise à jour étend les fonctionnalités de la commande tkn hub install en ajoutant un drapeau --type artifact, qui récupère les ressources de l'Artifact Hub et les installe sur votre cluster.
  • Cette mise à jour ajoute des informations sur le niveau de support, le catalogue et l'organisation en tant qu'étiquettes pour les ressources installées depuis Artifact Hub sur votre cluster.
3.1.3.1.7. Les pipelines en tant que code
  • Cette mise à jour améliore la prise en charge des webhooks entrants. Pour une application GitHub installée sur le cluster OpenShift Container Platform, vous n'avez pas besoin de fournir la spécification git_provider pour un webhook entrant. Au lieu de cela, Pipelines as Code détecte le secret et l'utilise pour le webhook entrant.
  • Avec cette mise à jour, vous pouvez utiliser le même jeton pour récupérer des tâches distantes du même hôte sur GitHub avec une branche autre que celle par défaut.
  • Avec cette mise à jour, Pipelines as Code supporte les modèles Tekton v1. Vous pouvez avoir des modèles v1 et v1beta1, que Pipelines as Code lit pour la génération de PR. Le PR est créé en tant que v1 sur le cluster.
  • Avant cette mise à jour, l'interface utilisateur de la console OpenShift utilisait un modèle d'exécution de pipeline codé en dur comme modèle de secours lorsqu'un modèle d'exécution n'était pas trouvé dans l'espace de noms OpenShift. Cette mise à jour de la carte de configuration pipelines-as-code fournit un nouveau modèle d'exécution de pipeline par défaut nommé pipelines-as-code-template-default pour la console à utiliser.
  • Avec cette mise à jour, Pipelines as Code supporte le statut minimal de Tekton Pipelines 0.44.0.
  • Avec cette mise à jour, Pipelines as Code supporte l'API Tekton v1, ce qui signifie que Pipelines as Code est maintenant compatible avec Tekton v0.44 et plus.
  • Avec cette mise à jour, vous pouvez configurer des tableaux de bord de console personnalisés en plus de la configuration d'une console pour OpenShift et des tableaux de bord Tekton pour k8s.
  • Avec cette mise à jour, Pipelines as Code détecte l'installation d'une application GitHub initiée à l'aide de la commande tkn pac create repo et ne nécessite pas de webhook GitHub si elle a été installée globalement.
  • Avant cette mise à jour, s'il y avait une erreur sur une exécution de PipelineRun et non sur les tâches attachées à PipelineRun, Pipelines as Code ne signalait pas correctement l'échec. Avec cette mise à jour, Pipelines as Code signale correctement l'erreur sur les contrôles GitHub lorsqu'un PipelineRun n'a pas pu être créé.
  • Avec cette mise à jour, Pipelines as Code inclut une variable target_namespace, qui s'étend à l'espace de noms en cours d'exécution où PipelineRun est exécuté.
  • Avec cette mise à jour, Pipelines as Code vous permet de contourner les questions d'entreprise de GitHub dans l'application CLI bootstrap GitHub.
  • Avec cette mise à jour, Pipelines as Code ne signale pas d'erreurs lorsque le référentiel CR n'a pas été trouvé.
  • Avec cette mise à jour, Pipelines as Code signale une erreur si plusieurs exécutions de pipeline portant le même nom ont été trouvées.

3.1.3.2. Changements en cours

  • Avec cette mise à jour, la version précédente de la commande tkn n'est pas compatible avec Red Hat OpenShift Pipelines 1.10.
  • Cette mise à jour supprime la prise en charge des ressources de pipeline Cluster et CloudEvent dans Tekton CLI. Vous ne pouvez pas créer de ressources de pipeline en utilisant la commande tkn pipelineresource create. De plus, les ressources de pipeline ne sont plus prises en charge dans la commande start d'une tâche, d'une tâche de cluster ou d'un pipeline.
  • Cette mise à jour supprime tekton en tant que format de provenance des chaînes Tekton.

3.1.3.3. Fonctionnalités obsolètes et supprimées

  • Dans Red Hat OpenShift Pipelines 1.10, les commandes ClusterTask sont désormais obsolètes et devraient être supprimées dans une prochaine version. La commande tkn task create est également obsolète avec cette mise à jour.
  • Dans Red Hat OpenShift Pipelines 1.10, les drapeaux -i et -o qui étaient utilisés avec la commande tkn task start sont désormais obsolètes car l'API v1 ne prend pas en charge les ressources de pipeline.
  • Dans Red Hat OpenShift Pipelines 1.10, l'indicateur -r qui était utilisé avec la commande tkn pipeline start est obsolète car l'API v1 ne prend pas en charge les ressources de pipeline.
  • La mise à jour Red Hat OpenShift Pipelines 1.10 définit le paramètre openshiftDefaultEmbeddedStatus à both avec full et minimal statut intégré. Le drapeau permettant de modifier le statut intégré par défaut est également obsolète et sera supprimé. De plus, le statut intégré par défaut du pipeline sera modifié en minimal dans une prochaine version.

3.1.3.4. Problèmes connus

  • Cette mise à jour inclut les changements suivants, incompatibles avec le passé :

    • Suppression de la grappe PipelineResources
    • Suppression du nuage PipelineResources
  • Si la fonctionnalité de mesure des pipelines ne fonctionne pas après une mise à niveau du cluster, exécutez la commande suivante en guise de solution de contournement :

    $ oc get tektoninstallersets.operator.tekton.dev | awk '/pipeline-main-static/ {print $1}' | xargs oc delete tektoninstallersets
  • Avec cette mise à jour, l'utilisation de bases de données externes, telles que Crunchy PostgreSQL, n'est pas prise en charge sur IBM Power, IBM zSystems et IBM® LinuxONE. Utilisez plutôt la base de données par défaut du Tekton Hub.

3.1.3.5. Problèmes corrigés

  • Avant cette mise à jour, la commande opc pac générait une erreur d'exécution au lieu d'afficher un message d'aide. Cette mise à jour corrige la commande opc pac pour qu'elle affiche le message d'aide.
  • Avant cette mise à jour, l'exécution de la commande tkn pac create repo nécessitait les détails du webhook pour créer un dépôt. Avec cette mise à jour, la commande tkn-pac create repo ne configure pas de webhook lorsque votre application GitHub est installée.
  • Avant cette mise à jour, Pipelines as Code ne signalait pas d'erreur de création d'une exécution de pipeline lorsque Tekton Pipelines rencontrait des problèmes lors de la création de la ressource PipelineRun. Par exemple, une tâche inexistante dans un pipeline n'affichait aucun statut. Avec cette mise à jour, Pipelines as Code affiche le message d'erreur approprié provenant de Tekton Pipelines ainsi que la tâche manquante.
  • Cette mise à jour corrige la redirection de la page de l'interface utilisateur après une authentification réussie. Désormais, vous êtes redirigé vers la même page que celle où vous avez tenté de vous connecter au Tekton Hub.
  • Cette mise à jour corrige la commande list avec ces drapeaux, --all-namespaces et --output=yaml, pour une tâche en grappe, une tâche individuelle et un pipeline.
  • Cette mise à jour supprime la barre oblique à la fin de l'URL de repo.spec.url afin qu'elle corresponde à l'URL provenant de GitHub.
  • Avant cette mise à jour, la fonction marshalJSON n'affichait pas de liste d'objets. Avec cette mise à jour, la fonction marshalJSON gère la liste d'objets.
  • Avec cette mise à jour, Pipelines as Code vous permet de contourner les questions d'entreprise de GitHub dans l'application CLI bootstrap GitHub.
  • Cette mise à jour corrige la vérification des collaborateurs GitHub lorsque votre dépôt a plus de 100 utilisateurs.
  • Avec cette mise à jour, les commandes sign et verify pour une tâche ou un pipeline fonctionnent désormais sans fichier de configuration kubernetes.
  • Avec cette mise à jour, Tekton Operator nettoie les tâches cron d'élagage restantes si l'élagage a été ignoré sur un espace de noms.
  • Avant cette mise à jour, l'objet API ConfigMap n'était pas mis à jour avec une valeur configurée par l'utilisateur pour l'intervalle de rafraîchissement du catalogue. Cette mise à jour corrige l'API CATALOG_REFRESH_INTERVAL dans le Tekon Hub CR.
  • Cette mise à jour corrige la réconciliation de PipelineRunStatus lors de la modification de l'indicateur de fonctionnalité EmbeddedStatus. Cette mise à jour réinitialise les paramètres suivants :

    • Les paramètres status.runs et status.taskruns à nil avec minimal EmbeddedStatus
    • Le paramètre status.childReferences à nil avec full EmbeddedStatus
  • Cette mise à jour ajoute une configuration de conversion au CRD ResolutionRequest. Cette mise à jour configure correctement la conversion de la requête v1alpha1.ResolutionRequest vers la requête v1beta1.ResolutionRequest.
  • Cette mise à jour vérifie la présence d'espaces de travail en double associés à une tâche de pipeline.
  • Cette mise à jour corrige la valeur par défaut de l'activation des résolveurs dans le code.
  • Cette mise à jour corrige la conversion des noms TaskRef et PipelineRef à l'aide d'un résolveur.

3.1.4. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.9

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.9 est disponible sur OpenShift Container Platform 4.11 et les versions ultérieures.

3.1.4.1. Nouvelles fonctionnalités

En plus des corrections et des améliorations de stabilité, les sections suivantes mettent en évidence les nouveautés de Red Hat OpenShift Pipelines 1.9.

3.1.4.1.1. Pipelines
  • Avec cette mise à jour, vous pouvez spécifier les paramètres du pipeline et les résultats sous forme de tableaux et de dictionnaires d'objets.
  • Cette mise à jour prend en charge l'interface de stockage de conteneurs (CSI) et les volumes projetés pour votre espace de travail.
  • Avec cette mise à jour, vous pouvez spécifier les paramètres stdoutConfig et stderrConfig lors de la définition des étapes du pipeline. La définition de ces paramètres permet de capturer la sortie standard et l'erreur standard, associées aux étapes, dans des fichiers locaux.
  • Avec cette mise à jour, vous pouvez ajouter des variables dans le gestionnaire d'événements steps[].onError, par exemple, $(params.CONTINUE).
  • Avec cette mise à jour, vous pouvez utiliser le résultat de la tâche finally dans la définition PipelineResults. Par exemple, $(finally.<pipelinetask-name>.result.<result-name>), où <pipelinetask-name> désigne le nom de la tâche du pipeline et <result-name> le nom du résultat.
  • Cette mise à jour prend en charge les besoins en ressources au niveau des tâches pour l'exécution d'une tâche.
  • Avec cette mise à jour, vous n'avez pas besoin de recréer les paramètres qui sont partagés, sur la base de leurs noms, entre un pipeline et les tâches définies. Cette mise à jour fait partie d'une fonctionnalité de l'avant-première pour les développeurs.
  • Cette mise à jour ajoute la prise en charge de la résolution à distance, comme les résolveurs intégrés de git, cluster, bundle et hub.
3.1.4.1.2. Déclencheurs
  • Cette mise à jour ajoute le CRD Interceptor pour définir NamespacedInterceptor. Vous pouvez utiliser NamespacedInterceptor dans la section kind de la référence aux intercepteurs dans les déclencheurs ou dans la spécification EventListener.
  • Cette mise à jour permet à CloudEvents.
  • Avec cette mise à jour, vous pouvez configurer le numéro de port du webhook lors de la définition d'un déclencheur.
  • Cette mise à jour permet d'utiliser le déclencheur eventID comme entrée dans TriggerBinding.
  • Cette mise à jour prend en charge la validation et la rotation des certificats pour le serveur ClusterInterceptor.

    • Les déclencheurs effectuent la validation des certificats pour les intercepteurs principaux et transmettent un nouveau certificat à ClusterInterceptor lorsque son certificat expire.
3.1.4.1.3. CLI
  • Cette mise à jour permet d'afficher les annotations dans la commande describe.
  • Cette mise à jour permet d'afficher le pipeline, les tâches et le délai d'attente dans la commande pr describe.
  • Cette mise à jour ajoute des drapeaux permettant d'indiquer le pipeline, les tâches et le délai d'attente dans la commande pipeline start.
  • Cette mise à jour permet d'indiquer la présence d'un espace de travail, optionnel ou obligatoire, dans la commande describe d'une tâche et d'un pipeline.
  • Cette mise à jour ajoute le drapeau timestamps pour afficher les journaux avec un horodatage.
  • Cette mise à jour ajoute un nouvel indicateur --ignore-running-pipelinerun, qui ignore la suppression de TaskRun associée à PipelineRun.
  • Cette mise à jour ajoute la prise en charge des commandes expérimentales. Cette mise à jour ajoute également des sous-commandes expérimentales, sign et verify à l'outil CLI tkn.
  • Cette mise à jour permet d'utiliser la fonction d'achèvement de l'interpréteur de commandes Z (Zsh) sans générer de fichiers.
  • Cette mise à jour introduit un nouvel outil CLI appelé opc. Il est prévu qu'une prochaine version remplace l'outil CLI tkn par opc.

    Important
    • Le nouvel outil CLI opc est une fonctionnalité de l'aperçu technologique.
    • opc remplacera tkn avec des fonctionnalités supplémentaires spécifiques à Red Hat OpenShift Pipelines, qui ne s'intègrent pas nécessairement dans tkn.
3.1.4.1.4. Opérateur
  • Avec cette mise à jour, Pipelines as Code est installé par défaut. Vous pouvez désactiver Pipelines as Code en utilisant le drapeau -p:

    $ oc patch tektonconfig config --type="merge" -p '{"spec": {"platforms": {"openshift":{"pipelinesAsCode": {"enable": false}}}}}'
  • Avec cette mise à jour, vous pouvez également modifier les configurations de Pipelines as Code dans le CRD TektonConfig.
  • Avec cette mise à jour, si vous désactivez la perspective développeur, l'opérateur n'installe pas les ressources personnalisées liées à la console développeur.
  • Cette mise à jour inclut le support de ClusterTriggerBinding pour Bitbucket Server et Bitbucket Cloud et vous aide à réutiliser un TriggerBinding sur l'ensemble de votre cluster.
3.1.4.1.5. Résolveurs
Important

Resolvers est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

  • Avec cette mise à jour, vous pouvez configurer les résolveurs de pipeline dans le CRD TektonConfig. Vous pouvez activer ou désactiver ces résolveurs de pipeline : enable-bundles-resolver, enable-cluster-resolver, enable-git-resolver, et enable-hub-resolver.

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonConfig
    metadata:
      name: config
    spec:
      pipeline:
        enable-bundles-resolver: true
        enable-cluster-resolver: true
        enable-git-resolver: true
        enable-hub-resolver: true
    ...

    Vous pouvez également fournir des configurations spécifiques au résolveur dans TektonConfig. Par exemple, vous pouvez définir les champs suivants dans le format map[string]string pour définir des configurations pour des résolveurs individuels :

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonConfig
    metadata:
      name: config
    spec:
      pipeline:
        bundles-resolver-config:
          default-service-account: pipelines
        cluster-resolver-config:
          default-namespace: test
        git-resolver-config:
          server-url: localhost.com
        hub-resolver-config:
          default-tekton-hub-catalog: tekton
    ...
3.1.4.1.6. Chaînes Tekton
Important

Tekton Chains est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

  • Avant cette mise à jour, seules les images de l'Open Container Initiative (OCI) étaient prises en charge en tant que sorties de TaskRun dans l'agent de provenance in-toto. Cette mise à jour ajoute les métadonnées de provenance in-toto en tant que sorties avec ces suffixes, ARTIFACT_URI et ARTIFACT_DIGEST.
  • Avant cette mise à jour, seules les attestations TaskRun étaient prises en charge. Cette mise à jour ajoute la prise en charge des attestations PipelineRun.
  • Cette mise à jour ajoute la prise en charge des chaînes Tekton pour obtenir le paramètre imgPullSecret à partir du modèle de pod. Cette mise à jour vous aide à configurer l'authentification du référentiel en fonction de chaque exécution de pipeline ou de tâche sans modifier le compte de service.
3.1.4.1.7. Hub Tekton
Important

Tekton Hub est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

  • Avec cette mise à jour, en tant qu'administrateur, vous pouvez utiliser une base de données externe, telle que Crunchy PostgreSQL avec Tekton Hub, au lieu d'utiliser la base de données par défaut de Tekton Hub. Cette mise à jour vous permet d'effectuer les actions suivantes :

    • Spécifier les coordonnées d'une base de données externe à utiliser avec Tekton Hub
    • Désactiver la base de données Tekton Hub par défaut déployée par l'Opérateur
  • Cette mise à jour supprime la dépendance de config.yaml à l'égard des dépôts Git externes et déplace les données de configuration complètes dans l'API ConfigMap. Cette mise à jour permet à l'administrateur d'effectuer les actions suivantes :

    • Ajoutez les données de configuration, telles que les catégories, les catalogues, les scopes et les defaultScopes dans la ressource personnalisée Tekton Hub.
    • Modifier les données de configuration du Tekton Hub sur le cluster. Toutes les modifications sont conservées lors des mises à jour de l'opérateur.
    • Mettre à jour la liste des catalogues pour Tekton Hub
    • Modifier les catégories pour Tekton Hub

      Note

      Si vous n'ajoutez pas de données de configuration, vous pouvez utiliser les données par défaut de l'API ConfigMap pour les configurations du Tekton Hub.

3.1.4.1.8. Les pipelines en tant que code
  • Cette mise à jour ajoute la prise en charge de la limite de concurrence dans le CRD Repository pour définir le nombre maximum de PipelineRuns en cours d'exécution pour un référentiel à la fois. Les PipelineRuns provenant d'une requête pull ou d'un événement push sont mis en file d'attente dans l'ordre alphabétique.
  • Cette mise à jour ajoute une nouvelle commande tkn pac logs pour afficher les journaux du dernier pipeline exécuté pour un dépôt.
  • Cette mise à jour prend en charge la correspondance d'événement avancée sur le chemin de fichier pour les requêtes push et pull vers GitHub et GitLab. Par exemple, vous pouvez utiliser le langage d'expression commun (CEL) pour lancer un pipeline uniquement si le chemin d'accès d'un fichier markdown dans le répertoire docs a changé.

      ...
      annotations:
         pipelinesascode.tekton.dev/on-cel-expression: |
          event == "pull_request" && "docs/*.md".pathChanged()
  • Avec cette mise à jour, vous pouvez référencer un pipeline distant dans l'objet pipelineRef: à l'aide d'annotations.
  • Avec cette mise à jour, vous pouvez configurer automatiquement de nouveaux dépôts GitHub avec Pipelines as Code, qui met en place un espace de noms et crée un CRD Repository pour votre dépôt GitHub.
  • Avec cette mise à jour, Pipelines as Code génère des métriques pour PipelineRuns avec des informations sur les fournisseurs.
  • Cette mise à jour apporte les améliorations suivantes au plugin tkn-pac:

    • Détecte correctement les pipelines en cours d'exécution
    • Correction de l'affichage de la durée lorsqu'il n'y a pas d'heure d'achèvement de l'échec
    • Affiche un extrait d'erreur et met en évidence le modèle d'expression régulière de l'erreur dans la commande tkn-pac describe
    • Ajoute le commutateur use-real-time aux commandes tkn-pac ls et tkn-pac describe
    • Importe la documentation des journaux de tkn-pac
    • Affiche pipelineruntimeout comme un échec dans les commandes tkn-pac ls et tkn-pac describe.
    • Afficher un échec spécifique de l'exécution d'un pipeline avec l'option --target-pipelinerun.
  • Avec cette mise à jour, vous pouvez voir les erreurs de votre pipeline sous la forme d'un commentaire du système de contrôle de version (VCS) ou d'un petit extrait dans les contrôles GitHub.
  • Avec cette mise à jour, Pipelines as Code peut optionnellement détecter les erreurs dans les tâches si elles sont d'un format simple et ajouter ces tâches en tant qu'annotations dans GitHub. Cette mise à jour fait partie d'un aperçu pour les développeurs.
  • Cette mise à jour ajoute les nouvelles commandes suivantes :

    • tkn-pac webhook add: Ajoute un webhook aux paramètres du référentiel du projet et met à jour la clé webhook.secret dans l'objet k8s Secret existant sans mettre à jour le référentiel.
    • tkn-pac webhook update-token: Met à jour le jeton de fournisseur pour un objet k8s Secret existant sans mettre à jour le référentiel.
  • Cette mise à jour améliore les fonctionnalités de la commande tkn-pac create repo, qui crée et configure des webhooks pour GitHub, GitLab et BitbucketCloud, ainsi que la création de dépôts.
  • Avec cette mise à jour, la commande tkn-pac describe affiche les cinquante derniers événements dans un ordre trié.
  • Cette mise à jour ajoute l'option --last à la commande tkn-pac logs.
  • Avec cette mise à jour, la commande tkn-pac resolve demande un jeton lors de la détection d'un git_auth_secret dans le modèle de fichier.
  • Avec cette mise à jour, Pipelines as Code cache les secrets dans les extraits de journaux pour éviter d'exposer des secrets dans l'interface GitHub.
  • Avec cette mise à jour, les secrets générés automatiquement pour git_auth_secret sont une référence propriétaire avec PipelineRun. Les secrets sont nettoyés en même temps que PipelineRun, et non après l'exécution du pipeline.
  • Cette mise à jour ajoute la possibilité d'annuler l'exécution d'un pipeline à l'aide du commentaire /cancel.
  • Avant cette mise à jour, le champ d'application du jeton GitHub apps n'était pas défini et les jetons étaient utilisés pour chaque installation de référentiel. Avec cette mise à jour, vous pouvez définir la portée du jeton GitHub apps sur le référentiel cible en utilisant les paramètres suivants :

    • secret-github-app-token-scoped: Le jeton d'application est limité au référentiel cible, et non à tous les référentiels auxquels l'installation de l'application a accès.
    • secret-github-app-scope-extra-repos: Personnalise le champ d'application du jeton d'application avec un propriétaire ou un dépôt supplémentaire.
  • Avec cette mise à jour, vous pouvez utiliser Pipelines as Code avec vos propres dépôts Git hébergés sur GitLab.
  • Avec cette mise à jour, vous pouvez accéder aux détails de l'exécution du pipeline sous la forme d'événements kubernetes dans votre espace de noms. Ces détails vous aident à résoudre les erreurs de pipeline sans avoir besoin d'accéder aux espaces de noms des administrateurs.
  • Cette mise à jour supporte l'authentification des URLs dans les Pipelines en tant que résolveur de code avec le fournisseur Git.
  • Avec cette mise à jour, vous pouvez définir le nom du catalogue du concentrateur en utilisant un paramètre dans la carte de configuration pipelines-as-code.
  • Cette mise à jour permet de définir les limites maximales et par défaut du paramètre max-keep-run.
  • Cette mise à jour ajoute des documents sur la façon d'injecter des certificats SSL (Secure Sockets Layer) personnalisés dans Pipelines as Code pour vous permettre de vous connecter à l'instance du fournisseur avec des certificats personnalisés.
  • Avec cette mise à jour, la définition de la ressource PipelineRun comporte l'URL du journal en tant qu'annotation. Par exemple, la commande tkn-pac describe affiche le lien du journal lors de la description d'une ressource PipelineRun.
  • Avec cette mise à jour, les journaux de tkn-pac affichent le nom du dépôt, au lieu du nom de PipelineRun.

3.1.4.2. Changements en cours

  • Avec cette mise à jour, le type de définition de ressource personnalisée (CRD) Conditions a été supprimé. Il est possible d'utiliser le type WhenExpressions à la place.
  • Avec cette mise à jour, la prise en charge des ressources de pipeline de l'API tekton.dev/v1alpha1, telles que Pipeline, PipelineRun, Task, Clustertask et TaskRun, a été supprimée.
  • Avec cette mise à jour, la commande tkn-pac setup a été supprimée. A la place, utilisez la commande tkn-pac webhook add pour ajouter un webhook à un référentiel Git existant. Et utilisez la commande tkn-pac webhook update-token pour mettre à jour le jeton d'accès du fournisseur personnel pour un objet Secret existant dans le référentiel Git.
  • Avec cette mise à jour, un espace de noms qui exécute un pipeline avec les paramètres par défaut n'applique pas le label pod-security.kubernetes.io/enforce:privileged à une charge de travail.

3.1.4.3. Fonctionnalités obsolètes et supprimées

  • Dans la version 1.9.0 de Red Hat OpenShift Pipelines, ClusterTasks est déprécié et il est prévu de le supprimer dans une prochaine version. Comme alternative, vous pouvez utiliser Cluster Resolver.
  • Dans la version 1.9.0 de Red Hat OpenShift Pipelines, l'utilisation des champs triggers et namespaceSelector dans une seule spécification EventListener est dépréciée et il est prévu de la supprimer dans une prochaine version. Vous pouvez utiliser ces champs dans différentes spécifications EventListener avec succès.
  • Dans la version 1.9.0 de Red Hat OpenShift Pipelines, la commande tkn pipelinerun describe n'affiche pas les délais d'attente pour la ressource PipelineRun.
  • Dans la version 1.9.0 de Red Hat OpenShift Pipelines, la ressource personnalisée (CR) PipelineResource` est obsolète. La CR PipelineResource était une fonctionnalité Tech Preview et faisait partie de l'API tekton.dev/v1alpha1.
  • Dans la version 1.9.0 de Red Hat OpenShift Pipelines, les paramètres d'image personnalisée des tâches de cluster sont obsolètes. Comme alternative, vous pouvez copier une tâche de cluster et utiliser votre image personnalisée dans celle-ci.

3.1.4.4. Problèmes connus

  • Les cartes de configuration chains-secret et chains-config sont supprimées après la désinstallation de Red Hat OpenShift Pipelines Operator. Comme elles contiennent des données d'utilisateur, elles doivent être conservées et non supprimées.
  • Lorsque vous exécutez le jeu de commandes tkn pac sous Windows, vous pouvez recevoir le message d'erreur suivant : Command finished with error: not supported by Windows.

    Solution de contournement : Définissez la variable d'environnement NO_COLOR sur true.

  • L'exécution de la commande tkn pac resolve -f <filename> | oc create -f peut ne pas donner les résultats escomptés si la commande tkn pac resolve utilise une valeur de paramètre modélisée pour fonctionner.

    Solution : Pour atténuer ce problème, enregistrez la sortie de tkn pac resolve dans un fichier temporaire en exécutant la commande tkn pac resolve -f <filename> -o tempfile.yaml, puis la commande oc create -f tempfile.yaml. Par exemple, tkn pac resolve -f <filename> -o /tmp/pull-request-resolved.yaml && oc create -f /tmp/pull-request-resolved.yaml.

3.1.4.5. Problèmes corrigés

  • Avant cette mise à jour, après avoir remplacé un tableau vide, le tableau original renvoyait une chaîne vide, ce qui rendait les paramètres qu'il contenait invalides. Avec cette mise à jour, ce problème est résolu et le tableau original retourne une chaîne vide.
  • Avant cette mise à jour, si des secrets en double étaient présents dans un compte de service pour une exécution de pipeline, cela entraînait un échec dans la création du module de tâches. Avec cette mise à jour, ce problème est résolu et le module de tâches est créé avec succès même si des secrets en double sont présents dans un compte de service.
  • Avant cette mise à jour, en consultant le champ spec.StatusMessage du TaskRun, les utilisateurs ne pouvaient pas savoir si le TaskRun avait été annulé par l'utilisateur ou par un PipelineRun qui en faisait partie. Avec cette mise à jour, ce problème est résolu et les utilisateurs peuvent distinguer le statut de TaskRun en regardant le champ spec.StatusMessage de la TaskRun.
  • Avant cette mise à jour, la validation du webhook était supprimée lors de la suppression d'anciennes versions d'objets invalides. Avec cette mise à jour, ce problème est résolu.
  • Avant cette mise à jour, si vous définissiez le paramètre timeouts.pipeline sur 0, vous ne pouviez pas définir les paramètres timeouts.tasks ou timeouts.finally. Cette mise à jour résout le problème. Désormais, lorsque vous définissez la valeur du paramètre timeouts.pipeline, vous pouvez définir la valeur du paramètre "timeouts.tasks" ou du paramètre timeouts.finally. Par exemple :

    yaml
    kind: PipelineRun
    spec:
      timeouts:
        pipeline: "0"  # No timeout
        tasks: "0h3m0s"
  • Avant cette mise à jour, une condition de course pouvait se produire si un autre outil mettait à jour des étiquettes ou des annotations sur un PipelineRun ou un TaskRun. Avec cette mise à jour, ce problème est résolu et vous pouvez fusionner les étiquettes ou les annotations.
  • Avant cette mise à jour, les clés de journal n'avaient pas les mêmes clés que dans les contrôleurs de pipeline. Avec cette mise à jour, ce problème a été résolu et les clés des journaux ont été mises à jour pour correspondre au flux de journaux des contrôleurs de pipeline. Les clés des journaux sont passées de "ts" à "timestamp", de "level" à "severity" et de "message" à "msg".
  • Avant cette mise à jour, si un PipelineRun était supprimé avec un statut inconnu, un message d'erreur n'était pas généré. Avec cette mise à jour, ce problème est résolu et un message d'erreur est généré.
  • Avant cette mise à jour, il était nécessaire d'utiliser le fichier kubeconfig pour accéder aux commandes de l'offre groupée telles que list et push. Avec cette mise à jour, ce problème a été résolu et le fichier kubeconfig n'est plus nécessaire pour accéder aux commandes de l'offre groupée.
  • Avant cette mise à jour, si le PipelineRun parent était en cours d'exécution pendant la suppression des TaskRuns, les TaskRuns étaient supprimées. Avec cette mise à jour, ce problème est résolu et les TaskRuns ne sont pas supprimées si le PipelineRun parent est en cours d'exécution.
  • Avant cette mise à jour, si l'utilisateur tentait de construire une grappe avec plus d'objets que le contrôleur de pipeline ne le permettait, l'interface de programmation Tekton n'affichait pas de message d'erreur. Avec cette mise à jour, ce problème est résolu et la CLI Tekton affiche un message d'erreur si l'utilisateur tente de construire une grappe avec plus d'objets que la limite autorisée dans le contrôleur de pipeline.
  • Avant cette mise à jour, si des espaces de noms étaient supprimés du cluster, l'opérateur ne supprimait pas les espaces de noms des sujets ClusterInterceptor ClusterRoleBinding. Avec cette mise à jour, ce problème a été résolu et l'opérateur supprime les espaces de noms des sujets ClusterInterceptor ClusterRoleBinding.
  • Avant cette mise à jour, l'installation par défaut de Red Hat OpenShift Pipelines Operator avait pour résultat que la ressource de liaison de rôle pipelines-scc-rolebinding security context constraint (SCC) restait dans le cluster. Avec cette mise à jour, l'installation par défaut de Red Hat OpenShift Pipelines Operator entraîne la suppression de la ressource de liaison de rôle pipelines-scc-rolebinding security context constraint (SCC) du cluster.
  • Avant cette mise à jour, Pipelines as Code ne recevait pas les valeurs mises à jour de l'objet Pipelines as Code ConfigMap. Avec cette mise à jour, ce problème est résolu et l'objet Pipelines as Code ConfigMap recherche toute nouvelle modification.
  • Avant cette mise à jour, le contrôleur de Pipelines as Code n'attendait pas que l'étiquette tekton.dev/pipeline soit mise à jour et ajoutait l'étiquette checkrun id, ce qui provoquait des conditions de concurrence. Avec cette mise à jour, le contrôleur de Pipelines as Code attend que l'étiquette tekton.dev/pipeline soit mise à jour et ajoute ensuite l'étiquette checkrun id, ce qui permet d'éviter les problèmes de concurrence.
  • Avant cette mise à jour, la commande tkn-pac create repo ne remplaçait pas une commande PipelineRun si elle existait déjà dans le dépôt git. Avec cette mise à jour, la commande tkn-pac create est corrigée pour remplacer une commande PipelineRun si elle existe dans le dépôt git, ce qui résout le problème avec succès.
  • Avant cette mise à jour, la commande tkn pac describe n'affichait pas les raisons de chaque message. Avec cette mise à jour, ce problème est corrigé et la commande tkn pac describe affiche les motifs pour chaque message.
  • Avant cette mise à jour, une demande d'extraction échouait si l'utilisateur dans l'annotation fournissait des valeurs en utilisant une forme de regex, par exemple, refs/head/rel-*. La demande d'extraction échouait parce qu'il manquait refs/heads dans sa branche de base. Avec cette mise à jour, le préfixe est ajouté et on vérifie qu'il correspond. Cela résout le problème et la demande d'extraction est acceptée.

3.1.4.6. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.9.1

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.9.1 est disponible sur OpenShift Container Platform 4.11 et les versions ultérieures.

3.1.4.7. Problèmes corrigés

  • Avant cette mise à jour, la commande tkn pac repo list ne fonctionnait pas sous Microsoft Windows. Cette mise à jour corrige le problème et vous pouvez désormais exécuter la commande tkn pac repo list sous Microsoft Windows.
  • Avant cette mise à jour, l'observateur de Pipelines as Code ne recevait pas tous les événements de changement de configuration. Avec cette mise à jour, l'observateur de Pipelines as Code a été mis à jour, et maintenant l'observateur de Pipelines as Code ne manque pas les événements de changement de configuration.
  • Avant cette mise à jour, les pods créés par Pipelines as Code, tels que TaskRuns ou PipelineRuns ne pouvaient pas accéder aux certificats personnalisés exposés par l'utilisateur dans le cluster. Cette mise à jour corrige le problème et vous pouvez maintenant accéder aux certificats personnalisés à partir des pods TaskRuns ou PipelineRuns dans le cluster.
  • Avant cette mise à jour, sur un cluster activé avec FIPS, l'intercepteur tekton-triggers-core-interceptors core utilisé dans la ressource Trigger ne fonctionnait pas après que l'opérateur Pipelines ait été mis à niveau vers la version 1.9. Cette mise à jour résout le problème. Désormais, OpenShift utilise MInTLS 1.2 pour tous ses composants. Par conséquent, l'intercepteur central tekton-triggers-core-interceptors est mis à jour vers la version 1.2 de TLS et sa fonctionnalité fonctionne correctement.
  • Avant cette mise à jour, lors de l'utilisation d'un pipeline avec un registre d'images interne à OpenShift, l'URL de l'image devait être codée en dur dans la définition du pipeline. Par exemple, l'URL de l'image devait être codée en dur dans la définition de l'exécution du pipeline :

    ...
      - name: IMAGE_NAME
        value: 'image-registry.openshift-image-registry.svc:5000/<test_namespace>/<test_pipelinerun>'
    ...

    Lors de l'utilisation d'une exécution de pipeline dans le contexte de Pipelines as Code, ces valeurs codées en dur empêchaient les définitions d'exécution de pipeline d'être utilisées dans différents clusters et espaces de noms.

    Avec cette mise à jour, vous pouvez utiliser les variables de modèle dynamiques au lieu de coder en dur les valeurs des espaces de noms et des noms d'exécutions de pipeline pour généraliser les définitions d'exécutions de pipeline. Par exemple :

    ...
      - name: IMAGE_NAME
        value: 'image-registry.openshift-image-registry.svc:5000/{{ target_namespace }}/$(context.pipelineRun.name)'
    ...
  • Avant cette mise à jour, Pipelines as Code utilisait le même jeton GitHub pour récupérer une tâche distante disponible dans le même hôte uniquement sur la branche GitHub par défaut. Cette mise à jour résout le problème. Désormais, Pipelines as Code utilise le même jeton GitHub pour récupérer une tâche distante à partir de n'importe quelle branche GitHub.

3.1.4.8. Problèmes connus

  • La valeur de CATALOG_REFRESH_INTERVAL, un champ de l'objet Hub API ConfigMap utilisé dans le Tekton Hub CR, n'est pas mise à jour avec une valeur personnalisée fournie par l'utilisateur.

    Solution de contournement : Aucune. Vous pouvez suivre le problème SRVKP-2854.

3.1.4.9. Changements en cours

  • Avec cette mise à jour, un problème de mauvaise configuration de l'OLM a été introduit, ce qui empêche la mise à niveau de la plateforme OpenShift Container. Ce problème sera corrigé dans une prochaine version.

3.1.4.10. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.9.2

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.9.2 est disponible sur OpenShift Container Platform 4.11 et les versions ultérieures.

3.1.4.11. Problèmes corrigés

  • Avant cette mise à jour, un problème de mauvaise configuration OLM avait été introduit dans la version précédente, ce qui empêchait la mise à niveau d'OpenShift Container Platform. Avec cette mise à jour, ce problème de mauvaise configuration a été corrigé.

3.1.5. Notes de mise à jour pour Red Hat OpenShift Pipelines General Availability 1.8

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.8 est disponible sur OpenShift Container Platform 4.10, 4.11 et 4.12.

3.1.5.1. Nouvelles fonctionnalités

En plus des corrections et des améliorations de stabilité, les sections suivantes mettent en évidence les nouveautés de Red Hat OpenShift Pipelines 1.8.

3.1.5.1.1. Pipelines
  • Avec cette mise à jour, vous pouvez exécuter Red Hat OpenShift Pipelines GA 1.8 et plus sur un cluster OpenShift Container Platform qui fonctionne sur du matériel ARM. Cela inclut la prise en charge des ressources ClusterTask et de l'outil CLI tkn.
Important

L'exécution de Red Hat OpenShift Pipelines sur du matériel ARM est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

  • Cette mise à jour met en œuvre les dérogations Step et Sidecar pour les ressources TaskRun.
  • Cette mise à jour ajoute les statuts minimaux TaskRun et Run dans les statuts PipelineRun.

    Pour activer cette fonctionnalité, dans la définition de la ressource personnalisée TektonConfig, dans la section pipeline, vous devez définir le champ enable-api-fields sur alpha.

  • Avec cette mise à jour, la fonctionnalité d'arrêt gracieux des exécutions de pipeline passe d'une fonctionnalité alpha à une fonctionnalité stable. Par conséquent, le statut PipelineRunCancelled, précédemment déprécié, reste déprécié et devrait être supprimé dans une prochaine version.

    Cette fonctionnalité étant disponible par défaut, il n'est plus nécessaire de donner au champ pipeline.enable-api-fields la valeur alpha dans la définition de la ressource personnalisée TektonConfig.

  • Avec cette mise à jour, vous pouvez spécifier l'espace de travail pour une tâche de pipeline en utilisant le nom de l'espace de travail. Cette modification facilite la spécification d'un espace de travail partagé pour une paire de ressources Pipeline et PipelineTask. Vous pouvez également continuer à mapper les espaces de travail de manière explicite.

    Pour activer cette fonctionnalité, dans la définition de la ressource personnalisée TektonConfig, dans la section pipeline, vous devez définir le champ enable-api-fields sur alpha.

  • Avec cette mise à jour, les paramètres des spécifications intégrées sont propagés sans mutations.
  • Avec cette mise à jour, vous pouvez spécifier les métadonnées requises d'une ressource Task référencée par une ressource PipelineRun en utilisant des annotations et des étiquettes. Ainsi, les métadonnées de Task qui dépendent du contexte d'exécution sont disponibles pendant l'exécution du pipeline.
  • Cette mise à jour ajoute la prise en charge des types d'objets ou de dictionnaires dans les valeurs params et results. Cette modification affecte la compatibilité ascendante et rompt parfois la compatibilité descendante, comme l'utilisation d'un client antérieur avec une version plus récente de Red Hat OpenShift Pipelines. Cette mise à jour modifie la structure de ArrayOrStruct, ce qui affecte les projets qui utilisent l'API du langage Go en tant que bibliothèque.
  • Cette mise à jour ajoute une valeur SkippingReason au champ SkippedTasks des champs de statut PipelineRun afin que les utilisateurs sachent pourquoi une tâche de pipeline donnée a été ignorée.
  • Cette mise à jour prend en charge une fonctionnalité alpha qui permet d'utiliser un type array pour émettre des résultats à partir d'un objet Task. Le type de résultat passe de string à ArrayOrString. Par exemple, une tâche peut spécifier un type pour produire un résultat sous forme de tableau :

    kind: Task
    apiVersion: tekton.dev/v1beta1
    metadata:
      name: write-array
      annotations:
        description: |
          A simple task that writes array
    spec:
      results:
        - name: array-results
          type: array
          description: The array results
    ...

    En outre, vous pouvez exécuter un script de tâche pour remplir les résultats avec un tableau :

    $ echo -n "[\"hello\",\"world\"]" | tee $(results.array-results.path)

    Pour activer cette fonctionnalité, dans la définition de la ressource personnalisée TektonConfig, dans la section pipeline, vous devez définir le champ enable-api-fields sur alpha.

    Cette fonctionnalité est en cours de réalisation et fait partie du TEP-0076.

3.1.5.1.2. Déclencheurs
  • Cette mise à jour fait passer le champ TriggerGroups de la spécification EventListener d'une fonctionnalité alpha à une fonctionnalité stable. Ce champ permet de spécifier un ensemble d'intercepteurs avant de sélectionner et d'exécuter un groupe de déclencheurs.

    Cette fonctionnalité étant disponible par défaut, il n'est plus nécessaire de donner au champ pipeline.enable-api-fields la valeur alpha dans la définition de la ressource personnalisée TektonConfig.

  • Avec cette mise à jour, la ressource Trigger prend en charge les connexions sécurisées de bout en bout en exécutant le serveur ClusterInterceptor à l'aide de HTTPS.
3.1.5.1.3. CLI
  • Avec cette mise à jour, vous pouvez utiliser la commande tkn taskrun export pour exporter une exécution de tâche en direct d'un cluster vers un fichier YAML, que vous pouvez utiliser pour importer l'exécution de tâche vers un autre cluster.
  • Avec cette mise à jour, vous pouvez ajouter l'option -o name à la commande tkn pipeline start afin d'afficher le nom de l'exécution du pipeline dès son démarrage.
  • Cette mise à jour ajoute une liste des plugins disponibles à la sortie de la commande tkn --help.
  • Avec cette mise à jour, lors de la suppression d'un pipeline ou d'une tâche, vous pouvez utiliser à la fois les drapeaux --keep et --keep-since.
  • Avec cette mise à jour, vous pouvez utiliser Cancelled comme valeur du champ spec.status plutôt que la valeur obsolète PipelineRunCancelled.
3.1.5.1.4. Opérateur
  • Avec cette mise à jour, en tant qu'administrateur, vous pouvez configurer votre instance locale de Tekton Hub pour qu'elle utilise une base de données personnalisée plutôt que la base de données par défaut.
  • Avec cette mise à jour, en tant qu'administrateur de cluster, si vous activez votre instance locale de Tekton Hub, celle-ci rafraîchit périodiquement la base de données afin que les changements dans le catalogue apparaissent dans la console web de Tekton Hub. Vous pouvez ajuster la période entre les rafraîchissements.

    Auparavant, pour ajouter les tâches et les pipelines du catalogue à la base de données, vous deviez effectuer cette tâche manuellement ou configurer un travail cron pour le faire à votre place.

  • Avec cette mise à jour, vous pouvez installer et faire fonctionner une instance de Tekton Hub avec une configuration minimale. De cette façon, vous pouvez commencer à travailler avec vos équipes pour décider des personnalisations supplémentaires qu'elles pourraient souhaiter.
  • Cette mise à jour ajoute GIT_SSL_CAINFO à la tâche git-clone afin que vous puissiez cloner des dépôts sécurisés.
3.1.5.1.5. Chaînes Tekton
Important

Tekton Chains est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

  • Avec cette mise à jour, vous pouvez vous connecter à un coffre-fort en utilisant OIDC plutôt qu'un jeton statique. Cette modification signifie que Spire peut générer l'identifiant OIDC afin que seules les charges de travail de confiance soient autorisées à se connecter à l'espace de stockage. En outre, vous pouvez transmettre l'adresse de l'espace de stockage en tant que valeur de configuration plutôt que de l'injecter en tant que variable d'environnement.
  • La carte de configuration chains-config pour Tekton Chains dans l'espace de noms openshift-pipelines est automatiquement réinitialisée par défaut après la mise à jour de Red Hat OpenShift Pipelines Operator car la mise à jour directe de la carte de configuration n'est pas prise en charge lors de l'installation à l'aide de Red Hat OpenShift Pipelines Operator. Cependant, avec cette mise à jour, vous pouvez configurer les chaînes Tekton en utilisant la ressource personnalisée TektonChain. Cette fonctionnalité permet à votre configuration de persister après la mise à jour, contrairement à la carte de configuration chains-config, qui est écrasée lors des mises à jour.
3.1.5.1.6. Hub Tekton
Important

Tekton Hub est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

  • Avec cette mise à jour, si vous installez une nouvelle instance de Tekton Hub en utilisant l'Opérateur, le login Tekton Hub est désactivé par défaut. Pour activer les fonctions de connexion et de notation, vous devez créer le secret API Hub lors de l'installation de Tekton Hub.

    Note

    Étant donné que la connexion Tekton Hub était activée par défaut dans Red Hat OpenShift Pipelines 1.7, si vous mettez à niveau l'opérateur, la connexion est activée par défaut dans Red Hat OpenShift Pipelines 1.8. Pour désactiver cette connexion, voir Désactivation de la connexion Tekton Hub après la mise à niveau d'OpenShift Pipelines 1.7.x -→ 1.8.x

  • Avec cette mise à jour, en tant qu'administrateur, vous pouvez configurer votre instance locale de Tekton Hub pour utiliser une base de données PostgreSQL 13 personnalisée plutôt que la base de données par défaut. Pour ce faire, créez une ressource Secret nommée tekton-hub-db. Par exemple :

    apiVersion: v1
    kind: Secret
    metadata:
      name: tekton-hub-db
      labels:
        app: tekton-hub-db
    type: Opaque
    stringData:
      POSTGRES_HOST: <hostname>
      POSTGRES_DB: <database_name>
      POSTGRES_USER: <user_name>
      POSTGRES_PASSWORD: <user_password>
      POSTGRES_PORT: <listening_port_number>
  • Avec cette mise à jour, vous n'avez plus besoin de vous connecter à la console web Tekton Hub pour ajouter des ressources du catalogue à la base de données. Désormais, ces ressources sont automatiquement ajoutées lorsque l'API Tekton Hub est lancée pour la première fois.
  • Cette mise à jour actualise automatiquement le catalogue toutes les 30 minutes en appelant le job API d'actualisation du catalogue. Cet intervalle est configurable par l'utilisateur.
3.1.5.1.7. Les pipelines en tant que code
Important

Pipelines as Code (PAC) est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

  • Avec cette mise à jour, en tant que développeur, vous recevez une notification de l'outil CLI tkn-pac si vous essayez d'ajouter un référentiel dupliqué à une exécution de Pipelines as Code. Lorsque vous entrez tkn pac create repository, chaque référentiel doit avoir une URL unique. Cette notification permet également d'éviter les exploits de détournement.
  • Avec cette mise à jour, en tant que développeur, vous pouvez utiliser la nouvelle commande tkn-pac setup cli pour ajouter un dépôt Git à Pipelines as Code en utilisant le mécanisme de webhook. Ainsi, vous pouvez utiliser Pipelines as Code même lorsque l'utilisation de GitHub Apps n'est pas possible. Cette fonctionnalité inclut la prise en charge des dépôts sur GitHub, GitLab et BitBucket.
  • Avec cette mise à jour, Pipelines as Code prend en charge l'intégration de GitLab avec des fonctionnalités telles que les suivantes :

    • ACL (Access Control List) sur le projet ou le groupe
    • /ok-to-test le soutien des utilisateurs autorisés
    • /retest le soutien.
  • Avec cette mise à jour, vous pouvez effectuer un filtrage avancé des pipelines avec le langage d'expression commun (CEL). Avec CEL, vous pouvez faire correspondre des exécutions de pipeline avec différents événements du fournisseur Git en utilisant des annotations dans la ressource PipelineRun. Par exemple :

      ...
      annotations:
         pipelinesascode.tekton.dev/on-cel-expression: |
          event == "pull_request" && target_branch == "main" && source_branch == "wip"
  • Auparavant, en tant que développeur, vous ne pouviez avoir qu'une seule exécution de pipeline dans votre répertoire .tekton pour chaque événement Git, tel qu'une pull request. Avec cette mise à jour, vous pouvez avoir plusieurs exécutions de pipeline dans votre répertoire .tekton. La console web affiche l'état et les rapports des exécutions. Les exécutions de pipeline fonctionnent en parallèle et renvoient des rapports à l'interface du fournisseur Git.
  • Avec cette mise à jour, vous pouvez tester ou retester un pipeline en commentant /test ou /retest sur une pull request. Vous pouvez également spécifier le pipeline par son nom. Par exemple, vous pouvez saisir /test <pipelinerun_name> ou /retest <pipelinerun-name>.
  • Avec cette mise à jour, vous pouvez supprimer une ressource personnalisée du référentiel et ses secrets associés en utilisant la nouvelle commande tkn-pac delete repository.

3.1.5.2. Changements en cours

  • Cette mise à jour modifie le niveau de métrique par défaut des ressources TaskRun et PipelineRun pour les valeurs suivantes :

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: config-observability
      namespace: tekton-pipelines
      labels:
        app.kubernetes.io/instance: default
        app.kubernetes.io/part-of: tekton-pipelines
    data:
      _example: |
      ...
        metrics.taskrun.level: "task"
        metrics.taskrun.duration-type: "histogram"
        metrics.pipelinerun.level: "pipeline"
        metrics.pipelinerun.duration-type: "histogram"
  • Avec cette mise à jour, si une annotation ou un label est présent à la fois dans les ressources Pipeline et PipelineRun, la valeur du type Run est prioritaire. Il en va de même si une annotation ou un label est présent dans les ressources Task et TaskRun.
  • Dans Red Hat OpenShift Pipelines 1.8, le champ PipelineRun.Spec.ServiceAccountNames, précédemment déprécié, a été supprimé. Utilisez le champ PipelineRun.Spec.TaskRunSpecs à la place.
  • Dans Red Hat OpenShift Pipelines 1.8, le champ TaskRun.Status.ResourceResults.ResourceRef, précédemment déprécié, a été supprimé. Utilisez le champ TaskRun.Status.ResourceResults.ResourceName à la place.
  • Dans Red Hat OpenShift Pipelines 1.8, le type de ressource Conditions, précédemment déprécié, a été supprimé. Supprimez la ressource Conditions des définitions de ressources Pipeline qui l'incluent. Utilisez les expressions when dans les définitions PipelineRun à la place.
  • Pour les chaînes Tekton, le format tekton-provenance a été supprimé dans cette version. Utilisez plutôt le format in-toto en définissant "artifacts.taskrun.format": "in-toto" dans la ressource personnalisée TektonChain.
  • Red Hat OpenShift Pipelines 1.7.x était livré avec Pipelines as Code 0.5.x. La mise à jour actuelle est livrée avec Pipelines as Code 0.10.x. Ce changement crée une nouvelle route dans l'espace de noms openshift-pipelines pour le nouveau contrôleur. Vous devez mettre à jour cette route dans les applications GitHub ou les webhooks qui utilisent Pipelines as Code. Pour récupérer la route, utilisez la commande suivante :

    $ oc get route -n openshift-pipelines pipelines-as-code-controller \
      --template='https://{{ .spec.host }}'
  • Avec cette mise à jour, Pipelines as Code renomme les clés secrètes par défaut pour la définition de ressource personnalisée (CRD) Repository. Dans votre CRD, remplacez token par provider.token, et remplacez secret par webhook.secret.
  • Avec cette mise à jour, Pipelines as Code remplace une variable de modèle spéciale par une variable qui prend en charge des exécutions de pipeline multiples pour des dépôts privés. Dans vos exécutions du pipeline, remplacez secret: pac-git-basic-auth-{{repo_owner}}-{{repo_name}} par secret: {{ git_auth_secret }}.
  • Avec cette mise à jour, Pipelines as Code met à jour les commandes suivantes dans l'outil CLI tkn-pac:

    • Remplacer tkn pac repository create par tkn pac create repository.
    • Remplacer tkn pac repository delete par tkn pac delete repository.
    • Remplacer tkn pac repository list par tkn pac list.

3.1.5.3. Fonctionnalités obsolètes et supprimées

  • À partir d'OpenShift Container Platform 4.11, les canaux preview et stable pour l'installation et la mise à jour de Red Hat OpenShift Pipelines Operator sont supprimés. Pour installer et mettre à niveau l'opérateur, utilisez le canal pipelines-<version> approprié ou le canal latest pour la version stable la plus récente. Par exemple, pour installer la version 1.8.x d'OpenShift Pipelines Operator, utilisez le canal pipelines-1.8.

    Note

    Dans OpenShift Container Platform 4.10 et les versions antérieures, vous pouvez utiliser les canaux preview et stable pour installer et mettre à niveau l'opérateur.

  • La prise en charge de la version de l'API tekton.dev/v1alpha1, qui était obsolète dans Red Hat OpenShift Pipelines GA 1.6, devrait être supprimée dans la prochaine version Red Hat OpenShift Pipelines GA 1.9.

    Ce changement affecte le composant pipeline, qui comprend les ressources TaskRun, PipelineRun, Task, Pipeline, et les ressources similaires tekton.dev/v1alpha1. Comme alternative, mettez à jour les ressources existantes pour utiliser apiVersion: tekton.dev/v1beta1 comme décrit dans Migrating From Tekton v1alpha1 to Tekton v1beta1.

    Les corrections de bogues et l'assistance pour la version de l'API tekton.dev/v1alpha1 ne sont fournies que jusqu'à la fin du cycle de vie actuel de l'AG 1.8.

    Important

    Pour Tekton Operator, la version de l'API operator.tekton.dev/v1alpha1 est not deprecated. Il n'est pas nécessaire de modifier cette valeur.

  • Dans Red Hat OpenShift Pipelines 1.8, la ressource personnalisée (CR) PipelineResource est disponible mais n'est plus prise en charge. La CR PipelineResource était une fonctionnalité Tech Preview et faisait partie de l'API tekton.dev/v1alpha1, qui a été dépréciée et qu'il est prévu de supprimer dans la prochaine version Red Hat OpenShift Pipelines GA 1.9.
  • Dans Red Hat OpenShift Pipelines 1.8, la ressource personnalisée (CR) Condition est supprimée. La CR Condition faisait partie de l'API tekton.dev/v1alpha1, qui a été dépréciée et devrait être supprimée dans la prochaine version de Red Hat OpenShift Pipelines GA 1.9.
  • Dans Red Hat OpenShift Pipelines 1.8, l'image gcr.io pour gsutil a été supprimée. Cette suppression pourrait interrompre les clusters avec les ressources Pipeline qui dépendent de cette image. Les corrections de bugs et l'assistance sont fournies uniquement jusqu'à la fin du cycle de vie de Red Hat OpenShift Pipelines 1.7.
  • Dans Red Hat OpenShift Pipelines 1.8, les champs PipelineRun.Status.TaskRuns et PipelineRun.Status.Runs sont dépréciés et devraient être supprimés dans une prochaine version. Voir TEP-0100 : Embedded TaskRuns and Runs Status in PipelineRuns.
  • Dans Red Hat OpenShift Pipelines 1.8, l'état pipelineRunCancelled est déprécié et il est prévu de le supprimer dans une prochaine version. La terminaison gracieuse des objets PipelineRun est maintenant promue d'une fonctionnalité alpha à une fonctionnalité stable (voir TEP-0058 : Terminaison gracieuse de l'exécution du pipeline). (Voir TEP-0058 : Graceful Pipeline Run Termination.) Comme alternative, vous pouvez utiliser l'état Cancelled, qui remplace l'état pipelineRunCancelled.

    Vous n'avez pas besoin de modifier vos ressources Pipeline et Task. Si vous avez des outils qui annulent les exécutions de pipeline, vous devez les mettre à jour dans la prochaine version. Ce changement affecte également les outils tels que le CLI, les extensions de l'IDE, etc., afin qu'ils prennent en charge les nouveaux statuts PipelineRun.

    Cette fonctionnalité étant disponible par défaut, il n'est plus nécessaire de donner au champ pipeline.enable-api-fields la valeur alpha dans la définition de la ressource personnalisée TektonConfig.

  • Dans Red Hat OpenShift Pipelines 1.8, le champ timeout dans PipelineRun a été déprécié. À la place, utilisez le champ PipelineRun.Timeouts, qui est maintenant passé d'une fonctionnalité alpha à une fonctionnalité stable.

    Cette fonctionnalité étant disponible par défaut, il n'est plus nécessaire de donner au champ pipeline.enable-api-fields la valeur alpha dans la définition de la ressource personnalisée TektonConfig.

  • Dans Red Hat OpenShift Pipelines 1.8, les conteneurs init sont omis des calculs de demande par défaut de l'objet LimitRange.

3.1.5.4. Problèmes connus

  • Le pipeline s2i-nodejs ne peut pas utiliser le flux d'images nodejs:14-ubi8-minimal pour effectuer des constructions source-image (S2I). L'utilisation de ce flux d'images produit un message error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127.

    Solution de contournement : Utilisez nodejs:14-ubi8 plutôt que le flux d'images nodejs:14-ubi8-minimal.

  • Lorsque vous exécutez des tâches de cluster Maven et Jib-Maven, l'image de conteneur par défaut n'est prise en charge que sur l'architecture Intel (x86). Par conséquent, les tâches échoueront sur les clusters ARM, IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x).

    Solution de contournement : Spécifiez une image personnalisée en définissant la valeur du paramètre MAVEN_IMAGE sur maven:3.6.3-adoptopenjdk-11.

    Astuce

    Avant d'installer des tâches basées sur le catalogue Tekton sur ARM, IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x) en utilisant tkn hub, vérifiez si la tâche peut être exécutée sur ces plates-formes. Pour vérifier si ppc64le et s390x sont répertoriés dans la section "Platforms" des informations sur la tâche, vous pouvez exécuter la commande suivante : tkn hub info task <name>

  • Sur ARM, IBM Power Systems, IBM Z et LinuxONE, la tâche s2i-dotnet cluster n'est pas prise en charge.
  • Le mappage implicite des paramètres transmet incorrectement les paramètres des définitions de premier niveau Pipeline ou PipelineRun aux tâches taskRef. Le mappage ne doit se faire qu'à partir d'une ressource de premier niveau vers des tâches avec des spécifications en ligne taskSpec. Ce problème n'affecte que les clusters où cette fonctionnalité a été activée en définissant le champ enable-api-fields sur alpha dans la section pipeline de la définition de la ressource personnalisée TektonConfig.

3.1.5.5. Problèmes corrigés

  • Avant cette mise à jour, les métriques pour les exécutions de pipeline dans la vue Développeur de la console web étaient incomplètes et obsolètes. Avec cette mise à jour, le problème a été corrigé de sorte que les métriques sont correctes.
  • Avant cette mise à jour, si un pipeline avait deux tâches parallèles qui échouaient et que l'une d'entre elles avait retries=2, les tâches finales ne s'exécutaient jamais, et le pipeline s'arrêtait et ne s'exécutait pas. Par exemple, la tâche pipelines-operator-subscription échouait par intermittence avec le message d'erreur suivant : Unable to connect to the server: EOF. Avec cette mise à jour, le problème a été corrigé de sorte que les tâches finales s'exécutent toujours.
  • Avant cette mise à jour, si l'exécution d'un pipeline s'arrêtait en raison de l'échec d'une tâche, les autres tâches risquaient de ne pas être relancées. Par conséquent, aucune tâche finally n'était programmée, ce qui entraînait un blocage du pipeline. Cette mise à jour résout le problème. Les objets TaskRuns et Run peuvent réessayer lorsqu'une exécution du pipeline s'est arrêtée, même par arrêt gracieux, afin que les exécutions du pipeline puissent se terminer.
  • Cette mise à jour modifie la façon dont les besoins en ressources sont calculés lorsqu'un ou plusieurs objets LimitRange sont présents dans l'espace de noms où un objet TaskRun existe. Le planificateur prend désormais en compte les conteneurs step et exclut tous les autres conteneurs d'applications, tels que les conteneurs sidecar, lors de la prise en compte des demandes provenant d'objets LimitRange.
  • Avant cette mise à jour, dans certaines conditions, le paquetage flag pouvait analyser incorrectement une sous-commande suivant immédiatement un double tiret de terminaison de drapeau, --. Dans ce cas, il exécutait la sous-commande du point d'entrée plutôt que la commande réelle. Cette mise à jour corrige ce problème d'analyse des drapeaux afin que le point d'entrée exécute la commande correcte.
  • Avant cette mise à jour, le contrôleur pouvait générer plusieurs paniques si l'extraction d'une image échouait ou si son statut d'extraction était incomplet. Cette mise à jour corrige le problème en vérifiant la valeur step.ImageID plutôt que la valeur status.TaskSpec.
  • Avant cette mise à jour, l'annulation d'une exécution de pipeline contenant une tâche personnalisée non planifiée produisait une erreur PipelineRunCouldntCancel. Cette mise à jour corrige ce problème. Vous pouvez annuler une exécution de pipeline contenant une tâche personnalisée non planifiée sans produire cette erreur.
  • Avant cette mise à jour, si le <NAME> dans $params["<NAME>"] ou $params['<NAME>'] contenait un point (.), toute partie du nom à droite du point n'était pas extraite. Par exemple, à partir de $params["org.ipsum.lorem"], seul org était extrait.

    Cette mise à jour corrige le problème de sorte que $params récupère la valeur complète. Par exemple, $params["org.ipsum.lorem"] et $params['org.ipsum.lorem'] sont valides et la valeur complète de <NAME>, org.ipsum.lorem, est extraite.

    Il génère également une erreur si <NAME> n'est pas entouré de guillemets simples ou doubles. Par exemple, $params.org.ipsum.lorem n'est pas valide et génère une erreur de validation.

  • Avec cette mise à jour, les ressources Trigger prennent en charge les intercepteurs personnalisés et garantissent que le port du service d'interception personnalisé est le même que celui du fichier de définition ClusterInterceptor.
  • Avant cette mise à jour, la commande tkn version pour les chaînes Tekton et les composants Operator ne fonctionnait pas correctement. Cette mise à jour corrige le problème de sorte que la commande fonctionne correctement et renvoie des informations sur la version de ces composants.
  • Avant cette mise à jour, si vous exécutiez une commande tkn pr delete --ignore-running et qu'un pipeline n'avait pas de valeur status.condition, l'outil CLI tkn générait une erreur de pointeur nul (NPE). Cette mise à jour corrige le problème de sorte que l'outil CLI génère désormais une erreur et ignore correctement les exécutions de pipeline qui sont toujours en cours.
  • Avant cette mise à jour, si vous utilisiez les commandes tkn pr delete --keep <value> ou tkn tr delete --keep <value> et que le nombre d'exécutions de pipeline ou de tâches était inférieur à la valeur, la commande ne renvoyait pas d'erreur comme prévu. Cette mise à jour corrige le problème de sorte que la commande renvoie correctement une erreur dans ces conditions.
  • Avant cette mise à jour, si vous utilisiez les commandes tkn pr delete ou tkn tr delete avec les drapeaux -p ou -t et le drapeau --ignore-running, les commandes supprimaient incorrectement les ressources en cours d'exécution ou en attente. Cette mise à jour corrige le problème de sorte que ces commandes ignorent correctement les ressources en cours d'exécution ou en attente.
  • Avec cette mise à jour, vous pouvez configurer les chaînes Tekton en utilisant la ressource personnalisée TektonChain. Cette fonctionnalité permet à votre configuration de persister après la mise à jour, contrairement à la carte de configuration chains-config, qui est écrasée lors des mises à jour.
  • Avec cette mise à jour, les ressources ClusterTask ne s'exécutent plus en tant que root par défaut, à l'exception des tâches de cluster buildah et s2i.
  • Avant cette mise à jour, les tâches sur Red Hat OpenShift Pipelines 1.7.1 échouaient lors de l'utilisation de init comme premier argument suivi de deux arguments ou plus. Avec cette mise à jour, les drapeaux sont analysés correctement, et les exécutions de tâches sont réussies.
  • Avant cette mise à jour, l'installation de Red Hat OpenShift Pipelines Operator sur OpenShift Container Platform 4.9 et 4.10 échouait en raison d'une liaison de rôle non valide, avec le message d'erreur suivant :

    error updating rolebinding openshift-operators-prometheus-k8s-read-binding: RoleBinding.rbac.authorization.k8s.io
    "openshift-operators-prometheus-k8s-read-binding" is invalid:
    roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"openshift-operator-read"}: cannot change roleRef

    Cette mise à jour corrige le problème de sorte que l'échec ne se produise plus.

  • Auparavant, la mise à niveau de Red Hat OpenShift Pipelines Operator entraînait la recréation du compte de service pipeline, ce qui signifiait que les secrets liés au compte de service étaient perdus. Cette mise à jour corrige ce problème. Lors des mises à niveau, l'Opérateur ne recrée plus le compte de service pipeline. Par conséquent, les secrets liés au compte de service pipeline persistent après les mises à niveau, et les ressources (tâches et pipelines) continuent de fonctionner correctement.
  • Avec cette mise à jour, les pods Pipelines as Code s'exécutent sur les nœuds d'infrastructure si les paramètres du nœud d'infrastructure sont configurés dans la ressource personnalisée (CR) TektonConfig.
  • Auparavant, avec l'élagueur de ressources, chaque opérateur d'espace de noms créait une commande qui s'exécutait dans un conteneur distinct. Cette conception consommait trop de ressources dans les grappes comportant un grand nombre d'espaces de noms. Par exemple, pour exécuter une seule commande, une grappe de 1000 espaces de noms produisait 1000 conteneurs dans un pod.

    Cette mise à jour corrige le problème. Elle transmet la configuration basée sur l'espace de noms à la tâche afin que toutes les commandes s'exécutent en boucle dans un conteneur.

  • Dans Tekton Chains, vous devez définir un secret appelé signing-secrets pour contenir la clé utilisée pour signer les tâches et les images. Cependant, avant cette mise à jour, la mise à jour de Red Hat OpenShift Pipelines Operator réinitialisait ou écrasait ce secret, et la clé était perdue. Cette mise à jour corrige ce problème. Désormais, si le secret est configuré après l'installation de Tekton Chains via l'Opérateur, le secret persiste et n'est pas écrasé par les mises à jour.
  • Avant cette mise à jour, toutes les tâches de construction de S2I échouaient avec une erreur similaire au message suivant :

    Error: error writing "0 0 4294967295\n" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted
    time="2022-03-04T09:47:57Z" level=error msg="error writing \"0 0 4294967295\\n\" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted"
    time="2022-03-04T09:47:57Z" level=error msg="(unable to determine exit status)"

    Avec cette mise à jour, la contrainte de contexte de sécurité (SCC) de pipelines-scc est compatible avec la capacité de SETFCAP nécessaire pour les tâches de cluster de Buildah et S2I. Par conséquent, les tâches de construction Buildah et S2I peuvent être exécutées avec succès.

    Pour exécuter avec succès la tâche de cluster Buildah et les tâches de construction S2I pour les applications écrites dans différents langages et frameworks, ajoutez l'extrait suivant pour les objets steps appropriés tels que build et push:

    securityContext:
      capabilities:
        add: ["SETFCAP"]
  • Avant cette mise à jour, l'installation de Red Hat OpenShift Pipelines Operator prenait plus de temps que prévu. Cette mise à jour optimise certains paramètres afin d'accélérer le processus d'installation.
  • Avec cette mise à jour, les tâches des clusters Buildah et S2I comportent moins d'étapes que dans les versions précédentes. Certaines étapes ont été regroupées en une seule afin de mieux fonctionner avec les objets ResourceQuota et LimitRange et de ne pas nécessiter plus de ressources que nécessaire.
  • Cette mise à jour met à jour les versions de Buildah, de l'outil CLI tkn et de l'outil CLI skopeo dans les tâches en grappe.
  • Avant cette mise à jour, l'opérateur échouait lors de la création de ressources RBAC si un espace de noms était dans l'état Terminating. Avec cette mise à jour, l'opérateur ignore les espaces de noms dans l'état Terminating et crée les ressources RBAC.
  • Avant cette mise à jour, les pods pour les cronjobs prune n'étaient pas planifiés sur les nœuds d'infrastructure, comme prévu. Au lieu de cela, ils étaient planifiés sur les nœuds de travail ou n'étaient pas planifiés du tout. Avec cette mise à jour, ces types de pods peuvent désormais être planifiés sur les nœuds d'infrastructure s'ils sont configurés dans la ressource personnalisée (CR) TektonConfig.

3.1.5.6. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.8.1

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.8.1 est disponible sur OpenShift Container Platform 4.10, 4.11 et 4.12.

3.1.5.6.1. Problèmes connus
  • Par défaut, les conteneurs ont des permissions restreintes pour une sécurité accrue. Les permissions restreintes s'appliquent à tous les pods contrôleurs dans l'Opérateur Red Hat OpenShift Pipelines, ainsi qu'à certaines tâches de cluster. En raison des permissions restreintes, la tâche de cluster git-clone échoue dans certaines configurations.

    Solution de contournement : Aucune. Vous pouvez suivre le problème SRVKP-2634.

  • Lorsque les ensembles d'installation sont dans un état d'échec, l'état de la ressource personnalisée TektonConfig est incorrectement affiché comme True au lieu de False.

    Exemple : Échec de l'installation des jeux

    $ oc get tektoninstallerset
    NAME                                     READY   REASON
    addon-clustertasks-nx5xz                 False   Error
    addon-communityclustertasks-cfb2p        True
    addon-consolecli-ftrb8                   True
    addon-openshift-67dj2                    True
    addon-pac-cf7pz                          True
    addon-pipelines-fvllm                    True
    addon-triggers-b2wtt                     True
    addon-versioned-clustertasks-1-8-hqhnw   False   Error
    pipeline-w75ww                           True
    postpipeline-lrs22                       True
    prepipeline-ldlhw                        True
    rhosp-rbac-4dmgb                         True
    trigger-hfg64                            True
    validating-mutating-webhoook-28rf7       True

    Exemple : Statut incorrect TektonConfig

    $ oc get tektonconfig config
    NAME     VERSION   READY   REASON
    config   1.8.1     True

3.1.5.6.2. Problèmes corrigés
  • Avant cette mise à jour, l'élagueur supprimait les tâches des pipelines en cours d'exécution et affichait l'avertissement suivant : some tasks were indicated completed without ancestors being done. Avec cette mise à jour, l'élagueur conserve les tâches qui font partie des pipelines en cours d'exécution.
  • Avant cette mise à jour, pipeline-1.8 était le canal par défaut pour l'installation de Red Hat OpenShift Pipelines Operator 1.8.x. Avec cette mise à jour, latest est le canal par défaut.
  • Avant cette mise à jour, les pods contrôleurs de Pipelines as Code n'avaient pas accès aux certificats exposés par l'utilisateur. Avec cette mise à jour, Pipelines as Code peut désormais accéder aux routes et aux dépôts Git protégés par un certificat auto-signé ou personnalisé.
  • Avant cette mise à jour, la tâche échouait avec des erreurs RBAC après la mise à niveau de Red Hat OpenShift Pipelines 1.7.2 à 1.8.0. Avec cette mise à jour, les tâches s'exécutent avec succès sans aucune erreur RBAC.
  • Avant cette mise à jour, à l'aide de l'outil CLI tkn, vous ne pouviez pas supprimer les exécutions de tâches et les exécutions de pipeline qui contenaient un objet result dont le type était array. Avec cette mise à jour, vous pouvez utiliser l'outil CLI tkn pour supprimer les exécutions de tâches et les exécutions de pipeline qui contiennent un objet result dont le type est array.
  • Avant cette mise à jour, si une spécification de pipeline contenait une tâche avec un paramètre ENV_VARS de type array, l'exécution du pipeline échouait avec l'erreur suivante : invalid input params for task func-buildpacks: param types don’t match the user-specified type: [ENV_VARS]. Avec cette mise à jour, les exécutions de pipeline avec de telles spécifications de pipeline et de tâche n'échouent pas.
  • Avant cette mise à jour, les administrateurs de grappes ne pouvaient pas fournir de fichier config.json à la tâche de grappe Buildah pour accéder à un registre de conteneurs. Avec cette mise à jour, les administrateurs de clusters peuvent fournir un fichier config.json à la tâche de cluster Buildah en utilisant l'espace de travail dockerconfig.

3.1.5.7. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.8.2

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.8.2 est disponible sur OpenShift Container Platform 4.10, 4.11 et 4.12.

3.1.5.7.1. Problèmes corrigés
  • Avant cette mise à jour, la tâche git-clone échouait lors du clonage d'un référentiel à l'aide de clés SSH. Avec cette mise à jour, le rôle de l'utilisateur non root dans la tâche git-init est supprimé, et le programme SSH recherche les clés correctes dans le répertoire $HOME/.ssh/.

3.1.6. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.7

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.7 est disponible sur OpenShift Container Platform 4.9, 4.10 et 4.11.

3.1.6.1. Nouvelles fonctionnalités

En plus des corrections et des améliorations de stabilité, les sections suivantes mettent en évidence les nouveautés de Red Hat OpenShift Pipelines 1.7.

3.1.6.1.1. Pipelines
  • Avec cette mise à jour, pipelines-<version> est le canal par défaut pour installer Red Hat OpenShift Pipelines Operator. Par exemple, le canal par défaut pour installer la version 1.7 d'OpenShift Pipelines Operator est pipelines-1.7. Les administrateurs de cluster peuvent également utiliser le canal latest pour installer la version stable la plus récente de l'Opérateur.

    Note

    Les canaux preview et stable seront dépréciés et supprimés dans une prochaine version.

  • Lorsque vous exécutez une commande dans un espace de noms utilisateur, votre conteneur s'exécute en tant que root (user id 0) mais dispose de privilèges d'utilisateur sur l'hôte. Avec cette mise à jour, pour exécuter des pods dans l'espace de noms utilisateur, vous devez passer les annotations attendues par CRI-O.

    • Pour ajouter ces annotations pour tous les utilisateurs, exécutez la commande oc edit clustertask buildah et modifiez la tâche de cluster buildah.
    • Pour ajouter les annotations à un espace de noms spécifique, exportez la tâche de cluster en tant que tâche vers cet espace de noms.
  • Avant cette mise à jour, si certaines conditions n'étaient pas remplies, l'expression when sautait un objet Task et ses tâches dépendantes. Avec cette mise à jour, vous pouvez étendre l'expression when pour garder l'objet Task uniquement, et non ses tâches dépendantes. Pour activer cette mise à jour, définissez l'indicateur scope-when-expressions-to-task sur true dans le CRD TektonConfig.

    Note

    L'indicateur scope-when-expressions-to-task est obsolète et sera supprimé dans une prochaine version. En tant que meilleure pratique pour OpenShift Pipelines, utilisez les expressions when limitées à l'élément gardé Task uniquement.

  • Avec cette mise à jour, vous pouvez utiliser la substitution de variables dans le champ subPath d'un espace de travail au sein d'une tâche.
  • Avec cette mise à jour, vous pouvez référencer les paramètres et les résultats en utilisant une notation entre crochets avec des guillemets simples ou doubles. Avant cette mise à jour, vous ne pouviez utiliser que la notation par points. Par exemple, les éléments suivants sont désormais équivalents :

    • $(param.myparam), $(param['myparam']), et $(param["myparam"]).

      Vous pouvez utiliser des guillemets simples ou doubles pour entourer les noms de paramètres qui contiennent des caractères problématiques, tels que ".". Par exemple, $(param['my.param']) et $(param["my.param"]).

  • Avec cette mise à jour, vous pouvez inclure le paramètre onError d'une étape dans la définition de la tâche sans activer l'indicateur enable-api-fields.
3.1.6.1.2. Déclencheurs
  • Avec cette mise à jour, la carte de configuration feature-flag-triggers dispose d'un nouveau champ labels-exclusion-pattern. Vous pouvez définir la valeur de ce champ par une expression régulière (regex). Le contrôleur filtre les étiquettes qui correspondent au motif de l'expression régulière et les empêche de se propager de l'auditeur d'événements vers les ressources créées pour l'auditeur d'événements.
  • Avec cette mise à jour, le champ TriggerGroups est ajouté à la spécification EventListener. Ce champ permet de spécifier un ensemble d'intercepteurs à exécuter avant de sélectionner et d'exécuter un groupe de déclencheurs. Pour activer cette fonctionnalité, dans la définition de la ressource personnalisée TektonConfig, dans la section pipeline, vous devez définir le champ enable-api-fields sur alpha.
  • Avec cette mise à jour, les ressources Trigger prennent en charge les exécutions personnalisées définies par un modèle TriggerTemplate.
  • Avec cette mise à jour, les déclencheurs prennent en charge l'émission d'événements Kubernetes à partir d'un pod EventListener.
  • Avec cette mise à jour, les mesures de comptage sont disponibles pour les objets suivants : ClusterInteceptor, EventListener, TriggerTemplate, ClusterTriggerBinding, et TriggerBinding.
  • Cette mise à jour ajoute la spécification ServicePort à la ressource Kubernetes. Vous pouvez utiliser cette spécification pour modifier le port qui expose le service d'écoute d'événements. Le port par défaut est 8080.
  • Avec cette mise à jour, vous pouvez utiliser le champ targetURI dans la spécification EventListener pour envoyer des événements cloud pendant le traitement des déclencheurs. Pour activer cette fonctionnalité, dans la définition de la ressource personnalisée TektonConfig, dans la section pipeline, vous devez définir le champ enable-api-fields sur alpha.
  • Avec cette mise à jour, l'objet tekton-triggers-eventlistener-roles a maintenant un verbe patch, en plus du verbe create qui existe déjà.
  • Avec cette mise à jour, le paramètre securityContext.runAsUser est supprimé du déploiement de l'écouteur d'événements.
3.1.6.1.3. CLI
  • Avec cette mise à jour, la commande tkn [pipeline | pipelinerun] export exporte un pipeline ou une exécution de pipeline sous la forme d'un fichier YAML. Par exemple, il est possible d'exporter un pipeline ou une exécution de pipeline sous forme de fichier YAML :

    • Exporter un pipeline nommé test_pipeline dans l'espace de noms openshift-pipelines:

      $ tkn pipeline export test_pipeline -n openshift-pipelines
    • Exporter un pipeline nommé test_pipeline_run dans l'espace de noms openshift-pipelines:

      $ tkn pipelinerun export test_pipeline_run -n openshift-pipelines
  • Avec cette mise à jour, l'option --grace est ajoutée à l'option tkn pipelinerun cancel. Utilisez l'option --grace pour mettre fin à l'exécution d'un pipeline de manière gracieuse au lieu de forcer la fin. Pour activer cette fonctionnalité, dans la définition de la ressource personnalisée TektonConfig, dans la section pipeline, vous devez définir le champ enable-api-fields à alpha.
  • Cette mise à jour ajoute les versions Operator et Chains à la sortie de la commande tkn version.

    Important

    Tekton Chains est une fonctionnalité de l'aperçu technologique.

  • Avec cette mise à jour, la commande tkn pipelinerun describe affiche toutes les exécutions de tâches annulées, lorsque vous annulez une exécution de pipeline. Avant cette correction, une seule tâche était affichée.
  • Avec cette mise à jour, vous pouvez ne pas fournir les spécifications de l'espace de travail optionnel lorsque vous exécutez la commande tkn [t | p | ct] start skips avec l'option --skip-optional-workspace. Vous pouvez également ne pas le faire en mode interactif.
  • Avec cette mise à jour, vous pouvez utiliser la commande tkn chains pour gérer les chaînes Tekton. Vous pouvez également utiliser l'option --chains-namespace pour spécifier l'espace de noms dans lequel vous souhaitez installer les chaînes Tekton.

    Important

    Tekton Chains est une fonctionnalité de l'aperçu technologique.

3.1.6.1.4. Opérateur
  • Avec cette mise à jour, vous pouvez utiliser l'opérateur Red Hat OpenShift Pipelines pour installer et déployer Tekton Hub et Tekton Chains.

    Important

    Les chaînes Tekton et le déploiement de Tekton Hub sur un cluster sont des fonctionnalités de l'aperçu technologique.

  • Avec cette mise à jour, vous pouvez trouver et utiliser Pipelines as Code (PAC) en tant qu'option supplémentaire.

    Important

    Pipelines as Code est une fonctionnalité de l'aperçu technologique.

  • Avec cette mise à jour, vous pouvez désormais désactiver l'installation des tâches de cluster communautaire en définissant le paramètre communityClusterTasks sur false. Par exemple :

    ...
    spec:
      profile: all
      targetNamespace: openshift-pipelines
      addon:
        params:
        - name: clusterTasks
          value: "true"
        - name: pipelineTemplates
          value: "true"
        - name: communityClusterTasks
          value: "false"
    ...
  • Avec cette mise à jour, vous pouvez désactiver l'intégration de Tekton Hub avec la perspective Developer en définissant l'indicateur enable-devconsole-integration dans la ressource personnalisée TektonConfig sur false. Par exemple :

    ...
    hub:
      params:
        - name: enable-devconsole-integration
          value: "true"
    ...
  • Avec cette mise à jour, la carte de configuration operator-config.yaml permet à la sortie de la commande tkn version d'afficher la version de l'opérateur.
  • Avec cette mise à jour, la version des tâches argocd-task-sync-and-wait est modifiée en v0.2.
  • Avec cette mise à jour du CRD TektonConfig, la commande oc get tektonconfig affiche la version de l'OPerator.
  • Avec cette mise à jour, le moniteur de service est ajouté aux mesures des déclencheurs.
3.1.6.1.5. Hub
Important

Le déploiement de Tekton Hub sur un cluster est une fonctionnalité de l'aperçu technologique.

Tekton Hub vous aide à découvrir, rechercher et partager des tâches et des pipelines réutilisables pour vos flux de travail CI/CD. Une instance publique de Tekton Hub est disponible sur hub.tekton.dev.

Depuis Red Hat OpenShift Pipelines 1.7, les administrateurs de clusters peuvent également installer et déployer une instance personnalisée de Tekton Hub sur les clusters d'entreprise. Vous pouvez créer un catalogue avec des tâches réutilisables et des pipelines spécifiques à votre organisation.

3.1.6.1.6. Chaînes
Important

Tekton Chains est une fonctionnalité de l'aperçu technologique.

Tekton Chains est un contrôleur de définition de ressources personnalisées (CRD) de Kubernetes. Vous pouvez l'utiliser pour gérer la sécurité de la chaîne logistique des tâches et des pipelines créés à l'aide de Red Hat OpenShift Pipelines.

Par défaut, Tekton Chains surveille les exécutions de tâches dans votre cluster OpenShift Container Platform. Chains prend des instantanés des exécutions de tâches terminées, les convertit en un ou plusieurs formats de charge utile standard, et signe et stocke tous les artefacts.

Tekton Chains prend en charge les fonctionnalités suivantes :

  • Vous pouvez signer les exécutions de tâches, les résultats des exécutions de tâches et les images de registre OCI avec des types de clés cryptographiques et des services tels que cosign.
  • Vous pouvez utiliser des formats d'attestation tels que in-toto.
  • Vous pouvez stocker en toute sécurité des signatures et des artefacts signés en utilisant le référentiel OCI comme backend de stockage.
3.1.6.1.7. Les pipelines en tant que code (PAC)
Important

Pipelines as Code est une fonctionnalité de l'aperçu technologique.

Avec Pipelines as Code, les administrateurs de clusters et les utilisateurs disposant des privilèges requis peuvent définir des modèles de pipelines dans le cadre de dépôts Git de code source. Lorsqu'elle est déclenchée par un push de code source ou une pull request pour le dépôt Git configuré, la fonctionnalité exécute le pipeline et signale son état.

Pipelines as Code prend en charge les fonctionnalités suivantes :

  • Statut de la demande d'extraction. Lors de l'itération sur une demande d'extraction, le statut et le contrôle de la demande d'extraction sont exercés sur la plateforme hébergeant le dépôt Git.
  • GitHub vérifie l'API pour définir le statut d'une exécution de pipeline, y compris les recontrôles.
  • Événements GitHub relatifs aux demandes d'extraction et aux livraisons.
  • Actions de demande d'extraction dans les commentaires, telles que /retest.
  • Filtrage des événements Git et pipeline séparé pour chaque événement.
  • Résolution automatique des tâches dans OpenShift Pipelines pour les tâches locales, Tekton Hub, et les URLs distantes.
  • Utilisation des blobs et des objets de l'API GitHub pour récupérer les configurations.
  • Liste de contrôle d'accès (ACL) sur une organisation GitHub, ou en utilisant un fichier de type Prow OWNER.
  • Le plugin tkn pac pour l'outil CLI tkn, que vous pouvez utiliser pour gérer les dépôts de Pipelines as Code et le bootstrapping.
  • Prise en charge de l'application GitHub, de GitHub Webhook, du serveur Bitbucket et de Bitbucket Cloud.

3.1.6.2. Fonctionnalités obsolètes

  • Changement radical : Cette mise à jour supprime les champs disable-working-directory-overwrite et disable-home-env-overwrite de la ressource personnalisée (CR) TektonConfig. Par conséquent, la CR TektonConfig ne définit plus automatiquement la variable d'environnement $HOME et le paramètre workingDir. Vous pouvez toujours définir la variable d'environnement $HOME et le paramètre workingDir en utilisant les champs env et workingDir dans la définition de ressource personnalisée (CRD) Task.
  • Le type de définition de ressource personnalisée (CRD) Conditions est obsolète et devrait être supprimé dans une prochaine version. Utilisez plutôt l'expression recommandée When.
  • Changement radical : La ressource Triggers valide les modèles et génère une erreur si vous ne spécifiez pas les valeurs EventListener et TriggerBinding.

3.1.6.3. Problèmes connus

  • Lorsque vous exécutez des tâches de cluster Maven et Jib-Maven, l'image de conteneur par défaut n'est prise en charge que sur l'architecture Intel (x86). Par conséquent, les tâches échoueront sur les clusters ARM, IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x). Pour contourner le problème, vous pouvez spécifier une image personnalisée en définissant la valeur du paramètre MAVEN_IMAGE sur maven:3.6.3-adoptopenjdk-11.

    Astuce

    Avant d'installer des tâches basées sur le catalogue Tekton sur ARM, IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x) en utilisant tkn hub, vérifiez si la tâche peut être exécutée sur ces plates-formes. Pour vérifier si ppc64le et s390x sont répertoriés dans la section "Platforms" des informations sur la tâche, vous pouvez exécuter la commande suivante : tkn hub info task <name>

  • Sur IBM Power Systems, IBM Z et LinuxONE, la tâche s2i-dotnet cluster n'est pas prise en charge.
  • Vous ne pouvez pas utiliser le flux d'images nodejs:14-ubi8-minimal car cela génère les erreurs suivantes :

    STEP 7: RUN /usr/libexec/s2i/assemble
    /bin/sh: /usr/libexec/s2i/assemble: No such file or directory
    subprocess exited with status 127
    subprocess exited with status 127
    error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
    time="2021-11-04T13:05:26Z" level=error msg="exit status 127"
  • Le mappage implicite des paramètres transmet incorrectement les paramètres des définitions de premier niveau Pipeline ou PipelineRun aux tâches taskRef. Le mappage ne doit se faire qu'à partir d'une ressource de premier niveau vers des tâches avec des spécifications en ligne taskSpec. Ce problème n'affecte que les clusters où cette fonctionnalité a été activée en définissant le champ enable-api-fields sur alpha dans la section pipeline de la définition de la ressource personnalisée TektonConfig.

3.1.6.4. Problèmes corrigés

  • Avec cette mise à jour, si des métadonnées telles que labels et annotations sont présentes dans les définitions des objets Pipeline et PipelineRun, les valeurs du type PipelineRun sont prioritaires. Vous pouvez observer un comportement similaire pour les objets Task et TaskRun.
  • Avec cette mise à jour, si le champ timeouts.tasks ou le champ timeouts.finally est défini sur 0, le champ timeouts.pipeline est également défini sur 0.
  • Avec cette mise à jour, l'indicateur -x set est supprimé des scripts qui n'utilisent pas de shebang. Cette correction réduit les risques de fuite de données lors de l'exécution des scripts.
  • Avec cette mise à jour, tout caractère backslash présent dans les noms d'utilisateur des identifiants Git est échappé par un backslash supplémentaire dans le fichier .gitconfig.
  • Avec cette mise à jour, la propriété finalizer de l'objet EventListener n'est pas nécessaire pour nettoyer les logs et les cartes de configuration.
  • Avec cette mise à jour, le client HTTP par défaut associé au serveur d'écoute des événements est supprimé et un client HTTP personnalisé est ajouté. En conséquence, les délais d'attente ont été améliorés.
  • Avec cette mise à jour, le rôle de cluster Déclencheurs fonctionne désormais avec les références de propriétaires.
  • Avec cette mise à jour, la condition de course dans l'écouteur d'événements ne se produit pas lorsque plusieurs intercepteurs renvoient des extensions.
  • Avec cette mise à jour, la commande tkn pr delete n'efface pas les pipelines exécutés avec l'indicateur ignore-running.
  • Avec cette mise à jour, les pods de l'opérateur ne continuent pas à redémarrer lorsque vous modifiez les paramètres d'un add-on.
  • Avec cette mise à jour, le pod tkn serve CLI est planifié sur les nœuds infra, s'il n'est pas configuré dans les ressources personnalisées d'abonnement et de configuration.
  • Avec cette mise à jour, les tâches de cluster avec les versions spécifiées ne sont pas supprimées lors de la mise à niveau.

3.1.6.5. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.7.1

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.7.1 est disponible sur OpenShift Container Platform 4.9, 4.10 et 4.11.

3.1.6.5.1. Problèmes corrigés
  • Avant cette mise à jour, la mise à niveau de Red Hat OpenShift Pipelines Operator supprimait les données de la base de données associée à Tekton Hub et installait une nouvelle base de données. Avec cette mise à jour, une mise à niveau de l'Opérateur préserve les données.
  • Avant cette mise à jour, seuls les administrateurs de cluster pouvaient accéder aux métriques de pipeline dans la console OpenShift Container Platform. Avec cette mise à jour, les utilisateurs ayant d'autres rôles dans le cluster peuvent également accéder aux métriques du pipeline.
  • Avant cette mise à jour, les exécutions de pipeline échouaient pour les pipelines contenant des tâches qui émettent des messages de fin volumineux. Les exécutions de pipeline échouaient parce que la taille totale des messages de fin de tous les conteneurs dans un pod ne peut pas dépasser 12 KB. Avec cette mise à jour, les conteneurs d'initialisation place-tools et step-init qui utilisent la même image sont fusionnés pour réduire le nombre de conteneurs en cours d'exécution dans le pod de chaque tâche. La solution réduit le risque d'échec des exécutions du pipeline en minimisant le nombre de conteneurs en cours d'exécution dans le pod d'une tâche. Cependant, elle ne supprime pas la limitation de la taille maximale autorisée d'un message de fin.
  • Avant cette mise à jour, les tentatives d'accès aux URL de ressources directement depuis la console web Tekton Hub entraînaient une erreur Nginx 404. Avec cette mise à jour, l'image de la console web Tekton Hub est corrigée pour permettre l'accès aux URLs des ressources directement depuis la console web Tekton Hub.
  • Avant cette mise à jour, la tâche d'élagage des ressources créait un conteneur distinct pour chaque espace de noms afin d'élaguer les ressources. Avec cette mise à jour, la tâche d'élagage des ressources exécute les commandes pour tous les espaces de noms en boucle dans un seul conteneur.

3.1.6.6. Notes de mise à jour pour Red Hat OpenShift Pipelines General Availability 1.7.2

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.7.2 est disponible sur OpenShift Container Platform 4.9, 4.10, et la version à venir.

3.1.6.6.1. Problèmes connus
  • La carte de configuration chains-config pour les chaînes Tekton dans l'espace de noms openshift-pipelines est automatiquement réinitialisée par défaut après la mise à niveau de Red Hat OpenShift Pipelines Operator. Actuellement, il n'y a pas de solution de contournement pour ce problème.
3.1.6.6.2. Problèmes corrigés
  • Avant cette mise à jour, les tâches sur OpenShift Pipelines 1.7.1 échouaient lors de l'utilisation de init comme premier argument, suivi de deux arguments ou plus. Avec cette mise à jour, les drapeaux sont analysés correctement et les tâches sont exécutées avec succès.
  • Avant cette mise à jour, l'installation de Red Hat OpenShift Pipelines Operator sur OpenShift Container Platform 4.9 et 4.10 échouait en raison d'une liaison de rôle non valide, avec le message d'erreur suivant :

    error updating rolebinding openshift-operators-prometheus-k8s-read-binding: RoleBinding.rbac.authorization.k8s.io "openshift-operators-prometheus-k8s-read-binding" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"openshift-operator-read"}: cannot change roleRef

    Avec cette mise à jour, l'opérateur Red Hat OpenShift Pipelines s'installe avec des espaces de noms de liaison de rôle distincts pour éviter les conflits avec l'installation d'autres opérateurs.

  • Avant cette mise à jour, la mise à niveau de l'opérateur entraînait la réinitialisation de la clé secrète signing-secrets pour les chaînes Tekton à sa valeur par défaut. Avec cette mise à jour, la clé secrète personnalisée persiste après la mise à niveau de l'opérateur.

    Note

    La mise à niveau vers Red Hat OpenShift Pipelines 1.7.2 réinitialise la clé. Cependant, lorsque vous mettez à niveau vers des versions ultérieures, la clé est censée persister.

  • Avant cette mise à jour, toutes les tâches de construction de S2I échouaient avec une erreur similaire au message suivant :

    Error: error writing "0 0 4294967295\n" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted
    time="2022-03-04T09:47:57Z" level=error msg="error writing \"0 0 4294967295\\n\" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted"
    time="2022-03-04T09:47:57Z" level=error msg="(unable to determine exit status)"

    Avec cette mise à jour, la contrainte de contexte de sécurité (SCC) de pipelines-scc est compatible avec la capacité de SETFCAP nécessaire pour les tâches de cluster de Buildah et S2I. Par conséquent, les tâches de construction Buildah et S2I peuvent être exécutées avec succès.

    Pour exécuter avec succès la tâche de cluster Buildah et les tâches de construction S2I pour les applications écrites dans différents langages et frameworks, ajoutez l'extrait suivant pour les objets steps appropriés tels que build et push:

    securityContext:
      capabilities:
        add: ["SETFCAP"]

3.1.6.7. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.7.3

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.7.3 est disponible sur OpenShift Container Platform 4.9, 4.10 et 4.11.

3.1.6.7.1. Problèmes corrigés
  • Avant cette mise à jour, l'opérateur échouait lors de la création de ressources RBAC si un espace de noms était dans l'état Terminating. Avec cette mise à jour, l'opérateur ignore les espaces de noms dans l'état Terminating et crée les ressources RBAC.
  • Auparavant, la mise à niveau de Red Hat OpenShift Pipelines Operator entraînait la recréation du compte de service pipeline, ce qui signifiait que les secrets liés au compte de service étaient perdus. Cette mise à jour corrige ce problème. Lors des mises à niveau, l'Opérateur ne recrée plus le compte de service pipeline. Par conséquent, les secrets liés au compte de service pipeline persistent après les mises à niveau, et les ressources (tâches et pipelines) continuent de fonctionner correctement.

3.1.7. Notes de mise à jour pour Red Hat OpenShift Pipelines General Availability 1.6

Avec cette mise à jour, Red Hat OpenShift Pipelines General Availability (GA) 1.6 est disponible sur OpenShift Container Platform 4.9.

3.1.7.1. Nouvelles fonctionnalités

En plus des corrections et des améliorations de la stabilité, les sections suivantes mettent en évidence les nouveautés de Red Hat OpenShift Pipelines 1.6.

  • Avec cette mise à jour, vous pouvez configurer la commande start d'un pipeline ou d'une tâche pour qu'elle renvoie une chaîne formatée YAML ou JSON en utilisant l'option --output <string>, où <string> est yaml ou json. Sinon, sans l'option --output, la commande start renvoie un message convivial difficile à analyser par d'autres programmes. Le renvoi d'une chaîne au format YAML ou JSON est utile pour les environnements d'intégration continue (CI). Par exemple, après la création d'une ressource, vous pouvez utiliser yq ou jq pour analyser le message au format YAML ou JSON concernant la ressource et attendre que cette ressource soit terminée sans utiliser l'option showlog.
  • Avec cette mise à jour, vous pouvez vous authentifier auprès d'un registre en utilisant le fichier d'authentification auth.json de Podman. Par exemple, vous pouvez utiliser tkn bundle push pour pousser vers un registre distant en utilisant Podman au lieu de Docker CLI.
  • Avec cette mise à jour, si vous utilisez la commande tkn [taskrun | pipelinerun] delete --all, vous pouvez conserver les exécutions datant de moins d'un certain nombre de minutes en utilisant la nouvelle option --keep-since <minutes>. Par exemple, pour conserver les exécutions datant de moins de cinq minutes, vous devez saisir tkn [taskrun | pipelinerun] delete -all --keep-since 5.
  • Avec cette mise à jour, lorsque vous supprimez des exécutions de tâches ou des exécutions de pipeline, vous pouvez utiliser les options --parent-resource et --keep-since en même temps. Par exemple, la commande tkn pipelinerun delete --pipeline pipelinename --keep-since 5 préserve les exécutions de pipeline dont la ressource parente est nommée pipelinename et dont l'ancienneté est inférieure ou égale à cinq minutes. Les commandes tkn tr delete -t <taskname> --keep-since 5 et tkn tr delete --clustertask <taskname> --keep-since 5 fonctionnent de la même manière pour les exécutions de tâches.
  • Cette mise à jour ajoute la prise en charge des ressources de déclenchement pour qu'elles fonctionnent avec les ressources v1beta1.
  • Cette mise à jour ajoute une option ignore-running aux commandes tkn pipelinerun delete et tkn taskrun delete.
  • Cette mise à jour ajoute une sous-commande create aux commandes tkn task et tkn clustertask.
  • Avec cette mise à jour, lorsque vous utilisez la commande tkn pipelinerun delete --all, vous pouvez utiliser la nouvelle option --label <string> pour filtrer les parcours du pipeline par étiquette. Vous pouvez également utiliser l'option --label avec = et == comme opérateurs d'égalité, ou != comme opérateur d'inégalité. Par exemple, les commandes tkn pipelinerun delete --all --label asdf et tkn pipelinerun delete --all --label==asdf suppriment toutes deux toutes les séries de pipelines portant le label asdf.
  • Avec cette mise à jour, vous pouvez récupérer la version des composants Tekton installés à partir de la carte de configuration ou, si la carte de configuration n'est pas présente, à partir du contrôleur de déploiement.
  • Avec cette mise à jour, les déclencheurs prennent en charge les cartes de configuration feature-flags et config-defaults pour configurer les drapeaux des fonctionnalités et définir les valeurs par défaut, respectivement.
  • Cette mise à jour ajoute une nouvelle métrique, eventlistener_event_count, que vous pouvez utiliser pour compter les événements reçus par la ressource EventListener.
  • Cette mise à jour ajoute les types d'API v1beta1 Go. Avec cette mise à jour, les déclencheurs prennent désormais en charge la version de l'API v1beta1.

    Avec la version actuelle, les fonctionnalités de v1alpha1 sont désormais obsolètes et seront supprimées dans une prochaine version. Commencez à utiliser les fonctionnalités de v1beta1 à la place.

  • Dans la version actuelle, l'exécution automatique des ressources est activée par défaut. En outre, vous pouvez configurer l'exécution automatique des tâches et des pipelines pour chaque espace de noms séparément, en utilisant les nouvelles annotations suivantes :

    • operator.tekton.dev/prune.schedule: Si la valeur de cette annotation est différente de la valeur spécifiée dans la définition de la ressource personnalisée TektonConfig, un nouveau travail cron est créé dans cet espace de noms.
    • operator.tekton.dev/prune.skip: Lorsqu'il est défini sur true, l'espace de noms pour lequel il est configuré ne sera pas élagué.
    • operator.tekton.dev/prune.resources: Cette annotation accepte une liste de ressources séparées par des virgules. Pour élaguer une seule ressource, telle qu'une exécution de pipeline, définissez cette annotation à "pipelinerun". Pour élaguer plusieurs ressources, telles qu'une exécution de tâche et une exécution de pipeline, définissez cette annotation à "taskrun, pipelinerun".
    • operator.tekton.dev/prune.keep: Utilisez cette annotation pour conserver une ressource sans l'élaguer.
    • operator.tekton.dev/prune.keep-since: Cette annotation permet de conserver les ressources en fonction de leur âge. La valeur de cette annotation doit être égale à l'âge de la ressource en minutes. Par exemple, pour conserver les ressources qui ont été créées il y a cinq jours au maximum, définissez keep-since sur 7200.

      Note

      Les annotations keep et keep-since s'excluent mutuellement. Pour toute ressource, vous ne devez configurer qu'une seule d'entre elles.

    • operator.tekton.dev/prune.strategy: Fixer la valeur de cette annotation à keep ou keep-since.
  • Les administrateurs peuvent désactiver la création du compte de service pipeline pour l'ensemble du cluster, et empêcher l'escalade des privilèges par une mauvaise utilisation du SCC associé, qui est très similaire à anyuid.
  • Vous pouvez désormais configurer les drapeaux de fonctionnalité et les composants en utilisant la ressource personnalisée (CR) TektonConfig et les CR pour les composants individuels, tels que TektonPipeline et TektonTriggers. Ce niveau de granularité permet de personnaliser et de tester des fonctionnalités alpha telles que le Tekton OCI bundle pour des composants individuels.
  • Vous pouvez désormais configurer le champ optionnel Timeouts pour la ressource PipelineRun. Par exemple, vous pouvez configurer des délais séparément pour l'exécution d'un pipeline, l'exécution de chaque tâche et les tâches finally.
  • Les pods générés par la ressource TaskRun définissent désormais le champ activeDeadlineSeconds des pods. Cela permet à OpenShift de les considérer comme terminés, et vous permet d'utiliser l'objet spécifiquement scoped ResourceQuota pour les pods.
  • Vous pouvez utiliser les cartes de configuration pour éliminer les balises de métriques ou les types d'étiquettes sur une exécution de tâche, une exécution de pipeline, une tâche et un pipeline. En outre, vous pouvez configurer différents types de métriques pour mesurer la durée, tels qu'un histogramme, une jauge ou la dernière valeur.
  • Vous pouvez définir les demandes et les limites d'un pod de manière cohérente, car Tekton prend désormais entièrement en charge l'objet LimitRange en tenant compte des champs Min, Max, Default et DefaultRequest.
  • Les fonctionnalités alpha suivantes sont introduites :

    • L'exécution d'un pipeline peut maintenant s'arrêter après l'exécution des tâches finally, plutôt que d'arrêter directement l'exécution de toutes les tâches comme c'était le cas auparavant. Cette mise à jour ajoute les valeurs spec.status suivantes :

      • StoppedRunFinally arrêtera les tâches en cours d'exécution une fois qu'elles seront terminées, puis exécutera les tâches finally.
      • CancelledRunFinally annulera immédiatement les tâches en cours, puis exécutera les tâches finally.
      • Cancelled conservera le comportement antérieur fourni par le statut PipelineRunCancelled.

        Note

        Le statut Cancelled remplace le statut PipelineRunCancelled, qui est obsolète et qui sera supprimé dans la version v1.

    • Vous pouvez désormais utiliser la commande oc debug pour mettre une tâche en mode débogage, ce qui met l'exécution en pause et vous permet d'inspecter des étapes spécifiques d'un module.
    • Lorsque vous attribuez la valeur continue au champ onError d'une étape, le code de sortie de l'étape est enregistré et transmis aux étapes suivantes. Toutefois, l'exécution de la tâche n'échoue pas et l'exécution des autres étapes de la tâche se poursuit. Pour conserver le comportement existant, vous pouvez attribuer au champ onError la valeur stopAndFail.
    • Les tâches peuvent désormais accepter plus de paramètres qu'elles n'en utilisent réellement. Lorsque l'option alpha est activée, les paramètres peuvent se propager implicitement aux spécifications intégrées. Par exemple, une tâche intégrée peut accéder aux paramètres de son pipeline parent, sans définir explicitement chaque paramètre pour la tâche.
    • Si vous activez l'indicateur pour les caractéristiques alpha, les conditions des expressions When ne s'appliqueront qu'à la tâche à laquelle elle est directement associée, et non aux dépendances de la tâche. Pour appliquer les expressions When à la tâche associée et à ses dépendances, vous devez associer l'expression à chaque tâche dépendante séparément. Notez qu'à l'avenir, ce sera le comportement par défaut des expressions When dans toutes les nouvelles versions API de Tekton. Le comportement par défaut existant sera supprimé en faveur de cette mise à jour.
  • La version actuelle vous permet de configurer la sélection des nœuds en spécifiant les valeurs nodeSelector et tolerations dans la ressource personnalisée (CR) TektonConfig. L'opérateur ajoute ces valeurs à tous les déploiements qu'il crée.

    • Pour configurer la sélection des nœuds pour le contrôleur de l'opérateur et le déploiement des webhooks, vous devez modifier les champs config.nodeSelector et config.tolerations dans la spécification de Subscription CR, après avoir installé l'opérateur.
    • Pour déployer le reste des pods du plan de contrôle d'OpenShift Pipelines sur un nœud d'infrastructure, mettez à jour le CR TektonConfig avec les champs nodeSelector et tolerations. Les modifications sont ensuite appliquées à tous les pods créés par Operator.

3.1.7.2. Fonctionnalités obsolètes

  • Dans le CLI 0.21.0, la prise en charge de toutes les ressources v1alpha1 pour les commandes clustertask, task, taskrun, pipeline, et pipelinerun est obsolète. Ces ressources sont désormais obsolètes et seront supprimées dans une prochaine version.
  • Dans la version 0.16.0 de Tekton Triggers, l'étiquette redondante status est supprimée des métriques de la ressource EventListener.

    Important

    Changement radical : Le label status a été supprimé de la métrique eventlistener_http_duration_seconds_*. Supprimez les requêtes basées sur le label status.

  • Avec la version actuelle, les fonctionnalités de v1alpha1 sont désormais obsolètes et seront supprimées dans une prochaine version. Avec cette mise à jour, vous pouvez commencer à utiliser les types d'API v1beta1 Go à la place. Les déclencheurs prennent désormais en charge la version de l'API v1beta1.
  • Avec la version actuelle, la ressource EventListener envoie une réponse avant que les déclencheurs ne terminent leur traitement.

    Important

    Changement de rupture : Avec cette modification, la ressource EventListener ne répond plus avec un code d'état 201 Created lorsqu'elle crée des ressources. Au lieu de cela, elle répond avec un code de réponse 202 Accepted.

  • La version actuelle supprime le champ podTemplate de la ressource EventListener.

    Important

    Changement radical : Le champ podTemplate, qui a été supprimé dans le cadre de #1100, a été supprimé.

  • La version actuelle supprime le champ replicas, obsolète, de la spécification de la ressource EventListener.

    Important

    Changement radical : Le champ replicas, obsolète, a été supprimé.

  • Dans Red Hat OpenShift Pipelines 1.6, les valeurs de HOME="/tekton/home" et workingDir="/workspace" sont supprimées de la spécification des objets Step.

    Au lieu de cela, Red Hat OpenShift Pipelines définit HOME et workingDir aux valeurs définies par les conteneurs exécutant les objets Step. Vous pouvez remplacer ces valeurs dans la spécification de vos objets Step.

    Pour utiliser l'ancien comportement, vous pouvez remplacer les champs disable-working-directory-overwrite et disable-home-env-overwrite de la CR TektonConfig par false:

    apiVersion: operator.tekton.dev/v1alpha1
      kind: TektonConfig
      metadata:
        name: config
      spec:
        pipeline:
          disable-working-directory-overwrite: false
          disable-home-env-overwrite: false
      ...
    Important

    Les champs disable-working-directory-overwrite et disable-home-env-overwrite de la CR TektonConfig sont désormais obsolètes et seront supprimés dans une prochaine version.

3.1.7.3. Problèmes connus

  • Lorsque vous exécutez des tâches de cluster Maven et Jib-Maven, l'image de conteneur par défaut n'est prise en charge que sur l'architecture Intel (x86). Par conséquent, les tâches échoueront sur les clusters IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x). Pour contourner ce problème, vous pouvez spécifier une image personnalisée en définissant la valeur du paramètre MAVEN_IMAGE sur maven:3.6.3-adoptopenjdk-11.
  • Sur IBM Power Systems, IBM Z et LinuxONE, la tâche s2i-dotnet cluster n'est pas prise en charge.
  • Avant d'installer des tâches basées sur le catalogue Tekton sur IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x) à l'aide de tkn hub, vérifiez si la tâche peut être exécutée sur ces plates-formes. Pour vérifier si ppc64le et s390x sont listés dans la section "Platforms" des informations sur la tâche, vous pouvez exécuter la commande suivante : tkn hub info task <name>
  • Vous ne pouvez pas utiliser le flux d'images nodejs:14-ubi8-minimal car cela génère les erreurs suivantes :

    STEP 7: RUN /usr/libexec/s2i/assemble
    /bin/sh: /usr/libexec/s2i/assemble: No such file or directory
    subprocess exited with status 127
    subprocess exited with status 127
    error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
    time="2021-11-04T13:05:26Z" level=error msg="exit status 127"

3.1.7.4. Problèmes corrigés

  • La commande tkn hub est désormais prise en charge sur les systèmes IBM Power, IBM Z et LinuxONE.
  • Avant cette mise à jour, le terminal n'était pas disponible après que l'utilisateur ait exécuté une commande tkn, et l'exécution du pipeline était terminée, même si retries était spécifié. La spécification d'un délai d'attente dans l'exécution de la tâche ou du pipeline n'avait aucun effet. Cette mise à jour corrige le problème afin que le terminal soit disponible après l'exécution de la commande.
  • Avant cette mise à jour, l'exécution de tkn pipelinerun delete --all supprimait toutes les ressources. Cette mise à jour empêche la suppression des ressources en cours d'exécution.
  • Avant cette mise à jour, l'utilisation de la commande tkn version --component=<component> ne renvoyait pas la version du composant. Cette mise à jour corrige le problème de sorte que cette commande renvoie la version du composant.
  • Avant cette mise à jour, lorsque vous utilisiez la commande tkn pr logs, elle affichait les journaux de sortie des pipelines dans le mauvais ordre des tâches. Cette mise à jour résout le problème de sorte que les journaux de PipelineRuns sont répertoriés dans l'ordre d'exécution approprié de TaskRun.
  • Avant cette mise à jour, la modification de la spécification d'un pipeline en cours d'exécution pouvait empêcher l'exécution du pipeline de s'arrêter lorsqu'elle était terminée. Cette mise à jour corrige le problème en ne récupérant la définition qu'une seule fois et en utilisant ensuite la spécification stockée dans l'état pour la vérification. Cette modification réduit la probabilité d'une condition de course lorsqu'un PipelineRun ou un TaskRun fait référence à un Pipeline ou un Task qui change pendant l'exécution.
  • When les valeurs d'expression peuvent désormais contenir des références à des paramètres de type tableau, comme par exemple : values: [$(params.arrayParam[*])].

3.1.7.5. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.6.1

3.1.7.5.1. Problèmes connus
  • Après la mise à niveau vers Red Hat OpenShift Pipelines 1.6.1 à partir d'une version plus ancienne, OpenShift Pipelines peut entrer dans un état incohérent dans lequel vous ne pouvez pas effectuer d'opérations (créer/supprimer/appliquer) sur les ressources Tekton (tâches et pipelines). Par exemple, lors de la suppression d'une ressource, vous pouvez rencontrer l'erreur suivante :

    Error from server (InternalError): Internal error occurred: failed calling webhook "validation.webhook.pipeline.tekton.dev": Post "https://tekton-pipelines-webhook.openshift-pipelines.svc:443/resource-validation?timeout=10s": service "tekton-pipelines-webhook" not found.
3.1.7.5.2. Problèmes corrigés
  • La variable d'environnement SSL_CERT_DIR (/tekton-custom-certs) définie par Red Hat OpenShift Pipelines ne remplacera pas les répertoires système par défaut suivants par des fichiers de certificats :

    • /etc/pki/tls/certs
    • /etc/ssl/certs
    • /system/etc/security/cacerts
  • L'Horizontal Pod Autoscaler peut gérer le nombre de répliques des déploiements contrôlés par Red Hat OpenShift Pipelines Operator. À partir de cette version, si le compte est modifié par un utilisateur final ou un agent sur le cluster, Red Hat OpenShift Pipelines Operator ne réinitialisera pas le compte de répliques des déploiements qu'il gère. Cependant, les répliques seront réinitialisées lorsque vous mettrez à niveau le Red Hat OpenShift Pipelines Operator.
  • Le pod qui sert le CLI tkn sera désormais programmé sur des nœuds, en fonction du sélecteur de nœuds et des limites de tolérance spécifiées dans la ressource personnalisée TektonConfig.

3.1.7.6. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.6.2

3.1.7.6.1. Problèmes connus
  • Lorsque vous créez un nouveau projet, la création du compte de service pipeline est retardée, et la suppression des tâches de cluster et des modèles de pipeline existants prend plus de 10 minutes.
3.1.7.6.2. Problèmes corrigés
  • Avant cette mise à jour, plusieurs instances d'ensembles d'installation Tekton étaient créées pour un pipeline après la mise à niveau vers Red Hat OpenShift Pipelines 1.6.1 à partir d'une version plus ancienne. Avec cette mise à jour, l'opérateur s'assure qu'une seule instance de chaque type de TektonInstallerSet existe après une mise à niveau.
  • Avant cette mise à jour, tous les réconciliateurs de l'Opérateur utilisaient la version du composant pour décider de la recréation des ressources lors d'une mise à niveau vers Red Hat OpenShift Pipelines 1.6.1 à partir d'une version plus ancienne. Par conséquent, les ressources dont la version des composants n'a pas changé lors de la mise à niveau n'ont pas été recréées. Avec cette mise à jour, l'opérateur utilise la version de l'opérateur au lieu de la version du composant pour décider de la recréation des ressources lors d'une mise à niveau.
  • Avant cette mise à jour, le service pipelines webhook était absent du cluster après une mise à jour. Cela était dû à un blocage de la mise à jour sur les cartes de configuration. Avec cette mise à jour, un mécanisme est ajouté pour désactiver la validation du webhook si les cartes de configuration sont absentes dans le cluster. Par conséquent, le service pipelines webhook persiste dans le cluster après une mise à jour.
  • Avant cette mise à jour, les tâches cron pour l'élagage automatique étaient recréées après tout changement de configuration de l'espace de noms. Avec cette mise à jour, les tâches cron pour l'élagage automatique ne sont recréées que s'il y a un changement d'annotation pertinent dans l'espace de noms.
  • La version amont de Tekton Pipelines est révisée en v0.28.3, qui comporte les corrections suivantes :

    • Correction des objets PipelineRun ou TaskRun pour permettre la propagation des étiquettes ou des annotations.
    • Pour les paramètres implicites :

      • Ne pas appliquer les paramètres de PipelineSpec à l'objet TaskRefs.
      • Désactive le comportement param implicite pour les objets Pipeline.

3.1.7.7. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.6.3

3.1.7.7.1. Problèmes corrigés
  • Avant cette mise à jour, l'Opérateur Red Hat OpenShift Pipelines installait des politiques de sécurité de pods à partir de composants tels que Pipelines et Triggers. Cependant, les politiques de sécurité de pods livrées dans le cadre des composants ont été dépréciées dans une version antérieure. Avec cette mise à jour, l'opérateur arrête d'installer des politiques de sécurité de pods à partir de composants. Par conséquent, les chemins de mise à niveau suivants sont concernés :

    • La mise à jour d'OpenShift Pipelines 1.6.1 ou 1.6.2 vers OpenShift Pipelines 1.6.3 supprime les politiques de sécurité des pods, y compris celles des composants Pipelines et Triggers.
    • La mise à niveau d'OpenShift Pipelines 1.5.x vers 1.6.3 conserve les politiques de sécurité des pods installées à partir des composants. En tant qu'administrateur de cluster, vous pouvez les supprimer manuellement.

      Note

      Lorsque vous mettez à niveau vers des versions ultérieures, l'Opérateur Red Hat OpenShift Pipelines supprimera automatiquement toutes les politiques de sécurité de pods obsolètes.

  • Avant cette mise à jour, seuls les administrateurs de cluster pouvaient accéder aux métriques de pipeline dans la console OpenShift Container Platform. Avec cette mise à jour, les utilisateurs ayant d'autres rôles dans le cluster peuvent également accéder aux métriques du pipeline.
  • Avant cette mise à jour, des problèmes de contrôle d'accès basé sur les rôles (RBAC) avec l'opérateur OpenShift Pipelines causaient des problèmes de mise à niveau ou d'installation de composants. Cette mise à jour améliore la fiabilité et la cohérence de l'installation de divers composants Red Hat OpenShift Pipelines.
  • Avant cette mise à jour, le fait de définir les champs clusterTasks et pipelineTemplates sur false dans le CR TektonConfig ralentissait la suppression des tâches en grappe et des modèles de pipeline. Cette mise à jour améliore la vitesse de gestion du cycle de vie des ressources Tekton telles que les tâches de cluster et les modèles de pipeline.

3.1.7.8. Notes de version pour Red Hat OpenShift Pipelines General Availability 1.6.4

3.1.7.8.1. Problèmes connus
  • Après la mise à niveau de Red Hat OpenShift Pipelines 1.5.2 vers 1.6.4, l'accès aux routes d'écoute d'événements renvoie une erreur 503.

    Solution : Modifiez le port cible dans le fichier YAML pour la route de l'écouteur d'événements.

    1. Extraire le nom de la route pour l'espace de noms concerné.

      $ oc get route -n <namespace>
    2. Editer l'itinéraire pour modifier la valeur du champ targetPort.

      $ oc edit route -n <namespace> <el-route_name>

      Exemple : Route d'écoute d'événements existante

      ...
      spec:
        host: el-event-listener-q8c3w5-test-upgrade1.apps.ve49aws.aws.ospqa.com
        port:
          targetPort: 8000
        to:
          kind: Service
          name: el-event-listener-q8c3w5
          weight: 100
        wildcardPolicy: None
      ...

      Exemple : Modification de l'itinéraire de l'auditeur d'événements

      ...
      spec:
        host: el-event-listener-q8c3w5-test-upgrade1.apps.ve49aws.aws.ospqa.com
        port:
          targetPort: http-listener
        to:
          kind: Service
          name: el-event-listener-q8c3w5
          weight: 100
        wildcardPolicy: None
      ...

3.1.7.8.2. Problèmes corrigés
  • Avant cette mise à jour, l'opérateur échouait lors de la création de ressources RBAC si un espace de noms était dans l'état Terminating. Avec cette mise à jour, l'opérateur ignore les espaces de noms dans l'état Terminating et crée les ressources RBAC.
  • Avant cette mise à jour, les tâches échouaient ou redémarraient en raison de l'absence d'annotation spécifiant la version du contrôleur Tekton associé. Avec cette mise à jour, l'inclusion des annotations appropriées est automatisée et les tâches s'exécutent sans échec ni redémarrage.

3.1.8. Notes de mise à jour pour Red Hat OpenShift Pipelines General Availability 1.5

Red Hat OpenShift Pipelines General Availability (GA) 1.5 est désormais disponible sur OpenShift Container Platform 4.8.

3.1.8.1. Matrice de compatibilité et de soutien

Certaines fonctionnalités de cette version sont actuellement en avant-première technologique. Ces fonctionnalités expérimentales ne sont pas destinées à être utilisées en production.

Dans le tableau, les caractéristiques sont marquées par les statuts suivants :

TP

Avant-première technologique

GA

Disponibilité générale

Notez l'étendue de l'assistance suivante sur le portail client de Red Hat pour ces fonctionnalités :

Tableau 3.2. Matrice de compatibilité et de soutien

FonctionnalitéVersionStatut de soutien

Pipelines

0.24

GA

CLI

0.19

GA

Catalogue

0.24

GA

Déclencheurs

0.14

TP

Ressources en gazoducs

-

TP

Pour toute question ou commentaire, vous pouvez envoyer un courriel à l'équipe produit à l'adresse pipelines-interest@redhat.com.

3.1.8.2. Nouvelles fonctionnalités

En plus des corrections et des améliorations de la stabilité, les sections suivantes mettent en évidence les nouveautés de Red Hat OpenShift Pipelines 1.5.

  • Les exécutions de pipelines et de tâches seront automatiquement élaguées par une tâche cron dans l'espace de noms cible. La tâche cron utilise la variable d'environnement IMAGE_JOB_PRUNER_TKN pour obtenir la valeur de tkn image. Avec cette amélioration, les champs suivants sont introduits dans la ressource personnalisée TektonConfig:

    ...
    pruner:
      resources:
        - pipelinerun
        - taskrun
      schedule: "*/5 * * * *" # cron schedule
      keep: 2 # delete all keeping n
    ...
  • Dans OpenShift Container Platform, vous pouvez personnaliser l'installation du composant Tekton Add-ons en modifiant les valeurs des nouveaux paramètres clusterTasks et pipelinesTemplates dans la ressource personnalisée TektonConfig:

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonConfig
    metadata:
      name: config
    spec:
      profile: all
      targetNamespace: openshift-pipelines
      addon:
        params:
        - name: clusterTasks
          value: "true"
        - name: pipelineTemplates
          value: "true"
    ...

    La personnalisation est possible si vous créez le module complémentaire à l'aide de TektonConfig ou directement à l'aide de Tekton Add-ons. Toutefois, si les paramètres ne sont pas transmis, le contrôleur ajoute des paramètres avec des valeurs par défaut.

    Note
    • Si le module complémentaire est créé à l'aide de la ressource personnalisée TektonConfig et que vous modifiez ultérieurement les valeurs des paramètres dans la ressource personnalisée Addon, les valeurs de la ressource personnalisée TektonConfig remplacent les modifications.
    • Vous ne pouvez définir la valeur du paramètre pipelinesTemplates sur true que si la valeur du paramètre clusterTasks est true.
  • Le paramètre enableMetrics est ajouté à la ressource personnalisée TektonConfig. Vous pouvez l'utiliser pour désactiver le moniteur de service, qui fait partie de Tekton Pipelines pour OpenShift Container Platform.

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonConfig
    metadata:
      name: config
    spec:
      profile: all
      targetNamespace: openshift-pipelines
      pipeline:
        params:
        - name: enableMetrics
          value: "true"
    ...
  • Les métriques OpenCensus d'Eventlistener, qui capturent les métriques au niveau du processus, sont ajoutées.
  • Les déclencheurs disposent désormais d'un sélecteur d'étiquettes ; vous pouvez configurer les déclencheurs d'un auditeur d'événements à l'aide d'étiquettes.
  • La définition de la ressource personnalisée ClusterInterceptor pour l'enregistrement des intercepteurs a été ajoutée, ce qui vous permet d'enregistrer de nouveaux types Interceptor que vous pouvez ajouter. En outre, les modifications suivantes ont été apportées :

    • Dans les spécifications du déclencheur, vous pouvez configurer les intercepteurs à l'aide d'une nouvelle API qui comprend un champ ref pour faire référence à un intercepteur de cluster. En outre, vous pouvez utiliser le champ params pour ajouter des paramètres qui seront transmis aux intercepteurs pour traitement.
    • Les intercepteurs intégrés CEL, GitHub, GitLab et BitBucket ont été migrés. Ils sont mis en œuvre à l'aide de la nouvelle définition de ressource personnalisée ClusterInterceptor.
    • Les intercepteurs de base sont migrés vers le nouveau format et tous les nouveaux déclencheurs créés à l'aide de l'ancienne syntaxe passent automatiquement à la nouvelle syntaxe basée sur ref ou params.
  • Pour désactiver le préfixe du nom de la tâche ou de l'étape lors de l'affichage des journaux, utilisez l'option --prefix pour les commandes log.
  • Pour afficher la version d'un composant spécifique, utilisez le nouvel indicateur --component dans la commande tkn version.
  • La commande tkn hub check-upgrade a été ajoutée et d'autres commandes ont été révisées pour être basées sur la version du pipeline. En outre, les noms des catalogues sont affichés dans la sortie de la commande search.
  • La prise en charge des espaces de travail optionnels a été ajoutée à la commande start.
  • Si les plugins ne sont pas présents dans le répertoire plugins, ils sont recherchés dans le chemin courant.
  • La commande tkn start [task | clustertask | pipeline] démarre de manière interactive et demande la valeur params, même si les paramètres par défaut sont spécifiés. Pour arrêter les invites interactives, passez le drapeau --use-param-defaults au moment de l'invocation de la commande. Par exemple :

    $ tkn pipeline start build-and-deploy \
        -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.9/01_pipeline/03_persistent_volume_claim.yaml \
        -p deployment-name=pipelines-vote-api \
        -p git-url=https://github.com/openshift/pipelines-vote-api.git \
        -p IMAGE=image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-api \
        --use-param-defaults
  • Le champ version est ajouté dans la commande tkn task describe.
  • L'option permettant de sélectionner automatiquement des ressources telles que TriggerTemplate, ou TriggerBinding, ou ClusterTriggerBinding, ou Eventlistener, est ajoutée dans la commande describe, si une seule est présente.
  • Dans la commande tkn pr describe, une section pour les tâches ignorées a été ajoutée.
  • La prise en charge du site tkn clustertask logs a été ajoutée.
  • La fusion YAML et la variable de config.yaml sont supprimées. En outre, le fichier release.yaml peut désormais être utilisé plus facilement par des outils tels que kustomize et ytt.
  • La prise en charge des noms de ressources contenant le caractère point (".") a été ajoutée.
  • Le tableau hostAliases de la spécification PodTemplate est ajouté à l'annulation de la résolution des noms d'hôtes au niveau du pod. Il est obtenu en modifiant le fichier /etc/hosts.
  • Une variable $(tasks.status) est introduite pour accéder à l'état d'exécution global des tâches.
  • Un point d'entrée binaire pour Windows a été ajouté.

3.1.8.3. Fonctionnalités obsolètes

  • Dans les expressions when, la prise en charge des champs écrits en PascalCase est supprimée. Les expressions when ne prennent en charge que les champs écrits en minuscules.

    Note

    Si vous avez appliqué un pipeline avec des expressions when dans Tekton Pipelines v0.16 (Operator v1.2.x), vous devez le réappliquer.

  • Lorsque vous mettez à niveau Red Hat OpenShift Pipelines Operator vers v1.5, les tâches de cluster openshift-client et openshift-client-v-1-5-0 ont le paramètre SCRIPT. Cependant, le paramètre ARGS et la ressource git sont supprimés de la spécification de la tâche de cluster openshift-client. Il s'agit d'un changement radical, et seules les tâches de cluster qui n'ont pas de version spécifique dans le champ name de la ressource ClusterTask sont mises à niveau de manière transparente.

    Pour éviter que le pipeline ne s'interrompe, utilisez le paramètre SCRIPT après la mise à niveau, car il déplace les valeurs précédemment spécifiées dans le paramètre ARGS vers le paramètre SCRIPT de la tâche de cluster. Par exemple :

    ...
    - name: deploy
      params:
      - name: SCRIPT
        value: oc rollout status <deployment-name>
      runAfter:
        - build
      taskRef:
        kind: ClusterTask
        name: openshift-client
    ...
  • Lorsque vous mettez à niveau Red Hat OpenShift Pipelines Operator v1.4 vers v1.5, les noms de profil dans lesquels la ressource personnalisée TektonConfig est installée changent désormais.

    Tableau 3.3. Profils pour TektonConfig ressource personnalisée

    Profils dans les pipelines 1.5Profil correspondant dans Pipelines 1.4Installation des composants Tekton

    Tous (default profile)

    Tous (default profile)

    Pipelines, déclencheurs, modules complémentaires

    De base

    Défaut

    Pipelines, déclencheurs

    Lite

    De base

    Pipelines

    Note

    Si vous avez utilisé profile: all dans l'instance config de la ressource personnalisée TektonConfig, aucune modification n'est nécessaire dans la spécification de la ressource.

    Toutefois, si l'opérateur installé est dans le profil Default ou Basic avant la mise à niveau, vous devez modifier l'instance config de la ressource personnalisée TektonConfig après la mise à niveau. Par exemple, si la configuration était profile: basic avant la mise à niveau, assurez-vous qu'elle est profile: lite après la mise à niveau vers Pipelines 1.5.

  • Les champs disable-home-env-overwrite et disable-working-dir-overwrite sont désormais obsolètes et seront supprimés dans une prochaine version. Pour cette version, la valeur par défaut de ces drapeaux est fixée à true pour des raisons de compatibilité ascendante.

    Note

    Dans la prochaine version (Red Hat OpenShift Pipelines 1.6), la variable d'environnement HOME ne sera pas automatiquement définie à /tekton/home, et le répertoire de travail par défaut ne sera pas défini à /workspace pour les exécutions de tâches. Ces valeurs par défaut entrent en conflit avec toute valeur définie par l'image Dockerfile de l'étape.

  • Les champs ServiceType et podTemplate sont supprimés de la spécification EventListener.
  • Le compte de service du contrôleur ne demande plus l'autorisation de lister et de surveiller les espaces de noms à l'échelle du cluster.
  • Le statut de la ressource EventListener est assorti d'une nouvelle condition appelée Ready.

    Note

    À l'avenir, les autres conditions d'état de la ressource EventListener seront supprimées au profit de la condition d'état Ready.

  • Les champs eventListener et namespace de la réponse EventListener sont obsolètes. Utilisez plutôt le champ eventListenerUID.
  • Le champ replicas est obsolète dans la spécification EventListener. Le champ spec.replicas est déplacé vers spec.resources.kubernetesResource.replicas dans la spécification KubernetesResource.

    Note

    Le champ replicas sera supprimé dans une prochaine version.

  • L'ancienne méthode de configuration des intercepteurs de base est obsolète. Cependant, elle continue de fonctionner jusqu'à ce qu'elle soit supprimée dans une prochaine version. À la place, les intercepteurs d'une ressource Trigger sont désormais configurés à l'aide d'une nouvelle syntaxe basée sur ref et params. Le webhook par défaut qui en résulte passe automatiquement de l'ancienne syntaxe à la nouvelle syntaxe pour les nouveaux déclencheurs.
  • Utilisez rbac.authorization.k8s.io/v1 au lieu de l'ancien rbac.authorization.k8s.io/v1beta1 pour la ressource ClusterRoleBinding.
  • Dans les rôles de grappe, l'accès en écriture à l'échelle de la grappe à des ressources telles que serviceaccounts, secrets, configmaps, et limitranges est supprimé. En outre, l'accès aux ressources telles que deployments, statefulsets, et deployment/finalizers est supprimé pour l'ensemble de la grappe.
  • La définition de la ressource personnalisée image dans le groupe caching.internal.knative.dev n'est plus utilisée par Tekton et est exclue de cette version.

3.1.8.4. Problèmes connus

  • La tâche cluster git-cli est construite à partir de l'image de base alpine/git, qui attend /root comme répertoire personnel de l'utilisateur. Cependant, cela n'est pas explicitement défini dans la tâche de cluster git-cli.

    Dans Tekton, le répertoire d'accueil par défaut est remplacé par /tekton/home à chaque étape d'une tâche, sauf indication contraire. Cet écrasement de la variable d'environnement $HOME de l'image de base entraîne l'échec de la tâche de cluster git-cli.

    Ce problème devrait être corrigé dans les prochaines versions. Pour Red Hat OpenShift Pipelines 1.5 et les versions antérieures, vous pouvez use any one of the following workarounds pour éviter l'échec de la tâche de cluster git-cli:

    • Définissez la variable d'environnement $HOME dans les étapes, afin qu'elle ne soit pas écrasée.

      1. [OPTIONNEL] Si vous avez installé Red Hat OpenShift Pipelines à l'aide de l'Opérateur, clonez la tâche de cluster git-cli dans une tâche séparée. Cette approche garantit que l'Opérateur n'écrase pas les modifications apportées à la tâche de cluster.
      2. Exécutez la commande oc edit clustertasks git-cli.
      3. Ajouter la variable d'environnement HOME au YAML de l'étape :

        ...
        steps:
          - name: git
            env:
            - name: HOME
              value: /root
            image: $(params.BASE_IMAGE)
            workingDir: $(workspaces.source.path)
        ...
        Avertissement

        Pour Red Hat OpenShift Pipelines installé par l'Opérateur, si vous ne clonez pas la tâche de cluster git-cli dans une tâche séparée avant de modifier la variable d'environnement HOME, les modifications sont écrasées lors de la réconciliation de l'Opérateur.

    • Désactive l'écrasement de la variable d'environnement HOME dans la carte de configuration feature-flags.

      1. Exécutez la commande oc edit -n openshift-pipelines configmap feature-flags.
      2. Fixer la valeur de l'indicateur disable-home-env-overwrite à true.

        Avertissement
        • Si vous avez installé Red Hat OpenShift Pipelines à l'aide de l'Opérateur, les modifications sont écrasées lors de la réconciliation de l'Opérateur.
        • La modification de la valeur par défaut de l'indicateur disable-home-env-overwrite peut perturber d'autres tâches et des tâches en grappe, car elle modifie le comportement par défaut de toutes les tâches.
    • Utilisez un compte de service différent pour la tâche de cluster git-cli, car l'écrasement de la variable d'environnement HOME se produit lorsque le compte de service par défaut pour les pipelines est utilisé.

      1. Créer un nouveau compte de service.
      2. Liez votre secret Git au compte de service que vous venez de créer.
      3. Utiliser le compte de service lors de l'exécution d'une tâche ou d'un pipeline.
  • Sur IBM Power Systems, IBM Z et LinuxONE, la tâche s2i-dotnet cluster et la commande tkn hub ne sont pas prises en charge.
  • Lorsque vous exécutez des tâches de cluster Maven et Jib-Maven, l'image de conteneur par défaut n'est prise en charge que sur l'architecture Intel (x86). Par conséquent, les tâches échoueront sur les clusters IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x). Pour contourner ce problème, vous pouvez spécifier une image personnalisée en définissant la valeur du paramètre MAVEN_IMAGE sur maven:3.6.3-adoptopenjdk-11.

3.1.8.5. Problèmes corrigés

  • Les expressions when dans les tâches dag ne sont pas autorisées à spécifier la variable de contexte accédant à l'état d'exécution ($(tasks.<pipelineTask>.status)) d'une autre tâche.
  • Utilisez les UID des propriétaires plutôt que les noms des propriétaires, car cela permet d'éviter les conditions de course créées par la suppression d'un PVC volumeClaimTemplate, dans les situations où une ressource PipelineRun est rapidement supprimée puis recréée.
  • Un nouveau fichier Docker est ajouté pour pullrequest-init pour l'image build-base déclenchée par des utilisateurs non root.
  • Lorsqu'un pipeline ou une tâche est exécuté avec l'option -f et que le param dans sa définition n'a pas de type défini, une erreur de validation est générée au lieu de l'échec silencieux du pipeline ou de l'exécution de la tâche.
  • Pour les commandes tkn start [task | pipeline | clustertask], la description de l'indicateur --workspace est désormais cohérente.
  • Lors de l'analyse des paramètres, si un tableau vide est rencontré, l'aide interactive correspondante est affichée sous la forme d'une chaîne vide.

3.1.9. Notes de mise à jour pour Red Hat OpenShift Pipelines General Availability 1.4

Red Hat OpenShift Pipelines General Availability (GA) 1.4 est désormais disponible sur OpenShift Container Platform 4.7.

Note

En plus des canaux stable et preview Operator, Red Hat OpenShift Pipelines Operator 1.4.0 est livré avec les canaux dépréciés ocp-4.6, ocp-4.5, et ocp-4.4. Ces canaux dépréciés et leur prise en charge seront supprimés dans la prochaine version de Red Hat OpenShift Pipelines.

3.1.9.1. Matrice de compatibilité et de soutien

Certaines fonctionnalités de cette version sont actuellement en avant-première technologique. Ces fonctionnalités expérimentales ne sont pas destinées à être utilisées en production.

Dans le tableau, les caractéristiques sont marquées par les statuts suivants :

TP

Avant-première technologique

GA

Disponibilité générale

Notez l'étendue de l'assistance suivante sur le portail client de Red Hat pour ces fonctionnalités :

Tableau 3.4. Matrice de compatibilité et de soutien

FonctionnalitéVersionStatut de soutien

Pipelines

0.22

GA

CLI

0.17

GA

Catalogue

0.22

GA

Déclencheurs

0.12

TP

Ressources en gazoducs

-

TP

Pour toute question ou commentaire, vous pouvez envoyer un courriel à l'équipe produit à l'adresse pipelines-interest@redhat.com.

3.1.9.2. Nouvelles fonctionnalités

En plus des corrections et des améliorations de la stabilité, les sections suivantes mettent en évidence les nouveautés de Red Hat OpenShift Pipelines 1.4.

  • Les tâches personnalisées présentent les améliorations suivantes :

    • Les résultats du pipeline peuvent désormais faire référence aux résultats produits par les tâches personnalisées.
    • Les tâches personnalisées peuvent désormais utiliser des espaces de travail, des comptes de service et des modèles de pods pour créer des tâches personnalisées plus complexes.
  • La tâche finally présente les améliorations suivantes :

    • Les expressions when sont prises en charge dans les tâches finally, ce qui permet une exécution gardée efficace et une réutilisation améliorée des tâches.
    • Une tâche finally peut être configurée pour consommer les résultats de n'importe quelle tâche au sein du même pipeline.

      Note

      La prise en charge des expressions when et des tâches finally n'est pas disponible dans la console Web d'OpenShift Container Platform 4.7.

  • La prise en charge de plusieurs secrets du type dockercfg ou dockerconfigjson a été ajoutée pour l'authentification au moment de l'exécution.
  • La fonctionnalité de prise en charge de la vérification éparse avec la tâche git-clone a été ajoutée. Cela vous permet de ne cloner qu'un sous-ensemble du référentiel en tant que copie locale et de limiter la taille des référentiels clonés.
  • Vous pouvez créer des exécutions de pipeline dans un état d'attente sans les démarrer. Dans les clusters fortement sollicités, cela permet aux opérateurs de contrôler l'heure de démarrage des opérations de pipeline.
  • Veillez à définir manuellement la variable d'environnement SYSTEM_NAMESPACE pour le contrôleur ; elle était auparavant définie par défaut.
  • Un utilisateur non-root est maintenant ajouté à l'image build-base de pipelines afin que git-init puisse cloner des dépôts en tant qu'utilisateur non-root.
  • La prise en charge de la validation des dépendances entre les ressources résolues avant le début de l'exécution d'un pipeline a été ajoutée. Toutes les variables de résultat du pipeline doivent être valides, et les espaces de travail optionnels d'un pipeline ne peuvent être transmis qu'aux tâches qui s'y attendent pour que le pipeline commence à fonctionner.
  • Le contrôleur et le webhook s'exécutent en tant que groupe non root, et leurs capacités superflues ont été supprimées pour les rendre plus sûrs.
  • Vous pouvez utiliser la commande tkn pr logs pour voir les flux de journaux pour les exécutions de tâches répétées.
  • Vous pouvez utiliser l'option --clustertask de la commande tkn tr delete pour supprimer toutes les exécutions de tâches associées à une tâche de cluster particulière.
  • La possibilité d'utiliser le service Knative avec la ressource EventListener est ajoutée par l'introduction d'un nouveau champ customResource.
  • Un message d'erreur s'affiche lorsque la charge utile d'un événement n'utilise pas le format JSON.
  • Les intercepteurs de contrôle de source tels que GitLab, BitBucket et GitHub utilisent désormais la nouvelle interface de type InterceptorRequest ou InterceptorResponse.
  • Une nouvelle fonction CEL marshalJSON est implémentée pour vous permettre d'encoder un objet JSON ou un tableau en une chaîne de caractères.
  • Un gestionnaire HTTP pour servir le CEL et les intercepteurs centraux de contrôle de source a été ajouté. Il regroupe quatre intercepteurs principaux dans un seul serveur HTTP qui est déployé dans l'espace de noms tekton-pipelines. L'objet EventListener transmet les événements à l'intercepteur via le serveur HTTP. Chaque intercepteur est disponible sur un chemin différent. Par exemple, l'intercepteur CEL est disponible sur le chemin /cel.
  • La contrainte de contexte de sécurité (SCC) pipelines-scc est utilisée avec le compte de service par défaut pipeline pour les pipelines. Ce nouveau compte de service est similaire à anyuid, mais avec une différence mineure telle que définie dans le YAML pour SCC de OpenShift Container Platform 4.7 :

    fsGroup:
      type: MustRunAs

3.1.9.3. Fonctionnalités obsolètes

  • Le sous-type build-gcs dans le stockage des ressources du pipeline et l'image gcs-fetcher ne sont pas pris en charge.
  • Dans le champ taskRun des tâches en grappe, l'étiquette tekton.dev/task est supprimée.
  • Pour les webhooks, la valeur v1beta1 correspondant au champ admissionReviewVersions est supprimée.
  • L'image d'aide creds-init pour la construction et le déploiement est supprimée.
  • Dans la spécification et la liaison des déclencheurs, le champ obsolète template.name est supprimé au profit de template.ref. Vous devez mettre à jour toutes les définitions de eventListener pour utiliser le champ ref.

    Note

    La mise à niveau d'OpenShift Pipelines 1.3.x et des versions antérieures vers OpenShift Pipelines 1.4.0 interrompt les auditeurs d'événements en raison de l'indisponibilité du champ template.name. Dans ce cas, utilisez OpenShift Pipelines 1.4.1 pour bénéficier du champ template.name restauré.

  • Pour les ressources/objets personnalisés EventListener, les champs PodTemplate et ServiceType sont obsolètes au profit de Resource.
  • Le style de spécification "embedded bindings", obsolète, a été supprimé.
  • Le champ spec est supprimé du champ triggerSpecBinding.
  • La représentation de l'ID de l'événement passe d'une chaîne aléatoire de cinq caractères à un UUID.

3.1.9.4. Problèmes connus

  • Sur le site Developer, les fonctionnalités de métriques et de déclencheurs de pipeline ne sont disponibles que sur OpenShift Container Platform 4.7.6 ou les versions ultérieures.
  • Sur les systèmes IBM Power, IBM Z et LinuxONE, la commande tkn hub n'est pas prise en charge.
  • Lorsque vous exécutez les tâches Maven et Jib Maven sur des clusters IBM Power Systems (ppc64le), IBM Z et LinuxONE (s390x), définissez la valeur du paramètre MAVEN_IMAGE sur maven:3.6.3-adoptopenjdk-11.
  • Les déclencheurs génèrent une erreur résultant d'une mauvaise gestion du format JSON, si vous avez la configuration suivante dans la liaison du déclencheur :

    params:
      - name: github_json
        value: $(body)

    Pour résoudre le problème :

    • Si vous utilisez les déclencheurs v0.11.0 et plus, utilisez la fonction marshalJSON CEL, qui prend un objet ou un tableau JSON et renvoie l'encodage JSON de cet objet ou de ce tableau sous la forme d'une chaîne.
    • Si vous utilisez une version plus ancienne des déclencheurs, ajoutez l'annotation suivante dans le modèle de déclencheur :

      annotations:
        triggers.tekton.dev/old-escape-quotes: "true"
  • Lors de la mise à jour d'OpenShift Pipelines 1.3.x vers 1.4.x, vous devez recréer les routes.

3.1.9.5. Problèmes corrigés

  • Auparavant, l'étiquette tekton.dev/task avait été supprimée de l'exécution des tâches en grappe et l'étiquette tekton.dev/clusterTask avait été introduite. Les problèmes résultant de ce changement sont résolus en corrigeant les commandes clustertask describe et delete. De plus, la fonction lastrun pour les tâches est modifiée, afin de résoudre le problème de l'étiquette tekton.dev/task appliquée aux tâches et aux tâches en grappe dans les anciennes versions des pipelines.
  • Lors d'une opération interactive tkn pipeline start pipelinename, un PipelineResource est créé de manière interactive. La commande tkn p start imprime l'état de la ressource si l'état de la ressource n'est pas nil.
  • Auparavant, l'étiquette tekton.dev/task=name était supprimée des exécutions de tâches créées à partir de tâches en grappe. Ce correctif modifie la commande tkn clustertask start avec l'indicateur --last pour vérifier la présence de l'étiquette tekton.dev/task=name dans les exécutions de tâches créées.
  • Lorsqu'une tâche utilise une spécification de tâche en ligne, l'exécution de la tâche correspondante est désormais intégrée dans le pipeline lorsque vous exécutez la commande tkn pipeline describe, et le nom de la tâche est renvoyé comme étant intégré.
  • La commande tkn version permet d'afficher la version de l'outil CLI Tekton installé, sans kubeConfiguration namespace configuré ni accès à un cluster.
  • Si un argument est inattendu ou si plusieurs arguments sont utilisés, la commande tkn completion génère une erreur.
  • Auparavant, les exécutions de pipeline avec les tâches finally imbriquées dans une spécification de pipeline perdaient ces tâches finally, lorsqu'elles étaient converties en version v1alpha1 et restaurées en version v1beta1. Cette erreur survenant lors de la conversion a été corrigée afin d'éviter toute perte potentielle de données. Les exécutions de pipeline avec les tâches finally imbriquées dans une spécification de pipeline sont désormais sérialisées et stockées sur la version alpha, pour être désérialisées ultérieurement.
  • Auparavant, il y avait une erreur dans la génération de pods lorsqu'un compte de service avait le champ secrets comme {}. L'exécution de la tâche échouait avec CouldntGetTask parce que la requête GET avec un nom secret vide renvoyait une erreur, indiquant que le nom de la ressource pouvait ne pas être vide. Ce problème est corrigé en évitant d'utiliser un nom secret vide dans la requête GET kubeclient.
  • Les pipelines avec les versions de l'API v1beta1 peuvent maintenant être demandés avec la version v1alpha1, sans perdre les tâches finally. L'application de la version v1alpha1 renvoyée stockera la ressource en tant que v1beta1, la section finally étant rétablie dans son état d'origine.
  • Auparavant, un champ selfLink non défini dans le contrôleur provoquait une erreur dans les clusters Kubernetes v1.20. Comme solution temporaire, le champ source CloudEvent est défini à une valeur qui correspond à l'URI source actuel, sans la valeur du champ selfLink auto-remplie.
  • Auparavant, un nom secret comportant des points, tel que gcr.io, entraînait l'échec de la création d'une exécution de tâche. Cela était dû au fait que le nom secret était utilisé en interne dans le cadre d'un nom de montage de volume. Le nom de montage du volume est conforme à l'étiquette DNS RFC1123 et interdit les points dans le nom. Ce problème est résolu en remplaçant le point par un tiret, ce qui permet d'obtenir un nom lisible.
  • Les variables contextuelles sont désormais validées dans les tâches finally.
  • Auparavant, lorsque l'outil de rapprochement des tâches recevait une tâche qui n'avait pas fait l'objet d'une mise à jour de statut contenant le nom du module qu'elle avait créé, l'outil de rapprochement des tâches répertoriait les modules associés à la tâche. Il utilise les étiquettes de l'exécution de la tâche, qui ont été propagées dans le module, pour trouver le module. La modification de ces étiquettes pendant l'exécution de la tâche a eu pour effet que le code n'a pas trouvé le module existant. Par conséquent, des modules en double ont été créés. Ce problème est résolu en modifiant le réconciliateur de tâches pour qu'il n'utilise que l'étiquette tekton.dev/taskRun contrôlée par Tekton lors de la recherche de la nacelle.
  • Auparavant, lorsqu'un pipeline acceptait un espace de travail optionnel et le transmettait à une tâche du pipeline, l'outil de réconciliation de l'exécution du pipeline s'arrêtait avec une erreur si l'espace de travail n'était pas fourni, même si une liaison d'espace de travail manquante est un état valide pour un espace de travail optionnel. Ce problème est corrigé en s'assurant que le réconciliateur d'exécution de pipeline n'échoue pas à créer une exécution de tâche, même si un espace de travail optionnel n'est pas fourni.
  • L'ordre trié des statuts d'étape correspond à l'ordre des conteneurs d'étape.
  • Auparavant, le statut d'exécution de la tâche était défini sur unknown lorsqu'un module rencontrait la raison CreateContainerConfigError, ce qui signifiait que la tâche et le pipeline s'exécutaient jusqu'à ce que le module s'arrête. Ce problème est résolu en définissant le statut d'exécution de la tâche sur false, de sorte que la tâche soit considérée comme ayant échoué lorsque le module rencontre la raison CreateContainerConfigError.
  • Auparavant, les résultats du pipeline étaient résolus lors de la première réconciliation, après l'achèvement de l'exécution du pipeline. Cela pouvait faire échouer la résolution et entraîner l'écrasement de la condition Succeeded de l'exécution du pipeline. En conséquence, les informations sur l'état final étaient perdues, ce qui risquait de perturber les services qui surveillaient les conditions de l'exécution du pipeline. Ce problème est résolu en déplaçant la résolution des résultats du pipeline à la fin d'une réconciliation, lorsque le pipeline est placé dans une condition Succeeded ou True.
  • La variable d'état d'exécution est désormais validée. Cela évite de valider les résultats de la tâche tout en validant les variables de contexte pour accéder à l'état d'exécution.
  • Auparavant, un résultat de pipeline contenant une variable non valide était ajouté à l'exécution du pipeline avec l'expression littérale de la variable intacte. Il était donc difficile d'évaluer si les résultats étaient correctement remplis. Ce problème est résolu en filtrant les résultats de l'exécution de la chaîne de production qui font référence à des exécutions de tâches qui ont échoué. Désormais, un résultat de pipeline qui contient une variable non valide ne sera pas du tout émis par le pipeline.
  • La commande tkn eventlistener describe a été corrigée pour éviter les plantages en l'absence de modèle. Elle affiche également les détails des références des déclencheurs.
  • Les mises à niveau d'OpenShift Pipelines 1.3.x et des versions antérieures vers OpenShift Pipelines 1.4.0 interrompent les auditeurs d'événements en raison de l'indisponibilité de template.name. Dans OpenShift Pipelines 1.4.1, template.name a été restauré pour éviter d'interrompre les auditeurs d'événements dans les déclencheurs.
  • Dans OpenShift Pipelines 1.4.1, la ressource personnalisée ConsoleQuickStart a été mise à jour pour s'aligner sur les capacités et le comportement d'OpenShift Container Platform 4.7.

3.1.10. Notes de publication pour Red Hat OpenShift Pipelines Technology Preview 1.3

3.1.10.1. Nouvelles fonctionnalités

Red Hat OpenShift Pipelines Technology Preview (TP) 1.3 est maintenant disponible sur OpenShift Container Platform 4.7. Red Hat OpenShift Pipelines TP 1.3 est mis à jour pour prendre en charge :

  • Tekton Pipelines 0.19.0
  • Tekton tkn CLI 0.15.0
  • Tekton Triggers 0.10.2
  • tâches en grappe basées sur le catalogue Tekton 0.19.0
  • IBM Power Systems sur OpenShift Container Platform 4.7
  • IBM Z et LinuxONE sur OpenShift Container Platform 4.7

En plus des corrections et des améliorations de stabilité, les sections suivantes mettent en évidence les nouveautés de Red Hat OpenShift Pipelines 1.3.

3.1.10.1.1. Pipelines
  • Les tâches qui construisent des images, telles que les tâches S2I et Buildah, émettent désormais une URL de l'image construite qui inclut l'image SHA.
  • Les conditions dans les tâches du pipeline qui font référence à des tâches personnalisées ne sont pas autorisées car la définition des ressources personnalisées (CRD) de Condition a été supprimée.
  • L'expansion des variables est désormais ajoutée dans le CRD Task pour les champs suivants : spec.steps[].imagePullPolicy et spec.sidecar[].imagePullPolicy.
  • Vous pouvez désactiver le mécanisme d'authentification intégré dans Tekton en définissant le drapeau de fonctionnalité disable-creds-init sur true.
  • Résolu lorsque les expressions sont maintenant listées dans les sections Skipped Tasks et Task Runs dans le champ Status de la configuration PipelineRun.
  • La commande git init peut désormais cloner des sous-modules récursifs.
  • L'auteur d'un CR Task peut désormais spécifier un délai pour une étape dans la spécification Task.
  • Vous pouvez maintenant baser l'image du point d'entrée sur l'image distroless/static:nonroot et lui donner un mode pour se copier vers la destination, sans dépendre de la présence de la commande cp dans l'image de base.
  • Vous pouvez désormais utiliser l'indicateur de configuration require-git-ssh-secret-known-hosts pour interdire l'omission d'hôtes connus dans le secret SSH de Git. Lorsque la valeur de l'indicateur est true, vous devez inclure le champ known_host dans le secret SSH de Git. La valeur par défaut de l'indicateur est false.
  • Le concept d'espaces de travail optionnels est désormais introduit. Une tâche ou un pipeline peut déclarer un espace de travail optionnel et modifier conditionnellement son comportement en fonction de sa présence. Une tâche ou un pipeline peut également omettre cet espace de travail, modifiant ainsi le comportement de la tâche ou du pipeline. Les espaces de travail par défaut de l'exécution de la tâche ne sont pas ajoutés à la place d'un espace de travail optionnel omis.
  • L'initialisation des identifiants dans Tekton détecte désormais un identifiant SSH utilisé avec une URL non-SSH, et vice versa dans les ressources du pipeline Git, et enregistre un avertissement dans les conteneurs d'étapes.
  • Le contrôleur d'exécution des tâches émet un avertissement si l'affinité spécifiée par le modèle de pod est remplacée par l'assistant d'affinité.
  • Le réconciliateur d'exécution des tâches enregistre désormais des mesures pour les événements du nuage qui sont émis une fois l'exécution d'une tâche terminée. Cela inclut les tentatives.
3.1.10.1.2. L'interface de programmation des pipelines
  • La prise en charge de --no-headers flag est maintenant ajoutée aux commandes suivantes : tkn condition list,tkn triggerbinding list,tkn eventlistener list,tkn clustertask list, tkn clustertriggerbinding list.
  • Lorsqu'elles sont utilisées ensemble, les options --last ou --use sont prioritaires sur les options --prefix-name et --timeout.
  • La commande tkn eventlistener logs a été ajoutée pour afficher les journaux de EventListener.
  • Les commandes de tekton hub sont désormais intégrées dans le CLI de tkn.