Provisioning Windows Development Environments
48 views
Skip to first unread message
Jamie Jackson
Dec 10, 2015, 9:43:18 AM12/10/15
to vagra...@googlegroups.com
Hi Folks,
I've set up a couple of Linux/Apache/MySQL/Web-App projects with Vagrant, using shell script provisioners (the learning curve of some of the fancy provisioners was prohibitive at the time). So far, I've been perfectly happy with configuration as code (building from scratch on bare Ubuntu Vagrant images), since I don't care to version binary images.
Another project, (unfortunately) on a Win/MSSQL/IIS/Web-App stack, has asked me to help out. I could use some advice as to how to approach it? For instance, how do people tackle the issue of Windows licensing (vagrant destroy/up every month)? What are some suggestions as to which provisioner to use?
Thanks,
Jamie
Fraser Goffin
Dec 11, 2015, 4:26:25 AM12/11/15
to Vagrant
Why 'unfortunately', the world is hetrogeneous my friend as is most non-trivial infrastructure !
Anyway that aside, this could be a pretty big question (as I'm sure you realise).
First off, I'm am no expert in terms of what is a legal licensing position for your company (or you personally), so you certainly shouldn't accept anything I say here without first checking with your Software Asset Management folk (or whatever the equivalent is in your org).
Insofar as licensing is concerned, that obviously depends on a number of things that relate to the organisation you work for (unless this is a personal project), the expected longevity of your development environments, your org's attitude to using 'free/trial' licenses and so on. If you work for a company that has an Enterprise license agreement for MS Windows across desktop and server versions (you haven't said what version you want to build on and licensing options will likely differ) then, you may well find that the 'host' Windows license will include provisioning a limited number of Windows VMs running on that single host, so no additional licenses are required. If you are not in that situation then you will either need to purchase licenses for each VM or go down the free trial license route. For the latter, there are a couple of options depending on your starting point. If you want to build your own base image from an ISO (using [say] Packer with a post provisioner to produce a Vagrant box) you can pop over to TechNet and download an ISO with a trial license. These typically last between 90-180 days (which is one reason why I mentioned the expected 'longevity of your dev environments). If you want to start further up the stack and are comfortable in taking a pre-built Vagrant box for your preferred VM (say Virtualbox) then you can head over to the Hashicorp Atlas site (there are others too) and download most versions you might need from there. For this option you still need to provide an activation key of some sort, so agian, either an Entreprise Volume license or a trial. If you *are* using an Enterprise MAK then you *may* want to configure your VMs to use a KMS server that you can reach on your network. Windows Server licensing is probably going to be a different story, although can still get trial licenses from TechNet if thats what you want to do. Otherwise you are likely going to need a separate licence for every VM.
Lifecycle of VMs revisited .... Typically I don't expect a development VM to be around too long ('too long' is a bit subjective, but I mean, measured in hours, days or sometimes weeks, but probably no longer than that). Mostly we follow the 'up' -> 'use' -> 'destroy' pattern and by-and-large aim for immutable instances that we can stand up and then destroy and re-create at will. As soon as you start down the path of incremental updates for 'long-lived' VMs you are likely to see recurrence of the 'works on my machine' nonsense, which we all know is a massive time waster because of the compounding effect of those updates. We have experienced this even when following Desired State Configuration (DSC) approaches, so these days we favour highly disposable instances (often Docker containers). In fact Docker containers are something we are using more and more rather than fully blown VMs, although we will often run them inside a VM host .. but I digress and Docker isn't really production-ready for Windows just yet.
You also need to work thru any concerns that your security/audit folk might have when the VMs are connected to your corporate network (e.g. anti-virus, et al), but thats likely to be very site specific and it depends how you configure networking options in your VMs.
Once you have a repeatable process for creating your base OS (and optionally 'hardended') builds (which will usually include some core provisioning tools too), you can then move on to configuration management. In our case, for Windows, we like to use a combination of Puppet, Powershell and Chocolatey, along with a package server (we use Sonatype Nexus) for provisioning the application stack, all of which can be launched as part of your VagrantFile, or earlier in Packer if you prefer. Clearly these depend heavily on the choices you have made in terms of the tools and skills you are comfortable with maintaining, so YMMV. Our primary CM tool is Puppet (which we run masterless). I highly recommend approaches that leverage the declarative abstraction of resources (rather than just OS level scripting) for lots of obvious reasons that I'm sure you are aware of (not least of which that you can share many modules across OS's, acheive idempotence and ..yadda, yadda, well, you get the idea). You will find modules on Puppet forge and on the Chocolately forge for common packages such as those you have mentioned as well as the ability to install and/or activate Windows 'features' and 'roles'. Substitute your CM tool of choice, but stay away from 'raw' scripting would be my advice (i.e. in the Vagrantfile you might use the Puppet provisioner rather than the [Power]Shell one).
Thats a short and not very detailed trip through some of the options, but as I said at the start, there's a lot more details and a bunch of options which, without knowing the environment constratints that you are working in, make it near impossible to be more prescriptive.
HTHs
Fraser.
Anyway that aside, this could be a pretty big question (as I'm sure you realise).
First off, I'm am no expert in terms of what is a legal licensing position for your company (or you personally), so you certainly shouldn't accept anything I say here without first checking with your Software Asset Management folk (or whatever the equivalent is in your org).
Insofar as licensing is concerned, that obviously depends on a number of things that relate to the organisation you work for (unless this is a personal project), the expected longevity of your development environments, your org's attitude to using 'free/trial' licenses and so on. If you work for a company that has an Enterprise license agreement for MS Windows across desktop and server versions (you haven't said what version you want to build on and licensing options will likely differ) then, you may well find that the 'host' Windows license will include provisioning a limited number of Windows VMs running on that single host, so no additional licenses are required. If you are not in that situation then you will either need to purchase licenses for each VM or go down the free trial license route. For the latter, there are a couple of options depending on your starting point. If you want to build your own base image from an ISO (using [say] Packer with a post provisioner to produce a Vagrant box) you can pop over to TechNet and download an ISO with a trial license. These typically last between 90-180 days (which is one reason why I mentioned the expected 'longevity of your dev environments). If you want to start further up the stack and are comfortable in taking a pre-built Vagrant box for your preferred VM (say Virtualbox) then you can head over to the Hashicorp Atlas site (there are others too) and download most versions you might need from there. For this option you still need to provide an activation key of some sort, so agian, either an Entreprise Volume license or a trial. If you *are* using an Enterprise MAK then you *may* want to configure your VMs to use a KMS server that you can reach on your network. Windows Server licensing is probably going to be a different story, although can still get trial licenses from TechNet if thats what you want to do. Otherwise you are likely going to need a separate licence for every VM.
Lifecycle of VMs revisited .... Typically I don't expect a development VM to be around too long ('too long' is a bit subjective, but I mean, measured in hours, days or sometimes weeks, but probably no longer than that). Mostly we follow the 'up' -> 'use' -> 'destroy' pattern and by-and-large aim for immutable instances that we can stand up and then destroy and re-create at will. As soon as you start down the path of incremental updates for 'long-lived' VMs you are likely to see recurrence of the 'works on my machine' nonsense, which we all know is a massive time waster because of the compounding effect of those updates. We have experienced this even when following Desired State Configuration (DSC) approaches, so these days we favour highly disposable instances (often Docker containers). In fact Docker containers are something we are using more and more rather than fully blown VMs, although we will often run them inside a VM host .. but I digress and Docker isn't really production-ready for Windows just yet.
You also need to work thru any concerns that your security/audit folk might have when the VMs are connected to your corporate network (e.g. anti-virus, et al), but thats likely to be very site specific and it depends how you configure networking options in your VMs.
Once you have a repeatable process for creating your base OS (and optionally 'hardended') builds (which will usually include some core provisioning tools too), you can then move on to configuration management. In our case, for Windows, we like to use a combination of Puppet, Powershell and Chocolatey, along with a package server (we use Sonatype Nexus) for provisioning the application stack, all of which can be launched as part of your VagrantFile, or earlier in Packer if you prefer. Clearly these depend heavily on the choices you have made in terms of the tools and skills you are comfortable with maintaining, so YMMV. Our primary CM tool is Puppet (which we run masterless). I highly recommend approaches that leverage the declarative abstraction of resources (rather than just OS level scripting) for lots of obvious reasons that I'm sure you are aware of (not least of which that you can share many modules across OS's, acheive idempotence and ..yadda, yadda, well, you get the idea). You will find modules on Puppet forge and on the Chocolately forge for common packages such as those you have mentioned as well as the ability to install and/or activate Windows 'features' and 'roles'. Substitute your CM tool of choice, but stay away from 'raw' scripting would be my advice (i.e. in the Vagrantfile you might use the Puppet provisioner rather than the [Power]Shell one).
Thats a short and not very detailed trip through some of the options, but as I said at the start, there's a lot more details and a bunch of options which, without knowing the environment constratints that you are working in, make it near impossible to be more prescriptive.
HTHs
Fraser.
pixel fairy
Dec 30, 2015, 2:41:35 AM12/30/15
to Vagrant
MS licensing is scary. i lost weeks trying to work through that nonsense. anyway, this might help https://github.com/Azure/vagrant-azure
It includes windows boxes. They used to have virtualbox vagrant boxes, but i cant find them now. one of my co workers just keeps regenerating his windows boxes with packer.
It includes windows boxes. They used to have virtualbox vagrant boxes, but i cant find them now. one of my co workers just keeps regenerating his windows boxes with packer.
Reply all
Reply to author
Forward
0 new messages