CI/CD
Contient des informations sur les builds, les pipelines et GitOps pour OpenShift Container Platform
Résumé
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.
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
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 estSerial
, 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 soitGit
, pour pointer vers un dépôt de code,Dockerfile
, pour construire à partir d'un fichier Docker en ligne, ouBinary
, 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égieSource
,Docker
, ouCustom
ici. Cet exemple utilise l'image du conteneurruby-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 :
- 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.
-
Le processus de construction change les répertoires en
contextDir
, s'il y en a un de défini. - Le fichier Docker en ligne, s'il existe, est écrit dans le répertoire courant.
-
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 decontextDir
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
demyinputimage
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
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 champref
permet d'extraire une référence Git spécifique. Un champref
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
).
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
.
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
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
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://
oussh://
-
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.
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>
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
.
-
Ajoutez les fichiers
client.crt
,cacert.crt
, etclient.key
au dossier/var/run/secrets/openshift.io/source/
dans le code source de l'application. 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
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
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
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
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
Générer les informations d'identification de la clé SSH :
$ ssh-keygen -t ed25519 -C "your_email@example.com"
NoteLa 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
ouid_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é.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.
AvertissementLe 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).NoteAssurez-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.
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
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
.
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 sourceBinary
défini, il est effectivement ignoré et remplacé par ce que le client envoie. -
Si votre
BuildConfig
a un type de sourceGit
défini, il est dynamiquement désactivé, puisqueBinary
etGit
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
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 :
-
Un fichier
settings.xml
configuré avec l'URL du miroir et les paramètres de connexion. -
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 valeurDNS_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 cartedata
. Ce champ est en écriture seule. La valeur n'est renvoyée que par le champdata
. - 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.
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.
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
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
Créez le pod pour référencer votre secret :
oc create -f <votre_fichier_yaml_>.yaml
Obtenir les journaux :
$ oc logs secret-example-pod
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
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 :
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 fichiersettings.xml
.AstuceVous 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>
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éeid_rsa
.AstuceVous 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
Ajoutez la carte de configuration et le secret à la section
source
de l'objetBuildConfig
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.
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"]
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.
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.
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"
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
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.Ajoutez un champ
pushSecret
dans la sectionoutput
deBuildConfig
et attribuez-lui le nom dusecret
que vous avez créé, c'est-à-diredockerhub
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 servicebuilder
. 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
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
NoteCet 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 servicebuilder
. 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 champpullSecret
, exécutez :$ oc secrets link builder dockerhub
NoteVous devez spécifier une image
from
dans la spécificationBuildConfig
pour bénéficier de cette fonctionnalité. Les constructions de stratégie Docker générées paroc new-build
ouoc 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
.
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.
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'adresseJsonPath
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
.
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
Ressources complémentaires
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
ettls.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'annotationservice.beta.openshift.io/expiry
sur le secret, qui est au format RFC3339.
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 :
Variable | Description |
---|---|
| Nom de la construction |
| Espace de noms de la construction |
| L'URL source de la construction |
| La référence Git utilisée dans la construction |
| 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 :
Étiquette | Description |
---|---|
| Auteur du commit source utilisé dans le build |
| Date du commit source utilisé dans le build |
| Hash du commit source utilisé dans le build |
| Message du commit source utilisé dans la construction |
| Branche ou référence spécifiée dans la source |
| 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.
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.
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"
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
surSkipLayers
: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.
Conditions préalables
Procédure
Dans la définition
dockerStrategy
de l'objetBuildConfig
, ajoutez tous les volumes de construction au tableauvolumes
. 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
, ouCSI
. - 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.
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
ousave-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
, etsave-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.
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 :
- Un script spécifié dans la configuration de la construction.
-
Un script trouvé dans le répertoire source de l'application
.s2i/bin
. -
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_dir
chemin absolu à l'intérieur de l'image vers un répertoire où se trouvent les scripts S2I. -
file:///path_to_scripts_dir
chemin 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énario | Description |
---|---|
|
Le script
|
|
Le script |
|
Le script
Ces dépendances sont rassemblées dans un fichier |
|
Le script |
|
Le script
Note
L'emplacement suggéré pour placer l'application de test construite par votre script |
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.
Conditions préalables
Procédure
Dans la définition
sourceStrategy
de l'objetBuildConfig
, ajoutez tous les volumes de construction au tableauvolumes
. 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
, ouCSI
. - 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.
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
etmountPath
du fichier YAMLstrategy
:strategy: customStrategy: secrets: - secretSource: 1 name: "secret1" mountPath: "/tmp/secret1" 2 - secretSource: name: "secret2" mountPath: "/tmp/secret2"
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
Définir un proxy HTTP personnalisé à utiliser lors de la construction :
customStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
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 variable | Description |
---|---|
|
L'intégralité du JSON sérialisé de la définition de l'objet |
| L'URL d'un dépôt Git contenant les sources à construire. |
|
Utilise la même valeur que |
| Spécifie le sous-répertoire du dépôt Git à utiliser lors de la construction. Uniquement présent s'il est défini. |
| La référence Git à construire. |
| La version du master OpenShift Container Platform qui a créé cet objet de construction. |
| Le registre de l'image du conteneur dans lequel l'image doit être transférée. |
| Le nom de l'étiquette de l'image du conteneur pour l'image en cours de construction. |
|
Chemin d'accès aux informations d'identification du registre des conteneurs pour l'exécution d'une opération |
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 :
-
La définition de l'objet
Build
contient toutes les informations nécessaires sur les paramètres d'entrée de la construction. - Exécuter le processus de construction.
- 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
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
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 dejenkinsfile
à utiliser par rapport à la sourcecontextDir
.
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
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 sourcecontextDir
de votre référentiel. -
Un nom de fichier spécifié via le champ
jenkinsfilePath
de la sectionJenkinsPipelineStrategy
de votre BuildConfig, qui est relatif à la sourcecontextDir
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 sourcecontextDir
. SicontextDir
est omis, la valeur par défaut est la racine du référentiel. SijenkinsfilePath
est omis, la valeur par défaut estjenkinsfile
.
2.5.4.3. Utilisation de variables d'environnement pour la construction de pipelines
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.
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
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
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
.Créez un fichier nommé
nodejs-sample-pipeline.yaml
avec le contenu suivant :NoteCela crée un objet
BuildConfig
qui utilise la stratégie du pipeline Jenkins pour construire, déployer et mettre à l'échelle l'application d'exempleNode.js/MongoDB
.kind: "BuildConfig" apiVersion: "v1" metadata: name: "nodejs-sample-pipeline" spec: strategy: jenkinsPipelineStrategy: jenkinsfile: <pipeline content from below> type: JenkinsPipeline
Après avoir créé un objet
BuildConfig
à l'aide d'un objetjenkinsPipelineStrategy
, vous indiquez au pipeline ce qu'il doit faire à l'aide d'un objet inlinejenkinsfile
:NoteCet 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'objetBuildConfig
en utilisant le style littéral YAML, bien que l'inclusion d'unjenkinsfile
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.
NoteL'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.
Créez le Pipeline
BuildConfig
dans votre cluster OpenShift Container Platform :$ oc create -f nodejs-sample-pipeline.yaml
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
Démarrer le pipeline :
$ oc start-build nodejs-sample-pipeline
NoteVous 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 commenodejs-mongodb-example:stage
.
-
Toutes les ressources créées précédemment avec l'étiquette
Le pod de l'agent est supprimé, s'il était nécessaire pour le pipeline.
NoteLa 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 :
- Créez un nouveau projet OpenShift Container Platform.
- Créez un secret contenant les informations d'identification permettant d'accéder à un dépôt de code source privé.
- Créer une configuration de construction.
-
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. - 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.
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
- Examiner comment accorder des autorisations de construction personnalisée.
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
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"]
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
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
Définissez un objet
BuildConfig
qui construira votre image de constructeur personnalisée :$ oc new-build --binary --strategy=docker --name custom-builder-image
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
Créez un fichier nommé
buildconfig.yaml
. Ce fichier définit l'objetBuildConfig
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.
Créer le site
BuildConfig
:$ oc create -f buildconfig.yaml
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: {}
Créer le flux d'images :
$ oc create -f imagestream.yaml
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 logiquebuild.sh
invoque Buildah pour construire le sitedockerfile.sample
qui a été intégré dans l'image de construction personnalisée, puis utilise Buildah pour pousser la nouvelle image vers le sitesample-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
:
Option | Description |
---|---|
| Spécifie un répertoire qui sera archivé et utilisé comme entrée binaire pour la construction. |
| 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. |
|
Spécifie un chemin vers un dépôt local à utiliser comme entrée binaire pour une compilation. Ajoutez l'option |
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.
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
-
Dans la vue Builds de la perspective Developer, cliquez sur le menu
pour voir l'option Edit BuildConfig.
- Cliquez sur Edit BuildConfig pour voir l'option Form view.
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é.
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.
- 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.
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.
-
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 siteBuildConfig
, 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
.
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 |
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'adressesourceStrategy
oudockerStrategy
à l'adresseBuildConfig
: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é.
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"
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
Pour configurer un GitHub Webhook :
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
- Copiez et collez cette URL dans GitHub, à partir de la console web de GitHub.
- Dans votre dépôt GitHub, sélectionnez Add Webhook à partir de Settings → Webhooks.
- Collez l'URL dans le champ Payload URL.
-
Changez le Content Type de la valeur par défaut de GitHub
application/x-www-form-urlencoded
àapplication/json
. 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.
NoteGogs 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.
Avec un fichier contenant une charge utile JSON valide, tel que
payload.json
, vous pouvez déclencher manuellement le webhook aveccurl
:$ 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
Pour configurer un GitLab Webhook :
Décrire le site
BuildConfig
pour obtenir l'URL du webhook :$ oc describe bc <name>
-
Copiez l'URL du webhook en remplaçant
<secret>
par votre valeur secrète. - Suivez les instructions d'installation de GitLab pour coller l'URL du webhook dans les paramètres de votre dépôt GitLab.
Avec un fichier contenant une charge utile JSON valide, tel que
payload.json
, vous pouvez déclencher manuellement le webhook aveccurl
:$ 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
Pour configurer un Webhook Bitbucket :
Décrivez le "BuildConfig" pour obtenir l'URL du webhook :
$ oc describe bc <name>
-
Copiez l'URL du webhook en remplaçant
<secret>
par votre valeur secrète. - Suivez les instructions de configuration de Bitbucket pour coller l'URL du webhook dans les paramètres de votre référentiel Bitbucket.
Avec un fichier contenant une charge utile JSON valide, tel que
payload.json
, vous pouvez déclencher manuellement le webhook aveccurl
:$ 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
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
.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 deBuildConfig
, ces dernières sont prioritaires. Par défaut, les variables d'environnement transmises par webhook sont ignorées. Définissez le champallowEnv
àtrue
dans la définition du webhook pour activer ce comportement.
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êteContent-Type
enapplication/yaml
ouapplication/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êtePOST
.
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.
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
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 nomdocker-registry
et fonctionnant dans OpenShift Container Platform.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'imageImageStream
:strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "ruby-20-centos7:latest"
Dans ce cas, la définition
sourceStrategy
consomme la baliselatest
du flux d'images nomméruby-20-centos7
situé dans cet espace de noms.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
etTag
tels que définis par le champfrom
de la stratégie de construction. L'objetimageChange
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 champfrom
qui fait référence auImageStreamTag
à 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
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
Dans
buildConfig.status.imageChangeTriggers
pour identifier le sitelastTriggerTime
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`.
-
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 leImageStreamTag
lorsque le dernier build a été déclenché à partir de ceBuildConfig
. -
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 siteImageStreamTag
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"
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
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
, utilisezcommand
et/ouargs
.NoteLe 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 descript
peut être plus pratique.Commande avec arguments :
postCommit: command: ["bundle", "exec", "rake", "test"] args: ["--verbose"]
Cette forme est équivalente à l'ajout des arguments à
command
.
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
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
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
, andmemory
parameters are optional:apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: resources: limits: cpu: "100m" 1 memory: "256Mi" 2
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 unrequests
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 votreBuildConfig
. L'exemple suivant montre la partie d'unBuildConfig
spécifiant le champcompletionDeadlineSeconds
pour 30 minutes :spec: completionDeadlineSeconds: 1800
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é.
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'adresseBuildConfig
, 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
etkey2=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.
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'imagesartifact-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
Limitez le nombre de constructions précédentes qui sont conservées en fournissant une valeur entière positive pour
successfulBuildsHistoryLimit
oufailedBuildsHistoryLimit
dans votreBuildConfig
, par exemple :apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: successfulBuildsHistoryLimit: 2 1 failedBuildsHistoryLimit: 2 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.
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
parSerial
ouSerialLatestOnly
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
enSerialLatestOnly
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 nomsopenshift
, 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
AstuceVous pouvez également appliquer le YAML suivant pour créer un
ImageStreamTag
dans l'espace de nomsopenshift
: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
AstuceVous 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.
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
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
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
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
Ressources complémentaires
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.
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'objetSecret
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 commandeoc 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 CRSharedSecret
donnée. En d'autres termes, vous pouvez exécuteroc adm policy who-can use <identifier of specific SharedSecret>
pour voir si le compte de servicebuilder
de votre espace de noms est répertorié.
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
Accorder au compte de service
builder
les autorisations RBAC pour utiliser l'instance CRSharedSecret
en utilisantoc apply
avec un contenu YAML :NoteActuellement,
kubectl
etoc
ont une logique de cas spécial codée en dur qui limite le verbeuse
aux rôles centrés sur la sécurité des pods. Par conséquent, vous ne pouvez pas utiliseroc create role …
pour créer le rôle nécessaire à la consommation des instances CRSharedSecret
.Exemple de commande
oc apply -f
avec définition de l'objet YAMLRole
$ 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
Créez le site
RoleBinding
associé au rôle en utilisant la commandeoc
:Exemple de commande
oc create rolebinding
$ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder
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
Lancez une construction à partir de l'objet
BuildConfig
et suivez les journaux avec la commandeoc
.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
NoteCertaines 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égie | Sous-ressource | Rô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
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"
.
Supprimer le rôle :
$ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated
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
Pour chaque rôle, indiquez les sous-ressources qui correspondent à la ressource de la stratégie à désactiver.
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
etbuilds/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'utilisateurdevuser
:$ oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser
AvertissementAccorder à 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 projetdevproject
à l'utilisateurdevuser
:$ 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ètres | Description |
---|---|
|
Contient des informations à l'échelle du cluster sur la manière de gérer les builds. Le nom canonique, et le seul valide, est
|
| Contrôle les informations par défaut pour les constructions.
Vous pouvez remplacer les valeurs en définissant les variables d'environnement
Les valeurs qui ne sont pas définies ici sont héritées de DefaultProxy.
|
|
|
| Contrôle les paramètres d'annulation des constructions.
|
|
|
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, estcluster
.- 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 quegit 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'adresseBuildConfig
.- 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 dansBuildConfig
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
etservice.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-
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 nomsopenshift-config
. domain
est la clé dans le siteConfigMap
etvalue
est le certificat codé en PEM.-
Chaque autorité de certification doit être associée à un domaine. Le format du domaine est
hostname[..port]
.
-
Chaque autorité de certification doit être associée à un domaine. Le format du domaine est
-
Le nom
ConfigMap
doit être défini dans le champspec.additionalTrustedCA
de la ressourceimage.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
Créez un site
ConfigMap
dans l'espace de nomsopenshift-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é deConfigMap
est le nom d'hôte du registre au formathostname[..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
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 Pipelines | Version du composant | Version d'OpenShift | Statut 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
ouTaskRun
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 modulesPipelineRuns
etTaskRuns
. Cette mise à jour ajoute également une nouvelle configuration par défaut nomméeforbidden-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.
NotePour désactiver cette mise à jour, définissez l'indicateur
enable-custom-tasks
surfalse
dans la ressource personnaliséefeature-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 deTaskRuns
créée à partir dePipelineRuns
peut désormais utiliser la version de l'APIv1beta1.CustomRun
au lieu dev1alpha1.Run
, si l'indicateur de fonctionnalitécustom-task-version
est défini surv1beta1
, au lieu de la valeur par défautv1alpha1
.NoteVous 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 demandesv1beta1.CustomRun
.-
Cette mise à jour ajoute un nouveau champ
retries
aux spécificationsv1beta1.TaskRun
etv1.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
, etTaskRuns
de la versionv1
de l'API ainsi que des objetsCustomRun
de la versionv1beta1
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.
NotePour activer ou désactiver cette mise à jour, définissez la valeur du paramètre
githubOwners
surtrue
oufalse
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 entls.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
ouPipeline
. -
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 APIv1beta1
etv1
pour ces ressources. -
Cette mise à jour ajoute la prise en charge d'un paramètre de type d'objet dans les commandes
start
etdescribe
.
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
etTaskRun
. -
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 formatin-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 objetTaskRun
.
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èlesv1
etv1beta1
, que Pipelines as Code lit pour la génération de PR. Le PR est créé en tant quev1
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'unPipelineRun
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
etCloudEvent
dans Tekton CLI. Vous ne pouvez pas créer de ressources de pipeline en utilisant la commandetkn pipelineresource create
. De plus, les ressources de pipeline ne sont plus prises en charge dans la commandestart
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 commandetkn 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 commandetkn task start
sont désormais obsolètes car l'APIv1
ne prend pas en charge les ressources de pipeline. -
Dans Red Hat OpenShift Pipelines 1.10, l'indicateur
-r
qui était utilisé avec la commandetkn pipeline start
est obsolète car l'APIv1
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
avecfull
etminimal
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é enminimal
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
-
Suppression de la grappe
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 commandeopc 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 commandetkn-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 fonctionmarshalJSON
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
etverify
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'APICATALOG_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
etstatus.taskruns
ànil
avecminimal EmbeddedStatus
-
Le paramètre
status.childReferences
ànil
avecfull EmbeddedStatus
-
Les paramètres
-
Cette mise à jour ajoute une configuration de conversion au CRD
ResolutionRequest
. Cette mise à jour configure correctement la conversion de la requêtev1alpha1.ResolutionRequest
vers la requêtev1beta1.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
etPipelineRef
à 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
etstderrConfig
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éfinitionPipelineResults
. 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éfinirNamespacedInterceptor
. Vous pouvez utiliserNamespacedInterceptor
dans la sectionkind
de la référence aux intercepteurs dans les déclencheurs ou dans la spécificationEventListener
. -
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 dansTriggerBinding
. 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.
-
Les déclencheurs effectuent la validation des certificats pour les intercepteurs principaux et transmettent un nouveau certificat à
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 deTaskRun
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
etverify
à l'outil CLItkn
. - 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 CLItkn
paropc
.Important-
Le nouvel outil CLI
opc
est une fonctionnalité de l'aperçu technologique. -
opc
remplaceratkn
avec des fonctionnalités supplémentaires spécifiques à Red Hat OpenShift Pipelines, qui ne s'intègrent pas nécessairement danstkn
.
-
Le nouvel outil CLI
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 unTriggerBinding
sur l'ensemble de votre cluster.
3.1.4.1.5. Résolveurs
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
, etenable-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 formatmap[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
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
etARTIFACT_DIGEST
. -
Avant cette mise à jour, seules les attestations
TaskRun
étaient prises en charge. Cette mise à jour ajoute la prise en charge des attestationsPipelineRun
. -
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
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'APIConfigMap
. 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
NoteSi 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 dePipelineRuns
en cours d'exécution pour un référentiel à la fois. LesPipelineRuns
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 commandestkn-pac ls
ettkn-pac describe
-
Importe la documentation des journaux de
tkn-pac
-
Affiche
pipelineruntimeout
comme un échec dans les commandestkn-pac ls
ettkn-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'objetk8s Secret
existant sans mettre à jour le référentiel. -
tkn-pac webhook update-token
: Met à jour le jeton de fournisseur pour un objetk8s 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 commandetkn-pac logs
. -
Avec cette mise à jour, la commande
tkn-pac resolve
demande un jeton lors de la détection d'ungit_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 avecPipelineRun
. Les secrets sont nettoyés en même temps quePipelineRun
, 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 commandetkn-pac describe
affiche le lien du journal lors de la description d'une ressourcePipelineRun
. -
Avec cette mise à jour, les journaux de
tkn-pac
affichent le nom du dépôt, au lieu du nom dePipelineRun
.
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 typeWhenExpressions
à 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 commandetkn-pac webhook add
pour ajouter un webhook à un référentiel Git existant. Et utilisez la commandetkn-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 utiliserCluster Resolver
. -
Dans la version 1.9.0 de Red Hat OpenShift Pipelines, l'utilisation des champs
triggers
etnamespaceSelector
dans une seule spécificationEventListener
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écificationsEventListener
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 ressourcePipelineRun
. -
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'APItekton.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
etchains-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
surtrue
.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 commandetkn 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 commandetkn pac resolve -f <filename> -o tempfile.yaml
, puis la commandeoc 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 leTaskRun
avait été annulé par l'utilisateur ou par unPipelineRun
qui en faisait partie. Avec cette mise à jour, ce problème est résolu et les utilisateurs peuvent distinguer le statut deTaskRun
en regardant le champspec.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
sur0
, vous ne pouviez pas définir les paramètrestimeouts.tasks
outimeouts.finally
. Cette mise à jour résout le problème. Désormais, lorsque vous définissez la valeur du paramètretimeouts.pipeline
, vous pouvez définir la valeur du paramètre "timeouts.tasks" ou du paramètretimeouts.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 quelist
etpush
. Avec cette mise à jour, ce problème a été résolu et le fichierkubeconfig
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 sujetsClusterInterceptor 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ôlepipelines-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 CodeConfigMap
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'étiquettecheckrun id
, ce qui provoquait des conditions de concurrence. Avec cette mise à jour, le contrôleur de Pipelines as Code attend que l'étiquettetekton.dev/pipeline
soit mise à jour et ajoute ensuite l'étiquettecheckrun 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 commandePipelineRun
si elle existait déjà dans le dépôt git. Avec cette mise à jour, la commandetkn-pac create
est corrigée pour remplacer une commandePipelineRun
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 commandetkn 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 manquaitrefs/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 commandetkn 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
ouPipelineRuns
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 podsTaskRuns
ouPipelineRuns
dans le cluster. -
Avant cette mise à jour, sur un cluster activé avec FIPS, l'intercepteur
tekton-triggers-core-interceptors
core utilisé dans la ressourceTrigger
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 centraltekton-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 APIConfigMap
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 CLItkn
.
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
etSidecar
pour les ressourcesTaskRun
. Cette mise à jour ajoute les statuts minimaux
TaskRun
etRun
dans les statutsPipelineRun
.Pour activer cette fonctionnalité, dans la définition de la ressource personnalisée
TektonConfig
, dans la sectionpipeline
, vous devez définir le champenable-api-fields
suralpha
.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 valeuralpha
dans la définition de la ressource personnaliséeTektonConfig
.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
etPipelineTask
. 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 sectionpipeline
, vous devez définir le champenable-api-fields
suralpha
.- 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 ressourcePipelineRun
en utilisant des annotations et des étiquettes. Ainsi, les métadonnées deTask
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
etresults
. 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 deArrayOrStruct
, 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 champSkippedTasks
des champs de statutPipelineRun
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 objetTask
. Le type de résultat passe destring
à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 sectionpipeline
, vous devez définir le champenable-api-fields
suralpha
.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écificationEventListener
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 valeuralpha
dans la définition de la ressource personnaliséeTektonConfig
.-
Avec cette mise à jour, la ressource
Trigger
prend en charge les connexions sécurisées de bout en bout en exécutant le serveurClusterInterceptor
à 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 commandetkn 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 champspec.status
plutôt que la valeur obsolètePipelineRunCancelled
.
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âchegit-clone
afin que vous puissiez cloner des dépôts sécurisés.
3.1.5.1.5. Chaînes Tekton
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 nomsopenshift-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éeTektonChain
. Cette fonctionnalité permet à votre configuration de persister après la mise à jour, contrairement à la carte de configurationchains-config
, qui est écrasée lors des mises à jour.
3.1.5.1.6. Hub Tekton
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éetekton-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
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 entreztkn 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
etPipelineRun
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
etPipelineRun
, la valeur du typeRun
est prioritaire. Il en va de même si une annotation ou un label est présent dans les ressourcesTask
etTaskRun
. -
Dans Red Hat OpenShift Pipelines 1.8, le champ
PipelineRun.Spec.ServiceAccountNames
, précédemment déprécié, a été supprimé. Utilisez le champPipelineRun.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 champTaskRun.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 ressourceConditions
des définitions de ressourcesPipeline
qui l'incluent. Utilisez les expressionswhen
dans les définitionsPipelineRun
à la place.
-
Pour les chaînes Tekton, le format
tekton-provenance
a été supprimé dans cette version. Utilisez plutôt le formatin-toto
en définissant"artifacts.taskrun.format": "in-toto"
dans la ressource personnaliséeTektonChain
.
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, remplaceztoken
parprovider.token
, et remplacezsecret
parwebhook.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}}
parsecret: {{ 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
partkn pac create repository
. -
Remplacer
tkn pac repository delete
partkn pac delete repository
. -
Remplacer
tkn pac repository list
partkn pac list
.
-
Remplacer
3.1.5.3. Fonctionnalités obsolètes et supprimées
À partir d'OpenShift Container Platform 4.11, les canaux
preview
etstable
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 canalpipelines-<version>
approprié ou le canallatest
pour la version stable la plus récente. Par exemple, pour installer la version1.8.x
d'OpenShift Pipelines Operator, utilisez le canalpipelines-1.8
.NoteDans OpenShift Container Platform 4.10 et les versions antérieures, vous pouvez utiliser les canaux
preview
etstable
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 similairestekton.dev/v1alpha1
. Comme alternative, mettez à jour les ressources existantes pour utiliserapiVersion: 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.ImportantPour 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 CRPipelineResource
était une fonctionnalité Tech Preview et faisait partie de l'APItekton.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 CRCondition
faisait partie de l'APItekton.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
pourgsutil
a été supprimée. Cette suppression pourrait interrompre les clusters avec les ressourcesPipeline
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
etPipelineRun.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 objetsPipelineRun
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'étatCancelled
, qui remplace l'étatpipelineRunCancelled
.Vous n'avez pas besoin de modifier vos ressources
Pipeline
etTask
. 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 statutsPipelineRun
.Cette fonctionnalité étant disponible par défaut, il n'est plus nécessaire de donner au champ
pipeline.enable-api-fields
la valeuralpha
dans la définition de la ressource personnaliséeTektonConfig
.Dans Red Hat OpenShift Pipelines 1.8, le champ
timeout
dansPipelineRun
a été déprécié. À la place, utilisez le champPipelineRun.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 valeuralpha
dans la définition de la ressource personnaliséeTektonConfig
.-
Dans Red Hat OpenShift Pipelines 1.8, les conteneurs
init
sont omis des calculs de demande par défaut de l'objetLimitRange
.
3.1.5.4. Problèmes connus
Le pipeline
s2i-nodejs
ne peut pas utiliser le flux d'imagesnodejs:14-ubi8-minimal
pour effectuer des constructions source-image (S2I). L'utilisation de ce flux d'images produit un messageerror building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
.Solution de contournement : Utilisez
nodejs:14-ubi8
plutôt que le flux d'imagesnodejs: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
surmaven:3.6.3-adoptopenjdk-11
.AstuceAvant 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 sippc64le
ets390x
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
ouPipelineRun
aux tâchestaskRef
. Le mappage ne doit se faire qu'à partir d'une ressource de premier niveau vers des tâches avec des spécifications en lignetaskSpec
. Ce problème n'affecte que les clusters où cette fonctionnalité a été activée en définissant le champenable-api-fields
suralpha
dans la sectionpipeline
de la définition de la ressource personnaliséeTektonConfig
.
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âchepipelines-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 objetsTaskRuns
etRun
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 objetTaskRun
existe. Le planificateur prend désormais en compte les conteneursstep
et exclut tous les autres conteneurs d'applications, tels que les conteneurs sidecar, lors de la prise en compte des demandes provenant d'objetsLimitRange
. -
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 valeurstatus.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"]
, seulorg
é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éfinitionClusterInterceptor
.
-
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 valeurstatus.condition
, l'outil CLItkn
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>
outkn 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
outkn 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 configurationchains-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 clusterbuildah
ets2i
. -
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 servicepipeline
. Par conséquent, les secrets liés au compte de servicepipeline
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é deSETFCAP
nécessaire pour les tâches de cluster deBuildah
etS2I
. Par conséquent, les tâches de constructionBuildah
etS2I
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 constructionS2I
pour les applications écrites dans différents langages et frameworks, ajoutez l'extrait suivant pour les objetssteps
appropriés tels quebuild
etpush
: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
etLimitRange
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 CLIskopeo
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'étatTerminating
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é commeTrue
au lieu deFalse
.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 objetresult
dont le type étaitarray
. Avec cette mise à jour, vous pouvez utiliser l'outil CLItkn
pour supprimer les exécutions de tâches et les exécutions de pipeline qui contiennent un objetresult
dont le type estarray
. -
Avant cette mise à jour, si une spécification de pipeline contenait une tâche avec un paramètre
ENV_VARS
de typearray
, 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 grappeBuildah
pour accéder à un registre de conteneurs. Avec cette mise à jour, les administrateurs de clusters peuvent fournir un fichierconfig.json
à la tâche de clusterBuildah
en utilisant l'espace de travaildockerconfig
.
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âchegit-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 version1.7
d'OpenShift Pipelines Operator estpipelines-1.7
. Les administrateurs de cluster peuvent également utiliser le canallatest
pour installer la version stable la plus récente de l'Opérateur.NoteLes canaux
preview
etstable
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 id0
) 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 clusterbuildah
. - 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.
-
Pour ajouter ces annotations pour tous les utilisateurs, exécutez la commande
Avant cette mise à jour, si certaines conditions n'étaient pas remplies, l'expression
when
sautait un objetTask
et ses tâches dépendantes. Avec cette mise à jour, vous pouvez étendre l'expressionwhen
pour garder l'objetTask
uniquement, et non ses tâches dépendantes. Pour activer cette mise à jour, définissez l'indicateurscope-when-expressions-to-task
surtrue
dans le CRDTektonConfig
.NoteL'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 expressionswhen
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'indicateurenable-api-fields
.
3.1.6.1.2. Déclencheurs
-
Avec cette mise à jour, la carte de configuration
feature-flag-triggers
dispose d'un nouveau champlabels-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écificationEventListener
. 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éeTektonConfig
, dans la sectionpipeline
, vous devez définir le champenable-api-fields
suralpha
. -
Avec cette mise à jour, les ressources
Trigger
prennent en charge les exécutions personnalisées définies par un modèleTriggerTemplate
. -
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
, etTriggerBinding
. -
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 est8080
. -
Avec cette mise à jour, vous pouvez utiliser le champ
targetURI
dans la spécificationEventListener
pour envoyer des événements cloud pendant le traitement des déclencheurs. Pour activer cette fonctionnalité, dans la définition de la ressource personnaliséeTektonConfig
, dans la sectionpipeline
, vous devez définir le champenable-api-fields
suralpha
. -
Avec cette mise à jour, l'objet
tekton-triggers-eventlistener-roles
a maintenant un verbepatch
, en plus du verbecreate
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 nomsopenshift-pipelines
:$ tkn pipeline export test_pipeline -n openshift-pipelines
Exporter un pipeline nommé
test_pipeline_run
dans l'espace de nomsopenshift-pipelines
:$ tkn pipelinerun export test_pipeline_run -n openshift-pipelines
-
Avec cette mise à jour, l'option
--grace
est ajoutée à l'optiontkn 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éeTektonConfig
, dans la sectionpipeline
, vous devez définir le champenable-api-fields
àalpha
. Cette mise à jour ajoute les versions Operator et Chains à la sortie de la commande
tkn version
.ImportantTekton 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.ImportantTekton 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.
ImportantLes 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.
ImportantPipelines 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
surfalse
. 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éeTektonConfig
surfalse
. 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 commandetkn 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 env0.2
. -
Avec cette mise à jour du CRD
TektonConfig
, la commandeoc 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
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
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)
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 CLItkn
, 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
etdisable-home-env-overwrite
de la ressource personnalisée (CR)TektonConfig
. Par conséquent, la CRTektonConfig
ne définit plus automatiquement la variable d'environnement$HOME
et le paramètreworkingDir
. Vous pouvez toujours définir la variable d'environnement$HOME
et le paramètreworkingDir
en utilisant les champsenv
etworkingDir
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éeWhen
.
-
Changement radical : La ressource
Triggers
valide les modèles et génère une erreur si vous ne spécifiez pas les valeursEventListener
etTriggerBinding
.
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
surmaven:3.6.3-adoptopenjdk-11
.AstuceAvant 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 sippc64le
ets390x
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
ouPipelineRun
aux tâchestaskRef
. Le mappage ne doit se faire qu'à partir d'une ressource de premier niveau vers des tâches avec des spécifications en lignetaskSpec
. Ce problème n'affecte que les clusters où cette fonctionnalité a été activée en définissant le champenable-api-fields
suralpha
dans la sectionpipeline
de la définition de la ressource personnaliséeTektonConfig
.
3.1.6.4. Problèmes corrigés
-
Avec cette mise à jour, si des métadonnées telles que
labels
etannotations
sont présentes dans les définitions des objetsPipeline
etPipelineRun
, les valeurs du typePipelineRun
sont prioritaires. Vous pouvez observer un comportement similaire pour les objetsTask
etTaskRun
. -
Avec cette mise à jour, si le champ
timeouts.tasks
ou le champtimeouts.finally
est défini sur0
, le champtimeouts.pipeline
est également défini sur0
. -
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'objetEventListener
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'indicateurignore-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
etstep-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 nomsopenshift-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.NoteLa 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é deSETFCAP
nécessaire pour les tâches de cluster deBuildah
etS2I
. Par conséquent, les tâches de constructionBuildah
etS2I
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 constructionS2I
pour les applications écrites dans différents langages et frameworks, ajoutez l'extrait suivant pour les objetssteps
appropriés tels quebuild
etpush
: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'étatTerminating
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 servicepipeline
. Par conséquent, les secrets liés au compte de servicepipeline
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>
estyaml
oujson
. Sinon, sans l'option--output
, la commandestart
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 utiliseryq
oujq
pour analyser le message au format YAML ou JSON concernant la ressource et attendre que cette ressource soit terminée sans utiliser l'optionshowlog
. -
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 utilisertkn 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 saisirtkn [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 commandetkn pipelinerun delete --pipeline pipelinename --keep-since 5
préserve les exécutions de pipeline dont la ressource parente est nomméepipelinename
et dont l'ancienneté est inférieure ou égale à cinq minutes. Les commandestkn tr delete -t <taskname> --keep-since 5
ettkn 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 commandestkn pipelinerun delete
ettkn taskrun delete
. -
Cette mise à jour ajoute une sous-commande
create
aux commandestkn task
ettkn 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 commandestkn pipelinerun delete --all --label asdf
ettkn pipelinerun delete --all --label==asdf
suppriment toutes deux toutes les séries de pipelines portant le labelasdf
. - 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
etconfig-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 ressourceEventListener
. 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'APIv1beta1
.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 dev1beta1
à 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éeTektonConfig
, un nouveau travail cron est créé dans cet espace de noms. -
operator.tekton.dev/prune.skip
: Lorsqu'il est défini surtrue
, 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éfinissezkeep-since
sur7200
.NoteLes annotations
keep
etkeep-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
oukeep-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 queTektonPipeline
etTektonTriggers
. 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 ressourcePipelineRun
. 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âchesfinally
. -
Les pods générés par la ressource
TaskRun
définissent désormais le champactiveDeadlineSeconds
des pods. Cela permet à OpenShift de les considérer comme terminés, et vous permet d'utiliser l'objet spécifiquement scopedResourceQuota
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 champsMin
,Max
,Default
etDefaultRequest
. 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 valeursspec.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âchesfinally
. -
CancelledRunFinally
annulera immédiatement les tâches en cours, puis exécutera les tâchesfinally
. Cancelled
conservera le comportement antérieur fourni par le statutPipelineRunCancelled
.NoteLe statut
Cancelled
remplace le statutPipelineRunCancelled
, qui est obsolète et qui sera supprimé dans la versionv1
.
-
-
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 champonError
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 champonError
la valeurstopAndFail
. - 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 expressionsWhen
à 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 expressionsWhen
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
ettolerations
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
etconfig.tolerations
dans la spécification deSubscription
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 champsnodeSelector
ettolerations
. Les modifications sont ensuite appliquées à tous les pods créés par Operator.
-
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
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 commandesclustertask
,task
,taskrun
,pipeline
, etpipelinerun
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 ressourceEventListener
.ImportantChangement radical : Le label
status
a été supprimé de la métriqueeventlistener_http_duration_seconds_*
. Supprimez les requêtes basées sur le labelstatus
.-
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'APIv1beta1
Go à la place. Les déclencheurs prennent désormais en charge la version de l'APIv1beta1
. Avec la version actuelle, la ressource
EventListener
envoie une réponse avant que les déclencheurs ne terminent leur traitement.ImportantChangement de rupture : Avec cette modification, la ressource
EventListener
ne répond plus avec un code d'état201 Created
lorsqu'elle crée des ressources. Au lieu de cela, elle répond avec un code de réponse202 Accepted
.La version actuelle supprime le champ
podTemplate
de la ressourceEventListener
.ImportantChangement 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 ressourceEventListener
.ImportantChangement radical : Le champ
replicas
, obsolète, a été supprimé.
Dans Red Hat OpenShift Pipelines 1.6, les valeurs de
HOME="/tekton/home"
etworkingDir="/workspace"
sont supprimées de la spécification des objetsStep
.Au lieu de cela, Red Hat OpenShift Pipelines définit
HOME
etworkingDir
aux valeurs définies par les conteneurs exécutant les objetsStep
. Vous pouvez remplacer ces valeurs dans la spécification de vos objetsStep
.Pour utiliser l'ancien comportement, vous pouvez remplacer les champs
disable-working-directory-overwrite
etdisable-home-env-overwrite
de la CRTektonConfig
parfalse
:apiVersion: operator.tekton.dev/v1alpha1 kind: TektonConfig metadata: name: config spec: pipeline: disable-working-directory-overwrite: false disable-home-env-overwrite: false ...
ImportantLes champs
disable-working-directory-overwrite
etdisable-home-env-overwrite
de la CRTektonConfig
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
surmaven: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 sippc64le
ets390x
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 siretries
é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 dePipelineRuns
sont répertoriés dans l'ordre d'exécution approprié deTaskRun
.
-
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 unTaskRun
fait référence à unPipeline
ou unTask
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éeTektonConfig
.
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
ouTaskRun
pour permettre la propagation des étiquettes ou des annotations. Pour les paramètres implicites :
-
Ne pas appliquer les paramètres de
PipelineSpec
à l'objetTaskRefs
. -
Désactive le comportement param implicite pour les objets
Pipeline
.
-
Ne pas appliquer les paramètres de
-
Correction des objets
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.
NoteLorsque 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
etpipelineTemplates
surfalse
dans le CRTektonConfig
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.
Extraire le nom de la route pour l'espace de noms concerné.
$ oc get route -n <namespace>
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'étatTerminating
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é | Version | Statut 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 detkn image
. Avec cette amélioration, les champs suivants sont introduits dans la ressource personnaliséeTektonConfig
:... 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
etpipelinesTemplates
dans la ressource personnaliséeTektonConfig
: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éeAddon
, les valeurs de la ressource personnaliséeTektonConfig
remplacent les modifications. -
Vous ne pouvez définir la valeur du paramètre
pipelinesTemplates
surtrue
que si la valeur du paramètreclusterTasks
esttrue
.
-
Si le module complémentaire est créé à l'aide de la ressource personnalisée
Le paramètre
enableMetrics
est ajouté à la ressource personnaliséeTektonConfig
. 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 typesInterceptor
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 champparams
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
ouparams
.
-
Dans les spécifications du déclencheur, vous pouvez configurer les intercepteurs à l'aide d'une nouvelle API qui comprend un champ
-
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 commandeslog
. -
Pour afficher la version d'un composant spécifique, utilisez le nouvel indicateur
--component
dans la commandetkn 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 commandesearch
. -
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 valeurparams
, 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 commandetkn task describe
. -
L'option permettant de sélectionner automatiquement des ressources telles que
TriggerTemplate
, ouTriggerBinding
, ouClusterTriggerBinding
, ouEventlistener
, est ajoutée dans la commandedescribe
, 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 fichierrelease.yaml
peut désormais être utilisé plus facilement par des outils tels quekustomize
etytt
. - La prise en charge des noms de ressources contenant le caractère point (".") a été ajoutée.
-
Le tableau
hostAliases
de la spécificationPodTemplate
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 expressionswhen
ne prennent en charge que les champs écrits en minuscules.NoteSi vous avez appliqué un pipeline avec des expressions
when
dans Tekton Pipelinesv0.16
(Operatorv1.2.x
), vous devez le réappliquer.Lorsque vous mettez à niveau Red Hat OpenShift Pipelines Operator vers
v1.5
, les tâches de clusteropenshift-client
etopenshift-client-v-1-5-0
ont le paramètreSCRIPT
. Cependant, le paramètreARGS
et la ressourcegit
sont supprimés de la spécification de la tâche de clusteropenshift-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 champname
de la ressourceClusterTask
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ètreARGS
vers le paramètreSCRIPT
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
versv1.5
, les noms de profil dans lesquels la ressource personnaliséeTektonConfig
est installée changent désormais.Tableau 3.3. Profils pour
TektonConfig
ressource personnaliséeProfils dans les pipelines 1.5 Profil correspondant dans Pipelines 1.4 Installation 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
NoteSi vous avez utilisé
profile: all
dans l'instanceconfig
de la ressource personnaliséeTektonConfig
, 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éeTektonConfig
après la mise à niveau. Par exemple, si la configuration étaitprofile: basic
avant la mise à niveau, assurez-vous qu'elle estprofile: lite
après la mise à niveau vers Pipelines 1.5.Les champs
disable-home-env-overwrite
etdisable-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.NoteDans 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
etpodTemplate
sont supprimés de la spécificationEventListener
. - 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éeReady
.NoteÀ l'avenir, les autres conditions d'état de la ressource
EventListener
seront supprimées au profit de la condition d'étatReady
.-
Les champs
eventListener
etnamespace
de la réponseEventListener
sont obsolètes. Utilisez plutôt le champeventListenerUID
. Le champ
replicas
est obsolète dans la spécificationEventListener
. Le champspec.replicas
est déplacé versspec.resources.kubernetesResource.replicas
dans la spécificationKubernetesResource
.NoteLe 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 surref
etparams
. 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'ancienrbac.authorization.k8s.io/v1beta1
pour la ressourceClusterRoleBinding
. -
Dans les rôles de grappe, l'accès en écriture à l'échelle de la grappe à des ressources telles que
serviceaccounts
,secrets
,configmaps
, etlimitranges
est supprimé. En outre, l'accès aux ressources telles quedeployments
,statefulsets
, etdeployment/finalizers
est supprimé pour l'ensemble de la grappe. -
La définition de la ressource personnalisée
image
dans le groupecaching.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 clustergit-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 clustergit-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.-
[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. -
Exécutez la commande
oc edit clustertasks git-cli
. 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) ...
AvertissementPour 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'environnementHOME
, les modifications sont écrasées lors de la réconciliation de l'Opérateur.
-
[OPTIONNEL] Si vous avez installé Red Hat OpenShift Pipelines à l'aide de l'Opérateur, clonez la tâche de cluster
Désactive l'écrasement de la variable d'environnement
HOME
dans la carte de configurationfeature-flags
.-
Exécutez la commande
oc edit -n openshift-pipelines configmap feature-flags
. 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.
-
Exécutez la commande
Utilisez un compte de service différent pour la tâche de cluster
git-cli
, car l'écrasement de la variable d'environnementHOME
se produit lorsque le compte de service par défaut pour les pipelines est utilisé.- Créer un nouveau compte de service.
- Liez votre secret Git au compte de service que vous venez de créer.
- 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 commandetkn 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
surmaven:3.6.3-adoptopenjdk-11
.
3.1.8.5. Problèmes corrigés
-
Les expressions
when
dans les tâchesdag
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 ressourcePipelineRun
est rapidement supprimée puis recréée. -
Un nouveau fichier Docker est ajouté pour
pullrequest-init
pour l'imagebuild-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 leparam
dans sa définition n'a pas detype
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.
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é | Version | Statut 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âchesfinally
, 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.NoteLa prise en charge des expressions
when
et des tâchesfinally
n'est pas disponible dans la console Web d'OpenShift Container Platform 4.7.
-
Les expressions
-
La prise en charge de plusieurs secrets du type
dockercfg
oudockerconfigjson
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 commandetkn 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 champcustomResource
. - 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
ouInterceptorResponse
. -
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'objetEventListener
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éfautpipeline
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'imagegcs-fetcher
ne sont pas pris en charge. -
Dans le champ
taskRun
des tâches en grappe, l'étiquettetekton.dev/task
est supprimée. -
Pour les webhooks, la valeur
v1beta1
correspondant au champadmissionReviewVersions
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 detemplate.ref
. Vous devez mettre à jour toutes les définitions deeventListener
pour utiliser le champref
.NoteLa 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 champtemplate.name
restauré.-
Pour les ressources/objets personnalisés
EventListener
, les champsPodTemplate
etServiceType
sont obsolètes au profit deResource
. - Le style de spécification "embedded bindings", obsolète, a été supprimé.
-
Le champ
spec
est supprimé du champtriggerSpecBinding
. - 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
surmaven: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"
-
Si vous utilisez les déclencheurs v0.11.0 et plus, utilisez la fonction
- 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'étiquettetekton.dev/clusterTask
avait été introduite. Les problèmes résultant de ce changement sont résolus en corrigeant les commandesclustertask describe
etdelete
. De plus, la fonctionlastrun
pour les tâches est modifiée, afin de résoudre le problème de l'étiquettetekton.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
, unPipelineResource
est créé de manière interactive. La commandetkn p start
imprime l'état de la ressource si l'état de la ressource n'est pasnil
. -
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 commandetkn clustertask start
avec l'indicateur--last
pour vérifier la présence de l'étiquettetekton.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é, sanskubeConfiguration 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âchesfinally
, lorsqu'elles étaient converties en versionv1alpha1
et restaurées en versionv1beta1
. 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âchesfinally
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 avecCouldntGetTask
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 GETkubeclient
. -
Les pipelines avec les versions de l'API
v1beta1
peuvent maintenant être demandés avec la versionv1alpha1
, sans perdre les tâchesfinally
. L'application de la versionv1alpha1
renvoyée stockera la ressource en tant quev1beta1
, la sectionfinally
é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 sourceCloudEvent
est défini à une valeur qui correspond à l'URI source actuel, sans la valeur du champselfLink
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 raisonCreateContainerConfigError
, 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 surfalse
, de sorte que la tâche soit considérée comme ayant échoué lorsque le module rencontre la raisonCreateContainerConfigError
. -
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 conditionSucceeded
ouTrue
. - 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
etspec.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
surtrue
. -
Résolu lorsque les expressions sont maintenant listées dans les sections
Skipped Tasks
etTask Runs
dans le champStatus
de la configurationPipelineRun
. -
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écificationTask
. -
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 commandecp
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 esttrue
, vous devez inclure le champknown_host
dans le secret SSH de Git. La valeur par défaut de l'indicateur estfalse
. - 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 deEventListener
. -
Les commandes de
tekton hub
sont désormais intégrées dans le CLI detkn
.