Učení DevOps: kde začít a co vynechat

Pokud chceš provozovat servery a dodávat software, uč se v tomhle pořadí: Linux a shell, pak jeden malý server, který dovedeš od prázdného stroje až k fungující, monitorované a zálohované aplikaci, a potom systemd, Nginx, Docker a deploy pipeline - přesně v tomto pořadí, každé nahrazuje něco, co už umíš udělat ručně. Kubernetes, service mesh a multi-cloud přijdou později, pokud vůbec. Většina lidí, kteří u DevOps uvíznou, uvízla proto, že začala od vrcholu toho seznamu, ne od spodku.

Provozujeme hostingovou platformu RE:NODE, na které běží přes 1 200 serverů pro více než 500 klientů. Provoz ukazuje, které dovednosti drží flotilu při životě v noci, a běžné způsoby učení ukazují, které z nich se lidé snaží přeskočit. Tento článek je cesta, kterou doporučujeme každému, kdo začíná od nuly, i s důvody, protože právě důvody ti umožní posoudit další nástroj samostatně.

Pořadí a proč je právě takové#

Zásada je jednoduchá: nikdy neautomatizuj něco, co jsi nedělal ručně. Každý DevOps nástroj je obal kolem ruční práce - spuštění procesu, směrování požadavku, kopírování souborů na server, kontrola, jestli něco běží. Když se naučíš obal jako první, zvládneš tutoriál, ale při první poruše nemáš pod ním nic, o co se opřít.

Každá fáze má sloupec „hotovo, když“ z důvodu. Studijní materiály dobře říkají, co nástroj dělá, a špatně říkají, kdy ho znáš dost na to, abys šel dál. Konkrétní cílová čára brání spěchu i věčnému leštění.

Monitoring a zálohy jsou na konci tabulky jen proto, že potřebují něco, co sledovat, a něco, co chránit. V praxi začínají prvním dnem a k tomu se vrátím níž.

Linux a shell před vším ostatním#

Téměř všechno v tomto oboru běží na Linuxu a téměř každý problém, který budeš ladit, je linuxový problém v převleku. Kontejner, který nenaběhne, je obvykle problém s oprávněními, chybějící soubor nebo obsazený port. Pomalý deploy bývá disk nebo síť. „Náhodný“ pád je často OOM killer v kernelu. Nic z toho neuvidíš, pokud je shell místo, kam chodíš jen vložit příkazy.

S čím by měl být člověk v pohodě, než sáhne na kontejner:

• Pohyb a čtení souborů: cd, ls -la, cat, less, tail -f, grep, find.
• Oprávnění a vlastnictví: co znamená rwx, chmod, chown, proč služba běžící jako www-data nepřečte soubor vlastněný rootem s režimem 600.
• Procesy: ps aux, top nebo htop, kill, co je signál, rozdíl mezi SIGTERM a SIGKILL.
• Disk a paměť: df -h, du -sh, free -h a proč „plný disk“ může znamenat i „došly inody“.
• Základy sítě: ss -tlnp pro zjištění, co poslouchá, curl -v pro to, co požadavek skutečně dělá, dig pro to, na co se překládá jméno.
• Logy: journalctl -u name, /var/log a návyk přečíst posledních 50 řádků, než začneš hádat.

# The five commands to answer before anyone says "it doesn't work"$ systemctl status myapp          # is it running, and what did it last say$ journalctl -u myapp -n 50       # the last 50 lines it logged$ ss -tlnp                        # what is listening, on which port, as which process$ df -h && free -h                # disk and memory, the two boring killers$ curl -v http://127.0.0.1:3000/  # does it answer locally, before blaming DNS

Nejdůležitější dovednost v shellu není pamatovat si přepínače. Je to návyk ptát se stroje, místo aby se hádalo. Začátečníci často změní tři věci najednou, restartují a doufají. Lepší pravidlo zní: jedna změna, jeden restart, přečíst log. Prvních deset minut je to pomalejší a po zbytek kariéry mnohem rychlejší. Delší přehled je v článku Linuxové příkazy pro správce serverů.

Nauč se tolik Bashe, aby šlo napsat dvacetiřádkový skript s proměnnou, if, cyklem a set -euo pipefail na začátku. Nemusíš v Bashi vynikat. Musíš umět číst skripty, které po sobě lidé nechávají na serverech, a těch bude hodně.

Jeden VPS od začátku do konce#

Nejužitečnější cvičení je tohle: pronajmi si jeden malý server a dovez ho z čisté instalace ke skutečné aplikaci, kterou se nebudeš stydět někomu ukázat. Žádný cluster, žádní tři poskytovatelé, jeden stroj. Projít celou cestu jednou tě naučí, jak do sebe díly zapadají, což žádné studium dílů zvlášť nedokáže.

Cesta v pořadí:

1. Přihlas se přes SSH, vytvoř běžného uživatele se sudo a přepni se na přihlašování klíčem. Vypni přihlášení heslem a rootem, až klíč funguje - ne dřív, jinak se zamkneš venku.
2. Zapni firewall, který nejdřív povolí SSH a pak jen porty, které potřebuješ. Na Ubuntu je to ufw allow OpenSSH, potom ufw enable.
3. Zapni automatické bezpečnostní aktualizace a nauč se restartovat stroj bez strachu.
4. Nainstaluj runtime a spusť aplikaci ručně, v popředí, dokud nefunguje.
5. Udělej z ní službu systemd.
6. Dej před ni Nginx s doménou a certifikátem.
7. Přidej zálohu, kontrolu dostupnosti a alert na disk.
8. Zapiš si každý krok, pak server zruš a postav ho znovu podle poznámek.

Krok 8 lidé přeskakují a nejvíc učí. Při prvním přestavění zjistíš změněné a zapomenuté nastavení, balíček nainstalovaný při ladění, soubor upravený v /etc o půlnoci. Ta mezera mezi „co si myslíš, že na serveru je“ a „co na něm skutečně je“ je problém, který řeší správa konfigurace a kontejnery. Zažij ji jednou a pochopíš, proč ty nástroje existují, ne jen jejich syntaxi.

První kroky jsou podrobně v článcích první hodina na novém VDS a SSH klíče a zabezpečení.

Jak cvičit na levném serveru

Moc nepotřebuješ. Stroj s 1-2 GB RAM a jedním či dvěma jádry pro výukové účely pohodlně pojme malou webovou aplikaci, Nginx, databázi a monitorovací agent. Důležitější než velikost je:

• Musí to být skutečný veřejný server. Virtuální stroj na notebooku stačí pro shell, ale skrývá části, které bolí: DNS, certifikáty, firewall otočený do internetu, boty zkoušející SSH hesla pár minut po zveřejnění adresy.
• Musí být na zahození. Ber ho jako něco, co smažeš a postavíš znovu. Pokud se bojíš, že ho rozbiješ, nic se na něm nenaučíš.
• Dej mu doménu. Levná doména namířená na něj záznamem A ti umožní pořádně si vyzkoušet TLS, přesměrování a virtuální hosty, místo abys je obcházel.
• Nastav rozpočtový alert nebo tarif s pevnou cenou. Cloudové účty s fakturací po minutách a bez stropu jsou špatné místo na učení, protože nejdražší chyba je ta, které si nevšimneš.

Rozbíjej ho schválně. Zaplň disk přes fallocate -l a sleduj, co selže první. Zabij aplikaci přes kill -9 a zkontroluj, jestli ji systemd vrátí. Zastav Nginx a podívej se, co řekne prohlížeč. Smaž databázi a obnov ji. Každé z toho je skutečné selhání, které později potkáš, a potkat ho na cvičném stroji je zadarmo.

systemd: část, kterou všichni přeskakují#

Začátečníci často přejdou rovnou od „běží mi to v terminálu“ k „běží to v Dockeru“ a přeskočí vrstvu, která na Linuxu skutečně drží procesy při životě. To je chyba, protože i když skončíš s vším v kontejnerech, samotný container runtime je služba systemd a dovednosti z ladění se přenášejí přímo.

Unit soubor je krátký a napsat ho ručně tě naučí, co znamená „běží to v produkci“: pevný uživatel, pracovní adresář, prostředí, politika restartů a logy, které končí tam, kde je přečteš.

[Unit]Description=My appAfter=network-online.targetWants=network-online.target[Service]User=myappWorkingDirectory=/opt/myappEnvironmentFile=/etc/myapp/envExecStart=/usr/bin/node /opt/myapp/server.jsRestart=on-failureRestartSec=5[Install]WantedBy=multi-user.target

Potom systemctl daemon-reload, systemctl enable --now myapp a journalctl -u myapp -f pro sledování. Pokud chápeš, proč tam je Restart=on-failure, proč aplikace neběží jako root a proč tajné hodnoty žijí v EnvironmentFile s přísnými oprávněními, a ne v samotném unitu, rozumíš produkci víc než mnozí, kdo mají v životopise Kubernetes. Celé zpracování je v článku služby systemd pro tvoje aplikace.

Nginx před vším#

Další vrstva je reverse proxy. Aplikace poslouchá na 127.0.0.1:3000 a Nginx poslouchá na portech 80 a 443, ukončuje TLS, servíruje statické soubory a vše ostatní předává dál. Je to vzor za větší částí webu a když ho poznáš ručně, každý spravovaný load balancer a ingress controller, na který narazíš později, bude zřejmý.

server {    listen 80;    server_name app.example.com;    location / {        proxy_pass http://127.0.0.1:3000;        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 $scheme;    }}

Získej certifikát přes Certbot, ověř, že se obnovuje přes certbot renew --dry-run, a před každým reloadem spusť nginx -t. Stojí za to pochopit, a ne jen kopírovat: proč má aplikace poslouchat na localhostu, a ne na 0.0.0.0, k čemu jsou forwardované hlavičky a proč logy aplikace ukazují 127.0.0.1 u každého návštěvníka, dokud jí neřekneš, aby proxy věřila. Průvodce reverse proxy v Nginxu jde dál, včetně WebSocketů a timeoutů.

Docker, až víš, co nahrazuje#

U Dockeru je nejvíc zmatku a téměř celý pochází z toho, že se učí příliš brzy. Pokud ti už aplikace běží jako služba systemd za Nginxem, je Docker snadné zařadit: image je zabalená verze souborů a runtime, které sis instaloval ručně, kontejner je proces, který spouštěl systemd, volume je datový adresář, na jehož zálohu bylo třeba myslet, a publikovaný port je řádek listen, kterému už rozumíš.

Co si má začátečník z Dockeru v této fázi odnést:

• Napsat Dockerfile pro vlastní aplikaci, ne jen stahovat cizí image.
• Rozumět vrstvám natolik, aby soubor seřadil tak, že se závislosti cachují.
• Vědět, že souborový systém kontejneru se zahodí a vše důležité žije ve volume.
• Používat Docker Compose ke společnému spuštění aplikace a její databáze, s pojmenovaným volume pro data.
• Publikovat porty záměrně a vědět, že porty publikované Dockerem mohou obejít pravidla ufw na stejném hostiteli, protože Docker zapisuje vlastní pravidla iptables.

services:  app:    build: .    restart: unless-stopped    env_file: .env    ports:      - "127.0.0.1:3000:3000"    depends_on:      - db  db:    image: postgres:16    restart: unless-stopped    environment:      POSTGRES_PASSWORD_FILE: /run/secrets/db_password    volumes:      - dbdata:/var/lib/postgresql/data    secrets:      - db_passwordvolumes:  dbdata:secrets:  db_password:    file: ./db_password.txt

Všimni si 127.0.0.1: před publikovaným portem. Bez něj je aplikace dostupná přímo z internetu, mimo Nginx i mimo firewall, o kterém se předpokládá, že tě chrání. Tenhle jediný detail dobře ukáže, jestli se někdo Docker naučil, nebo ho opsal. Více v článcích Docker na VDS a Docker Compose pro malé stacky.

CI/CD: automatizuj to, co už děláš ručně#

V tomhle bodě už proběhlo několik ručních nasazení - stáhnout kód, nainstalovat závislosti, build, restart služby. Ten ruční postup je tvoje pipeline. CI/CD je jeho zapsání do souboru, aby ho stroj spouštěl pokaždé stejně, s testy vpředu, aby rozbitý commit skončil dřív, než se dostane na server.

Začni nejmenší poctivou pipeline: spusť testy při každém push a nasaď hlavní větev, když projdou. GitHub Actions jsou rozumné místo k učení, protože bezplatný limit to pohodlně pokryje a syntaxi najdeš všude.

name: test-and-deployon:  push:    branches: [main]jobs:  test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: actions/setup-node@v4        with:          node-version: 22      - run: npm ci      - run: npm test  deploy:    needs: test    runs-on: ubuntu-latest    steps:      - name: Deploy over SSH        run: |          echo "${{ secrets.DEPLOY_KEY }}" > key && chmod 600 key          ssh -i key -o StrictHostKeyChecking=accept-new \            deploy@${{ secrets.HOST }} 'cd /opt/myapp && ./deploy.sh'

Deploy job jen volá deploy.sh, který leží na serveru - stejný skript, jaký se jinak spouští ručně. Je to lepší než vkládat celý deploy do workflow souboru, protože když se pipeline rozbije, můžeš se přihlásit přes SSH a skript spustit sám, a zjistit, co se děje. Deploy klíči dej vlastního uživatele s přístupem do toho jednoho adresáře a k ničemu dalšímu.

Dvě věci stojí za to vyžadovat brzy. První: deploy musí jít opakovat - dvojí spuštění za sebou má být neškodné. Druhá: musí existovat cesta zpět: ponech předchozí release nebo předchozí tag image, aby rollback byl jeden příkaz, ne archeologický projekt. V RE:NODE orchestrace stahuje průměrný deploy pod pět minut, a rychlost je méně důležitá než to, že každý krok je pokaždé stejný - právě to dělá časté nasazování bezpečným.

Monitoring a zálohy patří do prvního deploye#

Tohle je nepříjemná část. Většina studijních cest bere monitoring a zálohy jako pokročilá témata, která se přidají „později“. Později obvykle znamená poté, co se poprvé něco ztratí. Bereme je jako součást prvního nasazení, protože služba bez nich je demo, ne služba.

Minimum je malé:

Záloha, kterou nikdo neobnovil, je hypotéza. Test je jednoduchý: vezmi databázový dump z minulé noci, obnov ho na čistém stroji a spusť aplikaci nad ním. Pokud to z poznámek nezvládneš, zálohy zatím nemáš. Řekněme, že se ve 3:00 ráno zaplní disk nodu - užitečné otázky jsou, jestli se alert dostal k člověku dřív, než se zaplnil, a jestli data z doby před zaplněním existují někde, co není ten disk.

Monitoring má opačné selhání. Začátečníci často nainstalují dashboard s dvěma sty grafů a bez alertů, což je dekorace. Začni třemi nebo čtyřmi alerty, z nichž každý znamená „někdo by měl hned něco udělat“, a další přidávej, až když ti incident ukáže mezeru. Pravidlo, které stojí za to dodržovat, zní: alert, na který nikdo nereaguje, se maže, ne tlumí. Viz monitoring, který ti něco řekne a zálohy, které opravdu fungují.

Co na začátku vynechat#

Vynechávat je dovednost. V oboru je víc nástrojů, než se může naučit kdokoli, a většina řeší problémy, které zatím nemáš. Tohle je lepší nechat být, dokud základy nezačnou být nudné:

Kubernetes si zaslouží přímé slovo, protože je to věc, kterou začátečníci chtějí začínat nejčastěji. Je to dobrý nástroj pro plánování kontejnerů na mnoha strojích. Ale každý jeho pojem - pody, services, ingress, persistent volumes, sondy, secrets - je abstrakce nad něčím z dřívějších fází: procesem, portem, reverse proxy, diskem, kontrolou zdraví, souborem s prostředím. Když se Kubernetes učíš jako první, naučíš se abstrakce bez věcí, které abstrahují, a ladění se stane hádáním. Když ho přidáš po jednom VPS, Dockeru a Nginxu, většina z něj se čte jako „aha, to je ta věc, kterou už znám, jen deklarovaná v YAML“.

Netvrdíme, že Kubernetes je špatný nebo že ho nikdy nebudeš potřebovat. Tvrdíme, že pro jednu aplikaci na jednom nebo dvou serverech je to velké množství mašinérie, která tě chrání před problémy, které nemáš, a že učit se ho jako první zpomaluje.

Mylné představy, které začátečníci často přinášejí#

Tyto vzorce jsou dost běžné na to, aby se řešily hned na začátku, a nejsou to příběhy o nikom konkrétním.

• „DevOps je sada nástrojů.“ Je to způsob práce: lidé, kdo píšou software, zodpovídají i za to, jak běží, a cokoli, co se dělá dvakrát, se automatizuje. Nástroje se mění každých pár let. Návyky ne.
• „Když to funguje na mém stroji, chyba je na serveru.“ Rozdíl bývá v konfiguraci, verzích, proměnných prostředí nebo cestách k souborům. Najít ten rozdíl je ta práce.
• „Kontejnery jsou ve výchozím stavu bezpečné.“ Kontejner běžící jako root, s publikovaným portem a připojeným adresářem hostitele není izolovaný žádným způsobem, na kterém záleží. Kontejnery jsou především balení.
• „Více nástrojů znamená profesionálnější.“ Nejlepší sestavy jsou nudné: málo pohyblivých částí, každá pochopená. Každý přidaný nástroj je něco k aktualizaci, monitorování a ladění.
• „Na vlastním serveru je root v pořádku.“ Je to v pořádku, dokud zranitelná aplikace běžící jako root nepředá útočníkovi celý stroj. Oddělení uživatelé nestojí nic.
• „Zálohy dělá poskytovatel.“ Někdy. Zjisti přesně, co se zálohuje, kde se to ukládá a jak funguje obnova, než ji budeš potřebovat.
• „Musím si pamatovat příkazy.“ Musíš vědět, co je možné a kde hledat. Číst man stránky a logy je ta dovednost. Paměť přijde s používáním.

Nejdražší mylná představa je ta nejtišší: že porozumění přichází ze sledování. Kurzy, videa a tutoriály jsou užitečné, ale nic z tohoto nezůstane, dokud skutečný server nerozbiješ a sám neopravíš. Poměr, o který stojí za to usilovat, je mnohem víc času v terminálu než před slidy.

Co o pořadí ukazuje provoz hostingové platformy#

Provoz RE:NODE znamená automatizované zřizování, škálování a obnovu napříč desítkami nodů a více než 30 službami, s RBAC, monitoringem, automatizací záloh a reakcí na incidenty navrch. Nic z toho nezačalo jako sofistikovaný nástroj. Začalo jako ruční kroky, jimž se rozumělo, ze kterých se staly skripty, ze skriptů služby a ze služeb orchestrace. Každá vrstva automatizace byla bezpečná k postavení, protože vrstva pod ní už byla pochopená.

To je vlastně celý argument tohoto článku. Pořadí není náhodné. Každá fáze mění tu předchozí v něco, nad čím už nemusíš přemýšlet, a nad něčím přestat přemýšlet je bezpečné jen tehdy, po jednom pečlivém promyšlení. Lidé, kteří začnou nahoře, musí při poruše pracovat směrem dolů, v nejhorší možnou chvíli. Lidé, kteří začnou dole, postupují nahoru vlastním tempem.

AI coding agenti tohle ještě zesílili, ne zeslabili. Agent ochotně napíše Dockerfile, unit soubor nebo pipeline během pár vteřin. Jestli je ten soubor správný, bezpečný a vhodný pro tvůj server, je stále úsudek, který zvládne jen ten, kdo rozumí vrstvám. Dovednost, která zlevňuje, je psaní konfigurace. Dovednost, která zdražuje, je její čtení.

FAQ#

Jak dlouho trvá naučit se základy DevOps?

Záleží, kolik času strávíš v terminálu, a ne nad čtením. Projít výše uvedené fáze na skutečném serveru - včetně přestavby z poznámek a obnovy zálohy - jsou měsíce vytrvalého cvičení, ne týdny. Jistota v Linuxu je fáze, která trvá nejdéle, a každá hodina za to stojí.

Musím umět programovat, než se začnu učit DevOps?

Potřebuješ tolik, aby šlo číst kód a psát malé skripty: Bash pro lepení příkazů a jeden univerzální jazyk, třeba Python, na cokoli delšího. Musíš také rozumět tomu, jak jsou aplikace, které nasazuješ, postavené a nakonfigurované, protože většina problémů s nasazením leží na rozhraní mezi aplikací a serverem.

Mám se učit nejdřív AWS, Azure nebo Google Cloud?

Žádný z nich nejdřív. Uč se na jednom obyčejném linuxovém serveru, kde není nic schované za konzolí. Cloudové platformy přejmenovávají a obalují stejné stavební bloky - stroje, disky, sítě, firewally, load balancery - a mnohem snáz se učí, když víš, co ty bloky jsou. Cloud si vyber později podle práce, kterou chceš dělat.

Je důležitější naučit se Docker, nebo Kubernetes?

Docker, s velkým náskokem, a hodně před Kubernetes. Téměř každé moderní nasazení někde používá image kontejnerů a Kubernetes nelze pořádně používat bez pochopení image, volumes a sítí. Mnoho skutečných systémů běží spokojeně na Docker Compose na jednom serveru a nikdy nepotřebuje víc.

Jde cvičit DevOps bez placení za server?

Shell, Docker a skriptování se dají zdarma učit v lokálním virtuálním stroji. Co lokálně nevyzkoušíš, je veřejný internet: DNS, certifikáty, firewall vystavený skutečnému provozu a neustálé pozadí pokusů o přihlášení. Malý placený server se vyplatí, jakmile dojdeš k fázi od začátku do konce.