ericsysmin's DevOps Blog

Allowing ENV vars in Role/Collection Requirements

Allowing ENV vars in Role/Collection Requirements

If you have a private, or a repo that requires authentication, like in the case of GitLab Enterprise. You may find it difficult to simply pull without any auth your roles or collections from a repository. To do this I struggled for a while, and then realized that we can make use of the envsubst command.

First step we will need to have a template lets call it galaxy_requirements.tpl:

As long as you pass the environment vars to envsubst then it will work, in this case I am going to export the var just for command line sake, but ideally you’d put these in your build tool, either github, gitlab, or jenkins as a sensitive environment parameter to the job so that it does not get printed out.

Now lets put that somewhere in our build repo, and then during the pipeline steps (github/gitlab/jenkins) you will run something like this to resolve the token and run the ansible-galaxy install.

Using these two commands will create a new file galaxy_requirements.yml which would have the following contents.

This prevents you from storing any type of credential within the repository violating any security policies you may have.

Continue reading...
Using Ansible set_fact to generate lists of objects

Using Ansible set_fact to generate lists of objects

In some cases you may want to create nearly identical objects from a list of values, or another dictionary.

This was a commonly needed ability at VMware on the NSX ALB (Avi) team as for many of our infra, and for our customers have a list of servers that we needed to build into a list of dictionaries as we require more than just a specific IP.

This is how to do it (these are tasks, not the entire playbook)

So lets review what we did.

We created the servers_list fact, we set the default value to be a blank list and then for each of the servers in pool_servers separated by , we loop adding the dict {'ip': {'addr': item, 'type': 'V4'}, 'enabled': 'true'} to the servers_list.

This can be applied to any kind of situation where you need to create a list of complicated objects.

The returned output would look like this.

 

 

Continue reading...
Accessing Raw Files on Authenticated GitLab

Accessing Raw Files on Authenticated GitLab

Recently, I started working on more repositories on GitLab. One of the common items in my Ansible testing is the use of URL lookups in the templating of my Dockerfiles in Molecule. There’s a completely different method which requires the use of the GitLab API endpoints that require different formatting and token auth. The details for this can be found here: https://docs.gitlab.com/ee/api/repository_files.html#get-raw-file-from-repository

Searching around I did find that you can pass the token via the private_token parameter to the url.

Because you need to include the folder directory as an encoded value, I had to do lots of trial and error to figure out how to do complicated strings.

Formats like this, DO NOT WORK:

But after a series of attempts, THIS WORKS:

Some explanations of my findings urlencode filter did not work when used inline in the lookup, it made no changes to the file path. To separate, I had to split it out into a jinja set to set the var to a string that included the value using format() jinja filter, then take the result and create an encoded path to meet the encoded requirements of GitLab’s API.

 

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.

Requirements

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.
    zsh-shell-screenshot

Install of Oh-my-zsh

  1. Ensure that your terminal session is open and use the following command as per https://ohmyz.sh/#install
  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...
Ansible Collections: Testing only what’s changed

Ansible Collections: Testing only what’s changed

Previously

When testing roles before GitHub Actions, it was assumed that you’d only have one repository for each role. But with the addition of collections, that is no longer the case. Your collection can now have multiple roles, modules, and often you do not need to test everything when a role or a set of modules has changed.

Using GitHub Actions, there’s a way to do this.

Now with GitHub Actions

Using GitHub Actions and workflow, we can configure what actions will trigger a test (workflow) run. In my example, which I do use on all of my collections, I set only on Pull Request and Push will the tests be triggered.

So if you notice in the example, configured my test to run on both push and pull_request. Unfortunately, GitHub Actions doesn’t support anchors yet so I couldn’t use them.

Why did I choose those paths?

'roles/zabbix_agent/**'  – sets GitHub actions to watch all the files underneath the role zabbix_agent

'molecule/zabbix_agent/**'  – watches all the files part of the molecule testing for zabbix_agent

'.github/workflows/zabbix_agent.yml'  – the file that runs the GitHub Action workflow itself

The code here helps ensure that only when a file used for testing or executing this role is modified will it run and ensures that you don’t waste a lot of testing time on GitHub Actions so other tests can run on other repositories. You can find more options here https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#on

Continue reading...