GitLab 10.7

Byla vydána nová verze 10.7 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu. Vývojáři GitLabu zdůrazňují Web IDE (YouTube) a SAST (Static Application Security Testing) pro Go a C/C++.

23.4.2018 06:00 | Ladislav Hagara | Nová verze

Komentáře

[Max]

Provozuje někdo Gitlab na vlastním serveru? Nějaký feedback by byl?
Zdar Max

[Luboš Doležel (Doli)]

U nás ve firmě se to používalo a nebylo to špatný. Můj tým ale nakonec zvolil Bitbucket v cloudu, protože interní účtované náklady na 1 uživatele v interním Gitlabu byly násobně vyšší než cena za cloudový Bitbucket.

Problémem Gitlabu je například to, že nemergují některé patche dodané komunitou, protože si některé funkce chtějí nechávat do placených verzí.

[Honza]

Pouzivame nejakou starou verzi GitLabu - snad 8? Nikomu se kvuli narocnosti nechce do upgrade. Na druhou stranu to ma opravdu nizke naroky na HW na to, kolik to vyuziva lidi...

[t]

Provozuju přes dva roky dvě menší CE instance (jedna cca 10 uživatelů / 50 projektů, druhá 5 / 5). První je instalovaná ze zdrojů, druhá omnibus. Při tomhle množství je to poměrně náročné na zdroje, větší server jsem zkoušel omezit, i tak žere ~2 GB paměti. Používám repozitáře, issues, buildy. Chystám se vyzkoušet auto dev-ops a monitorování.

Verzi ze zdrojáků upgraduju tak ob 3 minor verze, podle návodu, žádný větší zádrhel si nevybavuju. Vyžaduje poměrně nové verze ruby / go / node, dokážu si představit, že se může tlouct s něčím jiným. Omnibus verze zahrnuje i nginx, je jednodušší ji vyhradit VPS. Upgraduje se z balíčku, zatím to vždy proběhlo bez problémů (a bez potřeby do toho zasahovat). Během psaní tohoto příspěvku jsem pomocí `apt-get update && apt-get upgrade` nasadil verzi 10.7. Zkušenosti tedy jen dobré.

[MP]

Jestli 2GB pameti = narocne na zdroje... :D

[mhepp]

Mám nasazený Gitlab 10.X ze zdrojových kódů, instance pro cca 200 uživatelů, 1500 projeků, cca 40 commitů/uživatel/den, CI, docker repository a jsem celkem spokojený. Jen celkem řeším problém s Unicornem, který padá. To snad odstraní aktualizace na 10.7 verzi.

Instalace zezdrojových kódů má nevýhodu, že nehlídá spotřebu prostředků, takže je potřeba občas celý gitlab restartovat, aby se vyčistila paměť. To řeší omnibus balík, který se mi ale nelíbí, protože obsahuje pár aplikací, které by (dle mého názoru) neměly být součástí (Postgres, nginx...). Omnibus balík zjednodušuje aktualizaci, ale nedává kontrolu na záplatováním chyb v přidružených aplikací (ten postgres a tak). Aktualizace ze zdrojových kódů je náročnější na pozornost, ale je to clekem rutinní zaležitost.

Náklady na provoz jsou podstatně nižší, než bychom dali v tomto počtu za EE verzi, i když kolegům některé funkce občas chybí. Aplikace bohatě stačí pokrýt naše potřeby a líbí se mi (zatím) směr vývoje a přístup k bezpečnostním problémům.

[MP]

Pokud vim, tak omnibus nebrani tomu, aby clovek mel vlastni instance posgres/nginx atd.

[mhepp]

Ano, ale v době nasazování to nebylo dobře dokumentované a podporované. A v tomto okamžiku je instance vysoce produkční, tudíž problém s ní více manipulovat.

Osobně zvažuji posunutí celého gitlabu dál, ale nemám teď moc času se tomu více věnovat. Potřeboval bych HA, možná bych chtěl přejít na omnibus (s vlastní DB, externí nginx...)

[Max]

Od nginx utíkám, verze zdarma je silně limitovaná a pro HA se nehodí. V současnosti mám 2x Nginx (Active-Pasive s VVRP, zatím je zbytečné řešit Active-Active alá dns roundrobin a řešit úpravu hlaviček pro zachování sessions) a za ním 2x IIS. Nginxem rozhrazuji zátěž na ty IIS servery a zjistil jsem, že to prostě není s free verzi Nginx rozumné.
Jde o to, že je dobré kontrolovat, zda backend (IIS server) žije, ale free verze nginx podporuje jen pasivní kontroly, né aktivní. To znamená, že on kontroluje dostupnost backendu jen v rámcu požadavku od klienta. Když klient narazí na nějaký bug na té aplikaci na IIS serveru, nebo z nějakého jiného důvodu se stane, že se spojení vytimeoutuje, tak Nginx vyhodnotí, že IIS neběží a odstřelí ho jen na základě toho, že jednomu klientovi to 2x, nebo 3x po sobě vytimeoutovalo request. A teď řešit počty vytemoutování a další věci a celkový čas, kdy ostatní klienti by padali na nedostupný backend narůstá. V případě aktivních kontrol si mohu nastavit co a jak se má kontrolovat, mám představu o stavu a rychlosti a jsem schopen detekovat, že je backend skutečně off/on v řádu sekund, né v řádu minut jako je tomu u pasivních kontrol.
Rozhodl jsem se, že od Nginx uteču a nasadím HAProxy (v poslední verzi už obsahuje podporuje http2 a další vychytávečky, je distribuční balík pro Debian, takže tak).
Samozřejmě existuje na githubu spousta pluginů/patchů pro Nginx, které tam nějaké funkcionality dodávají, ale já chci relativně bezúdržbové řešení, né si sestavovat Nginx ze zdrojáků, patchovat ho a řešit kompatibilitu a podporu patche, který má mnohdy jednoho vývojáře.
Zdar Max

[mhepp]

Nginx jsem se v počátku také bránil. Chtěli jsme nasadit ověřování uživatelů přes Shibboleth, který používáme v rámci celé organizace. To je v nginx velmi náročné na realizaci, tak v pilotním provozu jsem měl nasazený Apache. Zde ale byla spousta problémů, které neměly reálné řešení. Musel jsem tedy opustit Apache a Shibboleth. HAproxy také není v našem případě použitelné kvůli virtuálním hostům, které potřebuji v rámci instance gitlabu provozovat.

[Max]

HAProxy je jen proxy, tam přece není třeba vhosty řešit. A směrování v návaznosti na domain name tam jde nastavit. Pokud máš v backendu více serverů a určité vhosty na určitých serverech, tak s HAProxy mít problém nebudeš. Nebo jsem něco nepochopil?
Zdar Max