Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker-compose file and Dockerfile should be toghether with the code or separate #19

Open
sandroden opened this issue Dec 7, 2020 · 1 comment

Comments

@sandroden
Copy link

This repo provides a Dockerfile and docker-compose.yml for 2 separate sources and -as far as I understand- currently independent servers.
I think this is misleading. I really would have tried this if I understood there was a branch with the docker-compose but the name of the repo suggested it was the other repo's docker-compose...
I think that at a minimum the two repo should be separated so that it's clear before opening the repo what you will find inside. In fact not even the readme suggests there is a docker-compose for djankiserv.

A separate issue is the fact that Dockerfile and docker-compose.yml should or not be kept together with the sources. For the repo I administer I normally keep Dockerfile with the code so that an image is created by gitlab on commit and separately I have a Dockerfile that normally is much more dependent on how you decide to deploy (Anton suggested in fact to use microk8s that is probably a very good idea).

Since the docker can be done in many ways (uwsgi in single docker rather than gunicorn with separate static docker, mysql or postgresql, ...) we could just as well decide to go with different repositories, but if we agree on one docker we probably don't need to have so many options.

@VikashKothary
Copy link
Member

VikashKothary commented Feb 1, 2021

Another contributor has raised a similar point, and I made some comments about best practices in the ticket. See: ankicommunity/ankicommunity-sync-server#69.

But when it comes down to it, I think it's all about scale. Whether you believe the Dockerfile should be kept with code, as a separate repository, or as individual repositories, you're right. Based on the size and the complexity of the project and the organisation, the devops practices would be different.

My rule-of-thumb here is that we're organising repos by maintainers. This repo is maintained by @kuklinistvan and I don't want to make his life harder by spreading this issues between multiple repos.

When we need more maintainers, because we've got more docker services, then I'm happy to change things up. But right now, I'm not sold in the need for a change. Let me know if there are any benefits you think we're losing out on.

Improving our devops practices is my priority right now. So I should be considerably improving build process, so if you still feel like we need to improve our ways-of-working after my changes, then I'm happy to discuss it further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants