Open mjog opened 9 years ago
Just a few questions:
1) Why {{ project_name }}/app/{{ repo_name }}
vs. just {{ project_name }}/{{ repo_name }}
or {{ project_name }}/app
? I think probably the latter is best - why do we care what the repo name is, just make app
the working copy for brevity and consistency?
2) Why localhost
vs 127.0.0.1
? This seems a no-op at best (just a name lookup against /etc/hosts
), but to specify all interfaces (e.g. during development) it's 0.0.0.0
(no corresponding name). An IP then seems more consistent?
3) Should the system-supervisor
tag be django-supervisor
instead? Previously I think these tags indicated which services would be added to the system-level (and only) supervisor instance. Is the new tag just indicating that the django-supervisor
management command will be added to the system-level supervisor?
Oh, and would SUPERVISOR_ADDRESS
more directly match the setting we are pulling from the env? Just thinking if/when more deployment settings are added, using the same name in the env and settings module might be good.
The per-service hierarchy I have settled on is:
/ixc
|-- {{service}}
| |-- app
| | |-- {{repo}}
| | `-- venv
| |-- etc
| |-- log
| `-- media
.
Although it isn't quite the case at the moment, I'm planning on making app
the only directory writable by the ixc
user. I can't collapse the repo down a level, otherwise the ixc
user would need write access to {{service}}
, which will let users and intruders break things.
Using localhost
is human readable, a trivial lookup, and otherwise identical to using 127.0.0.1. It's got nothing to do with 0.0.0.0 - if you want that, then use that, but you don't, so use localhost.
The tag is system-supervisor
since if present, on deploy the app will be restarted in the system-wide instance of supervisor, not the app-local one. Doesn't have any other effect.
SUPERVISOR_ADDRESS is incorrect, since it's not an address that supervisor uses. Currently, it is passed to gunicorn, but using LISTEN_ADDRESS makes it both obvious what it is used for and decoupled from gunicorn.
I just pushed a change removing supervisor config from local.py - the default should cover all common use cases for both development and deployment, and people should be discouraged from messing with it.
@mrmachine given the move to docker, I gather this is outdated. If so, can you close this?
ICANHASMERGE?