CONCOURS INTERNE DE TECHNICIEN DE CLASSE NORMALE DES SYSTEMES

D’INFORMATION ET DE COMMUNICATION

- SESSION 2017 -

Mardi 12 septembre 2017

Option « solutions logicielles et systèmes d’information »

Traitement de questions et résolution de cas pratiques, à partir d’un dossier, portant sur l’une des deux options suivantes choisies par le candidat le jour de l’épreuve :

- infrastructures et réseaux, - solutions logicielles et systèmes d’information. Cette épreuve permet d’évaluer le niveau de connaissances du candidat, sa capacité à

les ordonner pour proposer des solutions techniques pertinentes et à les argumenter.

Le dossier ne peut excéder 20 pages.

(Durée : 3 heures – Coefficient 2)

Le dossier documentaire comporte 19 pages.

IMPORTANT

IL EST RAPPELE AUX CANDIDATS QU’AUCUN SIGNE DISTINCTIF NE DOIT APPARAITRE NI SUR LA COPIE NI SUR LES INTERCALAIRES.

ECRIRE EN NOIR OU EN BLEU - PAS D’AUTRE COULEUR

SUJET

QUESTIONS

Les réponses devront être rédigées. L'ensemble des questions sera noté sur 10 points.

Question 1 : Qu'est-ce que la base de registre dans le système d'exploitation Windows ?

Question 2 : Qu’est-ce que le S.Q.L. ?

Question 3 : Qu'est-ce que la virtualisation ?

Question 4 : Que signifie l'acronyme D.M.Z. ?

Question 5 : Quelle est la différence entre un client lourd et un client léger ?

Question 6 : Qu'est-ce qu'un test unitaire ?

Question 7 : Ecrire le pseudo-code de l’algorithme du tri à bulle d’un tableau d’entier T.

Question 8 : Quelle est la durée de fonctionnement nominale d’un système dont la disponibilité estde 99,99 % pour une période de 8760 heures ?

Question 9 : Quelle est la différence entre un forum et une F.A.Q. ?

Question 10 : Que signifie l’acronyme L.A.M.P. ?

CAS PRATIQUE

Vous êtes affecté.e à la Direction des Systèmes d’Information et de Communication (DSIC) duMinistère de l’Intérieur, dans une équipe d'exploitation de la Sous-Direction de la Supervision et dela Production (SDSP).

L'équipe de sous-direction de la SDSP souhaite ajouter au catalogue des prestations des services de la DSIC une offre CAAS (Container As A Service) basée sur Docker. Pour cette raison, elle examine les impacts internes qu’aurait l'ouverture d'une telle offre.Sous la responsabilité d'un.e chef.fe de projet, il vous est demandé d'être l'administrateur.rice système référent.e sur le sujet.

Cas 1 : (5 points)

C'est dans ce contexte que votre chef.fe de projet doit présenter brièvement à l'équipe de la SDSP les impacts sur les services d'exploitation ; elle/il vous demande de répondre sous forme d'un développement structuré, aux questions suivantes :

• Qu'est-ce que Docker ?• Présenter sa mise en œuvre au sein d'une section d'exploitation de la DSIC.

Cas 2 : (5 points)

Afin de préparer la réunion de cadrage du projet d'ouverture d'une offre CAAS par la SDSP, votrechef.fe de projet vous demande de lui adresser un argumentaire structuré détaillant les pointsimportants conditionnant la réussite du projet en répondant aux questions suivantes :

• Dans la démarche projet engagée, quels sont les principaux jalons concernés ?• Ce projet est-il impacté par les bonnes pratiques de la sécurité des systèmes

d'information ?

Dossier documentaire :

Document 1

DevOps et ITIL sont-ils conciliables ?http://www.hardis-group.com/actualites/devops-et-itil-sont-ils-conciliables 31/05/2017 – Maxime ORAND

Pages 1 à 3

Document 2

Docker : ce qu'il faut savoirhttp://www.journaldunet.com/solutions/cloud-computing/1146290-cloud-pourquoi-docker-peut-tout-changer/ 09/05/17 – JDN, Antoine CROCHET-DAMAIS

Pages 4 à 8

Document 3

START-UP : COMMENT MONITORER UNE INFRASTRUCTURE DOCKERhttp://blog.d2-si.fr/2016/10/03/monitoring-docker-infrastructure/ 03/10/2017 – Benoît POURRE

Pages 9 à 15

Document 4Docker est-il fiable et sécurisé ?http://www.kbcrawl.com/actualites/actualite/docker-fiable-securise/ 27/03/2017 – JDN, KB CRAWL SAS

Pages 16 à 18

Document 5Les principaux jalons de la conduite de projetFrise de la démarche projet DSIC.15/11/2011 – SG/DSIC/SGSIC/BP

Page 19

Document 1http://www.hardis-group.com/actualites/devops-et-itil-sont-ils-conciliables

DevOps et ITIL sont-ils conciliables ?31/05/2017 | Maxime Orand

Avis d'expert par Maxime Orand, Consultant, Hardis Group

Ce n'est pas nouveau, lorsqu'une nouvelle approche apparaît, il est tentant de faire table rasedu passé. Pourtant, la bonne approche à moyen terme, est plutôt de prendre le meilleur dechaque méthodologie. En effet, DevOps et ITIL ont tout pour favoriser une gestion efficacedes développements et de l'exploitation, sans sacrifier ni la rigueur et ni la créativité.

DevOps vs ITIL : une question complexe

Tel un clivage politique, les avis sont souvent assez tranchés quant à la compatibilité – oul'incompatibilité – entre les méthodes agiles, et notamment DevOps et ITIL. La question estpertinente, d'autant plus que chaque méthodologie ne tire pas sa source des mêmes enjeux, et doncdes mêmes équipes : ITIL est ainsi issue du monde de l'exploitation, tandis que agilité et DevOpspuisent leur inspiration du côté du développement. Et les arguments, pas toujours inspirés de labonne foi, ne manquent pas pour les opposer : agile vs statique ou encore rapidité vs lenteur (auprofit de la stabilité). Mais la réalité est, dans les faits, beaucoup plus complexe.

Inutile de ménager le suspense : oui, DevOps et ITIL sont compatibles. Car bien que leursapproches respectives soient clairement différentes, ces méthodologies ont toutes deux pour objectifla mise en œuvre de bonnes pratiques. Différentes certes, contradictoires, certainement pas. Inutiledonc de choisir entre les deux. Pour autant, et afin de concilier les deux dans le cadre d'un processusglobal de gestion efficace des développements et de l'exploitation, rigueur et créativité ne seront pasde trop. Et seront même les conditions de base pour surmonter les écarts en termes de vision et depratiques.

Le décalage temporel n'est, lui-aussi, pas à sous-estimer : ITIL, imaginé pour combler l'absence deprocessus formels de gestion du cycle de vie des applications, a largement été diffusé dans ladernière décennie. À l'opposé, beaucoup considèrent DevOps comme une "simple" extension del'agilité aux tâches d'exploitation, qu'il suffit d'imposer aux équipes qui en ont la charge. Mais dansles faits, ITIL étant déjà largement diffusée, la mise en place de DevOps devra prendre en comptecette base, qui est loin de ne comporter que des inconvénients.

Dès lors, concilier DevOps et ITIL consistera donc à injecter l'agilité proposée par DevOps dansl'exploitation, tout en capitalisant sur les processus et la traçabilité imposés par ITIL. Dans saversion 3, ITIL introduit d'ailleurs la notion d'amélioration continue et une approche globale ducycle de vie d'un système pour répondre aux besoins métiers. Ce qui renvoie à la notion d'itérationdes méthodes agiles. Le défi repose donc sur la fréquence des changements et la communicationtransverse. En bref, DevOps doit challenger ITIL, tandis qu'ITIL permet d'encadrer DevOps.

1

Transition des services : DevOps, complémentaire à la gestion des changements

En termes d'exploitation, la gestion des changements vise à répondre aux besoins d'évolutions, touten minimisant le risque de nuisance pour l'utilisateur : régression, indisponibilité, etc. Leschangements doivent être évalués, autorisés, enregistrés puis planifiés pour répondre à des objectifsde stabilité, de traçabilité (versions, configurations) et de prédictibilité. La valeur ajoutée immédiateest d'imposer un cadre aux changements dans une organisation peu mature, et permettre de donnerune image précise à un instant T du système.

Si la perception initiale peut être négative (lourdeur et lenteur du processus), elle est indispensable àla chasse aux changements sauvages. Et si le travail de modélisation a été correctement réalisé enamont, le processus ne sera pas plus lent ou lourd : il sera encadré et la réactivité sera au rendez-vous. Concrètement, cela signifie qu'il est essentiel de définir des processus d'approbation enfonction du type de changement, du risque associé et de sa criticité : ce qui favorise la réactivité encas d'urgence, et le formalisme dans tous les cas. Ces processus formels permettent en outred'imposer un feedback systématique sur les changements effectués, dans une logique d'améliorationcontinue.

Bien sûr, les tâches aboutissant à la création d'une demande de changement, de même que leur miseen œuvre, peuvent être automatisées sans remettre en cause le fait que les changements doiventpasser par un comité d'approbation. En d'autres termes, les tâches évoluent, mais la méthoded'évaluation ne change pas. Et pour être tout à fait en phase avec DevOps, le comité d'approbationdoit privilégier la communication transverse et les décisions collégiales.

Exploitation des services : la gestion des incidents, complémentaire à DevOps

Les organisations agiles et DevOps sont généralement définies pour répondre aux impératifs delivraison de nouvelles fonctionnalités. On peut parler de cas de travail "nominal". Mais, en dehorsdu support, on y trouve très rarement d'équipe dédiée à la gestion des problèmes en production. Etlorsque le cas de figure se présente, il est souvent difficile de suivre une méthode pré-établied'analyse, d'escalade et de résolution. Les itérations courtes ne sont en effet pas conçues pour laprise en compte et la gestion de nouveaux problèmes à diagnostiquer.

C'est, a contrario, le cas d'ITIL, qui sait répondre à ce cas de figure, en définissant une organisationet des processus capables de gérer au mieux les aléas liés à la gestion des problèmes et desincidents. Les rôles y sont définis, des règles de priorisation aussi. Ce qui n'est en rien incompatibleavec une organisation agile. Ainsi, dans une logique d'amélioration continue, les processus ITILvont nourrir les tâches DevOps. En premier lieu par l'enrichissement du monitoring sur un périmètrecomplet, de l'infrastructure aux cas métiers. Par l'automatisation des opérations de contournementsur incident ensuite, ainsi que par l'adjonction des cas de tests automatisés.

2

Pour mettre en place cette mécanique, la création d'un processus de remontée d'informations entrel'exploitation et la R&D est essentielle. Ce qui se traduit concrètement par des processus d'escalade,une méthode de gestion de crise et un back log partagé intégrant l'occurrence des incidents, afin depouvoir adapter la priorisation de leur correction. Un dispositif qui ne sera efficace qu'à la conditionde pouvoir mobiliser les équipes R&D quand cela est nécessaire : développeurs, testeurs et DevOpsdoivent ainsi pouvoir disposer de temps dédiés à ces sujets, en fonction des événements survenanten production. Dès lors, ITIL et DevOps pourront non seulement cohabiter, mais aussi et surtout secompléter l'un l'autre.

3

Document 2http://www.journaldunet.com/solutions/cloud-computing/1146290-cloud-pourquoi-docker-peut-tout-changer/

Docker : ce qu'il faut savoirAntoine Crochet- Damais

JDN

Mis à jour le 09/05/17 12:00

Docker vient bousculer le modèle, jusqu'ici fermé, des grands clouds. Il pourrait permettre en

effet de basculer une application entre les clouds d'Amazon, Google et Microsoft.

1 – Comment résumer ce qu'est Docker ?

Docker permet d'embarquer une application dans un container virtuel qui pourra s'exécuter surn'importe quel machine. D'abord optimisé pour Linux, il l'est désormais pour Windows Server. C'estune technologie qui a pour but de faciliter les déploiements d'application, et la gestion dudimensionnement de l'infrastructure sous-jacente. Elle est en partie proposée en open source (souslicence Apache 2.0) par une société américaine, également appelée Docker, qui a été lancée par unFrançais : Solomon Hykes.

2 – Quelle différence avec la virtualisation traditionnelle ?

La virtualisation traditionnelle permet, via un hyperviseur, de simuler une ou plusieurs machinesphysiques, et les exécuter sous forme de machines virtuelles (VM) sur un serveur ou un terminal.Ces VM intègrent elles-mêmes un OS sur lequel les applications qu'elles contiennent sontexécutées. Ce n'est pas le cas du container. Le container fait en effet directement appel à l'OS de samachine hôte pour réaliser ses appels système et exécuter ses applications. Historiquement, Dockerrepose sur le format de containers Linux, alias LXC. Il l'étend par le biais d'une API dans l'optiqued'exécuter les applications dans des containers standards, qui sont donc portables d'un serveur Linuxà l'autre.

3 – Quels sont donc les avantages de Docker comparé à la virtualisation ?

Comme le container n'embarque pas d'OS, à la différence de la machine virtuelle, il est parconséquent beaucoup plus léger que cette dernière. Il n'a pas besoin d'activer un second systèmepour exécuter ses applications. Cela se traduit par un lancement beaucoup plus rapide, mais aussipar la capacité à migrer plus facilement un container (du fait de son faible poids) d'une machinephysique à l'autre. Autre avantage : les containers Docker, du fait de leur légèreté, sont portables decloud en cloud. Seule condition : que les clouds en présence soient optimisés pour les accueillir. Etc'est désormais le cas des principaux d'entre eux :Amazon Web Services, Microsoft Azure, GoogleCloud Platform, OVH... Qu'est-ce que cela veut dire ? Eh bien qu'un conteneur Docker, avec sesapplications, pourra passer aisément d'un de ses clouds à un autre.

4

4 – Quels sont les grands scénarios dans lesquels Docker apporte une valeur ajoutée aux développeurs ?

D'abord, Docker accélère les déploiements. Pourquoi ? Parce que les containers Docker sont légers.Les basculer d'un environnement de développement ou de test à un environnement de productionpeut donc se faire presque en un clic, ce qui n'est pas le cas pour la VM, plus lourde. Du fait de ladisparition de l'OS intermédiaire des VM, les développeurs bénéficient aussi d'une pile applicativeplus proche de celle de l'environnement de production, ce qui engendre mécaniquement moins demauvaises surprises lors des passages en production. Docker pourra permettre dans le même tempsde concevoir une architecture de test plus agile, chaque container de test pouvant intégrer unebrique de l'application (base de données, langages, composants...). Pour tester une nouvelle versiond'une brique, il suffira d'inter changer le container correspondant. Enfin côté déploiement continu,Docker présente un intérêt car il permet de limiter les mises à jour au delta du container nécessitantde l'être.

5 – Qu'en est-il des avantages côté production ?

Grâce à Docker, il est possible de containériser une application, avec pour chaque couche descontainers isolant ses composants. C'est le concept d'architecture de microservices. Ces containersde composant, du fait de leur légèreté, peuvent eux-mêmes, chacun, reposer sur les ressourcesmachines voulues. "Pour parvenir au même résultat, les outils de virtualisation ont besoin d'un poolde VM inactives provisionnées à l'avance", rappelle-t-on chez Docker. Avec Docker, nul besoin depool, puisqu'un container est bootable en quelques secondes. Mais, la promesse de Docker va plusloin. Car les containers Docker étant portables d'une infrastructure à l'autre, il devient possibled'imaginer de réaliser du mirroring d'application et de l'équilibrage de charge entre clouds, etpourquoi pas des plans de reprise ou continuité d'activité entre clouds... voire même décider de lareprise d'un projet par un autre fournisseur cloud.

6 – La technologie Docker est-elle capable de passer à l'échelle sur des architectures en grappe ?

Pour gérer une architecture de containers en cluster, Docker a développé Swarm. L'enjeu : étendrela portabilité, au-delà d'un container unitaire, à toute une architecture de containers en cluster.Docker a parallèlement introduit dans son orchestrateur tous les processus nécessaires à laproduction à grande échelle (équilibrage de charge, gestion de la résilience, du chiffrement destransactions entre les nœuds...).

Mais en matière de performance, la société de San Francisco veut aller encore plus loin. Elle aacquis début 2016 la start-up Conductant qui s'est illustrée dans le développement d'Apache Aurora.Un système de clustering qui est conçu pour gérer des applications atteignant des centaines demillions d'utilisateurs. Toujours pour faciliter le déploiement des architectures en container, Dockerpropose, aussi, une console graphique de pilotage (Docker Universal Control Plane) et des outils desécurité (notamment Trusted Registry, ou Docker Secrets qui gère l'intégrité d'un container tout aulong de son cycle de vie). Toutes ces briques s'inscrivent dans une plateforme dite de Containers asa Service (CaaS), baptisée Docker Datacenter (DDC), visant à assurer le pilotage complet d'uncloud orienté containers (en recouvrant les processus de build, ship et run). Enfin, Docker a aussiacquis fin 2014 la plateforme cloud Tutum : un environnement SaaS conçu pour piloter ledéploiement d'applications containerisées sur divers clouds publics (Microsoft Azure, DigitalOcean, Amazon Web Services et IBM SoftLayer).

5

7 – Existe-t-il des benchmark entre Docker et les technologies de virtualisation classiques, et quels sont leurs enseignements ?

Oui. IBM notamment a réalisé un comparatif de performance entre Docker et KVM. Sa conclusionest sans appel : Docker égale ou excède les performances de cette technologie de virtualisation opensource - et ce dans tous les cas testés dans le cadre du comparatif. Pour Big Blue, la performancedes containers Docker se rapproche même de celle des serveurs machines nus. En éliminant lacouche de virtualisation, consommatrice en ressources machines, Docker permettrait de réduire laconsommation de RAM de 4 à 30 fois.

8 – Quelles sont les limites de la technologie Docker ?

Initialement limité à Linux, Docker a depuis été porté sur Windows dans le cadre de WindowsServer 2016. Cette annonce fait suite à un partenariat signé par Docker avec Microsoft. Il n'en restepas moins que les containers créés sur Linux, ne pourront être portables sur Windows, etréciproquement. Il s'agit là de la limite majeure de Docker, et sa principale différence avec lavirtualisation traditionnelle. Une machine virtuelle embarquant Linux peut en effet tourner sur unserveur Windows, et inversement.

9 – Au-delà des serveurs, les containers Docker peuvent-ils être utilisés sur des terminaux ou objets connectés ?

La réponse est oui. Docker propose depuis longtemps des outils permettant aux développeurs demanipuler des containers et tester des architectures containérisées sur leur poste. L'éditeur a aussiannoncé en avril 2017 un kit d'outils open source (baptisé LinuxKit) conçu pour assembler unedistribution Linux à partir de composants systèmes embarqués dans des containers. L'idée est deproposer une architecture modulaire pour bâtir une distribution personnalisée se limitant aux seulsprocessus systèmes nécessaires aux applications. Les avantages ? Etant containérisé, chaquecomposant peut être maintenu indépendamment. L'architecture donne aussi la possibilité de réduireau maximum le nombre de processus, ce qui optimise le poids de l'OS et sa surface d'attaque. Unesolution présentée par Docker comme idéale pour les objets connectés. Le projet LinuxKit a étélancé en lien avec la Fondation Linux et plusieurs acteurs du marché (ARM, HPE, IBM,Intel et Microsoft).

10 – Quid de Docker en matière de sécurité ?

Docker a été très critiqué sur ce plan. LXC [Linux Containers NDLR], sur lequel Docker, repose esten retard sur cet aspect. Il ne permet pas d'isoler les ressources utilisées par des containers basés surla même machine, si bien qu'un container peut très bien cannibaliser la ressource et déstabiliser sesvoisins... Pour répondre à cette critique, Docker a notamment introduit la possibilité d'appliquer unelimite de consommation de ressource pour les containers d'une même machine (avec ulimit).

Toujours dans le but de renforcer la sécurité et l'isolation des containers, le moteur Docker s'estaussi étendu à la prise en charge de dispositifs Linux de bas niveau (comme Seccomp et usernamespace). Fin 2015, Docker a également sortiplusieurs briques commerciales pour renforcer lasécurité des containers : Docker Content Trust (qui permet de certifier l'éditeur d'un container et lecontenu de ce dernier), ainsi qu'un service d'analyse de sécurité et de détection de vulnérabilité dansles images de container (Docker Security Scanning).

6

11 – Quels sont les composants proposés par Docker en open source ?

Docker a publié une dizaine de composants sous licence Apache (voir le graphique ci-dessous). Descomposants qui recouvrent les principales fonctionnalités nécessaires au pilotage d'une architecturecontainérisée : gestion du réseau, du stockage, de la sécurité... Parmi eux figure containerd. Unebrique centrale de la technologie Docker puisqu'elle permet l'exécution du container. Considérant lacriticité de cette brique en vue de la standardisation des offres de container, Docker en a reversé lesdroits à une organisation indépendante (la Cloud Native Computing Foundation). En avril 2017,l'éditeur est allé un peu plus loin dans la démarche en lançant Moby : un framework open sourcedessiné pour construire des systèmes de container. Il comprend 80 composants open source : ceuxde Docker (containerd, swarmkit...) mais aussi d'autres projets (Redis, Nginx...). Moby se veut êtreun projet participatif, à travers lequel tous les acteurs de la communauté Docker construisant dessolutions à base de container peuvent partager des briques.

© Docker

12 – L'unikernel est-ce la même chose qu'un container ?

Non. L'unikernel se situe à mi-chemin entre la virtualisation serveur classique et le container. Alorsque la virtualisation traditionnelle reprend l'intégralité de l'OS serveur dans la machine virtuelle,l'unikernel n'embarque, lui, dans la VM que les librairies du système nécessaires à l'exécution del'application qu'elle contient. Le noyau de l'OS restant lui en dehors de la machine. A la différencedu container Docker, l'unikernel reprend donc une partie de l'OS dans la VM.

Parmi ses principaux avantages comparé au container, l'unikernel peut permettre d'optimiser lacouche système embarquée dans la VM aux spécificités de l'application à exécuter. En janvier 2015,Docker a acquis la société Unikernel Systems, une start-up spécialisée dans l'unikernel, dansl'optique de proposer une alternative à ses containers.

7

13 – Historiquement, les containers Docker se créent et se manipulent en lignes de commande. Docker propose-t-il sur un interface de gestion graphique ?

La réponse est oui. C'est l'objet du rachat de Kitematic début 2015. Cette société apporte à Dockerune solution graphique de gestion de containers. Cette nouvelle brique pourrait se révéler assezstratégique pour Docker. A la manière de PHPMyAdmin et WampServer en leur temps pour lapile LAMP, elle pourrait permettre en effet de démocratiser sa technologie.

14 – Par où commencer un projet de déploiement de Docker ?

La communauté des utilisateurs de Docker commence à être importante, même si sa taille restedifficile à évaluer. Il existe une documentation fournie portant sur cette technologie open source surle web. Rien que sur StackOverFlow, plusieurs milliers de pages lui sont consacrées. La société metpart ailleurs à la disposition des utilisateurs un service, baptisé le Docker Hub, conçu permettrel'échange et le build de containers Docker pré paramétrés. Hébergeant plus de 460 000 images decontainer (avec Ubuntu, WordPress, MySQL, NodeJS...), cet espace est aussi intégré à GitHub.Docker commercialise par ailleurs une version on-premise du Docker Hub (le Docker HubEnterprise). Enfin, Docker a lancé une boutique en ligne d'applications. Objectif : offrir aux éditeursun canal commercial pour distribuer leurs applications sous forme de containers.

8

Document 3http://blog.d2-si.fr/2016/10/03/monitoring-docker-infrastructure/

START–UP : COMMENT MONITORER UNE INFRASTRUCTURE DOCKER• 3 octobre 2016

• Benoît Pourre

•Experts D2SI, Paroles d'expert

Dans un article précédent, nous avons vu comment Docker et Docker Swarm peuvent

simplifier la création d’une infrastructure scalable et adaptée aux nouveaux usages. Nous

allons maintenant voir comment monitorer et comment gérer les logs sur ce nouveau type

d’infrastructure, dans le contexte d’une startup., et comment répondre aux nouvelles

contraintes posées par ce type d’infrastructure.

Comment monitorer une infrastructure conteneurisée ?

Le monitoring fait partie des services indispensables d’une infrastructure. Il permet de détecter lesincidents, mais aussi de les anticiper pour éviter tout arrêt de service. Véritable couteau suisse, lemonitoring permet aussi de débugguer une application, collecter des métriques, en tirer desgraphiques, faire du reporting et du capacity planning. On l’utilise aussi bien en production que surtous les environnements de DEV / UAT / etc…

9

Que cherchons nous à monitorer ?Le premier réflexe en termes de monitoring, c’est de monitorer la machine et le système : parexemple collecter des métriques sur le CPU, la RAM, le Swap, les IOs disque et réseau, l’espacedisque.Ensuite, on va monitorer les middlewares et bases de données. En général ces solutions fournissentsoit des APIs, soit des outils en ligne de commande pour récupérer différentes métriques internesqui nous permettent de déterminer la santé de l’application.

Pour les applications, cela dépend :

• Si c’est un web service ou une application web, on va monitorer son URL, son temps deréponse. Dans certains cas, le web service fournit une URL spécifique pour récupérer l’auto-diagnostic de l’application, voire des métriques.

• Si c’est une application non HTTP, on va monitorer les process, utiliser des scripts dediagnostic.

• Parfois, on monitore tout ce qui se passe dans les logs.

Enfin, on va avoir des applications qui exécutent des jobs. Ces applications génèrent desévénements comme par exemple un message de succès ou d’échec d’une exécution d’un job desauvegarde. Ces événements sont très importants, il faut les collecter dans le service de monitoring.Cela peut se faire en pull via de la lecture de logs, ou en push vers l’API de monitoring.

Tout cela peut permettre de savoir si une application fonctionne ou non. En revanche cela ne donnepas un état de santé d’un cluster par exemple.

Il existe aussi des solutions de monitoring applicatif (New Relic par exemple) capablesd’enregistrer chaque transaction et ses performances, depuis l’application vers sa base de donnéespar exemple. Nous n’aborderons pas ce sujet ici.

10

Comment faisions-nous jusqu’à maintenant ?

Jusqu’à maintenant, on installait des agents (Nagios, Zabbix, Centreon, Patrol, etc…) sur chaqueserveur physique ou virtuel, voire sur les équipements réseau. On monitorait aisément les ressourceshardware et les applications hébergées.

Et maintenant, avec la conteneurisation ?

Pour les applications conteneurisées sur un cluster Swarm (par exemple) on va avoir de nouvellescontraintes :

• On ne sait pas à l’avance sur quel hôte Docker Engine va être déployé le conteneur• On ne connaît pas à l’avance son IP, et elle est par défaut dynamique• Le noms DNS des conteneurs ne sont pas visibles depuis l’hôte. Le mécanisme est interne à

Docker• S’il est dans un réseau Docker privé (Bridge, Link, Overlay), l’application ne sera pas

accessible par l’agent de l’hôte• Le conteneur peut être re-schedulé sur un autre Docker Engine en cas d’incident sur l’hôte• On souhaite avoir les métriques système de chaque hôte, mais aussi de chaque Docker• On ne va pas mettre un agent de monitoring dans chaque conteneur.

En résumé, on ne va pas pouvoir avoir de configuration de monitoring statique pour chaque serveur,et l’agent ne va pas forcément pouvoir accéder à l’application via le réseau.

Mais alors, comment fait-on ?

Pour monitorer notre nouvelle architecture, nous allons par exemple :

• Déployer un agent sur l’hôte pour les métriques OS, hardware et les métriques Docker surchaque conteneur via l’API de Docker Engine.

• Déployer un conteneur agent de monitoring par réseau Docker privé, ou service Docker. Ceconteneur se chargera de monitorer l’application via le réseau privé et pourra utiliser lesnoms DNS Docker de chaque conteneur (base de donnée, web service, cache, etc…).

11

On constate donc que les métriques liées à une application (métriques du/des conteneurs del’application et métrique de l’application même) vont être remontées par plusieurs agents. Il fautdonc avoir une solution qui facilite la corrélation et l’agrégation de ces métriques.

Les anciennes solutions open source ou propriétaires ne savent répondre à ce besoin. Il faut donc setourner vers les nouvelles solutions telles que DatadogHQ, Sematext, NewRelic, SysDigCloud, Prometheus, Sensu.

Dans le cadre du Kit Startup, nous avons choisi DatadogHQ pour les raisons suivantes :

• Version gratuite pour monitorer 5 serveurs• Collecte des métriques OS et Docker Engine• Collecte des Events Docker• Version Docker de l’agent• Très bonne intégration avec l’écosystème DevOps (Slack, PagerDuty, CI/CD)• Nombreux produits du marché supportés• Dashboards pré-configurés• Facile à installer• Agrégation et corrélation des métriques grâce aux tags• Bonne gestion des alertes• API de configuration et module Ansible pour l’API

Nous lui avons trouvé un petit défaut, c’est la gestion de configuration. En effet, la configurationdes paramètres des checks de monitoring se fait dans un seul fichier par type de check. Par exemple,si on a plusieurs web services HTTP à monitorer, on doit tous les configurer dans un seul fichier.C’est assez pénible à industrialiser correctement afin de gérer l’ajout, la suppression, lamodification d’un check parmis les autres dans le même fichier. Sensu répond très bien à cetteproblématique car on peut faire un fichier par check, ce qui est beaucoup plus simple à gérer avecun outil de gestion de configuration.

12

Gestion des logs

Toute application se doit de générer des logs. Les logs contiennent toutes les informationsindispensables sur l’exécution d’une application. On retrouvera par exemple les erreurs d’exécution,les warnings, des informations sur ce que fait l’application, qui l’utilise, les tentatives ratéesd’authentification. Ces informations sont précieuses pour les développeurs, comme les Ops, lesupport, mais aussi pour la sécurité.

Le fait d’avoir une architecture dynamique change la façon dont on gère les logs. Encore une fois,chaque conteneur peut être instancié n’importe où sur le cluster Docker Swarm. On ne peux doncpas déterminer à l’avance où collecter les logs applicatifs. De plus, l’application va probablementêtre instanciée plusieurs fois sur le cluster afin de supporter la charge et faire de la hautedisponibilité.

On se rend rapidement compte qu’il va être difficile d’aller consulter chaque fichier de log dechaque conteneur, un par un pour trouver une trace d’erreur ou analyser le trafic.

Heureusement il existe de nombreuses solutions pour collecter et rendre exploitables vos logs :

• Logguer classiquement dans des fichiers texte stockés dans des volumes Docker.

• Logguer directement sur les sorties standard du conteneur. Elles sont lues par Docker Engineet consignées dans un fichier Json. Nous déconseillons cette solution en production car il n’ya pas de rotation et compression des logs, ni de limite de taille. De plus, si on a plusieursinstances du conteneur, il faut consulter les logs de chaque conteneur. Nous réservons cettesolution pour les développements et les tests. De plus, cette méthode fonctionne aisémentdans des conteneurs mono process, mais pas quand on fait tourner 2 applications dans lemême conteneur. Par exemple, un container qui contient Nginx et PHP en même temps.

13

• Utiliser un plugin Docker de logging pour envoyer les logs vers Splunk, Elasticsearch ouGraylog. Attention, la problématique précédente sur le multi-process dans le mêmeconteneur reste la même.

• Soit adapter l’application pour envoyer les logs directement par le réseau (HTTP parexemple) à un des outils de gestion de logs cités ci-dessus, sans passer par Docker.

Le choix se fera en fonction des capacités de logging de l’application. On pourra évidementmélanger les 4 méthodes ci-dessus.

L’avantage des deux dernières solutions, c’est que l’on va pouvoir collecter les logs de nosconteneurs.

14

En revanche, il est fortement déconseillé d’écrire les logs dans un fichier, dans le conteneur sanspasser par un volume Docker.

En effet, on risque d’avoir des problèmes de performances sur les I/Os disque, mais surtout les logsne seront pas directement exploitables depuis l’extérieur du conteneur. Il est plus que recommandéde ne pas stocker les données variables d’une application dans le conteneur. Les volumes Dockersont là pour répondre à ce besoin.

Dans le Kit Startup, nous utiliserons par exemple le PaaS Logs d’OVH pour que le démon DockerEngine envoie par défaut les logs sur le service ElasticSearch / Kibana / Graylog d’OVH.

Pour aller plus loin, nous vous conseillons de vous référer à ces exemples de configuration pourrécupérer les logs de différents outils.

Conclusion

Nous venons de voir différentes pistes adaptées aux startups afin de monitorer et gérer correctementles logs. Nous avons vu que la conteneurisation, la distribution des applications sur les clusters, lesréseaux virtuels Docker, imposent de radicalement changer notre approche, voire les outils, afind’être capable à tout moment d’anticiper ou détecter des incidents, mais aussi de les diagnostiquerde manière efficace. Dans notre prochain article, nous étudierons différentes stratégies desauvegarde, et nous donnerons des conseils pour gérer la restauration des données ou del’infrastructure complète.

15

Document 4http://www.kbcrawl.com/actualites/actualite/docker-fiable-securise/

Docker est-il fiable et sécurisé ?En raison de sa jeunesse et de son succès, la techno des containers est régulièrement attaquée sur leterrain de la sécurité et de la performance. Qu’en est-il quatre ans après son lancement ?

Depuis mars 2013 et le lancement de sa première version, le succès de Docker ne s’est jamaisdémenti. Cette technologie de container logiciel encapsule une application pour qu’elle puisses’exécuter sur n’importe quel serveur en faisant abstraction des couches inférieures. Un bol d’airdans le monde fermé des clouds publics. Selon le baromètre 2017 de RightScale, Docker est utilisépar 35% des adeptes du DevOps pour motoriser leur processus, contre 27% un an plus tôt. Son tauxde pénétration se hisse même à 40% chez les grands comptes.

En France, Silca, GIE informatique du Crédit Agricole, ou Ingenico, société spécialisée dans lesmoyens de paiement, ont déployé des containers Docker. C’est également le cas chez PSA. « Quede grandes structures évoluant sur des activités sensibles, et donc soumises à d’importantescontraintes en termes de sécurité, choisissent cette voie est un gage de confiance », estime AlexisHorgix Chotard, consultant DevOps chez Xebia, un cabinet spécialisé dans la technologie Docker etorganisateur du Paris Container Day.

Pourtant, compte tenu de sa jeunesse, Docker fait régulièrement l’objet de critiques sur sesperformances ou sa vulnérabilité aux failles de sécurité. Dans une autre étude conduite parDevOps.com et ClusterHQ (remontant à 2015), environ 60 % des personnes interrogées citaient lasécurité comme principal obstacle à l’utilisation des conteneurs en production. Suivaient la gestiondes données, les problématiques réseaux et la prise en compte du stockage persistant.

Une version pour rassurer les grands comptes

Pour Hervé Leclerc, CTO d’Alter Way, la question de la sécurité de Docker est posée sous lemauvais angle. « Docker exprime des besoins simples. Une fois qu’on lui a fixé les règles, ils’occupe de toute la plomberie, y compris la sécurité. Cette approche désarçonne les administrateurssystèmes et les responsables de la sécurité qui essaient de reproduire les schémas classiques qu’ilsappliquent depuis des années », explique l’expert. Selon Hervé Leclerc, il s’agit d’abord d’appliquerles bonnes pratiques en matière de sécurité. A cet effet, le Sans Institute a récemment listé tous lespoints à vérifier concernant Docker. « Aller chercher des images publiques au format Docker surinternet présente bien sûr un risque », insiste Hervé Leclerc. 30 % des images présentes sur leDocker Hub, la place de marché de l’éditeur, seraient touchées par des vulnérabilités.

Dans le sillage de l’offre Docker Datacenter, la sortie début mars de la Docker Enterprise Edition(EE) est destinée à rassurer les grandes entreprises. Docker EE propose des outils de gestion decontainers et d’images, une intégration avec les annuaires d’entreprise et un contrôle d’accès parrôle. Sa version « avancée » s’étend, en plus, au scan de sécurité et à la surveillance continue desvulnérabilités. La solution fait l’objet de mises à jour trimestrielles avec un support garanti d’un an.L’introduction de Docker EE est une bonne nouvelle pour Hervé Leclerc. « Les entreprisespouvaient être déstabilisées par le nombre élevé de releases. Là, elles disposeront d’une versionstable et supportée, à l’image d’une distribution Linux », pointe le CTO.

16

Pour donner plus de visibilité à sa feuille de route, Docker a aussi modifié la nomenclature de sesversions. Comme l’indique ce billet, elles sont désormais nommées en fonction du mois et del’année de sortie. Pour la dernière en date, sortie en mars, nous sommes passés de la 1.13.1 à la17.03.

Des gages donnés à la communauté des développeursParallèlement, Docker a fourni des gages à la communauté des développeurs qui lui reprochait dene pas être suffisamment consultée. La start-up a participé, en 2015, à la création de l’Opencontainer initiative. Ce groupement où l’on retrouve Google et Red Hat travaille sur lesspécifications que doivent respecter le format des images ou la gestion du runtime de container.Pour prouver sa bonne foi, Docker vient d’ailleurs de mettre ce dernier (containerd) en open sourceen le confiant à la Cloud native computing foundation comme l’a expliqué Solomon Hykes, sonfondateur, dans un billet.

Des lacunes comblées au fil du temps

Au fil de ces quatre années, Docker a su également faire évoluer sa technologie afin de combler seslacunes. A l’origine, Docker reposait sur LXC (Linux Containers). Problème : ce dernier nepermettait pas d’isoler les ressources machines utilisées par des containers situés sur un mêmeserveur hôte. Un container pouvait contaminer son voisin et faire exploser la consommation deressources. « Ce n’est plus le cas aujourd’hui », note Alexis Chotard. « Les cgroups, désormaisimplémentés dans le Kernel Linux, limitent le nombre de processus. Par défaut, Docker ne va pasimposer de limites en termes de ressources mais, depuis sa version 1.11, il est possible derestreindre cette consommation », note le consultant de Xebia.

La sécurité est, elle, assurée par Seccomp (pour Secure Computing mode) mais aussi par lesmécanismes de protection intrinsèques à Linux via les Linux Security Modules – tels que SELinux(Security-Enhanced Linux) ou AppArmor. Une étude récente de NCC Group reprend le rôle de tousces composants. « Seccomp va filtrer les appels systèmes autorisés à engager un processus »,poursuit Alexis Chotard. « On peut donner une autorisation ou l’enlever et empêcher certainscontainers d’accéder au réseau. »

Le risque d’un goulot d’étranglement réseauUn goulot d’étranglement (bottleneck) réseau peut toutefois apparaître au niveau du Docker proxyqui pilote le réacheminement de port (port mapping). Pour le consultant, il existe cependant despossibilités de contournement. « Les containers peuvent ‘se parler’ directement entre eux via leurIP. Les containers qui doivent, eux, être accessibles de l’extérieur, via le host, peuvent utiliserdirectement la stack réseau du host [option –net=host ndlr] qui n’utilisera donc pas un NetworkNamespace à part, et qui ne passera pas par le docker proxy », détaille Alexis Chotard.

La persistance des données en question

Autre critique régulièrement énoncée : la gestion de la persistance des données. Par nature, Dockersert le déploiement de micro-services et d’applications sans état (stateless). Les containers sontpensés pour être temporaires. Ils peuvent être arrêtés et recrées sur une autre machine hôte. Mais siles applications doivent accéder à une base de données, comment assurer la persistance des donnéesdans un environnement distribué ? Pour Alexis Chotard, trois solutions sont possibles. « On peutesquiver le problème et le déléguer à un fournisseur de cloud en utilisant une base as a service. Sion veut conserver l’hébergement des données en interne, il faudra alors faire appel à des bases quidécoupent les données et les répliquent, comme ElasticSearch. Enfin, si on reste sur des serveurs de

17

données classiques type MySQL, on pourra passer par Rex-Ray, un plugin Docker de Dell EMCpour gérer les volumes distants. » Face à ce dilemme, Uber a construit son propre gestionnaire detopologie de clusters MySQL pour Docker.

La solution pourrait aussi venir de Docker lui-même. En s’offrant en décembre dernier le françaisInfinit, l’éditeur de San Francisco s’est doté d’une technologie de gestion distribuée du stockage.L’intégration de cette brique à son offre pourrait permettre d’apporter une réponse au problème. Desannonces en ce sens pourraient être réalisées lors de la prochaine DockerCon, la conférenceannuelle de l’éditeur qui se tiendra mi-avril à Austin.

Source : www.journaldunet.com – 27/03/2017

18

Document 5

Les principaux jalons de la conduite de projetFrise de la démarche projet DSIC.

15 novembre 2011, SG/DSIC/SGSIC/BP

19