Per un po', ho lavorato a un progetto che utilizza GitLab Runner con Docker come esecutore. Dal momento che i corridori sono ospitati su CentOS 7, tutto aveva un senso, finché non abbiamo iniziato a cercare di spostarlo su CentOS 8 e il nostro mondo è esploso.
La prima cosa che stavamo pensando era, dal momento che Podman è un sostituto drop-in, questo dovrebbe essere facile (puoi immaginare la veridicità di questa affermazione). La verità era che Podman non aveva l'API che GitLab Runner usava per gestire i container, quindi anche se potessimo fare tutto manualmente, non eravamo ancora lì.
OK, tornando al tavolo da disegno, che ne dici di presentare un problema con GitLab affinché GitLab Runner implementi Podman come esecutore? Si scopre che il problema esisteva già. La risposta parafrasata è stata:"non prendiamo nuovi esecutori testamentari, ma se lo scrivi tu stesso, possiamo vedere se possiamo accettarlo". La mia conoscenza degli interni di GitLab Runner è peggiore del mio tedesco e tutto ciò che posso dire è "Danke", nemmeno la parola intera.
Non provarlo a casa
Questa "semplice" migrazione era qualsiasi cosa ma, quindi, come ultima risorsa, abbiamo pensato che doveva esserci un modo per installare Docker in CentOS8. Bene, puoi leggere alcuni "tutorial" che lo fanno, ma ti fanno venire voglia di strappare gli occhi, quindi non era un'opzione. (Seriamente, non provarlo a casa).
[ Potrebbe interessarti anche: Integrazione del sistema migliorata con Podman 2.0 ]
Passò un po' di tempo e ci trasferimmo temporaneamente a un altro progetto più urgente. Anche se volevamo spostare tutto su CentOS 8, non c'era fretta.
Ma poi, alcuni mesi fa, abbiamo trovato un post che diceva che Podman stava implementando un'API REST compatibile con Docker. Sembrava che stessero leggendo le nostre menti; questo è esattamente ciò di cui avevamo bisogno. Questo dovrebbe essere facile ora. (Vedi dove sto andando con questo, vero?)
Abbiamo ricominciato a testare quando è stato rilasciato Podman 2.0, tutti felici e ottimisti. GitLab Runner si stava connettendo al socket ma non riusciva a creare i volumi. Poi abbiamo letto le note di rilascio con maggiore attenzione, e ci hanno detto che l'endpoint per i volumi non era ancora stato implementato, ma era nell'albero principale (che presto sarebbe stato 2.1). Quindi avevamo ancora una possibilità.
Un backport hacky
Passarono alcuni giorni; abbiamo fatto un backport hacky dell'endpoint dei volumi a 2.0 e provato anche il ramo principale, ma tutto stava fallendo, e non avevamo idea del perché.
Fortunatamente, Podman 2.1 è stato rilasciato abbastanza rapidamente e siamo tornati in pista. Abbiamo ricominciato, ma questa volta abbiamo adottato un approccio diverso. Dopo aver commentato un po' il corrispondente problema di Podman, abbiamo iniziato a frequentare #podman su IRC e a fare domande su questo problema. Abbiamo ricevuto alcune risposte dagli sviluppatori ed è allora che le cose sono diventate interessanti!
Abbiamo creato un repository di prova in GitLab, registrato un gruppo di corridori e iniziato ad affrontare ogni problema, uno per uno. Abbiamo anche impostato un'istanza Docker da utilizzare come linea di base, ma monitorato tutte le sue comunicazioni con GitLab Runner utilizzando socat —in questo modo, potremmo vedere esattamente cosa stava succedendo e cosa dovevamo abbinare.
Abbiamo iniziato con un problema in cui il lavoro sembrava funzionare, ma in realtà non stava facendo nulla; peggio di tutto, non stava registrando nulla, quindi i ragazzi hanno dovuto prima riparare i registri e poi tornare al problema principale. Detto questo, c'era un altro problema con le voci /dev, che è stato anche risolto. Dopo alcuni giorni di test, le cose stavano iniziando ad andare davvero bene; potremmo eseguire battute facili senza troppi problemi. Quindi pensavamo di aver finito, ma in realtà avevamo ancora un po' di strada da fare.
Quando siamo passati a lavori con esecuzione più lunga, sono stati tagliati nel mezzo a causa di un problema nel rilevamento della connessione inattiva. La risoluzione di ciò ha portato a un altro problema con Podman che non si è mai chiuso, ma i manutentori di Podman hanno affrontato entrambi questi problemi.
Bug per bug
Tuttavia, c'era un problema che ci aveva infastidito sin dall'inizio:ci ha costretto a rimuovere i volumi prima di ogni esecuzione. La cosa che nessuno ti dice sulla compatibilità è che a volte, per raggiungere questo obiettivo, devi essere compatibile bug per bug. Docker ha presentato un problema più di cinque anni fa in merito al fatto che quando chiedi di creare un volume già esistente, verrà restituito "tutto bene" e si comporterà come se non fosse mai successo niente. Podman, d'altra parte, stava restituendo il messaggio di errore corretto (enfasi su "era" perché ora si comporta allo stesso modo di Docker, almeno in modalità compatibilità. Bug-for-bug, giusto?)
Con questi problemi principali fuori mano, sono apparse alcune cose minori, ma tutto stava funzionando senza intoppi, almeno per quanto abbiamo potuto testare.
[ Manuale dell'utente dell'API:7 best practices per programmi API efficaci ]
Conclusione
Allora, come stanno le cose adesso? Bene, tutti i problemi che abbiamo riscontrato con Podman ora hanno tutti delle correzioni nel ramo principale e, se tutto va bene, faranno parte della prossima versione di Podman 2.2. Ciò segnerà la prima versione di Podman che può essere eseguita immediatamente con GitLab Runner, senza nemmeno sapere che sta parlando con Podman. Questa è una pietra miliare davvero importante per noi.