My GitHub, Vagrant and Docker Updates

I thought I would post an update about some of the things I’ve been doing that don’t necessarily fall exactly in line with my normal website content. All of it can be found on my GitHub.


Once the ‘bento/fedora-29’ box was released I created a Oracle 18c on Fedora 29 build. If you are interested in that sort of thing you can find it here.

A few of the other Vagrant builds have been updated to use the ‘bento/oracle-7.6’ box. I’ve run through them all and they seem to be fine.

As part of a recent question, I ran my RAC builds on Windows 10, Oracle Linux 7.6 and macOS Majave hosts. They all worked fine, with no drama. I also tried them with less memory than before, as my MBP only has 16G of memory. It worked fine. I updated some of the “” files to reflect these tests, and the option to use less memory.

I’ll be doing some stuff with Data Guard soon, so I will probably update those builds to use the latest ‘bento/oracle-7.6’ box and maybe neaten up anything that annoys me along the way. 🙂

All the Vagrant-related stuff can be found in this GitHub repository.

I’ve always assumed Vagrant was so simple it didn’t really require much in the way of explanation, but I was discussing it with someone from work, and figured it was worth a short post to explain a few things, just to save me having to repeat myself, so here it is.


I’ve done a few random things on Docker recently. Nothing particularly earth-shattering, but maybe worth a mention.

At UKOUG last year (a month ago 🙂 ) I was speaking to Roel Hartman about some stuff he mentioned in his Docker session. As a result of that I had a play with Portainer and Docker Swarm. I know Kubernetes has won the container orchestration war, but Swarm is so simple and does most of what I need.

I also needed to make some changes to my DB and ORDS Docker images to make using host directories as persistent volumes a little easier. I wrote these up as some short posts.

All the Docker-related stuff can be found in this GitHub repository.

As always, I feel the need to mention I’m not an expert in this stuff, and I don’t consider any of is “production ready”. It’s just stuff I’m playing with to learn the tech. If you find it useful, great. If not, that’s OK too. 🙂



Why Automation Matters : Consistent Test Environments

I’ve already made this point in a previous post, but I thought it was worth mentioning in a little more detail.

One of the neat things about automation is it gives you the ability to quickly build/replace test environments, so you know you have a consistent starting point. This is especially important for automated testing (unit, integration etc.), but it also applies to your learning experience.

I’m currently learning about a bunch of Oracle 18c new features. Some of those features are limited to engineered systems and Oracle Database Cloud Services. Not to worry, there is a little hack that gets you round some of those restrictions for testing purposes.

alter system set "_exadata_feature_on"=true scope=spfile;
shutdown immediate;

In some cases I’m enabling extended data types. I’m also building additional test instances, and multiple test users, each requiring different levels of privileges.

So I finish learning about feature X and I move on to learning about feature Y. What am I bringing along with me for the ride? What problems will I run into, or not run into, as a result of the hacks I put in place for the previous test? I have no way of knowing.

This is where automation comes in really useful. You can quickly burn and build your test environment and start with a clean slate. This can also be really useful to check your understanding, by rerunning your tests on clean kit. Did you really remember to write down everything you did? 🙂

It’s kind-of obvious I know, but it’s really surprising how often I’m rebuilding my testing kit these days. I’m literally talking multiple times a day just when I’m messing about with stuff. Earlier in the week someone asked me a question about RAC builds and I did the following in a 3 hour period, while I was doing other stuff. 🙂

  • Oracle 18c RAC build on a Windows 10 host.
  • Oracle 12.2 RAC build on a Windows 10 host.
  • Oracle 18c RAC build on an Oracle Linux 7.6 host.
  • Oracle 18c RAC build on a macOS Mojave host.

There’s no way I could have contemplated that without automation.

When you are learning new stuff, the last thing you need to worry about is being thrown off target by crap left over from previous tests, so just start again with a clean slate!

Check out the rest of the series here.



PS. I know sometimes you can learn interesting stuff by making mistakes, like finding out that feature X and feature Y are incompatible, but I think you should approach those sort of tests in a controlled and conscious manner. Learning the basics first is far more important in my opinion.