Both Jenkins and GitHub are very popular, so it couldn’t be a problem integrating them. It still might be a bit confusing if you’re doing it for the first time. That’s why I decided to spend a few minutes to show you guys how it can be done.
Jenkins master can be accessed through the URL different from the one specified in Jenkins configuration.
Why might we need this? Well, you probably want your Jenkins server to be publicly accessible (this is required for GitHub integration, by the way) and since it’s public you typically want to use an encrypted HTTPS connection.
Well, you can install nginx proxy to achieve this, but in this case you’ll have to maintain SSL certs, which obviously sucks, especially if you can use AWS Certificate Manager with AWS ELB.
Another reason to use different URL is to save your time. When you use Windows slaves via JNLP there’re well-known issues with both nginx and load balancers.
And the last but not least reason is that “LAN” connection between Jenkins master and slaves is still more secure and faster, so it’s preferable in most cases.
So let’s start implementing Jenkins and GitHub integration within these conditions!
Vagrant is awesome tool for creating and sharing environments running in VirtualBox, Vmware, Hyper-V, etc.
But nowadays we may need to run AWS Linux as well as CentOS, Ubuntu and Windows.
Powerful IDEs such as PyCharm can wok with Vagrant machines, which is really useful, e.g. while debugging scripts.
So in this post I’ll show you how to do it.
In one of the previous posts I explained how to create a custom box running Windows.
So in this post I’ll show how you can create your custom box running Linux – both CentOS and Ubuntu.
I won’t use Packer in this example – just regular VirtualBox and shell commands.
Here’re some basic steps to create a custom vagrant box with Linux:
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: