Skip to main content

Settings

The Settings section within your application allows you to configure various aspects of your application. The following settings are available:

Release commands​

Release commands are executed during the deployment process, in a container launched from the application's image. After all the release commands have been performed, the container is discarded and the deployment process continues.

Usage​

Release command are suited to performing actions that take place in the application's runtime environment. For example, actions such as:

  • running database migrations (e.g. python manage.py migrate in Django)
  • programmatically applying headers to media storage
  • performing a self-test or batch repair on an application's content (e.g. python manage.py cms fix-tree in django CMS)
  • performing a self-test on an application's configuration
  • using an API hook to flush a content cache
  • posting a notice to a company messaging tool to announce a successful deployment

are all good examples of release commands.

They are to be contrasted with actions that take place during the build process to define the application's runtime environment - for example, compilation of language files or static files - that should be executed in the Dockerfile.

If a release command fails or raises an error, the deployment will fail.

Release commands

Do not use release commands as part of your CI/CD process. They are not run as the final stage in the deployment process. They run before the deployment is released. Instead, use the Divio CLI and integrate it into your CI/CD environment.

Applying release commands​

Release commands can be added in an application's Settings view, along with a human-readable label.

Release commands

Commands will be executed in the order that they are added.

Commands can also be added programmatically by applications - for example those that use the legacy Aldryn Django framework - and will be listed here as well.

Cautions​

Risk of failed automated commands​

Release commands are executed in the runtime environment, and therefore have access to an application's resources and services. This includes the database and media storage. For example, a database migration in a release command can alter the structure of the database.

Even if a release command is completed successfully, it is not the final stage in the deployment process, and subsequent checks can also fail, in which case the new image will not be used; instead, the containers launched at the previous deployment will continue running, potentially putting the application into an inconsistent state.

Mitigations such as implementing roll-back mechanisms are the responsibility of the application developer.

Timeouts​

Release commands are suitable for running long-executing processes (for example, S3 header updates can take some time to execute), so we apply a generous timeout (30 minutes). However, commands that exceed this limit will cause a deployment failure.

Failures​

On deployment, a release command that produces an error will be shown in the deployment log under the docker release commands heading, for example:

===== docker release commands =====

Running security configuration checks...

database configuration    ... passed
user accounts             ... passed
gateway server            ... failed (HTTPS not enforced; no exemptions)

Security configuration checks failed.

Web container configuration​

Beta Feature

Web container configuration is currently in beta and may be subject to change. We welcome your feedback. You can enable Beta features in your account settings.

The web container configuration allows you to define the port for the web container that connects to the application.

If empty, the value is taken from the Dockerfile.

It is also used for the sanity tests executed on each container to ensure it is healthy.

Startup probe settings​

Beta Feature

Startup probe settings are currently in beta and may be subject to change. We welcome your feedback. You can enable Beta features in your account settings.

The startup probe mechanism validates a deployment. It sends requests to the web container until it succeeds, marking the deployment as successful. Otherwise, it is marked as failed.

  • Startup timeout: (Default: 60s) The Overall timeout for the container to start answering HTTP requests successfully in seconds. If no successful response is returned within this time, the deployment will be marked as failed.
  • Individual startup probe timeout: (Default: 10s) Timeout for a single HTTP probe request in seconds.
  • Startup probe max retries: (Default 300): Maximum number of HTTP requests to attempt.