You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
This repo provides a
Dockerfile
anddocker-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
anddocker-compose.yml
should or not be kept together with the sources. For the repo I administer I normally keepDockerfile
with the code so that an image is created by gitlab on commit and separately I have aDockerfile
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.
The text was updated successfully, but these errors were encountered: