Datacenter Exit : comment Veolia migre ses applications sur le Cloud AWS

Temps de lecture : 4 minutes

En Novembre dernier lors du AWS Transformation Day, Jean-Christophe Laissy, DSI Groupe, présentait la stratégie de “datacenter exit” entreprise par Veolia : ne plus avoir de datacenter en France d’ici fin 2018, et dans le monde d’ici 2020. Pour concrétiser cette vision, Veolia s’appuie sur le Cloud AWS : les équipes sont accompagnées dans la stratégie de datacenter exit, et les applications sont migrées massivement dans le Cloud AWS. Une partie de ces migrations a été réalisée par les équipes de D2SI.

Plus de 70 applications ont ainsi déjà été migrées dans une stratégie de replatforming. Ces applications métiers traitent tous types de données (ERP, applications d’infrastructure, serveurs web et bases de données, etc.). La migration est réalisée application après application, grâce à un pipeline d’automatisation qui a été perfectionné au fur et à mesure. Terraform a ainsi remplacé Cloudformation pour la construction du code, et la partie Windows est entièrement automatisée avec Chocolatey (pour l’installation des applications et le paramétrage des AMI), Packer et Nugget.

Périmètre de la migration

A ce jour la migration représente environ 300 instances sur AWS, et a fait appel aux services AWS suivants : EC2, RDS, EFS, Route 53, Direct Connect, Lambda, S3 et Appstream.

Jenkins est utilisé comme orchestrateur, avec le code chargé dynamiquement de GitHub.La migration a permis à l’équipe D2SI d’automatiser un certain nombre de tâches, comme le rafraîchissement des bases RDS, le patch management sur Windows et Linux avec EC2 System Manager, ou le démarrage et l’arrêt des ressources (EC2, RDS, Appstream) dans l’optique de mieux gérer les coûts sur AWS. Cette migration massive est encore “work in progress”, mais l’ensemble des applications “Corp” (c’est-à-dire concernant les services transverses et certaines business units) ont été migrées. Certaines applications sont sensibles en termes de disponibilité, car elles sont ouvertes à l’ensemble des clients externes. Dans le cas de l’une de ces applications (en production), 16 000 utilisateurs potentiels sont concernés. Enfin, il faut noter que dans le cadre de cette migration, les équipes de D2SI gèrent l’ensemble du build, et que le run est confié à un infogéreur.

Industrialiser le processus de migration

L’automatisation a également permis d’industrialiser le processus de migration en le rendant réplicable. Les nombreuses briques créées par les équipes de D2SI peuvent maintenant être ré-utilisées pour accompagner d’autres projets. Par exemple, dans le cas du déploiement de serveurs web et RDS, le code existant peut être utilisé en changeant simplement les paramètres. Cette capitalisation sur l’existant s’inscrit dans la démarche Go to Cloud, qui vise à proposer aux Business Units une méthodologie pour porter les applications dans le Cloud Public d’AWS selon les règles définies par Veolia.

Automatisation des images avec Packer

Pour gérer la problématique de la mise à jour des images, Armand Buisson, consultant Cloud D2SI, a automatisé le déploiement quotidien d’une machine, dont la tâche est de vérifier la dernière version d’AMI proposée par Amazon. S’il existe une nouvelle version, alors toutes les AMI sont reconstruites avec la version à jour, puis l’instance s’auto-détruit. On s’assure de cette façon que les images soient à jour à en permanence, sans nécessiter d’intervention humaine, puisque le lancement de Packer est automatisé. En cas de besoin, une simple modification dans le script permet d’ajouter d’autres images.

Jenkins, l’orchestrateur

Très souvent utilisé dans les chaînes de d’intégration continue, Jenkins a ici été utilisé comme orchestrateur. La migration et les besoins liés au run amènent en effet un fort besoin d’orchestration, notamment au niveau des dépendances, et Jenkins a été choisi pour répondre à ce besoin. Par exemple, dans le cadre de l’automatisation du rafraîchissement des bases RDS, les différents pipelines (export des données depuis RDS vers S3, puis import sur une autre base RDS existante) sont planifiés sur Jenkins de façon à être traités de façon automatisée de manière récurrente ou à la demande. Dans le cas d’un redémarrage d’infrastructure nécessitant un séquencement particulier (il ne s’agit pas d’un redémarrage ponctuel d’EC2 ou RDS), Jenkins permet de le paramétrer. Le patch management sur Windows et Linux est également piloté par Jenkins.

Accompagner la migration sur AWS

Souhaitant être moteur sur l’adoption des nouvelles technologies, Veolia a lancé plusieurs initiatives visant à faciliter la concrétisation de la stratégie “datacenter exit”. AWS Starter Kit permet par exemple aux Business Units souhaitant migrer sur AWS de démarrer un environnement AWS, conforme aux bonnes pratiques Veolia, clé en mains, mais déconnecté du système d’information, pour tester les différents services et monter en compétence sur AWS avec l’aide du Digital Solutions Store. Pour soutenir l’initiative Starter Kit, les équipes de D2SI ont automatisé la création des comptes pour les nouveaux utilisateurs, comptes reliés à un compte principal de facturation. Ceci permet de déployer autant de comptes que nécessaire, rapidement et facilement : le processus prend 20 minutes, contre 4h auparavant. Automatiser la création de comptes AWS répond à de nombreux cas d’usages, comme celui de l’entité Campus pour créer des sessions de formations sécurisées. Dans le cadre des formations Campus, les équipes D2SI travaillent également à assurer la haute disponibilité des applications sur de courtes durée (une semaine de formation, par exemple), et le streaming des applications avec AWS AppStream 2.0.

Commentaires :

A lire également sur le sujet :