Reworked docker docs

[regularfry]

Description

Minor (but important!) changes to how docker is run, DOCKER_IMAGE handling, and some docs.

Context

This change wraps up a few different changes I needed to make when using the template.

Docker context

Here we were cding into the infrastructure/images/whatever directory before running Docker. That restricts the docker context to only that directory and below. You can't COPY ../../. . or whatever because that's treated as a security problem.

This meant that you couldn't put your application code into a container inside the infrastructure/images structure. That's fine if you've got a single application container, and if you're happy with it living at the root of the repo, but as soon as you've got more than one it gets a bit messy (and I've never liked things that clutter the repo root at the best of times).

The change I've made gets rid of the cd in and out; docker is always run from the repo root. That means paths in Dockerfiles are relative to the root, not to themselves; same with .dockerignore (which I've made optional so that it doesn't break if there isn't one).

$DOCKER_IMAGE variable handling

Minor tweak but a good quality of life improvement here. If you specify $DOCKER_IMAGE to the make docker-* tasks but not $dir then it defaults $dir to infrastructure/images/$DOCKER_IMAGE. That means the make invocation, the filesystem, and the docker image list are all synchronised to the same name, by convention.

Updated docker usage docs

The example in the existing docs was specific to repackaging a third party tool, but gave no guidance about how to package your own application code. I've rewritten the Quick start section to show packaging a trivial python script. I'm a little worried that the docs are a bit repetitive now, but I don't think it's worth reworking right now.

I've also removed the python example code. It was a good start, but in practice having the tutorial docs is better because what I want to know as a new user is where to put my own stuff, and the example wasn't a huge help there and in fact was a bit of a confusion.

Type of changes

• Refactoring (non-breaking change)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would change existing functionality)
• Bug fix (non-breaking change which fixes an issue)

Checklist

• I am familiar with the contributing guidelines
• I have followed the code style of the project
• I have added tests to cover my changes
• I have updated the documentation accordingly
• This PR is a result of pair or mob programming

---

Sensitive Information Declaration

To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

• I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.

[stefaniuk]

A lot of good work went into this. The manual reads well. Approving this PR.

Some suggestions:

• Could we arrange for collegues who use the repo template to give us a feedback on the usage of the Docker module? I may ask the screening DToS team. We are also planning to implement devcontainers which may benefit from some of the functionality here.
• All the new docker scripts, can we include them in the scripts/docker/tests/docker.test.sh test suite?

[stefaniuk]

LGTM