URL: https://linuxfr.org/users/steph1978/journaux/ca-passe-creme Title: Ça passe crème Authors: steph1978 Date: 2020年04月18日T21:18:57+02:00 License: CC By-SA Tags: cremecrm, docker, dockerfile, python, django et redis Score: 13 # Quoi À la recherche d’un [CRM](https://linuxfr.org/tags/crm/public) pour un petit boulot, je découvre Creme CRM. Selon mon product owner, il y a toutes les fonctionnalités souhaitées. Top! Ma prod est à base de conteneurs ; il faut « dockeriser » l’outil. Creme est une application Python-Django. Cela ne devrait pas poser de problème particulier, python étant très bien [supporté dans Docker](https://hub.docker.com/_/python/). # Comment Le [site officiel](https://cremecrm.com/) renvoi vers le [repo git](https://bitbucket.org/hybird/creme_crm-2.1/src/default/) et le README explique la marche à suivre pour lancer l’application. Il s’avère que Django a une particularité. Il optimise les fichiers statiques (JS, CSS, HTML, images?) avec un outil écrit en java. Il faut java pour faire tourner une application Django avec de bonne performances. Il s’avère que Django a une deuxième particularité. Il dépend de Pillow, une bibliothèque logicielle de manipulation d’images. Et Pillow doit se compiler sur la machine lors de son installation. Je n’ai pas l’impression que ce soit utilisé par Creme mais dans le doute et pour avoir un packaging Django un peu généraliste, je vais la garder. Il faut un compilateur C et quelques bibliothèques logicielles de développement. Pour ne pas garder cet embonpoint dans mon image docker finale, je vais faire une construction en deux phases. La première phase fera la génération des médias et la compilation des dépendances, la seconde fera l’image finale, sans java ni compilateur. Je vais aussi utiliser un « virtual env ». Ce n’est habituellement pas conseillé pour une image docker car le conteneur fait déjà l’isolation de l’environnent applicatif vis-à-vis de l’hôte. Mais dans mon cas, c’est plus pratiques pour transporter les dépendances Python d’une phase à l’autre sans devoir fouiller dans les répertoires système. Cela donne : ``` FROM python:3.7-alpine AS django-builder-alpine RUN apk add --no-cache openjdk11-jre RUN apk add --no-cache jpeg-dev zlib-dev RUN apk add --no-cache build-base linux-headers WORKDIR /app ENV VIRTUAL_ENV=/app/venv RUN python3 -m venv $VIRTUAL_ENV ENV PATH="$VIRTUAL_ENV/bin:$PATH" COPY creme/requirements.txt . RUN pip install -r requirements.txt COPY . . # set sqlite backend, else it requires mysql client to be installed RUN echo "DATABASES={'default':{'ENGINE':'django.db.backends.sqlite3'}}"> creme/local_settings.py RUN python manage.py generatemedia FROM python:3.7-alpine RUN apk add --no-cache redis jpeg zlib WORKDIR /app ENV VIRTUAL_ENV=/app/venv ENV PATH="$VIRTUAL_ENV/bin:$PATH" COPY --from=django-builder-alpine /app . # needed for ingress auto discovery EXPOSE 8000 CMD redis-server & \ python manage.py migrate && \ python manage.py creme_populate && \ python manage.py creme_job_manager & \ python manage.py runserver 0:8000 ``` # Limitations * l’image propose le serveur django de développement ; il est certainement moins optimisé qu’un apache+mod_python ou un gunicorn * l’image propose le moteur de base de données SQLite ; il n’est pas conseillé pour une utilisation avec plusieurs utilisateurs simultanés. Cela pourrait se changer par simple configuration (fichier `local_settings`) * l’image embarque tous les composants – webapp, db, ordonnanceur, cache – dans le même conteneur ; un déploiement plus élaboré les aurait séparés Dans la pratique, pour notre petit usage, cela fonctionne parfaitement. # Résultat L’image de construction pèse 584MB, l’image finale 176MB, une économie de 412MB, environ 70%. La même tentative avec une base Debian-slim donne une image de construction de 508MB et une image finale de 289MB. EOF