Notes de Bernard
Organisation pour le déploiement des containers et les architectures logicielles et systèmes qui pourraient en découler.
Page de liens en fin de présentation de Rémi : il existe des présentations solides sur SARI
Octobre novembre : Initiation Délégation Régionale à Docker
Dépôt de code : plein de petits dépôts atomiques dont le rôle est de générer un artéfact cad un container. Le container doit être testé puis publié avant d’être mis en production sur le cluster Kubernet. La mise en production, l’infrastructure est déclarative (infra as code). On peut imaginer d’automatiser la mise en production des containers par de simples push git.
Avantage l’état de l’infrastructure correspond à l’état de git. On pourra gérer les droits (qui peut modifier notre application) de façon très simple.
Qui utilise déjà?
Vegan fermez les yeux : Passage du niveau animaux de compagnie au bétail (si un animal va mal on le tue et on en relance un autre)
Des containers stateless mais aussi des ressources mutualisés :
Répliquer (avoir plusieurs) clusters ailleurs France Grille cloud clusters openstack ⇒ suppose d’avoir du stockage objet (CEPH) BDD répliquées pgpool
RESIF : Jerome crée des webservices qui pourraient être mis dans du docker
k8s pour RESIF mais dans une phase de développement c'est compliqué pour accéder aux logs par exemple. Ne construire le docker que quand l’application est +- ok.
Cf liste Kubernet UGA les outils pour accéder au container, mais dans un premier temps flashserv (?) Rancher ui par dessus rke permet de gérer les privilèges pour accéder aux logs.
Documentation beaucoup de choses deviennent inutiles grâce au fichiers de déclaration.
Obsportal utilise les containers avec une page health très utile. Réunions régulières sur les bonnes pratiques. RESIF il faudrait que le dev fasse lui-même le docker file.
Groupe kubernetes UGA, 99% des messages OSUG. LIG actif.
Bonnes pratiques :
⇒ rapprocher l'infrastructure docker de RESIF de celle de l'UMS