4.4. À propos du test des images source-image


En tant qu'auteur d'une image Source-to-Image (S2I), vous pouvez tester votre image S2I localement et utiliser le système de construction d'OpenShift Container Platform pour les tests automatisés et l'intégration continue.

S2I exige que les scripts assemble et run soient présents pour exécuter avec succès la construction de S2I. Le fait de fournir le script save-artifacts permet de réutiliser les artefacts de construction, et le fait de fournir le script usage permet de s'assurer que les informations d'utilisation sont imprimées sur la console lorsque quelqu'un exécute l'image du conteneur en dehors du S2I.

L'objectif du test d'une image S2I est de s'assurer que toutes les commandes décrites fonctionnent correctement, même si l'image du conteneur de base a changé ou si l'outil utilisé par les commandes a été mis à jour.

4.4.1. Comprendre les exigences en matière de tests

L'emplacement standard du script test est test/run. Ce script est invoqué par le constructeur d'images S2I de OpenShift Container Platform et peut être un simple script Bash ou un binaire Go statique.

Le script test/run effectue la construction de S2I, vous devez donc avoir le binaire S2I disponible dans votre site $PATH. Si nécessaire, suivez les instructions d'installation dans le README de S2I.

S2I combine le code source de l'application et l'image du constructeur. Pour le tester, vous avez donc besoin d'un exemple de source d'application afin de vérifier que la source se transforme avec succès en une image de conteneur exécutable. L'exemple d'application doit être simple, mais il doit permettre d'exercer les étapes cruciales des scripts assemble et run.

4.4.2. Générer des scripts et des outils

L'outillage S2I est fourni avec de puissants outils de génération pour accélérer le processus de création d'une nouvelle image S2I. La commande s2i create produit tous les scripts et outils de test S2I nécessaires avec la commande Makefile:

$ s2i create _<image nom>_ _<destination répertoire>_

Le script test/run généré doit être ajusté pour être utile, mais il constitue un bon point de départ pour commencer à développer.

Note

Le script test/run produit par la commande s2i create exige que les sources de l'application exemple se trouvent dans le répertoire test/test-app.

4.4.3. Tester localement

La manière la plus simple d'exécuter localement les tests d'image S2I est d'utiliser la version générée de Makefile.

Si vous n'avez pas utilisé la commande s2i create, vous pouvez copier le modèle suivant Makefile et remplacer le paramètre IMAGE_NAME par le nom de votre image.

Échantillon Makefile

IMAGE_NAME = openshift/ruby-20-centos7
CONTAINER_ENGINE := $(shell command -v podman 2> /dev/null | echo docker)

build:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME) .

.PHONY: test
test:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME)-candidate .
	IMAGE_NAME=$(IMAGE_NAME)-candidate test/run

4.4.4. Flux de travail des tests de base

Le script test suppose que vous avez déjà créé l'image que vous souhaitez tester. Si nécessaire, construisez d'abord l'image S2I. Exécutez l'une des commandes suivantes :

  • Si vous utilisez Podman, exécutez la commande suivante :

    $ podman build -t <nom_de_l'image_du_constructeur>
  • Si vous utilisez Docker, exécutez la commande suivante :

    $ docker build -t <nom_de_l'image_du_constructeur>

Les étapes suivantes décrivent le flux de travail par défaut pour tester les constructeurs d'images S2I :

  1. Vérifiez que le script usage fonctionne :

    • Si vous utilisez Podman, exécutez la commande suivante :

      $ podman run <builder_image_name> .
    • Si vous utilisez Docker, exécutez la commande suivante :

      $ docker run <builder_image_name> .
  2. Construire l'image :

    $ s2i build file:///path-to-sample-app _<BUILDER_IMAGE_NAME>_ _<OUTPUT_APPLICATION_IMAGE_NAME>_ _<OUTPUT_APPLICATION_IMAGE_NAME>_ _YRFFGUNA-BUILDER_IMAGE_NAME>_
  3. Facultatif : si vous prenez en charge save-artifacts, exécutez l'étape 2 une nouvelle fois pour vérifier que l'enregistrement et la restauration des artefacts fonctionnent correctement.
  4. Exécuter le conteneur :

    • Si vous utilisez Podman, exécutez la commande suivante :

      $ podman run <nom_de_l'image_de_l'application_de_sortie>
    • Si vous utilisez Docker, exécutez la commande suivante :

      $ docker run <output_application_image_name>
  5. Vérifiez que le conteneur fonctionne et que l'application répond.

L'exécution de ces étapes suffit généralement à déterminer si l'image du constructeur fonctionne comme prévu.

4.4.5. Utilisation d'OpenShift Container Platform pour la construction de l'image

Une fois que vous avez Dockerfile et les autres artefacts qui composent votre nouvelle image S2I builder, vous pouvez les mettre dans un dépôt git et utiliser OpenShift Container Platform pour construire et pousser l'image. Définissez un build Docker qui pointe vers votre dépôt.

Si votre instance OpenShift Container Platform est hébergée sur une adresse IP publique, le build peut être déclenché à chaque fois que vous poussez dans votre dépôt GitHub S2I builder image.

Vous pouvez également utiliser le site ImageChangeTrigger pour déclencher une reconstruction de vos applications basées sur l'image du constructeur S2I que vous avez mise à jour.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.