thesabear/public
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update the readme

Browse Source
This commit is contained in:
thesabear committed 2026-08-24 13:36:07 +03:00
1 parent 62d1a508eb
commit a7f1a98ed2
1 file changed
+13 -21
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+13 -21
View File
@@ -44,41 +44,33 @@ My long-term goal is to build a career in IT — specifically in environments wh
--- ---
## 👀 What I'm Exploring ## 👀 What I Have Explored
I use my homelab as a real-world playground to deepen my understanding of core IT concepts. Some of the areas I'm actively exploring include: I use my homelab as a real-world playground to deepen my understanding of core IT concepts. Some of the areas I've learned and put into practice are:
- Infrastructure-as-Code: provisioning and hardening hosts from scratch with Terraform + Packer + Ansible - **Infrastructure-as-Code**: infrastructure that's provisioned, hardened, and reproducible from code — not clicked together by hand
- Reverse-proxy architecture and identity: a dual-zone Caddy setup (internal service-to-service vs. user-facing) fronted by Authentik forward-auth - **Security**: defense-in-depth in practice — network segmentation, secrets management, and identity, layered so no single control is ever the only thing standing between an attacker and everything else
- Workflow automation: Ansible for scheduled fleet maintenance, Kestra and n8n for everything else - **Automation**: fleet-wide operations running end-to-end on its own, with a human kept in the loop exactly where the consequences of getting it wrong are highest
- Monitoring, observability, and resilient service design - **Monitoring**: observability and security detection working as one system, not two separate concerns bolted together
Each project teaches me something new, and everything I learn pushes me further toward becoming a well-rounded IT/DevOps engineer. Each project started as something I didn't know how to do. Now it's just part of how this fleet runs — and pushes me further toward being a well-rounded IT/DevOps engineer.
--- ---
## 🌱 What I'm Learning Right Now ## 🌱 What I'm Focused On Right Now
I'm currently focused on:
- Refining the Ansible roles and playbooks that keep the fleet patched and consistent - Refining the Ansible roles and playbooks that keep the fleet patched and consistent
- Tightening the Caddy/Authentik reverse-proxy and SSO design as new services get added - Looking for genuine opportunities to put my Gitea CI/CD to work beyond hosting the registry, wherever it'd actually help
- Running my own self-hosted Gitea instead of relying on external platforms - Sharpening my scripting — Bash and Python, aimed at real-world IT skills I can use beyond this homelab
- Improving scripting skills — Python and Bash are next on my list
I enjoy understanding not just how something works, but how to automate it, secure it, and integrate it cleanly into a larger system.
--- ---
## ⚡ Fun Fact ## ⚡ Fun Fact
I'm entirely self-taught. Every tool, trick, concept, and workflow in my repos is something I learned by doing — from reading docs to breaking my lab at 2 a.m. and fixing it again.
![Profile Banner](https://img.shields.io/badge/Homelab-Explorer-blue?style=for-the-badge&logo=linux) I'm entirely self-taught. Every tool, trick, concept, and workflow in my repo's is something I learned by doing — from reading docs to breaking my lab at 2 a.m. and fixing it again before anyone noticed anything was ever wrong. There's no ticket queue here and no one to escalate to — when something breaks at midnight, I'm the on-call engineer, the incident commander, and the entire post-mortem team arguing with myself about whose fault it was (mine, always mine). I enjoy understanding not just how something works, but how to automate it, secure it, and integrate it cleanly into a larger system — "just add one more service" remains a permanent, unsolved architectural risk.
![Docker](https://img.shields.io/badge/Docker-Containers-blue?style=for-the-badge&logo=docker)
![Python](https://img.shields.io/badge/Python-Learning-yellow?style=for-the-badge&logo=python)
![Bash](https://img.shields.io/badge/Bash-Scripting-lightgrey?style=for-the-badge&logo=gnu-bash)
--- ---
## Architecture At A Glance
## Architecture at a glance
![Architecture Overview](assets/architecture-overview.svg) ![Architecture Overview](assets/architecture-overview.svg)
Solid arrows are hard dependencies — the target has to be reachable for the source to function. Dashed arrows are secondary relationships (request routing like "proxies"/"auth", or async telemetry reporting) that don't block the source if the target's unavailable. Full breakdown of all 8 traffic laws (ingress, east-west, secrets, DNS, observability, notifications, CI/CD, management) with the actual trust-boundary reasoning: [docs/architecture-overview.md](docs/architecture-overview.md). Solid arrows are hard dependencies — the target has to be reachable for the source to function. Dashed arrows are secondary relationships (request routing like "proxies"/"auth", or async telemetry reporting) that don't block the source if the target's unavailable. Full breakdown of all 8 traffic laws (ingress, east-west, secrets, DNS, observability, notifications, CI/CD, management) with the actual trust-boundary reasoning: [docs/architecture-overview.md](docs/architecture-overview.md).