[Feat] Easy setup for Postgre on Linux with Docker #2
Conversation
|
Not familiar with docker but wouldn't it make sense to have a Dockerfile instead of a shell script? |
|
Yeah! That's true. But, would work on that later, and remove this file, as for that kind of setup, even the Server should start using Docker. |
|
Using docker compose would probably make the most sense then |
|
Hi @SitiSchu I have tested compose file with only Postgres as container. But, when creating API server image for Cargo project, on my system it fails. If it fails for you as well, we can put this PR on hold for a while. Will work on this later then! |
|
When running |
Do create a secrets folder before u run @SitiSchu This PR is in working state now. 💯 |
phoenisx
changed the title
phoenisx
changed the title
| ENV RUST_BACKTRACE 1 | ||
|
|
||
| CMD ["cargo", "run"] | ||
|
|
There was a problem hiding this comment.
Well, to separate out deployment logics for production and dev builds. Having two separate ways of deployment, helps you manage separate concerns. For eg, in production build, you can remove the source code (atleast for Rust, as you will get a compiled binary, to reduce the docker image size), that got copied earlier.
Also, it helps to keep different rust versions, till the dev is properly tested and can be deployed to Production.
There was a problem hiding this comment.
Also check this - https://users.rust-lang.org/t/why-does-cargo-build-not-optimise-by-default/4150
where release build can be a lot more slower to compile.
There was a problem hiding this comment.
I'm still not sure I like it... there has to be a cleaner way to do this...make an env var or something and a script?
There was a problem hiding this comment.
I can understand your concern, and keeping things DRY, but if docker commands varies (like for dev and prod), we need separate Dockerfiles, as they are supposed to be pre-built and cached in the hub, with different tags.
Not sure if env vars can be used in images (as in used in Docker Commands), but even if they did, they will make Docker images in-consistent.
What I can think of is, Docker itself acts as an environment specific deployment strategy (just like envs). Each Environment having it's own set of deployment instructions, unless some environments have to be deployed with the exact same build, (like staging/prod can have a single Docker file).
There was a problem hiding this comment.
I suppose. Also Dockerfile, NOT DOCKERFILE
Context
Have added Docker setup for dev environment, where a user needs to do some pre-setup as mentioned in README.md and just run
docker-compose upfor the services to start.Prod Docker setup has been added as well, but as extra files. We can take a reference from them and update USERNAME/DBNAME when deployed to prod.