I was asked to show how Ansible can work together with Vagrant.
In my example I’ll install, enable and configure UFW firewall on Ubuntu, then machine will be rebooted and uptime will be shown.
It’s really simple task, so just have a look at Vagrantfile and playbook:
Boxes can be obtained from Atlas repos , from whatever other repos or created by ourselves with Packer or manually.
Please pay attention that almost all boxes are OK with VirtualBox , but only some can be used with other providers like Parallels, Hyper-V, AWS, etc.
Boxes are stored separately from VMs, in ~/.vagrant.d and during VM deploy process box is cloned to hypervisor default location.
Vagrantfile is used to deploy the whole infrastructure from scratch on any machine running Vagrant.
Vagrantfile describes environment configuration – stuff like VMs, shares, networking, etc.
Vagrantfile should be stored in VCS, such as Git – we’ll be able to share environment configurations within the team and switch between different environment versions.
Vagrantfile should be stored in the project directory, but if it’s not found there, vagrant will search for it in all dirs from project to / :
And for security reasons you might want to store Vagrantfiles in a private dir, in this case use environment variable VAGRANT_CWD to specify a path.
If you have a few Vagrantfiles, vagrant will automatically merge them, but it’s not really common practice.
We can generate simple vagrant file with vagrant init command, but we’ll construct our own configuration which would be a bit more complex.
Vagrantfiles are ruby-based, so it’s really easy to have a deal with syntax.
With Vagrant we can build and share reproducible and predictable environments using environment-as-code principles.
Vagrant can deploy both on-premise environments based on VirtualBox, VMware, Hyper-V, Parallels and cloud, such as DigitalOcean, Azure and AWS.
I prefer to use tools like CloudFormation to build cloud environments, so I’ll focus on on-premise in this post.
Vagrant can also work with Docker, but now we have native Docker not only on Linux, but also on Windows and OS X, so Vagrant can be used only for complex or legacy Docker scenarios.
Typically Vagrant is used to deploy infrastructure (servers) and Chef, Puppet or Ansible are used to deploy software to those servers.
You can find a full list of providers, provisioners and all other stuff here – https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Plugins
We’ve set up CloudFormation templates for EC2 and RDS, so far we’re ready to add necessary stuff for failover application deployment.
By necessary stuff I mean scaling, load balancing, monitoring, security and notifications.
Sounds great, so let’s take a look at template:
After we’ve reviewed CloudFormation template for EC2 let’s go on with MS SQL with Multi-AZ presence.
Database will be accessible only from default VPC with no Internet wide access.
In this example I want to show you how easily AWS resources can be created with CloudFormation templates.
So let’s take a look at template itself:
In this post I’ll show an example of simple automation task – we need to download 7z archive from SFTP, unzip it and restore the newest database automatically on a daily basics.
If we go bit deeper we’ll see a few more requirements:
- SFTP requires auth;
- 7z file is protected with password;
- We need to test every important step;
- We need to add permissions to a database;
- We can shrink transaction log to save some space;
- We we need to log every important step to EventLog;
- We want to get a nice report with time measures;
It’s clear now, so let’s get down to prerequisites.
In this post I’ll show how to setup Azure VMs turn off & on by schedule using Azure Automation which is really useful for cost saving.
We’ll use dozen of actions to manage this task.
However, not all actions can be managed with PowerShell, so we’ll use old Azure portal a few times.
Initially I used one big script, but for this demo I decided to split it to make things simple.
In this particular example I’ll use two VMs running in the same cloud service.