Upgrading Ansible AWX

What a frustrating exercise to get to do something so simple!

I’m running Ansible AWX 14.1.0 as a local docker install. The installation did all the hard work when I initially installed it. It build the docker-compose.yml for me from information I fed it in the inventory file. It’s been running flawlessly, but it’s about time I did an upgrade.

Wow! It wasn’t that long ago I installed it and it’s moved from v14 to v17 already. Better read up on the upgrade process. Wait a minute, where is the upgrade process? I can see how you install it. A bit of duck-jitsu and I’m finding github posts about the upgrade process being frustrating and going into loops and just edit the docker-compose.yml and change the version, do a docker-compose pull and re-up the container.

Ok, let’s see what happens. Change the version do a pull. Yes that’s seems to be starting – oh, wait it’s in the upgrade loop wait 5s as in the issues. Let’s back out of that and see if we can make more sense of how this works.

Bash Linting

I had some of my bash code commented on publicly and the one comment was “You should run your scripts through shellcheck.” This was probably the most useful bit of advice I’ve had to do with bash scripting.

You’ll maybe note that previously I’ve used linting for php and JavaScript and that’s been immensely helpful for keeping my code tidy and correct. Well shellcheck helps do the same thing but for shell scripts.

The thing I found most useful was not the fact it picked up errors, but that it makes coding suggestions. The suggestions lead you to instructive pages that actually teaches you how to code better.

What makes this equally easy to use is there is also an extension for VSCode that actively lints as I code.

https://marketplace.visualstudio.com/items?itemName=timonwong.shellcheck

Prosody Debugging

After building an ejabberd container set I’m continuing my foray into the world of xmpp by looking at prosody. I’ve run into a few man traps along the way and thought I’d document some of my failings to act as a catch all for search engines to help others with similar issues.

Nginx Maintenance Mode

We use a simple method of putting an Nginx site into maintenance mode. Just set a geo default variable on on and have it generate a HTTP 503 status response. Then Nginx delivers our maintenance page until we set it back to off

nginx.conf

geo $maintenance_SITE {
    default off;             # Set to 'on' to enable maintenance mode
    123.123.123.120/29 off;
}

upstream maintenance {
    server maint:80;
}

server {
  listen 443 ssl http2;
...
    if ($maintenance_SITE = on) {
        return 503;
    }

    error_page 503 @maintenance;

    location @maintenance {
        rewrite ^(.*)$ / break;
        proxy_pass http://maintenance;
    }
...
}

By using a geo I can add in our own ip addresses (the /29 range) so everyone but us, gets a 503 maintenance redirect. This way we can continue testing things as if the site were still live.

Load Testing with Locust

This has been a very tough few days. I was asked to build some load testing scripts for use with Locust. I was told “How hard can it be? Just a few scripts to poke a web site.”

The actual involvement requires investing in Python and digging deep into the chrome developer window to capture form data and parameters to use in the testing.

Back in the day of unit testing with Laravel I used Dusk which loaded a browser and automated it to carry out the tests. I was expecting that kind of thing here. No, take a step further back and look at PHPUnit testing and that’s more like how things are scripted for Locust.

With a browser you connect to a website, navigate around and the browser handles all of the session data and form submission type things. With Locust we are back to making our own http/json client calls to urls passing data and parsing responses. Unless you are testing a simple page hit you’ll need to process the returned HTTP Response to really act like a visitor and not a search robot.