mais c'est le seul moyen que je voie qui permette d'éviter les collisions.
Un unit systemd permet de définir les variables d'env du process. Docker permet de passer la valeur des variables d'env via l'option -e ou --env-file. Un Pod Kubernetes permet de passer la valeur des variables d'environnement and inline, via un ConfigMap, ou via un Secret. Les plateformes type Heroku, les fonctions Netlify ou AWS Lambda, toutes permettent de définir les valeurs des variables d'environnement.
Dans le cas de systemd, c'est simple : tu fais plusieurs units. Pour docker, c'est un docker run différent. Pour Kubernetes, c'est un Pod différent, etc...
Et c'est toujours la même application qu'on instancie de manière différente. Ou est le conflit ?
Ne pas stocker dans des fichiers parce que c'est local, préférer FTP & co? Idem, pas cohérent.
C'est pas ce que j'ai dit. Et ce n'est pas ce que 12 factors dit. Ce qui est dit c'est qu'il faut déléguer la persistance à un service tier, configurable, et ne pas le hard-coder dans l'application.
Dans le cas de docker, le système de fichier (si pas de volume), c'est un tmpfs (ou équivalent) qui disparaît entre 2 lancements.
Pour faire simple, lorsque tu écris ton application, considère qu'elle sera toujours exécuté sur un tmpfs, et rend paramétrable le lieu de stockage pour que l'ops puisse faire pointer ça vers un volume ou autre.
Je prend l'exemple de postgresql qui utilise la variable d'env PGDATA, que j'utilise avec docker pour le faire pointer vers un volume qui lui sera persisté (sur le disque local pour mon docker-compose de dev, sur un block storage dans le cloud pour kubernetes, etc...).
Dans l'ensemble, de ce que j'ai compris de ce que tu dis, ces 12 "règles" semblent être bien trop vagues pour être utilisables comme règles.
Nulle part sur le site il n'est dit que ce sont des "règles". C'est une philosophie, un ensemble de conseil que tu es libre d'adapter à ton besoin.
Par exemple, pour la numéro 8 (concurrency), j'ai pas de scrupule à utiliser supervisord dans une image docker pour lancer/gérer plusieurs process python (un worker celery, une webapp django), j'utilise le format %(ENV_CELERY_REPLICAS)s et %(ENV_DJANGO_REPLICAS)s pour la valeur de numprocs afin de rendre cela configurable quand même. Ici, 12factor conseille plutôt plusieurs image docker différentes, mais je m'en cogne.
[^] # Re: Explication
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 2.
Un unit systemd permet de définir les variables d'env du process. Docker permet de passer la valeur des variables d'env via l'option
-eou--env-file. Un Pod Kubernetes permet de passer la valeur des variables d'environnement and inline, via un ConfigMap, ou via un Secret. Les plateformes type Heroku, les fonctions Netlify ou AWS Lambda, toutes permettent de définir les valeurs des variables d'environnement.Dans le cas de systemd, c'est simple : tu fais plusieurs units. Pour docker, c'est un
docker rundifférent. Pour Kubernetes, c'est un Pod différent, etc...Et c'est toujours la même application qu'on instancie de manière différente. Ou est le conflit ?
C'est pas ce que j'ai dit. Et ce n'est pas ce que 12 factors dit. Ce qui est dit c'est qu'il faut déléguer la persistance à un service tier, configurable, et ne pas le hard-coder dans l'application.
Dans le cas de docker, le système de fichier (si pas de volume), c'est un tmpfs (ou équivalent) qui disparaît entre 2 lancements.
Pour faire simple, lorsque tu écris ton application, considère qu'elle sera toujours exécuté sur un tmpfs, et rend paramétrable le lieu de stockage pour que l'ops puisse faire pointer ça vers un volume ou autre.
Je prend l'exemple de postgresql qui utilise la variable d'env PGDATA, que j'utilise avec docker pour le faire pointer vers un volume qui lui sera persisté (sur le disque local pour mon docker-compose de dev, sur un block storage dans le cloud pour kubernetes, etc...).
Nulle part sur le site il n'est dit que ce sont des "règles". C'est une philosophie, un ensemble de conseil que tu es libre d'adapter à ton besoin.
Par exemple, pour la numéro 8 (concurrency), j'ai pas de scrupule à utiliser supervisord dans une image docker pour lancer/gérer plusieurs process python (un worker celery, une webapp django), j'utilise le format
%(ENV_CELERY_REPLICAS)set%(ENV_DJANGO_REPLICAS)spour la valeur denumprocsafin de rendre cela configurable quand même. Ici, 12factor conseille plutôt plusieurs image docker différentes, mais je m'en cogne.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg