lumenwrites
commented
7 years ago Hi! Wow, thank you so much for the detailed feedback and ideas!
Wouldn't it be better to have a docker-compose.yml file for production and one for development?
That would definitely be better, it's a great idea, I will do this.
You are exposing the frontend and backend containers to be accessible from the outside...
At the moment, I'm running my blog on a server along with several other websites, so I need to manually configure nginx(not using the one in the container), and it's more convenient with exposed ports. But you're absolutely right, not exposing the ports is better. Give me some time, I will tweak it a bit down the road.
I see that you commited the .env file with passwords to git, you are changing those credentials on the production version of your blog right?
The intention is to show an example of the file with generic passwords, so that anyone could easily change them. I should probably add this to the readme....
why are you using a second nginx to serve the static frontend files instead of using the main one at port 80?
You can only connect one nginx instance to the port 80, and I need to serve backend and frontend separately. So I have an nginx container that sits in front of the backend/frontend containers, and proxies requests to them. Requests to api.mydomain.com go to the backend, and from mydomain.com go to the frontend.
would it be possible to have a build directory on the react app with the bundle and minified files and serve those static files with the main nginx?
Essentially this is what is happening now, the nginx in the frontend container serves the whole frontend directory. But I am definitely planning to compile files that need to be served into a separate directory, it would be way better.
Also, by the way, it's all going to change soon, because I want to implement server-side rendering, so the frontend files will be served with node/express.
you are mounting host volumes to the containers to share the code and make live changes to it. would it be better to not do this on the production config to avoid depending on the host storage and just copy the code to the container.
Hmm... Well, at the moment it is just very convenient to me to be able to just pull the updated code on the server, and see the updates immediately, without the need to rebuild anything. This advice definitely makes sense, but I'm not sure... I'll keep using the volumes for now, but I'll think about it and see if I can implement it in a smarter way. If I'll end up using CI and automating it all somehow, I will probably do as you suggest.
to get postgres persistent storage the recommended way to do this is using named volumes available from docker 1.9+ , like this
This is definitely on my todo list, I just haven't figured out how to do this properly yet.
t's recommended that you install all your dependencies with a single RUN command, using bash && to chain commands
Will do.
Thank you again for such a great post! This is exactly the kind of feedback I needed. I'm still learning all this tech, so as I figure out how things work, I will make it all cleaner and more elegant. Your advice is really awesome and useful, and you're very welcome to open more issues, ask questions, etc, this will be very helpful to me!
Hello, thank you for sharing this project, I'll take a deep look at it since its the kind of setup I'd like to use for my projects.
Some questions/suggestions if I may (please correct me if I'm wrong, I'm still kinda new to these technologies):
Wouldn't it be better to have a docker-compose.yml file for production and one for development? these are the things I would change in the production config:
RUNcommand, makes searches for files more inefficient. It's recommended that you install all your dependencies with a singleRUNcommand, using bash&&to chain commandsIf you don't mind, I'll submit some issues if I have any further questions about the project, so I can learn a thing or two and hopefully contribute to this project.