From Jamf to… Well, Something, Part 3.

It’s been a year and change since I last wrote anything on this blog. Since then, a lot has happened.

  1. I changed jobs.
  2. I’m not deploying Chef anymore (or maybe I am. Or not. Ask me again in three months).
  3. I’m not an engineer anymore (except when I am).

That last one is perhaps the biggest change in my situation. Sometime last year I accepted an offer to manage the Client Engineering team I was part of. When I switched jobs this year, I got hired into a broader IT Manager position.

I now work for a startup in Silicon Valley (with those sweet, sweet stock options or something), running a decent chunk of employee-facing IT resources, from Help Desk (which I promptly renamed to something more appropriate) to SaaS/DaaS services, to AWS things. Which, sadly, has led to precious little time to do much engineering.

Yet this has brought some new opportunities. For one, this place is a Munki/AirWatch/Jumpcloud shop. For another, I have considerably greater free reign to do a few things I wanted to do before (more on this later).

So, step 1? Move Munki to AWS. Which I promptly started to do by creating a new VPC, setting up EC2 servers, an ELB for the front-end, a staging server, GitHub repos, all that good stuff. In the meantime I started learning a bit of Terraform because that’s what DevOps here uses and I plan on Terraforming my AWS setup once I learn enough to be comfortable (more on this later too).

Then yesterday one of my colleagues sent me this tweet from Graham Gilbert.

Side note: the “other things” Graham mentioned was his Movember campaign which you should absolutely support. I did.

The blog post is short and to the point, and made me smack myself in the head. I know a bit of Terraform. Why didn’t I just go this route to begin with?

My planned infrastructure can easily be adapted to Graham’s setup. I want our Munki repo git-controlled and, more importantly, I want my people to work in their own branches and do pull requests to a Staging branch. Then, once I approve the changes, they set up a second pull request to merge said changes from Staging to Master. Deploy keys are then used to automatically pull the updated Master repo into our prod instance and then it’s made available to the world.

This is easily adapted to Graham’s setup by then having the awscli tools running on the ‘prod’ EC2 instance which can then sync everything over to the S3 bucket.

So, next step: sketch all of this out in Terraform. Which I’ll get right on this weekend.

Leave a Comment

Your email address will not be published. Required fields are marked *