Automacao Linux & Infraestrutura – Bash, Python, systemd, Proxmox

Posicionamento

O Linux e ha decadas a plataforma dominante para infraestruturas de servidores, tarefas de automacao e fluxos de processamento de dados em organizacoes de todos os tamanhos. Minha experiencia com Linux e Unix se estende de projetos iniciais com AIX/KSH em grandes ambientes corporativos ate infraestruturas modernas Debian e Ubuntu que construo, opero e mantenho hoje para uso pessoal, projetos de clientes e cenarios hibridos. Ao longo desse tempo aprendi que uma solida automacao Linux nao consiste em scripts individuais, mas em um sistema completo: agendador, tratamento robusto de erros, logging, monitoramento, backup e documentacao.

O que me diferencia de especialistas em infraestrutura pura e a combinacao com o mundo de dados. Trago habilidades de automacao Linux junto com conhecimento profundo de SQL Server, data warehouses, pipelines ETL e processos de BI. Pipelines de carga e descarga rodando no Linux que alimentam bancos de dados SQL Server; jobs de transferencia Connect:Direct usando scripts shell como wrappers; scripts Python que extraem e transformam dados de DWH — esse e o ambiente no qual trabalho ha anos.

Alem disso, opero minha propria infraestrutura: um ambiente Proxmox multi-site com proxy reverso NGINX, VPN WireGuard, containers LXC, servicos Docker, Authelia SSO e backups automatizados. Essa operacao pratica nao e um projeto paralelo — e a prova de que uso as tecnologias aqui descritas em producao e conheco suas armadilhas por experiencia propria.

Escopo da Automacao Linux

A automacao Linux abrange um amplo espectro de tecnologias e tarefas. No nivel mais baixo estao os scripts shell que automatizam tarefas recorrentes: transferencias de arquivos, rotacao de logs, geracao de relatorios, orquestracao de jobs. No nivel seguinte estao os mecanismos de agendamento como cron e timers systemd, que executam esses scripts com base em tempo ou eventos. Acima disso fica a automacao de processos, onde rodam scripts Python, gatilhos ETL e extracoes de banco de dados.

Scripting Shell: Bash e KSH

Bash e o shell padrao na maioria das distribuicoes Linux; KSH (Korn Shell) e seu equivalente no AIX e em sistemas Unix mais antigos. Tenho fluencia em ambos e conheco as diferencas: sintaxe de arrays, expansao aritmetica, substituicao de processo e armadilhas de portabilidade. Em ambientes corporativos aplico consistentemente programacao defensiva: set -euo pipefail como base, trap para limpeza em erros, logging estruturado com timestamps e codigos de saida bem definidos para monitoramento por agendadores ou sistemas de monitoramento.

Python como Complemento ao Shell

Python complementa os scripts shell onde sao necessarios processamento de dados mais complexo, tratamento estruturado de erros ou bibliotecas externas. Watchers de arquivos com watchdog, conexoes de banco de dados via pyodbc, chamadas REST API, transformacoes de dados com pandas — tudo isso e muito mais limpo e sustentavel em Python do que em codigo shell. Combino os dois mundos: shell para integracao de sistema, orquestracao de processos e transformacoes simples; Python para processamento de dados, logica complexa e integracoes externas.

Virtualizacao e Containers

O Proxmox VE e minha plataforma de virtualizacao preferida para infraestruturas on-premise. Os containers LXC oferecem o meio-termo entre VMs e Docker: menos sobrecarga do que VMs completas, mais isolamento do que processos simples. Uso Docker onde as aplicacoes ja vem como containers ou onde e necessaria portabilidade rapida. A combinacao de host Proxmox, LXC para servicos de sistema e Docker para aplicacoes e um padrao consolidado para infraestruturas de medio porte.

• Debian/Ubuntu, SUSE Linux, AIX — distribuicao e shell adequados ao ambiente do projeto
• Scripting Bash/KSH: set -euo pipefail, trap, logging, codigos de saida
• Automacao Python: pyodbc, watchdog, pandas, paramiko, REST APIs
• Cron e timers systemd: agendamento, gerenciamento de dependencias, journalling
• Proxmox VE: containers LXC, gerenciamento de VMs, operacao de cluster
• Docker: stacks Compose, gerenciamento de volumes, automacao de atualizacoes
• NGINX: proxy reverso, terminacao SSL, rate limiting, Let's Encrypt
• VPN WireGuard: site-a-site, road warrior, gerenciamento de chaves
• rsync/rclone: backup, sincronizacao, replicacao offsite
• Hardening: fail2ban, iptables/nftables, hardening SSH, firewall

Scripting Bash Robusto com Tratamento de Erros e Logging

Scripts Bash sao frequentemente escritos as pressas e depois executados em producao por anos sem nunca serem revisados. Isso resulta em scripts que falham silenciosamente, nao deixam rastro de log e cujo estado de erro ninguem monitora. Sigo um padrao basico fixo em todo script de producao que combina tratamento robusto de erros, logging estruturado e logica de limpeza limpa.

Os principais blocos de construcao: set -euo pipefail aborta o script imediatamente em qualquer erro (em vez de continuar silenciosamente), variaveis nao definidas sao tratadas como erros e falhas em pipes sao expostas. trap ERR e trap EXIT garantem que recursos sejam liberados e estados de erro registrados independentemente de como o script termina. Timestamps no log permitem a reconstrucao post-mortem das execucoes.

Pipeline tipica de automacao Linux: um agendador (cron ou timer systemd) aciona um script shell ou Python que processa dados e os transfere para um destino (DWH ou Connect:Direct). Logging e monitoramento estao ancorados em cada etapa.

Template de Script com set -euo pipefail e trap

#!/usr/bin/env bash
# Script de producao para tarefas de carga e processamento de arquivos
# Requisitos: set -euo pipefail, logging, trap para limpeza
set -euo pipefail

# -- Configuracao -------------------------------------------------------------
NOME_SCRIPT="$(basename "$0" .sh)"
DIR_LOG="/var/log/etl"
ARQ_LOG="${DIR_LOG}/${NOME_SCRIPT}_$(date +%Y%m%d).log"
ARQ_LOCK="/var/run/${NOME_SCRIPT}.lock"
DIR_ENTRADA="/data/entrada"
DIR_PROCESSADO="/data/processado"
DIR_ARQUIVO="/data/arquivo"
MAX_DIAS=30  # Remover arquivos de arquivo mais antigos que 30 dias

# -- Funcao de logging --------------------------------------------------------
log() {
    local nivel="$1"; shift
    echo "$(date '+%Y-%m-%d %H:%M:%S') [${nivel}] $*" | tee -a "${ARQ_LOG}"
}

# -- Handler de erro e limpeza ------------------------------------------------
limpeza() {
    local codigo_saida=$?
    if [[ -f "${ARQ_LOCK}" ]]; then
        rm -f "${ARQ_LOCK}"
        log "INFO" "Arquivo de lock removido"
    fi
    if [[ $codigo_saida -ne 0 ]]; then
        log "ERROR" "Script encerrado com codigo ${codigo_saida} -- linha: ${BASH_LINENO[0]}"
        # Opcional: notificacao por e-mail ou monitoramento
        # echo "Erro ETL em ${NOME_SCRIPT}" | mail -s "ERRO: ${NOME_SCRIPT}" admin@example.com
    else
        log "INFO" "Script concluido com sucesso (saida 0)"
    fi
}
trap limpeza EXIT
trap 'log "ERROR" "Erro na linha $LINENO (comando: $BASH_COMMAND)"; exit 1' ERR

# -- Pre-requisitos ------------------------------------------------------------
mkdir -p "${DIR_LOG}" "${DIR_PROCESSADO}" "${DIR_ARQUIVO}"

# Evitar execucao concorrente (lock baseado em flock)
if [[ -f "${ARQ_LOCK}" ]]; then
    log "WARN" "Script ja em execucao (lock: ${ARQ_LOCK}) -- abortando"
    exit 0
fi
echo $$ > "${ARQ_LOCK}"
log "INFO" "=== ${NOME_SCRIPT} iniciado (PID $$) ==="

# -- Logica principal ---------------------------------------------------------
shopt -s nullglob  # Sem erro se glob nao retornar resultados
arquivos=("${DIR_ENTRADA}"/*.csv)

if [[ ${#arquivos[@]} -eq 0 ]]; then
    log "INFO" "Nenhum arquivo de entrada encontrado -- nada a fazer"
    exit 0
fi

log "INFO" "${#arquivos[@]} arquivo(s) encontrado(s)"

for arq in "${arquivos[@]}"; do
    nome_arq="$(basename "${arq}")"
    log "INFO" "Processando: ${nome_arq}"

    # Criar arquivo de destino (transformacao via sed/awk/python possivel)
    cp "${arq}" "${DIR_PROCESSADO}/${nome_arq}"

    # Arquivar o arquivo fonte
    mv "${arq}" "${DIR_ARQUIVO}/${nome_arq%.csv}_$(date +%Y%m%d%H%M%S).csv"
    log "INFO" "Arquivado: ${nome_arq}"
done

# Remover arquivos de arquivo antigos
find "${DIR_ARQUIVO}" -name "*.csv" -mtime "+${MAX_DIAS}" -delete
log "INFO" "Limpeza de arquivo: arquivos mais antigos que ${MAX_DIAS} dias removidos"

log "INFO" "=== Processamento concluido ==="

Uso este padrao como base para todos os scripts Bash de producao: set -euo pipefail, logging com timestamps, lock baseado em flock contra execucoes duplicadas e limpeza baseada em trap. O codigo de saida e avaliado pelo sistema de monitoramento e pelo agendador.

Cron vs. Timer systemd: Quando Usar Qual

Cron e o agendador classico do Linux e disponivel em todo sistema. Para tarefas simples orientadas por tempo, o cron e suficiente. Os timers systemd oferecem mais: dependencias entre units, logging automatico via journald, expressoes de calendario precisas, timers monotonicos (relativos ao ultimo inicio) e a capacidade de verificar o status do timer com systemctl status. Em ambientes Debian e Ubuntu modernos prefiro timers systemd para novas tarefas porque se integram melhor com o sistema operacional.

systemd: Servicos, Timers e Gerenciamento de Dependencias

O systemd mudou fundamentalmente a operacao de servicos Linux. Onde antes eram necessarios scripts init e entradas cron, o systemd fornece uma interface unificada e declarativa: units de servico definem como um processo e iniciado, monitorado e reiniciado em caso de falha. Units de timer substituem o cron para tarefas agendadas com melhor journalling e expressoes de tempo mais flexiveis. E o gerenciamento de dependencias do systemd garante que um servico so seja iniciado quando seus pre-requisitos estiverem satisfeitos.

Na minha propria infraestrutura e em projetos de clientes gerencio dezenas de units systemd: servicos de banco de dados, gatilhos ETL, jobs de backup, agentes de monitoramento e configuracao de proxy reverso. A interacao entre units de servico, units de timer e units de target permite cadeias de dependencias precisas que garantem que os processos iniciem na ordem correta e sejam encerrados de forma limpa em caso de falha.

Infraestrutura Proxmox tipica multi-site: o site A executa NGINX, banco de dados e servicos Docker como containers LXC. A VPN WireGuard conecta o site A ao site B, que hospeda o destino de backup e monitoramento (Grafana). DNS e Authelia SSO fornecem gerenciamento centralizado de acesso.

# /etc/systemd/system/etl-carga-diaria.service
# Descricao: Executa o processo de carga ETL diaria
# Pre-requisitos: rede disponivel, PostgreSQL em execucao

[Unit]
Description=Carga ETL Diaria
Documentation=https://wiki.interno/processos-etl
After=network-online.target postgresql.service
Requires=network-online.target
Wants=postgresql.service

[Service]
Type=oneshot
# Executar como usuario dedicado sem root
User=etl-user
Group=etl-group

# Carregar variaveis de ambiente de arquivo seguro
EnvironmentFile=/etc/etl/etl-carga-diaria.env

# Processo principal
ExecStart=/opt/etl/bin/etl_carga_diaria.sh

# Limites de recursos: limitar CPU e memoria
CPUQuota=50%
MemoryMax=512M

# Escrever stdout/stderr no journal
StandardOutput=journal
StandardError=journal
SyslogIdentifier=etl-carga-diaria

# Reiniciar em saida inesperada (nao em saida 0)
Restart=on-failure
RestartSec=60s

[Install]
WantedBy=multi-user.target

# ---------------------------------------------------------------------------

# /etc/systemd/system/etl-carga-diaria.timer
# Execucao por tempo: dias uteis as 22h00

[Unit]
Description=Timer para Carga ETL Diaria
Requires=etl-carga-diaria.service

[Timer]
# Expressao de calendario: seg-sex as 22:00
OnCalendar=Mon-Fri 22:00:00
# Executar execucao perdida imediatamente se o sistema estava desligado
Persistent=true
# Atraso aleatorio de ate 5 minutos (distribuicao de carga em muitos timers)
RandomizedDelaySec=5min

[Install]
WantedBy=timers.target

# ---------------------------------------------------------------------------
# Ativacao e verificacao de status:
# systemctl daemon-reload
# systemctl enable --now etl-carga-diaria.timer
# systemctl status etl-carga-diaria.timer
# journalctl -u etl-carga-diaria.service -f   # Acompanhar log ao vivo

A unit de servico e a unit de timer trabalham como par: o timer aciona o servico. O servico roda como processo oneshot, escreve logging via journald e reporta erros ao timer via codigo de saida. systemctl list-timers mostra a proxima execucao agendada e as execucoes anteriores.

Gerenciamento de Dependencias em Cadeias Complexas

Quando multiplas etapas ETL devem executar em uma sequencia especifica, o systemd resolve isso elegantemente: cada etapa e sua propria unit de servico que inicia apos a etapa anterior (After=). Com OnSuccess= e OnFailure= no systemd 246+ units de acompanhamento podem ser iniciadas condicionalmente — por exemplo uma unit de notificacao em caso de falha ou uma unit de arquivamento em caso de sucesso. Essas dependencias declarativas sao muito mais claras do que cadeias if aninhadas em scripts shell.

• Type=oneshot para scripts batch, Type=simple/notify para servicos de longa duracao
• EnvironmentFile para passagem segura de credenciais (nao inline na unit)
• Restart=on-failure com RestartSec para estrategia automatica de reinicio
• CPUQuota e MemoryMax evitam que jobs ETL prejudiquem outros servicos
• Persistent=true no timer: execucoes perdidas sao retomadas
• journalctl -u -f para log ao vivo; --since para analise historica

Automacao Python no Linux

Python e o complemento ideal para o Bash em tarefas de automacao que vao alem de simples comandos de sistema. Watchers de arquivos que reagem a novos arquivos de entrada; gatilhos ETL que executam consultas de banco de dados e armazenam resultados como CSV ou Parquet; chamadas REST API que buscam dados de sistemas externos e os traduzem em estruturas locais — tudo isso e muito mais preciso, testavel e sustentavel em Python do que em codigo shell puro.

Em meus projetos usei automacao Python para implementar extracoes de banco de dados do SQL Server no Linux (sqlcmd/bcp ou pyodbc com o driver ODBC), para orquestrar e registrar execucoes de processamento em lote e para acionar notificacoes em erros ou operacoes de carga concluidas. A integracao de scripts Python em units systemd fornece agendamento confiavel com journalling completo.

#!/usr/bin/env python3
# Watcher de arquivos: novos CSVs na pasta de entrada acionam o processamento ETL
# Dependencias: watchdog, pyodbc, pandas, logging (todos standard/pip)

import sys
import time
import logging
import pathlib
import shutil
import pandas as pd
import pyodbc
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler

# -- Configuracao -------------------------------------------------------------
DIR_ENTRADA  = pathlib.Path("/data/entrada")
DIR_PROCESSADO = pathlib.Path("/data/processado")
DIR_ERRO     = pathlib.Path("/data/erro")
ARQ_LOG      = pathlib.Path("/var/log/etl/watcher_arquivos.log")

# String de conexao ODBC (driver: ODBC Driver 18 for SQL Server)
CONN_STR = (
    "DRIVER={ODBC Driver 18 for SQL Server};"
    "SERVER=servidor-bd.interno;"
    "DATABASE=DWH_Staging;"
    "Trusted_Connection=no;"
    "UID=usuario_etl;PWD=__da_env__;"  # Senha da variavel de ambiente
)

# -- Configuracao de logging --------------------------------------------------
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(message)s",
    handlers=[
        logging.FileHandler(ARQ_LOG),
        logging.StreamHandler(sys.stdout),
    ],
)
log = logging.getLogger(__name__)


def processar_csv(caminho: pathlib.Path) -> None:
    # Carregar CSV, transformar e gravar na tabela staging do SQL Server.
    log.info("Processando arquivo: %s", caminho.name)
    try:
        df = pd.read_csv(caminho, sep=";", encoding="utf-8", dtype=str)
        # Limpeza: remover espacos ao inicio/fim em todas as colunas string
        df = df.applymap(lambda x: x.strip() if isinstance(x, str) else x)
        df["timestamp_carga"] = pd.Timestamp.now()

        # Gravar na tabela staging do SQL Server
        conn = pyodbc.connect(CONN_STR, timeout=30)
        cursor = conn.cursor()
        cursor.fast_executemany = True
        colunas = ", ".join(df.columns)
        marcadores = ", ".join(["?"] * len(df.columns))
        sql = f"INSERT INTO staging.csv_entrada ({colunas}) VALUES ({marcadores})"
        cursor.executemany(sql, df.itertuples(index=False, name=None))
        conn.commit()
        conn.close()

        log.info("Carregado com sucesso: %d linhas de %s", len(df), caminho.name)
        # Mover arquivo processado com sucesso
        shutil.move(str(caminho), str(DIR_PROCESSADO / caminho.name))

    except Exception as erro:
        log.error("Erro ao processar %s: %s", caminho.name, erro, exc_info=True)
        # Mover arquivo com falha para revisao manual
        shutil.move(str(caminho), str(DIR_ERRO / caminho.name))
        raise  # Propagar para que systemd capture o codigo de saida de erro


class HandlerEntrada(FileSystemEventHandler):
    # Reagir a novos arquivos na pasta de entrada.
    def on_created(self, event):
        if event.is_directory:
            return
        caminho = pathlib.Path(event.src_path)
        if caminho.suffix.lower() == ".csv":
            # Pequena pausa: garantir que o arquivo esta completamente gravado
            time.sleep(0.5)
            processar_csv(caminho)


if __name__ == "__main__":
    for d in (DIR_ENTRADA, DIR_PROCESSADO, DIR_ERRO, ARQ_LOG.parent):
        d.mkdir(parents=True, exist_ok=True)

    log.info("Watcher de arquivos iniciado: %s", DIR_ENTRADA)
    observer = Observer()
    observer.schedule(HandlerEntrada(), str(DIR_ENTRADA), recursive=False)
    observer.start()
    try:
        while True:
            time.sleep(5)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()
    log.info("Watcher encerrado")

Este watcher de arquivos roda como servico systemd (Type=simple, Restart=on-failure). Reage a novos arquivos CSV, os carrega no staging do SQL Server e move arquivos para pastas de processado ou erro. pyodbc com ODBC Driver 18 da Microsoft roda confiavelmente no Debian/Ubuntu sem problemas.

Python e Shell como Equipe

A arquitetura mais limpa combina scripts shell para integracao de sistema e Python para logica de dados. Um wrapper shell inicia o script Python, verifica o codigo de saida, grava um resumo no log do sistema e notifica em caso de falha. O script Python se concentra no processamento de dados. Essa separacao torna ambas as partes individualmente testaveis e independentemente sustentaveis.

Proxmox VE e Virtualizacao LXC

O Proxmox Virtual Environment e uma plataforma de virtualizacao open-source que combina virtualizacao KVM e containers LXC em uma unica interface de gerenciamento. Opero o Proxmox em producao na minha propria infraestrutura e trago essa experiencia para projetos de clientes que precisam de virtualizacao on-premise sem solucoes caras de vendor lock-in.

Os containers LXC sao o formato de implantacao preferido para processos de servidor no Proxmox: iniciam em segundos, consomem significativamente menos recursos do que VMs completas e sao faceis de criar snapshot e restaurar via Proxmox. Um container por servico — NGINX, banco de dados, monitoramento, agente de backup — fornece isolamento limpo e manutencao simples.

Clustering e Alta Disponibilidade

O Proxmox suporta clustering com varios nos e fornece alta disponibilidade integrada para VMs e containers. Em uma configuracao de dois nos com um dispositivo de quorum externo, HA basica pode ser realizada sem complexidade significativa. Para servicos criticos isso significa failover automatico em caso de falha de no em segundos a minutos.

Backup e Snapshotting

O Proxmox Backup Server (PBS) e o companheiro natural do Proxmox VE: backups incrementais e deduplicados de VMs e containers com verificacao de integridade. Jobs de backup configurados rodam durante a noite; o PBS verifica periodicamente a integridade dos dados de backup. Adicionalmente uso backups em nivel de guest com restic ou rclone para proteger dados de aplicacao de forma independente do backup de VM.

• Proxmox VE como hipervisor on-premise: KVM e LXC em uma unica plataforma
• Containers LXC: provisionamento rapido, eficiente em recursos, com snapshot
• Cluster Proxmox: HA, migracao ao vivo, gerenciamento centralizado de varios nos
• Proxmox Backup Server: backups incrementais e deduplicados com verificacao
• Rede: Linux bridges, VLANs, Open vSwitch para topologias complexas
• Armazenamento: ZFS para dados de producao com snapshots e checksums
• Automacao: API Proxmox e pvesh para gerenciamento de VM/LXC via scripts

Docker e Servicos em Container

Docker e o padrao na minha infraestrutura para servicos de aplicacao que vem como containers ou para os quais existem imagens prontas. No Proxmox, os servicos Docker tipicamente rodam dentro de um container LXC dedicado (containers aninhados), fornecendo isolamento entre servicos de sistema e servicos de aplicacao. O Docker Compose gerencia stacks de multiplos servicos e suas dependencias de forma declarativa.

Atualizacoes automatizadas sao um aspecto importante das operacoes Docker: Watchtower ou um script de atualizacao personalizado verifica periodicamente novas versoes de imagem e atualiza containers de acordo com uma estrategia definida. Volumes sao armazenados fora do container e incluidos em rotinas de backup. Politicas de rede garantem que containers so possam acessar servicos que realmente precisam.

• Docker Compose: definicao declarativa de stack, gerenciamento de dependencias
• Gerenciamento de volumes: volumes nomeados ou bind mounts para caminhos com backup
• Isolamento de rede: redes bridge dedicadas por stack, exposicao minima
• Atualizacoes automatizadas: Watchtower ou rotinas de atualizacao baseadas em script
• Health checks: restart: unless-stopped, diretiva healthcheck no arquivo Compose
• NGINX como proxy reverso na frente de containers Docker: terminacao SSL, rate limiting

Proxy Reverso NGINX, VPN WireGuard e Configuracao de Rede

O NGINX e o ponto de entrada central para todos os servicos baseados em web na minha infraestrutura. Como proxy reverso, o NGINX termina conexoes TLS (Let's Encrypt via Certbot ou acme.sh), encaminha requisicoes para containers internos e implementa rate limiting, autenticacao (via Authelia) e access logging. Essa centralizacao simplifica consideravelmente o gerenciamento de certificados e as politicas de seguranca.

O WireGuard e minha VPN de escolha para conexoes site-a-site e cenarios road-warrior. Em comparacao com o OpenVPN, o WireGuard oferece configuracao substancialmente mais simples, maior desempenho e menor footprint de codigo. Na minha infraestrutura o WireGuard conecta varios sites Proxmox e fornece acesso remoto seguro a servicos internos sem portas expostas publicamente.

# /etc/nginx/sites-available/app-interno
# Proxy reverso para aplicacao web interna com SSL e autenticacao

# Zona de rate-limiting (20 requisicoes/segundo por IP)
limit_req_zone $binary_remote_addr zone=app_limit:10m rate=20r/s;

server {
    listen 80;
    server_name app.exemplo.com.br;
    # Redirecionar todo HTTP para HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name app.exemplo.com.br;

    # Certificados SSL (Let's Encrypt via certbot)
    ssl_certificate     /etc/letsencrypt/live/app.exemplo.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.exemplo.com.br/privkey.pem;

    # SSL moderno: apenas TLS 1.2 e 1.3
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers   ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    # Cabecalhos de seguranca
    add_header Strict-Transport-Security "max-age=63072000" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options SAMEORIGIN;

    # Aplicar rate limiting
    limit_req zone=app_limit burst=50 nodelay;

    # Endpoint de autenticacao Authelia
    location /authelia {
        internal;
        proxy_pass        http://127.0.0.1:9091/api/verify;
        proxy_pass_request_body off;
        proxy_set_header  Content-Length "";
        proxy_set_header  X-Original-URL $scheme://$http_host$request_uri;
    }

    location / {
        # Verificar autenticacao via Authelia
        auth_request     /authelia;
        auth_request_set $user  $upstream_http_remote_user;

        # Encaminhar requisicao para servico interno (Docker/LXC)
        proxy_pass       http://127.0.0.1:8080;
        proxy_set_header Host            $host;
        proxy_set_header X-Real-IP       $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    # Log de acesso com timestamp e codigo de resposta
    access_log /var/log/nginx/app.exemplo.com.br_access.log combined;
    error_log  /var/log/nginx/app.exemplo.com.br_error.log warn;
}

Esta configuracao NGINX combina terminacao SSL, TLS moderno, rate limiting e autenticacao SSO baseada em Authelia. Todos os servicos internos estao ocultos atras deste proxy reverso; externamente apenas a porta 443 e publica.

WireGuard: Site-a-Site e Road Warrior

As configuracoes WireGuard sao minimais e legiveis. Uma interface tem uma chave privada e um endereco IP na rede VPN; cada peer recebe sua chave publica e os intervalos de IP de destino permitidos. Em uma configuracao site-a-site subredes inteiras sao roteadas; para clientes road-warrior 0.0.0.0/0 e configurado como rede permitida para que todo o trafego flua pelo tunel VPN. A configuracao DNS na interface WireGuard garante que nomes de host internos sejam resolvidos corretamente.

Automacao de Backup com rsync e rclone

A automacao de backup e um dos aspectos mais importantes mas frequentemente negligenciados das operacoes Linux. Muitos sistemas tem scripts de backup que rodam mas cuja integridade nunca foi testada, ou cuja estrategia de rotacao leva a volumes crescentes de dados sem periodos de retencao adequados. Implemento sistemas de backup que rodam confiavelmente, reportam seu status e sao verificados periodicamente.

rsync e a ferramenta de escolha para sincronizacao local e baseada em SSH: incremental, eficiente e universalmente disponivel. rclone estende o rsync para destinos na nuvem: armazenamento compativel com S3, Azure Blob, Backblaze B2, SFTP e dezenas de outros backends sao acessados pela mesma interface CLI. A combinacao de backup rsync local e replicacao offsite via rclone implementa uma estrategia de backup 3-2-1 sem solucoes proprietarias.

O fluxo de backup consiste em tres etapas: rsync faz backup dos dados do servidor fonte para um destino de backup local; rclone replica seletivamente para a nuvem ou local offsite; um processo de monitoramento rastreia codigos de saida e envia alertas em erros ou backups perdidos.

#!/usr/bin/env bash
# Script de backup: rsync local + replicacao offsite rclone
# Estrategia de rotacao: 7 diarios, 4 semanais, 12 mensais
set -euo pipefail

# -- Configuracao -------------------------------------------------------------
FONTE="/srv/dados"               # Diretorio fonte
BASE_BACKUP="/backup"            # Diretorio base de backup local
DESTINO_RCLONE="b2:meu-backup"  # Destino rclone (Backblaze B2 ou S3)
URL_MONITORAMENTO="https://hc-ping.com/XXXX"  # URL de healthcheck (opcional)
LOG="/var/log/backup/backup.log"
DATA=$(date +%Y%m%d)
DDS=$(date +%u)      # 1=Segunda, 7=Domingo
DDS_MES=$(date +%d)  # 01-31

mkdir -p "${BASE_BACKUP}"/{diario,semanal,mensal} "$(dirname "${LOG}")"

log() { echo "$(date '+%Y-%m-%d %H:%M:%S') $*" | tee -a "${LOG}"; }

# -- Notificar monitoramento: backup iniciando --------------------------------
[[ -n "${URL_MONITORAMENTO:-}" ]] && curl -fsS "${URL_MONITORAMENTO}/start" -o /dev/null || true

log "INFO Backup iniciado: ${DATA}"

# -- Diario: rsync com hard links para historico eficiente em espaco ---------
DESTINO_DIARIO="${BASE_BACKUP}/diario/${DATA}"
ULTIMO=$(ls -1d "${BASE_BACKUP}/diario"/20* 2>/dev/null | tail -1 || echo "")

if [[ -n "${ULTIMO}" && "${ULTIMO}" != "${DESTINO_DIARIO}" ]]; then
    # Backup incremental: arquivos inalterados vinculados, nao copiados
    rsync -avz --delete \
        --link-dest="${ULTIMO}" \
        --exclude-from="/etc/backup/exclusoes.list" \
        "${FONTE}/" "${DESTINO_DIARIO}/"
else
    # Primeiro backup ou mesmo dia: copia completa
    rsync -avz --delete \
        --exclude-from="/etc/backup/exclusoes.list" \
        "${FONTE}/" "${DESTINO_DIARIO}/"
fi
log "INFO Backup diario concluido: ${DESTINO_DIARIO}"

# -- Semanal: copia do backup diario todo domingo -----------------------------
if [[ "${DDS}" == "7" ]]; then
    SEMANA=$(date +%Y_S%V)
    cp -al "${DESTINO_DIARIO}" "${BASE_BACKUP}/semanal/${SEMANA}"
    log "INFO Backup semanal criado: ${SEMANA}"
fi

# -- Mensal: copia do backup diario no dia 1 de cada mes ---------------------
if [[ "${DDS_MES}" == "01" ]]; then
    MES=$(date +%Y_%m)
    cp -al "${DESTINO_DIARIO}" "${BASE_BACKUP}/mensal/${MES}"
    log "INFO Backup mensal criado: ${MES}"
fi

# -- Rotacao: remover backups antigos -----------------------------------------
find "${BASE_BACKUP}/diario"   -maxdepth 1 -type d -mtime +7   -exec rm -rf {} +
find "${BASE_BACKUP}/semanal"  -maxdepth 1 -type d -mtime +28  -exec rm -rf {} + 2>/dev/null || true
find "${BASE_BACKUP}/mensal"   -maxdepth 1 -type d -mtime +365 -exec rm -rf {} + 2>/dev/null || true
log "INFO Rotacao concluida"

# -- Replicacao offsite via rclone --------------------------------------------
rclone sync "${BASE_BACKUP}/mensal" "${DESTINO_RCLONE}/mensal" \
    --progress --transfers=4 --checkers=8 \
    --log-file="${LOG}" --log-level=INFO
log "INFO Replicacao offsite concluida"

# -- Notificar monitoramento: backup bem-sucedido -----------------------------
[[ -n "${URL_MONITORAMENTO:-}" ]] && curl -fsS "${URL_MONITORAMENTO}" -o /dev/null || true
log "INFO Backup totalmente bem-sucedido"

Este script implementa uma estrategia de backup 3-2-1 completa: backups diarios com hard links para eficiencia de espaco, backups semanais automaticos aos domingos, backups mensais no dia 1 e replicacao offsite via rclone. Um ping de healthcheck confirma o sucesso; pings ausentes acionam um alerta.

Backup de Configuracao

Junto com os backups de dados, os backups de configuracao sao essenciais: /etc, crontabs, units systemd, configuracoes NGINX e arquivos de configuracao de aplicacao devem ser copiados regularmente e versionados. Git e excelente para versionar arquivos de configuracao; etckeeper automatiza isso para /etc. Combinado com rsync/rclone, a configuracao completa do sistema e tratada como um artefato de backup independente.

Hardening e Seguranca

Um sistema Linux em producao deve ser endurecido. Hardening significa: minimizar a superficie de ataque, bloquear tentativas de brute-force, restringir o acesso de rede a portas necessarias e registrar o acesso ao sistema. As medidas mais importantes sao bem conhecidas e ainda assim frequentemente nao aplicadas de forma consistente na pratica.

Hardening SSH

SSH e o principal caminho de acesso a servidores Linux e portanto o alvo de ataque mais comum. Medidas basicas: desabilitar autenticacao por senha e permitir apenas autenticacao por chave publica; proibir login root via SSH; executar SSH em uma porta nao padrao (reduz a varredura automatizada); usar AllowUsers ou AllowGroups para restringir contas permitidas. O fail2ban monitora tentativas de login SSH e bloqueia IPs apos falhas repetidas.

Firewall com iptables/nftables

Todo servidor acessivel publicamente precisa de uma configuracao de firewall que permita apenas as portas realmente necessarias. iptables e a abordagem classica; nftables e o sucessor mais moderno com sintaxe mais consistente. Para configuracoes simples uso ufw (Uncomplicated Firewall) no Ubuntu; para topologias mais complexas com roteamento baseado em origem ou encaminhamento de porta uso nftables diretamente. A regra fundamental: bloquear tudo, permitir apenas o necessario.

Atualizacoes de Seguranca Automaticas

Sistemas sem patches sao o maior risco de seguranca. unattended-upgrades no Debian/Ubuntu instala patches de seguranca automaticamente e reporta resultados por e-mail. Para atualizacoes de kernel sem reinicializacao, kpatch ou livepatch (Ubuntu) permite patches ao vivo. No minimo, a instalacao automatica de atualizacoes de seguranca deve ser habilitada em todo servidor de producao.

• SSH: somente chave publica, sem login root, AllowUsers, fail2ban ativo
• Firewall: nftables/iptables com default-deny, somente portas necessarias abertas
• unattended-upgrades: patches de seguranca automaticos sem intervencao manual
• Minimizar servicos: somente servicos necessarios ativos
• Permissoes de arquivo: sem arquivos world-writable fora de /tmp
• fail2ban: proteger SSH, NGINX e outros servicos expostos
• Audit logging: auditd para eventos de sistema relevantes para seguranca

Ponte do Linux para SQL Server e Data Warehouse

Uma parcela significativa da minha experiencia em projetos esta precisamente nessa interface: pipelines de processamento baseados em Linux que alimentam bancos de dados SQL Server ou extraem de sistemas DWH. A Microsoft fornece sqlcmd e bcp para Linux ha anos; o Driver ODBC 17/18 para SQL Server roda estavelmente no Debian, Ubuntu e SUSE. Essa disponibilidade permite que pipelines ETL rodem inteiramente no Linux, sem precisar de servidores Windows como camada intermediaria.

Em projetos de logistica e seguros desenvolvi pipelines de carga e descarga baseados em shell rodando no UNIX/AIX/KSH que transferiam dados via Connect:Direct ou FTP para sistemas DWH centrais. Wrappers Perl orquestravam jobs Teradata FastLoad a partir de scripts shell. Essa experiencia com ambientes heterogeneos me torna um contato confiavel para todos os cenarios cross-plataforma.

sqlcmd e bcp no Linux

sqlcmd permite execucao T-SQL interativa e baseada em scripts no SQL Server diretamente do shell Linux. bcp (Bulk Copy Program) exporta e importa grandes conjuntos de dados de forma eficiente. Ambas as ferramentas se integram em scripts Bash, nao requerem ambiente Windows e funcionam com Autenticacao Windows via Kerberos ou Autenticacao SQL Server. Combinadas com o driver ODBC e pyodbc, uma pilha ETL completa pode ser construida inteiramente no Linux.

Orquestracao de Transferencia de Arquivos Connect:Direct

Connect:Direct (Sterling File Gateway / IBM MQ File Transfer) e a solucao padrao para transferencia confiavel de arquivos entre plataformas em grandes ambientes corporativos, particularmente em seguros e logistica. A orquestracao de jobs Connect:Direct a partir de scripts shell — envio de arquivos de processo, monitoramento de status de transferencia, tratamento de erros e logging — e uma parte central de tais ambientes de automacao que conheco de varios projetos.

• sqlcmd/bcp no Linux: execucao T-SQL e importacao/exportacao em massa
• Driver ODBC 17/18 para SQL Server no Debian/Ubuntu/SUSE
• pyodbc: conexao de banco de dados Python ao SQL Server no Linux
• Connect:Direct: envio de arquivo de processo e monitoramento de transferencia via shell
• ETL cross-plataforma: AIX/KSH para SQL Server / Teradata por experiencia direta
• Wrappers Perl para jobs legados (Teradata FastLoad, invocacoes Informatica)

Abordagem e Documentacao Operacional

Iniciar um engajamento de automacao Linux sempre comeca com um inventario: quais scripts ja estao rodando? Onde sao agendados — cron, systemd, manualmente? Qual tratamento de erros existe? Ha logging? Quem monitora os processos? Este inventario revela rapidamente se um sistema e operacionalmente solido ou um estado 'shared-nothing' nao documentado.

Documentacao operacional nao e um passo posterior para mim, mas parte da entrega. Todo processo de automacao recebe uma pagina de runbook com: proposito, frequencia de execucao, dependencias, guia de resolucao de problemas e contato. Esta documentacao e escrita em Markdown, versionada em um repositorio Git e idealmente publicada como site estatico acessivel a todos os interessados.

Gerenciamento de Configuracao

Para infraestrutura que consiste em mais de um servidor, um sistema de gerenciamento de configuracao vale a pena. Ansible e minha primeira escolha: sistema de playbook YAML sem agente que descreve estados de configuracao declarativamente e os aplica de forma idempotente. Playbooks para configuracao NGINX, units systemd, regras fail2ban e gerenciamento de usuarios rodam em toda mudanca de infraestrutura e garantem que todos os servidores compartilhem o mesmo estado desejado.

• Inventario: scripts, agendadores, logging, monitoramento, tratamento de erros
• Priorizacao: tratamento de erros ausente e monitoramento ausente primeiro
• Implementacao: passo a passo, com testes em ambiente nao-producao
• Documentacao: runbooks em Markdown, versionados, acessiveis
• Gerenciamento de configuracao: Ansible para config de servidor reproduzivel
• Transferencia: treinamento de equipe e transferencia de conhecimento como parte do projeto

Na minha propria infraestrutura mantenho uma documentacao operacional central que descreve todos os servicos em execucao, suas configuracoes, dependencias e status de backup. Esta documentacao nao e um artefato estatico — e atualizada a cada mudanca. Trago esta abordagem para projetos de clientes.

Servicos Tipicos de Automacao Linux

Meus servicos de automacao Linux vao desde suporte de curto prazo com um problema especifico de script ate o design e implementacao completa de uma infraestrutura de automacao. Dependendo da fase do projeto e das necessidades assumo areas individuais ou o escopo completo.

• Desenvolvimento e hardening de scripts Bash/KSH (set -euo pipefail, logging, trap)
• Desenvolvimento de units systemd: servicos, timers, cadeias de dependencias
• Automacao Python: watchers de arquivos, gatilhos ETL, extracao de banco de dados
• Proxmox VE: configuracao, gerenciamento de containers LXC, estrategia de backup
• Docker: stacks Compose, automacao de atualizacoes, backup de volumes
• Proxy reverso NGINX: SSL, rate limiting, integracao Authelia SSO
• VPN WireGuard: site-a-site, road warrior, gerenciamento de chaves
• Servicos DNS: Pi-hole, AdGuard Home, Unbound como resolver
• Automacao de backup: rsync, rclone, estrategia 3-2-1, testes de restauracao
• Hardening: SSH, fail2ban, nftables/iptables, unattended-upgrades
• ETL cross-plataforma: sqlcmd/bcp no Linux, pyodbc, Connect:Direct
• Monitoramento: Prometheus/Grafana, Alertmanager, rastreamento de codigo de saida
• Documentacao operacional: runbooks, Markdown, versionamento Git, Ansible

Essa amplitude de servicos me permite acompanhar projetos sem perdas de interface: do planejamento de infraestrutura, passando pelo desenvolvimento de automacao, ate a documentacao operacional, trabalho como unidade, economizando para o cliente a sobrecarga de coordenacao entre varios especialistas.

Essa amplitude e particularmente valiosa em ambientes hibridos: infraestrutura Linux interagindo com sistemas SQL Server ou Azure precisa de alguem que esteja em casa em todos os niveis — do shell ao banco de dados, do container a nuvem.

Projetos de referencia anonimizados selecionados

Perguntas frequentes sobre automacao Linux