Containerele nu sunt doar procese Linux: explicăm OCI

Când spunem „container”, un developer se gândește la Docker, la câteva incantații docker run și la o fericită ignoranță a ce se întâmplă sub capotă. Dar dacă săpăm un pic mai adânc, aflăm: un container nu e doar un proces Linux cu un strop de chroot. E o grădină zoologică de abstracții, standardizate de OCI (Open Container Initiative).

Ce se ascunde în spatele magiei docker run?

OCI nu e un singur standard, ci trei specificații care împreună descriu cum ar trebui să arate un container „corect”:

• Runtime Specification — cum să pornești și să oprești un container, folosind namespaces, cgroups și alte delicatese ale nucleului.
• Image Specification — ce conține imaginea: straturi, configurare, metadate. Tot ce obișnuim să facem push în registry.
• Distribution Specification — cum să schimbi imagini prin rețea, fără a reinventa roata.

Pe scurt, OCI e un set de reguli de bun simț datorită căruia Podman, containerd, CRI-O și chiar scriptul tău de acasă în bash se pot înțelege. Fără asta, am trăi încă în lumea „la mine merge”.

De ce nu sunt doar procese?

Da, la baza unui container stă un proces (sau un grup de procese), dar între tine și acest proces e un strat de magie: montarea sistemelor de fișiere, configurarea rețelei, gestionarea resurselor. Încearcă să configurezi manual cgroups pentru CPU și memorie — și vei înțelege de face Docker bani. OCI preia toată durerea, oferind o interfață unitară.

Apropo, dacă ai scris vreodată propriul runtime pentru containere (și cine n-a scris?), știi: implementarea unui OCI Runtime e un quest de nivel „asamblează IKEA în întuneric total”. Dar rezultatul merită: containerul tău va funcționa oriunde există un runtime compatibil OCI.

Comentariul studioului METABYTE: Și nouă ne place să scormonim prin OCI, dar de obicei avem încredere în containerd — cere mai rar restart la laptop. Iar dacă ai nevoie de o construcție personalizată de containere pentru producție, știm noi unde sunt greblele.