Le cloud computing consiste à utiliser des ressources matérielles sur Internet comme extension et/ou en remplacement de votre architecture informatique locale. Le cloud computing est en expansion dans plusieurs domaines de l'entreprise, incluant l'email et le partage de document (Gmail et Google Apps sont des exemples particulièrement connus, mais il y en a d'autres), stockage de données hors-site (comme Amazon S3), aussi bien bien que des services techniques comme des dépôts de code source (comme GitHub, Bitbucket, etc.) et de nombreux autres.
Bien sûr les solutions d'architecture matérielle externalisée existent depuis longtemps. Le point principal qui distingue le cloud computing des services plus traditionnels est la vitesse et la flexibilité avec laquelle un service peut être monté, et démonté quand il n'est plus nécessaire. Dans un environnement de cloud computing, une nouvelle machine peut fonctionner et être disponible en quelques secondes.
Cependant, le cloud computing dans le contexte de l'Intégration Continue n'est pas toujours aussi simple qu'il n'y paraît. Pour qu'une approche basée sur le cloud fonctionne, certaines de vos ressources internes pourraient devoir être disponibles au monde extérieur. Ceci peut inclure l'ouverture d'accès à votre système de contrôle de version, votre base de données de test, et à n'importe quelle autre ressource que vos builds et vos tests requièrent. Tous ces aspects doivent être examinés attentivement lors du choix d'une architecture d'IC basée sur le cloud, et pourrait limiter vos options si certaines ressources ne peuvent tout simplement pas être accédées depuis Internet. Malgré tout, l'IC basée sur le cloud a le potentiel pour vous offrir d'énormes bénéfices sur l'évolutivité de votre infrastructure.
Dans les sections suivantes, nous regarderons comment utiliser les services de cloud computing d'Amazon EC2 pour mettre en place une ferme de build basée sur le cloud.
En plus de vendre des livres, Amazon est l'un des fournisseurs les plus connus de services cloud computing. Si vous êtes prêt à payer pour le service, Amazon peut vous fournir des machines de build qui peuvent soit être utilisées de façon permanente comme partie de votre ferme de build, soit mis en ligne au besoin lorsque vos machines de build existantes deviennent surchargées. C'est un moyen excellent et raisonnablement coûteux pour absorber la charge exceptionnel de build en fonction de vos besoins, et sans le mal de tête associé à des machines physiques supplémentaires à maintenir.
Si vous voulez la flexibilité d'une architecture d'IC basée sur le cloud, mais que vous ne voulez pas externaliser votre matériel, une autre option est de mettre en place un cloud Eucalyptus. Eucalyptus est un outil open source qui vous permet de créer localement un cloud privé sur du matériel existant. Eucalyptus utilise une API compatible avec Amazon EC2 et S3, et fonctionne bien avec Jenkins.
Amazon EC2 est probablement le service de cloud computing commercial le plus populaire et le plus connu. Pour utiliser ces services, vous devrez créer un compte EC2 avec Amazon si vous n'en avez pas déjà un. Le processus requis pour faire cela est bien documenté sur le site web d'Amazon, nous n'insisterons donc pas ici sur le sujet. Une fois que vous avez créé votre compte, vous pouvez créer des machines virtuelles et des images de machines qui formeront votre ferme de build basée sur EC2.
Quand vous utilisez Amazon EC2, vous créez des machines virtuelles, appelées instances, en utilisant la console de gestion Amazon Web Services (AWS) (voir Figure 11.17, “Vous gérez vos instances EC2 en utilisant la console de gestion Amazon AWS”). Ce site web vous permet de gérer vos instances en fonctionnement et d'en créer de nouvelles. Vous créez ces instances à partir d'images prédéfinies, appelées Amazon Machine Images (AMIs). Il y a plusieurs images AMI, à la fois d'Amazon et dans le domaine public, que vous pouvez utiliser comme point de départ, couvrant la plupart des systèmes d'exploitation populaires. Une fois que vous avez créé une nouvelle instance, vous pouvez vous y connecter soit via SSH (pour les machines unix) soit via une connexion à distance Windows, pour la configurer en fonction de ce que vous voulez en faire.
Pour mettre en place une ferme de build, vous aurez également besoin de configurer la votre, rendez-vous simplement dans le menu Paires de clés dans la Sécurité du serveur de build afin d'être en mesure d'accéder à vos instances EC2. En particulier, vous aurez besoin d'installer les outils de l'API Amazon EC2, de configurer les clés privées/publiques appropriées, et d'autoriser les connexions SSH depuis votre serveur ou votre réseau vers vos instances Amazon. Encore une fois, les détails indiquant comment faire cela sont bien documentés pour tous les systèmes d'exploitation principaux sur le site web EC2.
Vous pouvez utiliser les instances Amazon EC2 de deux façons — soit vous créez les machines esclaves sur Amazon EC2 et les utilisez comme machines distantes, soit vous demandez à Jenkins de les créer dynamiquement pour vous à la demande. Ou vous pouvez avoir une combinaison des deux. Les approches ont leur utilité, et nous discuterons de chacune d'elles dans les sections suivantes.
Créer une nouvelle instance EC2 revient tout simplement à choisir une image de base que vous voulez utiliser. Vous devrez juste fournir quelques détails de base à propos de l'instance, comme sa taille et sa capacité, et la clé privée que vous voulez utiliser pour accéder à la machine. Amazon créera ensuite une nouvelle machine virtuelle basée sur cette image. Une fois que vous avez configuré cela, une instance EC2 est en substance une machine comme n'importe quelle autre, et il est simple et commode de configurer des machines EC2 permanentes ou semi-permanentes comme part de votre infrastructure de build. Vous pourriez même opter pour utiliser une image EC2 pour votre serveur maître.
Configurer une instance EC2 existante comme un esclave Jenkins est peu différent que de configurer n'importe quel autre esclave distant. Si vous mettez en place un esclave EC2 Unix ou Linux, vous devrez référencer le fichier de clé privée (voir Figure 11.18, “Configurer un esclave Amazon EC2”) que vous avez utilisé pour créer l'instance EC2 sur la console de gestion AWS. En fonction du type de Linux que vous utilisez, vous pourriez aussi avoir besoin de fournir un nom d'utilisateur. La plupart des distributions se connectent en tant que root, mais certaines, comme Ubuntu, nécessitent un nom d'utilisateur différent.
La seconde approche implique de créer de nouvelles machines Amazon EC2 dynamiquement, lorsqu'elles sont nécessaires. Configurer des instances dédiées n'est pas difficile, mais cela ne s'adapte pas très bien à la charge. Une meilleure approche est de laisser Jenkins créer de nouvelles instances en fonction du besoin. Pour faire cela, vous aurez besoin d'installer le plugin Jenkins Amazon EC2. Ce plugin permet à Jenkins de démarrer des esclaves EC2 sur le cloud à la demande, et de les éteindre ensuite lorsqu'ils ne sont plus nécessaires. Le plugin fonctionne à la fois avec Amazon EC2, et Ubuntu Enterprise Cloud. Nous nous concentrerons ici sur Amazon EC2. Notez qu'à l'écriture de ces lignes le plugin supportait seulement la gestion des images EC2 Unix.
Une fois que vous avez installé le plugin et redémarré Jenkins, allez dans l'écran principal de configuration et cliquez sur Ajouter un Nouveau Cloud (voir Figure 11.19, “Configurer un esclave Amazon EC2”). Choisissez Amazon EC2. Vous devez fournir votre clé d'identification d'accès Amazon (NdT : Amazon Access Key ID) et votre clé d'accès secrète afin que Jenkins puisse communiquer avec votre compte Amazon EC2. Vous pouvez accéder à ceux-ci dans l'écran Paires de clés de votre tableau de bord EC2.
Vous devrez aussi fournir votre clé privée RSA. Si vous n'en avez pas, rendez vous simplement dans le menu Paires de clé dans l'écran Security Credential et créez en une. Cela créera une nouvelle paire de clé pour vous et téléchargera la clé privée. Conservez la clé privée dans un endroit sûr (vous en aurez besoin si vous voulez vous connecter à vos instances EC3 via SSH).
Dans les options avancées, vous pouvez utiliser le champ Limite d'Instances pour limiter le nombre d'instances EC2 que Jenkins lancera. Cette limite est liée au nombre total d'instances en exécution, pas seulement celles que Jenkins exécute en ce moment. C'est une mesure de sécurité utile, parce que vous payez pour le temps pendant lequel vos instances restent actives.
Une fois que vous avez configuré votre connexion EC2 globale, vous devez définir les machines avec lesquelles vous travaillerez. Vous faites cela en spécifiant l'identifiant d'Image Miroir Amazon (AMI) de l'image serveur avec laquelle vous aimeriez démarrer. Amazon fournit quelques images de démarrage, et plusieurs autres le sont par la communauté, toutefois elles ne fonctionneront pas toutes avec EC2. A l'écriture de ces lignes, seules certaines images basées sur des distributions Linux 32-bit fonctionnent correctement.
Les images AMI prédéfinies par Amazon et publiques sont des points de départ utiles pour vos machines virtuelles permanentes, mais pour les besoins inhérents à la mise en oeuvre d'un cloud dynamique basé sur EC2, vous devez définir vos propres AMI avec les outils essentiels (Java, outils de build, configuration SCM etc.) préinstallés. Heureusement, c'est un processus simple : démarrez simplement avec une AMI générique (de préférence une compatible avec le plugin Jenkins EC2), et installez tout ce dont vous avez besoin. Assurez-vous d'utiliser une image EBS. De cette façon, les changements que vous faites sur votre instance serveur sont sauvegardés sur un volume EBS afin que vous ne les perdiez pas lorsque le serveur s'éteint. Créez alors une nouvelle image en sélectionnant l'option Créer une image dans l'écran Instances de la console de gestion EC2 (voir Figure 11.20, “Créer une nouvelle image Amazon EC2”). Vérifiez que SSH est ouvert depuis l'adresse IP de votre serveur de build dans le groupe de sécurité par défaut sur Amazon EC2. Si vous ne faites pas cela, Jenkins échouera après avoir attendu trop longtemps le démarrage du nouveau noeud esclave.
Une fois que vous aurez préparé votre image, vous serez capable de l'utiliser pour votre configuration EC2.
A présent, Jenkins créera automatiquement une nouvelle instance EC2 en utilisant cette image lorsque c'est nécessaire, et supprimera (ou la “terminera,” en termes Amazon) l'instance une fois qu'il n'en aura plus besoin. Sinon, vous pouvez ajouter un nouvel esclave EC2 manuellement depuis l'écran Noeuds en utilisant le bouton Provisionner via EC2 (voir Figure 11.21, “Ajouter un nouvel esclave Amazon EC2 manuellement”). C'est un moyen utile pour tester votre configuration.
