Loading search data...

Stocker ses containers dans Gitlab

Disponible même dans la version libre de gitlab, un registre de containers est complètement intégré à Gitlab et permet donc de stocker vos images docker, podman et autres.

Il se trouve dans le menu Packages et Registries > Container Registry.

menu container registry

S’authentifier auprès du container registry Gitlab

Avant de pouvoir envoyer des images, vous devez vous authentifier auprès du Container Registry.

docker login registry.gitlab.com -u <votre-compte> -p <votre-token>

Vous pouvez utiliser votre mot de passe ou générer un Personal Access Token ou encore un deploy token. Je vais prendre ici un PAT. Pour cela il suffit de se rendre dans le menu Access Tokens de votre profil utilisateur.

Il faut bien donner les droit api + read_registry et write_registry. Donnez lui un nom et une date de validité si besoin.

menu user gitlab preferences

Conversez bien votre token nous le stockerons plus tard dans les variables d’un CI.

docker login registry.gitlab.com -u xxxxxx -p xxxxxx

WARNING! Your password will be stored unencrypted in /home/vagrant/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

Créer et envoyer des images dans le container registry Gitlab

Nous allons prendre en exemple une image contenant l’outil que nous avons vu récemment ansible-lint dont voici le dockerfile.

FROM alpine:3.14 as builder
ARG VERSION=5.2.0
RUN apk add --no-cache bc cargo gcc libffi-dev musl-dev openssl-dev py3-pip python3 python3-dev rust \
    && python3 -m venv /opt/venv \
    && source /opt/venv/bin/activate \
    && pip3 install --no-cache-dir --no-compile ansible-lint==$VERSION yamllint \
    && pip3 install ansible

FROM alpine:3.14 as default

RUN apk add --no-cache git python3

COPY --from=builder /opt/venv /opt/venv

# Make sure we use the virtualenv:
ENV PATH="/opt/venv/bin:$PATH"

WORKDIR /src
ENTRYPOINT ["ansible-lint", "-p", "-v"]
CMD ["--version"]

Pour ceux qui ne connaissent pas l’utilisation étapes multiples pour créer des images avec une taille contenu, je vous renvoie à ce billet. Le principe est simple on utilise des containers temporaires pour builder des outils et on recopie dans un autre container les répertoires utiles. Cela permet par exemple ici de passer d’une image avec une taille de 1.9Gb à 453Mo. Le reste est très classique.

Pour stocker vos containers vous avez le choix de les stocker au niveau d’un projet ou d’un groupe. Cela va simplement changer le chemin de l’url. Quand vous allez la première fois dans le menu container registry, gitlab vous indique le chemin.

Si il contient deja des images il suffit de déplacer la souris au dessus de l’une d’entre elles.

menu container registry

Lançons le build :

LASTVERSION=`lastversion ansible-community/ansible-lint`
docker build --build-arg VERSION=${LASTVERSION} -t registry.gitlab.com/dockerfiles6/ansible-lint:${LASTVERSION} .

lastversion est outil python permettant de récupérer la dernière release d’un projet. Ici je récupère la dernière version de l’outil ansible-lint. Son installation est simple :

pip install lastversion

Personnellement je l’utilise dans mon environnement virtuel pyython ansible construit avec pyenv.

Au bout de quelques minutes vous devriez obtenir votre image. Il ne reste plus qu’à la pousser:

docker push registry.gitlab.com/dockerfiles6/ansible-lint:5.2.0

Mettre en place un ci pour construire vos images

Voici un exemple de fichier .gitlab-ci.yml pour générer l’image et la stocker dans votre container registry.

image: docker:latest
services:
- docker:dind

stages:
- build

build:
    stage: build
    before_script:
        - apk add --no-cache py3-pip
        - pip install lastversion
        - docker login -u ${DEPLOY_USER} -p ${DEPLOY_TOKEN} registry.gitlab.com
    script:
        - LASTVERSION=`lastversion ansible-community/ansible-lint`
        - docker build --build-arg VERSION=${LASTVERSION} -t registry.gitlab.com/dockerfiles6/ansible-lint:${LASTVERSION} -t registry.gitlab.com/dockerfiles6/ansible-lint:latest .
        - docker push registry.gitlab.com/dockerfiles6/ansible-lint:${LASTVERSION}
        - docker push registry.gitlab.com/dockerfiles6/ansible-lint:latest

Il faudra juste avant créer deux variables masquées dans les settings CI-CD du groupe ou du projet :

menu variables ci-cd

Pour optimiser les temps de traitement je vous laisse créer une image qui reprends les commandes présentes dans le before_script. Ensuite à remplacer dans le .gitlab-ci.yml l’image utilisé avec la votre.

Encore quelques releases et on pourra de passer de nexus ou d’artifactory.

Utiliser une images stockées dans le container registry Gitlab

C’est assez classique. Je lance par exemple l’image ansible-lint

docker run -v $PWD:/src --rm registry.gitlab.com/dockerfiles6/ansible-lint:latest

ansible-lint 5.2.0 using ansible 2.11.5

La même chose sur un playbook.

docker run -v $PWD:/src --rm registry.gitlab.com/dockerfiles6/ansible-lint:latest

...
deploy_nexus.yml:137: yaml wrong indentation: expected 4 but found 2 (indentation)
deploy_nexus.yml:144: yaml wrong indentation: expected 6 but found 4 (indentation)
deploy_nexus.yml:155: yaml truthy value should be one of  (truthy)
deploy_nexus.yml:219: yaml truthy value should be one of  (truthy)
deploy_nexus.yml:228: yaml truthy value should be one of  (truthy)
deploy_nexus.yml:230: yaml truthy value should be one of  (truthy)

Quelques petites corrections à apporter.

Si vous souhaitez surcharger l’entrypoint ca donne ceci :

docker run --entrypoint sh -v /home/vagrant/Projets/ansible/playbooks/nexus:/src --rm -it registry.gitlab.com/dockerfiles6/ansible-lint:latest
/src # ansible-lint deploy-nexus.yml

Plus d’infos dans la documentation gitlab


Alimenter un blog comme celui-ci est aussi passionnant que chronophage. En passant votre prochaine commande (n'importe quel autre article) via ce lien, je recevrai une petite commission sans que cela ne vous coûte plus cher. Cela ne me permet pas de gagner ma vie, mais de couvrir les frais inhérents au fonctionnement du site. Merci donc à vous!

Mots clés :

devops, gitlab, tutorials, ci-cd,

Autres Articles