Agence web » Actualités du digital » Comment configurer des builds automatiques pour les images Docker sur GitHub

Comment configurer des builds automatiques pour les images Docker sur GitHub

Logo GitHub.

GitHub dispose d’une fonctionnalité appelée Actions GitHub qui exécutent des compilations automatiques, des tests et d’autres scripts chaque fois que vous apportez des modifications à un référentiel. Un cas d’utilisation pratique de cela consiste à créer et à pousser automatiquement des conteneurs Docker vers un registre de conteneurs.

Nouveau registre de conteneurs de GitHub

Le nouveau registre de conteneurs de GitHub, appelé GitHub Container Registry, est un peu différent de la plupart des registres tels que Docker Hub. Il fonctionne comme une extension des packages GitHub, un système de stockage de packages qui associe les packages à leurs référentiels de code source. Les packages peuvent être créés et poussés à partir du référentiel, souvent automatiquement à l’aide d’un pipeline d’actions GitHub.

Registre de conteneurs GitHub.

GitHub Container Registry ajoute simplement une compatibilité spécifique à Docker aux packages GitHub, ce qui le fait fonctionner comme un registre de conteneurs à des fins d’exécution docker pull et d’autres commandes CLI.

Vous n’avez pas besoin de publier dans le registre de conteneurs de GitHub – vous pouvez toujours publier sur Docker Hub à partir d’une action avec une certaine configuration. Les actions prédéfinies fonctionnent avec GHCR par défaut, c’est donc beaucoup plus simple à configurer.

Comment configurer des builds automatiques sur des packages GitHub

Pour commencer, vous aurez besoin d’un référentiel. Même si vous ne publiez que des packages, vous aurez toujours besoin d’un dépôt, car le format de GHCR est:

ghcr.io/username/repository/image:version

Mettez en place un dépôt, puis cliquez sur «Actions» pour créer une nouvelle action. Sous « Plus de flux de travail d’intégration continue », cliquez sur « Publier le conteneur Docker ».

Configurez votre repo.

Cela génère un modèle de démarrage, qui nécessite quelques modifications pour fonctionner. Premièrement le IMAGE_NAME La variable doit être remplacée par le nom de votre image.

Remplacez la variable IMAGE_NAME par le nom de votre image.

Ensuite, à la ligne 39, vous trouverez où il se connecte à GHCR.

run: echo "${{ secrets.CR_PAT }}" | docker login https://ghcr.io -u ${{ github.actor }} --password-stdin

Actuellement, le seul schéma d’authentification pris en charge est les jetons d’accès personnels (PAT), ce qui n’est pas idéal pour la sécurité car ils accordent un accès à l’échelle du compte. GitHub le sait et travaille sur un meilleur correctif pour l’avenir, mais en attendant, si vous souhaitez utiliser GHCR à partir d’un flux de travail GitHub Actions, vous devrez stocker un PAT dans les Secrets de votre référentiel, car évidemment, il suffit de coller ce serait horrible ici.

Tout d’abord, vous devez vous rendre dans Paramètres> Paramètres du développeur> Jetons d’accès personnels et créer un nouveau jeton. Ce jeton a besoin write:packages et delete:packages réglages. Notez que pour une raison quelconque, la sélection des packages d’écriture sélectionne automatiquement «Contrôle total des référentiels», que vous devez décocher.

Créez un nouveau jeton avec les paramètres write: packages et delete: packages.

Ensuite, dirigez-vous vers les paramètres du référentiel et créez un nouveau secret appelé CR_PAT, pour correspondre à l’action.

Créez un nouveau secret appelé CR_PAT.

Revenez à l’action et cliquez sur «Démarrer la validation» pour la pousser vers le référentiel.

Cliquez sur "Commencer la validation" pour pousser le nouveau fichier vers le référentiel.

Une fois qu’il est validé, il déclenchera un flux de travail pour exécuter et créer le package. Vous pouvez surveiller l’état de tous les workflows en cours d’exécution sous l’onglet «Actions». Ici, cela a échoué car les actions par défaut s’attendent à ce qu’il y ait des tests à exécuter, ce que cette image n’avait pas.

Surveillez l'état de tous les workflows en cours d'exécution sous le "Actions" languette.

Une fois que c’est réussi, vous devriez voir le conteneur dans le registre, sous «Packages» sur la page principale du référentiel, ou sous les packages sur votre profil.

Une compilation réussie.

★★★★★