Pulp registry - télécharger, uploader, organiser et distribuer des paquets

Depuis le récent changement de licence de Sonatype Nexus début 2025, il est devenu préférable de se tourner vers une alternative open-source et souveraine sans limitations. Pulp est un gestionnaire de dépôts de paquets logiciels répondant à cette problématique. Polyvalent et modulable, il est adapté à un large éventail de formats tels que npm, Maven, OCI et plus encore.

Cet article se penchera d’abord sur les avantages apportés par Pulp en matière de sécurité et de souveraineté des données, puis décrira les étapes d’une installation simple du logiciel dans un environnement Kubernetes mono-noeud.

Les avantages d’utiliser Pulp

Au cours des dernières années, une croissance significative des attaques dites “supply-chain” a été observée, dans lesquelles des infrastructures entières ont été compromises en raison de paquets de dépendances malveillants. L’utilisation de Pulp constitue une brique importante de la stratégie de sécurisation des chaînes d’approvisionnement en assurant le contrôle des versions des paquets et en réduisant les risques d’attaques basées sur des dépendances externes. Cette solution offre également une souveraineté des données en permettant de garder le contrôle total sur les artefacts utilisés dans l’infrastructure.

Dans un environnement air-gapped, Pulp peut être aussi configuré pour agir tel un proxy pour sécuriser l’accès aux dépôts externes tout en maintenant une isolation complète de l’infrastructure interne. Cette approche permet de stocker les paquets nécessaires à partir de sources externes (comme les dépôts officiels) et de les servir localement, garantissant ainsi la disponibilité des dépendances sans nécessiter de connexion directe à Internet.

Installation et utilisation de Pulp

Prérequis

Un cluster Kubernetes. Le cluster ici utilisé est un cluster kind mono-noeud.
Le gestionnaire de paquets Helm.
Docker CLI.

Installation

Pulp implémente le pattern operator Kubernetes en utilisant des CRDs et des contrôleurs pour gérer automatiquement le cycle de vie de ses composants au sein du cluster.

# Le repository de Pulp est ajouté à Helm
helm repo add pulp-operator https://github.com/pulp/pulp-k8s-resources/raw/main/helm-charts/ --force-update
# L'opérateur est déployé
helm upgrade --install \
  -n pulp --create-namespace \
  --wait \
  pulp \
  pulp-operator/pulp-operator

Une fois l’opérateur déployé, l’instance principale de Pulp est créée à l’aide d’une CustomResource nommée “simple” tirée du repository officiel de Pulp.

Les tests ont été réalisés sur un cluster kind mono-noeud, d’où le paramètre file_storage_access_mode: "ReadWriteOnce". Attention : dans un environnement multi-noeuds, il est important de modifier ce paramètre en ReadWriteMany.

cat <<'YAML' | kubectl apply -n pulp -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: pulp-custom-settings
data:
  token_server: '"http://localhost:10000/token/"'
  content_origin: '"http://localhost:10000"'
  ansible_api_hostname: '"http://localhost:10000"'
  pypi_api_hostname: '"http://localhost:10000"'
---
apiVersion: repo-manager.pulpproject.org/v1
kind: Pulp
metadata:
  name: example-pulp
spec:
  api: replicas: 1
  content: replicas: 1
  worker: replicas: 1
  web: replicas: 1

  database:
    postgres_image: postgres:15
    postgres_storage_class: standard

  # Le paramètre "ReadWriteOnce" est à changer en "ReadWriteMany" dans un environnement multi-noeuds
  file_storage_access_mode: "ReadWriteOnce"
  file_storage_size: "2Gi"
  file_storage_storage_class: standard

  cache:
    enabled: true
    redis_storage_class: standard

  ingress_type: nodeport
  nodeport_port: 30000

  custom_pulp_settings: pulp-custom-settings
YAML

Après quelques minutes, on vérifie la complétion de l’installation.

kubectl -n pulp get pods -w
#> NAME                                                READY   STATUS      RESTARTS   AGE
#> example-pulp-api-77478484b4-jz2l9                   1/1     Running     0          4m3s
#> example-pulp-content-7dc7895cc-2pjqf                1/1     Running     0          4m3s
#> example-pulp-database-0                             1/1     Running     0          4m4s
#> example-pulp-pulpcore-migration-8f7lt-kwcdm         0/1     Completed   0          4m3s
#> example-pulp-redis-d989ffd4c-h6nxx                  1/1     Running     0          4m4s
#> example-pulp-reset-admin-password-cj825-fwxdq       0/1     Completed   0          4m3s
#> example-pulp-web-75ddc6644c-lzf5j                   1/1     Running     0          4m2s
#> example-pulp-worker-6c99876989-sb267                1/1     Running     0          4m3s
#> pulp-operator-controller-manager-579bfc5bdb-8lpr6   1/1     Running     0          5m24s

On peut alors requêter l’API.

kubectl -n pulp port-forward svc/example-pulp-web-svc 10000:24880
curl -s http://localhost:10000/pulp/api/v3/status/ | jq
#> {
#>   "versions": [
#>     {
#>       "component": "core",
#>       "version": "3.114.2",
#>       "package": "pulpcore",
#>       "module": "pulpcore.app",
#>       "domain_compatible": true
#>     },
#> ...

Exemple d’utilisation : Pulp en mode `pull-through`

Dans cet exemple, Pulp est configuré en mode pull-through. Il agit comme proxy vers un autre registre distant, permettant notamment de connecter des environnements air-gapped à des instances extérieures. Les téléchargements sont alors sauvegardés en cache, assurant la disponibilité des ressources même en cas de coupure à Internet.

# Récupération des credentials de l'utilisateur admin
PULP_ADMIN_USER="admin"
PULP_ADMIN_PASSWORD="$(
  kubectl -n pulp get secret example-pulp-admin-password \
  -o jsonpath='{.data.password}' | base64 -d
  )"
BASE_ADDR="http://localhost:10000"
# Création du remote pull-through
REMOTE_HREF=$(curl -k -u "$PULP_ADMIN_USER:$PULP_ADMIN_PASSWORD" \
  -X POST "${BASE_ADDR}/pulp/api/v3/remotes/container/pull-through/" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "quay-proxy",
    "url": "https://quay.io",
    "tls_validation": false
  }' | jq -r ".pulp_href")
# Création de la distribution pull-through
curl -k -u "$PULP_ADMIN_USER:$PULP_ADMIN_PASSWORD" \
  -X POST "${BASE_ADDR}/pulp/api/v3/distributions/container/pull-through/" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "quay-proxy",
    "base_path": "quay-proxy",
    "remote": "'$REMOTE_HREF'"
  }'

Les images peuvent donc être récupérées en passant par le registre Pulp.

docker login localhost:10000 -u "$PULP_ADMIN_USER" -p "$PULP_ADMIN_PASSWORD"
docker pull localhost:10000/quay-proxy/prometheus/busybox
#> Using default tag: latest
#> latest: Pulling from quay-proxy/prometheus/busybox
#> bb2e5dc6c183: Pull complete
#> c93f261857c3: Pull complete
#> Digest: sha256:065fa27af988710200f7a9ceb7a09ae2fa6604074898c650bd89459e36edd6cf
#> Status: Downloaded newer image for localhost:10000/quay-proxy/prometheus/busybox:latest
#> localhost:10000/quay-proxy/prometheus/busybox:latest

Pour aller plus loin

Pulp propose une multitude d’autres fonctionnalités, comme la prise en charge de nombreux formats de packages (RPM, Maven…) ou encore le versioning de dépôts. Des interfaces graphiques communautaires existent, comme pulp-ui ou pulp-ui-2, mais l’activité reste globalement faible, et l’essentiel de l’utilisation passe encore par l’API REST et le CLI. C’est pourquoi Pulp est, à ce jour, une des alternatives les plus crédibles à Sonatype Nexus.

Partagez cet article