Ansible Tower and full Enterprise Infrastructure

One of the greatest joys I experience is when an idea catches on and key members in a client organisation engage into the message that I’m delivering.  I recently conducted a presentation to an Ops team detailing how Ansible Tower can be introduced to help manage their server infrastructure.  “But why stop at servers?” they asked me “Could this be used to manage the desktop environments as well?”.

I’ve always considered Ansible as the tool for production based environments, but the question intrigued me.  Can Ansible be used to manage desktops as well as servers?  When you get right down to it, from Ansible’s point of view connecting to a windows 7 desktop or a server 2012 instance do not represent a lot of difference.  Providing those environments are setup to accept WinRM connections and have a valid Service Account, Ansible should be able to provision and configure those environments as easily as it can Servers.

Even managing an infrastructure consisting of several hundred windows desktops in the Inventories section doesn’t pose too much of a challenge.  Ansible Tower comes with a handy command line tool called tower-manage inventory_import so getting an export from Active Directory and into Tower is a sinch.

So from a technical point of view, managing desktops with Ansible Tower is definitely a possibility that could be implemented into enterprise sized infrastructure.

The only issue that has to be considered carefully is the financial cost and gained benefit from following this path.

With regards to Servers, how the environment is configured, updated, provisioned and maintained are critical to the long term operational stability of an organisation.  It makes sense for large organizations to use CM tools like Ansible to manage their environments and reduce risk.

Desktops on the other hand are a different story.  With the exception of large data centers, there will generally be a greater number of desktops than servers.  Other than core applications like Anti Virus and system updates (which usually have their own automated update mechanic), it’s not so critical to keep Desktop environments up to date with the latest software releases.  Many Desktop devices may be mobile, such as laptops, and are often offsite and not connected to the internal network.  Most problems can be fixed by the use of a strategic disk defragmentation or turning it off and back on again.  With all these points brought into consideration it is clear that the financial benefit of using Tower to manage full-scale Enterprise Infrastructures is just not worth the capital expenditure.  For the cost of licenses required to manage anything above 500 nodes, you could easily hire 2 or 3 extra desktop technicians and receive a greater return.

While the potential is there for including Desktop devices into the scope of CM, companies such as Red Hat and Puppet Labs need to look further into their pricing models to make it worth an organisation’s while to invest in these tools.  As it stands, the standard per node costing model doesn’t work on anything else other than Servers.  Which is a shame considering the potential advantages of simplifying the Continuous Delivery cycle for developers producing desktop applications right to the desktop on release day.

A big bar of Chocolatey

I posted recently my first impressions of chocolatey, the package manager for windows.

This post is going to focus on some scenarios that many Enterprise customers may face when using this software deployment platform as part of their Configuration Managements solution.

Most of the applications you’ll be installing will be fairly light weight.  Things like Notepad++ (because we all know not to use notepad right?), java-jre/jdk, Anti-Virus are generically standard additions for server environments.  They are usually light weight (less than a few hundred meg at most) and Chocolately can install them with ease.  But there is one current limitation to Chocolatey I found that makes installing certain software not as easy as choco install this-package.

Currently the limit to the size of the nupkg is 2 gig. For the majority of your enterprise dependencies this will not be an issue.  But what about when it comes to installing things like SQL Developer edition/Enterprise/Datacentre or exchange which can come in at over 4 gig in size when you package the whole media? There may be options that you can strip out of the installation folder if you have a specific build and don’t need certain features, but this blog will assume you have a dynamic use case that could change over time or by project so will need the full installation media present.

You can certainly create large packages, but Chocolatey will throw an error when trying to install them.  So how do we install large packages within the bounds of this limitation?

Chocolatey I’ve found is a very dynamic and configurable tool.  The help guides on their website give us all the information we require to get up and running quickly and there’s plenty of choice for creating our local repos.  So while the current 2 gig limit on nupkg binaries does limit quick package creation and installs for the bigger software, all is not lost as there are ways to work around it.

Applications like SQL Server and Exchange aren’t like your standard MSBuild or MSI installers.  Notepad++ for example is an installer which contains all the required dependencies in a single package.  SQL on the other hand is a lot more complex.  There is a setup.exe, but that is used to call all the other dependencies on the media source.  If you try and package the whole thing up you’re going to be in for a hard time as I’ve already stated, but due to the way that Chocolatey works, these giant installations can potentially be the smallest packages you create.

Lets examine the innards of a package to see how this can be done.

At it’s most basic form, a package consists of a .nuspec file which details all the meta data, a chocolateyinstall.ps1 script which handles what is being installed and how and finally the installer it’s self.  Creating packages is as easy as :

choco new packagename

and packaging with

choco pack path/to/packagename.nuspec

With a business version you can generate packages automatically from the installer it’s self which is with out a doubt a very neat feature.

My initial attempt at installing SQL Enterprise was to put all the media in the tools directory which gave me a nupkg of around 4.5 gig.  Way too big.

As I mentioned Chocolatey is very dynamic in how packages can be installed.  Initially it creates the installer script with the following headers detailing what the name of the actual installer is and where it can find it :

$packageName = ‘Microsoft-Mysql-Server-Datacenter’
$toolsDir = “$(Split-Path -parent $MyInvocation.MyCommand.Definition)”
$fileLocation = Join-Path $toolsDir ‘setup.exe’

So this would assume that I’m pulling a package from a repository that is specified when I set up Chocolatey initially, or from the –source argument.  Seeing as how SQL is too large to effectively package whole, I found that I could host the installation media on a UNC network share and map a drive to it.  So now my headers look like this :

$packageName = ‘Microsoft-Mysql-Server-Datacenter’
$toolsDir = “$(Split-Path -parent $MyInvocation.MyCommand.Definition)”
$fileLocation = ‘Y:\SQL_Server_DC\setup.exe’

This also means that when creating the nupkg I didn’t need to include the setup.exe so the new size is just under 4k!  But that is just one of the hurdles I had to leap.

I’m installing all my packages via Ansible configuration management.  One of the included modules is win_chocolatey which for simple installations from a NuGet type rep works well enough.  Unfortunately I’m installing from UNC which requires that an authenticated drive is mapped.  Mapped drives require a persistent user connection which Ansible currently does not support.  If you try and map a drive as part of the provisioning process, it will exist for the lifetime of that WinRM connection only and be lost when the next command is initiated.  I manged to work around this by creating a Chocolatey bootstrap script :

param (
$netshare_password,
$package,
$arguments
)
$PWord = ConvertTo-SecureString $netshare_password -AsPlainText -Force
$netshare_cred = new-object -TypeName System.Management.Automation.PSCredential -ArgumentList “NUGET\netshareuser”,$PWord

New-PSDrive -Name “Y” -PSProvider “FileSystem” -Root “\\NUGET\Installation Media” -Persist -Credential $netshare_cred

choco install $package -y –force -source Y:\ –ia=$arguments

And called within Ansible like this :

– name: Installing SQL Server
raw: ‘C:\Windows\Temp\ChocoBootstrap.ps1 -netshare_password “M@d3Up9@55w0Rd” -package “microsoft-sql-sever-datacenter” -arguments “/ConfigurationFile=C:\Windows\Temp\ConfigurationFile.ini”‘

Through this work around, I am able to install packages larger than 2 Gb with ease.

LEAN, mean DevOps machine

With all the noise and excitement over new tools being used it’s easy to overlook that DevOps is not just a technical role.  There are many aspects that sets being a DevOps specialist apart from being another form of Systems Administrator and it is one of these areas that I’m going to talk about today.

Lean is a methodology that is usually found in marketing and manufacturing.  Toyota is noted for it’s Just In Time (JIT) manufacturing methods which Ford also implemented into his early production lines.   But what is it and why is it so important for someone like myself?

The shortest explanation is that Lean helps you look at processes that form up how a function is performed and allow you to identify waste.  That is in wasted time, effort, resources, money etc.  To me it is a brilliant framework to help me diagnose what is wrong with the Delivery cycle in a company and start being able to implement the right tools, methods, strategies to bring about a robust and stable Continuous Integration and Delivery solution.  Knowing how to automate a process I feel is only half the battle.  Knowing what to automate is where the biggest gains can be made and Lean allows you to identify those areas that need the attention most.

Lean also forms a foundation for me to Measure.  At some point in the DevOps process you will be asked to identify improvements and justify the need for you in the organisation.  When I identify waste through Lean, I take that opportunity to also identify measurable metrics.  There may be a process in the deployment cycle that requires 2 or 3 members and takes 5 hours to complete.  This is an easy metric as you can identify an actual cost of that process by the number of man hours dedicated to it.  Time as they say is money and here you can clearly calculate a cost.  There may be many such processes in the organisation and Lean coupled with Measure allows you to identify what are the greatest wastes and the more valuable lowest hanging fruit to change first.

Full of Chocolatey Goodness

The one thing that nobody can deny Nix based OSes have down pat is the package manager.  The ability to install software on demand from trusted sources is without a doubt one of the coolest things I’ve experienced using Linux.  You need a media editing suite?  No problem!  A better text editor?  Take your pick! Whether it’s RPMs or ppa’s, via command line with yum and apt-get or in the GUI with Synaptic, that ability to install packages, updates and full software products is simply amazing!

In terms of configuration management this makes provisioning Linux from infrastructure as code tools like Ansible, Puppet and Chef insanely easy.  Unfortunately Windows does not have this feature.  Sure there is an app store similar to current smart phones in windows 10 (if there were any apps to download that is), but pretty much all CM solutions are geared towards server based environments so fully automated configuration management isn’t as simple as it would be with Centos or Ubuntu.

So how do we deal with installing software through CM on Windows?  One way is to package the software as part of the CM script.  If you version control those scripts in Git, you could feasibly include each software package as a submodule to git, but that means that you have to create a separate git repository for every package you use.  In some of the environments that I’m dealing with, there may be as many as 30 or 40 software dependencies on a whole environment so that means a lot of repos.  Tracking binaries with git is not really efficient either.  Every time you update the package, it snapshots those binaries so you can end up with massive repos for small software packages.  These take time to download and can slow the entire CM process down massively.

If only there was a decent package manager for windows like ppa or rpm…….

Well hold on to your socks guys because we are in luck.  There is a package manager for windows that works just like it’s Linux cousins.  It’s called Chocolatey and even though it’s early days for me and I’ve not had much exposure yet, it’s phreaking amazing!

I had a demonstration from Rob Reynolds and Mike at RealDimensions software and my jaw was hitting the floor through the whole presentation.  There is a public repository with so many applications available that it a desktop user can get pretty much whatever they want.  For the corporate environments there is the ability to host your own private repo in which you can create your own secure validated apps on.  Creating packages is extremely easy and all the options you need to change are clearly laid out in the configuration files.  There is a business option that allows you to create packages from a host of windows installers.

I am impressed with what I’ve seen so far.  I’ll certainly be blogging about my experience over the coming weeks.