Nano Server: un pas de géant vers DevOps

Lors de l’event //BUILD/ la semaine dernière à San Francisco, Jeffrey Snover et Andrew Mason de Microsoft ont dévoilé une nouveau type de serveur Windows, le Nano Server. Il a une particularité: Il n’y a aucune interface-homme-machine (GUI).

Oui, il y a les versions Core de Windows Server 2008 et 2012 qui peuvent être installées sans un GUI, mais on peut changer d’avis et remettre l’interface Windows. De plus, on peut se connecter à ces machines via RDP, et effectuer des opérations en local. Rien de ceci n’est possible avec Nano Server, car non seulement il n’y a pas de login, il n’y a pas non plus d’outils d’administration en local.

Nano Server est une version avec l’essentiel de Windows Server, et toute la performance d’un serveur ordinaire. Le superflu a été enlevé pour qu’il consomme le moins de place et de ressources possible. Aucun des rôles qu’on ajoute au serveur tels que IIS, AD, DNS etc, ne peuvent être installés tel qu’on le faisait jusqu’à aujourd’hui. Les rôles doivent être ajoutés à partir de packages comme n’importe quelle autre application.

Toute la gestion se fait à travers les composants à distance suivants:

  • Powershell DSC pour la configuration
  • WMI
  • Core Powershell, qui est une version basée sur le CoreCLR de .NET (oui c’est la version Open Source)
  • Portail Web (en remote) pour gérer certaines fonctionnalités telles que le Registry, le Control Panel, le Device Manager, l’Event Viewer, le Task Manager etc. Ce portail pourra gérer les versions « classiques » de Windows Server également.
  • Powershell Package Manager (OneGet) qui permet l’installation d’applications.

L’idée est de toujours passer par un ou des serveurs d’administration qui auront les scripts et les outils nécessaires pour la gestion du parc informatique, ces serveurs applicatifs auront pour rôle d’être le point central pour l’administration à distance d’un ou plusieurs serveurs, y inclus le serveur PULL de Powershell DSC qui sera lui même la clé de voûte de la configuration des machines  :

RemoteAdmin

Et tout ça veut dire beaucoup de scripts, d’automatisation, voire une approche qui s’apparente plus à du développement qu’à de l’administration IT.

Ce qui est important, est que nous sommes témoins d’un changement important dans la l’approche de mise en production et de gestion de serveurs Windows:

Les administrateurs IT devront se mettre au développement de scripts. Et ceci n’est ni une mauvaise chose, ni une nouveauté.

Il y a toujours eu des scripts, mais ces scripts étaient plutôt créés et utilisés si un outil d’administration ne remplissait pas totalement le cahier des charges. Oui, on utilisait des produits tel que SCCM pour le déploiement d’une multitude de machines, Mais dès qu’un problème faisait surface, on se connectait et on traitait les machines affectées de façon unitaire, en effectuant des opérations qui peuvent en modifier la configuration. Et c’est ainsi que petit à petit, on perd la conformité mise en place au début.

Tout ceci manque terriblement d’automatisation. La nouvelle approche Microsoft mets en place les composants nécessaires pour une automatisation du début à la fin du cycle de vie d’un serveur Windows.

Le point de focus n’est plus la machine, mais le(s) script(s) pour configurer la machine. Si le script est robuste, les serveurs le seront tout autant.

Si une machine présente une défaillance, on l’élimine, et on recommence en appliquant les scripts de déploiement et de configuration. L’unité n’est plus importante, le parc dans son ensemble le devient.

Si avec le temps, la machine déployée n’est plus conforme, on peut s’appuyer sur Powershell DSC pour que les réparations soient automatisées, ou éventuellement s’appuyer sur les rapports de conformités pour avoir un état des lieux.

Le monde applicatif a bougé, il s’appuie sur des méthodes de développement tels que Agile qui demandent des déploiements de plus en plus fréquents.

Coté IT, le but ultime reste la stabilité. C’est là que je pense que Powershell est capable de concilier deux mondes par tradition opposés. Car en s’appuyant sur l’automatisation on s’assure de créer et gérer les serveurs requis par les applications, et surtout on s’assure que ces serveurs restent en ligne avec les pré-requis de sécurité et de disponibilité, tout en améliorant les temps de mise à disposition et en réduisant les ressources requises.

A nous de nous assurer que nos serveurs d’infrastructure et nos méthodes répondent aux nouveaux besoins applicatifs, tels que des applications qui naissent et évoluent directement dans les clouds.

Voici le lien vers la session MSIgnite: Nano Server: The Future of Windows Server Starts Now