Mateusz Suski
35e6b139fc
ci / validate (push) Failing after 1m8s
Rework portfolio around Linux operations, Zabbix monitoring, migration validation, and ELK/Grafana log observability. Add AAP-style LVM resize workflow, Zabbix server/proxy/agent automation assets, Linux/AIX monitoring templates, and updated validation CI.
31 lines
974 B
Markdown
31 lines
974 B
Markdown
# Linux Operations Automation Architecture
|
|
|
|
## Components
|
|
|
|
- Operator interface: `make` targets and direct Ansible commands.
|
|
- Inventory: static host groups in `inventory/hosts.ini`.
|
|
- Automation: lifecycle playbooks in `playbooks/`.
|
|
- Simulation scripts: controlled failure and scaling events in `scripts/`.
|
|
- Evidence: logs, reports, scenario notes, and examples.
|
|
|
|
## Data Flow
|
|
|
|
```
|
|
Operator
|
|
-> Make target or shell script
|
|
-> Ansible inventory
|
|
-> lifecycle playbook
|
|
-> managed Linux node
|
|
-> log/report artifact
|
|
```
|
|
|
|
Failure drills follow a parallel flow:
|
|
|
|
```
|
|
Operator -> simulate_failure.sh -> target node/service -> health check -> patch/hardening playbook -> evidence
|
|
```
|
|
|
|
## Notes
|
|
|
|
The project favors explicit playbooks over hidden orchestration so the operational intent is visible during review. In a production implementation, the same workflows would typically run from a CI runner or automation controller with credentials supplied by a secret manager.
|