Extract Docker images into own repo

[ionut-arm]

For both CI and local testing we make use of specific Docker images that offer all the dependencies/functionality that we need (e.g. SoftHSM library or TPM2 simulator).

While these are mostly used for testing at the moment, they could provide a good environment for users to try out their own integrations in the future.

The image definitions could be pulled into a separate repo and maintained there (the way the TPM2 guys do) and upstreaming said images to Dockerhub. This has the benefit of allowing direct usage of the images anywhere and greatly reduced CI build times.

[anta5010]

Should we also produce images with parsec deployed?

[hug-dev]

Agree with that! It would also remove the duplication of the TPM image we use in the TSS crate and in the service.

Do we care about publishing "testing" images on Dockerhub? Is it meant for all kind of images or only "production" quality ones?

[ionut-arm]

Do we care about publishing "testing" images on Dockerhub? Is it meant for all kind of images or only "production" quality ones?

Again referring to the TPM2 example, their images are for CI purposes. So that should be fine.

Should we also produce images with parsec deployed?

I think that would be a good idea when we figure out exactly how we want to deploy it. Would that mean a Docker image with a deployed service inside, but for which the customer has to provide the config file and libraries/handles for connecting to the hardware backends? And the container would outsource its socket(s) somehow

[anta5010]

I don't think parsec should be a service in the image. It should be run as a command instead.
I haven't thought about access to backends yet. The config and the socket can be bind-mounted. Something like this:

docker container run -d \
 --name parsec-service \
 -v "config.toml:/etc/config.toml \
 -v "/tmp/security-daemon-socket:/tmp/security-daemon-socket \
 parsec-service \
/usr/bin/parsec --config /etc/comfig.toml

[anta5010]

we might provide separate images for each provider for example. Do we expect cases where more than one provider would be required from the service (except CI/testing)?

[ionut-arm]

I don't think parsec should be a service in the image. It should be run as a command instead.

Yes, sorry, that's what I meant!

I think we can provide one image that has all the dependencies and the admin just links in and configures the desired one(s)

[anta5010]

I don't think parsec should be a service in the image. It should be run as a command instead.

Yes, sorry, that's what I meant!

I think we can provide one image that has all the dependencies and the admin just links in and configures the desired one(s)

I'm not sure. What's the point to include libraries which won't be used? I think we should try to create as small images as possible. i.e. separate images for different backends.

[ionut-arm]

I'm working to build a container image that can be used for all our CI tests (well, for the service, at least). This will be a fairly large image as it requires dependencies for all different providers, but will be published in Github's container image registry and simply downloaded (instead of built) for every CI run. This should save us a lot of build time.

I'm unsure about whether I should simply publish the individual provider images as well (at least for PKCS11 and Mbed Crypto). The images would be much smaller, so quicker to download. But at the same time, there would be more than one image to maintain and there would be duplication between those ones and the all-providers image. Thoughts on this?

[hug-dev]

One year later 😄
I would be ok to only have one image, as it would be easier to maintain.

[hug-dev]

Done with #357