Vlákno názorů k článku
JetBrains YouTrack ukončil instalaci pomocí ZIP a přechází výhradně do kontejneru
od armg - asi je to serverová část, ok, ale i...
-
Mozno to je skor o tom, ze pri "zip" instalacii sa castokrat robi instalacia "rucne"... Takto je toto pouzitie deprecated, aby sa provisioning automatizoval, lebo tam to cele smeruje... Aby clovek neskoncil ako Slovensky Kataster, ked daco klakne...
Proste si predstavte, ze Vam fyzicky server zmizne (kradez, ransomware, poziar, cokolvek). Ako by ste riesili naradu? Ak je to cokolvek ine, ako 20 minutova praca admina, tak to je zle a oni to nechcu podporovat...
PS: Ano, saltstack, pupet, chef a podobne sa uz malo pouzivaju. Moderne je nahodit aspon openshift, pripadne kubernates... Je to sialene vela novej prace, ale tam seruje svet :/... A pre "chudobnejsie" firmy neostava nic ine, len nahodit cisty server, spravit "apk add git docker" a nasledne spravit jeden git checkout a nasledne docker compose up... A uz bezi server s povodnymi sluzbami, aj keby vyhorel...
PS: Ale tiez nechapem to nutenie. Jedno zipko navyse nemoze byt problem v pipeline... Akurat ten navod na instalaciu by sa mi nechcelo urdrzovat. Tam by som dal "vid docker build".
-
IMHO to je otázka nákladů na údržbu a testování. Dokud nabízejí ZIP oficiálně, nesmějí to rozbít, jinak budou na podpoře řešit související tickety. A když dělají změny, musejí je dělat při obojí. Pokud ZIP prakticky nikdo nepoužívá, chápu, že se jim to nechce udržovat.
Jo, pokud si někdo ten ZIP extrahuje z Dockeru a používá to, nejspíš nebudou mít nic proti. Pokud si ovšem související problémy vyřeší sám.
-
zip archiv není automatizovatelný? Proč mi to nikdo neřekl dříve...
Pokud chceš mít bezpečnost infrastrukturu, tak nestačí "stáhnout bezpečný docker image od JetBrains", ale musíš vědět, co tam máš, jaké nastavení tam je, jak to aktualizovat atd. Ideálně nechceš řešit nějaké výjimky, ale chceš mít infrastrukturu jednotnou.
Nějaký blackbox od JetBrains (mimochodem ani dnes nemají ten image v nejlepší kvalitě) je jen usnadnění jejich vývoje a testování, prostě když to funguje u nich, mohou to distribuovat, nemusí řešit nějakou kompatibilitu s různými knihovnami, nemusí dokumentovat jaké závislosti to potřebuje a testovat jejich kombinace.
-
nargStříbrný podporovatel
> Ideálně nechceš řešit nějaké výjimky, ale chceš mít infrastrukturu jednotnou.
To je fakt. Já třeba chci mít všude docker, resp. k8s protože to řeší spoustu problémů. Stejně jako valná část světa.> je jen usnadnění jejich vývoje a testování,
Ano, je to zefektivnění vývoje ať nemusí řešit kompatibilitu s různými distros který nejsou schopni držet aktuální verze software.> ale musíš vědět, co tam máš,
ne, nutně nemusím. O tom images jsou.> jaké nastavení tam je,
takové jaké si tam dáte> jak to aktualizovat
já nevím, deploynout nový image? Podívat se do nějakých upgrade notes jestli jsou třeba manuální kroky? -
ale také k8s spoutu nových problémů přináší, z pohledu bezpečnosti toho je celá plejáda problémů.
Efektivní vývoj ale znamená, že budou striktně svázaný s jedinou distribucí, na které to budou vyvýjet a testovat. To sníží přenositelnost a zvýší výskyt bugů při upgradu. Vývoj přes pokus omyl dokud mi to nefunguje je velmi rizikový ač v počátku to vypadá jako ušetření nákladů.
Nj. ale jak pak chceš řešit zranitelnosti? Audit? Provozní chování? Prostě nechceš mít v infrastruktuře blackbox, který netušíš co dělá a jeho autor za to nenese žádnou odpovědnost (viz podmínky JetBrains). Opravdu považuješ tohle za super přístup?
Když ten docker je vytvořený někým třetím, tak těžko může mít nastavení takové jaké si tam dám. Abych něco mohl změnit, musím vědět, co měním a kde a jsme u předchozího bodu.
Jakmile se objeví zneužívaná zranitelnost, máš prakticky hodiny max. dny na její vyřešení nebo vypnutí služby. Např. u teamcity-agent trvalo 3 týdny než JebBrains na přelomu roku vydal bezpečnostní aktualizaci. Ne, prakticky to potřebuješ mnohem, mohem rychleji.
-
nargStříbrný podporovatel
>Když ten docker je vytvořený někým třetím, tak těžko může mít nastavení takové jaké si tam dám. Abych něco mohl změnit, musím vědět, co měním a kde a jsme u předchozího bodu.
Zajímalo by mě co přesně chcete měnit. Tj. dodavatel/výrobce Vám dodá software a konfigurační optiony (ať file namoutovaný dovnitř dockeru nebo env variables)... Co dál potřebujete měnit?>Nj. ale jak pak chceš řešit zranitelnosti?
V kontejnerech by mělo být nezbytné minumum co aplikace vyžaduje pro běh. Tudíž tak nějak předpokládám že buďto software:
- závisí na knihovně co má exploit (a pak je to teda smůla -- musí se čekat na výrobce)
- nemá tam ta knihovna co dělatPřípadně můžete třeba na tom kontejneru ještě přidat vstvu a pustit apt-get update && apt-get upgrade -y (kupř.) ... Ale riskujete že Vám to nebude fungovat... Nicméně narozdíl od "distro" (zip) přístupu můžete vesele deploynout předchoz nezprzněný a fungující kontejner.
>Prostě nechceš mít v infrastruktuře blackbox, který netušíš co dělá
Ale já to tuším. Pustí javu a youtrack? To už můžete jít rovnou do extrémů, youtrack je sám o sobě blackbox. Jestlipak znáte všechny jeho závislosti a potencionální díry? -
Dodavatel nedodá jen SW, ale dodá celou linuxu distribuci s tím SW. A co bych potřeboval měnit? Třeba bach rád věděl, jaké ca má jako důvěryhodné, jaké používá nameservery, s jakými vnějšími adresami potřebuje komunikovat, chtěl bych propagovat selinux policies.
Ano, mělo by tam být nezbytné minimum, ale jaksitaksi JetBrains do svých dává celé ubuntu s celou řadu souborů s suid bitem. Řešit u toho věrohodnost, tj. rozlišovat ty, které tam jsou přepsané od těch, které jsou z ubuntu je trochu práce navíc.
S JetBrains docker obrazy je dlouhodobě problém, proto se používá zip, teď to tím moc nevylepší.
-
nargStříbrný podporovatel
NS
Nameservery používá jaké mu nastavíte. Tohle si managuje docker/k8s.CA
V životě jsem nepotřeboval prolézat CA. K čemu taky? V tom kontejneru by měl běžet jen daný software a autor software může třeba taky zvolit že bude důvěřovat všem CA nezávisle na nastavení systému. Nebo může mít dalších N storages důvěryhodných CA. Ale pokud to potřebujete hackovat, můžete si udělat další vrstvu kde smažete systémové CA a naimportujete si tam svoje. A pokud to potřebujete jen rozšířit o další CA, prostě další vrstva nad daným imageSELinux
Pokud máte potřebu v dockeru používat selinux, asi jste zcela nepochopil jak docker funguje. Je to vlastní container s vlastní IP adresou a (ideálně) jedním procesem bez přístupu (by default) kamkoli. Čeho byste tedy selinuxem chtěl docílit? Nějak si to neumím představits jakými vnějšími adresami potřebuje komunikovat
Firewall na hostu? NetworkPolicies v k8s? -
nj. ale historicky některé aplikace v kontejneru od JetBrains měli nastavené přímo v sobě konkrétní NS a nebrali hodnotu z resolv.conf od dockeru.
Chápu, vlastně ti je jedno, jak se ten kontejner chová, co dělá, hlavně že funguje a víc řešit nechceš. Bohužel ale někdo občas má trochu víc odpovědnost za provoz a potřebuje to mít pod kontrolou. Distribuovat aplikaci jen jako docker image (a nikoliv třeba jako helm chart pro kubernetes) s nedokumentovaným obsahem a změnami, s plnohodnotou linux distribucí je tak trochu nepěkná věc.
-
KateStříbrný podporovatel
> Nj. ale jak pak chceš řešit zranitelnosti? Audit? Provozní chování?
Nástrojů pro hlídání závislostí v kontejnerech je hafo, zas až takový blackbox to není. Navíc, v čem je ten rozdíl oproti zipu? Ten aby fungoval univerzálně, musí mít taky všechny závislosti přibalené k sobě. Narozdíl od OCI kontejneru ale neumí vrstvy pro snadné oddělení update základu a samotné aplikace, a musí celkově řešit updaty svou cestou.
-
tak ten zip toho obsahoval daleko méně než obsahuje docker image. Šlo snadno z toho udělat systemd službu se vším, co k tomu náleží, dali se použít systémové závislosti atd. atd.
Na hlídání ano, ale co potom, co ti ten nástroj začne křičet, že je kontejner zranitelný a JetBrains si dává na čas s aktualizací. To je ta nepříjemná konsekvence, o které mluvím. U toho zip je menší šance vzhledem k množství komponent.
Je to takový běh dokolečka. JetBrains pro Youtrack neruší za nic, vylučuje svoji odpovědnost z nezáplatovaných děr a zranitelností, nezavazuje se k rychlé aktualizaci atd.
Nemluvě o tom, že JetBrains k docker imagů negenerují žádný changelog (výjma samotného třeba youtrack).
-
Takže ZIP rozbalíš, napojíš na prostředky serveru, teoreticky ti appka může dělat kdovíco a připadá ti to ok.
OCI nastartuješ v omezeném namespace, takže to může jen tam, kam je to nezbytně nutné, což nastavuješ ty, ale připadá ti to nedůvěryhodné.
A pokud si ty programy audituješ, tak nechápu, v čem je rozdíl. ZIP si rozbalíš, podíváš se co tam je, a důvěřuješ binárce výrobce. Image si taky můžeš projít a podívat se, co tam je...
-
KateStříbrný podporovatel
Tohle je jedna z věcí co nechápu. Cokoliv má přístup zvenku na mé infra nejede mimo kontejnery. Osobně používám primárně containers v nixos (deklarativně definované nspawn kontejnery), ale i OCI (podman nebo k8s). Představa že si přímo na server rozbalím nějaký proprietární zip mě upřímně děsí.
Jako, z debaty to vypadá že je možná oficiální kontejner youtrack trochu prasečina, ale to není chyba technologie.
-
já ti nevím, provoz služeb pod systemd je tady už pěknou řádku let, je to robustní, standardní řešení na omezování zdrojů, monitoring a celý životní cyklus aplikace. Aplikace v archivu (zejména pokud jde o jarko) je poměrně standardní u placenýho SW, pokud nejsou ochotní poskytnout balíček do OS.
Ne každý to spouští v k8s se všemi bezpečnostními věcmi, ale jejich image je určen i pro docker, podman atd. Docker a OCI kontejnery nejsou bezpečnostní encláva, nelze k tomu tak přistupovat, v systemd s selinux máš daleko širší možnosti jak zajistit kontrolu služby, k8s to neřeší o moc lépe.
Stejně jako JetBrains s youtrack to dělají i další. Image bez jakékoliv dokumentace, bez výpisu závislostí a k nim licencí, bez dopředu dané politiky jak a kdy budou aktualizovat bezpečnostní zranitelnosti atd. To, že něco dělají všichni a někteří rádi neřeší jakoukoliv bezpečnost, hlavně, že to spustí nic nemění na tom, že to je špatně.
YouTrack asi není věc, kterou si člověk bude provozovat sám na domácím labu. Nix zatím ve firemním prostředí je rozšířený dost málo, bezpečnost zatím vyřešenou nějak rozumně ani nemá.
26. 3. 2025, 09:38 editováno autorem komentáře
-
KateStříbrný podporovatel
> já ti nevím, provoz služeb pod systemd je tady už pěknou řádku let, je to robustní, standardní řešení na omezování zdrojů, monitoring a celý životní cyklus aplikace.
A nějakou chvilku už taky přímo podporuje quadlety, způsob jak spouštět OCI kontejnery v podmanu jako systemd service, umí si hlídat updaty a provádět automatický rollback v situaci kdy update něco rozbije. Systemd a Podman je hodně silná kombinace, divím se že ještě někoho zajímá docker.
> v systemd s selinux máš daleko širší možnosti jak zajistit kontrolu služby
A oboje se dá používat v tandemu s kontejnery :)
-
nargStříbrný podporovatel
Vidíte, a autor nechce zase řešit haldu zbytečných issues plynoucích z různých verzí systémů, glibc, javy a další haldy věcí ...
-
nargStříbrný podporovatel
Ano, protože podporovat staré verze/zabugované verze je snem každého vývojáře a je to vizitka jeho práce. Ne, není. Navíc podpora každé kombinace čehokoli stojí peníze, čas a nervy (vývojáře, QA). U opensource to je většinou rozdělené mezi vývojáře/package maintainera/komunitu, ale u komerčních projektů se o to stará dodavatel (vývojář) sám. Osobně se nedivím že se mu do toho moc nechce, já taky u svého software (vyvíjeného na zakázku) garantuju otestovanou jednu kombinaci (která jede na produkčním serveru) a cokoli navíc mě nikdo nezaplatí (proč taky?) a ani popravdě s tím nechci ztrácet čas a nervy.
-
No na ZIP stacilo extrahovat slozku pod nejakeho usera a bylo...nebo to strcit za nejakou proxy a bylo...v CI uplne jednoducha vec i pro multiinstanci, jen ta aktualizace byla otravna. Ale docker...opet zavleceni problemu s root kontejnery, kdyz spadne docker, spadne vsechno, hledani problem v ramci dockeru etc etc...
Nam nezbyde nez to predelat do dockeru a cekat, jake problemy se projevi, vsechny navody doted vytvarely docker kontejner s importem ZIP varianty, takze ted to zkousim naslepo nejak nacpat do CI, kde se docker api nepouziva...
-
KateStříbrný podporovatel
> Ale docker...opet zavleceni problemu s root kontejnery, kdyz spadne docker, spadne vsechno, hledani problem v ramci dockeru etc etc...
Je to normální OCI image, půjde to spustit i v rootless podmanu.
-
Tak jsem to zatim zkusil v podmanu. Po hledani spravne syntaxe kvuli mapovani uid:gid jsem kontejner uspesne spustil s pripojenymi permanentnimi datovymi slozkami.
Uzasne.
YT si v /opt/youtrack/data slozce vytvori nejake soubory (napr. internal/bundle.properties) a vygeneruje token pro Set Up/Upgrade. Jdu do Set Up, nastavim zakladni parametry.
Vysledek:
Data Directory location: /opt/youtrack/data
--> Invalid location: Directory /opt/youtrack/data is not empty.WTF.
Jo a druhe WTF.
V bundle.properties je uvedeno, ze ho nemate menit rucne, ale pouzit prikazovou radku "/opt/youtrack/bin/youtrack.sh configure --property=newValue". Takze pro nektere zmeny budu muset lezt do kontejneru (pokud to nesezere nejaky budouci dockerfile) ??Chybi mi ZIP.
25. 3. 2025, 14:55 editováno autorem komentáře
