mirror of
https://github.com/Dokploy/website.git
synced 2026-07-22 14:25:26 +02:00
- Introduced new MDX components and configuration files for the documentation site. - Added various images and icons to enhance the visual representation of the documentation. - Updated package.json and pnpm-lock.yaml to include new dependencies for the documentation. - Created a .gitignore file for the new docs app to manage ignored files effectively. - Enhanced README with instructions for restarting the dev server after adding new MDX files.
81 lines
2.8 KiB
Plaintext
81 lines
2.8 KiB
Plaintext
---
|
|
title: "Schedule Jobs"
|
|
description: "Learn how to automate tasks using Dokploy's Schedule Jobs feature"
|
|
---
|
|
|
|
|
|
Schedule Jobs in Dokploy allows you to create and manage automated tasks that run on a specified schedule using cron expressions. Each job execution creates a log entry where you can monitor the output and execution status.
|
|
|
|
## Job Types
|
|
|
|
Dokploy supports four types of scheduled jobs:
|
|
|
|
1. **Application Jobs**: Run commands inside specific application containers
|
|
2. **Compose Jobs**: Execute commands in Docker Compose services
|
|
3. **Server Jobs**: Run scripts on remote servers
|
|
4. **Dokploy Server Jobs**: Execute tasks on the Dokploy server itself
|
|
|
|
## Container-based Jobs (Application and Compose)
|
|
|
|
For application and compose jobs, you can run single commands that will be executed inside the target container. Dokploy internally uses Docker exec to run these commands:
|
|
|
|
```bash
|
|
docker exec -it <container_id> <command>
|
|
```
|
|
|
|
### Example
|
|
Assuming you with a nginx container and you want to check the nginx version in a container:
|
|
1. Create a new schedule job
|
|
2. Set the command to: `nginx -v`
|
|
3. Configure your desired schedule using cron syntax
|
|
4. Save and monitor the execution logs
|
|
|
|
<Callout>
|
|
The target container must be running for the job to execute successfully.
|
|
</Callout>
|
|
|
|
<Callout >
|
|
For docker compose jobs, is required to not change the COMPOSE_PROJECT_NAME environment variable, since this is used to identify the project.
|
|
</Callout>
|
|
|
|
## Server-based Jobs (Server and Dokploy Server)
|
|
|
|
For remote servers and the Dokploy server, you can write bash scripts to perform various tasks. These scripts can use any command or tool available on the target system.
|
|
|
|
<Callout type="info">
|
|
Make sure any required dependencies are installed on the target server before using them in your scripts.
|
|
</Callout>
|
|
|
|
### Example 1: Automatic Docker Cleanup
|
|
This script cleans up unused Docker containers. You could schedule it to run every 15 minutes using the cron expression `*/15 * * * *`:
|
|
|
|
```bash
|
|
#!/bin/bash
|
|
docker system prune --force
|
|
```
|
|
|
|
### Example 2: Custom Database Backup
|
|
You can create scripts to backup databases that aren't natively supported by Dokploy. Here's an example structure for a custom backup script:
|
|
|
|
```bash
|
|
#!/bin/bash
|
|
# Backup script for custom database
|
|
backup_date=$(date +%Y%m%d_%H%M%S)
|
|
backup_file="database_${backup_date}.backup"
|
|
|
|
# search the container name
|
|
container_name=$(docker ps --filter "name=clickhouse" --format "{{.Names}}")
|
|
|
|
# Add your backup commands here
|
|
docker exec -it $container_name clickhouse-client --query "BACKUP DATABASE mydb TO '/backups/$backup_file'"
|
|
|
|
# Upload to S3 (if needed)
|
|
# aws s3 cp /backups/$backup_file s3://your-bucket/backups/
|
|
```
|
|
|
|
## Best Practices
|
|
|
|
1. Always test your commands or scripts manually before scheduling them
|
|
2. Use appropriate error handling in your scripts
|
|
3. Consider the impact of scheduled jobs on system resources
|