Reusable automation and operational contracts

Infrastructure & Operations

Public infrastructure work that separates reusable automation, image-building, and system runbooks from private runtime configuration.

  • Ansible
  • Packer
  • Proxmox VE
  • Python
  • PowerShell
  • Bash
  • Docker
infra-ansible public repository ↗packer-proxmox-templates public repository ↗
Problem
Infrastructure work needs repeatable baselines, image builds, validations, and recovery documentation without publishing the runtime details that identify real environments.
Contribution
Wrote reusable Ansible roles, Packer image templates with validation, and e-SUS PEC bootstrap runbooks.
Key decision
Separate generic infrastructure contracts from system-specific bootstraps and rebuild images through Packer instead of manual changes.
Repository
infra-ansible public repository ↗packer-proxmox-templates public repository ↗esus-pec-bootstrap public repository ↗

01 / Context

Context & contribution

Problem

Infrastructure work needs repeatable baselines, image builds, validations, and recovery documentation without publishing the runtime details that identify real environments.

Context

This case study combines only public evidence from three repositories. Its system view is a sanitized, illustrative reference topology, not a production inventory or a map of any real environment.

Contribution

  • Defined reusable Ansible roles and playbook contracts for server baselines, access hardening, firewall, backup, monitoring, and provisioning concerns.
  • Built repeatable Packer templates and validation routines for Linux and Windows image families.
  • Organized e-SUS PEC automation, validators, and operational runbooks in a dedicated lifecycle boundary.
  • Kept public examples separate from runtime inventory, credentials, endpoints, and environment state.

02 / Technical choices

Engineering decisions

Problem
Generic server operations and system-specific bootstraps change at different rates and couple unrelated work when kept together.
Decision
Scope infra-ansible to reusable Ansible code; inventory, secrets, image builds and each bootstrap live in their own repositories, consumed by pinned ref.
See in the code ↗
Problem
Hand-edited VM templates make it hard to know what changed between images or to reproduce one exactly.
Decision
Define templates as code and rebuild them: Packer HCL2 for Windows, versioned import scripts from official cloud images for Linux.
See in the code ↗
Problem
An operational script without a runbook or example configuration becomes unclear about what it changes and what it depends on.
Decision
Ship each operational script with a paired runbook and example configuration, and statically check that all three are present.
See in the code ↗

03 / Current state

Current state

Outcomes

  • The public repositories demonstrate repeatable infrastructure practices across configuration, image, and application-operation layers.
  • Explicit repository boundaries reduce duplication and make ownership of automation and documentation clearer.

04 / Public record

Public evidence

infra-ansible public repository

Generic Ansible roles, playbooks, examples, validation, and public scope boundaries.

Open public evidence ↗

packer-proxmox-templates public repository

Packer definitions, image-build scripts, validation, and public operational documentation.

Open public evidence ↗

esus-pec-bootstrap public repository

System-specific automation, validators, and public runbooks for application operations.

Open public evidence ↗

05 / Optional walkthrough

A paused, synthetic lifecycle of the system. Press Play or step through the chapters to explore states, failures and limits.

Systems Atlas / LifecycleSynthetic · illustrative

01 / 06

See the starting state

Uma instância serve no node-02. O estado desejado é running.

Node 02Ready to explore
WorkloadReady to explore
ClientReady to explore

See the starting state

Result

Workload: running on node-02. Generation 1. Client can access the service.

Paused · operation 1 / 16
Try a scenario

Actions preserve the current state and stop the guided tour. Replay starts over.

Controller e storage externos sobrevivem ao pool de workers. Restart gera nova instância; não preserva memória de host morto.

Read the complete lifecycle transcript

Calculated from the engine during the build. Available without JavaScript.

Falhar até zero. Retomar com segurança.

  1. Operação normal

    Uma instância serve no node-02. O estado desejado é running.

    Workload: running on node-02. Generation 1. Client can access the service.

  2. Host interrompido

    node-02 falha. A instância para; seu antigo proprietário precisa ser excluído.

    Workload: interrupted on none. Generation 1. Waiting: FENCING_REQUIRED.

  3. Exclusão confirmada

    O proprietário anterior não pode continuar gravando. Procurar capacidade elegível.

    Workload: pending on none. Generation 1. Waiting: none.

  4. Nova instância iniciando

    A definição persistida inicia geração nova no node-01; ainda sem saúde confirmada.

    Workload: starting on node-01. Generation 2. Waiting: none.

  5. Serviço retomado

    Healthcheck falso confirma a instância; o cliente volta a ser atendido.

    Workload: running on node-01. Generation 2. Client can access the service.

  6. Host interrompido

    node-01 falha. A instância para; seu antigo proprietário precisa ser excluído.

    Workload: interrupted on none. Generation 2. Waiting: FENCING_REQUIRED.

  7. Exclusão confirmada

    O proprietário anterior não pode continuar gravando. Procurar capacidade elegível.

    Workload: pending on none. Generation 2. Waiting: none.

  8. Nova instância iniciando

    A definição persistida inicia geração nova no node-03; ainda sem saúde confirmada.

    Workload: starting on node-03. Generation 3. Waiting: none.

  9. Serviço retomado

    Healthcheck falso confirma a instância; o cliente volta a ser atendido.

    Workload: running on node-03. Generation 3. Client can access the service.

  10. Host interrompido

    node-03 falha. A instância para; seu antigo proprietário precisa ser excluído.

    Workload: interrupted on none. Generation 3. Waiting: FENCING_REQUIRED.

  11. Exclusão confirmada

    O proprietário anterior não pode continuar gravando. Procurar capacidade elegível.

    Workload: pending on none. Generation 3. Waiting: NO_CAPACITY.

  12. Zero workers disponíveis

    Não existe destino. O serviço fica indisponível, mas sua intenção e dados permanecem.

    Workload: pending on none. Generation 3. Waiting: NO_CAPACITY.

  13. Um worker voltou

    Ligar não é estar pronto. Boot e checagens devem terminar.

    Workload: pending on none. Generation 3. Waiting: NO_READY_NODE.

  14. Worker elegível

    O controller independente enxerga capacidade pronta e agenda reconciliação.

    Workload: pending on none. Generation 3. Waiting: none.

  15. Autostart da intenção preservada

    Sem novo pedido de start: desired=running produz uma nova instância.

    Workload: starting on node-02. Generation 4. Waiting: none.

  16. Ciclo concluído

    O mesmo workload lógico voltou a atender; a instância agora é g4.

    Workload: running on node-02. Generation 4. Client can access the service.

Voltar não basta: quorum e storage.

  1. Três votantes

    Três nós aptos; 3/3 votos e dados disponíveis.

    Workload: running on node-02. Generation 1. Client can access the service.

  2. Primeira falha

    2/3 mantém quorum; excluir o antigo proprietário antes de reiniciar.

    Workload: interrupted on none. Generation 1. Waiting: FENCING_REQUIRED.

  3. Fence confirmado

    Quorum e dados permitem procurar novo destino.

    Workload: pending on none. Generation 1. Waiting: none.

  4. Reiniciando no node-01

    Destino pronto; esperar a saúde da nova instância.

    Workload: starting on node-01. Generation 2. Waiting: none.

  5. Operação em 2/3

    Serviço volta enquanto as condições permanecem válidas.

    Workload: running on node-01. Generation 2. Client can access the service.

  6. Perda de maioria

    Só 1/3 resta. Novo start fica bloqueado, mesmo havendo um host.

    Workload: interrupted on none. Generation 2. Waiting: NO_QUORUM, FENCING_REQUIRED.

  7. Fence não resolve quorum

    Excluir o proprietário anterior não cria votos.

    Workload: pending on none. Generation 2. Waiting: NO_QUORUM.

  8. Todos fora do ar

    Nenhuma capacidade de compute ou quorum. Dados ainda não estão disponíveis.

    Workload: pending on none. Generation 2. Waiting: NO_QUORUM, STORAGE_UNAVAILABLE, NO_CAPACITY.

  9. Primeiro retorno em boot

    Ainda não existe um votante utilizável.

    Workload: pending on none. Generation 2. Waiting: NO_QUORUM, STORAGE_UNAVAILABLE, NO_CAPACITY.

  10. Somente 1/3 pronto

    Continua bloqueado. O demo não muda os votos esperados.

    Workload: pending on none. Generation 2. Waiting: NO_QUORUM, STORAGE_UNAVAILABLE.

  11. Segundo nó em boot

    Preparar o segundo membro ainda não restaura quorum.

    Workload: pending on none. Generation 2. Waiting: NO_QUORUM, STORAGE_UNAVAILABLE.

  12. Quorum restaurado

    2/3 está pronto; o storage ainda precisa ficar utilizável.

    Workload: pending on none. Generation 2. Waiting: STORAGE_UNAVAILABLE.

  13. Dados disponíveis

    Agora todas as dependências de start estão satisfeitas.

    Workload: pending on none. Generation 2. Waiting: none.

  14. Autostart autorizado

    Uma instância nova é iniciada no primeiro destino elegível.

    Workload: starting on node-01. Generation 3. Waiting: none.

  15. Recuperação segura

    Serviço saudável após retorno de quorum, dados e compute.

    Workload: running on node-01. Generation 3. Client can access the service.

Capacidade primeiro. Réplicas depois.

  1. Serviço inicial

    Um worker e uma réplica atendem dentro da capacidade física.

    Target: 1 replicas. Ready: 1. Capacity: 1 used, 0 reserved across 3 physical hosts.

  2. Carga elevada

    O sinal muda; ainda não criar recursos por um único pico.

    Target: 1 replicas. Ready: 1. Capacity: 1 used, 0 reserved across 3 physical hosts.

  3. Persistência confirmada

    Dois ticks lógicos confirmam a condição da política.

    Target: 1 replicas. Ready: 1. Capacity: 1 used, 0 reserved across 3 physical hosts.

  4. Desired aumenta

    São desejadas três réplicas. Ready ainda é um.

    Target: 3 replicas. Ready: 1. Capacity: 1 used, 0 reserved across 3 physical hosts.

  5. Reservar recursos

    Duas reservas cabem no pool. Hosts físicos continuam três.

    Target: 3 replicas. Ready: 1. Capacity: 1 used, 2 reserved across 3 physical hosts.

  6. Provisionar e configurar

    Reservas viram recursos reais do modelo, ainda não servíveis.

    Target: 3 replicas. Ready: 1. Capacity: 3 used, 0 reserved across 3 physical hosts.

  7. Boot dos workers

    Apenas a réplica original atende; novos workers estão em boot.

    Target: 3 replicas. Ready: 1. Capacity: 3 used, 0 reserved across 3 physical hosts.

  8. Capacidade elegível

    Health/config dos workers concluídos. Réplicas ainda não iniciadas.

    Target: 3 replicas. Ready: 1. Capacity: 3 used, 0 reserved across 3 physical hosts.

  9. Iniciar serviço

    Duas novas instâncias são criadas com identidades próprias.

    Target: 3 replicas. Ready: 1. Capacity: 3 used, 0 reserved across 3 physical hosts.

  10. Scale-out completo

    Três réplicas prontas participam do roteamento.

    Target: 3 replicas. Ready: 3. Capacity: 3 used, 0 reserved across 3 physical hosts.

  11. Carga cai

    Não reduzir por um único ponto nem antes do cooldown.

    Target: 3 replicas. Ready: 3. Capacity: 3 used, 0 reserved across 3 physical hosts.

  12. Janela e cooldown satisfeitos

    O relógio lógico atravessa a janela mínima e o cooldown.

    Target: 3 replicas. Ready: 3. Capacity: 3 used, 0 reserved across 3 physical hosts.

  13. Desired reduz

    O alvo volta a um; três instâncias ainda existem.

    Target: 1 replicas. Ready: 3. Capacity: 3 used, 0 reserved across 3 physical hosts.

  14. Drenagem

    Retirar duas réplicas do tráfego novo; aguardar duas requisições em voo.

    Target: 1 replicas. Ready: 1. Capacity: 3 used, 0 reserved across 3 physical hosts.

  15. Drenagem concluída

    Nenhuma requisição pendente nessas réplicas; agora podem parar.

    Target: 1 replicas. Ready: 1. Capacity: 3 used, 0 reserved across 3 physical hosts.

  16. Parar instâncias

    Processos retirados sem apagar o pool físico.

    Target: 1 replicas. Ready: 1. Capacity: 3 used, 0 reserved across 3 physical hosts.

  17. Recursos liberados

    Volta a um worker usado; três hosts físicos permanecem.

    Target: 1 replicas. Ready: 1. Capacity: 1 used, 0 reserved across 3 physical hosts.

Current state and operation
{
  "type": "INIT"
}

06 / Limits & details

Limitations & details

Limitations

  • The topology is illustrative and cannot be used to infer a real deployment, inventory, network, or secret layout.
  • Public evidence demonstrates reusable contracts and workflows, not the current state or availability of any target system.
  • No private repository names, IP addresses, hostnames, credential locations, or real operational identifiers are included.

Reliability

  • Static validation, syntax checks, and preflight scripts provide cheap feedback before infrastructure code reaches a target.
  • Runbooks cover prerequisites, verification, rollback, and evidence expectations for operational changes.
  • Backup and monitoring concerns are represented as reusable contracts without exposing live destinations or endpoints.
  • Examples and interfaces are published while all environment-specific configuration stays outside the portfolio content.

System View

Architecture and component details

Conceptual reference topology, not a production inventory or a map of any real environment. Connectors describe responsibilities converging on a shared topology rather than an active deployment.

Reference topology map

Three source capabilities converge on one reference topology.

Component details

Generic roles, playbooks, example inputs, and validators define the shareable automation boundary.

Sends to
  • Configures target systems

Packer definitions and supporting scripts establish repeatable Linux and Windows template workflows.

Sends to
  • Provides repeatable base images

Dedicated scripts, validators, and runbooks keep application operations separate from base-image lifecycle work.

Sends to
  • Operates target systems

The relationship among automation control, image building, target systems, monitoring, and backup is deliberately generalized.

Receives from
  • Provides repeatable base images
  • Configures target systems
  • Operates target systems