La conteneurisation est aujourd’hui un des leviers de modernisation des applications, notamment dans un contexte Cloud public ou privé. Pour en tenir les meilleurs bénéfices, les équipes IT au sein des DSI sont amenées à adapter à la fois leurs pratiques mais aussi leur culture et leur organisation.
PARLONS D’ABORD DEVOPS
Nous l’avons évoqué dans les deux articles précédents : la conteneurisation permet de faciliter les cycles de livraison des applications. Il s’agit en effet d’un des accélérateurs de l’approche DevOps, qui vise à renforcer l’agilité au sein de la DSI.
Cette agilité peut être traduite par le passage, pour une même application, d’un cycle de livraison monolithique à plusieurs livraisons automatisées de plusieurs conteneurs (ou microservices portés par des conteneurs).
Ce nouveau modèle de livraison implique trois points clés :
1/ La nécessité d’adapter le processus de livraison des applications, en mettant en place des pipelines CI/CD, à savoir : automatiser de bout en bout le cycle de livraison de l’application (revue de code, compilation, tests unitaires, intégration, déploiement, livraison en production).
2/ Le besoin de s’organiser en mode Feature Team. En d’autres termes, passer d’un modèle siloté selon les phases projet à un modèle organisationnel, où les équipes sont autonomes sur leurs périmètres fonctionnels, de la phase développement jusqu’au run. Les fameux principes comme « You Build it, you run it ! » ou « Shift-left » ont encore plus de sens dans un contexte où les applications sont découplées en mode microservices et composées de conteneurs volatiles, portables et scalables.
3/ Penser Stateless, Observability, Design for failure, … et tout autre pattern en lien avec la performance de l’application, dès les phases de développement. En effet, les préoccupations des opérationnels telles que le monitoring et la maintenabilité de l’application deviennent au cœur des enjeux des développeurs.
Notons tout de même que les différents défis cités ci-dessus impliquent à la fois des considérations techniques mais aussi culturelles. Le DevOps est avant tout une culture nécessitant un état d’esprit de collaboration entre les développeurs et les opérationnels, avec pour objectif commun de répondre rapidement et au plus près au besoin métier.
N’OUBLIONS PAS LA SÉCURITÉ !
On peut difficilement aborder les sujets de transformation technologique comme la conteneurisation sans prendre le temps d’adresser les sujets de cybersécurité. En effet, les attaques de cybersécurité visant les conteneurs sont au cœur de l’actualité et font clairement partie des principaux enjeux de la SSI.
D’abord, il est important de rappeler que les bonnes pratiques « habituelles » autour de la sécurité des applications s’appliquent de la même manière dans le contexte des applications conteneurisées. En effet, il est nécessaire de continuer à appliquer le principe du « moindre privilège » et de le généraliser à l’échelle des conteneurs, en évitant de leur associer des privilèges élevés ou avec le compte root. Un conteneur ayant des privilèges importants représente une faille de sécurité et risque, une fois compromis, de compromettre l’intégralité de l’application. Afin de maîtriser ce type de risque, et à titre d’exemple dans le cadre de l’utilisation du moteur d’orchestration Kubernetes, les Pod Security Policies permettent de délimiter les privilèges associés aux conteneurs déployés.
De la même manière, il est nécessaire de continuer à intégrer la sécurité à tous les niveaux d’architecture : chiffrement des données (in transit & at rest), protection anti-DDoS et détection et remédiation aux vulnérabilités.
Sur le dernier point, une vigilance particulière doit être accordée aux vulnérabilités à l’échelle des images des conteneurs. En effet, une fois qu’une image d’un conteneur contient une vulnérabilité, tous les conteneurs déployés à partir de celle-ci seront impactés. Si une remédiation à une vulnérabilité sur une machine virtuelle est appliquée via un patch sur la ressource, la remédiation au niveau des conteneurs est réalisée via le redéploiement des conteneurs à partir d’une nouvelle image qui intègre la remédiation (les conteneurs étant des composants volatiles).
En complément, et en lien avec les pratiques DevOps évoquées ci-dessous, nous observons une attention de plus en plus forte accordée aux pratiques « DevSecOps ». Celles-ci soutiennent la démarche d’automatisation et de fiabilisation du cycle de livraison, en intégrant et systématisant les tests de sécurité automatisés dès les phases de développement. On passe donc d’une approche où les tests de sécurité (tests d’intrusion, scans de vulnérabilité, monitoring sécurité) sont considérés comme étant une étape de validation avant mise en production à une culture où la sécurité est intégrée par défaut dès les phases de développement.
ET LE FINOPS DANS TOUT CELA ?
Les pratiques à adopter dans un contexte de conteneurisation ne s’arrêtent pas au DevOps et au DevSecOps. Les enjeux d’optimisation financière doivent également être adressés via les pratiques FinOps adaptées aux conteneurs.
Certaines bonnes pratiques FinOps, telle que la mise en place des Tags, permettent de disposer d’une visibilité sur les coûts et leur répartition dans un contexte Cloud. Cette visibilité permet d’une part d’appliquer plus facilement le Chargeback ou refacturation des coûts aux équipes projet, en fonction de leur consommation des services, et d’autre part d’identifier plus facilement les ressources orphelines, qui nécessitent d’être décommissionnées.
Ces principes vont être très vite limités dans le contexte des conteneurs. En effet, le principe d’une approche de conteneurisation à l’échelle de plusieurs applications est la mutualisation des ressources utilisées. Par conséquent, une même ressource (cluster ou machine virtuelle) peut contenir des conteneurs associés à plusieurs applications. Le tag au niveau d’une machine virtuelle ne suffit pas à allouer correctement les coûts de manière alignée avec l’usage en question.
Pour répondre à cet enjeu, la bonne pratique consiste à faire en sorte de disposer d’une vision plus fine de l’usage des conteneurs. Pour le cas des conteneurs orchestrés par Kubernetes, cette vision devrait intégrer l’usage à l’échelle des clusters, des namespaces, des services, des labels, etc. Ainsi, il devient possible de ventiler les coûts de façon plus précise selon les usages associés. Des fonctionnalités de certains outils FinOps SaaS permettent de répondre plus facilement à ces enjeux.
Les pratiques FinOps ne s’arrêtent pas à l’obtention de visibilité sur les coûts et leur ventilation : elles concernent également des réflexions autour des architectures et de l’usage des services. Dans le contexte de la conteneurisation, où les architectures applicatives sont distribuées entre plusieurs ressources, il convient de mener une réflexion autour du dimensionnement des Clusters et de son adaptation sur la durée.
Le Rightsizing est indéniablement l’une des premières pratiques pouvant optimiser significativement les coûts. Pour mener cette réflexion correctement, il est nécessaire d’estimer, dès les phases de Design, les besoins techniques (CPU, mémoire, etc.) des conteneurs pour choisir les types d’instances adaptés. Par la suite, le monitoring des conteneurs et des ressources de l’architecture permet d’identifier le redimensionnement nécessaire sur ces ressources.
Notons tout de même que des services proposés par certains Cloud Providers et basés sur du Machine Learning permettent d’analyser ces données de monitoring et suggérer des modifications de redimensionnement des instances dans le but d’optimiser les coûts ainsi que la performance. C’est le cas par exemple du service Compute Optimizer sur AWS.
Pour finir, il convient également de mettre en place un ensemble de bonnes pratiques dans l’usage des clusters à partir du moteur d’orchestration. Parmi ces bonnes pratiques et dans un contexte Cloud Public, nous pouvons citer l’autoscaling des ressources, l’autoshutdown via l’arrêt automatique des ressources la nuit et les week-ends sur les environnements de hors production ou encore la souscription aux modèles de facturation avantageux – mais impliquant un engagement sur la durée (Reserved Instance, Savings Plans sur AWS à titre d’exemple) – ainsi qu’une utilisation des ressources Spot sur des cas d’usage moins critiques tels que les batchs.
