Production Deployment
Last updated
Was this helpful?
Last updated
Was this helpful?
as a third party application in a Django project.
In your production environment you can install with:
This is how the admin website looks like for editing Isabl CLI settings:
First you need to assign the right API permissions to your users. To facilitate this Isabl comes with the following command:
This command will create the following three Django groups:
Group name
Description
Permissions to
Managers
Individuals who register samples.
CustomField, Individual, Center, Disease, Experiment, Technique, Platform, Project, Submission, Analysis
Analysts
individuals who run analyses.
CustomField, Application, Analysis, Assembly
Engineers
A combination of Managers and Analysts
CustomField, Individual, Center, Disease, Experiment, Technique, Platform, Project, Submission, Analysis, Application, Assembly
Then you will need to configure the ADMIN_USER
and the DEFAULT_LINUX_GROUP
in the Isabl CLI client object (you can do so by updating your client ISABL_CLIENT_ID
from the Django admin website). For example:
Pro tip: use the Can Download Results
permission to configure what users can download analyses results in your Isabl instance.
For Django 2.0 & Python 3.6
Renders a Django project with 100% starting test coverage
Secure by default with SSL.
Optimized development and production settings
Media storage using Amazon S3
Run tests with py.test
Customizable PostgreSQL version
Only maintained 3rd party libraries are used.
Uses PostgreSQL everywhere (9.2+)
Environment variables for configuration (This won't work with Apache/mod_wsgi except on AWS ELB).
Before you begin, check out the production.yml
file in the root of this project. Keep note of how it provides configuration for the following services:
django
: your application running behind Gunicorn
;
postgres
: PostgreSQL database with the application's relational data;
redis
: Redis instance for caching;
caddy
: Caddy web server with HTTPS on by default.
Provided you have opted for Celery (via setting use_celery
to y
) there are three more services:
celeryworker
running a Celery worker process;
celerybeat
running a Celery beat process;
Access to the Django admin is set up by default to require HTTPS in production or once live.
Alternatively, If you have a local certificate and key provided by your institution, you will need to copy the keys in the caddy compose/production/caddy/Dockerfile
and use:
You will need to build the stack first. To do that, run:
Once this is ready, you can run it with:
To run the stack and detach the containers, run:
To run a migration, open up a second terminal and run:
To create a superuser, run:
If you need a shell, run:
To check the logs out, run:
If you want to scale your application, run:
Warning! don't try to scale postgres
, celerybeat
, or caddy
.
To see how your containers are doing run:
Its likely that the data resides in a different server than the web application. To make results available for the web server you may want to consider sshfs
:
For example, if ISABL_CLIENT_ID=1
you can update the settings field at . An example of such configuration could be:
Isabl CLI can be used by multiple users. By default, any user can import data and result files are owned by whoever triggered the application. These capabilities can be limited to an . In this setup, data and results are owned by theADMIN_USER
yet .
Anis a shared unix account that can be accessed by one or more engineers. These engineers are responsible for the data and results of Isabl installations.
Once you follow the , you will understand that Isabl Applications can be managed using a python package. If you have multiple users triggering applications, you may want to have them all pointing to the same package. This can be either using the PYTHONPATH
environment variable or pip installing locally your apps repo:
Learn more about :
Learn more about :
Learn more about using isabl-cli
to fetch data:
With the admin user run the following snippet in the :
You can bootstrap a new Django project using :
out of the box
based settings via
Registration via
Send emails via (using by default, but switchable)
for development and production (using with support)
for deploying to Heroku
with
optional - Serve static files from Amazon S3 or
optional - Integration with for local email testing
is a proud fork of , please note that most of their remains relevant! Also see . For reference, we forked out at commit . If you have differences in your preferred setup, please fork to create your own version. New to Django? is the best dessert-themed Django reference in the universe!
flower
running (for more info, check out instructions for local environment).
Check the original cookiecutter-django
to learn about AWS deployment, Supervisor Examples, Sentry configuration, and more. If you are deploying on an intranet, please see the HTTPS is on by default section.
The majority of services above are configured through the use of environment variables. Just check out and you will know the drill.
You will probably also need to setup the Mail backend, for example by adding a API key and a Mailgun sender domain, otherwise, the account creation view will crash and result in a 500 error when the backend attempts to send an email to the account owner.
The Caddy web server used in the default configuration will get you a valid certificate from Lets Encrypt and update it automatically. All you need to do to enable this is to make sure that your DNS records are pointing to the server Caddy runs on. You can read more about this here at in the Caddy docs. Please note:
If you are not using a subdomain of the domain name set in the project, then remember to put the your staging/production IP address in the DJANGO_ALLOWED_HOSTS
environment variable (see ) before you deploy your website. Failure to do this will mean you will not have access to your website through the HTTP protocol.
⚠️ Attention! If you are running your application on an intranet you may want to use caddy setting. Make sure that the DOMAIN_NAME
configuration has the https://
schema prepended in the caddy environment file .envs/.production/.caddy
(see this to learn more). Then include the following configuration in compose/production/caddy/Caddyfile
in order to use a self signed certificate:
Optional | Postgres is saving its database files to the production_postgres_data
volume by default. Change that if you want something else and make sure to make since this is not done automatically.