GPT-OSS additions
This commit is contained in:
78
async.md
78
async.md
@@ -1,25 +1,75 @@
|
||||
## Async
|
||||
## Asynchronous Tasks in Ansible
|
||||
|
||||
Run tasks asynchronously to avoid blocking:
|
||||
### Problem: Blocking Long-Running Tasks
|
||||
|
||||
When executing long-running tasks (e.g., backups, migrations, or API calls), Ansible's default behavior blocks the playbook execution until the task completes. This creates delays and reduces efficiency, especially when managing large infrastructure.
|
||||
|
||||
### Solution: Async Mode
|
||||
|
||||
Ansible's async mode allows tasks to run asynchronously, freeing the playbook to continue executing other tasks while the async operation completes in the background.
|
||||
|
||||
### Key Parameters
|
||||
|
||||
- `async`: Maximum number of seconds to wait for the task to complete
|
||||
- `poll`: Number of seconds to wait between checks (0 means no polling)
|
||||
|
||||
### Example Playbook
|
||||
- `async`: Maximum number of seconds to wait for the task to complete (e.g., `async: 30` waits 30 seconds)
|
||||
- `poll`: Number of seconds between status checks (0 means no polling)
|
||||
|
||||
### Example: Database Migration
|
||||
```yaml
|
||||
- name: Restart service asynchronously
|
||||
service:
|
||||
name: apache2
|
||||
- name: Initiate database migration
|
||||
mysql_db:
|
||||
name: production_db
|
||||
state: restarted
|
||||
async: 10
|
||||
poll: 0
|
||||
async: 60
|
||||
poll: 5
|
||||
|
||||
# Check async task status:
|
||||
# ansible-playbook site.yml --check
|
||||
```
|
||||
- name: Check migration status
|
||||
async_status:
|
||||
jid: "{{ async_jid }}"
|
||||
register: migration_result
|
||||
|
||||
- name: Fail task if migration failed
|
||||
fail:
|
||||
msg: "Database migration failed: {{ migration_result.stdout }}"
|
||||
when: migration_result.failed
|
||||
"""
|
||||
|
||||
### Best Practices
|
||||
1. Use async for I/O-bound tasks (e.g., API calls, file transfers)
|
||||
2. Combine with `ignore_errors: yes` for resilient workflows
|
||||
3. Always register async job IDs (`async_jid`) for monitoring
|
||||
4. Use `--check` flag to simulate async operations without executing
|
||||
|
||||
### Monitoring Async Tasks
|
||||
Use the `async_status` module to track progress:
|
||||
```yaml
|
||||
- name: Monitor async task
|
||||
async_status:
|
||||
jid: "{{ async_jid }}"
|
||||
register: task_result
|
||||
|
||||
- name: Display task status
|
||||
debug:
|
||||
msg: "Task status: {{ task_result.status }}"
|
||||
"""
|
||||
|
||||
### Troubleshooting
|
||||
- Use `--verbosity=2` to see detailed async output
|
||||
- Check the `ansible_async` directory for job logs
|
||||
- Verify network connectivity for remote tasks
|
||||
- Ensure correct credentials for authenticated operations
|
||||
|
||||
### When to Use Async
|
||||
- API calls with long response times
|
||||
- File transfers between nodes
|
||||
- Scheduled maintenance windows
|
||||
- Operations requiring user intervention
|
||||
|
||||
### When Not to Use Async
|
||||
- Simple, fast operations
|
||||
- Tasks requiring immediate feedback
|
||||
- Operations with strict timing requirements
|
||||
|
||||
Async mode transforms Ansible from a sequential executor to a parallel orchestrator, enabling more efficient management of complex infrastructure workflows.
|
||||
|
||||
### Best Practices
|
||||
|
||||
|
||||
Reference in New Issue
Block a user