Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker's Second Death

tariqislam.com

Post reply on HN
Print view View original

281–286 of 286 posts

Re: Docker's Second Death

#281

Post by cpuguy83 »

yjftsjthsd-h wrote: post #145
enos_feedler wrote: post #114

Earlier quoted context omitted.

What kind of control are you looking for?

I'd like explicit layers (transactions, I guess?) - so instead of every command making a layer, I could write FROM alpine STARTLAYER RUN apk update RUN apk upgrade RUN apk add foo ENDLAYER and end up with a 2-layer image (alpine + my stuff) rather than the 4-layer image that docker would produce today.

RUN --mount=source=my_script.sh,target=/tmp/script.sh /tmp/script.sh

This will adds the script without adding a layer for it.

Re: Docker's Second Death

#282

Post by bmelton »

chubot wrote: post #254
lima wrote: post #6

So, what's the better business model for a low-level piece of infrastructure like Docker?

Well Docker used to be dotCloud, a PaaS company around the time of Heroku, but that didn't take off. So they pivoted to Docker. https://en.wikipedia.org/wiki/Docker,_Inc . Heroku had a lot of revenue and was acquired by Salesforce. I just learned on Twitter that YC was in the red before the Heroku acquistion ! https://twitter.com/paulg/status/1334945195532685317 I think what Heroku did right is really nail the Rails…

The python/django experience on dotCloud was really rather nice, actually. Perhaps much of that sympathy was coming from people were comparing Rails/Heroku with Rails/dotCloud, where Heroku has a rather big head start, but Django/dotCloud was the first easy, pipelineable deployment experience I had ever found despite having already tried all the early competition.

It probably wouldn't have taken long for a Python-centric competitor to leapfrog them, but by the time they had, dotCloud was basically all in on the Docker experience, which was transformative.

Re: Docker's Second Death

#283

Post by zaro »

nikisweeting wrote: post #270
zaro wrote: post #168

Not a big loss, IMO. I still remeber when there was somebody on a dockercon with "I don't accept systemd patches".

From my understanding that was due to a long-running design philosophy clash between the systemd people thinking Docker should be using systemd primitives to manage things like unit startup/shutdown/etc., and the docker people wanting to use their in-house implementations so as not to depend on systemd (and thus rejecting PRs trying to change docker behavior to use systemd). I don't think it's fair to use that as an…

And what drove my attention to the "I don't accept systemd patches" was the need to run systemd in docker container. Which by digging a litte bit about I found it will be possible in non priviledged mode, but docker didn't want to merge it.

I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor.

This was several years ago, now this is not an issue anymore, but it's still telling of the toxic corporate culture Docker had back then.

Re: Docker's Second Death

#284

Post by nikisweeting »

zaro wrote: post #283
nikisweeting wrote: post #270

Earlier quoted context omitted.

From my understanding that was due to a long-running design philosophy clash between the systemd people thinking Docker should be using systemd primitives to manage things like unit startup/shutdown/etc., and the docker people wanting to use their in-house implementations so as not to depend on systemd (and thus rejecting PRs trying to change docker behavior to use systemd). I don't think it's fair to use that as an…

And what drove my attention to the "I don't accept systemd patches" was the need to run systemd in docker container. Which by digging a litte bit about I found it will be possible in non priviledged mode, but docker didn't want to merge it. I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor. This was several years ago, now this is not an issue an…

I think the reasoning was that you shouldn't need systemd in docker because the point is for docker itself to containerize each service unit, and use something like docker-compose to manage multiple units. Personally I think that's an aggressive but valid stance because by allowing systemd in docker they'd get a ton of low quality docker images floating around where they launch multiple services within containers, which is against the "do one thing per container" philosophy.

Now that docker has proliferated and the standard practices are clear and well documented, there's less of a danger allowing people to do messy things in their docker containers.

Re: Docker's Second Death

#285

Post by zaro »

nikisweeting wrote: post #284
zaro wrote: post #283

Earlier quoted context omitted.

And what drove my attention to the "I don't accept systemd patches" was the need to run systemd in docker container. Which by digging a litte bit about I found it will be possible in non priviledged mode, but docker didn't want to merge it. I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor. This was several years ago, now this is not an issue an…

I think the reasoning was that you shouldn't need systemd in docker because the point is for docker itself to containerize each service unit, and use something like docker-compose to manage multiple units. Personally I think that's an aggressive but valid stance because by allowing systemd in docker they'd get a ton of low quality docker images floating around where they launch multiple services within containers, wh…

Sure but what ws their recommended way instead of putting systemd in the image, just use supervisord. Not even comparable.

Anyway , the past is the past. Docker were clearly wrong in their decision to put off systemd inside containers, and was most probably for political reasons because it was very very requested feature.

Re: Docker's Second Death

#286

Post by nikisweeting »

zaro wrote: post #285
nikisweeting wrote: post #284

Earlier quoted context omitted.

I think the reasoning was that you shouldn't need systemd in docker because the point is for docker itself to containerize each service unit, and use something like docker-compose to manage multiple units. Personally I think that's an aggressive but valid stance because by allowing systemd in docker they'd get a ton of low quality docker images floating around where they launch multiple services within containers, wh…

Sure but what ws their recommended way instead of putting systemd in the image, just use supervisord. Not even comparable. Anyway , the past is the past. Docker were clearly wrong in their decision to put off systemd inside containers, and was most probably for political reasons because it was very very requested feature.

I disagree that it was clearly wrong, because supervisord is a vastly simpler service manger than systemd. They wanted to put organizational pressure on people to move away from managing multiple units within a single container with an extremely complex octopus of a unit manager like systemd, and they arguably succeeded at that goal. (Even if it caused short-term discomfort for people who wanted to rely on systemd features within containers.)
Post reply on HN