Úvod

Záměrem TA ČR je vybudovat a provozovat SISTA jako cloud native systém. Takový systém má být odolný, snadno kontrolovatelný, robustní a nezávislý na konkrétních dodavatelích technologií. Základní architektonické uspořádání SISTA jako množiny spolupracujících služeb vyžaduje kvalitní a aktuální dokumentaci jednotlivých částí.

Tento dokument nastavuje pravidla pro platformu SISTA, na které jednotlivé mikroslužby poběží, aby se měli dodavatelé o co opřít.

Cílem je:

  • Mít na jednom místě popis pravidel platformy SISTA.

  • Ustanovit si základní best practices pro vývoj platformy SISTA.

  • Nastavit pravidla pro monitoring, logging nebo metriky, která jsou dále využita pro alerting.

  • Nastavit bezpečnostní pravidla pro vývoj platformy SISTA.

  • Vytvořit platformu, která umožní snadné nasazování (mikro)služeb do SISTA.

Dokument se do budoucna může (a bude) měnit v závislosti na potřebách dodavatelů a TA ČR.

1. Platforma SISTA

1.1. Poskytované služby Dev týmům

  • GIT repozitáře.

  • GitLab Pipelines - separátní build a deployment služeb.

  • Postgres DB - stačí uvést do konfiguračního souboru deploymentu a databáze se v clusteru inicializuje pomocí platformy.

  • Možnost zobrazit si logy v konzoli Google Cloudu.

  • Možnost zobrazit si monitoring v konzoli Google Cloudu.

  • Možnost vytočit více testovacích clusterů (prosíme s mírou).

  • Máte-li nějaké aditivní požadavky ve prospěch SISTA, neváhejte kontaktovat IDP tým.

  • Nejasnosti lze řešit v rámci SISTA DevOps nebo schůzek ArchaTýmu.

Note Pokud bude potřeba něco navíc, tak je možné domluvit se s platformním týmem prostřednictvím [email protected].

1.2. Internal Developer Platform (IDP)

Platformní tým poskytuje Dev týmům Internal Developer Platform (IDP) zahrnující správu vrstev kompletního provozu technologické platformy včetně CI/CD pipelines.

Internal Developer platform zahrnuje správu:

  • infrastruktury,

  • monitoringu,

  • alertingu,

  • nasazování prostředí, clusterů a služeb,

  • CI/CD pipelines,

  • repozitářů,

  • uživatelů a jejich oprávnění,

  • pravidel a zásad pro psaní dokumentace,

  • pravidel a zásad pro psaní integračních testů,

  • Site Reliability Engineering (dohled, incident response).

Platformní tým připravuje šablony předpisů kontejnerů a poskytuje konzultace Dev týmům při prvotních nasazeních.

Samotná IDP platforma má tyto zásady:

  • zásady před procesy (policies over processes),

  • automatizace před manuálností (automation over manual),

  • sdílení před kopírováním (shared over copy & paste),

  • spokojenost vývojářů (developer experience - DX):

    • snadné pro použití:

      • dva kroky maximálně - konfigurace a aplikace,

    • bezpečnost:

      • idempotentní,

      • samoozdravné (self-healing),

    • možnost přepnout na nižší kontext, pokud je to potřeba,

  • podpora vývojářských týmů:

    • dohled nad kontrolou = ask for forgiveness, not permission.

Note Celou platformu se snažíme koncipovat tak, aby se dodavatelé mohli soustředit na agilní vývoj služeb. Každopádně kooperace mezi Dev a Ops týmy je nezbytná pro pěstování kultury DevOps.

1.3. Repozitáře – GitLab

Ops tým zajistí repozitáře a přístupy do nich pro Dev týmy.

Co služba, to repozitář. Ops tým připraví šablonu jak pro repozitář, tak pro pipeliny.

Repozitář platformy, kterou mohou vyvíjet i Dev týmy.

SISTA konzumuje prostředky a zdroje Google v rámci Google Cloud. S určitou mírou využíváme i managed komponenty Google.

1.4. Messaging

Messaging se řeší pomocí Google Pub/Sub. Služby vysílají (Publisher) informaci na nějakém topicu a jiné služby, které na daném topicu poslouchají, si informaci zpracují po svém (Subscriber).

“Např. služby, které pracují s informací o osobách, poslouchají na daném topicu, a pokud se v rejstříku osob (RO) změní informace o osobě, tak RO vyšle informaci a Subscriber služby si změněnou informaci uloží.”

Pro komunikaci s messaging službou se používá DAPR middleware, který je součástí platformy, viz podrobnosti v HOWTO Platform.

2. Běhová prostředí

2.1. Architektura

Platforma je vytvářena jako Infrastructure as Code (IaC). Je tvořena pomocí třech stavebních kamenů:

  1. Environment - část zajišťující tvorbu jednotlivých projektů v Google Cloudu, včetně databázového stroje,

  2. Cluster - do environmentu se může nasadit více clusterů,

  3. Service - uvnitř clusterů může běžet více services.

Platforma by měla být do budoucna připravena k využití i pro jiné státní agentury a zvažujeme její uvedení do open-source.

2.2. Prostředí

Pro potřeby projektu SISTA udržuje TA ČR v Google Cloud (GC) běhová prostředí TESTING, STAGING a PRODUCTION. Využití kontejnerizace umožňuje, aby se jednotlivé komponenty spouštěné v různých prostředích lišily pouze konfigurací a dostupnými zdroji – takové uspořádání považujeme za optimální:

  • Typ PRODUKČNÍ (PRODUCTION) = produkční, ostré běhové prostředí (SISTA pro koncové uživatele). Existuje pouze jedno.

  • Typ NEPRODUKČNÍ = instancí těchto prostředí může být mnoho, např.:

    • subtyp STAGING = prostředí určené pro integrační testy mezi službami:

      • mělo by obsahovat skutečná data z produkčního systému, podle potřeby anonymizovaná nebo pseudonymizovaná, a to pravidelně aktualizovaná,

    • subtyp TESTING = prostředí určené pro testy nad úrovní jednotkových testů:

      • musí obsahovat pouze testovací data.

  • Ops tým je zodpovědný za přípravu a údržbu všech těchto typů prostředí. Dev týmy jsou spoluzodpovědné za přípravu a údržbu dat a aplikací ve všech typech prostředí.

  • Podle specifických potřeb služby může být přidána další instance neprodukčního prostředí (např. IMPORT pro výpočetně náročnou přípravu dat, která se následně přesunou do PRODUCTION prostředí).

  • DevOps týmy jsou společně zodpovědné za určení podmínek, při jejichž splnění je možné nasazení do každého prostředí. Oba týmy jsou také zodpovědné za kontrolu, že dané podmínky jsou splněny.

2.3. Deployment

  • Adresáře GIT (repozitáře) obsahují definice deploymentů konkrétních služeb. Co soubor, to služba.

  • Definovanou pipeline je možné spustit v prostředí GitLab Pipelines.

  • Pro kontinuální nasazování (CD) se používá nástroj ArgoCD.

  • Detailnější popis souboru deployment.yaml lze nalézt zde.

2.4. CI/CD

  • Platformní tým poskytne Dev týmům ve službě GitLab Pipelines nástroje pro deploy do prostředí GC.

  • Existuje automatické nasazení služeb do clusterů (více zde).

  • Soubor .gitlab-ci.yml bude možný upravit tak, aby se mohly spustit jednotkové testy nasazovaných služeb.

  • Platformní tým zakazuje definovat proměnné deklarující konkrétní verze (např. imagů nebo knihoven) na úrovni grup nebo repozitářů. Tyto věci budou definované v souboru .gitlab-ci.yml (popřípadě v příslušném souboru pro CI/CD).

  • Platformní tým poskytne ukázky souborů deploymentů, tedy předpisy pro nasazení jednotlivých služeb. Environment variables se zapisují právě do tohoto deployment souboru.

  • Platformní tým bude zajišťovat správu a řízení tajemství (secrets).

  • Při definování verzí v CI/CD je zakázáno odkazovat na větve (např. master, devel či jiné branch). Všechny image musí být vždy pevně verzovány konkrétním tagem (s výjimkou testovacích případů).

2.5. Zabezpečení komunikačních kanálů mezi službami

Ověřování komunikace mezi službami primárně zajišťuje DAPR middleware, který postupně nahrazuje původní ověřování pomocí API klíčů a služby Apigov. Autentizace je tak pro volající služby zajištěna automaticky a nevyžaduje manuální řešení přístupových údajů

Pravidla na straně volaného (služba přijímající požadavek):

  • Do koncových bodů (endpointů) je nutné přidat logiku, která ověří, zda požadavek obsahuje hlavičku dapr-api-token. Tuto hodnotu služba porovná s proměnnou prostředí DAPR_APP_API_TOKEN (nebo s proměnnou, na kterou je v deployment.yaml v sekci env namapována). Pokud se hodnoty shodují, je požadavek považován za validní.

  • U stávajících služeb je zatím povolen fallback na původní kontrolu přes API klíč a službu Apigov, avšak u nově vznikajících služeb se tento fallback již nesmí implementovat.

Pravidla na straně volajícího (služba odesílající požadavek):

  • Při volání jiné služby se zachovávají původní HTTP metody, mění se pouze volaná URL adresa.

  • Autentizace je zajištěna automaticky na pozadí. Lze využít kteroukoliv ze tří ekvivalentních variant:

    • Přesměrování na localhost s hlavičkou: Nahrazení cílové URL za http://localhost:3500/…​ a přidání hlavičky dapr-app-id s názvem cílového trsu (např. app.forms).

    • Využití invoke URL: Volání na adresu ve formátu http://localhost:3500/v1.0/invoke/<Cílový trs>/method/…​

    • Zkrácený zápis: Využití adresy ve formátu http://<Cílový trs>@localhost:3500/…​

U řady služeb je již nová kontrola plně implementována. Patří mezi ně: rejstrik, vazbator, idm, workflow, rule-engine, sprava-ukolu, fisto, print-template, asciidoc-renderer, worklogger, smlouvy, experts a seznamy . Při volání těchto služeb neuvádějte API klíč. Pokud nevoláte žádné jiné služby, u kterých by byl starý způsob ověřování stále nutný, neuvádějte API klíč ani ve svém deployment.yaml. Tím jasně indikujete, že jej vaše služba již nepotřebuje .

2.6. Databáze

  • Momentálně podporujeme pouze Postgres DB. Pokud do budoucna vznikne používat nějakou další, tak kontaktujte Ops tým.

  • Každá služba, která potřebuje databázi musí obsahovat v souboru deployment.yaml

    • POSTGRES_USER: $(.POSTGRES_USER)

    • POSTGRES_URL: "jdbc:postgresql://$(.POSTGRES_HOST):$(.POSTGRES_PORT)/$(.POSTGRES_DB)?charSet=UTF-8&prepareThreshold=0"

Komunikace služby a databáze je řešena uvnitř v Google Cloud přes CloudSQLProxy.

3. Doporučení pro Kubernetes

3.1. Infrastruktura a organizace clusteru

Datum a čas

Všechny uzly musí používat NTP synchronizaci a sjednocené časové pásmo, ideálně UTC.

Topologie a uzly

Pracovní uzly by měly být označeny zónami dostupnosti (availability zones) pro správné rozložení zátěže. Omezujícím konstrukcím (jako jsou taints) je lepší se vyhnout, pokud nejsou nezbytné, protože komplikují správu. Pozor na to, že nasazení do více zón automaticky neznamená vyšší spolehlivost a škálování clusteru by mělo probíhat velmi opatrně.

Jmenné prostory (namespaces)

Slouží k izolaci, řízení přístupu a správě kvót. Platí pravidlo, že jeden namespace by měl ideálně patřit aplikacím jednoho vývojového týmu. Komponenty je vhodné rozdělit do samostatných jmenných prostorů, pokud spolu nesouvisejí, mají odlišnou zátěž na zdroje, vyvíjí je různé týmy nebo to vyžaduje bezpečnost.

3.2. Nasazení kontejnerů a správa zdrojů

Neměnné obrazy (immutable images)

Aplikace musí využívat pouze předem sestavené a verzované image kontejnerů. Kontejner za běhu nesmí nic kompilovat ani dynamicky načítat kód. Je silně nedoporučeno používat tag latest; každé vydání by mělo mít jasnou verzi a být stahováno z důvěryhodného repozitáře.

Životní cyklus podu (pod lifetime)

Každý kontejner musí mít implementované sondy: Readiness probe (ověřuje, že je připraven přijímat provoz) a Liveness probe (ověřuje zdravý stav). Pro bezpečné ukončení by měl obsahovat PreStop hook nebo dostatečný časový limit pro dokončení běžících transakcí.

Hardwarové limity (resources)

Každý kontejner musí definovat požadavky (requests) a limity (limits) na CPU a paměť. Poměr limitu k požadavku u CPU by neměl přesáhnout hodnotu 5. U paměti by měly být pro dlouhodobě běžící komponenty obě hodnoty shodné, aby se předešlo restartům a selháním z nedostatku paměti. Pozor na formát – u bajtů nevyužívejte desetinná čísla, ale přesné jednotky (např. místo 1,3G pište 1300M).

3.3. Architektura, komunikace a konfigurace

Stav aplikace a vysoká dostupnost (HA)

Aplikace by měly být primárně bezstavové (stateless). Pokud pracují se stavem, ten musí být uložen mimo samotný pod (databáze, fronta). Služby by měly běžet ve více replikách a v produkci dodržovat pravidlo N+2 (počet replik nutný pro zvládnutí zátěže plus dvě navíc). Sítě mohou kdykoliv vypadnout, a proto se relace musí sdílet napříč replikami.

Komunikace a nezávislost

Veškerá komunikace má využívat Kube DNS a musí počítat s výpadky. Nutností je implementace obnovy spojení (např. exponential backoff) a ochrana proti opakovaným dotazům na jedinou nedostupnou IP adresu v případě více DNS záznamů. Každá komponenta musí být nezávisle nasaditelná s možností rychlého rollbacku.

Pravidla pro konfiguraci

Konfigurační parametry pro daná prostředí musí být uloženy v proměnných prostředí nebo konfiguračních mapách jako verzovaný kód. Do objektu Secret patří pouze skutečná tajemství (hesla, certifikáty), nikoliv např. topologie nebo IP adresy databází.

3.4. Logování a metriky

Logy

Logy z celého clusteru musí téct do nezávislého centrálního zásobníku s uchováním minimálně týden. Preferovaným formátem zpráv je JSON. Je přísně zakázáno logovat osobní údaje a citlivá tajemství! Pro snadné trasování transakcí by zprávy měly obsahovat unikátní transakční ID (traceId). Je nutné správně používat úrovně logů (uživatelská chyba není ERROR) a udržovat celkový objem logů v rozumných mezích.

Metriky

Aplikace by měly poskytovat metriky o svém běhu (např. objemy transakcí, latence, počty chyb), které nezávislý metrický stack zpracovává pro účely alertingu.

3.5. Bezpečnost a ochrana dat

Správa tajemství (secrets)

Do objektu typu Secret patří pouze skutečné přihlašovací údaje, jako jsou hesla a tokeny. Je přísně zakázáno vkládat do Secrets netajné konfigurace, adresy koncových bodů či kompletní připojovací řetězce k databázím (obsahující IP adresy i porty).

Izolace a řízení přístupu

Jmenné prostory (namespaces) slouží také jako bezpečnostní izolace – přístup do jiných jmenných prostorů musí být z bezpečnostních důvodů omezen pro lidské uživatele i pro účty služeb (service accounts). Požadavek na bezpečnostní oddělení je hlavním důvodem k nasazení aplikací do oddělených namespace.

Bezpečnost logování

Je zakázáno logovat přihlašovací údaje nebo jiná tajemství; pokud se tak stane, musí být bezpodmínečně redigována. Dále se nesmí logovat osobní údaje; místo nich aplikace musí využívat interní identifikátory záznamů (ID).

Note Vychází z analýzy společnosti The MAMA AI a dosavadní provozní zkušenosti Ops týmu.

4. Release notes dokumentu

Verze: 1.2.
Datum vydání: 8. 6. 2026.
Autor: Lukáš Kulička, [email protected].
Poznámka k verzi: Revize 06/26 pravidel platformy SISTA.

Detailní popis změn:

  • Revize k 06/26.

  • Zjednodušení a doplnění doporučení pro Kubernetes.

  • Přidána bezpečnost a dapr autentizace.

Závěr

Dokument byl vytvořen pro potřeby TA ČR a jejich dodavatele pro projekt SISTA „Sdílený Informační Systém Technologické Agentury“.

V dokumentu se popisuje platforma vytvořená od IDP týmu a ukazuje se v něm možnosti a pravidla platformy. Pravidla obsahují správu GitLabu, pipelines, deployment a doporučení pro platformu v rámci Kubernetes.

Dokument byl vytvořen s využitím open-source projektů:

Termíny a definice

DevOps meeting

Exekutivní skupina zodpovědná za kontrolu a údržbu strategické a technologické architektury. Rada by měla reprezentovat všechny klíčové subjekty zainteresované v architektuře (stakeholder) a typicky sestává z členů Ops zodpovědných za dohled a údržbu celkové architektury z úhlu pohledu svých zodpovědností a relevantních členů Dev dodavatelských týmů.

Dev tým

Tým vývojářů, inženýrů, testerů a dalších potřebných rolí dodavatele.

IDP

Internal Developer Platforma - lidé ze strany TA ČR vyvíjející platformu SISTA pro vývojáře.

Ops tým

Tým vývojářů, správců, testerů a poučených uživatelů TA ČR.

Platforma SISTA

Platforma pro vývojáře, která umožňuje vývojářům běh a správu jejich vytvořených služeb.

Odkazy a zdroje

Rejstřík

Příloha A: Seznam příloh

Table 1. Internetové zdroje
ID Název přílohy s odkazem repozitář Verze

01

02

03

04

05

06

07

08

09

10