Déployer des applications sur le cloud

Une fois qu’une application cloud a été conçue et développée, elle peut passer en phase de déploiement pour être distribuée aux clients. Le déploiement peut être un processus en plusieurs phases, chacune impliquant une série de vérifications permettant de vérifier que les objectifs de l’application sont atteints.

Avant de déployer une application cloud en production, il est utile d’avoir une liste de contrôle pour évaluer l’application par rapport à une liste de bonnes pratiques essentielles et recommandées. C’est le cas, par exemple, de la liste de contrôle de déploiement d’AWS et d’Azure. De nombreux fournisseurs de cloud mettent à disposition une liste complète d’outils et de services qui facilitent le déploiement, par exemple ce document d’Azure.

Processus de déploiement

Le déploiement d’une application cloud est un processus itératif qui commence à la fin du développement et se poursuit jusqu’à la publication de l’application dans les ressources de production :

Figure 1 : Processus de déploiement de code

Il est courant pour les développeurs cloud de gérer plusieurs versions simultanées de leurs applications dans le cadre d’un pipeline de déploiement en différentes étapes :

1. Test
2. Préproduction
3. Production

Chacune des trois étapes doit idéalement avoir des ressources et une configuration identiques, ce qui permet aux développeurs de tester et de déployer l’application, et de réduire les risques d’incohérences résultant d’un changement d’environnement et de configuration.

Changements d’application dans un pipeline

Dans un scénario de développement d’application agile classique (comme indiqué dans la figure précédente), les applications sont gérées par un ensemble d’ingénieurs et de développeurs qui travaillent sur les problèmes et les bogues à l’aide d’un genre de mécanisme de suivi des problèmes. Les changements apportés au code sont conservés via un système de dépôt de code (par exemple, svn, mercurial ou git), où des branches distinctes sont conservées pour la publication du code. Après avoir fait l’objet de changements, de revues et d’approbations, le code peut être mis en pipeline dans des phases de test, de préproduction et de production. Cela peut se faire de plusieurs manières :

Scripts personnalisés : Les développeurs peuvent utiliser des scripts personnalisés pour tirer (pull) la dernière version du code et exécuter des commandes spécifiques afin de générer l’application et la placer en état de production.

Images de machine virtuelle ayant fait l’objet d’un bake préalable : Les développeurs peuvent également provisionner et configurer une machine virtuelle avec l’ensemble de l’environnement et des logiciels nécessaires au déploiement de leur application. Une fois configurée, la machine virtuelle peut faire l’objet d’une capture instantanée et être exportée vers une image de machine virtuelle. Vous pouvez fournir cette image à divers systèmes d’orchestration cloud pour qu’elle soit déployée et configurée automatiquement dans le cadre d’un déploiement de production.

Systèmes d’intégration continue : Si vous souhaitez simplifier les différentes tâches impliquées dans le déploiement, vous pouvez utiliser les outils d’intégration continue (CI) pour automatiser les tâches (par exemple la récupération de la dernière version d’une application dans un dépôt, la génération de fichiers binaires d’application et l’exécution de cas de test) qui doivent être effectuées sur les différentes machines qui composent l’infrastructure de production. Jenkins, Bamboo et Travis sont des exemples d’outils CI populaires. Azure Pipelines est un outil CI spécifique à Azure conçu pour fonctionner avec les déploiements Azure.

Gérer les temps d’arrêt

Certains changements apportés à l’application peuvent nécessiter un arrêt partiel ou complet des services d’application pour permettre l’incorporation d’un changement particulier sur le serveur back-end de l’application. Les développeurs doivent généralement planifier une heure spécifique de la journée pour réduire les interruptions subies par les clients de l’application. Les applications conçues pour une intégration continue peuvent effectuer ces changements en temps réel sur les systèmes de production, avec une interruption minimale ou inexistante des clients de l’application.

Redondance et tolérance de panne

Les bonnes pratiques de déploiement d’applications supposent généralement que l’infrastructure cloud est éphémère : elle peut être indisponible ou changer à tout moment. Par exemple, l’arrêt des machines virtuelles déployées dans un service IaaS peut être planifié à la discrétion du fournisseur de cloud, selon le type de contrat SLA.

Évitez de coder en dur les applications ou de supposer l’existence de points de terminaison statiques pour divers composants, par exemple les bases de données et les points de terminaison de stockage. Les applications bien conçues doivent idéalement utiliser des API de service pour interroger et découvrir les ressources, et s’y connecter de manière dynamique.

Des défaillances graves des ressources ou de la connectivité peuvent se produire à tout moment. Les applications critiques doivent être conçues pour anticiper de telles défaillances et pour favoriser la redondance de basculement.

De nombreux fournisseurs de cloud conçoivent leurs centres de données sous forme de régions et de zones. Une région est un site géographique spécifique qui héberge un centre de données complet, alors que les zones sont des sections individuelles d’un centre de données qui sont isolées à des fins de tolérance de panne. Par exemple, deux zones ou plus dans un centre de données peuvent avoir une infrastructure d’alimentation, de refroidissement et de connectivité distincte, afin qu’aucun défaut présent dans une zone n’affecte l’infrastructure de l’autre. En règle générale, les fournisseurs de services cloud mettent à disposition des clients et des développeurs les informations relatives aux régions et aux zones pour leur permettre de concevoir et de développer des applications qui peuvent tirer parti de cette propriété d’isolement.

Les développeurs peuvent donc configurer leur application pour utiliser des ressources dans plusieurs régions ou zones afin d’améliorer la disponibilité de l’application et d’offrir une tolérance de panne dans une zone ou une région spécifique. Ils doivent configurer des systèmes capables de router et d’équilibrer le trafic entre les régions et les zones. Les serveurs DNS peuvent également être configurés pour répondre aux requêtes de recherche de domaine à des adresses IP particulières dans chaque zone, selon l’origine de la requête. Cela permet de disposer d’une méthode d’équilibrage de charge basée sur la proximité géographique des clients.

Sécurité et durcissement de la sécurité en production

L’exécution d’applications Internet sur un cloud public doit être effectuée avec précaution. Dans la mesure où les plages d’adresses IP du cloud sont des cibles de haute valeur, il est important de vérifier que toutes les applications déployées sur le cloud respectent les bonnes pratiques liées à la sécurisation et au durcissement de la sécurité des points de terminaison et des interfaces. Voici quelques principes de base à suivre :

• Tous les logiciels doivent être mis en mode production. La plupart des logiciels prennent en charge le « mode débogage » pour les tests locaux et le « mode production » pour les déploiements réels. Les applications en mode débogage font fuiter généralement une grande quantité d’informations aux attaquants qui envoient des entrées incorrectes. Elles offrent donc une source de reconnaissance facile pour les pirates informatiques. Peu importe que vous utilisiez un framework web tel que Django ou Rails, ou une base de données Oracle, il est important de suivre les recommandations appropriées pour le déploiement d’applications de production.
• L’accès aux services non publics doit être limité à certaines adresses IP internes pour l’accès administrateur. Vérifiez que les administrateurs ne peuvent pas se connecter directement à une ressource critique à partir d’Internet sans passer par un Launchpad interne. Configurez les pare-feu avec des règles basées sur les adresses IP et les ports pour autoriser l’ensemble minimal d’accès nécessaires, en particulier avec SSH et les autres outils de connectivité à distance.
• Suivez le principe des privilèges minimum. Exécutez tous les services en tant qu’utilisateur ayant le moins de privilèges possible pour effectuer le rôle nécessaire. Limitez l’utilisation des informations d’identification root aux connexions manuelles spécifiques effectuées par les administrateurs système qui doivent déboguer ou configurer certains problèmes critiques du système. Cela s’applique également à l’accès aux bases de données et aux panneaux d’administration. Les accès doivent généralement être protégés à l’aide d’une paire de clés publique-privée longue et aléatoire. De plus, cette paire de clés doit être stockée de manière sécurisée dans un emplacement restreint et chiffré. Tous les mots de passe doivent répondre à des exigences strictes au niveau de la force.
• Utilisez des techniques et des outils défensifs bien connus pour les systèmes de détection d’intrusion et de prévention d’intrusion (IDS/IPS), les systèmes SIEM (informations de sécurité et gestion d’événements), les pare-feu de la couche Application et les systèmes antiprogramme malveillant.
• Définissez une planification des mises à jour correctives, qui coïncide avec la publication de correctifs effectuée par le fournisseur de vos systèmes. Souvent, les fournisseurs tels que Microsoft ont un cycle de publication fixe pour les correctifs.