Code source wiki de Idées de choses à faire sur l'infra
Version 10.1 par sasportesj le 2021/04/18 16:22
Afficher les derniers auteurs
| author | version | line-number | content |
|---|---|---|---|
| 1 | Si un jour vous sentez que l'infra marche très bien et qu'il n'y a rien à faire, n'ayez crainte ! Cette page est faite pour vous ! Ci-après, une liste non-exhaustive des petites améliorations qui pourraient être effectuées pour simplifier la vie des admins. | ||
| 2 | |||
| 3 | * Faire du nettoyage : désactiver / supprimer les composants dont l'association ne se sert plus aujourd'hui. Le plus souvent, ça veut dire : | ||
| 4 | ** Des VMs non utilisées (vérifier avec les assos en question) | ||
| 5 | * S'assurer que toutes les données de l'infra sont sauvegardées | ||
| 6 | ** Valider que la stratégie de sauvegarde reposant sur le système Bacula de l'EISTI est toujours valide pour : | ||
| 7 | *** psql-prod | ||
| 8 | *** mysql-prod | ||
| 9 | *** gitlab-prod | ||
| 10 | *** archive-prod | ||
| 11 | ** Rajouter des contenus qui devraient être sauvegardés (salut peertube & slides) | ||
| 12 | ** Documenter le fonctionnement des sauvegardes | ||
| 13 | * S'assurer que les machines sont à jour | ||
| 14 | ** Mettre à jour les VMs vers la dernière version stable de Debian | ||
| 15 | ** Mettre à jour les serveurs physiques vers la dernière version stable de Debian | ||
| 16 | ** S'assurer que Puppet fonctionne correctement une fois ces mises à jour déployées | ||
| 17 | * Automatiser la création de VM / d'enregistrements DHCP / d'enregistrements DNS / de VHosts | ||
| 18 | ** Ça peut être un peu complexe, ça amènerait potentiellement un gros gain de temps pour la maintenance | ||
| 19 | ** Soit ça peut être fait via l'intégration d'une solution d'automatisation déjà existante | ||
| 20 | ** Soit ça peut être fait via une configuration Puppet custom | ||
| 21 | ** Soit ça peut être fait //à la main// via un outil tel que [[nginx-config-generator>>https://gitlab.atilla.org/adminsys/nginx-config-generator]] | ||
| 22 | * Améliorer GitLab pour faciliter son utilisation pour les projets de l'asso | ||
| 23 | ** Soit automatiser (encore plus) sa mise à jour régulière, soit voir pour migrer l'instance vers une installation plus simple et standard | ||
| 24 | ** Mettre à jour les serveurs de CI | ||
| 25 | * Mettre en place un serveur CAS / SSO pour faciliter l'accès aux applications de l'association | ||
| 26 | ** On a déjà un LDAP, normalement ça devrait pas être trop compliqué | ||
| 27 | ** Quelques solutions Open Source qui existent : | ||
| 28 | *** [[LemonLDAP-NG>>https://lemonldap-ng.org/]] | ||
| 29 | *** [[Univention>>https://www.univention.com/]] | ||
| 30 | * Améliorer Members pour mieux gérer les adhésions | ||
| 31 | ** Exemple : actuellement les comptes LDAP restent actifs, même lorsqu'un utilisateur quitte l'asso | ||
| 32 | * Globalement, améliorer la documentation de comment tout le schmilblick fonctionne, pour que les prochains admins s'y retrouvent mieux | ||
| 33 | ** Mettre à jour le [[Guide de l'infrastructure>>Infrastructure.GuideInfrastructure.WebHome]] | ||
| 34 | ** Faire un guide pour que les nouveaux admins s'y retrouvent dans Puppet, car c'est puissant mais c'est un énorme sac de nœuds | ||
| 35 | ** On peut potentiellement créer une synchro entre Puppet et le wiki pour que le wiki stocke des infos sur les machines, et que ces infos soient tenues à jour régulièrement | ||
| 36 | * Globalement, améliorer la manière dont les services de l'asso (qui sont disponibles via l'infra d'ATILLA) peuvent être listés / montrés à un nouvel arrivant | ||
| 37 | * Héberger le bot discord sur nos serveurs | ||
| 38 | * Mettre à jour les schémas d'infra sur gitlab | ||
| 39 | * Mettre en place la role atilla sur touffu pour faire passer le script d'installation de puppet sur les nouvelles VMs | ||
| 40 | |||
| 41 | == Les projets YOLO == | ||
| 42 | |||
| 43 | Si vous n'en avez pas assez, voici quelques projets qui sont totalement en bonus, mais qui pourraient être sympa à réaliser sur l'infra (voyez ça comme un challenge technique) : | ||
| 44 | |||
| 45 | * Mettre en place des ponts entre les différents canaux de discussion d'ATILLA | ||
| 46 | ** Aujourd'hui, on a //au minimum// trois plateformes de chat : | ||
| 47 | *** rocket.atilla.org : quasiment pas utilisé | ||
| 48 | *** atilla-106.slack.com : utilisé par les anciens, principalement | ||
| 49 | *** un serveur sur Discord | ||
| 50 | ** L'idée c'est de mettre en place un outil qui permettrait, depuis Discord (par exemple), de communiquer avec quelqu'un sur Slack. En l'occurrence, il y a un protocole qui existe pour relier plusieurs services entre eux, et c'est [[Matrix>>https://matrix.org]]. En théorie, on peut monter un serveur Matrix sur atilla.org, et le connecter au Discord, au Slack, au Rocket, et à n'importe quelle messagerie qui pourrait être utilisée plus tard. | ||
| 51 | * Fournir un cluster Kubernetes ou OpenShift pour aider les membres de l'association à développer leurs projets | ||
| 52 | * Tester et mettre en place [[Eclipse Che>>https://www.eclipse.org/che/]] | ||
| 53 | * Automatiser plein de trucs sur les VMs via Puppet | ||
| 54 | * Mettre en place un nouveau système de monitoring | ||
| 55 | ** Virer les anciens agents Zabbix présents sur les machines qui n'ont pas été réinstallées depuis peu | ||
| 56 | ** Virer les anciens agents Icinga2 / Nagios présents sur les machines encore plus anciennes | ||
| 57 | ** Mettre en place un nouvel outil de monitoring, ça peut être quelque chose qu'on a déjà utilisé, ou quelque chose de nouveau image:icon:emoticon_smile | ||
| 58 | * SSO over RADIUS : utiliser le fait que, lorsqu'un membre se connecte au réseau d'ATILLA depuis le local, il est authentifié via RADIUS. Cette authentification permettrait également d'authentifier automatiquement le membre aux services de l'association. |