Utilisation des images Docker personnalisées

Le 20 novembre 2020, Dockerhub a introduit des limitations de débit sur les extractions d'image anonymes. Cette modification peut avoir un impact sur les utilisateurs qui exécutent des travaux à l'aide d'images personnalisées hébergées par Dockerhub.

Il est possible que l'image de base du pipeline ne réponde pas à toutes les exigences de votre build. Par exemple, vous pourriez avoir besoin d'un contrôle plus fin sur les versions de node, java, ou autres outils. Vous pouvez résoudre ce problème en incluant une première étape dans vos travaux de pipeline qui installe une série de nouveaux paquets et configure soigneusement les variables d'environnement, telles que PATH, pour configurer votre environnement. Cependant, il est préférable d'utiliser la prise en charge du pipeline pour l'exécution d'une image Docker personnalisée comme base de votre travail.

La prise en charge des images Docker personnalisées dans le pipeline permet de fournir une image qu'un travail de pipeline spécifique utilise lors de son exécution. Par exemple, vous pouvez fournir une image contenant des outils personnalisés qui sont requis par le script que le travail exécute. Une fois le travail exécuté, le conteneur dans lequel il s'exécutait est supprimé.

Que le travail soit de type Génération, Test ou Déploiement, vous pouvez sélectionner un sous-type Image Docker personnalisée pour fournir le nom de l'image Docker à utiliser et spécifier le script devant être exécuté. Par exemple, utilisez les options suivantes pour exécuter un travail de génération avec Maven 3.5.3 et IBM Java :

Construction Maven avec image personnalisée*Construction
avec
personnalisée*

Spécification du nom de l'image Docker

Le nom de l'image Docker dans les travaux d'images Docker personnalisées est conçu pour fonctionner de la même manière que les noms d'image fonctionnent avec l'interface de ligne de commande Docker. Le format d'un nom d'image Docker est : [repository][:][tag]. Par exemple, pour docker run maven:3.5.3-ibmjava, le nom de l'image Docker est maven:3.5.3-ibmjava, où maven est le référentiel et 3.5.3-ibmjava est l'étiquette. Il n'y a aucune restriction sur le nom de l'image Docker que vous pouvez utiliser ; n'importe quelle image Docker valide fonctionne.

Si la zone Nom d'image Docker n'est pas renseignée, l'image de base du pipeline standard est utilisée.

Par défaut, votre dépôt sur Docker Hub est recherché. Si vous utilisez un autre registre Docker, tel que IBM Cloud® Container Registry, vous pouvez utiliser le nom de DNS complet. Vous pouvez également utiliser le nom complet pour les images sur Docker Hub. Par exemple, registry.hub.docker.com/library/maven:3.5.3-ibmjava.

La balise (tag) d'une image Docker est facultative. Si vous ne spécifiez pas une balise, elle sera définie par défaut sur latest. Une valeur par défaut latest est juste un nom de balise que le propriétaire du référentiel doit gérer. Cela ne signifie pas que cette image Docker est la dernière image du point de vue chronologique.

Vous trouverez une vaste communauté de référentiels sur Docker Hub. IBM héberge un certain nombre de dépôts publics que l'équipe de IBM Cloud utilise à l'adresse suivante https://hub.docker.com/u/ibmcom/. Les référentiels ibmcom/ibmjava et ibmcom/ibmnode sont utiles comme base pour la génération.

Utilisation d'un registre d'images privé

Si vous utilisez un registre privé nécessitant une authentification, vous devez définir deux propriétés d'environnement de scène supplémentaires : DOCKER_USERNAME et DOCKER_PASSWORD. Vous pouvez utiliser une propriété sécurisée pour masquer votre DOCKER_PASSWORD. Avant que votre image ne soit extraite, le travail d'image Docker personnalisée utilise votre nom d'utilisateur et votre mot de passe pour effectuer un docker login.

Dans la plupart des registres, vous pouvez utiliser le nom d'utilisateur et le mot de passe qui vous ont été fournis. Si vous utilisez IBM Cloud Container Registry pour stocker vos images privées, vous devez utiliser une clé d'API de plateforme pour l'authentification.

  1. Demandez une clé API pour la plateforme et assurez-vous de la sauvegarder.

  2. Créez les propriétés d'environnement en deux étapes en utilisant iamapikey comme votre DOCKER_USERNAME et la clé d'API de plateforme sauvegardée comme DOCKER_PASSWORD.

    caption-side=bottom"
    IBM Cloud Container Registry credentials Références d'authentification

Spécification du script

Vous pouvez utiliser le bloc de script dans les travaux d'images Docker personnalisées pour créer un fichier script qui s'exécute dans un dossier de tâches, de la même manière que les travaux de pipeline réguliers.

ENTRYPOINT et CMD du fichier Docker de votre image Docker sont écrasés et ne sont pas appelés. Dans certains cas, cela peut signifier que vous devez ajouter des étapes d'initialisation à votre script.

Les travaux d'images Docker personnalisées offrent une plus grande flexibilité dans le mode d'exécution de votre script, notamment car vous pouvez contrôler l'interpréteur de commandes. Généralement, si la première ligne du script commence par #! et le nom d'un interpréteur de commandes, cette entrée est utilisée pour exécuter les commandes dans le travail. Si vous ne spécifiez pas d'interpréteur de commandes, l'interpréteur de commandes par défaut de l'image Docker est utilisé. Généralement, #!/bin/bash ou #!/bin/sh sont utilisés. Les interpréteurs de commandes d'images de awk, node et ruby fonctionnent également si vous spécifiez une image Docker appropriée.