The template `django-source.json` contains just a minimal set of components to get your Django application into OpenShift.
The template `django.json` contains just a minimal set of components to get your Django application into OpenShift.
The template `django-source-postgresql.json` contains all of the components from `django-source.json`, plus a PostgreSQL database service and an Image Stream for the Python base image.
The template `django-postgresql.json` contains all of the components from `django.json`, plus a PostgreSQL database service and an Image Stream for the Python base image. For simplicity, the PostgreSQL database in this template uses ephemeral storage and, therefore, is not production ready.
After adding your templates, you can go to your OpenShift web console, browse to your project and click the create button. Create a new app from one of the templates that you have just added.
@ -104,24 +122,82 @@ Service "django-ex" created at 172.30.16.213 with port mappings 8080.
You can access your application by browsing to the service's IP address and port.
## Special files in this repository
## Logs
Apart from the regular files created by Django (`project/*`, `welcome/*`, `manage.py`), this repository contains:
By default your Django application is served with gunicorn and configured to output its access log to stderr.
You can look at the combined stdout and stderr of a given pod with this command:
```
.sti/
└── bin/ - scripts used by source-to-image
├── assemble - executed to produce a Docker image with your code and dependencies during build
└── run - executed to start your app during deployment
osc get pods # list all pods in your project
osc logs <pod-name>
openshift/ - application templates for OpenShift
This can be useful to observe the correct functioning of your application.
scripts/ - helper scripts to automate some tasks
gunicorn_conf.py - configuration for the gunicorn HTTP server
## Special environment variables
requirements.txt - list of dependencies
```
### APP_CONFIG
You can fine tune the gunicorn configuration through the environment variable `APP_CONFIG` that, when set, should point to a config file as documented [here](http://docs.gunicorn.org/en/latest/settings.html).
### DJANGO_SECRET_KEY
When using one of the templates provided in this repository, this environment variable has its value automatically generated. For security purposes, make sure to set this to a random string as documented [here](https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SECRET_KEY).
## One-off command execution
At times you might want to manually execute some command in the context of a running application in OpenShift.
You can drop into a Python shell for debugging, create a new user for the Django Admin interface, or perform any other task.
You can do all that by using regular CLI commands from OpenShift.
To make it a little more convenient, you can use the script `openshift/scripts/run-in-container.sh` that wraps some calls to `osc`.
In the future, the `osc` CLI tool might incorporate changes
that make this script obsolete.
Here is how you would run a command in a pod specified by label:
1. Inpect the output of the command below to find the name of a pod that matches a given label:
osc get pods -l <your-label-selector>
2. Open a shell in the pod of your choice:
osc exec -p <pod-name> -it -- bash
3. Because of how `kubectl exec` and `osc exec` work right now, your current working directory is root (/). Change it to where your code lives:
cd $HOME
4. Because of how the images produced with CentOS and RHEL work currently, you need to manually enable any Software Collections you need to use:
source scl_source enable python33
5. Finally, execute any command that you need and exit the shell.