How to make Chef not unbearably slow on Windows

Last year, I was tasked with implementing “Chef” at work. It’s an impressive tool set, and I recommend you check out out (https://www.chef.io/). However, one of the things I noticed right off the bat is how poor the performance is on windows. From what I’m told by the developers, this is mainly because it’s based on Ruby, and the Ruby on Windows implementation is just dog slow. For those of you who don’t know me, to say I’m a little impatient is an understatement. Couple that with a mad case of ADD, and the excruciating wait times when trying to do anything in Chef was not conducive to me getting anything worth while done.

If you don’t care about the history, and just want to see the solution, click here!

Solution #1 – Ubuntu/SSH/Samba Shares

We had a decommissioned web server in our data-center. I installed Ubuntu on it and mapped a drive from my Windows machine to my Chef repository. This worked, but the IntelliSense in VS Code updated way too slow to be useful.

Solution #2 – Ubuntu Desktop/Remote Desktop

I installed Ubuntu Desktop on that same decommissioned web-server and used No Machine to remotely work in VS Code on the recipes. Now VS Code is accessing the files locally, and I still have a nice VS Code GUI with IntelliSense to help me with my recipes. (Side note, No Machine is a pretty amazing, free, cross platform remote desktop solution).

This solution is what I’ve used for the last 18 months or so, and it has worked pretty well. Other than the typical sluggishness you experience when using remote desktop software, it was a satisfactory solution…but, this week, I wanted to make it better.

Solution #3 – HyperV/Ubuntu VM/Windows Shares

I had this solution working, and it was working fantastically, with a few annoyances. One, while my desktop (the HyperV host) has a VPN connection into our data-center, the VM couldn’t see/use it. I was able to work around this by opening a second VPN connection in the VM. I was happy with how this was working, even if some parts of it were a little inconvenient. While I was finishing it up and starting to create shortcuts/scripts to make this usable and efficient, I had an idea. Something I’ve been playing with for the last couple of weeks…Docker!

Solution #4 – Docker Container

Sometimes the best solutions are the easiest to implement. It took me all of about 2 minutes to run a docker container and test it. After I saw it worked, and the speed was good, it was time to polish it up a little.

Step 1 – Create the image

FROM ubuntu

RUN apt update && \
    apt -y install iputils-ping dnsutils net-tools curl nano

COPY ./chef-workstation_0.5.1-1_amd64.deb /chef-workstation_0.5.1-1_amd64.deb

RUN dpkg -i chef-workstation_0.5.1-1_amd64.deb && \
    apt -y update && \
    apt -y upgrade && \
    rm chef-workstation_0.5.1-1_amd64.deb  && \
    apt autoremove

Step 2 – Build the image

docker build -t chefworkstation .

Step 3 – Create a powershell script to launch it quickly. I’ll use this script to have multiple “sessions” open. Although the sessions are technically independent containers, I’m using a shared persistent storage space.

if ( ! (Test-Path .berkshelf) ) {
    New-Item -ItemType Directory -Path .berkshelf
}

docker run --rm -it `
    --mount=type=bind,source="$(pwd)"/knife,target=/root/.chef `
    --mount=type=bind,source=D:\Projects\Infrastructure\chef,target=/chef `
    --mount=type=bind,source="$(pwd)"/.berkshelf,target=/root/.berkshelf `
chefworkstation bash

Step 4 – Use the new container!

./chef.ps1

Here are some comparative results. I timed a couple operations and took screenshots of them in both containers and not on both my home workstation and my desktop at the office.

Looking at the data in a table like that, makes me realize just how impatient I can be. It doesn’t seem like much, but it adds up quick!!! Not to mention, now I can work on all my files locally, and use all the tools I’m familiar with in Windows, an environment I’m much more comfortable in. This should be a huge boom in my productivity.