- Notifications
You must be signed in to change notification settings - Fork1k
feat: Add built-in PostgreSQL for simple production setup#2345
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Changes fromall commits
dc122b6
0450fcb
0856209
7fd3560
690c791
File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading.Please reload this page.
Jump to
Uh oh!
There was an error while loading.Please reload this page.
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -93,6 +93,8 @@ nfpms: | ||
type: "config|noreplace" | ||
- src: coder.service | ||
dst: /usr/lib/systemd/system/coder.service | ||
scripts: | ||
preinstall: preinstall.sh | ||
kylecarbs marked this conversation as resolved. Show resolvedHide resolvedUh oh!There was an error while loading.Please reload this page. | ||
# Image templates are empty on snapshots to avoid lengthy builds for development. | ||
dockers: | ||
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
@@ -47,10 +47,14 @@ To install, run: | ||||||||||
curl -fsSL https://coder.com/install.sh | sh | ||||||||||
``` | ||||||||||
Once installed, you canstart aproduction deploymentwith a single command: | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Sorry, but turning the DB off if the single instance of the app goes down is not what a lot of people would consider "production" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Why not? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. We do essentially this same thing right now on our dogfood deployment, which I'd consider a production deployment of Coder. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. I agree with@f0ssel here -- I'd be more comfortable with a "traditionally-managed" database if I were setting up a prod deployment than just using the embedded one. Doesn't detract from the value of being able to instantly kick the tyres with a real database! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Why though? I believe users should start real, production deployments with this setup. There isn't a technical reason why it's bad practice. Users can just backup the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Fair fair! Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Coupling the lifecycle of the database to the app lifecycle and running the DB on the same host are two pretty big red flags for any engineers that have to actually manage and troubleshoot the app in production. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. What are the specific red flags? You can still run the database independently. Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. I'm saying that if a customer wanting to run 1000 devs and it be production ready I'd probably advise them:
Right now this command not only does none of those things, but also won't even allow you to run multiple instances of the web app since it will conflict on the DB setup. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. And similar to why people recommend not putting DB healthchecks in the webserver healthchecks on kubernetes - you don't want your DB taking your webapp down and vice versa, you want their lifecycles independent for obvious reasons. | ||||||||||
```sh | ||||||||||
# Automatically sets up an external access URL on *.try.coder.app | ||||||||||
coder server --tunnel | ||||||||||
# Requires a PostgreSQL instance and external access URL | ||||||||||
coder server --postgres-url <url> --access-url <url> | ||||||||||
Comment on lines +56 to +57 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Suggested change
| ||||||||||
``` | ||||||||||
Use `coder --help` to get a complete list of flags and environment variables. Use our [quickstart guide](https://coder.com/docs/coder-oss/latest/quickstart) for a full walkthrough. | ||||||||||
Uh oh!
There was an error while loading.Please reload this page.