Wanneer u veel containers op een systeem uitvoert, wilt u niet dat een container het besturingssysteem monopoliseert. Daarom gebruiken we resourcebeperkingen voor het beheer van zaken als CPU, geheugen, netwerkbandbreedte, enzovoort. De Linux-kernel biedt de cgroups-functie, die kan worden geconfigureerd om de containerprocesbronnen te beheren.
2. Beveiligingsbeperkingen
Meestal wilt u niet dat uw containers elkaar kunnen aanvallen of het hostsysteem kunnen aanvallen. We maken gebruik van verschillende functies van de Linux-kernel om beveiligingsscheiding in te stellen, zoals SELinux, seccomp, mogelijkheden, enz.
3. Virtuele scheiding
Containerprocessen mogen geen weergave zijn van processen buiten de container. Ze zouden op hun eigen netwerk moeten zijn. Containerprocessen moeten in verschillende containers aan poort 80 kunnen binden. Elke container heeft een andere weergave van zijn afbeelding nodig, heeft zijn eigen rootbestandssysteem (rootfs) nodig. In Linux gebruiken we kernelnaamruimten om virtuele scheiding te bieden.
Daarom is een proces dat in een cgroup wordt uitgevoerd, beveiligingsinstellingen heeft en in naamruimten kan een container worden genoemd. Kijkend naar PID 1, systemd, op een Red Hat Enterprise Linux 7-systeem, zie je dat systemd in een cgroup draait.
# tail -1 / proc / 1 / cgroup
1: name = systemd: /
De psopdracht laat zien dat het systeemproces een SELinux-label heeft …
# ps -eZ | grep systemd
system_u: system_r: init_t: s0 1? 00:00:48 systemd
en mogelijkheden.
# grep Cap / proc / 1 / status
…
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff
CapBnd: 0000003fffffffff
Als je tenslotte naar het /proc/1/nssubdir kijkt , zie je de naamruimte waarin systemd wordt uitgevoerd.
ls -l / proc / 1 / ns
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 mnt -> mnt: [4026531840]
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 net -> net: [4026532009]
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 pid -> pid: [4026531836]
…
Als PID 1 (en eigenlijk elk ander proces op het systeem) beperkingen voor de bron, beveiligingsinstellingen en naamruimten heeft, stel ik dat elk proces op het systeem zich in een container bevindt.
Container runtime-hulpprogramma’s wijzigen deze resourcegrenzen, beveiligingsinstellingen en naamruimten. Vervolgens voert de Linux-kernel de processen uit. Nadat de container is gelanceerd, kan de runtime van de container PID 1 in de container of de container bewaken stdin/ stdout-de runtime van de container beheert de levenscycli van deze processen.
Runtimes van containers
Je zou tegen jezelf kunnen zeggen, nou, systemd klinkt behoorlijk vergelijkbaar met een containerruntime. Nadat ik verschillende e-mailbesprekingen had gevoerd over waarom containerruntimes niet systemd-nspawnals hulpmiddel voor het lanceren van containers gebruiken, besloot ik dat het de moeite waard was om de runtimes van containers te bespreken en een historische context te geven.
Docker wordt vaak een containerruntime genoemd, maar “containerruntime” is een overbelaste term. Wanneer mensen het hebben over een ‘containertijd’, hebben ze het echt over tools op hoger niveau, zoals Docker, CRI-O en RKT die met ontwikkelaarfunctionaliteit worden geleverd. Ze zijn API-gestuurd. Ze omvatten concepten zoals het ophalen van de containerafbeelding uit het containerregister, het instellen van de opslag en uiteindelijk het lanceren van de container. Het starten van de container omvat vaak het uitvoeren van een gespecialiseerde tool die de kernel configureert om de container uit te voeren, en deze worden ook wel “containerruntimes” genoemd. Ik zal naar ze verwijzen als ‘low-level containerruntimes’. Daemons zoals Docker en CRI-O,, zou in plaats daarvan waarschijnlijk ‘containermanagers’ moeten worden genoemd.
Toen Docker oorspronkelijk werd geschreven, lanceerde het containers met behulp van de lxc toolset, die dateert van vóór systemd-nspawn. Red Hat’s originele werk met Docker was om te proberen libvirt( libvirt-lxc) in Docker te integreren als een alternatief voor de lxctools, die niet werden ondersteund in RHEL. libvirt-lxcheeft ook niet gebruikt systemd-nspawn. In die tijd zei het systeemteam dat dit systemd-nspawnslechts een hulpmiddel was om te testen, niet voor productie.
Tegelijkertijd besloten de upstream Docker-ontwikkelaars, waaronder enkele leden van mijn Red Hat-team, dat ze een manier wilden hebben om containers te lanceren in plaats van een afzonderlijke applicatie te lanceren. Er werd gewerkt aan libcontainer, als een inheemse golang-bibliotheek voor het lanceren van containers. Red Hat Engineering besloot dat dit het beste pad voorwaarts was en viel weg libvirt-lxc.
Later werd het Open Container Initiative (OCI) opgericht, een feest omdat mensen op een andere manier containers wilden kunnen lanceren. Traditionele containers met naamruimten waren populair, maar mensen hadden ook behoefte aan virtuele isolatie op machineniveau. Intel en Hyper.sh werkten aan door KVM gescheiden containers en Microsoft werkte aan Windows-gebaseerde containers. De OCI wilde een standaardspecificatie die definieerde wat een container is, dus de OCI Runtime-specificatie werd geboren.
De OCI Runtime-specificatie definieert een JSON-bestandsindeling die beschrijft welk binair bestand moet worden uitgevoerd, hoe het moet worden ingesloten en de locatie van de rootfs van de container. Tools kunnen dit JSON-bestand genereren. Dan kunnen andere hulpprogramma’s dit JSON-bestand lezen en een container op de rootfs uitvoeren. De libcontainer-delen van Docker zijn uitgebroken en aan de OCI gedoneerd. De stroomopwaartse Docker-technici en onze technici hebben geholpen bij het maken van een nieuwe frontend-tool om het OCI Runtime Specification JSON-bestand te lezen en om met de libcontainer te werken om de container uit te voeren. Deze tool, genaamd runc, werd ook aan de OCI geschonken. Hoewel runchet OCI JSON-bestand kan worden gelezen, kunnen gebruikers het zelf genereren. runcis sindsdien de populairste low-level containerruntime geworden. Bijna alle tools voor containerbeheer ondersteunenruncwaaronder CRI-O, Docker, Buildah, Podman en Cloud Foundry Garden . Sindsdien hebben andere hulpprogramma’s ook de OCI Runtime Spec geïmplementeerd voor het uitvoeren van OCI-compatibele containers.
Zowel Clear Containers als de runVtools van Hyper.sh zijn gemaakt om de OCI Runtime Specification te gebruiken voor het uitvoeren van KVM-gebaseerde containers en ze combineren hun inspanningen in een nieuw project genaamd Kata . Vorig jaar creëerde Oracle een demonstratieversie van een OCI-runtime-tool genaamd RailCar , geschreven in Rust. Het is twee maanden geleden dat het GitHub-project is bijgewerkt, dus het is onduidelijk of het nog in ontwikkeling is. Een paar jaar geleden werkte Vincent Batts aan het toevoegen van een tool, nspawn-ocidie een OCI Runtime Specification-bestand interpreteerde en lanceerde systemd-nspawn, maar niemand pakte het echt op, en het was geen native-implementatie.
Als iemand een native wil implementeren systemd-nspawn –oci OCI-SPEC.jsonen het door het systemd-team wordt geaccepteerd voor ondersteuning, dan kunnen CRI-O, Docker en uiteindelijk Podman dit gebruiken naast runc en Clear Container / runV ( Kata ). (Niemand in mijn team werkt hieraan.)
De bottom line is, drie of vier jaar terug, de stroomopwaartse ontwikkelaars wilden een low-level golang-tool schrijven voor het lanceren van containers, en deze tool werd uiteindelijk runc. Die ontwikkelaars hadden op dat moment een C-gebaseerde tool om dit te doen lxc en belden dat weg. Ik ben er vrij zeker van dat op het moment dat ze de beslissing namen om libcontainer te bouwen, ze niet geïnteresseerd zouden zijn geweest in systemd-nspawnof enige andere niet-native (golang) manier om containers met “naamruimte” uit te voeren.
Extra
Snel, ordelijk en correct offertes maken of opstellen is essentieel voor elk bedrijf om potentiële klanten te overtuigen. Met onFact maakt u snel offertes aan door bestaande producten en prijzen op te zoeken in uw persoonlijke productlijst en aan te vullen met specifieke informatie per prospect. Wanneer u later gelijkaardige aanvragen krijgt maakt u met 1 klik een kopie van deze offerte en past u de specifieke informatie aan.