Les Chatons (membres du Collectif des Hébergeurs Alternatifs, Transparents, Ouverts Neutres et Solidaires) veulent sauver Internet en proposant des services décentralisés pouvant remplacer ceux des GAFAM. Cependant, ils n’invitent pas qu’à utiliser leurs services1, leur projet est aussi de vous faire devenir vous‐même un fournisseur de services, pour héberger vos propres données et, pourquoi pas, celles de vos proches.
Cependant, il est normal que vous ayez une appréhension naturelle à vous lancer dans cette activité, parce que vous pensez que vous n’en avez pas techniquement la possibilité ou que les connaissances théoriques à maîtriser sont trop importantes. Sachez qu’il n’en est rien ! La complexité de l’activité n’est qu’une légende uniquement entretenue par les salariés du domaine qui veulent pouvoir négocier un gros salaire2.
Nous verrons dans cette dépêche les quelques concepts à maîtriser pour passer pour un professionnel, et les outils dont il faut s’équiper pour garantir sa tranquillité. Aucun nom de logiciel ou d’entreprise ne sera donné, le choix est immense dans le monde du logiciel libre : les connaisseurs sont invités à indiquer leurs technologies préférées dans les commentaires3.
-
Ce que vous pouvez faire en toute confiance, ce sera toujours mieux que de confier votre vie privée aux entreprises qui veulent les exploiter. ↩
-
Note de l’auteur : si mon employeur me lit, je tiens à préciser que la complexité immense de mon travail mériterait une augmentation. ↩
-
C’est un sujet à troll immense, alors essayez, s’il vous plaît, de présenter ce que vous utilisez sans prétendre qu’on ne fait rien de meilleur… ↩
Sommaire
- Les trois grands concepts à connaître pour passer pour un hébergeur
- La conception d’une plate‐forme : état de l’art
-
Fin de la conception : accouchons de notre plate‐forme
- Supervision : le super‐héros de la tranquillité
- Métrologie : on va prendre des mesures
- Sécurité du réseau : tes parents avaient raison
- Sécurité de la plate‐forme : garde à vous !
- Sauvegarde de la configuration (comme une espadrille : rien à cirer)
- Sauvegarde des données (comme la cire chaude : ça nous fait une belle jambe)
- La sauvegarde : tout à voir avec la choucroute
- Conclusion : alors, tu montes ?
Les trois grands concepts à connaître pour passer pour un hébergeur
Les architectes de plates‐formes de services vous impressionnent ? Et pourtant, ils n’utilisent que trois concepts pour monter une telle architecture, cela est tout à fait accessible à quiconque ayant un peu étudié le sujet.
Haute disponibilité : flambants neufs
La haute disponibilité correspond à la fiabilité de la plate‐forme dans le temps. Celle‐ci s’exprime en pourcentage de temps de bon fonctionnement sur une période donnée (par exemple, si la plate‐forme a été injoignable trois jours pendant un mois de trente jours, on dira qu’elle a une disponibilité de 90 %). Pour se la raconter, les administrateurs aiment bien compter en nombre de neufs pour indiquer ce qu’ils peuvent garantir. Ce qui donne les garanties suivantes :
| garantie | disponibilité | sur 30 jours |
|---|---|---|
| 3 neufs | 99,9 % | 43 min 12 s |
| 4 neufs | 99,99 % | 4 min 19 s |
| 5 neufs | 99,999 % | 25,9 s |
| 6 neufs | 99,9999 % | 2,6 s |
En général, dans le monde professionnel, on prend un engagement entre 3 et 4 neufs, un engagement de 5 neufs est envisageable pour certaines infrastructures. Quant à l’engagement de 6 neufs, qui existe sur le marché, celui‐ci est aussi appelé « il bluffe ».
Lorsque l’on parle de la haute disponibilité d’une plate‐forme, on peut se la raconter en utilisant le vocabulaire suivant :
- haute disponibilité, high availability, HD ou HA : objectif de disponibilité permis par l’architecture mise en place ;
- GTI ou Garantie de Temps d’Intervention : délai maximal entre le début d’une panne et le début de l’intervention d’un technicien ;
- GTR ou Garantie de Temps de Rétablissement : temps maximal de remise en service après le début d’une panne ;
- MTTR ou Mean Time To Repair : temps moyen de remise en service après le début d’une panne ;
- SLA ou Service Level Agreement : engagements de service, incluant pour la partie technique la HD, la GTI, le MTTR et la GTR.
Scalabilité : aller plus haut !
Lorsque l’on monte une plate‐forme, surtout si celle‐ci est destinée à des services Internet, il n’est pas toujours facile de prévoir quel sera son usage. On peut, par exemple, avoir juste quelques utilisateurs au début, puis suite à une citation à la télévision, en avoir plusieurs dizaines de milliers qui arrivent rapidement. Dans le plan de haute disponibilité, on peut avoir mis en place une limitation en nombre (lorsque le plafond est dépassé, les nouveaux utilisateurs n’ont pas accès au service ou ont accès à une version dégradée), mais si la situation doit durer, il faut adapter la plate‐forme à cette augmentation de l’usage, afin qu’un maximum d’utilisateurs potentiels puissent accéder au service. La scalabilité correspond à la capacité d’une plate‐forme à s’adapter à l’évolution de son utilisation. Il y a quatre grands types de scalabilités :
- la scalabilité 0 : la plate‐forme peut accueillir un maximum d’utilisateurs, et rien n’est prévu en cas de dépassement de ce plafond, on veille simplement à garantir que la plate‐forme saura encaisser jusque celui‐ci et qu’elle refusera de façon élégante au‐delà (page d’erreur explicative, redirection vers un autre service, appel à financement…) ;
- la scalabilité projet : la plate‐forme n’est pas prévue pour encaisser un dépassement de plafond, mais est compatible avec d’éventuels projets d’évolution qui permettraient d’ajouter de la capacité ; la durée de mise en place de cette extension de capacité peut être ou non prévue contractuellement ;
- la scalabilité préventive : la plate‐forme est conçue pour pouvoir encaisser une importante évolution des besoins de capacité ; des systèmes d’alerte préviennent quand des ressources matérielles commencent à manquer pour pouvoir continuer à encaisser les prochaines augmentations afin que le matériel supplémentaire puisse être installé avant tout dépassement ;
- la scalabilité dynamique : la plate‐forme est située dans un écosystème permettant une extension bien supérieure aux besoins à venir, et toute son architecture est conçue pour s’adapter aux besoins au fur et à mesure que ceux‐ci augmentent ou baissent.
Exploitabilité : veiller sur les néophytes
L’exploitabilité d’une plate‐forme consiste à offrir un même niveau d’information pour toute personne ayant à intervenir dessus. Le meilleur moyen de la mettre à l’épreuve est d’accueillir un nouvel arrivant, parce qu’il souhaitera pouvoir travailler vite et il convient de ne pas le démotiver. Pour cela on veillera à :
- qu’il sache quoi lire pour se familiariser avec la plate‐forme ;
- qu’il comprenne comment celle‐ci est conçue ;
- qu’il soit en mesure de faire des petites tâches ;
- qu’il participe rapidement à la réparation de pannes et autres problèmes ;
- qu’il puisse apporter sa pierre à l’édifice sans risque.
Si la documentation remplit ces conditions, on considérera qu’elle est en mesure de répondre à tous les besoins de toute personne ayant à intervenir sur la plate‐forme. L’objectif n’est pas seulement que les personnes puissent travailler seules, une documentation simple, à jour et utile ne peut être qu’une conséquence d’un travail d‘équipe efficace.
La conception d’une plate‐forme : état de l’art
Depuis les débuts des services Internet ouverts au public, la déclinaison pratique des trois grands concepts a évolué pour suivre les évolutions technologiques et managériales apparues au cours des années. Ainsi, pour concevoir sa plate‐forme on peut s’inspirer de ce qui a existé, selon ses moyens et compétences.
Années 1990 : la pl@te‐forme
Si vous retrouvez une vieille publicité avec un nom de service contenant un « a » remplacé par « @ », vous êtes en contact avec les années 1990, glorieuse période ayant vu décliner les disquettes, au début de laquelle fut inventé le World Wide Web (qui changera l’usage d’Internet), et pendant laquelle un gnou et un manchot se sont rencontrés pour former un couple qui mènera à une démocratisation de l’activité d’hébergeur1.
Haute disponibilité de la pl@te‐forme : quand le PRA tique
Héritées des grosses infrastructures de l’informatique de gestion, les méthodes de conception de plates‐formes Internet sont structurées autour de quatre axes pour assurer leur disponibilité :
- la redondance : la perte d’un élément ne doit pas causer la perte de la plate‐forme, tous les éléments faillibles doivent être présents en double ; il y a donc des disques redondés dans les serveurs, deux alimentations électriques différentes et deux circuits de refroidissement dans la salle d’hébergement, et, bien sûr, deux accès au réseau au minimum ;
- la duplication : une plate‐forme miroir de l’existante est présente et peut prendre le relais en cas d’indisponibilité de la plate‐forme nominale ; si possible, le miroir est installé dans un autre site géographique pour éviter qu’un élément puisse rendre indisponibles les deux plates‐formes en même temps (…) ; il est aussi souvent envisagé de réduire les coûts de la seconde plate‐forme, en n’y implémentant pas de redondance ou en réduisant sa capacité (le service étant dégradé en cas d’utilisation) ;
- la réplication : les mêmes données et services doivent être présents dans la plate‐forme nominale et celle de secours ; pour assurer cela, les opérateurs ont comme consigne de faire systématiquement toutes leurs interventions sur les deux plates‐formes (ce qui dans les faits ne peut pas toujours être fait, et la bascule se révèle pleine de surprises) et/ou une solution logicielle permet la réplication automatique du premier site vers le miroir (ce dernier ayant toujours des données en retard à l’époque, parce que les liens réseau étaient particulièrement coûteux et peu capacitaires) ;
- le plan de reprise d’activité : le PRA est une procédure indiquant comment basculer du site nominal à celui de secours (et inversement), dans les entreprises les plus sérieuses on le teste régulièrement (cela donnant souvent lieu à une non‐satisfaction faute de procédure claire et/ou de mauvaise réplication), mais en général on attend que ça casse pour tenter une bascule et regretter de ne pas avoir fait de tests plus tôt, pour améliorer la procédure et le miroir avant qu’on en ait besoin.
Scalabilité de la pl@te‐forme : TMC, t’es bath, t’es in
Les grosses infrastructures des années 1990 étaient démesurément coûteuses et représentaient un investissement sur plusieurs années, il n’était donc souvent pas envisageable de les faire évoluer pendant la période d’amortissement de cet investissement. La scalabilité 0 (souvent cachée par une pseudo‐scalabilité projet impossible à mener) est donc de mise, et seul un nombre d’utilisateurs défini sera destiné à être accueilli par la plate‐forme. Pour définir ce nombre d’utilisateurs, on procède à des tests de montée en charge (TMC), ceux‐ci consistant à :
- définir les cas d’usage : les différents scénarios d’utilisation du service sont listés (par exemple, on aura le scénario de simple lecture, le scénario de connexion, le scénario d’édition, le scénario de recherche, etc.) ;
- anticiper l’usage : on définit quelle part de l’usage représentera chaque scénario, grâce à une méthode pifométro‐bayésienne et/ou une étude de marché poussée (par exemple : 90 % de lecture, 0,1 % de connexion, 5 % de recherche, etc.) ;
- simuler l’usage : à l’aide de logiciels spécialisés ou de programmes internes, on met en place des simulateurs des différents scénarios (permettant de lancer en un clic ou une ligne de commande n’importe quel cas précédemment défini), ceux‐ci intégrant une vérification du bon fonctionnement (validant que le résultat attendu est obtenu sans erreur) ;
- tirer ! : le tir de TMC consiste à exécuter les scénarios selon l’usage prévu (par exemple, sur mille scénarios lancés, il y en aura neuf cents de lecture et dix de connexion) pour voir combien d’utilisateurs en simultané peut accueillir la plate‐forme (quand les scénarios commencent à remonter des erreurs, on arrête le tir et on compte combien d’utilisateurs étaient simulés) ; les donneurs d’ordres ayant le plus de budget peuvent demander plusieurs tirs de TMC selon différents réglages de l’infrastructure et/ou répartitions des usages envisagés.
Exploitabilité de la pl@te‐forme : pas de choix, le DAT
« Dossier d’architecture technique » ou DAT : sous ce nom qui évoque des moments douloureux aux moins jeunes d’entre nous se cache un monstre documentaire. Il faut envisager la conception d’une plate‐forme comme un cycle long, faisant intervenir de nombreux acteurs (architectes, installateurs, développeurs, experts système et/ou réseau, etc.). Pour s’y retrouver dans tout cela, on demande à chacun de noter tout ce qu’il fait, pourquoi il le fait et comment il le fait. Puis, pour chaque tâche d’exploitation, on écrit également le quoi/pourquoi/comment, et pendant toute la vie de la plate‐forme on doit mettre à jour le DAT, au fur et à mesure qu’on apprend (méthodes de résolution des incidents les plus courants, correction du PRA suite à un test ayant mené à un échec…), que des mises à jour sont effectuées et que des éléments sont ajoutés ou retirés.
Le problème est qu’il y a de multiples intervenants devant intervenir sur le PRA, et qu’on se retrouve souvent avec plusieurs versions en parallèle de celui‐ci, qui seront fusionnées plus ou moins bien lorsqu’on voudra obtenir un document unique. Pire, les mises à jour prennent énormément de temps (il faut vérifier dans toutes les parties qu’une modification n’en entraîne pas d’autres), et les intervenants ne disposent pas de suffisamment de temps et de volonté pour mettre à jour ce document. Ainsi, on voit fleurir sur les bureaux des montagnes de papier portant la mention « ne pas jeter », avec toutes les notes nécessaires à la mise à jour du DAT… qui, bien entendu, ne sera jamais réalisée.
Années 2000 : la plate‐forme 2.0
Les années 2000, où chaque entreprise se devait d’avoir une stratégie numérique avec un nom finissant par « 2.0 », ont plutôt mal commencé dans le domaine de l’informatique, puisque les pauvres développeurs ont eu à travailler successivement sur la gestion du bogue de l’an 2000 et le passage à l’euro. Les métiers de l’informatique en général ont souffert de la grande chute financière du secteur des nouvelles technologies. Mais les services sur Internet ont continué à croître et il n’était plus envisageable pour une structure quelle qu’elle soit de ne pas être présente en ligne.
Haute disponibilité de la plate‐forme 2.0 : et on fait tourner les serveurs
Le matériel coûtant moins cher, on peut se permettre d’avoir plusieurs serveurs qui rendent le même service. Ainsi, en cas de perte d’un serveur il en reste toujours d’autres pour prendre le relai : un équipement ou un logiciel ayant la fonction de répartiteur de charge est utilisé pour diriger le service vers les seuls serveurs en état de fonctionnement. Les coûts d’interconnexion à Internet ayant également baissé, il est possible d’avoir une infrastructure distante répliquée en continu avec l’architecture nominale, ce qui permet d’éviter les problèmes de retard de réplication lors de l’activation du PRA.
Scalabilité de la plate‐forme 2.0 : des cas denses
Puisque l’on dispose d’un répartiteur de charge qui peut envoyer le service à plusieurs serveurs identiques, la scalabilité est en général gérée de façon simple en ajoutant des serveurs au fur et à mesure que le nombre d’utilisateurs augmente. Cependant, si l’on a beaucoup de services différents, on finit par constater que tous les serveurs ne sont pas chargés en même temps (les sites pros et les sites grand public, par exemple) ou de la même façon (certains chargent surtout la mémoire, d’autres les disques, d’autres le processeur, etc.). Des moyens de mettre ces différentes applications sur les mêmes serveurs se sont développés afin de « densifier » la plate‐forme 2.0 (machines virtuelles et conteneurs) : on peut ainsi utiliser au mieux les capacités totales.
Exploitabilité de la plate‐forme 2.0 : un jeu d’enfants
Les années 2000 furent celles de la popularisation du wiki, la révolution du travail en équipe : en général, la première version saisie rappelle un DAT, mais sa mise à jour est tellement simple que c’en est fini des papiers « à traiter plus tard » qui s’entassent. Chacun peut créer de nouvelles pages hors pseudo‐DAT avec des informations plus opérationnelles qu’architecturales (comment réparer un service particulier lorsqu’il a un problème, comment vérifier un bon fonctionnement, etc.), et tous les intervenants sont en mesure de mettre à jour la documentation pendant toute la durée de vie de la plate‐forme 2.0 (ajout et suppression de serveurs, densification, modification de la méthode de répartition de charge, etc.).
Années 2010 : Cloud Agility Platform On The Enfuming
Si l’on travaille dans les services Internet dans les années 2010, il est absolument nécessaire d’utiliser des mots (pseudo‐)anglophones à la mode, surtout si c’est pour les détourner de leur sens (ici on va utiliser l’amphigouri « Cloud Agility Platform On The Enfuming », qu’on résumera par l’acronyme « CAPOTE »). Ces années voient arriver une augmentation exponentielle des usages d’Internet, avec la multiplication des téléphones mobiles intelligents et des objets connectés. Par ailleurs, ce sont les années de la centralisation des services sur Internet, ceux‐ci se retrouvant essentiellement dans les mains des GAFAM. Heureusement, cela provoque une prise de conscience qui redonne de la vigueur aux micro‐acteurs comme les CHATONS, et laisse encore un peu d’espoir pour les années 2020.
Haute disponibilité de la CAPOTE : dans ton centre
L’augmentation continue de la capacité des liens Internet permet de gérer un site distant comme un site proche, si bien que la notion de PRA n’a plus de sens. Les services et les données sont répartis entre plusieurs centres de données, et si l’un d’entre eux est perdu, ça ne pose pas de problème, puisque d’autres continuent à rendre le service. On comprend pourquoi certains opérateurs annoncent pouvoir garantir des taux de disponibilité paraissant incroyables : le principe de coupure de service n’existe théoriquement plus.
Scalabilité de la CAPOTE : Jawad Academy
Alors que dans les années 2000 on avait commencé à virtualiser les serveurs pour optimiser l’usage de nos serveurs physiques, dans les années 2010 on va un cran plus loin : les serveurs physiques et virtuels sont totalement décorrélés. Pour créer un serveur virtuel, on indique seulement au « cloud » les caractéristiques du serveur souhaité et celui‐ci est implémenté automatiquement sur un serveur physique dans un centre de données quelconque, sans que l’on ait à s’en soucier2. Le serveur virtuel ne sait pas qui l’héberge, et les serveurs physiques ne savent pas ce qu’ils hébergent, tel un propriétaire qui louerait un appartement sans se soucier de qui sera dedans.
La création de serveurs devient un simple appel à une interface de programmation applicative, gérée depuis les logiciels métier des créateurs et exploitants d’infrastructure. De nombreuses expressions en anglais sont utilisées pour vendre ce type de services, finissant souvent par « … as a service » ou « … as code ».
Exploitabilité de la CAPOTE : un outil bien en main
Comme l’infrastructure est de plus en plus gérée comme du code, les hébergeurs ont commencé à utiliser les outils des développeurs, notamment les forges logicielles, dans lesquelles on peut stocker toutes les informations permettant de :
- décrire l’infrastructure, à l’aide de fichiers de description d’état cible utilisés par des logiciels pour installer et contrôler automatiquement des machines stockées dans le dépôt logiciel ;
- suivre les modifications, et mettre en place des processus de validation ;
- répertorier les incidents et demandes des utilisateurs avec le système de tickets ;
- gérer plus finement les droits de chacun des administrateurs avec les concepts de groupe ;
- documenter au fur et à mesure en remplissant le fichier de documentation associé à chaque création ou modification.
Comme dans les projets logiciels, si l’organisation humaine n’est pas pensée pour utiliser ces outils (auto‐validation des changements, absence de relecture des documentations, faible valorisation du traitement des tickets), ceux‐ci peuvent créer de nouveaux problèmes plutôt que d’en résoudre, ajoutant de la complexité par rapport aux gestions historiquement manuelles des configurations et documentations.
Fin de la conception : accouchons de notre plate‐forme
L’infrastructure est en place, celle‐ci a des conditions de disponibilité et de scalabilité connues, et bénéficie d’une exploitabilité optimale. Maintenant, il vous faut l’exploiter et, pour cela, quatre plans doivent être obligatoirement mis en place dès le premier jour :
- la supervision ;
- la métrologie ;
- la sécurité ;
- la sauvegarde (même si l’on verra que c’est sans intérêt).
Supervision : le super‐héros de la tranquillité
Le plan de supervision doit prévoir des outils qui permettent de valider en continu :
- l’état du matériel (défaillance d’un disque, port réseau déconnecté…) et de son environnement (température de la salle trop élevée, intrusion dans un espace protégé…) ;
- l’état du réseau (lien perdu, trafic inhabituel, répartiteur de charge défaillant…) ;
- l’état du système (espace disque, utilisation processeur, mémoire, etc.) ;
- l’état des applicatifs (serveur de courriel, serveur de base de données, etc.) ;
- l’état du service, qui est la seule chose qui intéresse les utilisateurs, en trouvant des moyens de tester celui‐ci de bout en bout (par exemple en simulant le comportement de la plante connectée qui veut moins d’eau et plus de soleil).
Métrologie : on va prendre des mesures
La métrologie se présente en général sous forme de graphes. Ces graphes permettent de voir dans le temps les usages système, applicatifs et services de son infrastructure. Cela permet de faire de l’analyse à chaud (si un disque est plein, on n’interviendra pas de la même façon en sachant que ça a descendu progressivement pendant des mois que si c’est descendu en une fois le jour même) ou à froid (si un incident survient, on pourra trouver ce que l’on aurait dû superviser pour le détecter avant une coupure de service).
Les outils de métrologie récents permettent de faire de la corrélation de données, pour pouvoir, par exemple, surveiller ensemble l’utilisation des processeurs, le nombre de connexions à la base de données et le temps de réponse du service, cela évite de devoir utiliser des méthodes artisanales de superposition des graphes utilisées jusque dans les années 2000. Il est à noter que l’on peut utiliser le même outil pour la supervision et la métrologie, ou que l’outil de métrologie peut appeler l’outil de supervision pour alerter en cas de mesure anormale.
Sécurité du réseau : tes parents avaient raison
Une vision très fausse que l’on peut avoir en montant son infrastructure, est de constater qu’Internet concentre les méchants, et notre plate‐forme les gentils, mettons un grand mur entre les deux et on sera à l’abri… Mais de quel côté sont vos utilisateurs ? Comment savez‐vous que vos services ne sont pas utilisés pour faire le mal ?
Une autre vision est portée par les commerciaux de certaines entreprises. C’est simple : on doit arrêter les méchants et laisser passer les gentils, avec un super outil bien cher, vous pourrez dormir tranquille. Sauf que si avec un outil vous pouvez détecter les méchants sur Internet, il ne devrait plus y en avoir, non ?
Pour commencer de la sécurité réseau, mettez simplement un pare‐feu qui bloque tout, sauf ce qui est nécessaire au bon fonctionnement du service. Quel que soit le sens de passage, votre équipement doit suivre le conseil de grand‐maman : « on ne doit pas parler aux inconnus ».
Sécurité de la plate‐forme : garde à vous !
- il faut faire les mises à jour de sécurité de son système, systématiquement ; le mieux pour ça est d’utiliser une distribution GNU/Linux disposant d’une équipe sécurité réactive ;
- il faut faire les mises à jour de sécurité de ses applicatifs, systématiquement ; on n’installera pas de logiciel non suivi par une équipe de sécurité (si vous avez fait le choix de compiler un logiciel vous‐même, vous devrez suivre les mises à jour de sécurité vous‐même), le mieux est encore d’utiliser les logiciels portés par une distribution GNU/Linux disposant d’une équipe sécurité réactive ;
- il faut limiter au maximum les droits des administrateurs (l’expert en courriel n’a pas à redémarrer la base de données), utilisateurs (les espaces de chacun doivent être cloisonnés) et applications (l’outil de publication de contenu ne doit pas pouvoir accéder à la métrologie) ;
- il faut éduquer les utilisateurs et administrateurs, en suivant par exemple une charte ; les CHATONS tiennent beaucoup à cet aspect, mais il faut aussi y veiller autant que l’on peut en milieu professionnel, même si une mauvaise relation opérateur‐client rend cela difficile ;
- il ne faut jamais oublier que derrière quelque chose de visiblement mignon, peut se cacher quelque chose de bien plus inquiétant : tout ce que vous ne connaissez pas est un danger.
Sauvegarde de la configuration (comme une espadrille : rien à cirer)
La sauvegarde de la configuration permet d’espérer que, si l’on a un gros crash, on sera capable de reconstruire partiellement ou totalement la plate‐forme en s’aidant des données sauvegardées. Il existe quatre solutions de sauvegarde de la configuration :
- tenter de deviner tous les répertoires et fichiers contenant des éléments de configuration, et les sauvegarder… mais on est à peu près certains d’en oublier ;
- sauvegarder totalement à partir de la racine chaque serveur, au moins on est sûr d’avoir les configurations dans la masse… ça peut fonctionner, mais c’est extrêmement coûteux ;
- ou peut compter sur le DAT ou le wiki pour contenir toutes les configurations à jour… pour plus de sécurité, il est prudent de demander au père Noël de veiller à leur mise à jour ;
- si toute la configuration est dans une forge logicielle, il suffit de sauvegarder la forge logicielle et, mieux, on peut s’attendre à ce que tous les administrateurs disposent d’au moins une copie des configurations pour pouvoir travailler… si l’on dispose d’un outil de déploiement automatique des configurations, remonter la plate‐forme peut ne nécessiter que quelques minutes.
Vous pouvez suivre ces conseils, mais de toute façon la sauvegarde de la configuration n’est d’aucune importance.
Sauvegarde des données (comme la cire chaude : ça nous fait une belle jambe)
On peut ne pas sauvegarder les données et demander aux utilisateurs de le faire. Cette méthode est la moins coûteuse, et si vous lisiez les CGU de tous les services que vous utilisez, vous sauriez que c’est un usage courant pour les services grand public.
Si l’on sauvegarde les serveurs à la racine pour la configuration, cela fera également une sauvegarde des données. Cependant la sauvegarde des fichiers de certains outils comme les bases de données ne permettront pas de reconstruire une base, parce que les données seront corrompues : il faut dans ce cas utiliser un outil spécifique qui pourra générer un format d’exportation.
Il faut donc identifier les données à sauvegarder, puis vérifier si une simple copie de fichiers suffit ou s’il faut exporter les données avec un outil spécifique. Enfin, à quoi bon faire cela ? Après tout, la sauvegarde des données n’a pas le moindre intérêt.
La sauvegarde : tout à voir avec la choucroute
On pourrait parler des différents types d’outils de sauvegarde, mais on n’en a rien à secouer. On pourrait aussi parler de l’archivage qui est destiné à stocker pendant une certaine durée des données qui ne sont pas destinées à être modifiées (archivage légal, fermeture d’un service, etc.), mais on s’en câlisse. Pourquoi donc autant de mépris pour la sauvegarde, alors qu’elle semble absolument nécessaire aux utilisateurs comme aux administrateurs ? Pour une simple raison : une donnée sauvegardée n’a de l’intérêt que si l’on sait la restaurer, autrement dit ce que les utilisateurs et administrateurs demandent, ce n’est pas de sauvegarder, mais de pouvoir restaurer le jour où on l’en a besoin ! Alors, intégrez des tests de restauration dans la supervision, et vous pourrez commencer à trouver un intérêt à la sauvegarde.
Conclusion : alors, tu montes ?
Si vous avez à peu près tout compris de ce billet, vous avez toutes les compétences théoriques pour devenir hébergeur, et vous pourriez même faire illusion devant certains recruteurs. Il ne reste plus qu’à acquérir les compétences techniques.
Monter sa propre plate‐forme
Monter sa propre plate‐forme pour héberger des services non critiques est un bon moyen pour commencer à apprendre seul comment gérer une infrastructure. Au niveau matériel, on peut faire ça sur son PC ou sur un nano‐ordinateur dédié. Et si l’on ne veut pas dépendre de sa connexion à Internet, il existe de nombreux services proposant des locations de serveurs (physiques ou virtuels). Côté logiciel, le plus simple pour commencer est d’utiliser une distribution YunoHost destinée spécifiquement aux hébergeurs débutants.
Intégrer une équipe existante
Sur le site des Chatons, on peut trouver une carte de tous les chatons existants. S’il y en a un près de chez vous, vous pouvez essayer de le contacter pour rejoindre leur équipe technique.
Autre solution, vous pouvez proposer au Chapril (chaton de l’April) de gérer un service (ou autant de services que vous voulez, mais vous pouvez n’en gérer qu’un si plus vous effraie). Il suffit pour cela de s’inscrire à la liste de discussion et de se présenter, tout le monde est bienvenu.
En faire son métier
Si vous comptez travailler dans ce domaine, sachez qu’il est fort probable que vous ayez un entretien et/ou un test technique pendant la phase de recrutement, il est donc déconseillé d’y aller au bluff. Ce qui fera la différence entre plusieurs candidats sera souvent l’expérience, même si celle‐ci est associative ou solitaire.
Toutes les images contenues dans cette dépêche peuvent, comme le texte, être distribuées sous licence CC-BY-SA. Celles‐ci sont dérivées des œuvres de Kotivalo, Hell Pé, Bibi Saint‐Pol, Bug_de_l'an_2000, Luigi Chiesa, Darby, GitLab, RRZEicons, Georges Biard, le projet Debian, Matt92300, Dark Attsios, Arnaud 25, Sinovoip, A. Lorenzo et John Markos O’Neill
-
Oui, il manque ici d’autres technologies ayant grandement participé à la domination des protocoles standards sur Internet, mais il y aurait eu trop d’animaux à citer si j’avais voulu les intégrer, citez‐les vous‐mêmes en commentaire. ↩
-
Certains services d’informatique en nuage permettent cependant d’imposer des contraintes géographiques. ↩
# top news
Posté par bubar🦥 (Mastodon) . Évalué à 6.
bash
okok je ->
[^] # Re: top news
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
mieux : POSIX Shell !
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# J'ai rien compris
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -4.
Vous pouvez faire un TL;DR en bon français ?
[^] # Re: J'ai rien compris
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 10.
Si tu ne veux pas qu'un gars-femme te fasse un enfant dans le dos, il faut mettre une CAPOTE. Et élever des chatons.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: J'ai rien compris
Posté par Denis Dordoigne . Évalué à 3. Dernière modification le 12 janvier 2019 à 08:43.
Je suis en train d'imaginer l'image que j'aurais mise si j'avais pensé au jeu de mots « gars-femme », et je suis content qu'on y ait échappé !
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: J'ai rien compris
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4.
Je suis allé voir chapril qui propose 4 services et c'est un bon début. Notamment le pad. Et en quoi c'est différent des framatools ?
[^] # Re: J'ai rien compris
Posté par Denis Dordoigne . Évalué à 4.
Pour comprendre les chatons, le mieux est de lire la dépêche correspondante
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: J'ai rien compris
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4. Dernière modification le 13 janvier 2019 à 16:04.
Merci, C’est un peu plus clair avec cette dépêche (faut penser à les mettre au début pour ceux qui ont raté l’ épisode précédent). Maintenant que se passe t’il si j’heberge Un service de pad chez moi et que quelqu’un s’en sert pour partager des propos pénalement répréhensibles ou des données à caractère personnel qui n’ont rien à y faire ?
[^] # Re: J'ai rien compris
Posté par Denis Dordoigne . Évalué à 9.
En France, rien. Sauf si tu en es informé, ce qui ne sera pas le cas a priori parce que tu ne surveilles pas les agissements de tes utilisateurs. Quelqu'un peut t'en informer, mais ça implique qu'il le fasse d'une façon bien normalisée pour que tu sois en mesure de constater que le contenu est manifestement illégal.
Si tu veux des informations juridiques à propos de l'hébergement, on partage ce type d'informations avec les chatons : https://wiki.chatons.org/doku.php?id=pointsjuridiques (pour le moment on n'y parle presque uniquement de droit français, à noter qu'on cherche quelqu'un qui s'y connaît en droit allemand pour compléter cette page).
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: J'ai rien compris
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 5.
"En France, rien."
T'es sur de ton coup ?
"parce que tu ne surveilles pas les agissements de tes utilisateurs"
Admettons, j'ai signé une charte d'éthique. Mais qu'est ce qui garantit aux utilisateurs que je ne les surveille pas ?
"Quelqu'un peut t'en informer, mais ça implique qu'il le fasse d'une façon bien normalisée"
Ça tombe bien, j'aime bien les normes, mais je n'ai rien trouvé s'y rapportant dans les pages suscitées.
"constater que le contenu est manifestement illégal"
C'est là que ça devient intéressant. En tant qu'hébergeur, suis je tenu de signaler ce contenu manifestement illégal ? Est ce que les "autorités" peuvent me demander des informations sur ce contenu, voire venir saisir mon matériel ?
"on n'y parle presque uniquement de droit français"
C'est un bon début, et on me souffle dans l'oreille que ça peut être intéressant d'héberger ses chatons en Suisse.
[^] # Re: J'ai rien compris
Posté par Denis Dordoigne . Évalué à 10.
Totalement, le statut de prestataire technique est très protecteur : https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=LEGIARTI000032400316&cidTexte=LEGITEXT000005789847
Ben c'est toi qui te l'interdis, et c'est dans ton intérêt, si tu relis tout ce que tu héberges tu risques de te voir attribuer le statut d'éditeur, qui lui est plein de responsabilités !
C'est la partie "Critères de notification" dans le wiki (ça ne ressemble pas une RFC)
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: J'ai rien compris
Posté par barmic . Évalué à 4.
Faudra l'expliquer à framasoft un jour, puisque c'est l'argument qui était ressorti quand je m'étais interrogé au sujet de la clause « Tout abus sera puni » qui dit « si un utilisateur abuse du service, par exemple en monopolisant des ressources machines partagées, ou en publiant des contenus considérés comme non pertinents, son contenu ou son compte pourra être supprimé sans avertissement ni négociation. »
[^] # Re: J'ai rien compris
Posté par Denis Dordoigne . Évalué à 3.
Framasoft héberge ses services en Allemagne, je n'ai aucune idée de la réglementation là-bas.
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: J'ai rien compris
Posté par barmic . Évalué à 4.
Ça ne change rien. Ils ne disent pas que c'est lié aux droit du pays où ils hébergent, ils se donnent juste le droit de d'être arbitraire. D'ailleurs ça pourrait être intéressant que ce soit plus mis en avant le lieu d'hébergement. Ça permet de savoir quel droit est en vigueur.
[^] # Re: J'ai rien compris
Posté par Pol' uX (site web personnel) . Évalué à 3.
Beh il se passe que « quelqu’un s’en sert pour partager des propos pénalement répréhensibles ou des données à caractère personnel qui n’ont rien à y faire ».
Adhérer à l'April, ça vous tente ?
[^] # Commentaire supprimé
Posté par tommy21 . Évalué à -1. Dernière modification le 08 février 2019 à 12:15.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par tommy21 . Évalué à -1. Dernière modification le 08 février 2019 à 12:15.
Ce commentaire a été supprimé par l’équipe de modération.
# Meilleure dépeche Linuxfr de tous les temps !
Posté par dinomasque . Évalué à 8.
C'est lumineux (et bien joliment illustré).
BeOS le faisait il y a 20 ans !
# ahaha...
Posté par ocebe . Évalué à 10.
J'ai ri.
[^] # Re: ahaha...
Posté par voxdemonix . Évalué à 8. Dernière modification le 11 janvier 2019 à 14:34.
Perso je trouve la phrase un tantinet mensongère quand on voit :
Le tout devant bien entendu être sécurisé (OS, réseau, accès, search engine, etc).
Sans compter non plus le fait qu'il n'y a généralement pas de module de payement intégré permettant a monsieur/madame tout le monde de louer son ou ses services sur le nain-ternet.
Et ne parlons même pas des projets basé sur NodeJS.
[^] # Re: ahaha...
Posté par Denis Dordoigne . Évalué à 9.
Oui oui je suis d'accord (insérer ici un gros clin d'œil complice)
Pas tant que ça lorsqu'on utilise des logiciels libres communs, il faut essentiellement savoir lire l'anglais et utiliser un moteur de recherche.
C'est vrai, mais je ne trouve pas que ça complexifie tant que ça notre travail, si ce n'est la partie diplomatique quand plusieurs personnes se renvoient la balle
Là je ne vois pas la difficulté, il y a probablement quelque chose qui m'échappe
Jamais eu de problèmes lors de mises à jour de sécurité, et avec les outils actuels il est très simple de monter une machine identique à la prod pour les tests
Attention, n'utilise pas ça pour justifier ton salaire, si tu prétends ne pas savoir l'anglais et être allergique aux sites moches, je crains que tu sois déclaré inapte (et pour les docs qui ne sont pas à jour, on peut toujours s'appuyer sur des archives de listes, des forums, des blogs, voire même des dépêches ou journaux linuxfr).
Alors là je ne suis pas du tout d'accord, on a toujours au moins une interface en ligne de commande, et de plus en plus des API, je trouve que ça n'a jamais aussi simple de faire de l'administration
Je pense que si c'est compliqué, c'est bien parce qu'on n'a pas de super-pouvoirs, on sait juste appliquer la doc et galérer quand elle n'est pas suffisante.
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: ahaha...
Posté par voxdemonix . Évalué à 8. Dernière modification le 12 janvier 2019 à 14:39.
Ton article semble s'adresser aussi aux auto-hébergé, monde du quel je proviens. Donc pas de salaire, mais l'objectif doit être atteint peu importe comment.
Tant qu'on y est, je te remercie pour la rédaction de cet article fort intéressant 😉
Pour mettre en place un bête Hello World web il te faut :
Et si jamais tu décides d'utiliser plusieurs machines: tu fais exploser le nombre de sujets a traiter (sécurité des communications interservers, proxy/frontend, optimisations diverses, différents stockages distants).
Avoir la motivation d'écrire risque vite de se faire sentir quand l'aide d'autrui sera nécéssaire.
A plusieurs ok, mais quand tu es seul ces bugs peuvent vite s'avérer complètement bloquant, surtout pour un francophone.
Par exemple Got an error reading communicatoin packets
ou encore Glusterfs-server - pourquoi l'arbitre se rempli-t-il.
Dernièrement j'ai pu expérimenter de mettre à jours deux serveurs de ubuntu 16.04 a 18.04 => obligé de formater car kapout. (=> et le lendemain ce fut nextcloud qui explosa car il a pas du tout kiffé que le noeud de secoure soit resté sous php7.0 alors que les autres étaient passé a php7.2).
Pour nous (milieu DIY) c'est aussi plus difficile de recréer des machines à l'identique avec des trucs comme chefcook/Ansible/docker qui sont trop compliqué (et doc pas traduite).
C'est simple : tu te retrouves a tout gérer en command line (bonjour les oublis/erreurs + la difficulté pour cloisonner). Et quand tu as besoin de modifier des droits par défaut (par exemple pour monter un cluster web), c'est la galère.
(pour créer le tuto linké juste avant, j'ai dû peter deux noeuds de mon cluster à force de modifier des fichiers de conf de partout)
GlusterFS ne possède aucune interface libre, même pas en CLI. Si tu veux une interface tu vas sur un fournisseur cloud qui te louera l'accès à sa surcouche qu'il ne partagera jamais avec la communauté du libre.
Vivement le jour où quelqu'un se décidera à coder un outils en CLI permettant de visionner/tester/gérer les permissions Unix aisément plus tôt que de devoir tout faire à la mano.
Va expliquer ça aux utilisateurs 😁
[^] # Re: ahaha...
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Moi "souvent". Car s'il est vrai que ça se passe extrêmement souvent bien, quand tu as beaucoup de serveurs à gérer, tu tombes sur des problèmes aléatoires ou des combinaisons exotiques. Bref les tests sont indispensables (si tu ne veux pas de soucis en prod, ce qui n'est par forcément rédhibitoire en autohébergement), mais ça n'empêche pas malgré tout des soucis parfois. Et bien sûr il faut faire les mises à jour, s'en dispenser ne résoud rien non plus.
[^] # Re: ahaha...
Posté par Denis Dordoigne . Évalué à 2.
Je réponds qu'à cette partie de ton commentaire parce que je suis d'accord sur le reste, mais sur cette partie je ne suis pas du tout d'accord. Quoique en lisant la suite :
Je pense que le vrai soucis est l'utilisation d'un outil pour copier des données qui ne gère pas les droits lui-même, il aurait été plus simple d'utiliser quelque chose basé sur rsync ou scp, par exemple lsyncd (https://linuxfr.org/news/exploiter-inotify-c-est-simple#lsyncd--vers-un-syst%C3%A8me-de-fichiers-distribu%C3%A9).
Par contre je ne critiquerai pas le fait que tu n'aies pas abandonné ton outil (après avoir constaté que son usage était bordélique et qu'il vaudrait mieux chercher une autre solution), je l'ai fait trop de fois
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: ahaha...
Posté par voxdemonix . Évalué à 1. Dernière modification le 13 janvier 2019 à 17:47.
Dans le cas présent ce serait plus tôt glusterfs (ou alternative) qui conviendrait, avec réplication sur toutes les machines. Mais il consomme hélas trop de ressources, est très lent avec les petits fichiers et ses bugs m'ont trop frustré.
Rsync ne permet que de faire des modifications dans un sens si je ne m'abuse.
Donc si tu modifies un fichier sur la machine A, un autre sur la machine B et aucun fichier sur la machine C :
tu vas devoir créer un truc en série assez bordelique pour propager les modifs. Syncthing a le mérite de tourner dans les deux sens, d'automatiser l'échange de clés de chiffrement, de disposer d'une interface rassurante et de completement faire abstraction de la notion de nom de domaine ou d'adressage IP.
[^] # Re: ahaha...
Posté par barmic . Évalué à 2.
C'est pas de la gestion de conf qu'il faut plutôt ? Tu ne modifie jamais les fichiers sur les serveurs, tu leur applique une conf. C'est long à mettre en place et ça demande beaucoup de rigueur par contre.
[^] # Re: ahaha...
Posté par voxdemonix . Évalué à 1.
Les CMS créent/modifient/suppriment des fichiers pour faire leur petite vie. Dans le cas d'un cluster web ça sous-entends propager toute modification le plus vite possible.
Il faut aussi pas mal de recul et énormément de patience pour les cluster (car le moindre changement de paramètres doit être appliqué sur tout les noeuds peu importe l'OS).
[^] # Re: ahaha...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
?!? …pas compris
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: ahaha...
Posté par voxdemonix . Évalué à 2. Dernière modification le 07 février 2019 à 17:25.
Essayes de faire des dossiers partagés entre plusieurs utilisateurs utilisé pour du local, du remote storage et du backup, tu comprendras vite 😉 (et si jamais tu ne sais pas ce qu'est l'umask, tu va galérer et juste pas y arriver 😆 )
Sur linux non seulement tu n'as pas d'interface CLI pour gérer les utilisateurs/permissions (ou alors je ne l'ai pas vu), mais en prime l'accès aux fichiers/dossiers est limité à un seul user:groupe, se qui force à offir des droits openbar à des users en les placant dans des groupes aux accès trop large.
Un exemple typique de ce qui m'a bien fait galérer (surtout l'umask dont il faut avoir du cul pour que quelqu'un te le fasse découvrir) : https://linuxfr.org/wiki/tuto-howto-debian-ubuntu-creer-manuellement-un-cluster-web
[^] # Re: ahaha...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Merci pour ta réponse.
C'est hélas un peu courant pour moi depuis des années ; c'est probablement pour ça que je n'ai pas compris la difficulté… (Oui, j'ai eu à expliquer cet
umaskà un collègue il y a moins de dix jours hihi)J'ai toujours trouvé ça suffisant (dans la majorité des entreprises en environnement mixte où je suis passé, effectivement les tech ont tendance à vouloir gérer les accès comme sous petit mou où paradoxalement il ont au moins un cas où on s'arrache les cheveux pendant plus de 24h pour retrouver et rétablir les droits sur des partages --à cause d'ACL rompus par endroits) ; il faut juste définir proprement les groupes, chose à laquelle personne n'accorde du temps paradoxalement.
Qu'entends-tu par CLI et qu'en attends-tu ?
Pour moi, l'interface de ligne de commande(s) [command line interface] est justement celle par laquelle tu passes des commandes à ton interpréteur de commandes, donc ici les
chmodetchownetc.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: ahaha...
Posté par voxdemonix . Évalué à 1. Dernière modification le 07 février 2019 à 23:15.
Le chmod avec 4 chiffres est pas mal aussi 😁
Question existentielle 😄
Quelque chose qui aiderait à la compréhension lorsqu'on a besoin de quelque chose de plus évoluer que ls -l, peut-être basé sur des graphiques interactifs ou autre chose.
Un outil qui aiderait à appliquer (ou à minimat à faire découvrir/comprendre) des chmod à 3 ou 4 chiffres, les umask, les partages, etc.
D'ailleurs en disant tout ça, je me rappel qu'il manque un truc : umask permet d'appliquer la restriction des permissions, chmod de définir les permissions, chown définit les propriétaires; mais c'est lequel encore qui force les propriétaire sur les nouveau fichier créé/modifié par d'autres utilisateurs ? 🤔
[^] # Re: ahaha...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Pour les nouveaux fichiers, le plus simple est d'utiliser
setfaclavec les "default ACL", mais il faut avoir un système de fichier qui comprend les ACL étendus. Si je me souviens bien, ça ne règle pas le soucis pour les fichiers créés ailleurs puis copiés dans ton dossier.L'interface "graphique" que tu cherches est peut être d'ailleurs simplement la commande
getfacl: elle liste tous les droits actuel et prend en compte umask pour l'affichage.[^] # Re: ahaha...
Posté par Kerro . Évalué à 3. Dernière modification le 08 février 2019 à 18:27.
En entreprise (et asso, etc) on a souvent des besoins tels que :
- le dossier « factures » doit être accessible :
- en lecture/écriture à l'utilisateur « logiciel ERP » (qui est utilisé par un ensemble de scripts)
- en lecture/écriture à l'utilisateur « Sophie de la compta »
- en lecture seule au groupe « comptabilité » (sauf Sophie qui est en lecture/écriture)
- en lecture seule au groupe « direction »
- en lecture seule au groupe « commercial »
- en lecture seule à l'utilisateur « logiciel export »
- interdit à tous les autres
Comment faire avec les droits Unix ?
Avec Windows + NTFS c'est trivial (ce qui n'empêche pas certains de le faire de manière crade).
[^] # Re: ahaha...
Posté par Yves (site web personnel) . Évalué à 2.
J’ai exactement ce type de situation sur mon serveur, et ça passe sans difficulté avec les ACL.
[^] # Re: ahaha...
Posté par Kerro . Évalué à 2.
La question est « comment » ? :-)
Tu parles des ACLs avec setfacl/getfacl ?
[^] # Re: ahaha...
Posté par Yves (site web personnel) . Évalué à 2.
Oui, c’est ça. Dans les cas que je rencontre, ça marche bien. Je combine souvent avec le bit “s” sur le groupe principal.
Il est vrai que dans d’autres cas d’usage (notamment avec des fichiers qui se promènent beaucoup), il peut y avoir le problème que les ACL sont appliquées à la création, pas en cas de déplacement de fichier…
# Je suis resté en 2000
Posté par Pascal Greliche (site web personnel) . Évalué à 7.
Très bon article!
Pour ma part, je suis resté en 2000.
Les technos de 2010 nécessitent une conception particulière et plutôt de repartir de zéro.
Je vois mal comment faire une transition douce des concepts des années précédentes avec les concepts actuels dans le cloud (à moins de ne faire que de la VM basique mais ce ne sont pas les concepts de 2010 (1)).
Le personnel nécessaire et/ou le temps de mise en oeuvre au départ est un peu plus important.
Autre souci, les éditeurs de logiciels métier ne sont pas passés à ces concepts. Tenter de les rentrer au chausse pieds dans du déploiement automatisé, c'est coûteux, sans garantie d'aboutir et risqué car si ça ne fonctionne pas, c'est parce qu'on n'a pas suivi les procédures!
Pour la sécurité, M$crote ne nous aide pas. Quasiment partout où je suis passé, les mises à jour ne sont pas faite. On a peur que ça casse tout (y compris sur des Linux). C'est, de mon point de vue, la grande faute de M$. Rappelez-vous les passages d'une version de Windaube à une autre, toujours pas certain que tout fonctionne (et même on peut être certain qu'il y aura un truc essentiel qui va foirer). Le passage du SP2 de XP a été l'une des pire choses pour la sécurité. Un procès devrait être intenté rien que pour ça et toutes les réticences que ça a engendré au sujet des mises à jour. Les cafouillages des derniers patchs entretiennent ces méfiances.
Notes:
(1)
Chez un Gros opérateur (Historique) Français, la notion de cloud est limitée à de la Virtualisation pour l'infra et des services web mutualisés pour le grand publique… Ils sont restés en 2000 sur les concepts mais essaient d'utiliser les technos actuelles.
[^] # Re: Je suis resté en 2000
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Pour être en plein dans le grand saut, les techno moderne imposent :
- https://12factor.net/fr/ ce qui permet la sécurité et la scalabilité
- d'un coté, il y a le code sans aucun état interne.
- de l'autre la base de données.
Cela permet d'avoir le code dans une git, et la gestion de la base de donnée pour faire les sauvegardes complètent.
Concernant les produits "externes", les techno comme docker permet de les gérer comme avec une VM, et l'intégrer avec le reste.
J'aime beaucoup l'approche micro-service, qui est une découpe vertical et non en couche. Le code devient jetable sans en faire un drame, ce sont les interfaces entre services qui deviennent primordial. La base de donné n'est plus le centre du monde, ce qui donne bien plus de souplesse.
"La première sécurité est la liberté"
[^] # Re: Je suis resté en 2000
Posté par Guillaume Maillard (site web personnel) . Évalué à 4.
Aurais tu des exemples d'applications qui sont, selon ta description, basées sur des "techno modernes"?
Difficile d'en trouver trace hors du helloworld ou de la description d'infra basées sur des milliers de serveurs.
[^] # Re: Je suis resté en 2000
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Tu ne les vois pas, ce sont les architectures des sites web modernes.
Les techno qui sortent du lot :
- go
- docker/Kubernetes ou clever-cloud/heroku (plus simple)
- postgresql pour tout (max ~100 io/s)
- mongoDb quand postgresql ne tient plus
- java qui traine dans les recoin
- rust pour ceux hyper en avance
- auth/jwt/openid pour ceux qui vont devenir chauve en 2ans
- keycloak pour ceux qui vont seulement avoir des cheveux blancs
- swagger pour definir ses api rest, et goswagger pour générer 80% du serveur web frontal.
- python a l'air bien aimé, pour torcher un truc rapidement et qui marche.
- angularJS de google était hyper hype en 2017
- c'est dépassé, maintenant, c'est react.js de Facebook (create-react-app aide bien)
- react, c'est bien, mais si vous avez besoin de redux, le mal de tête va revenir vite
- react se développe dans un env node.js, et nécessite une phase de transpilation (compiler n'est plus hype), ce qui peut nécessité de souffrir avec webpack/babbel/tercer ou éviter les config de 3 pages avec parcel.
Au niveau archi :
- j'aime bien frontend react, backend GO en api rest avec une db postgresql
- Les microservices avec des bus logiciel ont l'air pas mal pour gérer la redondance et se débarrasser de l'adressage (rabit MQ ou Kafka)
- sinon en plus complexe, il y a le CQRS "Command query responsibility segregation", qui sépare lecture et écriture pour gérer les trafics élevés. il y a eu un très bon article dans linuxmag sur le sujet.
- DDD (aide à la modélisation)et Event Sourcing (gestion par changements d'état) sont aussi à la mode.
"La première sécurité est la liberté"
[^] # Re: Je suis resté en 2000
Posté par flan (site web personnel) . Évalué à 5. Dernière modification le 15 janvier 2019 à 22:03.
Mais en pratique, combien de sites ont vraiment besoin de perfs aussi élevées ?
Quand je vois que des sites comme Libération, Disqus, Instagram, Spotify, The Washington Post sont (ou ont été) avec du « bête » Django, je me dis que 99% des sites web devraient pouvoir tenir sans trop de souci avec des technos très classiques.
À nouveau, je ne suis pas développeur web, mais quand je compare le coût annuel du développeur avec celui d'un serveur, j'imagine que la rapidité de développement doit largement primer la performance (sauf quand on s'appelle Google ou Facebook ou qu'on fait partie du 1% ci-dessus, bien sûr)
Ce n'est pas la première fois que je me fais cette réflexion, vu que la question des perfs revient régulièrement (par exemple avec les framework C++).
[^] # Re: Je suis resté en 2000
Posté par barmic . Évalué à 5.
Django c'est un fronted web, ça n'est pas une architecture en soi. Spotify par exemple doit gérer les musiques et les profils utilisateurs. Il faut stocker et mettre à disposition les musiques aux utilisateurs, ça ne se fait pas en stockant tout dans un sgbdr. Essayez de proposer les musiques qui plaisent aux bonnes personnes ça demande à pouvoir faire du calcul en arrière plan pour mettre à jour les profils et vérifier ce qui correspond le mieux. Enfin si django est à l'aise avec des interfaces web avec templates coté serveurs, il va falloir faire des choses en plus pour les mobiles et par exemple les chromecast ou les trucs comme Alexa. Il faut des api pour ça, il faut les authentifier ce qui se fait souvent autrement que dans un site web (sans cookies par exemple).
Il faut bien distinguer architecture et technologie. On peut garder une techno par inertie par exemple (on a commencé avec et on a pas encore jugé bon de la remplacer ou on ne s'en sert que pour une partie) et au contraire on peut utiliser des technologies hypes pour faire des trucs très à l'ancienne.
Un blog de référence dans le domaine http://highscalability.com/
Mais ces architectures peuvent avoir de l'intérêt même sans grand besoin de montée en charge. Elles peuvent donner une meilleure résilience par exemple (pense aux sites de billetterie par exemple qui ont des pics de charges très ponctuels) ou permettre certaines souplesse (c'est plus simple de supprimer un micro service pour le remplacer que du code qui aura tendance à avoir un plus fort couplage avec le reste de l'application).
[^] # Re: Je suis resté en 2000
Posté par barmic . Évalué à 2.
D'ailleurs spotify utilise des microservice https://labs.spotify.com/2013/03/15/backend-infrastructure-at-spotify/
Tu peux trouver l'architecture de disqus sur le blog How Disqus Went Realtime with 165K Messages Per Second and Less than .2 Seconds Latency
J'ai pas trouvé pour instagram et pour libé, c'est différent c'est largement plus simple pour eux. Ils ont beaucoup moins de publications, monter en charge sur de la lecture uniquement est relativement simple. Je ne suis pas sûr qu'ils aient besoin de publications temps réel. Si un article apparaît une minute plus tard, je ne suis pas sûr que ce soit grave, donc tu peux t'autoriser pleins de choses pour consommer très peu.
[^] # Re: Je suis resté en 2000
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il n'y a pas que la performance. Je dirais même que c'est souvent un peu secondaire.
Il y a la facilité de mise à jour, qui impose l'intégration continue(CI), blue/green deployment, Feature toggle (ou feature switch), etc… pour mettre à jour sans arrêt du service, avec une monté en charge progressive (pour tester avec ces utilisateurs…).
Là, ou cela commence à être compliqué, c'est faire cela avec le schéma de la base de données….
"La première sécurité est la liberté"
[^] # Re: Je suis resté en 2000
Posté par Guillaume Maillard (site web personnel) . Évalué à 4.
Une sorte d'apologie de la "hype" en fin de compte?
J'ai comme l'impression que certains se font plaisir au grès des tendances, la "mode",
des surcouches, des abstractions tout en discréditant toutes ces vielles technologies de plus d'un an.
Je comprend qu'il y ait un haut besoin de redondance quand on commence à hyper complexifier les choses, mais plutôt que de simplifier j'ai l'impression que tout converge vers le "on va répartir la charge et tout redonder" au lien de fiabiliser et de simplifier.
Bref, on en a pas fini de voir des pages web de plus de 1Mo et des "frontends" qui n'encaisse pas plus de 100 req/s….
[^] # Re: Je suis resté en 2000
Posté par Nicolas Boulay (site web personnel) . Évalué à 2. Dernière modification le 17 janvier 2019 à 17:36.
Non justement, les problèmes sont remontés, les vieilles techno essayent de les contourner, mais c'est lourd. Et une nouvelle techno est lancé pour utiliser les avancées conceptuelles. React reprend le shadow DOM pour avoir la vitesse que angular n'a pas.
Je prédis que la prochaine mode sera ELM qui est un langage fonctionnel qui vérifie l'usage correct à l'inverse des lib javascript qu'il remplace. Cela permet justement de faire plus simple que react+redux. J'en ai pas parlé car cela débute, et que très peu de lib existe.
En react pour avoir des pages de 1Mo, il faut avoir un paquet d'image dedans. Le hello world doit faire dans les ~50ko maximum.
Et si tu veux un frontend qui encaisse, tu utilises les services de cache mondiale comme netlify ou autre, et tu n'utilises pas ton serveur.
"La première sécurité est la liberté"
[^] # Re: Je suis resté en 2000
Posté par barmic . Évalué à 3.
Hum… Ça coûte le blog dont je parle un peu plus haut. Par exemple pour disqus, il est décrit ce qu'ils ont essayé et ce qui a marché et pourquoi.
Tu parle de surcouche, mais bon quand on parle de Django, c'est qu'on a pas peur des abstractions, non ? L'exemple de disqus est intéressant ils ont retiré des briques pour utiliser au maximum d'autres composants notamment ils ont viré redis (je ne sais pas si tu le considère comme hype) pour le remplacer par un module de nginx (c'est hype?). Ils ont quelque chose qui est à la fois plutôt sophistiqué (leur reverse proxy fait un peu tout), mais simple par d'autres égards (il y a beaucoup moins de couches). C'est très pragmatique comme choix. Ils ont un besoin, des contraintes ils expliquent leur solution.
Le fait que ça sorte de ce que l'on voit d'habituel fais vraiment peur ?
[^] # Re: Je suis resté en 2000
Posté par InfoLibre . Évalué à 1.
react, c'est dépassé. Vue.js est plus hype.
[^] # Re: Je suis resté en 2000
Posté par Anonyme . Évalué à 2.
Le truc qui m’embête dans la « spec » 12 factors c’est les logs.
Pour moi les logs devraient être envoyés vers syslog, avec une « severity » bien définie pour chaque message, pas vers
stdout/stderr.[^] # Re: Je suis resté en 2000
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
oula non.
L'avantage énorme est que tu peux récupérer et faire ce que tu veux des logs en question, y compris les envoyé dans syslog.
L’intérêt est de virer la gestion des logs de l'application, ainsi quand tu débugs, tu n'as pas besoin d'avoir le système de log opérationnel. Les 2 peuvent évoluer indépendamment.
"La première sécurité est la liberté"
[^] # Re: Je suis resté en 2000
Posté par Anonyme . Évalué à 2. Dernière modification le 18 janvier 2019 à 15:38.
Ça prend 2 minutes et ça permet à l’admin système de pas devoir se faire chier avec le format de log spécifique à ton application pour récupérer les informations de base (gravité, date/heure, etc).
[^] # Re: Je suis resté en 2000
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Disons que si tu as un problème dans ton application sur le réseau tu va perdre tes logs.
concernant le format des log, tu as 2 écoles :
- le format
severity time key1=value1 key2=value2…
avec quelques clefs vaguement standardisé
- le format JSON
Il y a des boite qui fournissent clef en main des outils de recherche dans les logs qui utilise ce json pour avoir de la vrai sémantique.
Le problème est d'avoir assez de log, mais pas trop pour tout ralentir et couter cher en disque.
"La première sécurité est la liberté"
[^] # Re: Je suis resté en 2000
Posté par barmic . Évalué à 2.
Bof ça fait longtemps que j'ai pas vu de sysadmin. La plupart du temps je suis l'administrateur. Éventuellement on me demande les rendre accessibles via une interface web.
# À la maison !
Posté par Marius . Évalué à 2.
Très bel article.
Novice en «réseau», j'utilise à la maison Yunohost 3.3, Debian 9 , XFCE sur un Toshiba Satellite de 2009.
Tout, pour l'instant, a fonctionné facilement, mais bien sûr je ne maitrise rien «sous le capot» !
Freebox, domaine Yunohost, serveur de mail + Roundcube, Hextris, Tiny Tiny RSS…
# Après YunoHost, systemd et Ansible
Posté par Yves (site web personnel) . Évalué à 10.
Tout d’abord, je « plussoie » pour YunoHost, que je n’ai jamais utilisé mais que je suis depuis son début. Pour un débutant (ou pas) c’est parfait.
Pour aller plus loin, en auto-hébergement (jamais de la vie pour un Chaton), ArchLinux est une plateforme à la souplesse formidable, du fait de la fraicheur et de la diversité des logiciels, et des rapides mises à jour (de sécurité ou autres).
Et basé sur cela, je souhaite surtout souligner l’intérêt d’une solution automatisée comme Ansible, car comme le dit l’article, ça permet de remonter une infra en un rien de temps ; exemple :
https://yalis.fr/git/yves/home-server
Enfin, une mention spéciale pour systemd, qui a grandement facilité (à mon avis) l’administration, la sécurisation et la supervision du serveur (et même, dans mon cas, la conteneurisation) !
# déGAFAMisation de la vie numérique ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4. Dernière modification le 11 janvier 2019 à 16:03.
J’ai tout relu avec le doigt, voilà ce que j’ai compris :
1. L’initiative des CHATONS propose des services alternatifs à ceux proposés par les GAFAMs pour le grand public (mail, partage de fichiers, messagerie instantanée, etc.)
2. Ils proposent maintenant à ceux qui le souhaitent de participer à l’initiative en « hébergeant » chez eux certaines ressources nécessaires
3. La dépêche se concentre sur les aspects techniques avec une présentation humoristique, mais fait l’impasse sur « tout le reste » (qui est peut être traité dans une autre dépêche ?)
PS : J’ai encore 3 petits chats à caser, me demander sur La Tribune
# Bon, ben c'est pour les pros, quoi
Posté par Zorro (site web personnel) . Évalué à 10.
LOL, la dépêche censée démystifier, mais qui te prouve qu'en fait, c'est pour les pro, quoi. Des pros pas-GAFAM, certes, mais des pros quand même.
[^] # Re: Bon, ben c'est pour les pros, quoi
Posté par Yves (site web personnel) . Évalué à 4.
C’est un peu mon sentiment aussi, mais c’est tout de même intéressant.
À mon avis, devenir Chaton s’inscrit dans une démarche progressive, et l’auto-hébergement arrive avant dans cette démarche ; il permet de commencer à se familiariser avec les logiciels, leur impact sur le système, leurs problèmes, etc.
Je trouve la conclusion bien formulée : si on a tout compris jusque là, on est prêt ; ce à quoi j’ajouterai juste : après avoir eu un peu d’expérience en vrai avec de l’auto-hébergement ;-)
[^] # Re: Bon, ben c'est pour les pros, quoi
Posté par voxdemonix . Évalué à 3. Dernière modification le 11 janvier 2019 à 17:56.
Boaf pas du même avis.
Savoir que le monitoring existe ne t'aide pas forcément à trouver une solution moderne pour le mettre en place. (ça fait plus d'un an que je cherche la perle rare, si tu l'as, 22 😋)
Le chapitre traitant de redondance n'évoque pas le split brain ni l'arbitre. (des sujets simple mais compliqués) Quand le néophyte va les découvrir, j'espère que se sera moins frustrant et avec moins de pertes de vieilles photos de famille que mon propre vécu.
D'où que le rédacteur vous invite tous à partager quels sont vos logiciels favoris en commentaire :)
[^] # Re: Bon, ben c'est pour les pros, quoi
Posté par CrEv (site web personnel) . Évalué à 4. Dernière modification le 11 janvier 2019 à 21:02.
Pourtant des solutions de monitoring c'est pas forcément ce qui manque. Genre prometheus-alertmanager-grafana est plutôt sympa, mais c'est sans connaitre le besoin.
[^] # Re: Bon, ben c'est pour les pros, quoi
Posté par Pol' uX (site web personnel) . Évalué à 3.
Perso j'ai adopté icinga2. Et je pense que je ne suis pas près d'en changer. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Bon, ben c'est pour les pros, quoi
Posté par Pierre Jarillon (site web personnel) . Évalué à 6.
Je veux bien le croire. Ce serait plus instructif si on savait pourquoi !
[^] # Re: Bon, ben c'est pour les pros, quoi
Posté par Pol' uX (site web personnel) . Évalué à 8.
Beh ça mériterais un journal de grande taille, mais « rapidement » :
Comparé à Nagios, on peut avoir à peu de frais une description très déclarative de l'host (par ex: volumes
disques, vhosts http, processes, zones dns) et utiliser cette description pour appliquer automagiquement les services associés. Le tout avec une grande souplesse pour les évolutions futures car ça repose sur des prédicats riches (contrairement à Nagios qui se limite à associer les services à des groupes d'hotes). Donc on a plus de description, moins de répétitions. Et le code qui interprète ces descriptions pour définir des services est relativement trivial.
En plus, on est sur du monitoring distribué. On peut déployer des agents si on veut (mais sans obligation) et on se débarrasse de NRPE. Avec des agents on a une large configurabilité possible pour choisir le lieu d'exécution de chaque test. Et le coût de déploiement d'un cluster icinga est franchement faible sur l'échelle du brainfuck (comparé à Nagios+NRPE…).
Comparé à Zabbix, on dispose des mêmes qualités qu'un monitoring distribué. Mais on n'a pas affaire à une tétrachiée de configurations en base de donnée via une interface web à destinée à vous faire attraper une tendinite. Tout est sur la/les machine(s) maître(s) dans des fichiers textes lisibles avec vim. Personnellement, rien que le fait de ne pas pouvoir mettre sa conf dans un git me semble être un énorme boulet au détriment de Zabbix. Et c'est bien parce qu'il a des bonnes qualité par ailleurs que des gens l'utilisent faute de mieux.
Je n'ai jamais déployé de Prometeus. Mais ce que j'en ai lu ne donne pas méga envie : il ne semble y avoir aucune possibilité pour factoriser la configuration. Donc soit tu fais du 100% automatisé et ce n'est pas trop un soucis ; soit t'es foutu : 1 check => 1 conf et 1000 checks => 1000 confs… Ça a l'air cool, ça a l'air hype, mais la doc ne m'a pas encore convaincu. Et en plus c'est centralisé. Donc si tu as tout en cœur de réseau, ça peut passer ; sinon ça casse vite.
Le principal point noir que je vois de icinga2 est le suivi graphique des données qui n'est pas terrible. Mais l'équipe a fait le choix d'orienter vers des grapheurs dédiés, notamment grafana. C'est certainement un bon choix mais à titre perso je trouve que le coût d'entrée dans grafana est bien trop élevé comparé par ex au bon vieux nagios-pnp ou à Zabbix (assez remarquable sur cet aspect je trouve).
PS: puisque on parle de chapril, j'ai précisément utilisé le cluster de chapril pour tester en vrai Icinga2. :) Pour se faire une idée de à quoi la conf ressemble :
https://admin.chapril.org/doku.php?id=admin:procedures:ajout-d-une-machine#ajout_de_l_objet_a_la_configuration
Adhérer à l'April, ça vous tente ?
[^] # Re: Bon, ben c'est pour les pros, quoi
Posté par Wawet76 . Évalué à 3.
Pour le monitoring je suis parti sur Zabbix. Il m'a semblé beaucoup plus simple à mettre en place et avec moins de ressources nécessaires.
Mais ce n'est ptet qu'une impression, je n'ai jamais essayé Nagios ou un de ses forks.
[^] # Re: Bon, ben c'est pour les pros, quoi
Posté par voxdemonix . Évalué à 2. Dernière modification le 11 janvier 2019 à 22:33.
Surveiller les services et OS et si possible agir sur le système de mes serveurs ubuntu/debian autant en X64 qu'ARM.
Grafana est joli mais assez complexe à installer (c'est dommage qu'ils n'ont pas conçu un client qui facilite l'installation, ou un script d'install pour taper un Zabbix alléger côté client et une pré-config de grafana).
# Il faut savoir ce que parler veux dire
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
Le métier d'hébergeur est avant tout un métier de gestion des risques. Savoir qu'avec telle infra, on peut garantir tel périmètre avec tel taux de disponibilité. 99.9 de dispo d'un middlware, ce n'est pas la même chose que 99.9 de dispo réseau. Une GTI de 4h n'est pas la même si elle exclue l'escalade vers les constructeur … etc … etc …
Je pense enfin que, même si ça ne fait pas plaisir aux marchands de baies de stockage, un PRA n'est pas un élément de la haute-dispo. Un PRA est une stratégie d'entreprise, un parchemin qui explique ce qu'il faut faire en cas de drame pour rétablir les quelques assets sans lesquels on ne peut pas fonctionner (N de téléphone, accès aux zones DNS, accès au coffre pour récupérer des sauvegardes, CB pour souscrire un nouvel hébergement …).
Ce que sait faire un hébergeur, c'est de la reprise sur incident.
# Sur la supervision.
Posté par Kwiknclean . Évalué à 2. Dernière modification le 14 février 2019 à 23:35.
Sur l'aspect supervision c'est une vraie problématique lorsque vous commencez à avoir des milliers voir des dizaines de milliers de services.
Souvent la solution historique Nagios-Like, montre vite ses limites en terme de scalabilité justement, c'est courant de voir les collecteurs, bien que sur des machines physiques, avec des gros Xeon en permanence à 100% voir complètement sur les rotules avec des checks qui prennent plusieurs heures de retard. Et globalement tu t'aperçois souvent que l'utilisateur voit le problème avant ton outil de supervision …
De plus pour migrer la plateforme, ce sont des projets qui traînent sur des mois.
Cela fait le travail pour monitorer une infra par exemple ou l'utilisateur ne voit pas ne sent pas la coupure, mais globalement, dés que ça impact l'utilisateur (service ko, performance en retrait), c'est souvent ce dernier qui t'alerte en premier … pas génial comme pro activité.
J'ai ouïe dire que certaines méthode modernes s'orientait plus sur une analyse de log de tout le matos, avec des stack comme ELK par exemple (mais dans le genre usine à gaz on est bien).
J'aimerais l'avis d'expert ou de personne ayant été confronté à ce genre de questionnement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.