Issues, improvements, ideas for the new Kubernetes system that will replace this one
Opened this issue · 2 comments
J'ouvre cette issue suite à une discussion que @grunenwald et moi avons eu.
Pas mal de choses commencent à dater sur ce projet et il n'a jamais vraiment été activement maintenu.
Nous sommes en train de créer une nouvelle solution en utilisant Kubernetes pour fournir des conteneurs Docker aux étudiants et plus généralement à l'école (RaD et cours).
Cette issue à pour objectif de noter tous les problèmes, améliorations, idées que nous pourrions avoir et à ne pas oublier lors de la création du nouveau système. Je propose de discuter de toutes les idées dans cette issue. Une fois l'idée validé, je l'ajouterais dans cette description:
TODO:
- Voir si uWSGI est la meilleure solution pour le déploiement, sinon utiliser autre chose, voir la doc de Django : https://docs.djangoproject.com/en/4.0/howto/deployment/
Voir si uWSGI est la meilleure solution pour le déploiement.
Se renseigner sur le site de Django pour voir ce qu'il est recommandé d'utiliser : https://docs.djangoproject.com/en/4.0/howto/deployment/
@SpicyPaper pour le contexte, ce projet crée un environment (sous forme d'image Docker) pour déployer des applications non cloud-native. Donc via SSH, qui sonne assez old school. Le but étant de cacher au maximum ce qui pourrait être fourni par un prestataire d'infogérance permettant de se concentrer sur le cœur, l'application web elle-même.
Demander de fournir une application sous forme de conteneur (+ ?) offre des challenges intéressants.
- Stocker les conteneurs,
ghcr.io(facile) - Fournir un moyen de déploiement. Kubernetes (managé ou pas?), Nomad?, Docker Swarm?
Alternatives possibles
Un cluster Kubernetes managé est une solution simple, il faudra y ajouter à minima une DB(aaS), un Ingress, et Cert-Manager (TLS) (voire un ingress basé sur Traefik, pas utilisé). Plus une gestion des droits d'accès afin que chaque puisse seulement casser des trucs dans son namespace.
Si, vous n'avez toujours qu'une seule machine (la fameuse srvz), Nomad peut être une solution viable, relativement simple où la configuration actuelle se traduirait assez simplement. Avec les namespaces, il est possible de fournir des jetons d'accès par équipe.
Docker Swarm, était donné comme mort, ne l'est pas, et je n'ai pas une expérience suffisante pour savoir si c'est une alternative viable pour s'en servir sur srvz.
Avis
Fournir un déploiement sous forme de conteneur Docker + configuration (YAML Kubernetes, Helm, Kustomize, Nomad job, docker-compose.yml, etc.) serait une bonne progression par rapport à l'état de l'art de quand ce projet a été concu.
La direction à prendre pour y arriver dépend pas mal des moyens à votre disposition. Si vous pouvez obtenir un cluster Kubernetes chez Azure ou GCP, c'est top. Si vous êtes coincé avec srvz, ça va être tendu d'aller vers du Kubernetes, sauf si vous avez des personnes passionnées par cet univers. Là, Nomad ou Docker (Swarm) vis Compose sont envisageables, sans trop devoir tout refaire ce qui existe ici.
Bonus
Je ne prendrai pas µWSGI aujourd'hui. Ceci dit, c'est un détail d'implantation.