Hebben we een stippingpunt van verdragen bereikt?

Er is een deugdzame technologiecyclus die de grenzen verlegt van wat er wordt gebouwd en hoe het wordt gebruikt. Een nieuwe technologieontwikkeling komt naar voren en trekt de aandacht van de wereld. Mensen beginnen te experimenteren en ontdekken nieuwe toepassingen, use cases en benaderingen om het potentieel van de innovatie te maximaliseren. Deze use cases genereren een aanzienlijke waarde, waardoor de vraag naar de volgende iteratie van de innovatie wordt aangewakkerd, en op zijn beurt een nieuwe golf van innovators creëert de volgende generatie use cases, waardoor verdere vooruitgang wordt aangebracht.

Containerisatie is de basis geworden van moderne, cloud-native softwareontwikkeling, ter ondersteuning van nieuwe use-cases en benaderingen voor het bouwen van veerkrachtige, schaalbare en draagbare applicaties. Het bevat ook de sleutels tot de volgende innovatie van software-levering, die tegelijkertijd de evolutie nodig heeft om te beveiligen, per ontwerp, continu bijgewerkte software en dienen als het middel om daar te komen.

Hieronder zal ik enkele van de innovaties bespreken die hebben geleid tot onze containerrevolutie, evenals enkele van de eigenschappen van cloud-native softwareontwikkeling die hebben geleid tot dit buigpunt-een die de wereld heeft voorbereid om weg te gaan van traditionele Linux-distributies en naar een nieuwe benadering van open source software-levering.

Iteratie heeft ons dichter bij alomtegenwoordigheid gebracht

Er zijn veel innovaties geweest die de weg hebben vrijgemaakt voor een veilige, performante open source levering. In het belang van je tijd en mijn woord tellen zal ik drie specifieke mijlpalen roepen. Elke stap, van Linux -containers (LXC) tot Docker en uiteindelijk het Open Container Initiative (OCI), gebouwd op zijn voorganger, die beperkingen aanpakt en nieuwe mogelijkheden ontgrendelen.

LXC legde de basis door de mogelijkheden van de Linux -kernel te benutten (namelijk cgroups en naamruimten), om lichtgewicht, geïsoleerde omgevingen te creëren. Voor het eerst konden ontwikkelaars applicaties met hun afhankelijkheden verpakken en een zekere mate van consistentie bieden in verschillende systemen. De complexiteit van LXC voor gebruikers en het ontbreken van een gestandaardiseerde beeldverdelingscatalogus belemmerde echter de wijdverbreide acceptatie.

Docker kwam naar voren als een game-wisselaar en democratisering van containertechnologie. Het vereenvoudigde het proces van het maken, uitvoeren en delen van containers, waardoor ze toegankelijk zijn voor een breder publiek. Docker’s gebruiksvriendelijke interface en het maken van Docker Hub, een centrale repository voor containerafbeeldingen, bevorderde een levendig ecosysteem. Dit gebruiksgemak heeft een snelle acceptatie aangewakkerd, maar bracht ook bezorgdheid uit over leveranciervergrendeling en de noodzaak van interoperabiliteit.

De OCI (Open Containers Initiative) herkende het potentieel voor fragmentatie, stapte in om containerformaten en runtimes te standaardiseren. Door open specificaties te definiëren, zorgde de OCI ervoor dat containers konden worden gebouwd en over verschillende platforms konden worden gelopen, waardoor een gezond, competitief landschap werd bevorderd. Projecten zoals Runc en Containerd, geboren uit de OCI, boden een gemeenschappelijke basis voor container runtimes en maakten een grotere draagbaarheid en interoperabiliteit mogelijk.

De OCI-normen stelden ook Kubernetes (een andere leverancierneutrale standaard) in staat om een ​​echt draagbaar platform te worden, dat in staat is om op een breed scala van infrastructuur te lopen en organisaties in staat te stellen hun toepassingen consistent te orkestreren tussen verschillende cloudproviders en on-premises omgevingen. Deze standaardisatie en de bijbehorende innovaties hebben het volledige potentieel van containers ontgrendeld, waardoor de weg werd vrijgemaakt voor hun alomtegenwoordige aanwezigheid in moderne softwareontwikkeling.

(Containerized) Software is de wereld opeten

De vooruitgang in Linux, de snelle democratisering van containers via Docker en de standaardisatie van OCI werden allemaal aangedreven door noodzaak, met de evolutie van cloud-native app-use cases die orkestratie en standaardisatie naar voren duwen. Die cloud-native applicatiekarakteristieken benadrukken ook waarom een ​​algemene benadering van Linux-distos niet langer softwareontwikkelaars bedient met de meest veilige, bijgewerkte stichtingen om te ontwikkelen:

Microservice-georiënteerde architectuur: cloud-native applicaties worden meestal gebouwd als een verzameling kleine, onafhankelijke services, waarbij elke microservice een specifieke functie uitvoert. Elk van deze microservices kan onafhankelijk worden gebouwd, geïmplementeerd en onderhouden, wat een enorme hoeveelheid flexibiliteit en veerkracht biedt. Omdat elke microservice onafhankelijk is, hebben software -bouwers geen uitgebreide softwarepakketten nodig om een ​​microservice te laten werken, die alleen afhankelijk zijn van de kale essentials in een container.

Resource-bewust en efficiënt: cloud-native applicaties zijn gebouwd om efficiënt en hulpbronnenbewust te zijn om de belastingen op de infrastructuur te minimaliseren. Deze uitgeklede aanpak komt natuurlijk goed overeen met containers en een efemere implementatiestrategie, waarbij nieuwe containers voortdurend worden ingezet en andere workloads worden bijgewerkt naar de nieuwste beschikbare code. Dit vermindert beveiligingsrisico’s door te profiteren van de nieuwste softwarepakketten, in plaats van te wachten op distro -patches en backports.

Draagbaarheid: cloud-native applicaties zijn ontworpen om draagbaar te zijn, met consistente prestaties en betrouwbaarheid, ongeacht waar de applicatie actief is. Als gevolg van containers die de omgeving standaardiseren, kunnen ontwikkelaars verder gaan dan de eeuwenoude “It werkte prima op mijn machine” hoofdpijn uit het verleden.

De deugdzame cyclus van innovatie die nieuwe use-cases en uiteindelijk nieuwe innovaties aandrijft, is duidelijk als het gaat om containerisatie en de wijdverbreide acceptatie van cloud-native applicaties. Van cruciaal belang is dat dit verbuigingpunt van innovatie en gebruiksbehoeften een ongelooflijke mate van verandering heeft aangedreven binnen open source software-we hebben een punt bereikt waarop de beveiliging, prestaties en innovatie van traditionele “Frozen-In-Time” Linux-distro’s zwaarder wegen dan de bekendheid en waargenomen stabiliteit van de laatste generatie software-levering.

Dus hoe moet de volgende generatie open source software -levering eruit zien?

Enter: Chainguard OS

Om te voldoen aan moderne beveiligings-, prestaties- en productiviteitsverwachtingen, hebben softwarebouwers de nieuwste software nodig in de kleinste vorm die is ontworpen voor hun use case, zonder een van de CVE’s die leiden tot risico voor het bedrijf (en een lijst met “fix-its” van de beveiligingsteams). Het goedmaken van die parameters vereist meer dan alleen het verleden maken. In plaats daarvan moet de volgende generatie open source software -levering beginnen bij de bron van beveiligde, bijgewerkte software: de stroomopwaartse onderhouders.

Dat is de reden waarom Chainguard deze nieuwe verdorvensbenadering heeft gebouwd, die continu softwarepakketten opnieuw opgebouwd is gebaseerd op niet -stroomafwaartse distributies, maar op de stroomopwaartse bronnen die kwetsbaarheden verwijderen en prestatieverbeteringen toevoegen. We noemen het Chainguard OS.

Chainguard OS dient als de basis voor de brede beveiligings-, efficiëntie- en productiviteitsresultaten die Chainguard -producten tegenwoordig leveren, “chainguarding” een snel groeiende catalogus van meer dan 1.000 containerbeelden.

Chainguard OS houdt zich aan vier belangrijke principes om dat mogelijk te maken:

  • Continue integratie en levering: benadrukt de continue integratie, het testen en het vrijgeven van stroomopwaartse softwarepakketten, waardoor een gestroomlijnde en efficiënte ontwikkelingspijplijn wordt gewaarborgd door automatisering.
  • Nano-updates en herbouwingen: voorstander van non-stop incrementele updates en herbouw over grote release-upgrades, zorgt voor soepelere overgangen en het minimaliseren van verstorende veranderingen.
  • Minimale, geharde, onveranderlijke artefacten: stript weg onnodige leverancier van softwareartefacten, waardoor zijspanpakketten en extra’s optioneel zijn voor de gebruiker, terwijl de beveiliging wordt verbeterd door middel van verhardingsmaatregelen.
  • Delta -minimalisatie: behoudt afwijkingen van stroomopwaarts naar een minimum, neemt alleen extra patches op als essentieel en slechts zo lang als nodig is totdat een nieuwe release van stroomopwaarts wordt gesneden.

Misschien is de beste manier om de waarde van de principes van Chainguard OS te benadrukken om de impact in Chainguard -afbeeldingen te zien.

In de onderstaande screenshot (en hier zichtbaar) kunt u een vergelijking van een zij-aan-zij zien tussen een externe en chainguard-afbeelding.

Afgezien van de zeer duidelijke discrepantie in het aantal kwetsbaarheid, is het de moeite waard om het grootteverschil tussen de twee containerafbeeldingen te onderzoeken. Het Chainguard -beeld omvat slechts 6% van het open source alternatieve afbeelding.

Samen met de geminimaliseerde beeldgrootte werd de Chainguard -afbeelding voor het laatst bijgewerkt slechts een uur voorafgaand aan de screengrab, iets dat dagelijks gebeurt:

Een snelle scan van de herkomst- en SBOM-gegevens illustreert de end-to-end integriteit en onveranderlijkheid van de artefacten-een soort compleet voedingslabel dat de beveiliging en transparantie onderstreept die een moderne benadering van open source software-levering kan bieden.

Elke Chainguard -afbeelding staat als een praktisch voorbeeld van de waarde die Chainguard OS biedt, en biedt een sterk alternatief voor wat ervoor is gekomen. Misschien is de grootste indicator de feedback die we van klanten hebben ontvangen, die hebben gedeeld hoe de containerafbeeldingen van Chainguard hebben bijgedragen aan het elimineren van CVE’s, hun supply chains beveiligen, naleving te bereiken en te behouden en de ontwikkelaars te verminderen, waardoor ze de middelen voor ontwikkelaars opnieuw kunnen toewijzen.

Onze overtuiging is dat de principes en -benadering van Chainguard OS kan worden toegepast op verschillende use-cases, waardoor de voordelen van continu herbouwd-van-softwarepakketten van de source worden uitgebreid tot nog meer van het open source ecosysteem.

Als je dit nuttig vond, bekijk dan zeker onze whitepaper over dit onderwerp of neem contact op met ons team om te praten met een expert op het gebied van Chainguard’s verspillende aanpak.

Opmerking: Dit artikel is vakkundig geschreven en bijgedragen door Dustin Kirkland – VP van engineering bij Chainguard.

Thijs Van der Does