We’ve all heard about DSC, right? Sure you have. Maybe you’ve been playing around a bit in labs or using for test environments. Why haven’t we all taken the plunge to Infrastructure as Code ( or more accurately Infrastructure from Code)? Because it’s hard, and we’re busy?
Likely, it’s because we don’t have the opportunity to go all ‘greenfield‘ in our daily jobs. Most of us live in the depressingly named ‘brownfields.’ We have servers already, we have workloads on them that are of different importance to our companies. We can’t just rip everything out and replace it! Oh but wait! Most of those machines are running older versions of Window Server or have old hardware. We’re going to need to do an upgrade/replacement plan anyway.
I know a lot of us have those old servers that run some important job. Maybe we virtualized when the hardware broke, but otherwise, they are still on 2008 or god forbid 2003. We can’t manage them with the latest tools because they have an old version of PowerShell ( if at all). We want to get rid of them, but what a daunting task!
Why not combine these two tasks? Two birds one stone and all that. Build out a pull server, and rebuild your infrastructure the “Modern” way. Don’t upgrade those VM,s construct new ones and shift the workload over. That ensures the cleanest installation and configuration. Since you’re configuring them from scratch, why not do it with DSC?
Here’s what I’m in the middle of right now: I have several physical servers at or near the end of life. I have a few 2008 servers still lingering. I want to get all my servers on 2016 to take advantage of several newer technologies. To make our Hyper-V hosts more efficient, I want to move as much as possible to Server Core. I had used DSC for several small servers but not in a truly ” production ” manner. Time to upgrade!
Here’s my plan in broad terms:
- Build out a pair of new load balanced secure Pull Servers – using DSC Push Mode.
- From there, make a BASE configuration shared by all servers and inject that MOF into the image I’m using to build new VMs. This base config contains things like domain join, setting up the LCM with where to look for the pull server, network set up, etc.
- Create configurations for the server Archetypes – File Server – Web Server – App Server – Backup Server – Domain Controller – etc.
- Write some basic Pester tests to verify that the configurations are doing what I expect.
- Start standing up servers, pushing configs and testing. Once tests pass…..
- Move to production mode!
At some point, I plan to move the whole shooting match from Github to Visual Studios Team Services for source control and test beds. It would be nice to be able to apply a MOF file to a VM in Azure, run pester tests, and upon a full pass, have it deploy that new MOF to the on-site pull servers. But that’s a learning curve for another day!
If you missed the first two parts to this , start here and continue here….
So the reason for the long delay in finishing this is due to some hardware problems with my test server. What was going to work fine for a 2012 server, doesn’t work for crap in 2016.
The problem is in the CPU. The old server I had planned on using as a lab does NOT have a SLAT capable chip. Since that’s a requirement for 2016 Hyper-V, it’s kind of a show stopper.
However – all is not lost! Jason Helmick and Melissa Januszko cooked up a PowerShell Automated Lab Environment that uses Virtual Engine Lability to easily stand up a lab environment on any Windows 10 machine. You don’t even have to manually download the ISO files for the OS install. Now I can very easily stand up/ tear down a lab with little fuss.
So with the lab situation handled, I’m moving on!
My goals this year is to get better with DSC, Pester testing and to complete a build pipeline for work. Let’s see how it goes…..
(For the introduction post : Rebuilding the Test Lab v2 )
Before getting into the actual planning let me describe the environment and restrictions.
- Dell 2950 w/ 2 Xeon 3GHz CPUs, 32 GB RAM, 12 TB JBOD Direct attached
- Windows 2012 R2 (full install), Hyper-V role, with Windows Deduplication running on the JBOD to keep file sizes on VHDs down. The license is through our company MSDN account, permissible as this is for testing and development.
- Powershell v5 is installed
- Dual gigabit ethernet adapters connected to the company LAN.
- As a “guest” on the company network, I have to be very careful to isolate traffic in and out of my test environment. I’ll use a Vyos VM Router to do this.
- I have no System Center VMM, no VMware, just plain vanilla out of the box Windows.
Alright so with our tools laid out, let’s talk about goals. What do I want to do be able to develop and test on this box? What’s that going to take? I’ve got to keep this simple or I’ll go down a rabbit hole of setting up the setup of the environment so that in the end I’ll get bogged down in minutiae. That may come later but for now – simple wins over cool new stuff.
Goal 1 : Learning to work in more of a DevOps kind of environment with source control and a development pipeline for my Powershell based tools. For this we’ll need TWO Virtual subnets – one for Dev and one for Test. Since there will only be one or two people on this at a time, I can build this all on the same box for now. Later when this process becomes more mainstream it won’t be difficult to rebuild the infrastructure on a production box.
Goal 2: build as much as possible with DSC – within reason. This is that rabbit hole I mentioned above. True you can build out a full network from scratch with DSC and a server WIM, but I’ve never done that and in the interest of getting stuff running right now I’m going a more old school route. Build a “Base” server in each subnet that is a multifunction server. It’ll be a domain controller, with DHCP, DNS, Windows Deployment Services and a DSC Pull server. From THERE I can work on things that I’m either rusty or inexperienced on. Walk before run before fly and all that good jazz.
I might add a goal 3 later but for now this is good. Let’s diagram this out so we can get that big picture over view.
Right. Next step, we build 3 VM switches, a VyosRouter and 2 “Base” servers.
See ya then!
Last year I wrote an article for Powershell.org extolling the benefits of a home lab and how it didn’t cost much to build a basic one. You can read it here.
That lab has done me well, but things change and needs increase and opportunities arise. The needs changing obviously is ” I want to be able to run more VM’s without sitting and listening to my disk thrash for minutes to start one”. The answer to that need is “buy more RAM or a SSD”, both of which have that nasty side-effect of costing money. So I gritted my teeth and waited…
Fast forward and now my work is decommissioning physical servers due to them not being covered under a 4 hour service agreement. Also due to a ton of virtualization by yours truly. So there are a few functioning servers with older cpu’s and smaller disks sitting idle…. yeah right. Time for TestLab v2!
This time I’m doing things a little different. First of all, obviously I’m not building on a Windows 8/10 machine. Secondly this box, while small by server standards, is a big improvement over my home pc. Also I’m building this as a test lab for our team so it’s a little more ” official”. I am using their hardware and network after all, I should share *grin*!
Now I’ve recognized a flaw in my process of “build, test, document”. Really it’s a side-effect of my mild ADD and the hectic work pace I keep up. Once I’ve built it and solved those problems and tested it and solved those problems, I kind of lose interest. There’s no more puzzle to solve, just homework to do. bah.
So we’re going to try a NEW (to me) technique. I’m going to write AS I build it, typing during those install waits, and reboots. I’m going to break this into a few parts. First this introduction, followed by a section on “Pre-build planning”,one on the actual build, then a wrapup “post-mortem” post.
. Let’s see how this goes!