Bonjour
j'apprécie énormément la méthode de partitionnement de debian qui sépare les partitions /home, /usr, /var et /tmp.
Il se trouve que je travaille avec des gens qui vont plus loin dans cette démarche de segmentation des volumes logiques.
Sur les serveurs il y a de nombreux LV en fonction de l'application concernée.
On observe:
/apache
/postfix
/php
/samba
/mysql
/perl
…
Cette méthode possède l'avantage indéniable de ne pas bloquer le serveur en consommant tout l'espace disque disponible (les daemon apache et postfix ne pourront remplir que leur espace)
De plus on trouve facilement les données concernant tel ou tel programme. (chaque /app contient à la fois les fichiers de conf, les logs, les binaires…)
Cela impacte les paquets d'installation rpm qu'il faut recompiler et créer en fonction de ces volumes logiques.
cela fait naître des problématiques au niveau de certaine appli trés ramifiée (je pense à perl) dont l'isolation dans /perl n'est pas évidente.
Je trouve cette organisation extrêmement contrainte et je ne peux m'empêcher de lui opposer celle de debian que je trouve plus pérenne et maintenable.
Seulement on me dit que c'est très stable et cela s'inscrit dans une volonté de mutualiser les applis d'autre serveur (on peut aisément imaginer la création de /apache2 /samba2 pour l'hébergement d'un serveur 2 en centralisant ses données)
Dans cette optique je ne peut m'empêcher de penser à des méthodologies touchant au Cloud?
Qu'en pensez vous ? pouvez vous m'apporter des arguments, lien vers de la documentation, sur des méthodes alternatives à une solution que je qualifierai un peu d 'Usine à gaz'?
Je ne sais pas trop comment argumenter, je ne connais pas d'application 'cloud' dans le monde du Libre, par contre je suis persuadé qu'il y a moyen d'obtenir une meilleur organisation des data et de l'applicatif sans passer par un découpage laborieux.
Merci
# Docker ?
Posté par Atem18 (site web personnel) . Évalué à 2.
http://linuxfr.org/news/la-folie-docker
[^] # Re: Docker ?
Posté par cichlid . Évalué à 0.
merci pour l'info effectivement je ne connaissais pas.
j'ai oublié de préciser que l'os hébergeur des conteneurs est un OS unix AIX 7
je ne suis pas sûr que docker est installable sous unix?
non?
envoyé depuis mon clavier bépo
[^] # Re: Docker ?
Posté par Atem18 (site web personnel) . Évalué à 1.
Non, en effet, il n'est disponible que sous Windows, OS X et Linux. :/
# Mon ancien boulot
Posté par Pouetpouet . Évalué à 1.
A mon précédent poste la règle était d'avoir un lv par appli qui tourne sur une bécane. Chaque appli ayant son propre user dont le home était le volume.
C'était assez contraignant, d'autant plus que ça venait avec d'autres règles, notamment que tout ce qui concernait l'appli (binaires, logs, etc) devaient être sur cette partoche, mais au final sur plusieurs milliers de machines aux OS différents c'était pas du tout le bazar, au contraire.
[^] # Re: Mon ancien boulot
Posté par Tonton Benoit . Évalué à 2.
Java ?
Non parce-que sinon, c'est un truc à s’arracher les cheveux avec les dépendances et l'ABI ça.
[^] # Re: Mon ancien boulot
Posté par Pouetpouet . Évalué à 1. Dernière modification le 12 janvier 2015 à 22:43.
Un framework maison en shell (OS différents mais surtout de l'Unix, j'ai pas regardé ce qu'ils faisaient côté Windows)
# /srv
Posté par Tonton Benoit . Évalué à 3.
On parle de beaucoup de choses différentes là.
Pour la configuration, elle reste généralement là où la distribution l'a mise et je gère son déploiement et sa mise à jour via puppet/etcd/scripts…
Pour les applications elles-même, j'utilise de préférence le gestionnaire de packages de la distribution (c'est quand-même mieux niveau dépendances et compatibilité binaire). Après faut voir de quoi on parle par "application", si on parle d'une application web, genre horde, elle peut aller dans /srv/horde qui sera partagé entre le serveur web et le daemon php-fpm. Dans ce dernier cas "l'application" c'est plutôt le serveur web et les fichiers php et autres les représentent les données.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.