diffy
diffy copied to clipboard
pbu88
Fix docker setup
Hey there.
I was trying to set up diffy with Docker. While all tests pass and it builds successfully, the resulting app doesn't. The issue is that is missing the frontend build, which is not happening in the dockerfile.
I'm guessing it went unnoticed, because there is a volume for ./:/diffy and you likely have a built frontend on dist, which the docker server happily uses.
Tried to re-order a bit the Dockerfile to take advantage of layer caching, as well. Let me know if there's something you think needs modifying.
Just found this
#tools/frontend_install.sh (line 1)
docker-compose run web /bin/sh -c 'cd ../frontend; npm install'
Was that the purpose of the script? Are the modifications enough to replace this script?
Also, not related to the PR, but I also gave it a go into dividing the app into two different applications. I was mostly playing around, seeing where it led me. I don't see an explicit advantage to this change to be honest. Might be useful, because you can serve it from different boxes, put a server in the middle, etc..
Anyway, here it is: https://github.com/Qu4tro/diffy/tree/split
The docker support was added to make the development easier (for new contributors). If five developers want to contribute to the project, they can use those default files and it will work fine. However, deploying something in a production environment is completely different. I don't usually use docker-compose in production, for example. You might want to have the mongo database running in a different host, or having a load balancer sending traffic to multiple instances/containers of the app, and in those cases the "default" docker-compose.yml file for production won't work.
With that being said, I think we should maintain the default docker-compose.yml and Dockerfile files for development, and create the .prod ones for production in case someone wants to deploy it in a single computer.
Tbh, I was just aiming for people being able to git clone and docker-compose up to try diffy.
I like having the development override, because it solves some pains of working with docker, like long iterating times. This is the docker setup on master. It probably should be more thoroughly documented in the README.md, as just starting it, without instructions, will give you an unhelpful message, along the lines of "Something broke.". You actually need to build on the host, due to the volume created on the docker-compose. This was why I created this PR. It's helpful, but confusing because it's not documented.
A production docker-compose file would be a override of the default, just like the development is. I also agree, that is use-case dependent. Ideally, each end user (someone who wants to host diffy), would create his own override (with env-vars, load balancers, reverse-proxies, forked images, etc).
But again, the production build was not the point of the PR.
Tbh, I was just aiming for people being able to
git cloneanddocker-compose upto try diffy.I like having the development override, because it solves some pains of working with docker, like long iterating times. This is the docker setup on master. It probably should be more thoroughly documented in the README.md, as just starting it, without instructions, will give you an unhelpful message, along the lines of "Something broke.". You actually need to build on the host, due to the volume created on the docker-compose. This was why I created this PR. It's helpful, but confusing because it's not documented.
I agree with this. What if we just document the volumes creation part in the README? Is there anything else missing? I'm not in my computer now, but when I go back I can delete everything locally (the project, volumes, images, etc.) and make sure anyone can run the project by following the steps in the README.
But again, the production build was not the point of the PR.
I was consused with those COPY statements in the default Dockerfile. If we start using that default image for development we would have to recreate it every time we make a change in the project.
Yes, that would be great. cd <diffy-dir> && git clone .git diffy2 && cd diffy2 && docker-compose down && docker-compose up --build should be enough to reproduce, without actually [re]moving files.
Right. The last COPY is mostly to keep project files inside the images i.e. README.md, LICENSE, etc.
I won't push further on this, but I still think being able to just docker-compose up would be a good thing. It's like the ./configure && make && make install of 2019 :smile:
Should I close this?
Please don't close it. I want to merge it but I haven't had the time yet to review it.