Initial CV-aligned infrastructure portfolio

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.
2026-05-04 17:37:24 +00:00
commit 35e6b139fc
114 changed files with 6422 additions and 0 deletions
@@ -0,0 +1,45 @@
+# AAP-Style LVM Resize Workflow
+
+## Purpose
+
+This workflow shows how a routine storage ticket can be converted into a controlled Ansible Automation Platform job. It is intentionally conservative: dry-run is the default, required variables are explicit, and every run produces before/after evidence.
+
+## Suggested Job Template
+
+- Name: `Linux - LVM Filesystem Resize`
+- Inventory: Linux production or pre-production inventory
+- Playbook: `playbooks/lvm_resize.yml`
+- Credentials: privileged Linux automation credential
+- Privilege escalation: enabled
+- Default extra vars:
+
+```yaml
+lvm_dry_run: true
+lvm_resize_filesystem: true
+```
+
+## Suggested Survey Variables
+
+| Variable | Example | Required | Notes |
+| --- | --- | --- | --- |
+| `lvm_vg_name` | `vg_app` | yes | Target volume group. |
+| `lvm_lv_name` | `lv_data` | yes | Target logical volume. |
+| `lvm_mountpoint` | `/data` | yes | Filesystem mountpoint to validate before/after. |
+| `lvm_size_request` | `+20G` | yes | Passed to `lvextend -L`; use explicit growth syntax for tickets. |
+| `lvm_dry_run` | `true` | yes | Start with `true`; switch to `false` after evidence review. |
+
+## Safety Notes
+
+- Run with `lvm_dry_run=true` first and attach output to the ticket.
+- Confirm backup/snapshot status before actual resize.
+- Confirm filesystem type; this workflow supports XFS and ext filesystems.
+- Keep requested size aligned with the ticket approval.
+- Use maintenance windows for critical systems.
+
+## Evidence Captured
+
+- `lsblk --fs`
+- `pvs`, `vgs`, `lvs`
+- `df -hT <mountpoint>` before and after
+- target LV path and filesystem type
+- dry-run flag and requested size
@@ -0,0 +1,30 @@
+# 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.