Gitlab

Dockerfile

Le fichier Dockerfile décrit les éléments nécessaires pour construire l’image de l’application. Il doit embarquer les sources de l’application (qui sont dans le repo du projet Gitlab), les librairies requises, définir l’utilisateur qui sera utilisé par le kernel pour l’instancier, ainsi que la commande permettant de lancer le processus.

Nous avons construit des images de base que nous maintenons à jour afin de faciliter la tâche des développeurs. Ces images contiennent une grande partie des librairies requises pour des applications web courantes.

Bearstech fournit des images pour différents langages et leurs variantes de développement : Golang, Node, PHP, Python, Ruby, Java.

A partir de ces images de base, on peut construire l’image de notre application.

Build

L’exemple du Dockerfile ci-dessous permet de construire l’image d’une application écrite en python, utilisant le projet Flask:

# we use a bearstech image!
FROM bearstech/python:3

# we create a user for our app
ARG uid=1001
RUN useradd myuser --uid ${uid} --shell /bin/bash --home /home/myuser
WORKDIR /home/myuser

# extends PATH to use our venv first
ENV PATH=/home/myuser/venv/bin/:$PATH

# copy our project
COPY . /home/myuser

# use our user
USER myuser

# run our application
CMD ["python", "-m", "app.web"]

Une fois les directives posées, l’image peut être construite en local au moyen d’une commande docker build :

docker build -t myapp/app:dev --build-arg=uid=$(id -u) .

Tester l’image

Une fois que l’image est construite localement, on peut tester les services en utilisant docker-compose en local, ou sur la CI en ajoutant un service de reverse-proxy.

# run compose in background
docker compose up -d
# show apps logs
docker compose logs --tail="all" app

L’image est prête à être buildée dans la CI, mais avant de détailler le fonctionnement de l’intégration continue, il est temps de documenter la manière dont le workflow expose publiquement l’application avec son reverse-proxy et sa gestion du routage HTTP.

NB: Le paramétrage du routage http est requis dans le cadre d’un projet qui vise un déploiement en mode conteneurisé car les conteneurs ne sont jamais exposés publiquement.

Top