---
title: "Description d'une Docker Registry."
canonical: "https://blog.kaptus.net/space/BKAP/blog/833978370/Description%20d'une%20Docker%20Registry."
format: markdown
---
> Macro (toc)

# **1. Qu’est-ce qu’une Docker Registry ?**

Une `Docker Registry` est un service de stockage et de distribution d’images de conteneurs compatibles `Docker` et `OCI` ([Open Container Initiative](https://opencontainers.org/)). Son rôle est comparable à celui d’un dépôt `Git` pour le code source : elle centralise les images afin qu’elles puissent être partagées, versionnées et déployées sur différentes machines.

Lorsqu’un développeur construit une image avec `docker build`, celle-ci existe uniquement sur sa machine locale. Pour la rendre accessible à d’autres utilisateurs, serveurs ou pipelines `CI/CD`, il faut la publier dans une `registry` à l’aide de la commande `docker push`. Inversement, un système qui souhaite utiliser cette image la télécharge grâce à `docker pull`.

Une registry organise les images sous forme de **repositories** (dépôts) contenant un ou plusieurs **tags** (versions). Par exemple :

```plaintext
forgejo.xxxxxx.xxx/kaptus/email-api:1.0.0
```

- `forgejo.xxxxxx.xxx` : la registry
- `kaptus` : le propriétaire (organisation ou utilisateur)
- `email-api` : le repository
- `1.0.0` : le tag/version

Les registries modernes implémentent généralement l’API `OCI/Docker Registry v2`, qui permet :

- l’authentification des utilisateurs ;
- la gestion des permissions ;
- le stockage des couches (`layers`) d’images ;
- le versioning des images ;
- l’intégration avec les outils `CI/CD`.

Parmi les registries les plus connues figurent :

- [Docker Hub](https://hub.docker.com/),
- [GitHub Container Registry](https://github.com/container-registry) (`GHCR`),
- [GitLab Container Registry](https://docs.gitlab.com/user/packages/container_registry/),
- [Harbor](https://goharbor.io/),
- [Nexus](https://help.sonatype.com/en/docker-registry.html),
- [JFrog Artifactory](https://jfrog.com/fr/container-registry/)
- [Forgejo Container Registry](https://forgejo.org/docs/latest/user/packages/container/).

# **2. Souveraineté et maîtrise des infrastructures**

L’utilisation de la `Container Registry` intégrée à `Forgejo` présente également un intérêt majeur en matière de **souveraineté numérique**. En hébergeant à la fois le code source, les pipelines `CI/CD` et les images de conteneurs sur une infrastructure maîtrisée par l’organisation, il devient possible de réduire fortement la dépendance à des services tiers tels que `Docker Hub`, `GitHub Container Registry` ou d’***autres plateformes cloud étrangères.***

Les images `Docker` constituent souvent un élément stratégique du système d’information puisqu’elles contiennent les applications, leurs dépendances et parfois des configurations spécifiques à l’entreprise. En les stockant dans une `registry Forgejo` hébergée sur ses propres serveurs ou chez un hébergeur de confiance, l’organisation conserve la maîtrise complète de ses données, de ses politiques d’accès et de ses procédures de sauvegarde. ***Cela facilite également la conformité avec les exigences réglementaires ou contractuelles liées à la localisation des données et à la sécurité des systèmes d’information.***

Cette approche permet enfin de garantir la continuité de service et l’indépendance technologique :

- les processus de développement,
- de déploiement
- d’exploitation

ne reposent plus sur la disponibilité ou les conditions commerciales d’un fournisseur externe. `Forgejo` devient ainsi une brique centrale d’une chaîne `DevOps` souveraine, ouverte et pérenne, dans laquelle l’entreprise garde le contrôle de l’ensemble de ses actifs numériques.

# **3. La Docker Registry de Forgejo**

`Forgejo` intègre nativement une `Container Registry` compatible `Docker` et `OCI`. Elle permet d’héberger des images de conteneurs directement dans la même plateforme que le code source, les tickets, les `pull requests` et les `pipelines` d’automatisation.

Dans `Forgejo`, les images sont stockées sous forme de **packages** associés à un utilisateur ou à une organisation. Par exemple :

```plaintext
forgejo.xxxxxx.xxx/kaptus/email-api:1.0.0
```

correspond à l’image `email-api` publiée dans l’organisation `kaptus`.

L’accès se fait avec les outils Docker standards :

```shell
docker login forgejo.xxxxxx.xxx
docker push forgejo.xxxxxx.xxx/kaptus/email-api:1.0.0
docker pull forgejo.xxxxxx.xxx/kaptus/email-api:1.0.0
```

La registry `Forgejo` expose l’`API Docker Registry v2` via l’endpoint :

```plaintext
https://forgejo.xxxxxx.xxx/v2/
```

et utilise l’authentification `Forgejo` (mot de passe ou `Personal Access Token`). Les permissions sont directement héritées des comptes et organisations `Forgejo`, ce qui simplifie la gestion des accès.

L’un des principaux avantages est l’intégration avec `Forgejo Actions` :

- une `pipeline` peut construire une image `Docker` puis la publier automatiquement dans la `registry` lors d’un `commit` ou d’une `release`.

Cela permet de disposer d’une chaîne complète de développement et de déploiement sans dépendre d’un service externe comme `Docker Hub.`

Dans un contexte d’entreprise comme `KAPTUS`, la `registry Forgejo` constitue ainsi un dépôt privé centralisé pour toutes les images applicatives, garantissant la maîtrise des accès, la traçabilité des versions et l’intégration avec les processus `DevOps` existants.