Napredne shell skripte: automatizacija deploy-a na Linux terminalu

Article Image

Automatizacija deploy procesa direktno iz terminala — zašto i kada je to bolje

Kada radiš na projektima koji zahtevaju česte isporuke koda, ručni deploy postaje ograničenje: spor, podložan greškama i teško ponovljiv. Automatizacijom deploy procesa shell skriptama dobijaš brz, ponovljiv i auditabilan tok rada koji može da se pokreće lokalno, iz CI/CD okruženja ili preko daljinskog terminala.

U ovom delu ćeš razumeti ključne razloge za automatizaciju, osnovne rizike koje treba izbegavati i šta treba pripremiti pre nego što napišeš prvu skriptu za deploy.

Prednosti automatizovanog deploy-a koje ćeš odmah osetiti

  • Doslednost: iste komande uvek znače isti rezultat, što smanjuje greške prilikom produkcije.
  • Brzina: višestruki koraci se izvršavaju bez potrebe za manuelnim unosom, što smanjuje vreme izdanja.
  • Audit i povratne tačke: logovanje i verzionisanje skripti olakšavaju praćenje promena i vraćanje na prethodnu verziju.
  • Integracija: shell skripte se lako integrišu sa alatima kao što su Git, systemd, cron i CI serveri.

Priprema okolinu i osnovni principi koje moraš znati pre pisanja skripti

Pre nego što počneš da pišeš napredne skripte, važno je da postaviš osnove u okruženju i razumeš nekoliko principa koji će ti omogućiti pouzdanu automatizaciju.

Ključni elementi okruženja

  • SSH ključevi i pristup: obezbedi bezloznički pristup serveru koristeći SSH ključeve, ograniči prava pomoću korisničkih naloga i autorizacije.
  • Kontrola verzija: smeštaj skripti u Git repozitorijum omogućava praćenje izmena i rollback strategije.
  • Prava i permisije fajlova: testiraj izvršnost skripti (chmod +x) i minimiziraj privilegije potrebne za izvršenje.
  • Sigurnosne kopije: uvek imaš fallback — backup baze podataka i fajlova pre pokretanja kritičnih operacija.

Principi pisanja pouzdanih shell skripti

  • Idempotentnost: skripta treba da može da se pokrene više puta bez neželjenih posledica.
  • Robusno rukovanje greškama: koristi set -euo pipefail i logovanje grešaka kako bi otkrio i zaustavio neispravne tokove.
  • Parametri i konfiguracija: odvoji konfiguracione vrednosti (putanje, serveri, korisnici) u promenljive ili fajlove za konfiguraciju.
  • Transparencija i logovanje: beleži korake i izlaze komandi u log fajl radi audita i debugginga.

Sa postavljenim osnovama i jasnim principima pisanja skripti, spreman si da pređeš sa teorije na praksu — u sledećem delu ćemo napisati konkretan deploy skript korak po korak, objasniti svaku liniju i demonstrirati kako testirati i pokrenuti skriptu bezbedno.

Article Image

Primer praktičnog deploy skripta — korak po korak

U nastavku je pojednostavljen, ali praktičan primer deploy skripta koji demonstrira ključne principe: idempotentnost, logovanje, zaključavanje (mutex) i atomicnu zamenu release-a preko simboličkog linka. Ne moraš koristiti baš ovaj precizan kod, ali arhitektura je proverena u mnogim projektima.

#!/usr/bin/env bash
set -euo pipefail
IFS=$'
t'

# Konfiguracija
APP_USER="deploy"
REMOTE="[email protected]"
REMOTE_DIR="/var/www/myapp"
RELEASES_DIR="${REMOTE_DIR}/releases"
CURRENT_LINK="${REMOTE_DIR}/current"
KEEP=5
SSH_KEY="$HOME/.ssh/deploy_id_rsa"
LOG="/var/log/deploy-myapp.log"
LOCK="/tmp/deploy-myapp.lock"

_usage(){ echo "Usage: $0 [--noop]"; exit 2; }

# jednostavan lock
if ! mkdir "${LOCK}" 2>/dev/null; then
  echo "Deploy already running" | tee -a "${LOG}" >&2
  exit 1
fi
trap 'rm -rf "${LOCK}"' EXIT

# generiši release ime
RELEASE="$(date +%Y%m%d%H%M%S)"
TMP_ARCHIVE="/tmp/${RELEASE}.tar.gz"

# build/archive lokalno
tar -czf "${TMP_ARCHIVE}" ./ --exclude .git

# upload i priprema na daljini
scp -i "${SSH_KEY}" "${TMP_ARCHIVE}" "${REMOTE}:/tmp/"
ssh -i "${SSH_KEY}" "${REMOTE}" bash -s > "${LOG}"

Objašnjenje ključnih delova:

  • set -euo pipefail i trap osiguravaju da skripta stane i očisti lock u slučaju greške.
  • Upload se radi preko scp/ssh — za veće projekte preferruj rsync zbog efikasnosti i –delete opcije.
  • Atomicnost se postiže ln -sfn koji menja simbolički link u jednom trenutku, bez prekida rada.
  • Čišćenje starih release-ova (KEEP) omogućava jednostavan rollback i oslobađanje prostora.

Atomicni deploy i rollback strategije

Najjednostavniji, ali izuzetno efikasan pristup za rollback je čuvanje više release-ova i korišćenje simboličkog linka current. Ako deploy nešto pokvari, vraćanje je samo komanda:

  • Prikazavaj release-ove: ls -1dt /var/www/myapp/releases/*
  • Rollback na prethodni: ln -sfn /var/www/myapp/releases/20250301091500 /var/www/myapp/current && systemctl restart myapp.service

Ovo je bezbedno jer promena linka traje tren i sve reference (npr. socket fajlovi) ostaju konzistentne. Dodatno, možeš održavati fajl sa poslednjim poznatim dobrom verzijama ili koristiti git tag koji se pamti u metapodacima release-a.

Testiranje i bezbedno pokretanje u proizvodnji

Pre nego što pustiš skriptu na produkciju, testiraj u nekoliko faza:

  • Statika i lint: pokreni shellcheck i shfmt na skripti; proveri permisije i da li skripta radi sa set -n (syntax check).
  • Dry-run: umesto stvarnog kopiranja koristi rsync –dry-run ili opciju –noop u skripti koja samo loguje komande koje bi se izvršile.
  • End-to-end na stagingu: identičan env kao produkcija, isti systemd servisi i isti servisni korisnik.
  • CI integracija: u CI pipeline-u pokreni build artefakta, statičke testove i simulaciju deploy-a (bez restart-a servisa) pre omogućavanja automatskog deploy-a.

Za dodatnu bezbednost:

  • Ograniči SSH ključ samo na komande koje su potrebne (authorized_keys command=).
  • Pokreni restart servisa kao nesudo korisnik preko sudoers uz minimalna prava.
  • Implementiraj health-check: nakon deploy-a skripta proveri endpoint /health i rollback-uje ako je nedostupan.
Article Image

Dalji koraci i preporuke

Kad uspostaviš pouzdan deploy proces, fokusiraj se na postepeno unapređivanje: dodaj health-checkove koji automatski vrše rollback, integriši obaveštavanje (Slack/email) za neuspešne deploy-e, i razmisli o canary ili blue/green strategijama za minimiziranje rizika. Isto tako, zadrži disciplinu oko testova i pristupa privilegijama — najmanje privilegija za SSH ključeve i jasno odvajanje build/runner okruženja.

Za proveru i poboljšanje kvalitetа shell skripti koristi alat kao što je ShellCheck, i uvedi formatiranje skripti u CI pipeline (shfmt, lint). Na kraju, automatizacija nije cilj sama po sebi — cilj je brz, ponovljiv i bezbedan deploy sa mogućnošću brzog vraćanja u prethodno stanje.

Frequently Asked Questions

Kako da bezbedno testiram rollback pre nego što ga koristim u produkciji?

Postavi istovetno staging okruženje i simuliraj neuspešan deploy (npr. pokreni servis koji namerno vraća grešku). Testiraj rollback komandom ln -sfn na stagingu i proveri integritet podataka i logove servisa. Automatizuj ovaj test u CI da se izvršava periodično.

Šta tačno radi set -euo pipefail i zašto je važan u deploy skripti?

set -e zaustavlja skriptu na prvoj grešci, -u prijavljuje korišćenje nedefinisanih varijabli, -o pipefail čini da greška u bilo kojoj komandi u pipe-u propagira exit kod. Zajedno smanjuju šanse da skripta nastavi u nepredviđenom stanju, što je kritično za bezbedan deploy.

Koliko release-ova treba čuvati i kako odabrati vrednost KEEP?

Vrednost KEEP zavisi od dostupnog prostora i potrebe za rollback-om — često 3–7 je dovoljna. Ako ti treba duži period za inspekciju ili audite, povećaš broj. Takođe razmotri automatsko arhiviranje starih release-ova umesto brisanja ako želiš sačuvati istoriju bez zauzimanja primarnog prostora.

By