Environnement Docker modulaire et réutilisable avec Carnotzet

Nous avons créé un outil qui intègre Docker et Maven pour aider des centaines de nos développeurs à gérer des environnements de développement complexes avec des centaines de services, avec un minimum d'effort. C'est une histoire sur la façon dont une idée folle est devenue réalité. C'est l'histoire de Carnotzet .

Tout a commencé il y a environ cinq ans (date de publication approximative le 3 août 2017), Swissquote s'est rapidement développée et développée. À l'époque, nous comptions environ 70 développeurs travaillant sur de grands projets Java (environ monolithiques), nécessitant chacun de passer 1 à 2 jours pour configurer le lancement du projet localement. Nous détestons perdre du temps sur des tâches répétitives! Il a donc été décidé d'améliorer ce processus en utilisant Vagrant et Chef pour automatiser le déploiement de notre environnement de développement local. Cela a marqué le début de notre premier projet Sandbox (Sandbox, approx.)

Nous souhaitons partager des environnements de développement et de test légers, reproductibles, isolés et portables.

Pendant un moment, tout s'est bien passé. Les développeurs pouvaient simplement télécharger le projet, exécuter «vagabond» et se mettre au travail. Nous avons utilisé cette approche pendant environ deux ans et nous en avons été très satisfaits.

Par la suite, travailler sur ces grandes applications est devenu plus difficile du fait que la logique métier est devenue plus complexe (marque blanche de notre plateforme de trading). Et nous avons décidé de faire ce que la plupart des organisations ont fait en 2014: briser la logique en microservices.

Tout s'est bien passé, et en 2016, nous avions environ 150 (micro, environ) Services de production. Mais les scripts Chef utilisés pour configurer les machines virtuelles ont augmenté et sont hors de contrôle. Les environnements de développement sont devenus beaucoup plus compliqués pour certaines applications avec environ 30 dépendances. Nous avons également découvert que la connaissance de Chef ne faisait pas partie de l'ensemble de compétences standard de nos développeurs. Pour cette raison, de nombreuses personnes ont simplement fait fonctionner le script, parfois, en copiant de mauvais exemples. En essayant de ne pas casser la configuration pour les autres équipes, ils ont créé des brunchs de longue durée pour les besoins de leur propre équipe et, par conséquent, le code de configuration de l'environnement de développement n'était plus public.



Nous avons dû le réparer.

Les faiblesses suivantes de notre bac à sable ont été identifiées:

• Besoin de connaître le chef. Et pour les développeurs existants, et pour les débutants, apprendre ce framework était un plaisir assez cher.
  En outre, cela n'était redondant que pour l'environnement de développement / test.
• Il n'y avait aucun moyen d'abstraction / composition facile ou de réutilisation d'une partie de la configuration de l'environnement. Cela a conduit au fait que les gens devaient se plonger dans tous les détails et les nuances de la configuration de dépendance de leurs projets, qui étaient généralement pris en charge par d'autres équipes. Cela a conduit à un désaccord et à une interaction inutile entre les équipes.

Afin de corriger le premier point, il a été décidé de passer à l'utilisation de Docker. Il a un seuil d'entrée inférieur et offre également d'autres avantages, tels que la normalisation, la prise en charge PaaS et un déploiement plus facile dans plusieurs environnements.

Nous avons également envisagé d'utiliser uniquement docker-compose. Il avait l'air très prometteur, mais malgré son nom, il lui manquait des choses comme la possibilité de composition et, en même temps, l'abstraction et la réutilisation. Ce sont ces aspects dont nous avions besoin. Nous rêvions de pouvoir prendre l'environnement de développement / test existant, y ajouter un service et éventuellement redéfinir une partie de sa configuration. Nous voulions y parvenir sans avoir à copier la configuration du service ajouté ou à plonger dans les détails des dépendances transitives et leur configuration.

C'est alors que nous avons eu cette idée: «Et si nous prenions Maven, le système de gestion des dépendances que nous utilisons pour construire nos applications java, et commençons à l'utiliser pour construire nos environnements?» Cela nous permettrait d'abstraire nos dépendances transitives, les configurations de packages, d'en créer des versions et de les réutiliser. Il ne sera pas non plus nécessaire d'apprendre un nouveau système de gestion des dépendances.

Après plusieurs tentatives, nous sommes parvenus à la solution suivante:

• Chaque artefact Maven représente un environnement entièrement fonctionnel qui peut être utilisé comme dépendance dans d'autres environnements. (un environnement minimal peut être représenté par un service, par exemple, une base de données)
• Les fichiers JAR contiennent la configuration. Variables d'environnement, fichiers de configuration d'application, nom Docker d'image, etc.
• Cette configuration peut être remplacée dans les modules situés plus haut dans la hiérarchie des dépendances, si nécessaire.
• La bibliothèque Java peut soulever l'environnement complet (en utilisant docker-compose sous le capot) à partir d'un module Maven (GAV ou pom.xml)

Maven permet de distribuer et de versionner ces artefacts («artefacts d'environnement») et nous pouvons facilement partager le code source entre les équipes. Le processus est devenu plus simple et les développeurs ont commencé à utiliser des modules d'autres équipes. Et créez et entretenez également le vôtre.

En prime, tous les outils facilitant le travail avec Maven peuvent être utilisés ici. À titre d'exemple, le graphe de dépendances généré à l'aide d'IntelliJ IDEA nous montre maintenant un schéma de l'architecture pour l'interaction de nos dépendances :)


Architecture d'un exemple d' application de vote à partir de docker-compose

Dans le même temps, il y a eu quelques difficultés de mise en œuvre, telles que forcer toutes les équipes à emballer des applications à l'aide de Docker (dockerize) et à regrouper des configurations dans des modules Maven distincts. Par tous les comptes, il est devenu plus facile d'importer des applications à partir d'autres équipes et de prendre en charge des environnements de développement complexes.

Nous avons commencé à travailler dans ce sens il y a environ un an, et maintenant nous avons environ 200 de ces modules utilisés pour le développement et les tests. Nous sommes arrivés à la conclusion que cette bibliothèque est également idéale pour gérer l'environnement temporaire pour les tests de bout en bout sur notre plate-forme CI.

Nous étudions actuellement comment réutiliser cette technologie pour gérer nos environnements UAT / d'intégration en lançant des conteneurs dans Kubernetes au lieu de docker-composer, et ainsi assurer des mises à jour continues et une élasticité informatique sur des environnements beaucoup plus grands.

J'espère que vous serez heureux de savoir que notre projet a été ouvert sous la licence Apache 2.0 et est disponible sur Github: github.com/swissquote/carnotzet

Utilisez :)