DevOps @ LogicGate As a backend engineer at LogicGate I’ve been tasked with creating a DevOps workflow for provisioning our applications on AWS in an automated way. Previously, we used a combination of CloudFormation templates, shell scripts, and a bit of Node. I wanted to a process that makes it easy for developers to test on a laptop but also easy to deploy to EC2 instances.
A foray into DevOps Before getting into DevOps formally I used a combination of Chef scripts, shell scripts, and Vagrant to do my DevOps.
Curse of the Polyglot Most Jenkins environments I’ve seen are very homogeneous - a Java shop, a Ruby shop, etc. My projects are anything but. Looking at my machine I’ve got:
Java 6, 7, 8 Python 2.7, 3.5 Ruby 2.2.3 Keeping track of each of these versions on the Jenkins server would be a pain. Its easier to containerize the build environment.
Installing Docker To build and start our build container we run the following commands:
Why CI a simple blog? Just like we write automated unit tests for our applications, anything we’re pushing to the Web should be stable and we’re confident we didn’t break our site with an errant //JS or <HTML> tag. To do this, we’ll attach an integration service listening to our commits to the master branch.
Choosing a Platform Since I’m running my blog outside of Github Pages, I can’t depend on integration servies such as Travis CI and Github’s ecosystem of integrations.
Welcome to the inaugural post of mblum.me. I figured a good start to this blog would be a series of posts on how this blog can to be: from development to production.
Why use Docker? A valid question. Looking at the Jekyll Quick Start it should be as simple as:
gem install jekyll && jekyll serve What I found to be difficult as when more gems came into play or my version of Ruby on my host machine was wrong (my Linux workstation has an old Ruby install).