Fotolia
Comment optimiser la portabilité de Docker sur AWS
L’un des gros avantages des conteneurs Docker est leur portabilité. Toutefois, certaines erreurs peuvent en limiter les capacités d’automatisation et par extension cette portabilité.
Lorsqu’AWS a lancé Amazon EC2 Container Service, les professionnels du secteur ont immédiatement compris l’avantage que pouvaient apporter les conteneurs à la portabilité du Cloud. Avec ce concept, les développeurs développent une application une fois et s’appuient sur Docker pour la déployer sur autant de plateformes qui supportent le framework.
AWS et Google supportent Docker directement sur leur infrastructure. Mais le simple fait d’utiliser Docker ne rend pas l’application portable immédiatement. Pour cela, il convient de passer certaines étapes.
Séparer les composants et les construire automatiquement
Certains développeurs configurent un serveur Docker en local, bâtissent à la main une image personnalisée et installent tous les composants dans une unique image. C’est une erreur. Assembler manuellement un conteneur Docker sur un système local n’est pas très synonyme de portabilité. A la moindre modification d’un composant, c’est l’ensemble qu’il faut reconstruire.
En revanche, il suffit de créer des Dockerfiles avec des instructions automatisées. Un Dockerfile est en fait un template qui définit commet construire un composant d’une application. Les conteneurs Docker peuvent être bâtis automatiquement à partir de ce Dockerfile sur toutes les plateformes qui supportent la technologie.
A savoir également : il est impératif que les développeurs segmentent les composants en petites unités logiques. Par exemple, les applications qui nécessitent une base de données MongoDB peuvent déplacer le conteneur MongoDB vers un Dockerfile séparé pour le relier ensuite au serveur d’application. Cela permet aussi aux équipes DevOps de reconfigurer les applications.
Relier les conteneurs
La plupart des applications doivent disposer de plusieurs composants – ou couches – pour fonctionner. Par exemple, un simple stack LAMP requiert un backend MySQL et un serveur Apache avec PHP. Il est courant que les applications de base de données soient composées de plusieurs conteneurs Docker pour séparer le chargement et les permissions. Cela permet aux développeurs de relier ces composants pour en faire une unique application. Les conteneurs Docker sont bon marché ; en créer plusieurs, en fonction des composants, est une bonne solution.
Une application traditionnelle peut par exemple comprendre :
- Un serveur d’application
- Memcached
- MySQL ou des bases de données NoSQL, comme MongoDB ou Redis.
Dans ce cas, on retrouve un conteneur Docker pour chaque composant et Docker expose les ports de chacun des sous-composants à un serveur d’applications. AWS propose un service Memcached, MySQL et Redis.
Eviter les bases et les services trop « fournisseur »
Les applications dont la portabilité est clé ne doivent pas se reposer sur des services trop spécifiques de certaines plateformes – comme avec DynamoDB. Utiliser un service comme Amazon ElastiCache au lieu d’un serveur Memcached conteneurisé fonctionne, mais il faut s’assurer que le composant serveur d’applications utilise les variables d’environnement que Docker utilise pour identifier l’emplacement du serveur Memcached. Ainsi, lorsqu’un développeur veut migrer un conteneur vers un autre cloud ou sur site, il est facile de créer un conteneur Docker Memcached et de les relier.
Certains services, comme Memached, Redis et ElasticSearch sont agnostiques d’un point de vue fournisseurs. Si un service fonctionne dans un conteneur Docker, vous pouvez utiliser la version native pour le Cloud. Mais il est important de configurer ces services sans avoir à réécrire la couche applicative. Avant d’utiliser un service très lié au fournisseur, vérifiez qu’il existe un remplaçant identique et qu’il soit disponible dans un conteneur Docker.
Créer des petits conteneurs
Les micro-conteneurs permettent d’exécuter une application avec une empreinte la plus réduite possible. Par exemple, un serveur d’application Go peut ne peser que 5 Mo. Les conteneurs plus imposants, ou ceux qui contiennent des distributions Linux, mettent plus de temps à démarrer et ont besoin de plus de ressources. Séparer les conteneurs entre plusieurs composants est clé, mais il faut s’assurer que cela n’a pas d’impact sur les performances.
Ne pas utiliser un OS ou un logiciel spécifique
Si l’OS Linux d’Amazon motorise les applications sur les instances EC2, il ne convient pas à Docker. Il s’agit d’un OS spécifique à AWS, aux instances EC2.
De plus, n’utilisez pas des logiciels spécifiques, comme AWS Command Line Interface. En revanche, assurez-vous que toutes les options de configuration peuvent être passées via des variables d’environnement.
Configurer le load balancing
Chaque fournisseur de Cloud dispose de ses propres offres de load balancing, spécifique à sa plateforme. Il est nécessaire que le fournisseur de DNS permette de changer rapidement de points de load balancing ou supporte la tolérance aux pannes.
Amazon Route 53 fait des diagnostics en matière de santé de l’application et des performances. Le service n’enferme pas les développeurs.
Tester la portabilité
Comme il est nécessaire de vérifier l’état de ses sauvegardes, on doit aussi vérifier la portabilité des conteneurs Docker. Lorsque l’on travaille avec cette technologie, il fait la tester sur plusieurs emplacements, et indépendamment de chaque fournisseur.
Effectuer régulièrement des tests de portabilité permet de voir si une application régresse. Si possible, ayez des conteneurs sur plusieurs plateformes et vérifiez que le demande peut être assurée depuis chaque emplacement.
Traduit et adapté par la rédaction
