Texte original:

• Building and Running 12 Factor Microservices on Docker (Part 1)
• Building and Running 12 Factor Microservices on Docker (Part 2)

Autres lecture: docker

• Le code d'une application doit être gérée avec gestionnaire de version (Version Control System (VCS)) comme “Git”, “Subversion (svn)” ou “Mercurial (hg)”.
• Le code est déployé sur plusieurs et/ou différents environnements locaux ou distants comme “production”, “test” ou “développement”

• Chaque dépendance doit être explicite (Gem bundle avec Ruby, Pip avec Python, Composer avec Php, …)
• L'application ne dépend pas d'éléments devant être installés au niveau système, elle doit être isolée (“bundle exe” avec Ruby, Virtualenv avec Python)

• La configuration doit être stockée dans l'environnement pour pouvoir leurs être spécifique: dév, pré-prod, prod (par exemple la connexion à la BdD, la clé de sécurité).

• L'application doit être indépendante des services tiers que l'on peut sélectionner (passer de MySql à Amazon RDS) sans changer le code mais simplement un URL. Il faut donc utiliser une couche d'abstration (abstraction layer) à chaque fois que c'est possible (SQLAlchemy pour Python, PDO pour Php).
  • DATABASE_URL=mysql://testdb:t123@localhost/testdb
  • DATABASE_URL=postgresql://testdb:t123@localhost/testdb
  • DATABASE_URL=mysql://sa:mypwd@mydbinstance.abcdefghijkl.us-west-2.rds.amazonaws.com/mydb

• La construction (Build) créé un paquet autonome à partir du code source, des médias et des dépendances.
• La distribution (Release) créé un paquet unique avec le Build et la configuration de déploiement. Le paquet est unique et identifiable (numéro de version)

L'article présente la construction d'une 1ere image Docker “0.1.0” avec l'application, et d'une 2eme image Docker “0.1.0.0” héritant de la 1ère et ajoutant son environnement de configuration, c'est la release (Le 4eme chiffre décrit la version de la configuration).

• L'application est exécuté comme un ou plusieurs processus sans état (stateless) qui ne partage(nt) rien et sont donc distribuable(s) horizontalement
• Un mot sur le PID file et le gestionnaire de service “runit”

• Le port d'écoute réseau doit être défini par l'environnement, pas par l'application
• Le serveur web doit être fourni par l'application

• Comme les processus n'ont pas d'état, on peut en ajouter au besoin
• L'application peut être composée de différents types de processus: web, tâches de fond, tâches périodiques, …

• Les processus de l'application doivent pouvoir être arrêtés et démarrés facilement et indépendemment

• le temps entre développement et production doit être court
• Un développeur doit pouvoir pousser en production un nouveau code: continus deployement

• L'application écrit ses logs sur “stdout”, c'est l'environnement qui est en charge de les récolter, distribués, agréger …

• un processus d'administration doit pouvoir être lancé facilement et utilisant le même code et la même configuration que l'application