Docker Desktop wordt betaalde tool voor bedrijven met meer dan 250 medewerkers

Docker gaat via enkele nieuwe abonnementsvormen geld vragen voor het gebruik van Docker Desktop voor bedrijven met meer dan 250 medewerkers en een jaaromzet van meer dan 10 miljoen dollar. Individuele ontwikkelaars kunnen Docker Desktop gratis gebruiken.

Docker introduceert vier verschillende abonnementsvormen. Personal, bedoeld voor individuele ontwikkelaars, onderwijs, opensourcegemeenschappen en kleine bedrijven, vervangen het huidige Docker Free-abonnement.

Alle andere abonnementen zijn betaald: Pro voor individuele ontwikkelaars, Team voor teams van meer dan vijf ontwikkelaars en het nieuwe abonnement Business voor bedrijven met meer dan vijftig gebruikers. De prijzen zijn omgerekend respectievelijk 5,93 euro, 7,63 euro of 17,79 euro per gebruiker bij een maandelijks opzegbaar abonnement. Pro en Team zijn goedkoper bij een jaarabonnement. Dan komt de prijs uit op respectievelijk 4,24 euro per maand en 5,93 euro per maand per gebruiker.

Het gratis abonnement, dat toegang geeft tot de gratis Docker Desktop-app, is nadrukkelijk bedoeld voor kleine bedrijven met minder dan 250 medewerkers en omgerekend minder dan 8,5 miljoen euro jaarlijkse omzet, voor persoonlijk gebruik, voor educatie en voor niet-commerciële opensource-projecten. Vanaf 31 augustus moeten gebruikers die niet aan deze voorwaarden voldoen en Docker Desktop gebruiken volgens de nieuwe Subscription Service Agreement een betaald abonnement afsluiten. Wel zegt Docker dat er tot 31 januari 2022 een respijtperiode geldt, waarbinnen het nog niet handhaaft.

Kleine bedrijven, individuele ontwikkelaars, ontwikkelaars in het onderwijs en opensourcegemeenschappen zijn samen goed voor meer dan de helft van de Docker-gebruikers, legt het bedrijf uit. Zij kunnen blijvend gratis gebruik maken van alle Docker-tools, waaronder Docker CLI, Docker Compose, Docker Build/BuildKit, Docker Engine, Docker Desktop, Docker Hub en Docker Official Images.

Het nieuwe Docker Business-abonnement geeft organisaties de mogelijkheid om op schaal gebruik te maken van Docker met een managementplatform voor IT-beheerders en uitgebreidere tools om te beheren welke gebruikers welke images kunnen openen vanuit de Docker Hub. Daarnaast krijgt Docker for Business binnenkort SAML SSO, waardoor beheerders kunnen beheren tot welke registries ontwikkelaars toegang hebben en waarmee op afstand Docker Desktop-instanties beheerd kunnen worden.

Reacties (186)

[jrswgtr]

Zijn er veel tweakers die de Docker desktop app gebruiken? Heeft het meerwaarde boven containers aanmaken / opstarten via de terminal?

[wackmaniac]

Voor zover ik weet is het op Mac/Windows niet mogelijk om Docker te installeren zonder Docker Desktop. Dus het heeft wel een aardig impact als je om die besturingssystemen zit.

[Reactie gewijzigd door wackmaniac op 23 juli 2024 03:51]

[Anoniem: 162126]

Die impact is er alleen als je meer dan 8.5 miljoen/meer dan 250 medewerkers in de organisatie hebt.

[casberrypi]

8.5 miljoen omzet is maar weinig. Bedenk dat als iemand 50.000 euro bruto kost je van die omzet dus maar 170 mensen salaris kunt betalen. Met andere kosten en marges is 8.5 miljoen omzet met 100 mensen voor een Nederlands IT bedrijf realistischer dan 250 mensen.

[Anoniem: 162126]

Maar wat wil je daar mee zeggen? Dat ze bij Docker voor niks moeten blijven werken omdat jij 8,5 miljoen weinig omzet vindt?
Ik vind het een redelijke deal eerlijk gezegd. Als ZZP’er betaal ik ook jaarlijks voor mijn Jetbrains abo. Het is gewoon een tool waar ik mijn brood mee verdien.

[casberrypi]

Nee, dat zeg ik niet. Ik heb privé de jetbrains ultimate. Ik betaal heel graag voor software, omdat ik als developer ook graag betaald wordt.

Ik zeg dat het in Nederland dus al gauw het geval is dat je moet gaan betalen als je het wilt gebruiken. Daar heb ik geen enkel probleem mee.

[Anoniem: 162126]

Dat had ik verkeerd begrepen!

[supersnathan94]

Docker verdient gewoon geld met docker enterprise. Dat is de daadwerkelijke laag waar productie servers op draaien. Dingen als clustering dmv docker swarm of kubernetes en een eenduidige control plane.

Docker desktop is dan ook een applicatie die je gebruikt specifiek om te ontwikkelen voor die productieomgeving. Zou dan dus ook part of the deal moeten zijn vind ik zelf.

Hiermee schieten ze zichzelf behoorlijk in de voet, want men gaat nu zeker kijken naar gewoon plain K8S zodat je bijvoorbeeld met K3S lokaal kunt ontwikkelen (open source en gratis in gebruik)

[Anoniem: 162126]

Ik weet niet waar je het idee vandaan haalt dat docker gewoon geld verdient met docker enterprise. Ze zijn nog niet winstgevend geweest. Vwb het in de voet schieten kan wel eens meevallen. Kubernetes zie ik niet als een waardig alternatief.

edit: linkje met bron voor financiële situatie van docker:
https://www.zdnet.com/article/docker-is-in-deep-trouble/

[Reactie gewijzigd door Anoniem: 162126 op 23 juli 2024 03:51]

[Robby517]

Kun je verklaren waarom je Kubernetes geen waardig alternatief vindt? Bij mijn weten is de aantrek er van net dat Docker Enterprise geen waardig alternatief voor Kubernetes is.

[Anoniem: 162126]

Mijn probleem met kubernetes is de planet scale. 90% van de applicaties heeft geen planet scale nodig. Geen service discovery en of complexe distributed configuratieservers. Het is overkill maar vele malen complexer opzetten. De huis tuin en keuken applicatie heeft genoeg aan een database, applicatieserver en webserver. Dat is met docker-compose relatief eenvoudig. Met kubernetes is heb je er ineens tig problemen bij.

Maar lang verhaal kort, ik kan voor development en productie prima uit de voeten met docker en heb geen toegevoegde waarde bij een overstap naar kubernetes vanwege de extra complexiteit die ik heel niet nodig heb.

[GewoonWatSpulle]

Hoe krijg je er ineens tig problemen bij als je enkel van docker-compose naar kubernetes deployment gaat? Je hoeft niet perse een cluster op te zetten, je hoeft niet perse meerdere replicasets in te richten? Het kan wel maar je bent nergens verplicht.

Misschien een iets té simpel voorbeeld maar laten WordPress als voorbeeld pakken docker-compose vs. kubernetes, is toch eigenlijk hetzelfde maar ander taaltje?

Edit: en als je het allemaal makkelijker wilt maken voor jezelf kijk eens naar wat Helm Charts voor je kunnen doen.

[Reactie gewijzigd door GewoonWatSpulle op 23 juli 2024 03:51]

[supersnathan94]

Geen geld verdienen en niet winstgevend zijn, zijn twee verschillende dingen. Docker enterprise kost gewoon serieus geld. Vanaf $750/node/jaar. Loont het dus wel om grotere machines te gebruiken, maar als je dat dus vergelijkt met cloud is het helemaal niet zo goedkoop. Je betaald immers ook voor alles wat standby staat.

[Anoniem: 76058]

Die impact is er alleen als je meer dan 8.5 miljoen/meer dan 250 medewerkers in de organisatie hebt.

Docker Desktop begint ook meer en meer commerciële "oplossingen" te pushen. Image viewing is ook zo een betaalde optie van Docker Desktop ( WSL2/Windows), dat nogal grondig gepushed word door Docker uit in de interface. Is 1 van de redenen ( naast het onzinnige geheugen gebruik ) dat Docker Desktop eruit gevlogen is bij mij.

Er zijn genoeg alternatieven ( oa podman ) om containers te draaien dat niet zo pushy zijn.

[Anoniem: 162126]

Ik was zwaar geïrriteerd door de dagelijkse popup met nieuwe versies. Dat zijn nare praktijken, maar ze moeten wel gezien de financiële situatie waar ze in zitten. podman is voor mij (nog) geen alternatief. Heel kubernetes erger ik me groen en geel aan.

[supersnathan94]

Ja maar dat zijn dus serieus een hoop bedrijven.

Denk daarbij aan bedrijven zoals rabobank, kadaster, ING, de belastingdienst. Gebruiken allemaal wel docker desktop.

Ook niet overheid dus.

[DigitalExorcist]

Die verdienen dan ook geld zát om zo'n tool te kunnen betalen.

[Polydeukes]

Is dat het argument? Wat denk je dan van 't onderwijs?

[kevints]

onderwijs is uitgesloten van deze wijziging. Dit staat in de mail die ik gisteren heb ontvangen:
"The existing Docker Free subscription has been renamed Docker Personal. Docker Desktop remains free for personal use, education, non-commercial open source projects, and small businesses (fewer than 250 employees AND less than $10M USD in annual revenue)"

[supersnathan94]

Ja ho ff. Daarmee bedoelen ze dus waarschijnlijk “educational purposes”. Als jij als bedrijf producten ontwikkelt voor onderwijs doeleinden (denk daarbij aan Malmberg of Topicus edu) dan zit je niet in die groep. Voor scholen is het dus toegestaan om docker desktop te gebruiken voor lessen (zodat je niet voor al je docenten licenties hoeft af te nemen), maar voor leveranciers niet.

Die rekening komt uiteindelijk wel weer bij de onderwijsinstanties uit.

[kevints]

Tsjaa, zo komt de boete van Volkswagen's sjoemelsoftware uiteindelijk ook bij de klant terecht. Zo kunnen we alles wel doorrekenen naar een eindgebruiker

[supersnathan94]

Jazeker. En dus heeft het impact.

Al met al vind ik dit een zeer kwalijke stap. Voor een bedrijf met 1000 medewerkers heb je ineens een kostenpost van $21K per maand extra aan je broek voor niks.

Daar kun je echt een serieus cluster voor draaien hoor.

[alienfruit]

Ik moet het eerste bedrijf nog tegenkomen dat 1000 medewerkers heeft en ook Docker gebruikt op alle computers van deze medewerkers. Bij de bank waar ik werkte in Londen was dit in ieder geval niet het geval was al moeilijk genoeg om de windows policies te krijgen om het te kunnen installeren

[supersnathan94]

Oke. Met die duizend medewerkers bedoel ik dus duizend developers. Overig personeel laat ik dan buiten beschouwing. Mijn huidige opdrachtgever komt daar denk ik wel aan.

Misschien wat realistischer scenario is 500 developers. Nog steeds $10,5K in de maand.

[alienfruit]

Het is lullig maar als je 500 ontwikkelaars hebt en de daling in productiviteit door het niet kunnen gebruiken van Docker desktop kost je misschien wel meer dan die $10,5K. Verder is $10.5 voor 500 ontwikkelaar niet zo veel in vergelijking tot de salariskosten

[brobro]

10K is best geld, maar alles is relatief. Wat kosten 500 developers? Waarschijnlijk minstens 3 miljoen per maand aan salarissen, premies, kantoren, apparatuur, opleidingen, reiskosten, en dan gaat het nog niet over managers, HR en whatnot. 10K/3M is een kostenstijging van wat? 0,3%?

[GeroldM]

Oke. Met die duizend medewerkers bedoel ik dus duizend developers. Overig personeel laat ik dan buiten beschouwing.

Dat mag jij dan buiten beschouwing laten, maar doet Docker dat ook? Kon dat niet uit het artikel halen, dus ga ik er maar van uit dat het over totaal aantal werknemers gaat, niet alleen developers als in het 'Hope for the best, prepare for the worst'-concept.

[supersnathan94]

Het “wanneer moet ik betalen” zal zijn vanaf 250 medewerkers. Dus als je duizend medewerkers hebt moet je gaan betalen. Ook al heb je maar 10 man die het daadwerkelijk gebruikt. Je zal dan ws alleen voor die tien een licentie af hoeven te nemen.

[casberrypi]

Ja, als je 1000 gebruikers hebt in docker desktop, niet met 1000 medewerkers.

[Reactie gewijzigd door casberrypi op 23 juli 2024 03:51]

[acemoo]

quote: https://www.docker.com/blog/updating-product-subscriptions/

Docker Desktop remains free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.

Waar haal jij die docker desktop gebruikers vandaan?

[Reactie gewijzigd door acemoo op 23 juli 2024 03:51]

[DdeM]

https://www.docker.com/pricing

"Team 5+
Ideal for teams and includes capabilities for collaboration, productivity and security.
$7/user/month
Start with minimum
5 users for $25."

"Business 50+
Ideal for medium and large businesses who need centralized management and advanced security capabilities.
$21/user/month"

[supersnathan94]

Voor de noodzaak om te moeten betalen gaat het wel over het totaal aantal medewerkers. Dus als je 251 medewerkers hebt en 10 daarvan zijn ontwikkelaar dan ben je dus wel de sjaak en moet je wel voor die 10 een licentie afnemen.

[Falcon]

Die bedrijven zijn dan commercieel bezig en zullen dit dan ook prima kunnen betalen of door moeten gaan berekenen.

[Robby517]

Ook daar weer: enkel die toeleveranciers die meer dan 250 medewerkers hebben, dus dat zal best meevallen.

[supersnathan94]

Of 10 miljoen omzet draaien. En als je dan even kijkt naar een beetje bedrijf in die sector dan zit je daar echt zo hoor.

De bedrijven die ik noemde doen dat met gemak.

[Nystran]

Die rekening komt uiteindelijk wel weer bij de onderwijsinstanties uit.

Wat moeten ze dan? Rabobank een gratis licentie geven voor de docker desktop omdat scholen ook een rabobank rekening hebben? Natuurlijk willen ze dat mensen op school Docker leren gebruiken, want eenmaal afgestudeerd... maar kunnen we alsjeblieft het onderwijs ook gewoon zien als een volwassen sector die voldoende budget krijgt om kwalitatief hoogwaardige producten in te kopen, en niet een soort derdewereld land wat zielig is en gesubsidieerd moet worden?

[supersnathan94]

Wat moeten ze dan?

Stoppen met dit soort onzin en niet laten betalen voor de tooling (die helemaal niet zo goed is dat het het ook daadwerkelijk waard is) voor een platform waar je ook voor betaald!

Docker enterprise is namelijk ook helemaal niet goedkoop. Doe dan daar je licenties duurder maken oid.

[Polydeukes]

Ah, da's een goede aanvulling. Heb ik overheen gelezen.

[DonJunior]

Personal, bedoeld voor individuele ontwikkelaars, onderwijs, opensourcegemeenschappen en kleine bedrijven, vervangen het huidige Docker Free-abonnement.

Eerste alinea..

[alienfruit]

Wat als je omzet is $10M USD maar 230 medewerkers hebt?

[vanthome]

Als je goed leest zie je dan ook AND staan. Dus je moet aan allebei voldoen.

[supersnathan94]

Je begrijpt wel dat die kosten gewoon doorberekend worden aan de klant?

[JustFogMaxi]

Met WSL2 kun je gewoon linux docker installeren.

[zordaz]

Ik was ook in dezelfde veronderstelling als @wackmaniac. Is dat veranderd dan?

[afterburn]

Nee. Onder WSL2 kun je gewoon docker draaien zoals op Linux. Maar WSL heeft ook ondersteuning voor integratie met Docker Desktop en containers die draaien op docker linux onder WSL.

Maar als je die GUI integratie niet nodig hebt/wilt, kun je gewoon je apt/dnf install docker-ce doen en gaan.

[base_]

Saillant detail: docker draait veeeeeel sneller op WSL

[jkommeren]

Nog een saillant detail:
Porten forwarded vanuit docker in WSL is veeeeeel ingewikkelder 😔

[yeep]

Maar kun je onder WSL ook automatisch startende containers hebben? Ik draai een MariaDB in Docker op mijn laptop. Onder Windows start deze automatisch op. Van wat ik tot nu toe gevonden heb over Docker op Windows onder WSL is dat je zelf elke keer de containers moet starten.

[afterburn]

Dat gebeurt standaard niet nee, maar kan in principe wel. Kan dat nu niet volledig uittikken zo m'n telefoon, maar je kunt oa:

1) een shortcut maken naar wsl met een commando voor het starten van je container en deze automatisch laten starten. Je containers lopen dan al op de achtergrond voordat je de shell start.
2) systemd bottle draaien in wsl dmv BV genie zodat je Linux services kan laten starten etc zoals een normale install dat doet. Je containers starten dan als je wsl start.

[vpm]

Ik ben recent verhuisd van een Linux omgeving naar Windows en kwam er heel pijnlijk achter dat gewoon IP routing 'echt heel moeilijk' is voor Windows, omdat de host geen idee heeft hoe het de interne ipadressen van WSL moet bereiken.
Ik was in de veronderstelling dat je Docker Desktop nodig zou hebben voor de koppeling tussen de containers in WSL2 en je host machine. Is dat onder CLI wel stabiel te regelen (zonder tussenkomst van allerlei toevoegingen aan je env)?

[afterburn]

Je kunt services draaiend onder WSL gewoon bereiken op localhost:poort, mits de firewall goed staat. Met andere woorden, als je een webserver hebt draaien op poort 80 in WSL2 kun je met je webbrowser naar http://localhost gaan en dan werkt het.

Note: Services moeten wel luisteren op 0.0.0.0.

[Reactie gewijzigd door afterburn op 23 juli 2024 03:51]

[vpm]

Ik ga er nog eens mee spelen. Thanks.

[Cobalt]

alleen de engine blijft ongewijzigd

[Reactie gewijzigd door Cobalt op 23 juli 2024 03:51]

[Pieterll]

Op MacOS kun je eventeel ook https://multipass.run/ gebruiken. Alhoewel Docker Desktop wel aanzienlijk laagdrempeliger is.

[Berlinetta]

Draait gewoon in een VM, maar is wel handig.

[Pieterll]

Het gebruikt HyperKit, waar Docker ook op draait. Dus ondanks het een VM is, gebruikt het wel een Hypervisor.

[Martinspire]

Het is laagdrempelig, maar ook vrij nutteloos imo. Ik vind het een vrij omslachtig programma voor wat het doet en bevat veel te weinig functies om die containers een beetje handig te managen. Je moet alsnog vrij snel een terminal starten om ook maar wat te doen of te zien wat je container doet.

[Reactie gewijzigd door Martinspire op 23 juli 2024 03:51]

[bassekeNL]

Voor mensen die net beginnen met docker, of er niet dagelijks mee werken, is het enorm handig. Je kunt namelijk zien wat er gebeurt en wat er draait, zonder dat je meteen naar een command line hoeft te grijpen.

Als je ermee bekend bent, en de commando's in je vingers hebt, dan heb je aan een kale versie genoeg.

[Martinspire]

Volgens mij kun je alleen zien wat er draait, niet wat er gebeurd. Ja 2 regels als ie aan het opstarten is en live gaat, maar voor meer info moet je toch al snel verder kijken. En zoals ik al elders had aangehaald heeft elke container weer zijn eigen manier van werken. Veel uniformiteit zit er niet in. Menig container laat zich ook niet starten via desktop, dan moet je toch al wat configuratie-velden meegeven. Die ondersteuning biedt de desktop niet.

[Anoniem: 76058]

Tip: Podman ... Is de Docker alternatief van redhat. Docker containers zijn niets speciaals, het zijn gestandaardiseerde containers, dat kunnen draaien onder andere runtimes. k8 draait ook geen docker, ondanks dat het "docker" containers gebruikt.

Podman is an OCI-compliant container runtime that works without a daemon. The CLI implements all the core Docker commands. You can easily transition to Podman or use it alongside an existing Docker installation. Unlike Docker, Podman has first-class support for managing multiple containers.

Het probleem met Docker is dat je de een daemon nodig hebt dat niet mooi draait met WSL2.

Docker Desktop is gewoon een ramp voor je geheugen. Het werkt, ja ... Maar het draait 2 extra Hyper-V instances, dat elk gigabytes van data opslorpen omdat dit niet gedeeld is en elk hun eigen cache draaien.

Nadat ik Docker Desktop eraf gesmeten heb, gebruik ik nauwelijks 2/10 van hetzelfde geheugen door de apps onder podman te draaien of native.

Docker is al een tijdje de verkeerde richting aan het uitgaan en het word meer en meer tijd voor alternatieven te gaan promoten zoals podman enz...

[supersnathan94]

Hmm zal er eens naar kijken. Klinkt wel interessant. Vooral ook het resource gebruik.

Als ze een mac client hebben dan is dat wel handig. Docker desktop draait namelijk nog een VM die direct reserveringen doet. Heb je gewoon 8Gb weg als je af en toe zware omgevingen moet starten maar de rest van de tijd een beetje met mongo zit te klooien oid.

[martenjacobs]

Ik heb zelf onder macOS docker via rancheros draaien binnen Parallels en de docker cli daarmee verbonden. Docker desktop is dus niet strikt noodzakelijk.

[Blaise]

Op macOS is Docker CLI helaas ook onderdeel van Docker Desktop. Je kan wel de CLI tool uit de app vissen, maar dan bevind je je op grijs gebied als je Docker commercieel gebruikt.

Update: ik had het mis, je kan de CLI tool los downloaden via https://download.docker.com/mac/static/stable/x86_64/

[Reactie gewijzigd door Blaise op 23 juli 2024 03:51]

[martenjacobs]

Docker cli is volgens mij ook uit homebrew te halen

[supersnathan94]

Nee maar wel heel handig en snel. De overhead van parallels is ook niet bepaald klein in verhouding met docker VM.

[martenjacobs]

Ja, dat weet ik dus niet. De laatste keer dat ik docker desktop had draaien liep daar intern virtualbox onder. Ook nou niet persé de meest efficiënte hypervisor volgens mij. Moet zeggen dat dat wel een tijd geleden was; ik weet niet waar docker desktop ondertussen op draait

[Reactie gewijzigd door martenjacobs op 23 juli 2024 03:51]

[Salmon]

WSL2

[martenjacobs]

Onder macOS krijg ik dat maar niet aan de praat…

[teek2]

Behalve dan met WSL2.

Edit: Oeps te snel gereageerd, het stond al in een paar reacties.

[Reactie gewijzigd door teek2 op 23 juli 2024 03:51]

[Snowfall]

Mac

Je kan gewoon Docker installeren via de terminal. Heb je geen Docker Desktop voor nodig.

[TheBoneJarmer]

Belangrijke toevoeging is dat je Docker Desktop enkel kan installeren op Windows Pro omdat er een feature vereist is in verband met virtualisatie dat niet beschikbaar is voor Windows Home gebruikers.

[tweazer]

(ben niet helemaal kundig) met vmware fusion kun je nu toch gratis dockers draaien ?

[WizX]

Dat is incorrect, dat is zeker wel mogelijk, zie bijvoorbeeld: https://dev.to/bowmanjd/i...thout-docker-desktop-34m9

[hooibergje]

Als ervaren programmeur heb ik nog nooit iets met Docker gedaan.
Wel eens gehoord van security issues ervan, dus laat maar.

[Loen]

"als ervaren programmeur" en "nog nooit iets met docker gedaan" zijn 2 zinsdelen die ik niet echt bij elkaar vind passen, tenzij je misschien meer in low level programmeertalen zit (edit: of de meer windows-achtige talen natuurlijk, daar zijn containers nog wat nieuwer en (nu nog) minder goed geimplementeerd). Ik neem wel eens programmeurs aan, en als iemand dat zou zeggen in een interview dan zou daar toch echt een goede uitleg van moeten volgen. Niks ten nadele van jou en misschien met goede reden dus, maar de statement lijkt ietwat kortzichtig.

Ik weet dat het een beetje off topic is, maar een container is inherent veiliger dan een willekeurige applicatie plain op een OS draaien. "Wel eens iets gehoord hebben van security issues" kan bijna alleen maar gaan over issues waarbij de extra beveiliging (containment) die containers brengen (gedeeltelijk) teniet gedaan zijn.

[Reactie gewijzigd door Loen op 23 juli 2024 03:51]

[Niosus]

Zelfs low-level... Ik heb een tijdje embedded C code geschreven. Dat was vroeger een hel om gcc en alle libraries met alle dependencies goed te krijgen telkens als er een nieuwe developer in het team kwam. Vooral als ze dan een nieuwe versie van Ubuntu geïnstalleerd hadden.

Toen zijn we overgestapt naar een "build" image die met regelmaat op de build server wordt gebouwd, die zowel voor development (op de dev machines) als voor de nightlies en release builds dient. Er staan scriptjes in die image voor alles wat je maar zou willen doen.

Om op een nieuwe machine een build in gang te krijgen, is de "git clone" letterlijk de stap die het langste duurt. Ik compileer echt nooit meer C code native. Als ik de moeite ga doen om het build proces te debuggen, dan doe ik het meteen in Docker zodat ik het tenminste maar één keer moet doen.

[cricque]

Docker is geen must. Er zijn genoeg bedrijven die nog nooit van docker gehoord hebben. Er worden ook nog altijd dingen in Cobol gemaakt. Delphi heeft bijvoorbeeld ook nog zijn userbase en ook voor nieuw development. En in grotere teams komen meeste programmeurs zelfs niet in aanraking met docker. Jij maakt de code en daarna is wel iemand anders die alles test en opzet etc. Het kan, persoonlijk vind ik het wel een gemis zijn dat je niet weet dat er mogelijkheden zijn.

Maar veel hangt ook af van wat juist je taak is. Iemand die een gui bouwt die heeft weinig aan docker. Buiten misschien de API die hij moet aanspreken die in docker kan draaien lokaal. Iemand die puur database gerelateerde dingen doet kan het misschien handig zijn om dingen te testen etc, maar voor hetzelfde doet hij dit gewoon op een lokale instance. Daarom heb je dus ook misschien geen docker nodig. Ik ken ook genoeg programmeurs die zelfs nog niet weten hoe geheugen en een cpu werken, deze hebben ook nog nooit een pc van de binnenkant gezien. Vraag hun ook niet hoe ze routing/netwerk moeten opzetten etc. Is dat een gemis ? Tsja afhankelijk van je taak misschien wel, voor sommige dingen dan weer niet. Maar wat wel zo is, tegenwoordig, als het niet in docker draait is het niet goed ... en alles moet perse in een container draaien ... Dikwijls ook overkill

[jrswgtr]

Ik gebruik Docker alleen om snel lokale ontwikkelomgevingen op te kunnen zetten. Zo lang je dan een beetje je goede verstand gebruikt en geen "ongeverifieerde" images installeert lijkt me er weinig aan de hand. Voor productieomgevingen is dat natuurlijk een ander verhaal.

[Berlinetta]

Wat doe je in een productie omgeving dan?

[jrswgtr]

Voor productieomgevingen gebruik ik geen Docker maar meestal gewoon een Linux server met een LEMP stack

[tweazer]

Ik zou toch eens meer naar docker kijken, versiebeheer, security, sizing etc gaat echt veel beter met dockers dan een LAMP stack server ...

[jrswgtr]

Grotendeels heb je gelijk. Daarom gebruik ik docker vooral voor ontwikkeling.

Je corrigeert LEMP naar LAMP. Maar daar zit een wezenlijk verschil. LAMP is Apache MySQL PHP.

LEMP is NGINX MySQL PHP. Met NGINX kun je gebruik maken van load balancing en reverse proxy caching, ook bijvoorbeeld in combinatie met Varnish. Veel hostingplatforms zijn met deze stack uitgerust.

[Reactie gewijzigd door jrswgtr op 23 juli 2024 03:51]

[rootpowered]

Docker is juist ideaal om ontwikkelomgevingen en productie gelijk aan elkaar houden, je zou maar net een andere versie op productie draaien dan je lokaal hebt, krijg je onverwachte foutmeldingen e.d.

[borft]

Hoe schaal je dan? Hoe porteer je dan? En hoe zorg je dat je productieomgeving hetzelfde is als je ontwikkel en testomgevingen?

[jrswgtr]

Applicaties die schaalbaar moeten (zoals webshops) zijn komen op een platform te draaien dat wel schaalbaar is, bijvoorbeel Byte Hypernode. Hypernode levert docker images zodat je lokale omgeving nagenoeg gelijk is aan de productieomgeving.

Code overzetten uiteraard met GIT.

[Reactie gewijzigd door jrswgtr op 23 juli 2024 03:51]

[borft]

By treating the Docker as a lightweight VM instead of as a vehicle for a single process we stay close to what an actual Hypernode actually looks like.
The hypernode-docker image has SSH, PHP, NGINX, MySQL, Redis and Varnish.

hmm, niet helemaal mijn architectuur van keuze. Je hebt alles in een grote monolitische container draaien. Ik mag hopen dat dat niet hetzelfde is als productie En je code zit dus niet in de container, dus hoe weet je dat de snapshot van de container en die van je code hetzelfde zijn op productie? (hint: dat weet je niet).

That said, ieder natuurlijk zijn meug, wat voor mij werkt, werkt natuurlijk niet per se voor iemand anders Wel tof dat ze die images aanbieden.

[Anoniem: 162126]

Als ervaren programmeur wel eens iets gehoord, dus laat maar? Als je zo redeneert gebruik je waarschijnlijk geen enkel framework om te developen.

[Berlinetta]

Kan in principe prima zonder docker werken.

Edit: Docker desktop en daarmee bedoel ik iedereen kan zonder dat werken...

[Reactie gewijzigd door Berlinetta op 23 juli 2024 03:51]

[Yggdrasil]

Ik kan ook coden in Notepad. Dat wil niet zeggen dat meer geavanceerde tools geen meerwaarde hebben.

[Berlinetta]

Ik bedoel zonder Docker desktop...

[tweazer]

Als je niet met de tijd meegaat doe je dat toch met wordstar op je cp/m pc ? Notepad, security en zo ?

[Yggdrasil]

Ik snap je opmerking niet.

[Anoniem: 162126]

Je kan ook prima zonder grafische interface werken. Maar voor database werk is het toch redelijk handig. Zo draai ik voor de ene klant een Microsoft SQL Server in een docker container op mijn laptop en voor de andere klant een postgresql database. En deploy ik lokaal en op de testserver docker containers met daarin de backend applicatie. Dus ter ondersteuning van continuous integration is het handig.

Dus het is niet strikt noodzakelijk, maar wel een heel handige tool om kwaliteit te borgen.

[hooibergje]

Precies. Heb alleen een goede recente compiler nodig.

Een editor met syntax highlighting is wel erg fijn.
Een editor met tabs en syntax highlighting is goud, maar meer heb ik echt niet nodig.

[Anoniem: 162126]

vim! Ik zweer er bij, maar docker, of eigenlijk containers zijn voor veel workflows erg handig.

[okkies]

als een noob die aventoe heel cool in ubuntu wat tutorials volgt op internet:

Waarom VIM en geen Nano ?

ik heb nooit de meerwaarde van VIM tov nano begrepen

[Anoniem: 162126]

Ik heb geen pijltjestoetsen op mijn keyboard!
Maar iets serieuzer, het is gewoon een ontzettend goede editor waarbij ik eigenlijk nooit mijn handen hoef te verplaatsen bij het schrijven van code. Ik ga niet beweren dat het de beste editor is oid. Maar ik vind het zo ontzettend fijn werken na bijna 30 jaar normale editors gebruikt te hebben. Ik was/ben fan van de Jetbrains tools, maar ik ben inmiddels nog grotere fan van vim.

Voor het bijzondere geval dat ik nog eens een pijltjestoets nodig heb, switch ik naar een andere layer op mijn keyboard door de spatiebalk iets langer ingedrukt te houden en dan alsnog (net als in vim) hjkl te gebruiken.

edit: ohja, en het opstarten van een code editor zou ook geen tig seconden moeten zijn. Zeker niet als je een 8 core laptop hebt met 64GB geheugen.

[Reactie gewijzigd door Anoniem: 162126 op 23 juli 2024 03:51]

[TheBoneJarmer]

Ik vind persoonlijk Nano heel fijn werken maar ik ben bekend met de Vim commands omdat Nano nog niet op elke Linux distro geintregreerd is en Vim al bestaat sinds de oertijd.

[cricque]

VSCode en vergeet al de rest . Ik gebruik al linux sinds 97 en heb een hele resem tools gebruikt. Als ik een linux desktop ter beschikking heb is het gewoon vscode. Om wat op een commandline (meestal remote) aan te passen gebruiken we de tools die op de machine staan. Maakt mij niet zoveel uit.
Maar qua development VSCode, gebruik het al op linux desktop sinds de beta en dat is 2x gecrashed sinds ik het gebruik ergens 2016 ofzo

[goarilla]

Maar dat is van ... de hellemond in Redmond

[ProjWorld]

Ik gebruik zelf bijna alleen nano, maar ik ik kan wel voordelen van vi of vim bedenken:
krachtigere editing tools (regular expressions, tekstaanvulling, etc.), wordt zelfs met de meest minimale *NIX installatie meegeleverd, minder groot op disk (discutabel), keycodes zijn altijd hetzelfde (ongeacht welke layout je ook kiest of hebt) voor modifiers en (mijn favorieten) split screen en sessie herstel.

Er zullen er vast wel meer zijn, maar dat zijn in elk geval dingen waarom ikzelf soms terugval op vi. Vooral op een "echte" seriële console op embedded installaties heb je soms geen keus.

Zolang je geen vi (of vim) gebruikt of regelmatig nodig hebt, zul je waarschijnlijk je mening ook niet veranderen. Ik heb 16 jaar prima zonder vi kunnen werken. Pas de laatste jaren ben ik vi (en emacs) gaan waarderen. Nano werkt prima voor de meeste taken en is ook lekker makkelijk om me te beginnen...(Volgens mij was mijn grootste struikelblok zelfs het herkennen van de circumflex als controltoets )

[goarilla]

Waarom nano en geen mcedit ?

[jj71]

Nogal kortzichtig om te zeggen "ik heb wel eens gehoord van security issues dus laat maar".

Voor software ontwikkelen en testen op je lokale systeem is het ontzettend handig. Ik werk aan backend applicaties die met allerlei systemen moeten praten zoals databases en message queues. Om te ontwikkelen en te testen start ik dingen zoals een Oracle database en ActiveMQ op in Docker containers. In een Docker container zit het in een sandbox, zodat ik dat soort software niet helemaal lokaal hoef te installeren (met de nodige vervuiling van mijn systeem tot gevolg). Het is ook heel makkelijk om een container weg te gooien en opnieuw aan te maken, waarmee ik heel snel (in een paar seconden) een database heb die in de juiste state is om bijv. een test te kunnen uitvoeren.

We hebben voor bepaalde systemen waar onze software aan moet koppelen ook stub / mock services gemaakt. Dan maken we bijvoorbeeld een kleine mock REST service in Node.js ofzo die standaard antwoorden geeft op requests. Die stubs starten we ook op in Docker containers. Daarmee zijn we niet afhankelijk van externe testservers tijdens het ontwikkelen. Met Docker Compose kun je met één commando de hele stack aan services, incl. database en message queue, opstarten. Heel handig dus voor ontwikkelen en testen.

Dus, ik zou je aanraden over je vooroordeel heen te stappen en je er toch eens in te verdiepen als ervaren programmeur.

Mijn werkcomputer draait overigens Ubuntu, dus Docker draait hier native op, en Docker Desktop gebruik ik niet.

[Reactie gewijzigd door jj71 op 23 juli 2024 03:51]

[cricque]

Mock services is leuk, maar de andere partij moet toch maar net iets wijzigen en dan ben je nog gezien. Ik doe het ook zo hoor, daar nu niet van. Maar er zijn genoeg partijen die iets kleins wijzigen en dan ben je gezien. DIe probeer je dan ook gewoon te vermijden. Een goeie 3de partij heeft zijn eigen testserver. En iets mocken is nog altijd spijtig genoeg the real thing. Als je een wijziging niet doorkrijgt ben je gezien en je moet ook nog tijd steken in updates.Het probleem is dat er voor sommige 3de partijen geen andere mogelijkheden zijn. En dat is een probleem zeker als ze het niet zo nauw nemen met partners informeren over wijzigingen (en niet 5 minuten voor een update)

[jj71]

Ja, we testen natuurlijk ook met "echte" testservices. Maar tijdens ontwikkelen is het erg handig om niet afhankelijk te zijn van de beschikbaarheid van die testservices, die een derde partij ook wel eens zomaar onaangekondigd down kan gooien. En met mock services in Docker heeft je ontwikkelsysteem zelfs helemaal geen netwerkverbinding naar de buitenwereld nodig om te kunnen testen.

[ddefrenne]

Wat heeft geen security issues? Het hangt er maar vanaf hoe je het gebruikt, dus best niet zomaar gelijk welke image downloaden en starten.

[Oon]

Er zijn geen security issues in docker die niet aanwezig zijn in iedere andere vorm van beheren van containers of VMs. Als ervaren programmeur zou je dat toch wel moeten weten

[tweazer]

I'd beg to differ: met deze pricemove komt de A van CIA in gevaar: availability, zonder centjes geen docker lees ik ... nosepicking, I know ...

[Oon]

Ik hoop toch heel zeker dat er geen enkel bedrijf op de wereld is dat Docker Desktop gebruikt voor het daadwerkelijk hosten van diensten. Daarbij zijn de meeste bedrijven inmiddels overgestapt naar Kubernetes of een andere vorm van beheren van containers op servers, en zo niet heb je dit abonnement ook niet nodig om Docker gewoon zoals voorheen op een server te draaien

[Jack Flushell]

Wel eens gehoord van security issues ervan, dus laat maar.

Wel eens van gehoord - DUS laat maar. Goed verhaal, zeker voor een ervaren promammeur!

[Goldwing1973]

Hij gebruikt nog vast en zeker MS-DOS 6.22 zonder internet verbinding, want tsja, Windows, Linux, MacOS hebben allemaal wel eens security issues gehad, dus “laat maar”

[Wilke]

Tijd om onder die steen vandaan te kruipen dan

In de rest van de wereld bouwen mensen hiermee consistente devevelopment en CI/CD environments, wat je een heleboel gedoe bespaart als je het eenmaal opgezet hebt.

[rc_enzo]

Het heeft een iets lagere instapdrempel dan het leren van een CLI. Iets visueel hebben helpt wel bij nieuwe dingen.

Bovendien heb ik 'm zelf dus nodig op mijn systeem. Waarschijnlijk ligt het aan mijn configuratie, maar als ik de Docker Desktop applicatie niet heb gestart, dan draait de Docker daemon niet en kan ik dus nog niks.

[Waswat]

Eh, behoorlijk lagere instaprdrempel. Voor de gemiddelde gebruiker is het ook handiger dan CLI commands te onthouden en gebruiken.

[OMX2000]

Docker is in basis een developer en tester tool. Ik verwacht dat je dan toch wel wat ervaring hebt met CLI. Dat "gewone" gebruikers een UI fijner vinden geloof ik zeker, maar dat is niet de primaire doelgroep.
En ja ik weet dat er ook developers zijn die liever een UI gebruiken, maar die zijn stom

[supersnathan94]

Sorry maar dat is toch een onzin argument?

Als ik dagelijks 2 minuten kan besparen door een tool te downloaden dan scheelt dat een opdrachtgever om en nabij 15 euro per week.

Reken maar uit wat dat in een jaar scheelt.

En hoezo zijn developers die een UI gebruiken stom? Ik type m’n source code toch ook gewoon in een fatsoenlijke IDE met highlighting en niet in vim of nano?

[Katsunami]

En hoezo zijn developers die een UI gebruiken stom? Ik type m’n source code toch ook gewoon in een fatsoenlijke IDE met highlighting en niet in vim of nano?

Het lijkt erop dat er mensen zijn die vinden dat alles dat is uitgevonden na 1981 ofzo waardeloze bloat is. Onder die mensen heerst een cultuur dat alles op de moeilijkste / meest traditionele / onmogelijke manier moet. Een beetje zoiets als dit:

https://imgs.xkcd.com/comics/real_programmers.png

Ken Thompson, ontwerper van Unix en vele andere dingen in de computerwereld, heeft blijkbaar ooit gezegd: “The X server has to be the biggest program I’ve ever seen that doesn’t do anything for you.”

Als je vindt dat de X-server niks voor je doet (en daarin doorgetrokken, de window manager, de login manager, etc) dan zeg je eigenlijk: "Een grafische interface is nutteloos." Nou... ik kan goed tot zeer goed met de CLI overweg (bash, in elk geval), maar voor veel taken is een GUI toch echt sneller, handiger, of soms zelfs de enige optie. (Heb je iemand al eens foto's, video's of muziek zien bewerken met behulp van FFMPEG op de command-line?)

Zelf gebruik ik gewoon wat het handigst is voor een bepaalde taak.

[Reactie gewijzigd door Katsunami op 23 juli 2024 03:51]

[Niosus]

Het is inderdaad maar wat het handigste is voor een taak, maar ook hoe vaak die taak moet gebeuren.

Ik ben één van die wierdos die dus ffmpeg op de command line heeft gebruikt. Maar dat was ook omdat ik dezelfde bewerking op een paar honderd video's moest doen. Die 2 uur knoeien om ffmpeg cli uit te vogelen was het dan echt wel waard.

Moest ik het maar op 1 of 2 video's moeten doen, dan had ik waarschijnlijk die oude versie van Sony Vegas die ik nog heb staan open gedaan.

The right tool for the right job.

[Katsunami]

Ik ben één van die wierdos die dus ffmpeg op de command line heeft gebruikt. Maar dat was ook omdat ik dezelfde bewerking op een paar honderd video's moest doen. Die 2 uur knoeien om ffmpeg cli uit te vogelen was het dan echt wel waard.

Ik heb ooit voor mijn vorige werkgever een billboard-systeem gebouwd, dat video's moest kunnen afspelen, in een bepaald formaat, en foto's moest kunnen weergeven op 1920x1200 (of zo kort mogelijk erbij met behoud van aspect ratio).

Dan kun je de gebruiker wel zeggen dat die video's moet uploaden in container X, met MPEG voor de video en OGG als geluid, en dat hij zijn foto's zelf moet bewerken, maar dat gaat nooit goedkomen. Ik heb ffmpeg en imagemagick destijds (2014) gebruikt om geüploade video's en foto's automatisch in de juiste formaten om te zetten.

Dat vind ik ook het mooie van een command-line: als je erachter komt dat je sommige taken vaak uitvoert, kun je er een scriptje van maken. Met een GUI moet je dan al snel aan de slag met dingen als een macro-recorder oid.

[supersnathan94]

The right tool for the right job zou het motto van iedere dev moeten zijn.

Wij zijn van de automatisering. Als we dat dan niet zelf ook gebruiken waar zijn we dan mee bezig? Commandline voor herhalende taken is fijn. Voor dingen als een docker built maak ik eigenlijk direct een script die ik dan in IDE als run config opsla die kun je dan delen met andere ontwikkelaars en daarmee bespaar je direct geld.

Handig zijn met commandline sluit echter het gebruik van tooling niet uit.

Git op commandline gebruik ik zelden. Gewoon omdat committen en pushen via IntelliJ sneller is en minder foutgevoelig.

[devices]

Filters toepassen voor encoding gaat juist veel via command line en heb je in princiepe geen grafische interface voor nodig en is een bewerking. Ik weet niet of de pros dat ook zo doen, maar anime wordt vooral encode via x264 command line interface. (Image)Magick wordt ook veel gebruikt om foto's te bewerken. Echter om het resultaat te inspecteren ontkom je niet aan een grafische interface en andere soorten van bewerking natuurlijk ook.

[Berlinetta]

Ziet er naar uit dat het sarcasme is.

Ik dacht dat docker desktop gewoon Docker aanzette en een terminal emulator gaf. Maar goed, ik heb ook nooit gebruikt.

[Anoniem: 25604]

Als ex-Unix systeembeheerder ben ik eigenlijk wel klaar met CLI, VI etc... Als ik Powershell ISE kan gebruiken i.p.v. de Powershell-console... waarom zou ik mezelf dan pijnigen? Ik weet dat er beheerders en developers zijn die op CLI g31l3n, maar die zijn zelfkastijders... en stom.

[OMX2000]

Ieder zijn ding. Maar het is toch wel heel opvallend dat Microsoft met Windows Terminal en ssh client + server meer een meer de commandline omarmt. Dat wil niet zeggen dat GUI's waardeloos zijn, maar wel dat het voor best wel wat taken die je als developer doet handiger is.

[tweazer]

De microsoft ontwikkelingen klinken mij eerder als verder uitbouwen van een freebsd kernel waar ze eerst enkel de netwerk stsck van hadden gecopieerd ....

[SuperDre]

Nouja, zelfs als developer blijf ik graag weg van de CLI, wordt er altijd zo moe van om alles te typen en al die commando's/opties te moeten onthouden, zeker als je sommige zaken vaak maar 1x in de zoveel tijd gebruikt om weer even wat te wijzigen.

[OMX2000]

Wat ik zei was ook redelijk tongue in cheek. Maar tegelijk vind ik ECHT dat ontwikkelaars de commandline moeten beheersen. Dan bedoel ik niet dat ze complete guru's moeten zijn en alle ins en outs kennen.

UI is voor sommige taken handig, en voor andere weer niet. Maar CLI beheersen is ook handig omdat er altijd een situatie ontstaat waarbij de CLI de boel verkloot, en je moet terugvallen op CLI.

Maar goed dit gaat wat mij betref specifieker over docker gebruik. Als ik een terminal open heb, al dan niet binnen bijvoorbeeld VS Code, dan ben ik sneller omdaar docker commands uit te voeren dan dat ik die via de GUI doe.

[TheBoneJarmer]

Maar tegelijk vind ik ECHT dat ontwikkelaars de commandline moeten beheersen. Dan bedoel ik niet dat ze complete guru's moeten zijn en alle ins en outs kennen.

Ik vind het bijzonder dat hier een hele discussie gaande is over het al dan wel niet moeten kennen van de CLI terwijl dat Dockerfiles uit niets anders bestaan dan CLI commands.

[OMX2000]

Ja dat! Ook als je een container wilt troubleshooten is het handig dat je iets kunt met de CLI. Want met een GUI kom je gewoon nergens dan.

[TheBoneJarmer]

Ja precies. Dat is echt quasi onmogelijk om te doen zonder idd. Ik heb vaak genoeg gehad dat ik een container moest attachen omdat er een app gecrashed was binnen die container om dan uit te zoeken wat er mis gegaan is. Ik zie niet hoe dat kan zonder CLI.

[Waswat]

Dat is dus eerder omdat CLI daarbij vaak het minimale is en overal toepasbaar is. Meeste devs die ik ken hebben het liefst een GUI bij vele incidentele taken en vallen vaak alleen terug op CLI voor de uitgebreidere/herhaalde taken. Docker is opgebouwd om dat herhaaldelijke CLI geneuzel juist te verminderen maar natuurlijk kan je er (helaas) niet omheen.

[Reactie gewijzigd door Waswat op 23 juli 2024 03:51]

[faim]

Jij beheert je database zeker ook vanaf een CLI?

[Berlinetta]

Wacht even, ik dacht dat je juist de CLI moest gebruiken, omdat het anders niet kon?

[supersnathan94]

Jawel hoor. Dbeaver voor postgres ed, voor mongo, elasticvue oid voor ES stack. Zijn ontzettend veel UI tools.

Of ik heb de /s gemist

[OMX2000]

Wie heeft het over databases. Dit gaat toch over docker desktop en eventueel een alternatief daarvoor. Ik heb niks tegen GUI's als ze helpen om je werk sneller en beter te doen. En voor mij vind ik docker acties via de commandline fijner en sneller. Da's alles.

[faim]

En ja ik weet dat er ook developers zijn die liever een UI gebruiken, maar die zijn stom

Je hebt het hier toch echt over UI's in het algemeen...

[OMX2000]

Why so serious? Ik gebruik ook UI's, bijvoorbeeld mijn IDE (Visual Studio), of GitKraken voor git. Omdat sommige taken met een grafische interface wat fijner werken. Dus vandaar de emoji.

Maar bijvoorbeeld een "docker run hello-world" gaat voor mij sneller via een CLI dan een GUI.

[Waswat]

>Docker is in basis een developer en tester tool

Dit klopt allang niet meer gezien docker containers worden gebruikt om snel en makkelijk even iets op te zetten met standaardwaardes dat ook vrij makkelijk up to date te houden is.

Zelfs dan... Ben ook gewoon ontwikkelaar en CLI is prima maar letterlijk het minimum. Zodra ik een interface heb gebruik ik dat over het algemeen 10x liever. 'Tuurlijk is het prima om een scriptje te schrijven maar dat geneuzel om commands te onthouden per applicatie ben ik echt ontzettend beu. Ik weet precies wat het moet doen, maar wanneer ik moet ploeteren door de CLI documentatie om iets simpels op te zetten dan sla je de plank mis als development tool.

Terugvallen op commands als het mis gaat is uiteraard niet erg.

[Reactie gewijzigd door Waswat op 23 juli 2024 03:51]

[Martinspire]

Maar elke container en elke ontwikkelaar heeft weer zijn eigen manier om de zaken erbinnen op te starten dus eigenlijk ontkom je er niet aan

[Waswat]

Uiteraard, maar een GUI voor de meeste gevallen heeft toch wel mijn voorkeur

[Martinspire]

Oh dat ben ik helemaal met je eens. Ik ben ook geen fan van terminals, maar ik heb het idee dat je bij dit soort tools daar toch te snel mee te maken krijgt omdat de GUI zo enorm beperkt is. Ik heb ook niet het idee dat het helemaal matched met wat mensen doen met containers. Ik zou verwachten dat 95% van de handelingen gewoon in de GUI kunnen, maar dat is gewoon niet het geval.

[cricque]

Tsja het is wel laagdrempelig. Maar hoe je het draait of keert, CLI is ondenkbaar. Ken genoeg mensen die hier niks willen mee te maken hebben, persoonlijk gebruik ik voor veel dingen gewoon mijn commando's op de commandline. Natuurlijk helpt het wel dat ik in 97 begonnen ben met linux (red hat). Ieder zijn eigen keuze uiteraard. Maar voor de meeste zaken hoe je het draait of keert zal je op een gegeven moment toch een command line moeten gebruiken

[Woy]

Volgens mij is er ook geen losse install van de docker-deamon op windows ( buiten WSL2 natuurlijk ). Dus om Docker direct op windows te draaien heb je Docker Desktop nodig.

[Pinkys Brain]

Is natuurlijk gewoon docker in linux in een VM, of je nou WSL2 gebruikt of op de oude manier.

Alleen WSL1 zat "direct" op windows, maar was op een of andere manier langzamer dan linux in een VM.

[Reactie gewijzigd door Pinkys Brain op 23 juli 2024 03:51]

[GeroldM]

WSL was op mijn systemen ook langzamer dan een VM. Nu gebruik ik liever voor elke taak een aparte (Linux) VM dan dat ik alles op een hoop gooi. Dat houd de VMs best "schoon", redelijk klein en installatie snel en eenvoudig. Zo'n beetje alles waar je een container zou willen inzetten.

Een container heeft veel meer mogelijkheden voor granulariteit, dat betwist ik niet. Maar voor mijn doeleinden is de huidige methode afdoende. Hardware resources zijn er voldoende en de baas zit niet te wachten op een verborgen kostenpost door de (alsmaar) veranderende regels van Docker. Waarbij het nu misschien nog niet het geval is, als Docker besluit dat het bedrijf nog steeds niet solvabel genoeg is, dan staat het hun vrij om hun abonnementsvoorwaarden nog verder aan te scherpen.

Iedereen moet zijn geld kunnen verdienen, echter is Docker in Windows omgevingen al jaren geen vetpot. Misschien dat het dan verstandiger is om die markt dan maar te laten vallen. Er zijn genoeg andere projecten die dat gedaan hebben en daardoor winstgevend zijn geworden.

[ddefrenne]

Ligt niet aan je configuratie. Op MacOS/Windows heb je de applicatie nodig om Hyperkit te starten die een VM start met Linux waarbinnen je container(s) draaien.

[opblaashaas]

Integratie met visual studio zodat je direct je code kan testen in een container is een groot voordeel.

[SiErRa]

Inderdaad, en ik ben bang dat je hiervoor toch echt aan Docker Desktop vastzit. Wel jammer deze ontwikkeling, de trend was dat er steeds meer tooling gratis / open source werd, en je als ontwikkelaar vaak alleen nog een betaalde IDE nodig had.

[Locke_]

Ik rommel veel met containers en heb op mijn PC docker-desktop geinstalleerd staan, maar in de praktijk merk ik eigenlijk dat ik het niet gebruik.

[TheNephilim]

Jazeker, maar opstarten/aanmaken/etc. gebeurd gewoon in de command line.

[Ed Vertijsment]

Ik gebruik de Docker desktop eigenlijk alleen maar voor het opstarten van docker zelf, de rest doe ik via de CLI. Het opstarten zelf zou ook vast wel via de CLI kunnen maar dat heeft dan weinig meerwaarde vergeleken met spotlight.

[kevinkrs]

Ik vind het voornamelijk voor de visualisatie handig, even snel kijken welke poorten mapped zijn in de container. Even snel binnen de container kijken, even snel de output log bekijken etc.

[V3LoXy]

Wij gebruikten al lange tijd docker in combinatie met een custom vagrant box (op mac), recent geswitcht naar docker desktop om de setup te vergemakkelijken en de snelheid te verbeteren. De dev tools die we gebruiken hebben ook een integratie met docker desktop waardoor de dev experience ook beter is. Vooral voor onze frontenders is een UI ook veel gemakkelijker, al is er nog wel een beetje command line nodig voor de initiele start (via docker-compose)

[StarZ]

Ik vind het nog vrij onduidelijk wat nu onder Docker Desktop valt. Naar mijn idee was Desktop een bundel van allerlij tools + een UI maar dat kan ik mis hebben

[Eonfge]

Paar termen
- Containerd: linux kernel en subsysteem voor het draaien van containers
- Moby: white-label engine die images beheerd en kan starten.
- Docker: merknaam voor Moby
- Docker Desktop: utility die Moby e.d. beschikbaar maakt op Mac en Windows

Persoonlijk raad in iedereen aan om eens naar podman, buildah en podman-compose te kijken. Daarmee kun je de hele Docker software stack op linux vervangen

[Anoniem: 334725]

Tip: gebruik docker engine zonder docker desktop. Dat mag nog steeds zonder te betalen.

[Reactie gewijzigd door Anoniem: 334725 op 23 juli 2024 03:51]

[OMX2000]

De tip zou zijn, hoe dat te doen. Op Windows via WSL2. Maar zijn er ook andere manieren? En is dat ook beschikbaar voor macOS?

[thomasmoors]

Je zou een gewone VM kunnen installeren bijv. Virtualbox met daarop Ubuntu. Op Ubuntu installeer je dan Docker. Als je Docker dan wil gebruiken voor development (waarbij je steeds code moet syncen in tegenstelling tot containers voor productie) zou je bijvoorbeeld rsync kunnen gebruiken. Nu zijn er meer sync tools tussen mac en linux.

[zx9r_mario]

Ik gebruik docker onder Linux desktop. Geen overhead met wsl2 oid.

[elmuerte]

Ik zit met werk vast aan Windows. Op dit moment is Docker Desktop, zo ver ik weet, de enige manier voor een bruikbare setup. Docker WSL2/VM exclusive maken is heel onhandig in gebruik.
Ik gebruik verder die afgrijselijke Docker Desktop UI niet, dus hoe eerder ik een Docker for Windows without Docker Desktop kan krijgen, hoe beter.

[thomasmoors]

Kan ik me voorstellen, maar OMX2000 vroeg naar een oplossing voor Mac. En de gemiddelde mac gebruiker wil geen linux installeren op een dure machine waar je ook betaald voor het OS.

[OMX2000]

Dus WSL2 is dan een betere keus. Virtualbox met daarbinnen Ubuntu, lijkt me slechter ter performen dan WSL2 + Ubuntu of whatever + Docker.

Maar dat is een aanname hè. Ik heb allebei uitgeprobeerd, en dus vergeleken.

[thomasmoors]

Ik reageerde met name op je laatste vraag als oplossing voor de Mac. Voor Windows zou ik dan altijd WSL2 gebruiken.

[OMX2000]

Klopt. Ik had de vraag anders moeten stellen. Maar eens met wat je aangeeft. En ja WSL2 is the way to go. Is sowieso een sterke pluspunt van Windows tov macOS.

[Loen]

Gelijk overstappen naar podman klinkt dan als een betere oplossing. Daarvoor komen langzaamaan ook betere how-to's beschikbaar. Volgens mij moet je daarvoor nu inderdaad ook virtualbox+vagrant hebben draaien, maar kun je de install doen met podman-machine. Podman richt zich op 1-op-1 compatibility met docker. Voor RHEL heb je zelfs podman-docker die de translatie van commando's doet (wat volgens mij niet veel meer is dan wat aliasses)

[frickY]

Op Windows draai ik een Ubuntu VM met de Docker-daemon.
Ik heb een DOCKER_HOST environment variabele met het IP van de VM zodat ik lokaal gewoon de docker cli kan gebruiken.
Alleen toegang tot files op je host machine vanuit de daemon is even een aandachtspuntje maar dat went.

[Reactie gewijzigd door frickY op 23 juli 2024 03:51]

[Anoniem: 334725]

Persoonlijk zou ik een VM opzetten en via het netwerk van je pc/laptop beschikbaar maken. Dan kan je daar Docker installeren en met de docker cli op je windows machine via DOCKER_HOST verbinden met deze VM.

Vergt wel wat voorkennis, maar is wel een common use-case waardoor je veel documentatie over kan googlen.

Docker desktop vind ik persoonlijk waardeloos.

[EEstar]

Dit artikel zegt 2x iets anders.... is het nou 250 medewerkers en 10 miljoen dollar of 250 medewerkers of 10 miljoen dollar

[Woy]

De originele text is

fewer than 250 employees AND less than $10M USD in annual revenue

Maar dat is wanneer je onder de small-businesses valt. De vertaling heeft het omgedraaid, maar niet overal juist. Wanneer je dus meer dan 250 medewerkers hebt of meer dan 10 miljoen omzet, moet je een abo afsluiten

[Reactie gewijzigd door Woy op 23 juli 2024 03:51]

[olafmol]

Docker Desktop can be used for free as part of a Docker Personal subscription for: small companies (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.

[Cobalt]

Er staat ook:

"Commercial use of Docker Desktop in larger enterprises (more than 250 employees OR more than $10 million USD in annual revenue) requires a Docker Pro, Team or Business subscription for as little as $5 per user per month."

- minder dan 250 man en minder 10 miljoen omzet is klein bedrijf
- meer dan 250 man is groot bedrijf
- meer dan 10 miljoen omzet is groot bedrijf

[SirRosencrantz]

Excuses, ik heb het aangepast. Het gaat inderdaad om én.

[Gyske]

[edit] nevermind

[Reactie gewijzigd door Gyske op 23 juli 2024 03:51]

[Oogappel]

EEstar heeft je op een verkeerd been gezet.

Docker Desktop remains free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue)

Dus, wordt betalend als een van de twee voorwaarden geschonden wordt : vanaf 250 werknemers of $10 milion annual revenue.

[svane]

Weet iemand hoe je Docker-Engine kan gebruiken (op Windows of MacOS) zonder Docker-Desktop? Dit lijkt toch wel een probleem te worden.

Als ik naar de installatie-instructies van docker-engine kijk:

dan staat er dat je voor Windows/MacOS de Docker-Desktop versie moet installeren. Voor Linux zijn er wel binaries beschikbaar.

Er zijn ook binaries voor Windows/MacOS, maar dan krijg je alleen de client, niet de daemon

Static binaries for the Docker daemon binary are only available for Linux (as dockerd). Static binaries for the Docker client are available for Linux and macOS (as docker).

Voor Windows begrijp ik dat 't nog wel via WSL kan, maar met MacOS lijk je wel redelijk de klos te zijn. Misschien dat Podman kan helpen? (geen ervaring mee)

Update: Deze methode lijkt een goed alternatief te zijn voor gebruikers die geen Docker-Desktop willen gebruiken.

[Reactie gewijzigd door svane op 23 juli 2024 03:51]

[borft]

ook op de mac kan je in principe docker gewoon in een linux VM draaien (zo werkte dat vroeger ook, in de tijd voor hyperkit)

[Ventieldopje]

Misschien met docker-machine? Dat werkt zonder de desktop app te installeren en is afhankelijk van de hypervisor en config soms ook sneller op Mac.

[svane]

Geen slecht idee, al staat Docker-machine inmiddels tussen de 'Superseded products and tools'. Ik weet niet hoe lang dit nog actief ondersteund gaat worden. Het voelt voor mij ook als een stap terug.

Volgens mij zou dit moeten werken:

- Installeer Minikube (MacOS: `brew install minikube`)
- Installeer Hyperkit, als alternatief op Docker (`brew install hyperkit`)
- Start Minikube: `minikube start --driver=hyperkit`
- Run dit commando, om de docker-client/cli te laten werken met de minikube/hyperkit install: `eval $(minikube -p minikube docker-env)`

Nu werkt de Docker client zonder docker-desktop aan te hebben staan. Getest op MacOS Big Sur.

Inspiratie: https://news.ycombinator.com/item?id=28371127

edit:
Dit is natuurlijk voor de meeste gebruikers niet nodig, maar het voelt altijd goed om een alternatief te hebben.

[PdeBie]

Vanochtend inderdaad ook gezien en gemeld in de Devschuur: https://gathering.tweaker...message/68569986#68569986

[yade]

Ik heb tot op de dag van vandaag meer last dan lust van Docker Desktop, in ik blijf adviseren om in een VM te werken.

[pumpidumpi]

Hopelijk kunnen ze met dat geld de file IO performance fixen van een Docker container op Macos. Iedere IO operatie loopt nu via de CPU. Wat resulteert in slechte performance en een warme blazende Macbook.

[rbroen]

Dat was voor mij 2,5 jaar geleden de reden om afscheid te nemen van de MacBooks. (Ter info, de overstap was naar Linux.)

[rbroen]

Docker gaat via enkele nieuwe abon...

Laten we de zaken wel zuiver houden:

Docker, Inc., de ontwikkelaar achter het open source project Docker, gaat via enkele nieuwe abon...

[timmus]

Doe mij maar FreeBSD Jails