Tagging images and containers

[abbydrury]

Scope

Explore tagging images and containers in a versioned manner so that it is easier to detect what "version" of the container someone is running going forward in response to #7.

Implementation

Working with image tags makes working with docker compose slightly more complicated. This PR adds environment/docker-environment-common.sh to help abstract that complication away. Now, instead of lengthy and complicated docker compose -f ... commands, you can use:

• environment/docker-environment-common.sh build
• environment/docker-environment-common.sh up
• environment/docker-environment-common.sh start
• environment/docker-environment-common.sh stop
• environment/docker-environment-common.sh logs
• environment/docker-environment-common.sh down
• ./environment/docker-environment-common.sh version
• ./environment/docker-environment-common.sh tags

The Docker image tag takes the form datascience-notebook:${hash of the current commit in Git}. This is specified by image: datascience-notebook:$TAG in compose.yml; $TAG is set by the build command in environment/docker-environment-common.sh and saved in environment/image-tags.

You can see your container's version with ./environment/docker-environment-common.sh version, provided Docker is running and the container is built and running.

If the org.opencontainers.image.version value for your container matches that of a fellow researcher, you should be working from the same version of the Docker code.

Things to note

The tag refers to the latest commit. That's mostly good. When it might go weird is if work is done on a branch over time (leading to commits) and someone needs to rebuild the containers or set up on a new machine, they'll have a different image tag even if the environment hasn't actually changed...

If that behavior does not work, lead researchers can elect to either
1. Hard code a value for ${TAG} in environment/compose.yml This probably won't work because $TAG won't be set in environment/docker-environment-common.sh...
2. Possibly (untested) – change the retrieve_tag() function in environment/docker-environment-common.sh to (replacing x.x.x with the desired tag):

function retrieve_tag() {
  TAG="x.x.x"
  export TAG
}

This will more closely control the tag values across commits – the downside to this is that researchers will have to remember to manually change the tag value when the environment is changed.

TODO: add description of how implemented....

Future Work

None at this time

Testing

1. From the project directory, check out this branch.
2. Rebuild the containers and bring them up again: ./environment/docker-environment-common.sh build and ./environment/docker-environment-common.sh up
3. Open JupyterLab in the browser OR reload JupyterLab in the browser.
4. Check the image and container tags

To be completed by the person testing

• Docker image is tagged
• Docker container is tagged

Special considerations for making this live

• Remove log information from wiki; it's in the environment/README.md now.
• Add any required documentation around how to update the tag information, if applicable

[abbydrury]

Alternate idea: docker container ls -a will show you when you created the containers with something like this:

CONTAINER ID   IMAGE                                   COMMAND                  CREATED        STATUS                     PORTS                                                                     NAMES
c594073843c5   f095a4018bd7                            "tini -g -- start-no…"   3 weeks ago    Exited (255) 2 weeks ago   0.0.0.0:10000->8888/tcp, :::10000->8888/tcp                               environment_datascience-notebook_1

You should be able to see in GitHub when the Docker files were last updated for your project – would combining that information with the "created" date of the container be sufficient to understand whether a given researcher is running the latest version of the container?

[abbydrury]

Alternate idea: docker container ls -a will show you when you created the containers with something like this:

CONTAINER ID   IMAGE                                   COMMAND                  CREATED        STATUS                     PORTS                                                                     NAMES
c594073843c5   f095a4018bd7                            "tini -g -- start-no…"   3 weeks ago    Exited (255) 2 weeks ago   0.0.0.0:10000->8888/tcp, :::10000->8888/tcp                               environment_datascience-notebook_1

You should be able to see in GitHub when the Docker files were last updated for your project – would combining that information with the "created" date of the container be sufficient to understand whether a given researcher is running the latest version of the container?

Whoops, meant to tag @BeniamG there!