métamorphosé dans lequel l ’ informatique d ’ entreprise évolue aujourd ’ hui . Bien que les projets d ’ informatique d ’ entreprise prennent traditionnellement des mois ou des années , les capacités des technologies cloud , associées aux approches DevOps , ont irrémédiablement changé ce modèle .
Les personnes occupant les postes clés des entreprises informatiques ont saisi le potentiel d ’ accélération des cycles de développement et de baisse des coûts opérationnels des conteneurs , surtout lorsqu ’ on les associe au cloud et au DevOps . Ces capacités peuvent se traduire par un avantage concurrentiel énorme , et si une chose peut motiver l ’ informatique d ’ entreprise , c ’ est bien la concurrence directe .
J ’ ai pu constater cette réalité au cours de récentes sessions de présentation des conteneurs auxquelles j ’ ai participé avec les architectes Docker Aaron Huslage et Matt Bentley . Ces deux sessions se sont déroulées au sein de services d ’ informatique d ’ entreprise dans des sociétés bien installées dans le classement Fortune 50 , toutes deux avec énormément d ’ infrastructure et de processus hérités . Cependant , ces deux entreprises voulaient à tout prix intégrer un maximum de conteneurs dans leurs processus et architectures de fourniture d ' applications , en tirant parti de l ’ expertise Docker .
Etat de l ’ idée préconçue n ° 3 : DEMONTEE !
Idée préconçue n ° 4 : Les conteneurs Docker ne sont pas aussi sûrs que l ’ infrastructure traditionnelle
Cette idée préconçue est souvent exprimée de manière plus directe ( et moins précise ) : « les conteneurs ne sont pas sûrs ». Une évaluation de sécurité utile ne peut être faite que par rapport à des critères reconnus - car après tout , la sécurité totale ne peut être atteinte que par un accès nul . Si les critères sont ceux d ’ une machine virtuelle comme celle de VMware , pas de doute , les conteneurs n ’ offrent pas le même niveau d ’ isolation , et les conteneurs Docker présentent des failles de sécurité qui doivent être réglées .
Cependant , on oublie souvent le fait que le déploiement de conteneurs entraîne une réduction correspondante du nombre d ’ instances de système d ' exploitation déployées . Les VM modernes n ’ offrent qu ’ une surface réduite aux attaques . Cependant , chaque VM exécute une instance du système d ' exploitation , donc le total de surface susceptible d ’ être attaquée de chaque VM est une combinaison de la VM et du système d ' exploitation . Si un système d ' exploitation virtualisé est compromis , il ne sert plus à grand-chose de continuer l ’ attaque sur la couche de l ’ hyperviseur . Si un conteneur Docker est compromis , à moins que les protocoles de durcissement standard soient ignorés , l ’ attaque n ’ a accès qu ’ à ce seul processus d ’ application , et non au système d ' exploitation entier .
La leçon à retenir ici est que même à ce stade d ’ évolution des conteneurs , où la sécurité n ’ est pas encore mature , la surface combinée d ’ une pile d ’ application mise en conteneurs n ’ est pas tellement différente de celle d ’ une pile virtualisée .
Etat de l ’ idée préconçue n ° 4 : Semble crédible , mais DEMONTEE !
Idée préconçue n ° 5 : Le déploiement et l ’ orchestration des conteneurs sont impossibles à grande échelle
Cette idée préconçue est probablement la plus facile à démonter . Cette phrase était vraie si on l ’ allongeait en « l ’ orchestration des conteneurs est impossible à grande échelle ... avec les solutions prêtes à l ’ emploi . » Mais désormais , même la version allongée est fausse depuis que Docker a sorti Machine , Swarm et Compose .
Même sans prendre en compte les contributions de Docker , plusieurs exemples d ’ orchestration de conteneurs testés pour la production sont actuellement disponibles , avec en tête l ’ expérience d ’ ingénierie de Google et l ’ outil qui en résulte , Kubernetes . Suite à l ’ acquisition d ’ Orchard & Fig , l ’ API Docker fournit désormais un chemin clair de développement d ’ outils d ’ orchestration de conteneurs , un chemin suivi non seulement par Fig / Compose , mais aussi par Helios de Spotify et Centurion de New Relic .
Etat de l ’ idée préconçue n ° 5 : DEMONTEE !
Idée préconçue n ° 6 : Rocket et ses concurrents vont ralentir l ’ adoption de Docker
Le timing et le lancement de Rocket par CoreOS en tant que norme de conteneurs concurrente a incité beaucoup d ’ observateurs à douter de la viabilité de Docker . Le raisonnement est le suivant : si Docker était aussi formidable , pourquoi une norme concurrente verrait-elle le jour si rapidement ? Après tout , il a fallu plusieurs années pour qu ’ une alternative sérieuse à VMware et à son hyperviseur émerge . La réponse est assez simple : la technologie Docker est un projet open source avec une API ouverte , un projet qui avance grâce à la communauté de développement open source , et pas uniquement grâce à la société Docker . VMware a choisi un modèle fermé , comme Microsoft , pour son projet de virtualisation , et s ’ est retrouvé , sans surprise , face à Microsoft comme concurrent direct ( et compétent ).
42 | THE DOPPLER | HIVER 2016