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.
On Thursday, 10 December 2015 14:43:18 UTC, Jamie Jackson wrote:
>
> 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
>
--
This mailing list is governed under the HashiCorp Community Guidelines -
https://www.hashicorp.com/community-guidelines.html. Behavior in violation of
those guidelines may result in your removal from this mailing list.
GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
You received this message because you are subscribed to the Google Groups
"Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vagrant-up/1d654125-5ab1-4519-aa7f-1461d7b524c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
