Problèmes de logiciels et comment Docker les résout

Résumé

Les organisations tirent parti de Docker pour devenir plus agiles, plus réactives et plus légères alors qu'elles continuent à être compétitives dans un environnement logiciel difficile. L'utilisation de Docker permet aux organisations de créer des systèmes logiciels faciles à déployer qui peuvent fonctionner sur des systèmes informatiques individuels ou en grappe sur une grande variété de plateformes. Découvrez comment Docker facilite la mise à jour, le test et le débogage des logiciels grâce à ce livre blanc et acquérez des connaissances de base sur Dockerfile, les images Docker et les conteneurs.

Article

Docker est une nouvelle approche de problèmes anciens, mais de plus en plus gênants dans l'industrie du logiciel, à savoir :

• Comment déployer des systèmes logiciels toujours plus puissants et complexes, utilisés par des dizaines, des centaines ou des milliers d'utilisateurs simultanément ?
• Comment créer, mettre à jour et maintenir ces logiciels, tout en donnant aux développeurs les plates-formes nécessaires pour les tester et les déboguer ?
• Comment faciliter les tests et créer des systèmes automatisés qui détectent les bogues et les problèmes de performance ?
• Comment pouvons-nous déployer ces systèmes, en effectuant l'équivalent de l'administration de système qui consiste à changer les pneus d'une voiture en mouvement, pour aider les utilisateurs qui dépendent de la disponibilité permanente de nos logiciels ?
• Comment pouvons-nous utiliser les leçons que nous avons tirées de la création d'un matériel plus puissant et plus flexible pour nous aider à résoudre nos problèmes logiciels ?

Cette dernière question est importante, car le matériel a connu une évolution similaire pour répondre à un problème similaire et Docker a été partiellement inspiré par l'évolution du matériel. À mesure que le matériel devenait plus puissant, l'industrie informatique utilisait cette puissance supplémentaire pour résoudre les problèmes inhérents au fonctionnement de systèmes complexes.

Le matériel a été "découpé" en logiciels de machines virtuelles (VM) qui, à toutes fins utiles, sont des machines distinctes, impossibles à distinguer de celles qui fonctionnent sur des machines traditionnelles (ordinateurs "bare metal"). Les VM ont résolu le problème de l'efficacité et de la rentabilité des ordinateurs. Vous pouvez acheter un ou plusieurs gros boîtiers, puis diviser leur capacité en plusieurs VM plus petites pour faire fonctionner le système. Au fur et à mesure que le système se développe et évolue, il suffit de modifier l'espace et la puissance alloués à la VM.

Pour être aussi portable que possible, une VM définit le système d'exploitation à utiliser, le nombre de CPU à allouer, la quantité de mémoire à attribuer et tout espace de stockage local qui lui est réservé. Lorsque ces ressources sont disponibles, la VM démarre le système d'exploitation, lance tout autre programme nécessaire, puis est prête à exécuter tout ce qu'un ordinateur "bare metal" pourrait exécuter.

Du côté des logiciels, les nouveaux systèmes deviennent également plus complexes et, à ce titre, ils dépendent de plus en plus d'autres systèmes logiciels (par exemple, une application qui dépend d'une bibliothèque de rendu d'images). Ces dépendances doivent être gérées avec soin, car un système mal configuré peut ne pas fonctionner, fonctionner incorrectement ou présenter des failles de sécurité. Une façon de gérer les dépendances est d'utiliser l'approche VM : il suffit de regrouper le logiciel souhaité, ainsi que tous les logiciels dont il dépend, dans une image VM. Ainsi, lorsque le système démarre, tout se trouve au bon endroit, au bon niveau de version et dans la bonne configuration. Le problème avec l'approche VM pour le déploiement de logiciels est qu'un serveur doit être construit avec chaque paquet. Les paquets finissent par devenir plus gros et plus complexes pour justifier les ressources consacrées au démarrage et au fonctionnement de la VM. De plus, le déploiement d'un logiciel sous forme de VM signifie que toutes les ressources de la VM elle-même doivent être allouées, ce qui rend difficile l'utilisation de plusieurs VM sur l'ordinateur portable d'un développeur, par exemple.

Parallèlement, avec le concept de produit minimum viable (MVP) et les approches agiles du développement, les parties prenantes du projet et les utilisateurs finaux exigent des cycles plus rapides et des équipes logicielles plus réactives. Plutôt que d'attendre des mois ou des années pour des produits, les utilisateurs exigent des sorties de produits en quelques semaines, jours, voire heures ou minutes. Pensez à la fréquence à laquelle des entreprises comme Google, Twitter, Amazon et Facebook modifient leurs logiciels. Dans ces entreprises, il n'y a pas de concept de version gelée, testée, puis publiée. Le logiciel est en constante évolution. Et comme il n'existe pas de version "gelée" du logiciel, chaque nouvelle itération du logiciel doit être conditionnée pour pouvoir être déployée rapidement.

En même temps, l'idée qu'une entreprise développe un seul système logiciel basé sur un langage de programmation, un ensemble de bibliothèques, pour un seul système d'exploitation, n'est plus une pratique courante. Désormais, chaque groupe travaillant sur ses propres modules au sein d'un système logiciel peut choisir les outils et les environnements qui répondent le mieux aux besoins de ces modules. 

NOS FORMATIONS DOCKER