The virtues of Ansible – Running Ansible on Windows

Devops and Ansible

The mantra of DevOps (Development Operations) is Infrastructure is Code.
For those who are not familiar with DevOps, it is a culture and philosophy of computer and network infrastructure management geared around development and delivery of software and services. DevOps uses tools geared towards automation of infrastructure, delivery of software and services.
Ansible is one of those indispensable tools used in DevOps. With Ansible, you can manage your whole network infrastructures , deploy and manage virtual machines, install and configure VMs, provision and update software and services, etc. Written in python, and the configuration files are “programmed” in YAML (Yet Another Markup Language). It is a easy to learn tool for mass provisioning of Linux, Windows, Mac and virtual infrastructure using scriptable command line.
Windows operating system is ubiquitous and is probably one of the easiest, lowest cost hardware/software combinations to get for your testing and development and production environment.

The Windows Dilemma

However if you like me, are running Windows, there is one problem, Ansible does not run on Windows. The developers of Ansible have no intention of porting it to Windows (at this time). Even though, there “is” a way to use Linux like libraries on Windows (using things like CygWin) , however, it’s not very stable. You need a stable platform to do mission critical work. So, how do I run Ansible in Windows?

Introducing Vagrant

The answer to this dilemma is to use Virtualization. “Wait a minute…”, you might say, “Isn’t this a clunky and bulky way to run a tool by getting a clunkier interface to run it on?” This is where a virtualization environment for developers like Vagrant comes into play. Vagrant, from command line allows you to do some cool things:

1 – Use your favorite Windows based editor to edit your playbooks in which you can make changes to your files THEN run them without repackaging the image (as in the case of Docker).
2 – With command line within PowerShell, QUICKLY spin up your Linux VM to run Ansible.
3 – From the same command line, enter the Linux VM command line and run Ansible commands and run your playbooks.
4 – If you want to run the Vagrant VM for a dedicated task involving Ansible, with one command, you can do just that.

For those not familiar with Vagrant, this is a piece of cake.

How to set up Ansible in Vagrant

For the purpose of demonstrating how to do this in Windows, I will show you how to do this in a Windows 7 SP1 machine. I will also assume you are running the latest version of VirtualBox hypervisor. Vagrant will also work with VMWare and HyperV and other versions of Windows (7/8/10), but this will be left (for now) as an exercise you can do on your own.

Also, my preferred way to add software to Windows machines is to use a package manager like Chocolatey. Using automation with package management is the DevOps way. Follow this link for instructions installing Chocolatey.

Steps for setting up Vagrant

1 – Download and install VirtualBox

a – use chocolatey
C:\> choco install virtualbox

b – manually install
Download from here: https://www.virtualbox.org/wiki/Downloads

2 – Download and install vagrant

a – use chocolatey
C:\> choco install vagrant

b – manually install
Download from here: https://www.vagrantup.com/downloads.html

3 – Download this vagrant file from the git repository and unpack it. This is a Vagrantfile template. You can use git to get the file.

4 – Change directory to vagrant directory and run “vagrant up”

5 – Access VM shell, run “vagrant ssh” It will take you into a Linux shell.

6 – To exit out of the VM shell, type ‘exit’ and hit enter. You will be back to the powershell command prompt.

7 – To shut down vagrant and the VM, run “vagrant halt” and it will shut down the VM.

I would recommend reading the README.md file in the directory for additional details.

How do these files work?

This is not a full tutorial on how to work with Vagrant, just enough to get you running with Ansible on Windows. We may cover the particulars of Ansible and Vagrant another time.

What is a Vagrant file?

The Vagrantfile tells vagrant how to provision the VM. The VM will be installed with Python and Ansible. It’s a file written in the Ruby programming language. It’s pretty straightforward how you can configure it to work with your development environment. Anyhow, from here, you can experiment with Ansible on the VM itself.

Once you access Ansible through Vagrant, you can start using Ad Hoc commands and writing playbooks for Ansible and executing them right there. Do some searching on the internet on what you can do with Ansible. It’s a very powerful tool.

That was quite a bit of info, how do I wrap my head around this?

That is the unfortunate nature of any profession, especially the technology profession.  You need to know many different tools and concepts in order to use them, and many of the tools by themselves don’t make much sense until you find a context to use these tools.  Each one of the tools and technologies I used in this intro have their own use in the DevOps area.  You have to dive right in and play with them in order to find out how they can help you to use them in your own particular situation.   I may cover each of these tools  individually in a future article.

Until then, have a good day.

Roy

DevOps vs Systems Administration – Why should I care?

Originally, I was going to write about Ansible and how to run it in a Windows environment using Vagrant, but as I started to write the article, I found that I had to describe how these tools were used and developed around the culture and philosophy of DevOps. Then, it occurred to me, I needed to describe what is DevOps. According to Wikipedia, DevOps is a software development methodology that combines software development (Dev) with information technology operations (Ops). Of course, I’ll use DevOps definition in a broader sense and more oriented towards operations.

Why should I care? Isn’t systems administration and DevOps the same?
Not exactly. Being brought up on old school Unix Systems Administration, I remember when machines consisted of dedicated hardware(CPU, Memory, Framebuffer, hard drive, etc.) software and network switches and routers. I would spend hours configuring individual machines using scripts or installing software (or compiling it) one machine at a time. I would be working with a team of people it seems firefighting. Keeping up with the demands of the users and their needs for additional resources…well was a pain. Then we turned the corner with virtualization where your machine is just a disk image sharing space on high powered hardware, more efficient, easier to use programming languages such as python & ruby (though this can be debated, but these languages are easier than programming c) and working towards automation. Mass on demand Virtualization is now called “cloud computing” or what I call Commoditized Virtualization. You can get VMs on demand and pay for what you need even by the hour. Out of these merging of technologies and software development methodologies (such as Agile) is where DevOps finds its origins.

Contrasting Systems Administration with DevOps.

Systems Administration tends to focus on being a tech…that is a power user who loads and configures software and plugs in hardware into the system. DevOps on the other hand focus on programming and automation of the system and network infrastructure. The mantra is “Infrastructure is Code” where you write and run code to make running the systems and network infrastructure more predictable and controlled.

System Administration tends to be reactive. That is you plug in the hardware/software and find out if it works and fix it as you go. DevOps is proactive in its approach. Use automation in a consistent and predictable way by using tools to test in a development environment before releasing it into a production environment.

System Administration tends to follow a “waterfall” approach to planning, getting requirements and deployment. You tend to make big expenditures of capital, time and resources up front. You fix it as the complaints come in. DevOps approach is more “agile” with many smaller changes to the system with plenty of user feedback BEFORE it’s all rolled out as well as DURING and AFTER the rollout.

While your company or organization may not be a software development house, i.e. you may be a web design company or your supporting your own companies internal network, you WILL benefit from adopting a DevOps approach as this can be applied to:

1 – Rolling out new software to your internal desktop users and keeping them current.
2 – Keeping your customers websites updated using automation tools.
3 – Being able to show management (and other stakeholders) what is accomplished and what is needed. You keep them in the loop.

While this is not ment to be an exhaustive treatise on DevOps, this should open your eyes to what is useful and what is possible.

In the meantime, have a good day.

Roy

Software is perishable – Identify your HIDDEN requirements.

Software is perishable

In a world where fresh food goes stale then rots, pets are born, grow old and then die, software is perishable. What do I mean by that?

Requirements change

Isn’t software something that once it’s written just does it’s task and doesn’t change? Yes, that is true, but the REQUIREMENTS needed to keep software useful will change over time. Often the changes can be swift and rapid. This can get you and your business into trouble if you don’t keep your eye on it.

A way to look at software is what reason did you get the software in the first place. It filled a need, a requirement.

For instance, I get an accounting package…lets say KwikyBooks. I get the package for my accounting needs. Well, what are my requirements?

1 – Generate invoices of my customers.
2 – Take payments and track this information.
3 – Generate various reports.

Hidden REQUIREMENTS

However, there are HIDDEN requirements that may not be obvious until you start using your software:

1 – What kind of hardware does this software run on. If you can’t obtain or afford the hardware, the software will be useless.

2 – Is the software secure? If you can’t keep your confidential business data safe, you will lose customers because they can’t trust you to keep the information safe. It’s just a matter of time before someone or something hacks your system.

3 – Is the software keeping up with industry standards and practices? Is it compliant with Federal, State and Local laws? E-commerce businesses, depending on it’s size, for example may have to track sales tax in EVERY STATE it sells to. Every year the Federal and Local government adds new laws and regulations that affect accounting and Tax laws. Having software that is non-compliant with industry standards and laws can cost you money and even your business.

In the same way, even though your software you have purchased or have developed for your company or customers may fulfill your original requirements, the HIDDEN requirements often will change because the software doesn’t change with time.

Prepare for Hidden Requirements

With this in mined, here is what I’d suggest you do when you either purchase software or have it developed:

1 – Check on the stability of the developer or company you are getting your software from. Even if it’s AWESOME software, if the software developers who wrote it go away, you can’t get the software HIDDEN requirements fixed. If your working with an independent software developer, I would recommend you use a well known open source framework  and languages. In the worst case scenario, you can find a python or java developer to take over development ant maintenance of your software than something written in let’s say a Esoteric programming language or a language that is not as common to use these days (i.e. Fortran, Pascal, Assembly, etc.)

2 – Get or obtain a service contract or maintenance agreement for the software. With this in place, you keep the software developer vested  to keep your software up to date.

3 – Periodically review your requirements and discover what your HIDDEN requirements are and get them addressed.by the developers. The HIDDEN requirements are usually found in changes in these three categories:

a – Industry rules and standards – Software is codified expertise that follows the rules and standards of your industry.
b – Laws (Federal, State and Local) – Legal requirements affecting your industry or profession.
c – Technology  – New technology and advancements, including updates and security fixes.

I would recommend you work with your software developer or software company to help you keep track of these areas that can affect your software requirements. Incorporate this process if you are working with Agile software developer.

In summary, please re-examine your software requirements regularly and make sure you keep you software fresh. Don’t allow your software to perish along with your business.

In the meantime, have a good day.

Roy