L'exemple de la réinstallation en 10min par MTux est un peu fantaisiste (en vrai on a des infras de dev, inté, test avant de passer en prod) mais il est vrai que dans toutes les boites où j'ai bossé on passe son temps à migrer des trucs d'un serveur/stockage/solution de virtualisation, souvent pour des raisons économiques.
Si tes procédures de disaster recovery sont au points, tu peux normalement migrer relativement facilement et rapidement toute appli, et souvent de façon relativement rapide et indolore. Une appli est généralement divisée en un certain nombre de composants frontend, backends, DB, webservices, annuaires, message queue...Tous ces composants peuvent souvent être migrés séparément, sont individuellement pas sorcier à comprendre/gérer et sont souvent multiplateformes. Ces dernières années j'ai fais beaucoup de migrations de Solaris vers Redhat qui sont au moins aussi différents que debian l'est de freebsd. Je n'ai pas l'impression d'avoir été devant des montagnes insurmontables. À vrai dire le pire c'était des alfresco. Pas parce que l'appli est compliquée mais uniquement parce que les filesystems hébergeaient des multitudes de petits fichier et que d'un point de vue perf c'est ce qu'il y'a de plus long à copier. Les applis web, c'est hyper simple. Ton nginx/Apache, ton php, python, nodejs où que sais-je ne fonctionnent pas différemment qu'ils soient sous Linux, Solaris, Aix ou FreeBSD (voire même windows dans la plupart des cas où la sensibilité à la casse n'est pas primordiale).
Tu parles de bases de données mais en général c'est justement ce qu'il y'a de plus facile à migrer. Tu fous une réplication en place entre la nouvelle et l'ancienne machine (même sous des OS différents), tu laisses la synchro se faire, et le jour où tu bascules c'est l'affaire de quelques minutes. Je l'ai fais encore cette semaine avec Oracle Dataguard. Et au pire même avec des bases non répliquées ça se résume généraleemnt à un dump d'un côté suivi d'un restore de l'autre et à un changement de records DNS. Je n'ai rencontré aucun moteur de base de donnée qui nécessitait un seul OS et dans une seule version pour tourner.
Le stockage sur les 3 boites où j'ai bossé ces 15 dernières années j'ai fais des migrations à peu près tous les 2-3 ans. Je ne vois pas trop en quoi c'est compliqué à vrai dire, d'autant plus quand tu utilises de la virtualisation. Faux être méticuleux pour que ça se passe bien oui, mais je ne connais aucune boite qui a freiné des 4 fers pour éviter des migrations devant l'ampleur de la tâche. Au contraire.
Les messageries c'est souvent dur d'en changer si on est dans le monde proprio (exchange, Lotus Domino, etc) mais pour migrer des serveurs je n'ai pas vu de difficultés particulières.
Bref oui dans le monde pro, ça migre un peu tout le temps. Les seuls qui restent figés dans des versions, c'est les cas de logiciels dont le développement a été fais une fois que ce soit par un employé ou un presta sans qu'un cycle de vie ou une maintenance n'ait été définie. Mais bon dans la plupart ça n'empêche pas de migrer. De toute façon le jour où c'est plus supporté tu t'en fous d'être en conformité avec les specs originale du fournisseur, ce qui compte c'est que ça tourne donc tu vas pas garder un vieux serveur qui est déjà aux soins paliatifs, si tu dois le changer tu le fais et tu fais en sorte que l'appli tourne quand même en copiant les vieilles librairies où en la faisant tourner dans un chroot, zone, container, jail ou vm. De toute façon Murphy fait toujours en sorte que la vieille bécane va cramer et que même si tu trainais des pieds pour migrer t'es quand même obligé un jour à te sortir les doigts du cul et la migrer.
[^] # Re: C'est pas vendredi
Posté par Psychofox (Mastodon) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 5.
L'exemple de la réinstallation en 10min par MTux est un peu fantaisiste (en vrai on a des infras de dev, inté, test avant de passer en prod) mais il est vrai que dans toutes les boites où j'ai bossé on passe son temps à migrer des trucs d'un serveur/stockage/solution de virtualisation, souvent pour des raisons économiques.
Si tes procédures de disaster recovery sont au points, tu peux normalement migrer relativement facilement et rapidement toute appli, et souvent de façon relativement rapide et indolore. Une appli est généralement divisée en un certain nombre de composants frontend, backends, DB, webservices, annuaires, message queue...Tous ces composants peuvent souvent être migrés séparément, sont individuellement pas sorcier à comprendre/gérer et sont souvent multiplateformes. Ces dernières années j'ai fais beaucoup de migrations de Solaris vers Redhat qui sont au moins aussi différents que debian l'est de freebsd. Je n'ai pas l'impression d'avoir été devant des montagnes insurmontables. À vrai dire le pire c'était des alfresco. Pas parce que l'appli est compliquée mais uniquement parce que les filesystems hébergeaient des multitudes de petits fichier et que d'un point de vue perf c'est ce qu'il y'a de plus long à copier. Les applis web, c'est hyper simple. Ton nginx/Apache, ton php, python, nodejs où que sais-je ne fonctionnent pas différemment qu'ils soient sous Linux, Solaris, Aix ou FreeBSD (voire même windows dans la plupart des cas où la sensibilité à la casse n'est pas primordiale).
Tu parles de bases de données mais en général c'est justement ce qu'il y'a de plus facile à migrer. Tu fous une réplication en place entre la nouvelle et l'ancienne machine (même sous des OS différents), tu laisses la synchro se faire, et le jour où tu bascules c'est l'affaire de quelques minutes. Je l'ai fais encore cette semaine avec Oracle Dataguard. Et au pire même avec des bases non répliquées ça se résume généraleemnt à un dump d'un côté suivi d'un restore de l'autre et à un changement de records DNS. Je n'ai rencontré aucun moteur de base de donnée qui nécessitait un seul OS et dans une seule version pour tourner.
Le stockage sur les 3 boites où j'ai bossé ces 15 dernières années j'ai fais des migrations à peu près tous les 2-3 ans. Je ne vois pas trop en quoi c'est compliqué à vrai dire, d'autant plus quand tu utilises de la virtualisation. Faux être méticuleux pour que ça se passe bien oui, mais je ne connais aucune boite qui a freiné des 4 fers pour éviter des migrations devant l'ampleur de la tâche. Au contraire.
Les messageries c'est souvent dur d'en changer si on est dans le monde proprio (exchange, Lotus Domino, etc) mais pour migrer des serveurs je n'ai pas vu de difficultés particulières.
Bref oui dans le monde pro, ça migre un peu tout le temps. Les seuls qui restent figés dans des versions, c'est les cas de logiciels dont le développement a été fais une fois que ce soit par un employé ou un presta sans qu'un cycle de vie ou une maintenance n'ait été définie. Mais bon dans la plupart ça n'empêche pas de migrer. De toute façon le jour où c'est plus supporté tu t'en fous d'être en conformité avec les specs originale du fournisseur, ce qui compte c'est que ça tourne donc tu vas pas garder un vieux serveur qui est déjà aux soins paliatifs, si tu dois le changer tu le fais et tu fais en sorte que l'appli tourne quand même en copiant les vieilles librairies où en la faisant tourner dans un chroot, zone, container, jail ou vm. De toute façon Murphy fait toujours en sorte que la vieille bécane va cramer et que même si tu trainais des pieds pour migrer t'es quand même obligé un jour à te sortir les doigts du cul et la migrer.