|
| 1 | +--- |
| 2 | +title: One-off Jobs |
| 3 | +description: Defang enables you to run one-off jobs during your deployment workflow. |
| 4 | +sidebar_position: 280 |
| 5 | +--- |
| 6 | + |
| 7 | +# One-off Jobs |
| 8 | +Defang enables you to run one-off jobs during your deployment workflow. One-off jobs are commands that run at specific points in the deployment process, such as after your database is ready but before your application starts. |
| 9 | + |
| 10 | +One-off jobs are run a single time, and failure to run a one-off job will cause the entire deployment to fail. |
| 11 | + |
| 12 | +:::info |
| 13 | +Currently, AWS and GCP are supported for one-off jobs. Support for Digital Ocean is coming soon. |
| 14 | +::: |
| 15 | + |
| 16 | +## When should one-off jobs be used? |
| 17 | +One-off jobs are useful for running commands that need to be executed before your application starts. Common use cases include: |
| 18 | + |
| 19 | +- Database migrations |
| 20 | +- Warming or cleaning caches |
| 21 | +- Running build scripts |
| 22 | + |
| 23 | +## How to configure one-off jobs |
| 24 | + |
| 25 | +One-off jobs can be configured in your `compose.yaml` file as services with a [Restart Policy](https://docs.docker.com/reference/compose-file/services/#restart) set to `"no"`. |
| 26 | + |
| 27 | +In the example below, we define a one-off job called `release` that runs a script called `release.sh`. This job will run once during the deployment process. It will be run concurrently with the `web` service. |
| 28 | + |
| 29 | +<table width="100%"> |
| 30 | +<thead> |
| 31 | +<tr> |
| 32 | +<th><code>compose.yaml</code></th> |
| 33 | +<th>Workflow</th> |
| 34 | +</tr> |
| 35 | +</thead> |
| 36 | +<tbody> |
| 37 | +<tr> |
| 38 | +<td valign="top"> |
| 39 | + |
| 40 | +```yaml |
| 41 | +services: |
| 42 | + app: |
| 43 | + build: . |
| 44 | + ports: |
| 45 | + - "80:80" |
| 46 | + |
| 47 | + release: |
| 48 | + build: . |
| 49 | + command: ["./release.sh"] |
| 50 | + restart: "no" |
| 51 | +``` |
| 52 | +
|
| 53 | +</td> |
| 54 | +<td valign="top"> |
| 55 | +
|
| 56 | +```mermaid |
| 57 | +flowchart LR |
| 58 | + subgraph workspace["Deployment Workflow"] |
| 59 | + deployment_start |
| 60 | + app |
| 61 | + release |
| 62 | + deployment_complete |
| 63 | + |
| 64 | + deployment_start --> app |
| 65 | + deployment_start --> release |
| 66 | + app --> deployment_complete |
| 67 | + release --> deployment_complete |
| 68 | + end |
| 69 | +``` |
| 70 | + |
| 71 | +</td> |
| 72 | +</tr> |
| 73 | +</tbody> |
| 74 | +</table> |
| 75 | + |
| 76 | +### How to specify job dependencies |
| 77 | + |
| 78 | +You can specify when the job should run by using [`depends_on`](https://docs.docker.com/reference/compose-file/services/#depends_on) to define dependencies on other services. For example, when running database migrations, you would typically want to ensure that the database service is ready before executing the migration job. |
| 79 | + |
| 80 | +Here is an example configuration for a one-off job that runs database migrations after the database service is ready: |
| 81 | + |
| 82 | +<table width="100%"> |
| 83 | +<thead> |
| 84 | +<tr> |
| 85 | +<th><code>compose.yaml</code></th> |
| 86 | +<th>Workflow</th> |
| 87 | +</tr> |
| 88 | +</thead> |
| 89 | +<tbody> |
| 90 | +<tr> |
| 91 | +<td valign="top"> |
| 92 | + |
| 93 | +```yaml |
| 94 | +services: |
| 95 | + db: |
| 96 | + image: postgres:latest |
| 97 | + |
| 98 | + migrate: |
| 99 | + build: . |
| 100 | + command: ["./migrate.sh"] |
| 101 | + depends_on: |
| 102 | + - db |
| 103 | + restart: "no" |
| 104 | + |
| 105 | + web: |
| 106 | + build: . |
| 107 | + ports: |
| 108 | + - "80:80" |
| 109 | + depends_on: |
| 110 | + - migrate |
| 111 | +``` |
| 112 | +
|
| 113 | +</td> |
| 114 | +<td valign="top"> |
| 115 | +
|
| 116 | +```mermaid |
| 117 | +flowchart LR |
| 118 | + subgraph workspace["Deployment Workflow"] |
| 119 | + deployment_start |
| 120 | + db |
| 121 | + web |
| 122 | + migrate |
| 123 | + deployment_complete |
| 124 | + |
| 125 | + deployment_start --> db |
| 126 | + db --> migrate |
| 127 | + migrate --> web |
| 128 | + web --> deployment_complete |
| 129 | + end |
| 130 | +``` |
| 131 | + |
| 132 | +</td> |
| 133 | +</tr> |
| 134 | +</tbody> |
| 135 | +</table> |
| 136 | + |
| 137 | +## How do one-off jobs work under the hood? |
| 138 | + |
| 139 | +One off jobs are deployed as temporary containers on the same infrastructure as your main services. They are deployed as separate containers to ensure that they do not interfere with the main application services, so resources can be configured independently. They will share the same network and security groups as your other services, allowing them to communicate with your application and database services as needed. |
| 140 | + |
| 141 | +### Supported Providers |
| 142 | + |
| 143 | +| Provider | Release Task Support | |
| 144 | +|----------------|:--------------------:| |
| 145 | +| Playground | ✅ | |
| 146 | +| AWS | ✅ | |
| 147 | +| DigitalOcean | ❌ | |
| 148 | +| GCP | ✅ | |
| 149 | + |
| 150 | + |
0 commit comments