Voici une brève description de la façon dont nous avons commencé notre voyage dans Docker. Notre objectif était de disposer d’un environnement de développement et d’intégration complètement autonome, afin de rendre l’expérience de développement plus fluide et de réduire le temps de mise en route pour tout nouveau venu dans l’équipe. Il s’agissait également de rompre la dépendance à l’égard de l’infrastructure AWS au moment du développement et de réduire considérablement les coûts. Pour y parvenir, nous avons dû faire fonctionner ensemble plusieurs nœuds avec des configurations différentes, comme le nœud d’ingestion de données, le développement, la production, etc. Nous aurions pu opter pour une solution basée sur plusieurs VM, avec des VM de différentes saveurs/configurations. Mais les problèmes avec cette approche sont:
- Nous devons installer/configurer manuellement différentes VM en installant les services appropriés
- La mise en place de l’intercommunication entre les VM serait difficile à faire, notamment sur la base des dépendances impliquées entre les nœuds
- Les performances seraient vraiment faibles lorsque nous exécutons plusieurs VM dans une seule machine.
Sur la base de ces éléments, nous avons opté pour une approche basée sur Docker
Approche
Nous avons commencé par créer différentes images Docker, chacune avec l’ensemble des services préinstallés pour les nœuds mentionnés ci-dessus. Ensuite, nous avons dû nous attaquer au problème de les faire fonctionner ensemble et d’établir les dépendances requises entre eux. Par exemple, les données traitées doivent passer d’un des nœuds à l’autre. Ceci doit être réalisé avec les références logiques entre les nœuds, c’est-à-dire sans se référer à un nœud par son adresse IP, etc. Pour y parvenir (c’est-à-dire pour exécuter plusieurs instances ensemble avec coordination, nous avions deux options:
- Pour aller pour une solution pure basée sur Docker seulement avec Docker compose.
- Pour aller pour Docker et Vagrant solution basée.
Nous avons décidé d’aller pour Vagrant plus Docker sur l’approche Docker seulement.
Vagrant et Docker
Vagrant nous aide à créer et à configurer des environnements de développement légers, reproductibles et portables. C’était exactement ce que nous recherchions, c’est-à-dire un environnement de développement reproductible. Les raisons pour lesquelles nous n’avons pas pu opter pour Docker compose étaient les suivantes :
Il manquait certaines fonctionnalités en termes de provisionnement des instances par rapport à Vagrant.
- Vagrant avait des dispositions pour exprimer les dépendances entre les instances.
- Comme l’ordre dans lequel elles doivent être mises en place et d’autres formes de dépendances également.
- Nous pouvons également mentionner si les instances doivent être mises en place séquentiellement ou en parallèle.
- Vagrant a également une disposition pour arrêter/reprendre l’ensemble de l’environnement avec une seule commande « vagrant haut/bas ».
Nous avons commencé à écrire des fichiers vagrant pour assembler toutes nos images de la manière dont nous avions besoin.
Nous devions faire en sorte que nos images démarrent dans la séquence appropriée.Nous avons ajouté les scripts de provisionnement pour toutes les instances. Avec des commandes pour démarrer les services appropriés pour chaque nœud/instance.Nous avons personnalisé les scripts de création de cluster et de démarrage de Sequence-iq image, selon nos besoins.Nous avions ajouté le mappage des ports et la configuration de liaison pour les instances concernées en utilisant les options de Vagrant dans le fichier Vagrant.
Notre réalisation
Avec une commande Vagrant up on, les développeurs obtiennent un environnement de développement cohérent sur lequel ils peuvent travailler (dans n’importe quel OS comme Linux, Mac ou Windows). Aucune étape supplémentaire autre que l’installation de Vagrant n’est nécessaire. Nous avons modifié l’image de base de sequenceiq pour mettre en place le cluster Hadoop avec les services nécessaires préinstallés et créé une image personnalisée pour Crayon. Nous avons défini nos propres blueprints et utilisé Vagrant pour les déclencher au lieu d’utiliser le shell Ambari. Nous avons pu éviter complètement d’utiliser l’infrastructure AWS au moment du développement, sauf en de rares occasions. Nous l’utilisions uniquement à des fins de production et de déploiement. Nous avions mis en place notre propre registre docker privé pour stocker nos images personnalisées, également en utilisant l’image docker docker registry docker.
Meilleures pratiques
Certaines des meilleures pratiques qui peuvent être suivies lors de l’utilisation/adoption de docker sont:
- Il est préférable d’avoir une hiérarchie d’images tout en créant nos propres images docker avec les services requis pré-installés
- Nous pouvons définir une image de base qui a des composants qui changent rarement pendant le cycle de vie du produit
Par-dessus, nous pouvons construire une autre image en utilisant cela comme image de base avec des composants que vous prévoyez de changer souvent. Pour ce faire, il suffit d’y faire référence dans la section FROM de votre fichier Docker. Utilisez l’image correspondante pour établir un lien avec le système de construction du produit et créer l’image Docker avec vos derniers artefacts.
