ericsysmin's DevOps Blog

Configuring Docker Desktop on WSL2

Configuring Docker Desktop on WSL2

First steps, you’ll need to install and configure WSL2. To install WSL2 you can use the Microsoft Store or follow these instructions:

Then to install Docker to run on Windows and WSL2 you’ll need to follow these instructions:

During some testing and trying to simplify my WSL2 environment I stumbled upon an annoying issue that prevented me from running docker ps each time I attempted to run docker ps I’d receive the following error.

To get around this issue you’ll need to run the following commands:

Once those are ran you should be able to run docker without hitting permissions errors.

Those commands are adding/ensuring that the docker group exists and adding your existing user to the docker group. It then modifies the docker.sock to allow the docker group access to the socket.

Continue reading...
Installing ZSH on WSL: Ubuntu

Installing ZSH on WSL: Ubuntu

Having moved away from development of Ansible/Python/Terraform, and others on Windows a few years ago. I’ve heard that WSL has become much better, especially with its support of VS Code now that they have a WSL connector. So, I decided to give it a try.

However, I did run into one surprising inconvenience, BASH! I have become so accustomed to ZSH over the years on Apple and using oh-my-zsh that all my shortcuts and quick ways to doing things just weren’t there.

I did attempt to use oh-my-bash but there just aren’t the number of plugins already to support the plethora of plugins I need and use on a regular basis. So, next logical step is to install ZSH on my WSL: Ubuntu system.


WSL with Ubuntu installed

Steps to install ZSH

  1. Install ZSH.
  2. Verify that ZSH has been installed on the system.
  3. Set ZSH as your default shell.
    NOTE: This used to require modifications to the shortcut to access WSL but in newer versions of WSL you can use the following.

    For older versions you will need to modify the shortcut to WSL and use the command:

  4. Once you close and reopen your WSL Ubuntu shell you should now be in ZSH shell.

Install of Oh-my-zsh

  1. Ensure that your terminal session is open and use the following command as per
  2. You should now be able to configure your oh-my-zsh installation by modifying your .zshrc file and enable any plugins you need.
  3. The final result! 🙂 

    Screenshot of oh-my-zsh on WSL: Ubuntu


Hopefully that helps, I know it helped me as I venture back to Windows for development of my Ansible playbooks and other tools.

Continue reading...

Deploying Modules as an Ansible Role

As Ansible grows as solution for much of the DevOps community many partners and supported modules are hitting the community. However, all of us are being hit by a serious problem. Release Gap.

Release Gap is the difference of time between your modules being accepted into the Ansible core and the time you release a new feature or patch you want your customers to use.

At Avi we ran into this problem, and luckily Ansible has a solution. Roles. Using roles to deploy your modules helps you control your code and guarantee customers are using the latest tested modules you offer.

To do this we need to have a role structure as such.

However, users will need to include the role in their playbook.

However, there are some caveats. Your module names should never be the same as modules that someone else, or core uses. In our case we stuck with avi_<module-name>  for our modules.

A good way to look at the pipeline is the following.

Using this pipeline you can then import your modules into the core, but also pre-release or release modules at your own schedule and version, independent of Ansible release schedule. You can also allow users to upgrade their environments.

Users can then download your modules using the following command.

You can also specify version so your end users can control versions of your modules

The goal of this was to empower the partners, supported modules to be downloaded by customers without having to force customers to also upgrade Ansible itself which can affect other modules that are working for all playbooks.

Continue reading...

DevOps Really…..

What is DevOps?

DevOps is not one thing, its a plethora of ideas, and practices that have revolutionized Operations and the Release Process. It’s a culture change. DevOps is using development practices and applying them to operations. Then using those methods to automate everything.  It starts to join both Operations and Development together, consider it as a hybrid, I mean it is DevOps, it’s the joining of Development and Operations. DevOps was created to empower developers to quickly integrate and build environments to test code, and allows the operations teams to quickly deploy and monitor applications just as fast as the developers and QA teams can approve it, thus leading to Continuous Integration and Continuous Deployment. DevOps teams that I have started tend to do well with another great practice called Scrum, which are just as important to operations as it is to development, if you don’t believe me try it for a month, then see how effective your team starts becoming. As you may have noticed many of these things are part of Agile practices, if you aren’t familiar hopefully reading and following this blog you will be. DevOps and Agile go hand in hand. DevOps helps reach the goals of Agile effectively, also much easier. You don’t want Operations to be a blocker….that looks bad…wait…it looks really bad.

Some extremely popular concepts come into play here.

  • Scrum
  • Operations Early
  • Infrastructure as Code
  • Automate Everything
  • Test Driven Development for Ops (CircleCI, TravisCI, etc.)
  • Integrated Operations
  • Pets vs. Cattle

Over the next few weeks I will cover all of these, and hopefully more. There’s just way too much to type up in one blog post, and all of it is important (I mean there’s entire books written about this stuff, there’s even series of books written about these practices).

Continue reading...