Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Red Hat neemt CoreOS over voor 250 miljoen dollar

Red Hat, bekend van zijn Enterprise Linux-distributie, heeft een overeenkomst gesloten om CoreOS over te nemen voor een bedrag van 250 miljoen dollar, omgerekend iets meer dan 200 miljoen euro.

CoreOS is op zijn beurt weer bekend van producten als het Kubernetes-platform Tectonic en de Linux-distributie Container Linux, die beide gerelateerd zijn aan het draaien van containerized applicaties. Red Hat meldt dat het met de overname van CoreOS 'klanten in staat wil stellen om applicaties te bouwen en deze in te zetten in elke omgeving met de flexibiliteit van opensourcesoftware'. Containers spelen daarin een belangrijke rol volgens het bedrijf.

De producten van CoreOS zouden Red Hats eigen OpenShift-containerplatform aanvullen; hetzelfde zou gelden voor Container Linux als aanvulling op Enterprise Linux. Die distributie blijft echter de enige Linux-optie van Red Hat, schrijft het bedrijf in een faq. Het integreren van producten van beide bedrijven en het overzetten van klanten moeten in de komende maanden plaatsvinden. Over het open source maken van alle CoreOS-producten moet in de toekomst ook meer duidelijk worden.

Het in 2013 opgerichte CoreOS heeft ongeveer 130 werknemers in dienst en heeft zijn hoofdkantoor in San Francisco. Het in North Carolina gevestigde Red Hat heeft meer dan 10.000 werknemers. Beide bedrijven hebben bijgedragen aan de ontwikkeling van Kubernetes sinds het in 2014 werd aangekondigd door Google.

Door

Nieuwsredacteur

28 Linkedin Google+

Reacties (28)

Wijzig sortering
Mooie ontwikkeling, ik gebruik zowel CentOS (RHEL) en CoreOS vrijwel dagelijks en zijn geweldige stabiele OS'en. Ik denk dat dit voor beide OS'en alleen maar voordelen gaat opleveren.
Mooie ontwikkeling
Nee, dat is het niet.

Red Hat heeft teveel vingers in de pap. De meest prominente ontwikkelaars van D-Bus, systemd en GNOME zitten op de loonlijst van Red Hat. Ansible is van Red Hat. FreeDesktop.org is een sokpop van Red Hat.

Tuurlijk, al die software pakketten zijn de fundering van de services die Red Hat te koop aan biedt en het is begrijpelijk dat Red Hat ook een aandeel in het onderhoud neemt.

Maar langzaamaan gaat het de kant op dat de "de facto standaarden" alleen nog maar compatibel zijn met wat Red Hat goed dunkt. Dat moeten we niet willen.

[Reactie gewijzigd door RoestVrijStaal op 31 januari 2018 21:33]

Dat moet je juist wel willen in een enterprise omgeving. Vergeet ook niet dat Red Hat al zijn producten Open Source't, en je altijd weg kan bij Red Hat. Maar de facto standaarden maken het in een enterprise omgeving net veel makkelijker dan 1001 verschillende (non-)standaarden.
Ik heb nog nooit met CoreOS gewerkt maar ik kom het wel regelmatig tegen. Vanuit mijn positie als Linux beheerder, welke voordelen biedt CoreOS mij voor het beheer van de services die ik oplever (databases e.d.) waar ontwikkelaars dan weer applicaties op bouwen?
CoreOS is èèn van de zoveelste Linux containers.
Nee, helemaal niet, coreos is een minimaal os gericht om containers te draaien, waarbij ze zoveel mogelijk operating system services ook als een container runnen.

Het dient niet als (minimale) basis van je container, zoals bvb een busybox.

Je nodes in je kubernetes cluster draaien zo bvb coreos, en daarbovenop rol je dan je applicaties uit. Het onderliggende os kan je vanuit kubernetes standpunt eigenlijk niet zo heel veel schelen, buiten dat je wil dat alles stabiel is en naar verwachting reageert.

Het voordeel van kubernetes is dat er een defacto standaard is ontstaan, die zowel lokaal te draaien is, als on-premise, als in de cloud, met oplossingen, of op z'n minst structuur om oplossingen in te plaatsen waar enkel containerisatie geen oplossing voor bied. Een frequente waar mensen snel op botsen is storage. Je kan een directory aan een container koppelen, maar dan hang je weer vast aan een machine of locatie, kubernetes schuift daar een abstractie tussen om dit los te koppelen met persistent volume claims die dan geresolved kunnen worden van overal op de cluster.

Slechts 1 van de vele features, andere niet te verwaarlozen zijn natuurlijk de zero downtime deployments, self healing abilities, etc

Aanrader voor mensen die meer willen weten zijn hier 2 entertainende opties: https://deis.com/blog/2016/kubernetes-illustrated-guide/ of https://cloud.google.com/kubernetes-engine/kubernetes-comic/
Dank je voor de duidelijke uitleg.
Bedankt voor je uitleg! Was het al een keer tegen gekomen in de marketplace van GNS3.
Ik gebruik CoreOS voornamelijk icm Docker, puur daarop gefocust draait het op CoreOS out-of-the-box vrijwel direct met minimale configuratie, het is een kleine installatie en gebruikt minimale resources, waardoor je resources beter aan je Docker containers kan besteden. ;)
Okee, maar wat is dan het wezenlijke verschil tussen CoreOS + Docker (of een andere container oplossing) en een minimale installatie van CentOS/Ubuntu + diezelfde container oplossing? Ik kreeg namelijk altijd de indruk dat CoreOS iets wezenlijk anders was dan een minimale Linux installatie om containers op te draaien, maar eigenlijk is het dus gewoon hetzelfde.
Hier ben ik ook benieuwd naar.

Ik draai nu Kubernetes op CentOS, en de hele installatie is scripted met Ansible. Wij installeren een minimale CentOS7 met wat EPEL stuff, Docker, en Kubernetes. Eénmaal een cluster gedeployed is, hoeven we er amper nog naar om te kijken (buiten het installeren van updates).

Wat wordt er in mijn geval gewonnen door CoreOS te gebruiken ipv CentOS7?
Een stukje configuratie gemak. CoreOS ondersteund bijvoorbeeld bootstrapping door middel van Cloud-Init, en het heeft een etcd installatie ingebouwd. Hierdoor hoef je zelf een hoop dingen niet meer te onderhouden, en hoef je alleen maar updates voor CoreOS te installeren, en niet je Ansible cookbooks bij te houden qua updates van systemen.

Bovendien bevat CoreOS een (veel) nieuwere kernel dan CentOS7. Daardoor is de performance van je containers weer een stukje beter.
Goh, het kernel stuk heb ik met ElRepo al lang opgelost.

Nu Redhat waarschijnlijk de enterprise adoptie van CoreOS wat zal bespoedigen moet ik er toch maar eens naar beginnen kijken.
(buiten het installeren van updates)
Daar gebruik je toch yum-cron voor, of unattended-updates op Debian-gebaseerde Linux systemen?

[Reactie gewijzigd door rbr320 op 31 januari 2018 16:33]

Ja, maar Container Linux (de CoreOS distributie) houdt daarbij rekening met het feit dat het in een cluster draait. Zo kan de auto update er bijv. rekening mee houden dat, wanneer worker-nodes in een cluster allemaal geupdate en evt. herstart moeten worden, er altijd een bepaald deel van de nodes beschikbaar blijft zodat bijv. je etcd quorum in orde blijft en er genoeg capaciteit voor containers beschikbaar blijft. Soort rolling-updates dus. Ze gebruiken daarvoor een 'lock' in etcd.

Daarnaast gebruikt Container Linux een dual-partition methode zodat updates atomair kunnen worden uitgevoerd en een volledige rollback mogelijk is.

Het OS is verder read-only gemount met zoveel mogelijk applicaties in afgeschermde containers, wat het platform moeilijker maakt om in te breken.
Dit is overduidelijk een actie van Redhat om de concurrentie uit te schakelen voordat ze echt voet aan de grond krijgen. Het voordeel voor Redhat is dat CoreOS met Tectonic nog wat dingen doet die Redhat nog niet goed heeft met OpenShift en CloudForms maar je kunt nu wel al op je klompen aanvoelen dat CoreOS en Tectonic gewoon verwerkt gaan worden in die 2 producten en zullen verdwijnen.

Dus het is voor een deel wel slecht omdat er weer een keuze minder is. Er zijn organisaties die de keus maken om niet met Redhat te werken maar wel een supported scenario nodig hebben. Die organisaties komen nu van een koude kermis thuis. Want wat moet je nu nog kiezen?

[Reactie gewijzigd door PulsatingQuasar op 2 februari 2018 08:39]

Mooie ontwikkeling. Red Hat levert puike Linux distributies. Fedora staat bij mij al lange tijd bovenaan als favoriete gratis Linux distributie.

De nieuwste pakketten en uiterst stabiel en met de nieuwste security features zoals SELinux en Secure boot. Daar kan Debian nog heel wat van leren met hun trage updates en langzame ontwikkelingen.

Benieuwd wat deze overname aan nieuwe ontwikkelingen zal gaan betekenen.

[Reactie gewijzigd door CR2032 op 31 januari 2018 18:26]

De nieuwste pakketten en uiterst stabiel en met de nieuwste security features zoals SELinux en Secure boot. Daar kan Debian nog heel wat van leren met hun trage updates en langzame ontwikkelingen.
Je kon er niet verder naast zitten. Simpel gezegd:
RHEL = Debian Stable maar dan minder actuele software versies
Fedora = Debian Testing en misschien zelfs wel Debian Unstable.

Zowel RHEL als Debian Stable zijn gericht op het bedrijfsleven en lopen daardoor behoorlijk achter op software versies. Dat komt doordat men hier voor stabiliteit en veiligheid gaat waardoor dingen langer en intensiever worden getest. Als je deze versies met Fedora vergelijkt dan lopen ze inderdaad achter. Zoals je in het lijstje al wel kunt zien kent Debian dezelfde varianten alleen noemen ze het weer net even anders omdat hun aanpak, drumroll...net even anders is.

Om toch ook iets te kunnen doen voor mensen die een desktop willen hebben met actuele software versies is er bij Red Hat Fedora en bij Debian Unstable (of Testing wanneer het iets minder actueel kan). Maar als je dan toch echt wat wil leren wat actueel is dan ga je natuurlijk voor een rolling release van bijv. SUSE of Arch. Die lopen pas voor op de rest ;)

De reden waarom velen juist voor Debian kiezen is de traagheid van updates en ontwikkelingen bij Red Hat, dus exact andersom als jij stelt. Een andere reden is de eenvoudige wijze om naar een nieuwe versie van Debian te upgraden, dat doen ze bij Red Hat net eventjes iets minder. Voor de rest zijn het tegenwoordig allemaal hele kleine details. Er is de laatste jaren aardig wat aan standaardisatie bij de Linux distro's gedaan.

Wat ik echter in je verhaal mis is een ander belangrijk stukje die juist voor dit nieuwsbericht van toepassing is: project Atomic van Red Hat. Atomic is de Red Hat versie van CoreOS (als in Container Linux, niet als in het bedrijf). Zij waren met Atomic volledig afhankelijk van andere partijen zoals Docker. Met de aankoop van CoreOS is dat niet meer (op Kubernetes na dan). Naast CoreOS hebben ze nu ook etcd, Clair, rkt (een tegenhanger van Docker) en Quay (een registry voor container images). In feite concurreren ze nu Docker de tent uit als je alleen naar de productportfolio kijkt. Juist dat gegeven wordt interessant. Wat gaat er nu met rkt en met Docker gebeuren?

Btw, om nou SELinux als voordeel te noemen...het wordt en masse direct na (of tijdens install) al uitgeschakeld. Dat secure boot is eenzelfde liedje, dat komt uit de Microsoft hoek en kent een fikse discussie.
Waarom wordt SELinux direct uitgeschakeld?
Omdat mensen continu tegen issues aanlopen en SELinux moeten afstellen. Dat wordt vaak als "te lastig" ervaren waarbij het niet opweegt tegen het stukje extra security die het oplevert en men het dan maar uitschakelt.

Het draait overigens wel op Debian: Debian SELinux support. Zoals je daar al kunt lezen staat het echter standaard uit.

[Reactie gewijzigd door ppl op 31 januari 2018 23:04]

mensen die selinux uit zetten... sjongejonge... is een beetje alsof je de voordeur van je huis maar openzet zodat je je sleutelbos dan lekker binnen kan laten liggen.

anyway, je kan gewoon met 1 commando je eigen selinux policy maken als dat nodig zou zijn.

dacht dat debian based systems apparmor als tegenhanger van selinux gebruikten.. of is dat enkel ubuntu?
Dat is minder erg dan mensen die denken dat je met 1 tooltje (lees: SELinux) meteen een compleet veilige omgeving hebt ;) De realiteit is heel anders. SELinux is maar een tool uit velen (je noemt nota bene zelf al een alternatief op) en security is een compleet plan op diverse lagen waarbij je dus diverse tools gebruikt en diverse policies instelt. Hierbij is het van essentieel belang dat je een risicoanalyse hebt. Op basis van die analyse bouw je namelijk je hele security op. Als uit die analyse blijkt dat de security issues die je met SELinux dicht bar weinig voorkomen en door de andere maatregelen weinig effect hebben dan ga je kijken of het de moeite van het instellen waard is. Dat is vaak waarom dingen sneuvelen: teveel moeite, teveel geld voor iets wat te weinig oplevert (waarbij men dan ook de bekende 80-20 regel van stal haalt).

SELinux uit op een machine die een testbak is die je continu in puin helpt...hoe groot is het risico dat daar iets mee gebeurd waarvoor je een melding bij het AP moet maken? Levert dat een voordeel op tov de moeite die je er voor moet doen? Is het überhaupt zinnig om daar zoiets in te stellen als de scope alleen maar het testen van bepaalde zaken en/of het opdoen van bepaalde kennis is? Ja, je kunt SELinux erbij pakken maar daarmee maak je een project ineens heel erg groot...redt je dat met de tijd?

AppArmor is net als SELinux onderdeel van de kernel zelf en tevens ook de grote concurrent. Vroegah werd deze vooral als alternatief naar voren geschoven omdat het eenvoudiger was dan SELinux. Geen idee of dat nu nog zo is.

Klakkeloos dingen inschakelen en met 1 commando een policy aanmaken is nou ook niet bepaald verstandig. Dit is nou echt iets waar je over na moet denken omdat je anders heel veel kunt slopen.

En tot slot is er nog de harde werkelijkheid: software support. Als de software niet met SELinux overweg kan zul je toch echt iets anders moeten gaan verzinnen. Uitschakelen van SELinux is 1 van de opties die je hebt.
gaat mij vooral om de massa's tutorials (en adviezen in fora) die beginnen met: "zet selinux als eerste uit want dat is toch maar lastig." juist met name wordt dit advies aan veel nieuwkomers gegeven. is echt het verkeerde signaal afgeven.

je kan en mag er van uit gaan dat alle packages in de repo van het OS zelf getest zijn en werken met de meegeleverde policies dus er is, totdat je echt zelf buiten je eigen repo om iets gaat zitten vogelen, echt geen enkele reden om defaut selinux uit te zetten.
Je slaat hier nu zelf de plank mis.

Vuistregel is dat Debian Stable ongeveer 5 jaar achter loopt op Fedora;
Debian Unstable loopt ongeveer 1 jaar achter op Fedora.
Stable bij Debian is ook een foute naam, Debian Freeze zou het beter heten. Je krijgt geen bug fixes of nieuwe versies, dat is allemaal bevroren, alleen security updates.

Dat je Red Hat beticht van trage updates en Debian niet slaat nergens op en is de wereld op zijn kop zetten. Red Hat levert de grootste bijdrage aan de Linux kernel en nieuwe ontwikkelingen. Wat nu in Fedora zit zie je pas over pakweg 5 jaar terug bij Debian.

Net zo vreemd zijn je opmerkingen over SELinux en Secure boot. Beiden staan standaard aan in Fedora en werken uitstekend en zijn een must in de beveiliging voor een moderne desktop met alle internet bedreigingen van nu. Net zoals Fedora standaard een firewall ingeschakeld heeft staan. Ga je die soms ook uitzetten omdat het te ingewikkeld wordt? Wil je geen gebruik maken van de Microsoft keys voor Secure boot dan maak je die gewoon keys zelf aan.

Blijkbaar zie je dit als kritiek op Debian. Het is geen kwestie van welke beter of slechter is, maar waarvoor je het gebruikt. Debian of CentOS van Red Hat gebruik je voor servers. Fedora/Korora of Ubuntu/Mint op een desktop. Wil je een rolling release dan is er ook Fedora Rawhide.

[Reactie gewijzigd door CR2032 op 1 februari 2018 20:50]

Goed, basiszaken als release management, package maintainers, repositories en het feit dat er diverse soorten manieren zijn om software te installeren zijn jou dus volledig onbekend. M.a.w. je voert nu een discussie die boven je kennisniveau zit en dat los je nu op door een persoonlijke aanval en zaken die voor geen meter kloppen. Je vuistregel bestaat namelijk niet, je uitspraak over bugfixes is niet correct (als je er ook maar even een seconde aan had besteed kun je zelf ook wel bedenken waarom), CentOS is niet van Red Hat (ze gebruiken alleen de open source broncode van ze en maken er een eigen distro van; Scientific Linux en Oracle Linux doen exact hetzelfde) en ik beticht Red Hat ook nergens van (en anderen ook niet).

Het hele punt van actualiteit van software op een distributie is er eentje die nergens op slaat. Er zijn package maintainers die van software een pakketje moeten maken voor de distributie waar ze het werk voor doen (hoewel dat niet voor allen op gaat, denk aan pkgsrc, een systeem bedoeld voor diverse operating systems). Dat werk is afhankelijk van hun drukte en complexiteit (de ene distro is nog steeds niet de ander hoewel tegenwoordig veel hetzelfde is). Gevolg: de ene maintainer heeft zijn package sneller naar de nieuwste versie dan de ander. M.a.w. het verschil in actualiteit tussen distro's fluctueert nogal. Waar de een actueel is op pakket a is de ander dat weer op pakket r. Daar zit soms een bepaalde lijn in waardoor bepaalde mensen voor een bepaalde distro kiezen. Dat heeft niets met betichten te maken.

Het meest belangrijk bij software is release management. Al helemaal bij systemen als CoreOS (Container Linux), RHEL, SLES, Debian Stable, CentOS, enz. Deze zijn gericht op stabiliteit en veiligheid want dat zorgt ervoor dat dingen niet alleen voorspelbaar en veilig zijn maar ook dat het domweg werkt. Dat is namelijk overeenkomstig met de eis van de gebruikers (=over het algemeen bedrijven, systeembeheerders). Juist die groep kan het aan hun reet roesten welke versie van pakket a of r er op het systeem staan. Niet alleen omdat het gewoon moet werken maar ook omdat zij wel over de kennis beschikken hoe ze dit soort software via andere kanalen op het systeem kunnen krijgen. Je hoeft dus niet eens een bepaalde distro te gebruiken en dat is maar goed ook anders krijg je een willekeur van distro's omdat pakket a op de ene de nieuwste is en r op de andere.

Dat je dingen in Fedora ziet die je later pas bij distro's als Debian, RHEL, enz. ziet is ook niet zo raar. Het hele doel van Fedora is het zijn van een experimentele distro. Je kunt daar van alles en nog wat uitproberen voordat het misschien ooit (met een hele grote nadruk op misschien ooit!) in RHEL komt. SUSE heeft exact dezelfde methodiek. Bij Debian is dat dus het hele rijtje van Stable, Unstable en Testing.

Wat het SELinux betreft: zoals je in de officiële documentatie al kunt lezen zit dat gewoon in de kernel zelf. Dat is dus niet specifiek een Fedora feature. Of het ook een handige feature is valt te bezien aangezien velen het uitschakelen vanwege problemen (en ja er zijn nog steeds stukken software die hier niet mee compatible zijn). Dat uitschakelen is ook niet zo'n drama als wat jij er van maakt. Security behelst nou eenmaal aanzienlijk meer dan dat alleen. Gek genoeg is release management door ook onderdeel van.

Een ander ding die ik hier mis is kennis over CoreOS, zowel als bedrijf als het OS. We hebben het hier over een firma die allerlei zaken ontwikkeld op gebied van containers. Hun OS is dan ook helemaal gestript zodat er een minimaal systeem overblijft om de containers te kunnen draaien en beheren. Dit uit oogpunt van security maar ook beheercomplexiteit (dat wat er niet is hoef je ook niet te beheren) en schaalbaarheid. Het hele idee bij containers is dat het onderliggende OS er totaal niet aan toe doet. Daarmee vervallen ook al je argumenten (SELinux is en blijft discutabel). Bij containers zit namelijk alles al in de container zelf en die draaien, vanwege overhead, vaak Alpine Linux (hoogstens 5MB ipv 300~500MB voor iets als Debian, Ubuntu, CentOS of RHEL). Daarmee is het dus niet meer de systeembeheerder die de softwareversies beheert maar de developer. Die levert ze door de container technologie standaard met de containers mee. Voordeel is wederom het feit dat dingen dan gewoon werken en je geen last hebt van allerlei versieconflicten. In dit hele segment had Red Hat al een hele grote vinger in de pap. Deze overname is niet zo heel veel meer als een kers op de taart.

Heb je überhaupt wel een idee waar je op reageert? Vanwaar al die drama? Nergens voor nodig.
Dat is bijna 2 miljoen per weeknemer. Niet misselijk.
Gaat denk ik vooral om het product, merknaam en klanten
Denk dat de human resources wat ze hiermee overnemen ook interessant is, niet bepaald makkelijk te vinden mensen met deze skills en expertise in de huidige markt.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S9 Google Pixel 2 Far Cry 5 Microsoft Xbox One X Apple iPhone 8

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*