Containerize application and configure GitHub Actions to build and push Docker image to Harbor

[VKTB]

Description

This PR adds a Dockerfile which can be used to build a Docker image and create a container using it. It is configured to create a production image and run a Gunicorn server on port 8000 when a container is started.

To add an extra layer of security, the image has been set up so that containers run as non-root.

Environment variables have also been defined in the Dockerfile to allow for values to be passed at runtime to future running containers. These values are then used by the docker-entrypoint.sh script, which acts as an entry point script that is executed when the container starts, to update the config values in the config.yaml file. The environment variables are:

• ICAT_URL (Default value: http://localhost)
• ICAT_CHECK_CERT (Default value: false)
• LOG_LOCATION (Default value: /dev/stdout)

Finally, this PR adds a docker job to the ci-build GitHub Actions workflow to build a Docker image using the Dockerfile introduced in this PR and push the same to Harbor. The job only triggers if all the other jobs succeed and does different things depending on the context. It builds the Docker image in all cases and also pushes the image to Harbor only if something is pushed to the main branch.

To build an image, run the command below in the datagateway-api repo directory

docker build -t datagateway_api_image .

To start a container on port 8000 from the image that you just built, run:

docker run -p 8000:8000 --name datagateway_api_container datagateway_api_image 

If you want to pass values for the environment variables then instead run:

docker run -p 8000:8000 --name datagateway_api_container --env ICAT_URL=https://127.0.0.1:8181 --env ICAT_CHECK_CERT=true --env LOG_LOCATION=/datagateway-api-run/logs.log datagateway_api_image

Testing Instructions

Add a set up instructions describing how the reviewer should test the code

• Review code
• Check GitHub Actions build
• If icatdb Generator Script Consistency Test CI job fails, is this because of a deliberate change made to the script to change generated data (which isn't actually a problem) or is here an underlying issue with the changes made?
• Review changes to test coverage
• Does this change mean a new patch, minor or major version should be made? If so, does one of the commit messages feature fix:, feat: or BREAKING CHANGE: so a release is automatically made via GitHub Actions upon merge?
• GitHub Actions should build and push an image to Harbor when this PR is merged

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: -2.02% ⚠️

Comparison is base (c503f9c) 96.80% compared to head (378ab9b) 94.78%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #426      +/-   ##
==========================================
- Coverage   96.80%   94.78%   -2.02%     
==========================================
  Files          40       40              
  Lines        3375     3375              
  Branches      317      317              
==========================================
- Hits         3267     3199      -68     
- Misses         80      135      +55     
- Partials       28       41      +13     

see 11 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MRichards99]

Your CI failures look similar to what we've seen on OG API. Have a look at the PR I made to fix the issues: ral-facilities/operationsgateway-api#59. The Semantic PR job seems to be working so that's good

[VKTB]

Thanks @MRichards99. From the PR that you linked, it looks like upgrading Poetry to 1.3.2 fixes this issue. However, I just had a look at Poetry's release notes and noticed that they dropped Python 3.6 support in their 1.2.0 version (see more here) and this project still supports 3.6.

[MRichards99]

Ah yes, that's true. Having to support Python 3.6 is becoming a bit of an issue, there's so many dependencies that need upgrading but we can't as future versions drop 3.6 support (as you've experienced with Poetry).

The root of this issue seems to be relating to a dependency called cachecontrol, read psf/cachecontrol#292

You could try pinning urllib3 as per psf/cachecontrol#292 (comment) but lots of people saying that doesn't work. You could also try the same with requests as per psf/cachecontrol#292 (comment) but again, lots saying that doesn't work.

There's a brief discussion where someone is tied to a Poetry version < 1.2 at python-poetry/poetry#7877. I don't fully understand what's being discussed here and how we'd translate that into our repo but could be worth a try if you can work out what to do.

We really need to move to support 3.8+ on this repo, but we can't until we can get 3.8 on a RIG VM/Docker for production 😢

[VKTB]

Thank you @MRichards99. I think I somehow fixed the failures in #427. I agree, though, that we need to drop support for the older Python 3 versions.