Cattle vs pets, DSC configdata best practice

This topic contains 2 replies, has 3 voices, and was last updated by  Dave Wyatt 2 years, 4 months ago.

  • Author
    Posts
  • #24730

    David Jones
    Participant

    Every where I go the demo config data that boil down to this.

    (pre)AllNodes =
    @(
    @{
    NodeName = "*"
    LogPath = "C:\Logs"
    },
    @{
    NodeName = "snowball";
    Role = "cat"
    },
    @{
    NodeName = "fifi";
    Role = "dog"
    },
    @{
    NodeName = "rex";
    Role = "cat";
    }
    );(/pre)

    I know that the .mof of a node can be placed on a pull server and re-used, but I don't see a lot of examples of that.

    It just feels like treating a node as a pet. The DSC tools on PowerShell.org's gitgub repo take the opposite.

    Something like

    AllNodes =
    @(
    @{
    NodeName = "*"
    LogPath = "C:\Logs"
    },
    @{
    NodeName = "WebServer01;
    },
    @{
    NodeName = "WebServer02";
    Role = "SQLServer"
    },
    @{
    NodeName = "SQLServer01";
    }
    );
    Services=
    @(
    WebServer = @{
    Nodes = "WebServer01", "WebServer02;
    SiteContents = "C:\Site1"
    SiteName = "Website1"
    },
    SQLServer @{
    Nodes = "SQLServer1";
    }
    );

    This to me feels more like treating servers like cattle.

    How does everyone else feel?

  • #24731

    Don Jones
    Keymaster

    I think you're seeing a couple of things.

    First, nobody outside a cloud-scale environment like Azure is accustomed to thinking of servers as anything but specialized, precious individuals.

    Second, right now there's no built-in tooling. That leads to a couple of things.

    For example, every server is going to have _some_ individualized information – computer name, for example. A lot of us are still trying to hard to keep personalized information that we maybe shouldn't. Consider IP addresses – why not leave everything on DHCP and manage reservations centrally? You remove a "personalized" piece of information. But there'll still be some, and there's still what I think is a habitual need to put all of that into the MOF – which makes them individualized. I think the more we have tooling to track that individualized stuff for us, and then produce the MOFs, the more we'll be able to do that. You think Azure tracks the names of every host they run? Doubtful.

    But DSC itself has to evolve a bit more – and v5 will help – to make this easier. The ability to ingest multiple MOFs (partial configurations) will be a big part of that, because the "individualized" stuff can then be broken out from "standards" stuff a lot more easily.

    But the fact is that most businesses simply don't treat there servers as anything but pets, and they never have. Making that shift – and looking at what's preventing you from doing so, and addressing those things – takes a long time and a lot of breaking-of-habits. It's truly a paradigm shift in the actual sense of that word, and those come slowly. The technology needs to point the direction, and right now it's a little nascent.

  • #24732

    Dave Wyatt
    Moderator

    In practice, you'll probably have bits of both. Most of your settings should be assigned in some sort of "Role" definition that can be used by multiple servers; this eliminates duplication (making the config data easier to maintain), and also ensures that you don't have a bunch of little differences between similar nodes creep into your data by mistake.

    However, there are some settings that should be node-specific, such as the certificate / thumbprint used to encrypt credentials in the MOF file. (For optimal security, this should be a different certificate generated on each node, though it is possible to just distribute the same certificate to every machine, if you prefer.) You may also be setting up agents that point to collectors in the nearest network / datacenter, etc.

    The DSC tooling on PowerShell.org is flexible enough to allow you to define these settings however you like, through the hierarchy defined when you use Resolve-DscConfigurationProperty. You can define settings in Service (aka "Role") files, globally, by physical site, or individually on each node, whatever is needed for your environment.

You must be logged in to reply to this topic.