Category Archives: Automation

Jenkins and GitHub integration

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!

Continue reading

Vagrant with AWS and PyCharm / Visual Studio Code

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.

Continue reading

Vagrant for DevOps: Boxes

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.

Continue reading

Vagrant for DevOps: Vagrantfile

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 / :

Screen Shot 2016-05-25 at 17.02.05
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.

Continue reading

Vagrant for DevOps

vagrant_chillingIntroduction

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

Continue reading