Consistent, publishable docker image

[mchangrh]

Derived from #171

Currently the docker containers and implementation is inconsistent and the current container built is meant to be used as an interactive shell or for running tests. Having a publishable ready-to-run docker image would be beneficial and more convenient for users who want to run it without ruby, since ruby applications cannot be converted to binaries. This would look something like

docker run -v ./backups:/data -v ./config:/config joeyates/imap-backup

When pointed to a directory with a config file, it would automatically run imap-backup and back it up the the /data directory

The points I was trying to address in the PR were

• a consistent bundler version between docs and container
• a runnable docker image that can run with a mount to a config.yml instead of interactive shell
• a smaller docker image built on a smaller base (alpine Linux) and more strict with ignored files
• seperation and distinction between the testing container/stack and a production container while hopefully maintaining compatibility and consistency

The docker image is a slightly larger departure from the project, but if possible I would like to at least help clean up the docker documentation and add alpine Linux to the testing matrix to hopefully show off its advantages in speed and size.

[joeyates]

Hi @mchangrh

Thanks for opening the issue.

I think having an imap-backup image that can be run with only Docker as a dependency is a great idea.

Note that as preparation for this work, I have moved the Docker-related development files to the dev directory in the main branch.

A few notes:

• I think the image can be published to GitHub Packages. I suggest using this commit and the others that follow as a guide,
• I don't think a docker-compose.yml is necessary, we should be able to run the container image directly, e.g.

  docker run ghcr.io/joeyates/imap-backup:release

• The idea of having a data and config directory looks good. The config.json file can then reside in the config directory.
• The ENTRYPOINT configuration will need to indicate the path of config file, i.e.

ENTRYPOINT ["bundle", "exec", "imap-backup", "-c", "/config/config.json"]

• I propose putting the new Dockerfile in a new container directory under the project root,
• ...there will also be a .github directory with the configuration for the GitHub action,
• there will need to be a section in the README explaining how to use it!

[mchangrh]

I think the image can be published to GitHub Packages.

I have built my own workflows off of that, notably to include cross-platform (ARM) builds so that is very doable, if you want to add dockerhub it should also be trivial.

I don't think a docker-compose.yml is necessary, we should be able to run the container image directly

I understand, I guess for my own usecase I would like to automate my own backups with Cron but it can also be run directly.

...there will also be a .github directory with the configuration for the GitHub action,

If you mean the tests for the GitHub action workflow, I don't think the .github directory is a suitable fit since it is reserved for GitHub-related files.

The Dockerfile is usually reserved for the root directory, perhaps moving the support files for the dev container to a dedicated docker or tests directory would be more suitable, especially if a docker-compose file isn't desired.

[joeyates]

Hi @mchangrh

I like the idea of also producing ARM images!

I would prefer not to put the Dockerfile in the root. I think it's better to put it in a container subdirectory where, if necessary, it can have its own README, etc.

I think the GitHub Packages repository is sufficient for the image, no need to ship to Docker Hub.

[mchangrh]

I have some questions about your current container setup that are confusing me a bit

docker compose files

It seems you have 2/3 different docker compose files, all of which I assume are for different purposes?

The idea I have so far is that

• dev/container/compose.yml is for CI tests and reading from environment variables
• dev/docker-compose.yml is for your own personal development so you can test against multiple IMAP servers in docker

The GHA CI tests against a matrix of ruby versions, but I don't see any invocation or passing in of environment variables unless you're handling it within GHA's environment management

ideally I would like to give proper names to each compose file to distinguish between what an end user would run and what is specifically meant for testing/ development, especially if the container base will differ between the two

purpose of container

It seems that previously, you would use the docker as a live attached console for running imap-backup, opting to be dropped in /bin/bash. Is this functionality still desired or would an invoke-and-forget option be better?

[joeyates]

Hi @mchangrh

Currently, there are 3 uses of containers in the project:

1. in normal development, dev/docker-compose.yml starts the two IMAP servers needed to run the tests (see docs/development.md),
2. as an occasional alternative, dev/container/compose.yml starts the two IMAP servers, plus a third image providing any desired Ruby version, this was mainly useful when there were problems with openssl versions (see dev/container/README.md),
3. .github/workflows/main.yml runs the tests in CI, starting the same two IMAP servers as above.

As the project should work equally well with Podman as with Docker, I intend to rename dev/docker-compose.yml to dev/compose.yml.

So, the current use of containers is for development and CI.

The new image you are proposing, which is actually for end users, can go in a new container directory, with a new GitHub workflow file .github/workflows/publish-image.yaml to build the image and push it to GitHub Packages. I think this commit can be used as a basis for that workflow.

Also, to avoid confusion, .github/workflows/main.yml can be renamed .github/workflows/ci.yaml

Finally, you say

The GHA CI tests against a matrix of ruby versions, but I don't see any invocation or passing in of environment variables

The CI environment variables are set here.

[joeyates]

Hi @mchangrh

Have you gone any further with this? I'd really like to get this feature implemented :smile:

[mchangrh]

Oh sorry about that, I've been consumed by a few other projects and relegated this one to a side project at my day job. I should be able to get it done today!

[joeyates]

Hi @mchangrh

I'm looking forward to getting this feature implemented. Do you have time to make a new PR? If not, I'll handle the implementation

[joeyates]

I've done an implementation of this. Thanks for proposing the idea!