Dockeriser votre Actix backend
Apprenez à conteneuriser votre projet Actix en utilisant Docker et à optimiser la taille de votre image avec des images distro-less.
18 décembre 2022
Published
Hugo Mufraggi
Author

Dockeriser Votre Actix Backend
Je vous propose ce nouvel article sur l’arc rust, arc devops / telemetry, après l’article sur l’arc logiciel. Pour pouvoir intégrer de la telemetry à notre back end nous allons avoir besoin dans un premier temps de contenairiser notre projet, puis de le faire fonctionner dans un docker composé et d’implémenter la telemetry.
Vous pouvez retrouver les articles de l’arc précédent sur Medium et le code sur mon github.
Dockerfile
Le Dockerfile va nous permettre de créer une image de notre backend qui sera utilisable dans un docker-composé ou plus tard dans un kubernetess. Il faut voir cette image comme un snapshot du projet avec la possibilité d’être runné de partout où docker est installé. Cela permet de faciliter les déploiements et le versionning du projet.
L’objectif est d’avoir le container docker le plus léger possible.
A l’époque pour gagner de la place, on partait sur des bases alpine. A l’heure actuelle, cela ne fait plus partie des best practices. A une époque les Alpine comportaient des fails de sécurité et les images étaient que très peu maintenues. Puis sont arrivées les images distro-less.
Dristro-less
Sur le github de Google on peut retrouver une video datant de 2017 présentant le concept.
Les avantage sont multiples je vais vous les lister.
- Les images distro-less embarquent l’appilcation et les runs time dependance et c’est tout. Pas de package manager, pas de bash et pas d’autre programme.
- une best practice utilisée chez Google et d’autres gros acteur permet une limitation des risques
- Ultra leger
[gcr.io/distroless/static-debian11](<http://gcr.io/distroless/static-debian11>)pèse environ 2 Mib, unealpine(~5 MiB) et unedebian(124 MiB).
Je vous invite à aller jeter un coup oeil sur le github de Google. Vous y trouverez les différentes stats et les explications de l’équipe dans le README.
Dockerfile multi stage
Si j’ai pu vulgariser ce qu’est une image distro-less, vous comprenez que l’on va pas pouvoir l’utiliser telle quelle. On va diviser en 2 étapes la création de notre image Docker.
Build Stage
Le buid stage est la partie qui va nous permettre de compiler notre projet rust.
⚠️ Les images distro-less peuvent être aussi utilisées pour vos projets Frontend.
FROM rust:1.63.0 as build
ARG DATABASE_URL
WORKDIR /usr/src/api-service
COPY . .
ENV DATABASE_URL=$DATABASE_URL SQLX_OFFLINE=true RUST_BACKTRACE=1 PKG_CONFIG_ALLOW_CROSS=1
EXPOSE 8080
RUN cargo install --path .
Du coup, j’ai fait le choix de partir d une image rust:1.63.0 . Le tag build permet de définir que cette partie est la build stage.
J’ai fait le choix de passer l’url de la database en ARG, ce qui sera plus pratique plus tard. Puis, je lie à une vairable denv url de la database ENV DATABASE_URL=$DATABASE_URL.
Cette partie reste très classique nous finissons par RUN un RUN cargo install --path . qui va compiler notre projet Rust.
Package stage
FROM gcr.io/distroless/cc-debian10
COPY --from=build /usr/local/cargo/bin/hexa-domain-tutorial /usr/local/bin/hexa-domain-tutorialENTRYPOINT ["/usr/local/bin/hexa-domain-tutorial"]
Enfin voilà la fameuse image distro-less FROM [gcr.io/distroless/cc-debian10](<http://gcr.io/distroless/cc-debian10>). Le but est de venir copier le build fait dans le stage de build, ce qui va nous permettre de stocker seulement le binaire de notre application. Les deux stages sont regroupés dans un seul et même dockerfile
FROM rust:1.63.0 as build
ENV PKG_CONFIG_ALLOW_CROSS=1
ARG DATABASE_URL
WORKDIR /usr/src/api-service
COPY . .
ENV DATABASE_URL=$DATABASE_URL SQLX_OFFLINE=true RUST_BACKTRACE=1
EXPOSE 8080
RUN cargo install --path .
FROM gcr.io/distroless/cc-debian10COPY --from=build /usr/local/cargo/bin/hexa-domain-tutorial /usr/local/bin/hexa-domain-tutorialENTRYPOINT ["/usr/local/bin/hexa-domain-tutorial"]
Depuis, le debut nous parlons de la chasse à l’optimisation au niveau de la taille de notre container docker. Une fois notre image buildée, l’image et le container lancé, il ne fait que 31 MB Mission accomplie 🔥
Nous nous arrêterons ici pour cet article, vous pouvez essayer de lancer votre image docker en local mais vous allez devoir vous battre avec les réseaux, ou attendre le prochain article où nous réaliserons une intégration dans un docker-composé avec une database postgres sql.