In the previous post I wrote about our pre-chef approach for instance bootstrapping.

Today I will explain the process of our migration to Chef. I’m sure that could be useful for someone down the road, who’s trying to travel on similar route.

Starting point

At the time of the migration we had about 35 AWS instances of different sizes and roles, all of those eventually will need to be converted to Chef.. Lots of time will be spent going through the boxes and figuring out what’s installed and running there, so it could be converted into the Chef recipes.

So I went ahead and installed open source chef-server 11 ( at the time of writing, use newer version if available ). There is also hosted version provided by Opscode if you don’t want through the hustles of installation process. Thankfully that process wasn’t so complicated, just follow installation steps from the Chef site.

I remember spending a lot of time trying to figure out post installation problem, but unfortunately don’t remember what it was.. Something related to install paths inside chef embed on the chef server, so I think I modified some config files there. Just be aware.

Another interesting thing about chef install is the way it’s packaged, everything that needed for Chef-server to function comes bundled and configured, including solr, nginx and other required soft. Very clever.. Moving on

After that part is done I needed to configure my workstation, so I could actually do some useful stuff with Chef. You probably heard, or even tried famous knife command – yes, that will be installed as part of chef-client install.

The most important part is omnibus installer ( that neat prepackaged thing again )

curl -L http://www.opscode.com/chef/install.sh | sudo bash

Anyways, I just followed those steps in the tutorial and got chef-client installed on my workstation. Great!

Chef layout

Now, I have to confess, I did play with chef-solo beforehand, so I had some initial experience with Chef philosophy.

Couple things bothered me at the moment, one of those things was the process of community cookbook modification. I did some research on the topic and two posts stood out to me during the process. First – Chef Patterns and Anti-Patterns, another one is How to write reusable cookbooks, Gangnam Style. I highly recommend to get familiar with those materials as they flesh out a lot of really useful Chef concepts. Great materials!

Most important things to take out:

don’t set / override cookbook attributes in the role or environment – those are not versioned, that could bite you in the ass during testing and rollout. Use custom cookbooks for that and version them!

don’t modify community books directly – that will create a mess in your repo and you may get stuck with those modified books without upgrade option. Fork and submit pull requests instead. Yay!

don’t use chef roles as a place to specify all cookbooks required for it to function. Try to keep roles clean as possible. Encapsulate role specific logic (attributes, community recipes with include_recipe) into custom cookbooks you can version and deploy in steps.

Chef package managers

You probably used package managers before, things like apt, yum, npm, gem, bundler, composer. Guess what? – there are couple solid packaged managers for chef as well. Two of the most popular ones are Librarian Chef and Berkshelf.

I already hear screams like “Which one is better?”. I personally have no idea. Google or read some blog posts, but don’t get too crazy – just pick one and go with it.

I chose Librarian Chef and have no problems with it so far, just for the argument. ))

Having this tool I can simply specify cookbooks I need for the project in the Cheffile, including versions and stuff, even point it to the particular github repo (which turned out to be extremely useful in case you need to fork a book on github and point your Cheffile to your fork, while your pull request is not merged to the upstream ).

Back to chef repo layout

If you followed workstation tutorial I mentioned above you should have something similar to this:

Every folder here should be pretty self explanatory. One thing I want to expand on is .chef folder. In the tutorial it’s recommend not to commit this folder to the repo and there is a good reason for it, you don’t want your sensitive data (keys and stuff) to end up in the repo. That’s why we added it to .gitgnore.

This doesn’t really scale well when you are working in the team, where you knife configuration needs to be shared. Here is great post by Joshua Timberman called Local-only Knife Configuration

I helped to build and maintain the infrastructure for Game of Thrones, the biggest and most popular show in the world.

Do you want to know the single most important thing that I learned over the years?

NONE OF IT REALLY MATTERED…

Yes, it was fun for a while.

Yes, like most of us engineers I was making good money.

But at the end of the day, I would still have to show up at work and sell my time.

Sometimes I would come in, sit in my cubicle and dream about things I could do instead of staring at the screen all day long…

I could go to the beach with my wife and my son.

I could fly to El Classico game in Barcelona with my brother and watch Messi scoring amazing goals.

I could organize a surfing trip to South Africa and other awesome places around the world. Places I’ve never seen.

I could work on my own projects that would make the impact in the world or at the very least, make me some money.

Hell, I could just sit home and do absolutely nothing!

And yet there I was still in my cubicle 12 years later with big hopes and dreams and pretty much nothing to show for…

Sounds familiar?

The tipping point for me was when I started buying games on Steam and GoG and playing them in my mind.

Nothing to install, no need to upgrade video cards, no need to feel bad in front of my wife, no time to waste…

You are right, I was spiraling down and needed a break, but more so I felt like I needed some radical changes in my life.

I’m sure you heard this saying before: “Insanity: doing the same thing over and over again and expecting different results”

It became clear that the road I was walking on would lead me to mediocre life.

The problem was that I didn’t want to be mediocre. I wanted my life to be awesome, full of fun, happiness and excitement!

I wanted to make a difference in the world, leave a legacy, make my kids proud, live without regrets, discover my true purpose.

So about a year ago, I set out on my new journey…

I left my old comfortable job, attended multiple high profile non-technical events (including Tony Robbins UPW), joined an expensive business program, hired a personal coach and mentor, met a bunch of people who were able to disconnect from the Matrix and never looked back.

And let me tell you – there is another world out there, something we technical guys don’t get to experience!

There is hope.

Now, here is my question for you:

Do you want to continue to be just a tool in someone else’s hands or you want to upgrade yourself and become a Rain Maker?

If you want to find out who you really are, take full control of your life, step outside your comfort zone in order to grow physically, mentally and financially and help others along the way, then the Red pill is for you. Just drop your email in the field below and we’ll be in touch.

Take a Blue pill and you will forget that we ever met. You will close this popup and continue reading articles about Nginx, Kubernetes, Docker, secretly dreaming of life that you could have… (or pathetically thinking that you will have it one day just by perfecting technical skills)