Většina týmů skončí tak, že má zdrojový kód v jednom americkém cloudu, obrazy kontejnerů v druhém a uživatelské účty ve třetím. Každý z nich je samostatná smlouva, samostatný výpadek a samostatná odpověď na otázku „kdo si může přečíst náš kód?“
Celý vývojářský stack provozujeme sami, v EU, a děláme to jako službu. Správa zdrojového kódu, CI/CD, registr obrazů a jednotné přihlášení přicházejí z jednoho místa - z infrastruktury, kterou spravujeme v Německu, ne z přeprodané kapacity hyperscalera.
Z čeho se stack skládá
- GitLab CE na vyhrazeném serveru Hetzner v Norimberku, Debian 12, HTTPS s certifikáty Let's Encrypt obnovovanými automaticky.
- Registr kontejnerů dodávaný s GitLabem, dostupný na portu 5050 téhož stroje, s politikami uchovávání, které nechají žít nasazené obrazy a zbytek promažou.
- GitLab Runner s exekutorem Docker - každá úloha CI běží ve vlastním kontejneru.
- Keycloak jako poskytovatel identity, který federuje uživatele z LDAP, s klienty OIDC pro jednotlivé aplikace.
- Odchozí pošta přes náš vlastní mailový server, aby notifikace z pipeline a e-maily k merge requestům nechodily přes cizího odesílatele.
Žádná z těch součástí není exotická. To je právě ta pointa: je to standardní open source software, provozovaný poctivě, lidmi, kteří zvednou telefon.
Jednotné přihlášení, které zná vaši organizaci
Zajímavé není to, že Keycloak existuje. Zajímavé je, co o přihlašujícím se člověku ta přihláška vlastně ví.
Uživatelé žijí v LDAP. Keycloak je federuje do realmu a skupiny z LDAP mapuje do skupinových claimů v OIDC. GitLab tyhle claimy přebírá standardním providerem openid_connect s PKCE, takže o úrovni přístupu rozhoduje členství ve skupině - kdo je ve skupině administrátorů, je administrátorem v GitLabu, a nikdo k tomu nemusí udržovat druhý seznam, kdo je kdo.
Tentýž realm vydává tokeny i pro všechno ostatní, co provozujete - wiki, přehledové obrazovky, ERP, monitoring. Nástup vývojáře se tím zmenší na jeden záznam v LDAP a jedno členství ve skupině. Odchod se zmenší na jedno smazání, a to zavře všechny dveře naráz. To je skutečný argument pro SSO, a platí jen tehdy, když jeden provozovatel drží adresář i aplikace.
Na registru se pozná provozní disciplína
Registr kontejnerů se zaplní. Týmy, které staví několikrát denně, na to přijdou tvrdě, obvykle ve chvíli, kdy push selže v nejnevhodnější možný moment. Registr proto má politiku promazávání - a ta politika má jeden nedotknutelný předpoklad: promazávání nesmí nikdy smazat obraz, který je právě nasazený.
V praxi to znamená, že počet uchovávaných obrazů musí pokrýt každou odlišnou značku, která běží současně, ne jen několik nejnovějších. U aplikace nasazené jednou je deset až dvacet značek dost. U aplikace, která běží v deseti rozbíhajících se instancích, musí to číslo pokrýt všech deset a k tomu historii. Robustnější varianta označí nasazené obrazy chráněnou značkou a nechá je bez ohledu na počet.
Jedna související drobnost, která lidi stojí víkend: pull secret ve vašem clusteru musí být trvalý deploy token jen pro čtení, ne pomíjivý token z úlohy CI. Ten skončí s úlohou a další stažení obrazu spadne na chybu 401, která vypadá jako výpadek registru a není to výpadek registru.
Od commitu do clusteru
CI postaví obraz, označí ho neměnným SHA commitu a pošle do registru. Nasazovací fáze si vytáhne Helm chart a hodnoty z infrastrukturního repozitáře a povýší release. Aplikační repozitáře si vlastní kopie chartů ani manifestů nenosí.
Je to úmyslné omezení. Git je zdrojem pravdy o tom, co běží; v běžícím produkčním systému se nic nemění ručně. Když si cluster a repozitář odporují, při dalším nasazení vyhrává repozitář - a to je bezpečné pravidlo jen za předpokladu, že mezitím nikdo neopravoval produkci přímo.
Pro koho to je
- Týmy pěti až padesáti vývojářů, které potřebují správu kódu, CI a registr, a nechtějí kvůli tomu spravovat tři samostatné smlouvy na služby.
- Organizace s požadavky na uchování dat v EU - GDPR, NIS2, DORA - kde na otázku „kde je náš zdrojový kód a kdo si ho může vyžádat soudně?“ musí existovat doložitelná odpověď.
- Firmy stavěné na open source, které už provozují Linux, Postgres a Keycloak a chtějí dodavatele, který mluví stejným jazykem.
- Firmy, které opouštějí vývojářský stack u hyperscalera a chtějí migraci odpracovanou, ne jen doporučenou.
Co nepředstíráme
Popsané nasazení běží na jednom uzlu. Je navržené a monitorované pro tým, ne pro podnik s tisícem uživatelů, a vysoce dostupný cluster GitLabu dnes nenabízíme. Pokud se váš cíl doby obnovy měří v minutách, ne v hodinách, řekněte to na začátku a my vám poctivě řekneme, jestli jsme pro vás ten správný dodavatel.
Instance hlídáme zvenčí: sondami dostupnosti, hlídáním blížící se expirace certifikátů TLS, alerty na disk i na frontu. Data Keycloaku zálohujeme do objektového úložiště v EU a každou noc ověřujeme, že záloha opravdu vznikla; GitLab a registr běží na vlastním stroji s denními blokovými snapshoty.
Jak začít
Napište nám, kolik máte vývojářů, co provozujete dnes a co musí během přechodu zůstat funkční. Vrátíme se s plánem migrace a s nabídkou - cena se odvíjí od velikosti týmu a od toho, kolik ze současného prostředí přebíráme.
Napište na info@cybermindnet.eu nebo použijte kontaktní formulář.