Qu'est-ce qui est différent / meilleur entre DSC et les scripts «réguliers»?

J'ai regardé une vidéo sur ITPro.tv sur PowerShell Desired State Configuration DSC . Ils l'introduisent et exécutent efficacement un script. Cependant, c'était aussi leur première (vraie) introduction du script, donc je n'ai pas fait la différence entre DSC et le script normal. J'ai déjà fait des scripts réguliers auparavant, et peut-être qu'ils n'avaient tout simplement pas un si bon exemple; il semblait qu'un script normal pourrait installer un rôle / fonctionnalité et copier très bien certains fichiers. Je n'ai pas vu l'avantage pour DSC par rapport à un simple script. Mis à part une machine capable d'interroger pour une sorte de changements, qu'ils ne couvraient pas en pratique, juste en théorie.

Quels sont les avantages de DSC par rapport aux scripts traditionnels; par exemple "installer le rôle, copier le fichier"?

• Avec PowerShell, vous pouvez vous connecter à des machines distantes et leur dire de faire des choses, donc ce n'est pas exclusif à DSC.
• Avec DSC, il semble que vous effectuez une sorte de compilation pour créer un fichier mof, puis vous l'exécutez à partir du shell après le script, ce qui semble être une étape inutile.
• La vue d'ensemble MSDN se lit comme une vue d'ensemble de PowerShell, et je ne vois pas les caractéristiques de différenciation.

Comme vous l'avez dit, vous pouvez faire à peu près tout ce que vous feriez avec DSC, avec du code PowerShell simple.

Mais, DSC est tout au sujet de la gestion de configuration.

La gestion de la configuration concerne les modèles et les pratiques d'utilisation du code et de divers systèmes pour garantir qu'un système est dans un état spécifique. Réf 1 2

Une chose importante à propos de la gestion de la configuration est l'idempotence. Cela signifie que le code décrivant votre système dans le système de gestion de la configuration sera vérifié et exécuté régulièrement sur votre système. Beaucoup de scripts de base ne sont pas bien conçus et feront ce qu'il faut la première fois que vous l'utiliserez pour configurer un système, mais la prochaine fois ils feront des erreurs, dupliqueront des choses, etc. Idéalement, les systèmes de gestion de la configuration résumeront une grande partie du code de test et de vérification d'état que vous devez ajouter manuellement dans un script, pour rendre votre script idempotent.

Une autre chose importante à propos de DSC et de nombreux autres systèmes de gestion de configuration est de créer des ressources réutilisables qui font réellement le travail qui peuvent être partagées avec n'importe qui et tout le monde dans le monde. De cette façon, votre «configuration» ne devrait être que les quelques détails spécifiques à votre environnement. Cela signifie également que vous devriez avoir besoin d'écrire beaucoup moins de code, car vous pouvez réutiliser des choses qui ont été utilisées et vérifiées par de nombreuses autres personnes.

J'ai inclus quelques liens ci-dessus, mais il existe de nombreux bons sites Web sur Internet sur la théorie des systèmes de gestion de configuration. La théorie générale s'applique à tous les systèmes de gestion de configuration (marionnette, chef, dsc, ansible, etc.), cela vaut certainement la peine d'être appris et utile dans la plupart des environnements.

Je vous suggère de jeter un œil à https://docs.microsoft.com/en-us/powershell/dsc/dscforengineers#i-have-powershell-why-do-i-need-desired-state-configuration .

Je fais des devops en tant que chef de projet C # depuis bien avant qu'on ne l'appelle ainsi. J'ai écrit des dizaines de ces scripts de «configuration d'un partage», de «création d'une application dans IIS» et de «vérification si IIS Rewrite est installé». On me demande généralement de le faire par quelqu'un qui pense "Ce n'est qu'une ligne de code pour faire X." Mais que se passe-t-il si la chose existe déjà? Que se passe-t-il si les étapes 1,3 existent déjà mais 2,4 pas, ou l'étape 2 (disons un pool d'applications IIS) n'est pas configurée exactement comme la dernière fois?

Oui, DSC vous oblige à nommer chaque "partie" du script. Ce qui semble fastidieux au premier abord. Mais si vous ne le nommez pas, le moteur DSC et les fournisseurs ne peuvent pas vous dire quelle partie du script prend trop de temps ou quelle partie du script échoue.

Si vous utilisez des dossiers, IIS, le déploiement d'applications ou les fonctionnalités Windows, je vous recommande fortement d'investir quelques jours dans l'apprentissage de DSC.