Anatomy of a Divio Cloud project¶
For each addon in your project, a directory will be created in
addon.json: basic metadata for the addon (generally, there is no need ever to edit this file)
aldryn_config.py: optional; manages settings for the addon (see aldryn_config.py explanation and how to create an aldryn_config.py file)
settings.json: any settings that were applied via the Control Panel, so that they can be used locally
For local development use only. An addon can be placed here for development purposes.
addons-dev contains a little magic; any packages within directories in
automatically be placed on the Python path for convenience.
divio project develop <addon> for an addon in
addons-dev will add it to the
settings.INSTALLED_ADDONS, then attempt to build the
For local development use only. In
media directory functions as the local analogue
of Cloud project’s S3 storage bucket (see How to interact with your project’s media storage).
Project-level Django templates.
Templates at the project level will override templates at the application level if they are on similar paths. This is standard Django behaviour, allowing application developers to provide templates that can easily be customised.
On initial project creation¶
For your convenience, when you first create a project, any templates in addons are copied to the project level so you have them right at hand.
For example, templates from Aldryn News & Blog will be copied to
templates/aldryn_newsblog/ in your project.
If a template does not exist in the project’s
templates directory, Django
will simply fall back to the one in the addon itself.
Subsequent addon updates¶
After templates have been copied to the project’s
templates directory, they
will not be copied again, so as not to overwrite any changes the project
developer may have made. However, this does mean that if an addon is
subsequently updated and its templates change, those changes will not appear in
In this case:
- if you have made changes to the templates in your project, you will need to obtain any updated templates and merge them with your own versions
- if you have not made any changes, you can simply delete your local versions and Django will use the updated application templates.
The project build process¶
- The Divio CLI clones (downloads) the project’s files from the Divio Cloud Git server.
- The project’s
docker-compose.ymlfile is invoked, telling Docker what containers need to be created, starting with the
webcontainer, which is built using…
- …the project’s
Dockerfile. This tells Docker how to build the the project’s containers - Docker begins executing the commands contained in the file.
- If necessary, Docker downloads the layers from which the container image is built.
- Docker continues executing the commands, which will include copying files, installing packages using Pip, and running Django management commands.
- Docker returns to the
docker-compose.yml, which sets up filesystem, port and database access for the container, and the database container itself.
docker-compose.ymlfile contains a default
commandthat starts up the Django server.
- The Divio CLI opens a web browser window with a login page for the locally running site.