Pilvi, Docker ja DevOps — nopea ja luotettava julkaisu
Konteitamme kaikki sovellukset Dockerilla, orkestroimme ne Docker Composella (tai Kubernetesilla enterprise-projekteissa), määritämme Caddyn käänteiseksi välityspalvelimeksi automaattisella SSL:llä ja automatisoimme koko julkaisusyklin GitHub Actionsilla — commitista tuotantoon automaattisesti.
Konttien käyttö Dockerilla ja Docker Composella
Jokaisella palvelulla on oma monivaiheinen (multi-stage) Dockerfile: build-vaihe, joka asentaa riippuvuudet ja kääntää koodin, sekä minimaalinen lopullinen vaihe (distroless tai alpine), joka sisältää vain tarvittavat artefaktit. Tyypillinen Next.js-image jää alle 150 Mt:n, FastAPI-image alle 80 Mt:n. Imaget rakennetaan uudelleen jokaisen mergen yhteydessä main-haaraan ja merkitään semanttisesti (`v1.2.3` + `latest`).
Docker Compose määrittelee koko pinon: frontend, API, tietokanta, Redis, worker. Arkaluonteiset muuttujat (tietokannan salasana, API-avaimet, Stripe-salaisuus) ovat `.env`-tiedostossa, joka on suljettu pois gitistä — niitä ei koskaan kovakoodata imageen. Composen health checkit varmistavat, että riippuvuudet ovat valmiina ennen käynnistystä (tietokanta valmis → API käynnistyy → frontend käynnistyy).
- Build-välimuisti `--mount=type=cache`-asetuksella riippuvuuksien asennukseen
- Optimoitu kerrosjärjestys: vakaat riippuvuudet → lähdekoodi
- Salaisuuksien hallinta Docker secretsillä tai HashiCorp Vaultilla enterprise-projekteissa
- `restart: unless-stopped` + `docker compose up --no-deps` atomiseen julkaisuun
Caddy — moderni käänteinen välityspalvelin automaattisella SSL:llä
Caddy 2.8 hoitaa SSL/TLS:n automaattisesti ACME:n kautta (Let's Encrypt tai ZeroSSL) — ei vanhentuneita sertifikaatteja, ei manuaalista konfigurointia. HTTP/2 ja HTTP/3 (QUIC) ovat oletuksena käytössä. Tietoturvaotsikot (HSTS, X-Frame-Options, CSP) asetetaan globaalisti uudelleenkäytettävillä snippeteillä. Deklaratiivinen Caddyfile-konfiguraatio on vertailtavissa (diffable) ja versioitu gitissä.
Nopeusrajoitus (rate limiting), gzip/brotli-pakkaus ja jäsennelty JSON-lokitus otetaan käyttöön Caddyn natiiveilla direktiiveillä — ilman nginx-moduuleja tai monimutkaista Apache-konfigurointia. Pääsy arkaluonteisiin reitteihin (`/admin`, `.env`, `.git`) palauttaa 444 (ei vastausta), mikä on määritetty globaaliksi tietoturvasnippetiksi.
- Vain TLS 1.3 nykyaikaisilla salausmenetelmillä (cipher suites)
- On-demand TLS monivuokralaisille (multi-tenant) SaaS-ratkaisuille dynaamisilla aliverkkotunnuksilla
- Katkoton uudelleenlataus — `caddy reload` ei katkaise aktiivisia yhteyksiä
- Caddy-lokitus → Loki → Grafana — liikenneanalyysi ja poikkeamahälytykset
GitHub Actions CI/CD ja monitorointi
CI-putki ajetaan jokaisella PR:llä: lint, tyyppitarkistus, yksikkötestit, Docker-imagen build, haavoittuvuusskannaus (Trivy). Jos kaikki läpäistään, image työnnetään registryyn ja julkaisu staging-ympäristöön tapahtuu automaattisesti. Merge mainiin = automaattinen julkaisu tuotantoon julkaisun jälkeisellä healthcheckillä. Automaattinen palautus, jos healthcheck epäonnistuu 60 sekunnissa.
Monitorointi Grafanalla + Prometheuksella sovellusmetriikoille (viive, virheprosentti, jonon koko) ja Lokilla lokien aggregointiin. Hälytykset on määritetty Slackiin/sähköpostiin: virheprosentti >1 %, P95-viive >500 ms, levy >85 %. Ulkoinen käytettävyysseuranta Better Uptimella — julkinen SLA-kojelauta saatavilla pyynnöstä.
- Trivy-haavoittuvuusskannaus imageille — esto Critical-tason CVE:illä
- Dependabot + auto-merge patch-päivityksille (vihreä CI vaaditaan)
- Tietokannan automaattinen varmuuskopiointi S3-yhteensopivaan tallennustilaan (öisin, säilytys 30 päivää)
Edut ja rajoitukset
Edut
- Julkaisu käynnistää uuden version vanhan rinnalle, ja jos healthcheck epäonnistuu, palataan automaattisesti edelliseen.
- Automaattinen SSL/TLS Caddyn kautta — ei manuaalisesti vanhentuneita sertifikaatteja.
- Toistettava ympäristö: sama Docker-image kehityksessä, stagingissa ja tuotannossa.
- Monitorointi ja hälytykset (Grafana, Loki) virheprosentille, viiveelle ja lokeille.
Rajoitukset
- Docker Compose ei skaalaudu kuten Kubernetes monisolmuiseen enterprise-käyttöön.
- Alkuperäinen CI/CD-käyttöönotto vaatii aikaa ja DevOps-osaamista.
- Imaget ja lokit kuluttavat levytilaa — tarvitsevat säännöllistä siivousta.
- Täysi monitorointi (Prometheus + Grafana) lisää ylläpidettäviä palveluita.
Lyhyt yhteenveto
Docker + Caddy + GitHub Actions on ihanteellinen yhdistelmä luotettavaan julkaisuun VPS-palvelimella tai muutamalla solmulla. Kymmenien solmujen ja aggressiivisen automaattisen skaalauksen tarpeisiin siirrytään Kubernetesiin.
Tekniset tiedot
| Ominaisuus | Raja / kynnys | Tyypillinen käyttö | |
|---|---|---|---|
| Orkestrointi | Docker Compose, koko pino | Yksi solmu; monisolmuinen vaatii Swarmin/K8s:n | VPS, pienet ja keskisuuret projektit |
| Käänteinen välityspalvelin | Caddy 2.8, HTTP/3, automaattinen SSL | Hyvin monimutkaiset säännöt vaativat laajan konfiguraation | Monta verkkotunnusta, monivuokralaisuus |
| CI/CD | GitHub Actions, automaattinen julkaisu | CI-minuutit maksullisia ilmaistason jälkeen | Automaattinen commitista tuotantoon |
| Tyypillinen kustannus | VPS alkaen ~5 €/kk | Monitorointi + varmuuskopiointi lisäävät kustannuksia | Yhdestä sivustosta usean brändin kokonaisuuteen |
Docker Compose vs Kubernetes
| Kriteeri | Docker Compose | Kubernetes |
|---|---|---|
| Käyttöönoton monimutkaisuus | Pieni | Suuri |
| Monisolmuinen skaalaus / automaattinen skaalaus | Rajoitettu (yksi solmu) | Erinomainen |
| Soveltuu | VPS, pienet ja keskisuuret projektit | Suuret laivastot, enterprise |
Usein kysytyt kysymykset
Miksi Caddy eikä Nginx?
Caddy hoitaa SSL/TLS:n automaattisesti ACME:n kautta, ottaa HTTP/2:n ja HTTP/3:n käyttöön oletuksena ja sillä on lyhyt deklaratiivinen konfiguraatio. Nginx vaatii certbotin ja enemmän manuaalista konfigurointia samaan lopputulokseen.
Tarvitsenko Kubernetesin?
En useimmille sivustoille. Docker Compose VPS-palvelimella hoitaa yhden sivuston tai muutaman palvelun luotettavasti. Kubernetes tulee hyödylliseksi vasta kymmenien solmujen ja aggressiivisen automaattisen skaalauksen kanssa.
Miten julkaisu toimii?
GitHub Actions rakentaa uuden imagen, käynnistää sen vanhan rinnalle, ajaa healthcheckin ja vaihtaa sitten liikenteen. Jos healthcheck epäonnistuu 60 sekunnissa, edelliseen versioon palataan automaattisesti.
Mitä monitorointia suosittelette?
Grafana + Prometheus metriikoille (viive, virheprosentti) ja Loki aggregoiduille lokeille, hälytyksin Slackiin/sähköpostiin. Ulkoiseen käytettävyysseurantaan lisäämme erillisen palvelun, kuten Better Uptimen.