Canonical geeft twaalf jaar ondersteuning op Ubuntu Docker-images

Canonical is een nieuw initiatief gestart waarmee Ubuntu Pro-gebruikers twaalf jaar ondersteuning krijgen voor opensource Docker-images. Dit doet Canonical onder het nieuwe Everything LTS-programma.

Everything LTS is gemaakt voor Docker-images op RHEL, Ubuntu, VMware en publiccloud-K8-instances, aldus Canonical in een aankondiging. Daarnaast start Canonical een nieuwe dienst voor distroless Docker-images. Dat zijn images gebouwd aan de hand van specificaties van de klant, met daarin alleen de bestanden die echt nodig zijn voor de applicaties, aldus Canonical.

Het bedrijf ontwerpt en bouwt deze images op verzoek van klanten en biedt dan direct twaalf jaar beveiligingsonderhoud aan alle opensource-apps en dependency's, ook als die niet als deb in Ubuntu zitten, zegt CEO Mark Shuttleworth.

Reacties (41)

[Aeternum]

Dit kan wel een uitkomst zijn met legacy software die niet zomaar te vervangen is.

[the_stickie]

Na 12 jaar moet die dan uiteindleijk wel vervangen worden. En dat is waarschijnlijk na 12 jaar niet eenvoudiger geworden...

[d3burt]

Precies... De reden dat ik probeer om de Ubuntu LTS cyclus te volgen is dat als je na twee jaar kunt beginnen met kijken wat er nodig is om je app op de volgende LTS werkend te krijgen, je een goede kans hebt dat alle kennis nog in living memory is. Als je kijkt naar de RedtHat/CentOS cyclus zie je dat je die kennis vaak weer van begin af aan moet opbouwen tegen de tijd dat de update komt. Upgraden blijft pijnlijk, maar in mijn beleving is de pijn iedere twee jaar een ordegrootte minder dan de pijn iedere vijf jaar, en als bonus blijft de hele software een bekende grootheid voor het hele team.

De gevallen waar ik me niet aan mijn eigen regels heb gehouden achtervolgen mij tot op de dag van vandaag. Ik wil niet denken aan de pijn als er twaalf jaar niet naar gekeken is..

[Nozmordre]

Het gaat juist alleen maar meer legacy software maken die niet zomaar te vervangen is.
Want het wordt toch zó lang onderhouden waarom zou je nog moeite steken in LCM? Tot je ineens 12 jaar verloren tijd moet inhalen.

[Creesch]

Och dat gebeurt nu ook al. Heb op diverse plekken gezien dat men platformen op een bepaalde versie van een linux distro "bevriest". Geeft een heel stabiel platform en zorgt inderdaad een flinke tijd later voor flink veel hoofdpijn.

Het ging hierbij om systemen die eigenlijk alleen maar actief waren op een intern netwerk en geen verbinding met de buitenwereld hadden. Toch vraag ik me af hoe blij security hier altijd mee was, aangezien er wel een verbinding mogelijk was van buiten naar binnen voor zaken zoals applicatie updates, etc.

Anyway, moraal van het verhaal is dat dit allang gebeurt en dit er in mijn optiek niet noemenswaardig aan gaat bijdragen.

[com2,1ghz]

Bij vrijwel iedere opdrachtgever waar ik gekomen ben draaide wel wat 5 tot 15 jaar niet onderhouden werd. en dat is geheel normaal.
Je kan niet zomaar zeggen dat de boel maar up to date moet blijven. Soms zijn er eisen zoals wetgeving of internationale protocollen waardoor je het oude systeem beschikbaar moet houden.
Dit soort LTS images zijn dan goed bruikbaar omdat je nog ten minste OS updates krijgt.

[Reactie gewijzigd door com2,1ghz op 22 juli 2024 22:11]

[yamlel]

Als je een applicatie voor zo lang gaat draaien zonder te updaten snap ik niet waarom je in eerste instantie bent overgestapt naar containerizatie.

[JasperE]

Nou bijvoorbeeld zodat het eenvoudig te migreren is naar nieuwe hardware

[jctjepkema]

Niet alle applicaties in docker draaien aan een cloud. Waar ik werk hebben we bijvoorbeeld een container gemaakt voor embedded software ontwikkeling zodat we over x jaar die container weer kunnen starten en nog steeds software ondersteuning kunnen bieden. Daarvoor is zoiets juist heel handig.

[JustFogMaxi]

Tja of je update gewoon je software...

[kid1988]

Want dat kost geen cent.

In sommige zakelijke, embedded of industriële toepassingen is het zeer arbeidsintensief om te upgraden.

Hoe dichter de software ondersteuning in de buurt komt van de technische levensduur van het apparaat waar het op draait, hoe veiliger het apparaat (ik weet uit ervaring dat in industriële toepassingen de machines gewoon ongepatched doordraaien indien er geen software support meer is maar de machine nog niet (technisch) afgeschreven is).

Veel machinebouwers zijn niet in staat software support te leveren op het onderliggende is.

[CH4OS]

Die (industriële) machines draaien hun software meestal niet in Docker en helemaal niet in de (public) cloud.

[joost00719]

De embedded machines doen zelf niet zo veel data processing.
Daarnaast kun je in Docker ook gewoon COM-poorten doorgeven als je Linux draait. Je kunt dan bijvoorbeeld een barcodescanner o.i.d. aansluiten en hem in je software dat in een docker-container draait, gebruiken.

[CH4OS]

Ik weet wat de (on)mogelijkheden van Docker zijn, ik gebruik het zelf ook vrij veelvuldig. Maar (industriele) machines moeten het vaak ook doen met beperkte resources en Docker is dan misschien extra (onwenselijke?) overhead.

[joost00719]

Ik werk ook veel met Docker, onze machines draaien vooral op kleine passief gekoelde mini-pc's met een low power Intel chip en 8 GB RAM. Deze machines zijn krachtig genoeg voor Docker.
Voor de rest gebruiken we PLC's met netwerkmogelijkheden die direct communiceren met deze PC's. Ik werk zelf niet met PLC's dus daar kan ik verder niet veel over zeggen. Ik weet alleen wel zeker dat die géén docker draaien

Maar over het algemeen draait Docker op best veel hardware. Als het Linux aan kan, kan het waarschijnlijk ook Docker aan. Een RPi 4 draait het prima. Heb zelfs jaren lang een RPi3 gehad met Docker voor kleine low-power containers zoals VPN. Het deployen was dan wel enorm traag, maar voor de rest prima te doen.

[jeroen3]

Nu nog niet. Hierom misschien straks wel?

[Tjidde]

De machines zelf niet, maar de software die tussen de machines communiceert of monitort kan makkelijk in docker.

[JustFogMaxi]

En die hoort de vendor gewoon up to date te houden...

[DeCo]

Even advocaat van de duivel: waarom?

Zolang die machines niet aan een netwerk hangen, zoals internet, maar enkel onderling verbonden zijn in een gesloten netwerk voor bepaalde processen, dan is het moment dat die machines opgeleverd worden de waarheid en draaien de processen -als het goed is- volgens plan en is zodanig te monitoren, daar waar nodig.
Of anders: waarom up-to-date houden, als het proces gewoon prima is en met een update niet beter van wordt? Onder het mom: if it ain't broke, don't fix it

Zodra de machines op afstand via internet beheerd gaan worden, ja.. dat is een ander verhaal. Maar de software van een machine is niet meer dan een schakelkast, die je ook niet up-to-date houdt als het niet hoeft. Die gaat met de levensduur van de machine mee... zo ook de software.

Anders zou m'n wasmachine elk jaar een nieuwe patch moeten krijgen.. want niet up-to-date

[kaas-schaaf]

Zolang die machines niet aan een netwerk hangen

By design wellicht, maar er komt een moment dat iemand het briljante idee krijgt dit wel te doen.

Bovendien zijn er ook non-connected exploits (zie stuxnet), en bij sommige industriele processen is jezelf beschermen tegen een state-actor wel degelijk onderdeel van je beveiligingsprofielen.

[RogerWilco2]

In de industrie is support voor 30+ jaar gebruikelijk.

Ik heb nog niet zo lang geleden nog support geleverd op een systeem dat communiceerde met 2400/75 baud modems en software uit het vroege Windows 95 tijdperk.

Up-to-date houden klinkt leuk, maar dit draait op een oude Motorolla 68000 met 256 kB RAM.

Ik heb nu een andere werkgever, maar mogelijk draait het systeem nog steeds. Hoefde alleen af en toe een pomp aan te zetten als de stand van het water boven een bepaald niveau komt.

[Reactie gewijzigd door RogerWilco2 op 22 juli 2024 22:11]

[BCC]

Voor dat stukje OS dat tussen de host OS en mijn app zit? Waarvan alleen de poorten op mijn app ge-exposed worden? Waarvan het host OS wel up to date wordt gehouden? Waarom?

[Reactie gewijzigd door BCC op 22 juli 2024 22:11]

[pennywiser]

Dat kan dus straks 12 jaar lang.

[rtxxx]

Voor zakelijke doeleinden kan ik me nog wel bedenken waarom dit handig is maar ik zag dat je als home user ook 12 jaar support kunt krijgen........


Daar is geen enkele zinnige reden voor

[rbr320]

Als thuisgebruiker kan je inderdaad een gratis Ubuntu Pro account aanmaken en 3 systemen koppelen om zo in theorie 12 jaar ondersteuning te krijgen. Dat heeft echter inderdaad weinig nut op je Linux desktop en zelfs voor je thuisserver is het overdreven. Het is puur bedoeld om je geïnteresseerd te krijgen zodat je het professioneel ook gaat gebruiken, waardoor het bedrijf waarvoor je werkt wel een support contact gaat afnemen bij Canonical.

[pennywiser]

Ook op alle gewone Ubuntu LTS releases.

[groene henk]

Leuk, maar Canonical maakt Ubuntu en heeft nog nooit RHEL gesupport. Het is een beetje water en vuur tussen die 2. Dus support wordt dan altijd moeilijk.
Voor support op RHEL containers moeten ze dus wel draaien op Canonical microK8s wat je met een snap bovenop Ubuntu moet installeren. Of nog met Canonicals Openstack eronder.
RHEL gebruikers zitten echt niet op een extra Linux distro te wachten (windows en RHEL naast elkaar is al veel om te onderhouden).
Vervolgens is dan de vraag hoe je die containers op MicroK8s moet managen. Dan kom je weer bij Rancher uit en dan zou ik liever het hele pakket bij Suse kopen (met K3S eronder). Of de alles in 1 solution van RedHat OpenShift.
Dus leuke marketing, maar gaat in de praktijk niet het verschil maken.
Canonical Ubuntu App Pro levert op papier op meer dan 30.000 libraries support (> 23.000 externe libraries).
De Canonical helpdesk weet echt niet wat al die pakketten doen of kunnen daarbij zeker niet helpen om een patch te schrijven.
Het enige wat ze daarbij doen is de bug in de community gooien en hopen voor een snelle oplossing (support by praying). Daar valt dan deze support ook onder.

[Reactie gewijzigd door groene henk op 22 juli 2024 22:11]

[quazar]

Geen idee of dit systeem nog steeds in de lucht is, maar wel een mooi voorbeeld van systemen die jaren blijven draaien: Commodore gebaseerd luchtbewerkingssysteem dat sinds 1980 draait: https://www.woodtv.com/ne...ontrols-grps-heat-and-ac/

[Tivoler]

Niets speciaals aan; ik doe dit dagelijks en lever support zolang het kan.

[blinchik]

Dat is dus een slecht idee. Als je je klanten support blijft aanbieden op een product dat uit support is, gewoon omdat het in een vm of een docker kan draaien, dan gaat het ooit fout. Ooit stoot je op een bug waarbij er data in komt waar geen rekening mee gehouden wordt, dan zit je volledig vast en dan kan je zelf je support niet meer waarmaken. Om nog niet te spreken over security updates.

Eventueel kan je nog wel een paar maanden overbruggen tijdens de overgangsfase, maar als een product EOL is, dan moet je je klant echt verplichten om te upgraden of te veranderen.

[blinchik]

Een voorbeeld, een product dat op WIndows XP draait, kan je bijvoorbeeld niet blijven supporteren. Je kan misschien wel wat truuken uit halen om eens een probleem op te lossen, maar als er bijvoorbeeld een CVE uitkomt, kan je die niet patchen. Je hebt de sourcecode niet en je hebt geen support meer van de leverancier. Wie dat wel beweert, kan beter een andere pet opzetten. Dat is geen onzekerheid, dat is zekerheid.

[Tivoler]

Je kunt alles supporten zoals jij dat wil; heb je een ander echt niet (altijd) voor nodig.

[blinchik]

Vind ik een beetje beangstigend. Docker wordt nu al misbruikt door developers om software niet te moeten upgraden waarbij de systeembeheerder zegt "op deze VM updaten we de libraries". De docker bundelt gewoon oude libraries die niet worden geüpgraded, zo blijft de image vulnerable en als systeembeheerder kan je er weinig tegen beginnen.

Ik denk echt niet dat software na 10 jaar (of korter) nog veilig kan onderhouden worden. CVE's komen uit en die kunnen echt niet allemaal gebackported worden. Canonical heeft nu al packages die soms niet zomaar geupdated worden naar de laatste versie, laat staan dat het binnenkort in docker zit.

[NoTechSupport]

Rustig man. Als je inhoudelijk iets te zeggen hebt, zeg het dan, maar zo'n stoerdoenerij is na je 16de nergens voor nodig.

[Tivoler]

Tja gezien jouw gebruikersnaam en reactie zullen we je maar achterwege laten... wat een niveau als het mensen te heet onder de voeten wordt; Oh wacht het is Tweakers en geen profesioneel netwerk natuurlijk

[blinchik]

Oei oei, wat een boosheid, en zelfs dat nu het eindelijk mooi weer is :-) Heb je verder ook iets inhoudelijk toe te voegen?

Sure, docker heeft voordelen, zeker bij testing. En ja, ik weet dat er systemen bestaan om docker images te voorzien van nieuwe libraries en waar je zelfs een CVE scan kan op doen. Maar eigenlijk, als je die systemen gebruikt zou je eigenlijk ook gewoon packages kunnen bouwen.

Als je outdated software (12 jaar oud) gaat builden, werkt die meestal niet met recente libraries. Dus sowieso zal je met oude libraries zitten binnen je docker image, wat ik hierboven aanhaalde, waar je de CVE's dus niet uitkrijgt. Checkpoint heeft er een leuk blog artikel over geschreven.

[Reactie gewijzigd door blinchik op 22 juli 2024 22:11]

[The Realone]

Dat een image 12 jaar ondersteuning heeft, wil niet zeggen dat je die ook 12 jaar moet draaien. Er zijn prima omstandigheden te bedenken dat je een applicatie met die image voor 10+ jaar kunt ondersteuning op een veilige manier. Containers zijn prima nagenoeg volledig geïsoleerd te draaien en het idee dat is dit microservices zijn, waarbij zo min mogelijk libraries aanwezig zijn.

[Tivoler]

Exact maar veel mensen denken een populaire reactie te hebben dat nieuw altijd beter is; jammer genoeg weten ze dus ook niet hoe hun dagelijkse brood gemaakt word en wellicht maar goed ook omdat ze zouden schrikken van hoe menselijk het eigenlijk is om iets te kunnen vanuit jezelf.

[Tivoler]

As dat dit boosheid noemt lijkt het me lastig om je staande te houden in een harde IT-wereld waar het om resultaten gaat.

Maar laten we even eerlijk zijn; wie begon er nou met een overtrokken reactie op iemand die gewoon zegt dat hij iets kan en doet ?