Publier et consommer des artefacts avec Pulp

Ce guide déroule le cycle de vie complet d'un artefact dans Pulp : le déposer, le publier, l'exposer, puis le récupérer depuis une machine cliente. Public visé : équipes qui veulent héberger leurs propres paquets ou mettre un dépôt public en cache. Prérequis : une instance Pulp opérationnelle et la CLI pulp configurée (voir Installer Pulp). Vous ferez deux tours de piste : un dépôt de fichiers que l'on remplit à la main, puis un proxy PyPI consommé par un vrai pip install.

Rappel du modèle : dans Pulp, un artefact traverse quatre objets, Repository → Publication → Distribution, alimentés soit par upload direct, soit par synchronisation depuis un remote. On illustre les deux modes.

Ce que vous allez apprendre

Créer un dépôt et y déposer un artefact par upload.
Publier puis distribuer ce dépôt à une URL stable.
Récupérer l'artefact via une simple requête HTTP.
Synchroniser un sous-ensemble de PyPI et l'installer avec pip.

Déposer un artefact par upload

On commence par le plugin pulp_file, le plus simple : il héberge n'importe quel fichier binaire. Le scénario est celui d'un artefact interne (un livrable, une archive) que l'on veut distribuer à ses machines.

Créer le dépôt :

pulp file repository create --name livrables

Déposer un fichier dans ce dépôt :
Fenêtre de terminal
```
echo "Livrable interne v1.0" > mon-livrable-1.0.txt
pulp file content upload \
  --repository livrables \
  --file mon-livrable-1.0.txt \
  --relative-path mon-livrable-1.0.txt
```
Pulp calcule le sha256 du fichier, le stocke une seule fois (dédoublonnage par empreinte) et l'ajoute au dépôt. Chaque upload crée une nouvelle version immuable du dépôt.

Publier et distribuer

Un dépôt rempli n'est pas encore consultable. Il faut le publier (figer une version dans un format servable) puis créer une distribution (l'URL d'accès).

Publier la dernière version du dépôt :
Fenêtre de terminal
```
pulp file publication create --repository livrables
```
Distribuer cette publication sous un chemin de base lisible :
Fenêtre de terminal
```
pulp file distribution create \
  --name livrables \
  --base-path livrables \
  --repository livrables
```
En liant la distribution au dépôt (et non à une publication figée), elle sert toujours la dernière publication : un nouvel upload suivi d'une publication est exposé automatiquement.

Récupérer l'artefact

L'artefact est maintenant accessible à une URL prévisible, sous /pulp/content/<base-path>/. Depuis n'importe quelle machine autorisée :

curl https://pulp.exemple.com/pulp/content/livrables/mon-livrable-1.0.txt

La sortie affiche Livrable interne v1.0. Vous venez de parcourir le cycle dépôt → publication → distribution → récupération de bout en bout.

Mettre PyPI en cache et l'installer avec pip

Passons au mode proxy, celui qui remplace un dépôt public par un cache local. On synchronise un paquet depuis PyPI, puis on l'installe avec pip en pointant vers Pulp. C'est le cas d'usage qui fait de Pulp un concurrent direct des dépôts proxy de Nexus et Artifactory.

Décrire la source avec un remote, en ne récupérant qu'un paquet ciblé et en stockant réellement les fichiers (immediate) :
Fenêtre de terminal
```
pulp python remote create \
  --name pypi-proxy \
  --url https://pypi.org/ \
  --includes '["shellingham"]' \
  --policy immediate
```
Le filtre --includes limite la synchronisation ; c'est aussi un premier levier de contrôle (voir Sécuriser Pulp). La politique immediate télécharge et conserve les artefacts, ce qui garantit un cache complet et des empreintes cohérentes.

Créer un dépôt Python et le synchroniser :

pulp python repository create --name pypi-cache
pulp python repository sync --name pypi-cache --remote pypi-proxy

Distribuer le dépôt : le plugin Python expose alors un index compatible PEP 503 :

pulp python distribution create \
  --name pypi-local \
  --base-path pypi-local \
  --repository pypi-cache

Installer le paquet depuis Pulp sur une machine cliente :
Fenêtre de terminal
```
pip install \
  --index-url https://pulp.exemple.com/pypi/pypi-local/simple/ \
  shellingham
```
pip interroge l'index servi par Pulp en HTTPS, télécharge le wheel depuis le cache et l'installe. Vos machines ne dépendent plus directement de PyPI. Le client doit approuver le certificat de Pulp : certificat public, ou autorité auto-signée ajoutée au magasin de confiance (voir Pulp en air-gapped). Ne recourez pas à --trusted-host, qui désactive la vérification TLS.

Le même schéma pour tous les formats

Ce cycle est identique quel que soit le format. Vous remplacez simplement file ou python par le plugin voulu :

pulp rpm pour un dépôt YUM/DNF interne.
pulp deb pour un miroir APT.
pulp ansible pour un dépôt de collections privées.
pulp npm, pulp maven, pulp gem pour les écosystèmes correspondants.

C'est cette cohérence de modèle qui rend Pulp productif : une fois le schéma remote / repository / publication / distribution acquis, tous les formats se pilotent de la même manière.

À retenir

Un artefact suit le cycle dépôt → publication → distribution → récupération.
On alimente un dépôt par upload direct (content upload) ou par synchronisation depuis un remote.
Lier une distribution au dépôt expose toujours la dernière publication.
Un remote Python en proxy permet un vrai pip install depuis Pulp, sans dépendre de PyPI.
Le même modèle vaut pour RPM, DEB, Ansible, npm, Maven : seul le nom du plugin change.

Prochaines étapes

Registre de conteneurs et scan Trivy Héberger et scanner des images de conteneurs.

Sécuriser Pulp Filtres de synchronisation, RBAC et content-guards.

Présentation de Pulp Revenir au modèle de contenu et au positionnement.

Gérer les paquets sous Linux Comprendre les dépôts .deb et .rpm côté client.