Nějakou dobu jsem pracoval na projektu, který používá GitLab Runner s Dockerem jako jeho realizátorem. Vzhledem k tomu, že běžci jsou hostováni na CentOS 7, vše dávalo smysl – dokud jsme nezačali uvažovat o přesunu na CentOS 8 a náš svět explodoval.
První věc, na kterou jsme mysleli, byla, protože Podman je náhradník typu drop-in, mělo by to být snadné (pravdivost toho tvrzení si jistě dokážete představit sami). Pravdou bylo, že Podman neměl API, které GitLab Runner používal ke správě kontejnerů, takže i když jsme mohli dělat vše ručně, ještě jsme tam nebyli.
OK, zpět na rýsovací prkno, co kdybychom zadali problém GitLab pro GitLab Runner, aby implementoval Podmana jako vykonavatele? Ukazuje se, že problém již existoval. Parafrázovaná odpověď zněla:"Nebereme žádné nové exekutory, ale když to napíšeš sám, uvidíme, jestli to vezmeme." Moje znalosti o vnitřnostech GitLab Runner jsou horší než moje němčina a jediné, co mohu říct, je „Danke“, ani celé slovo.
Toto doma nezkoušejte
Tato „jednoduchá“ migrace byla čímkoli, ale jako poslední možnost jsme si mysleli, že musí existovat způsob, jak nainstalovat Docker v CentOS8. Můžete si přečíst nějaké „návody“, které to dělají, ale nutí vás vyškrábat si oči, takže to nepřipadalo v úvahu. (Vážně, doma to nezkoušejte).
[ Také by se vám mohlo líbit: Vylepšená integrace systému s Podmanem 2.0 ]
Uplynul nějaký čas a dočasně jsme přešli na jiný projekt, který byl naléhavější. I když jsme chtěli vše přesunout na CentOS 8, nebylo kam spěchat.
Před několika měsíci jsme ale našli příspěvek, že Podman implementuje REST API kompatibilní s Dockerem. Bylo to, jako by nám četli myšlenky; přesně tohle jsme potřebovali. Teď by to mělo být snadné. (Vidíte, kam tím mířím, že?)
Začali jsme znovu testovat, když byl vydán Podman 2.0, všichni šťastní a optimističtí. GitLab Runner se připojoval k soketu, ale nepodařilo se mu vytvořit svazky. Potom jsme si pozorněji přečetli poznámky k vydání a řekli, že koncový bod pro svazky ještě nebyl implementován, ale je v hlavním stromu (brzy to bude 2.1). Takže jsme ještě měli šanci.
Hrubý backport
Uplynulo několik dní; udělali jsme hacknutý backport koncového bodu svazků na 2.0 a vyzkoušeli i hlavní větev, ale všechno selhalo a nevěděli jsme proč.
Naštěstí byl Podman 2.1 vydán docela rychle a byli jsme zpět na správné cestě. Začali jsme znovu, ale tentokrát jsme zvolili jiný přístup. Poté, co jsme se trochu vyjádřili k příslušnému problému s Podmanem, začali jsme se scházet v #podman na IRC a klást otázky týkající se tohoto problému. Dostali jsme několik odpovědí od vývojářů a tehdy to začalo být zajímavé!
Založili jsme testovací repo v GitLab, zaregistrovali spoustu běžců a začali řešit každý problém, jeden po druhém. Nastavili jsme také instanci Docker, která se použije jako základní, ale veškerou její komunikaci s GitLab Runner jsme monitorovali pomocí socat —tak jsme přesně viděli, co se děje a co jsme potřebovali sladit.
Začali jsme problémem, kdy se zdálo, že úloha funguje, ale ve skutečnosti nic nedělala; nejhorší ze všeho bylo, že to nic nezaznamenávalo, takže kluci museli nejprve opravit protokoly a pak se vrátit k hlavnímu problému. Když to bylo z cesty, vyskytl se další problém s položkami /dev, který byl také vyřešen. Po několika dnech testování to začalo vypadat opravdu dobře; mohli jsme provozovat jednoduché jednolinky bez větších problémů. Takže jsme si mysleli, že jsme skončili, ale ve skutečnosti jsme měli před sebou ještě několik cest.
Když jsme přešli na déle běžící úlohy, byly uprostřed přerušovány kvůli problému se sledováním nečinného připojení. Oprava, která vedla k dalšímu problému s Podmanem, který se nikdy neuzavřel, ale správci Podman vyřešili oba tyto problémy.
Chyba pro chybu
Od začátku nás však trápil jeden problém – kvůli němu jsme museli před každým spuštěním odstraňovat svazky. Věc, kterou vám o kompatibilitě nikdo neřekne, je, že někdy, abyste toho dosáhli, musíte být kompatibilní s chybami za chyby. Docker před více než pěti lety podal problém se skutečností, že když požádáte o vytvoření svazku, který již existuje, vrátí se „vše v pořádku“ a bude se chovat, jako by se nikdy nic nestalo. Na druhou stranu Podman vracel správnou chybovou zprávu (důraz na „byl“, protože nyní funguje stejně jako Docker, alespoň v režimu compat. Chyba za chybu, že?)
Když byly tyto hlavní problémy mimo cestu, objevily se některé drobné věci, ale vše běželo hladce, alespoň pokud jsme mohli testovat.
[ Uživatelská příručka API:7 osvědčených postupů účinných programů API ]
Koneckonců
Takže, jak se věci mají nyní? Všechny problémy, na které jsme narazili s Podmanem, jsou nyní opraveny v hlavní větvi, a pokud vše půjde dobře, budou součástí nadcházejícího vydání Podman 2.2. Bude to první vydání Podmana, které může běžet s GitLab Runner hned po vybalení, aniž by vůbec věděl, že mluví s Podmanem. To je pro nás opravdu významný milník.