docs: add how-to on deploying with docker compose#2019
Conversation
| @@ -1,126 +1 @@ | |||
| <a id="howto_run_fxa"></a> | |||
|
|
|||
| # Run Your Own Mozilla Accounts Server (Outdated) | |||
There was a problem hiding this comment.
No reason to this around.
There was a problem hiding this comment.
Maybe we should delete the whole file then?
There was a problem hiding this comment.
oh oops, I thought I did it. Not sure how that happened. Thanks.
taddes
left a comment
taddes
left a comment
There was a problem hiding this comment.
Just a couple suggestions. Thx for doing this.
| 1. Go to `about:config` in Firefox. | ||
| 1. Find the `identity.sync.tokenserver.uri` configuration. | ||
| 1. Change the value to `http://localhost:8000/1.0/sync/1.5`. | ||
| 1. Restart Firefox. |
There was a problem hiding this comment.
| 1. Go to `about:config` in Firefox. | |
| 1. Find the `identity.sync.tokenserver.uri` configuration. | |
| 1. Change the value to `http://localhost:8000/1.0/sync/1.5`. | |
| 1. Restart Firefox. | |
| 1. Go to `about:config` in Firefox. | |
| 2. Find the `identity.sync.tokenserver.uri` configuration. | |
| 3. Change the value to `http://localhost:8000/1.0/sync/1.5`. | |
| 4. Restart Firefox. |
There was a problem hiding this comment.
The markdown renderer can handle it.
| @@ -1,126 +1 @@ | |||
| <a id="howto_run_fxa"></a> | |||
|
|
|||
| # Run Your Own Mozilla Accounts Server (Outdated) | |||
There was a problem hiding this comment.
Maybe we should delete the whole file then?
| ``` | ||
|
|
||
| Note that multiple values will be read from the environment: | ||
| - `SYNC_MASTER_SECRET`: a secret used in cryptographic operations |
There was a problem hiding this comment.
In the e2e tests, we use secret0. Perhaps we can suggest here that for active use, it should be a proper crypto key, but can be something simpler like a string password. It may possibly confuse someone that this value has to be generated somehow or needs to be something special. Kinda like what you did below with use_your_own_secret_4d3d3d3d, just a clarifying sentence.
| - `SYNC_SYNCSTORAGE__DATABASE_URL`: database URL for syncstorage, e.g. `mysql://sync:test@example.io/syncstorage` or `postgres://testo:@localhost/syncdb` | ||
| - `SYNC_TOKENSERVER__DATABASE_URL`: database URL for tokenserver, e.g. `mysql://sync:test@example.io/tokenserver` or `postgres://testo:@localhost/syncdb` | ||
|
|
||
| The values can be directly written into the yaml as well. |
There was a problem hiding this comment.
If someone will use env variables, perhaps there should be a suggestion or recommendation on how best to pass said ENV vars? Putting the settings in the yaml is certainly easiest. We may not need to decide this here, but we should probably come up with a best practice on how to set and pass env vars, whether it be in the local.toml or when invoking the service in terminal, or dotenv.
There was a problem hiding this comment.
The reader can see that on https://github.com/mozilla-services/syncstorage-rs/pull/2019/changes#diff-694b9247321f6a4ec48bd348e6f4a5c3ea3da468e3eb8e8ee30c0f1b536a03c5R66-R69 already though?
There was a problem hiding this comment.
Fair enough, I'll leave it up to you. I've been zealously wanting to make stuff as crystal clear as possible after wading though so much unclear documentation heh
There was a problem hiding this comment.
I believe by the time someone wants to self-host Sync they likely have experience with environment/shell variables. Or if we do not believe that to be true, then we should (resource permitting) provide something they can copy and paste to get the service running. I don't think teaching about env vars (or reverse proxy, or certs, etc.) should be a goal here.
chenba
force-pushed
the
docs/how-to-deploy-docker-compose-STOR-118
branch
from
c9e46b3 to
de08b03
Compare
2 participants
Update docs with a simple how-to on deploying with docker compose.
Closes STOR-118 / #1428