Add a docker-compose setup for fast setup

[cn-ml]

Is your feature request related to a problem? Please describe.
I don't like setting up projects when I'm not certain that this is exactly what I'm looking for. Creating a docker-compose.yml description of the services needed will make deploying this app much faster.

Describe the solution you'd like
I would like to have a docker-compose.yml file for easily deploying a fully working instance of this app including its database and php backend for very quick and easy deployment.

Describe alternatives you've considered
I'm not sure if there are any useful alternatives to docker deployment.

Additional context
No additional context.

[Bubka]

I think it's time for me to dive into the docker doc 😄
I'm going to work on it.

[Bubka]

Hi

Here is my very first attempt to provide something easy to deploy using docker : https://github.com/Bubka/2FAuth-Docker

For now the idea is to ease install 2FAuth in a production environment to test it or to use it. So I created a dedicated 2fauth docker-hub image that installs the latest version of 2FAuth from the master branch on Github. The docker-compose setup binds a MySQL container to run the db. Everything is persisted via volumes.

Hope it will be useful!

[MohamedElashri]

Hi

Here is my very first attempt to provide something easy to deploy using docker : https://github.com/Bubka/2FAuth-Docker

For now the idea is to ease install 2FAuth in a production environment to test it or to use it. So I created a dedicated 2fauth docker-hub image that installs the latest version of 2FAuth from the master branch on Github. The docker-compose setup binds a MySQL container to run the db. Everything is persisted via volumes.

Hope it will be useful!

When trying that I got 500 | Server Error after I deploy the image.

[ameralzarouni]

I am also getting a 500 Server Error

[qdm12]

Hey there, I have a working image available at qmcgaw/2fauth (only amd64 for now).

Docs on how to run it: https://github.com/qdm12/2FAuth/tree/docker/docker
It's working pretty well for me so far. There is also a docker-compose.yml for it.

@Bubka Do you prefer to:

1. Have the docker things in your repo together with the CI to push to your Docker Hub Account
   • you have to create a Docker hub account, give me your docker hub username and set your password as a secret in the Github repository settings
   • It will use Github Actions to build and push the image
2. Or I can create another repo with only docker specific things and push under my docker hub account

I'm happy with both, I just want some Docker image to be built automatically really 😉

[Bubka]

@qdm12 Few questions:

Option 1:

• I never used GH Actions. Will it runs without disturbing the current Travis CI?

Option 2:

• I'm not sure to understand how you propose to build automatically the image using a new repo. GH Actions can be triggered by the main 2FAuth repo to build/push the Docker image from another repo?

In fact I already have a dedicated 2FAuth-Docker repo for docker things and a DockerHub ID. So, IMO, the easiest would be to use this existing repo to host your work (as a new branch) and build/push an alternative image to the 2FAuth DockerID. Basically I would say it corresponds to your option 2 right?

[MohamedElashri]

@qdm12 Few questions:

Option 1:

• I never used GH Actions. Will it runs without disturbing the current Travis CI?

Yes, There is no overlab between travis which work from .travis.yml file in repository with Github action which works in .github/workflows/<action>.yml file. It is easy and free and you can even use it to build mutli arch docker so you can support arm and arm64 not only amd64.

[qdm12]

Thanks for the quick reply! Sorry I wasn't aware of your 2Fauth-docker repo! Shouldn't we close this issue since it has a docker-compose.yml file?

Now I think yeah we should do option 1. I know how to easily build cross arch Docker images with some github actions out there, not too sure with Travis. We could do it with Travis too though I guess. that way the build would trigger on every commit.

Otherwise we can have it in a separate repo and build it periodically like once a week.

[MohamedElashri]

Otherwise we can have it in a separate repo and build it periodically like once a week.

You don't need a separate one to do this. Instead of using

on:
  push:
    branches:
      - main

You can use a schedule event like

on:
  schedule:
    - cron:  '30 5,17 * * *'

Which you define a cron job to do that. More information about how to configure that is on GitHub action docs

[qdm12]

@MohamedElashri Definitely. But if it is part of the same repository, I would rather have it build it on every commit that passes tests etc. The periodic approach is a workaround to have it built from another repo.

[Bubka]

After some reflections I think that keeping all things in the main repo is a better approach. It will prevent users to miss out the Docker resources and it will be more straightforward.

Go for option 1 then 👍🏻