How to deal with named pet(server role with something unique per server) in DSC?

Welcome Forums DSC (Desired State Configuration) How to deal with named pet(server role with something unique per server) in DSC?

This topic contains 4 replies, has 3 voices, and was last updated by

Syl
 
Participant
6 months, 1 week ago.

  • Author
    Posts
  • #133427
    Syl

    Participant
    Topics: 12
    Replies: 33
    Points: 59
    Rank: Member

    We have a web server farms that is troublesome to code.  Every server in the NLB farm has the same config, except for one IP address, assigned to a website, that is unique to each server in the farm(the ip address is unique per server, but it's assigned to the same website name).  That ip is there for an old probing application to determine the state of the web service on each server.  Modifying the code of that app to use modern technique is not possible for the moment.

    How can we code this optimally in DSC?  I know, DSC is not really suited for named pet, but I'm sure we all encounter cases like this at one point 🙂

  • #133575

    Participant
    Topics: 1
    Replies: 9
    Points: 133
    Rank: Participant

    Do you compile your Configurations per machine with a specified name or do you use Localhost for the node name and use a generic one?

    If you are using a per-name configuration you could just pass the name with a set ip address when you compile them in a loop.

    If the machines themselves are static you could just make DHCP reservations for them.

    Depending on your environment you could also achive this with ephemeral machines by creating them with set MAC addresses (although creating them with a preset static ip would do much the same thing and would probably be better supported).

  • #133608
    Syl

    Participant
    Topics: 12
    Replies: 33
    Points: 59
    Rank: Member

    We compile using a role name.  So far we are trying really hard to build our configdata with Roles in mind.

    DHCP won't help since the problem is when we create the website, and then must assign that unique  IP to the website.  So, Webserver01 has WebsiteIP1 assigned to it, Webserver02 has WebsiteIP2, etc.   As such, in our configurationdata, when we create the Webserver Role, we can configure everything, except that IP since it's different for every member of the nlb farm.

    We tried using the very promising Datum module, and that solved the unique IP/website problem, but we encountered other breaking problems with it so we had to back out of using it.

     

    • #133790

      Participant
      Topics: 1
      Replies: 44
      Points: 140
      Helping Hand
      Rank: Participant

      Maybe you can let me know about the "other breaking problems" of my Datum module 😉
      Probably best to hit me on slack (http://poshcode.org/), or ask me to follow you on twitter so we can DM.

      I'd be happy to get feedback anyway.

      I suspect that if you're setting up websites, you might have felt blocked with how to pass sub-construct (cimInstance types of parameters). Such as MSFT_xWebApplicationAuthenticationInformation?

      Let me know.

    • #133863
      Syl

      Participant
      Topics: 12
      Replies: 33
      Points: 59
      Rank: Member

      Breaking problems is probably the wrong expression to use(english is  not my first language), it's more like we faced a current limitation of Datum(and our lack of expertise to solve it by coding what is missing).  As such, we can't use Datum until it support some kind of variable substitution(variable Interpolation you call it on github https://github.com/gaelcolas/Datum/issues/21)  I tried using a handler for that feature but I was soon faced with the recursive search problem that I have no idea how to solve.

      Funny thing, I asked our Microsoft TAM what could be done to solve our "pet" problem and he sent me a link to the AutoLab DSCworkshop Repo 😛

      P.S. I am now following you on twitter

The topic ‘How to deal with named pet(server role with something unique per server) in DSC?’ is closed to new replies.