Mais ceux que tu voulais préserver en utilisant l'option -a de la commande cp, pardi !

Je veux préserver les caractéristiques intrinsèques qui affectent l'interprétation du fichier. Par exemple, la permission EXECUTE rend un fichier exécutable (si il a le bon format), donc ça affecte son comportement. Les autres permissions, les propriétaires, etc. détermine qui peut faire quelle opération, donc c'est important de les préserver.

L'attribut atime n'est utile que si quelqu'un a la curieuse idée de l'utiliser, ce qui est très rarement le cas. C'est une méta-information sans aucun intérêt dans 97 % des cas (mais qui peut, parfois, être utile).

De toute façon, tu ne peux pas créer une copie identique d'une arborescence ou même d'un seul fichier, tel que TOUS les attributs Unix soient identiques!

Désolé pour le déterrage.

Tu appelles ça un déterrage, après même pas 6 mois?

Non mais tu plaisantes!

Je ne comprend pas bien le concept exposé.

Donc je ne suis pas seul!

tu m'a plutôt l'air d'avoir compris le concept ... tu vois juste les inconvénients sans voir les avantages.
 (...)
On parle de micro-services la, avec des nuées d'instances.
 (...)
Apres c'est l'éternel débat d’où on met la 'frontière' d'intervention. Certains sysadmins ne supportent pas de devoir faire tourner des 'boites noires' sans pouvoir aller jeter un oeil dedans. Certains devs ne supportent pas que les sysadmins bidouillent dans leur apps. Il est vrai que quelque part certains métiers vont se simplifier...voir disparaitre.
 (...)
J'ai pas bien compris "pas de séparation des interfaces réseaux admin/service/NAS".
 (...)

Je suis probablement plus dans les inconvénients du fait de ce que je vois au boulot.
Je m'ocuppe d'OS et de stockage sur des environnements virtualisés pour des appli de compta à base d'ERP.
Il m'arrive d'avoir à aller sur les machines pour voir comment se comporte l'appli dessus ou l'OS en terme de performance principalement notamment pour ce qu'ils demandent aux couche dessou (sur des VM à OS AIX et Linux).
Par ailleurs, nous avons un ordonnanceur externe pour les traitements applicatifs et une partie des traitements techniques (par exemple j'arrête les tomcat d'une appli puis je lance le recalcul des stats de la DB associée puis démarrage des tomcat dans le bon ordre le tout réparti sur une 20aines de serveurs, ok, l'exemple est un peu bateau).

Je me suis donc principalement intéressé à l'impact sur mon quotidien sachant que quasi tout les avantages / inconvénients pour un DEV ne me concernent pas (et pas de souci là dessus, chacun son métier).

Vu que je vais recevoir un "tout en un", il va falloir que les spec de DEV incluent d'autres fonctions que juste le mini-service afin d’intégrer celui-ci dans un environnement ou le monitoring de l'appli/"OS".
De plus, un partie des problématiques de perf repérée ce jour par les sysadmin devra être vue par l'éditeur et pour l'instant, je ne leur fait pas confiance pour dépenser plus de budget pour faire un bon produit en terme d'utilisation technique.
Avec le modèle proposé, je n'aurait plus aucun argument pour contrer un support.

C'est un point de vue sur la généralisation de ce mode de déploiement, l'idée technique est bien sur elle est correctement réalisée, mais j'ai des doutes sur la mise en œuvre.

Pour la séparation des interfaces réseaux admin/service/NAS.
Chez nous, les VM on 3 interfaces virtuelles :

• une qui va vers le NAS sans traverser de firewall et qui sert aussi pour les backup IP en direct sur l'équipement de backup.
• une qui sert à venir dessus en tant qu'administrateur (par exemeple en SSH)
• une pour le service applicatif

Ca permet de bien s'y retrouver, gérer plus facilement les firewall (notamment d'avoir des FW périphériques différents) et les routes réseau et le diagnostique

Sur les appliance que je vois, il n'y a en général qu'une interface virtuelle avec une seule IP qui ne supporte qu'une donc passerelle et pas toujours la possibilité de rajouter des routes ce qui complique un peu le management.
Encore une fois, ca n'est pas une limite inhérente à la techno choisie mais des choix de mise en oeuvre au plus simple / moins couteux constatés.

Pour la séparation des interfaces réseaux admin/service/NAS.
Chez nous, les VM on 3 interfaces virtuelles :

• une qui va vers le NAS sans traverser de firewall et qui sert aussi pour les backup IP en direct sur l'équipement de backup.
• une qui sert à venir dessus en tant qu'administrateur (par exemeple en SSH)
• une pour le service applicatif

Ca permet de bien s'y retrouver, gérer plus facilement les firewall (notamment d'avoir des FW périphériques différents) et les routes réseau et le diagnostique

Ayant pratiqué cette segmentation je plussoie sur les avantages de configuration des règles de firewall quand on a plusieurs interfaces réseaux distinctes en terme d'utilisation. N'avoir qu'une seule adresse IP/Vlan est vraiment pénible surtout quand un auditeur sécurité demande à avoir un aperçu sur les flux autorisés.

Vous avez pensé à la maintenance ?
Si chaque "vm" embarque ses piles logicielles de base qu'on sort donc d'un OS commun, imaginez le chemin de croix pour patcher une faille de sécurité commune, avec les centaines d'éditeurs qui vont devoir produire leur patch !
C'est déjà pénible avec X OS différents, mais alors si on passe à Y applis avec Y=100*X...

on est en 2016... il ne s'agit pas d'aller 'a la main' accéder a chaque 'vm ou 'image' pour patcher, mettre a jour ou administrer.

En production, tout ce passe au sein d'un système qui s'auto-heal, s'auto-corrige et ou tout ses aspects de maintenance sont pris en compte des le départ via l'utilisation d'un orchestrateur.

Au cours des derniers années il y a eu de gros travaux et avancées sur ces outils d'automation, orchestration et de gestion de clusters ou d'essaims (swarm).

cf Docker Swarm, Apache Mesos, Kubernetes, etc

on est en 2016... il ne s'agit pas d'aller 'a la main' accéder a chaque 'vm ou 'image' pour patcher, mettre a jour ou administrer.

Tu n'as pas bien compris le sens de ma remarque : tu confonds nombre de VM et nombre d'éditeurs.
Si chaque éditeur d'applis embarque sa propre libC, son propre bash, etc, bref ses propres fonctions de bases autrefois communes aux OS classiques, tu vas multiplier les sources de fournisseurs logiciels, et tu vas pleurer pour maintenir ça, avec ou sans orchestration.
Et ce, que tu ais 200 ou 10000 VM...