#95 Add dockerfiles
Closed by ryanlerch. Opened by nerdsville.
nerdsville/elections feature/add_prod_dockerfile  into  develop

Download 95.patch

While starting on the work to bring in a Jenkinsfile for https://pagure.io/elections/issue/93, I noticed there isn't a production ready Dockerfile. This could be helpful if down the line this app gets deployed as a container.

As such, I have started to bring in a proof of concept of a production Dockerfile, development dev.Dockerfile, and docker-compose.development.yaml in this PR.

Feel free to decline if this is not needed.

Caveats:

  • envsubst is probably suboptimal, other suggestions would be great
  • Production image is not currently rootless

Questions:

  • Is createdb.py idempotent?

1 new commit added

  • Add initial entrypoint

1 new commit added

  • Add command to createdb

To avoid spamming with PR's, I put all the work related to docker here. We can slice, dice, adjust, and remove anything as is seen fit.

CC: @pingou @bcotton

1 new commit added

  • Add dev dockerfile and docker-compose

1 new commit added

  • Let group stand alone

2 new commits added

  • Add production docker-compose
  • Rename development docker-compose

Should we add the dockerfile to the develop and production branches separately? IOW, instead of having both files in the repo, the develop branch has the dev dockerfile and the production branch has the prod dockerfile? This seems like it fits the historical use of this repo better (although I'm not entirely sure I love that) and would in theory mean we're not editing the same file twice when we need to tweak it (assuming we can cleanly merge the changes)

@bcotton I am not sure I quite understand, but having the dev dockerfile on the develop branch only, wouldn't that make releases a bit more difficult (as now we need to exclude files on release to master). Normally of projects I've worked on, the prod dockerfile, and development dockerfile are in the same repository (and in some cases are the same file entirely).

This PR just serves to provide a starting point for "dockerizing" the app, and we can modify it, remove stuff, change stuff, etc prior to merging.

Hope this helps

elections currently uses s2i to be deployed. Is there a way we could leverage this in the test environment?
For example, in prod election doesn't use apache but nginx.

Elections have been migrated to https://forge.fedoraproject.org/apps/elections

Pull-Request has been closed by ryanlerch

Metadata