Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[Feat] Easy setup for Postgre on Linux with Docker #2
base: develop
Are you sure you want to change the base?
[Feat] Easy setup for Postgre on Linux with Docker #2
Changes from all commits
f905564
18a6ad7
c9fd99c
6b803a5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you have two Dockerfiles?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can understand your concern, and keeping things DRY, but if docker commands varies (like for dev and prod), we need separate
Dockerfile
s, 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose. Also
Dockerfile
, NOTDOCKERFILE