GoGrid Snap-in - Managing Cloud Services with PowerShell

GoGrid Snap-in - Managing Cloud Services with PowerShell

  • Comments 1

I was pleased to see Mitch Denny’s announcement and demo of a PowerShell snapin for GoGrid.  GoGrid is a cloud-based, multi-tier grid hosting service leveraging virtual machines.  The snapin is a shared source effort at CodePlex (there are now 52 PowerShell CodePlex Projects).  Very cool stuff. 

What could go better together than cloud computing and PowerShell?  At the end of the day, cloud computing is about managing at scale in a lights out fashion and end-administrator self-servicing.  PowerShell is great at both of these and, as you’ll see at the PDC and our next CTP, PowerShell V2 gets even better at both!

Here is an example of creating a GoGrid Windows 2008 Server using Mitch’s SnapIn:

Add-GoGridServer -Credential $credential `
 -Name DemoServer `
 -Image w2k8_32_base `
 -Memory 1GB `
 -IPAddress 173.1.23.194

Pretty sweet huh?  I’ll drop one of the secrets now because it is so relevant to this scenario.  At some point in this process, you are going to have a VHD on your machine that you need to get to the cloud and the question is, how are you going to do that?  In PS V2, we are providing a full set of BITS cmdlets for this.  BITS is the Background Intelligent Transfer Service.  You point BITS at your source and destination and then you can walk away.  At that point, the network can break, you can restart your process, either machine can reboot and BITS just keeps on going like Arnold in the Terminator – it will not be stopped (unless you stop it).   BITS is also very smart about being gentle to your network (unless you tell it to go full throttle).  It will monitor network bandwidth and consumption and throttle itself.  Is that sweet or what?

Here are the other GoGrid Cmdlets in Mitch’s Snapin

  • Add-GoGridLoadBalancer
  • Add-GoGridServer
  • Delete-GoGridLoadBalancer
  • Delete-GoGridServer
  • Get-GoGridImage
  • Get-GoGridIPAddress
  • Get-GoGridLoadBalancer
  • Get-GoGridOption
  • Get-GoGridServer
  • Get-GoGridServerPassword
  • Restart-GoGridServer
  • Start-GoGridServer
  • Stop-GoGridServer

There are some other new techniques in PowerShell V2 that make this task even simpler and more powerful but you’ll have to come to my PDC talk to hear more (I’ll drop the slides here after the PDC). 

<Update> 
One of the things the cmdlets do is to take a CREDENTIAL parameter.  The issue/problem is that it requires a credential for each cmdlet.  This is a common design issue that people have when designing cmdlets - they have some parameter that needs to be passed to every cmdlet.  Here is my suggestion for how to deal with this: 

Make the parameter OPTIONAL.  If the user provides it, use it.  If the user does NOT provide it, look for a variable that contains this value.  In this case, I would name the parameter $GoGridCredential.  If that variable exists and contains a credential - use it otherwise throw an error.  This allows the user to define a variable once and then avoid having to pass it the the cmdlet everytime.  This is especially useful for interactive sessions where you just want to GO GO GO.

</Update>

 

PowerShell and Cloud – better together!

Enjoy!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Leave a Comment
  • Please add 5 and 8 and type the answer here:
  • Post
  • Hi Jeff,

    Mitch here. Huge fan of your work. With the credential stuff I was thinking of a better way of handling that so thanks for making that suggestion.

    Not sure if I am a fan of magic variable names specific to a snap-in though. One thing I was thinking of doing was creating a Get-GoGridCredential cmdlet with a -cache argument. So what I could do is issue a command like this:

    $cred = get-gogridcredential -apikey 1234 -cache

    If I hadn't accessed the credential previously with that user on that machine it would prompt for the secret (using the standard PSCredential dialog, but if it had it would build the PSCredential for me.

    I've done this in script previously where I use the ConvertTo-SecureString and ConvertFrom-SecureString to store it in a file.

    Credential management for scripts is something that I'd definately like to see addressed in the future as well as packaging scripts, snap-ins and types into installable units.

    That said I need to spend more quality time with PowerShell 2.0, especially the job features which I think might be useful for server builds.

Page 1 of 1 (1 items)