18 ms·

Talk of a Split from Docker

leetrout 10y ago
Support for legacy OSes in newer releases would be wonderful but I don't know how hard that is... There's a lot of talk about how the older kernel makes it really difficult. If you're using CentOS 6 you're stuck with Docker 1.7. There are a lot of enterprise companies out there (I'm looking at you big banking) that aren't ready to move to CentOS / RHEL 7 and trying to get stable usage out of Docker 1.7 doesn't "Just Work" in my experience. Anyone here use rkt with CentOS 6??
raesene6 10y ago
I'm not really sure why the proponents of this split don't just put their efforts into improving one of the alternatives which are already available (e.g. rkt). A split would seem to be a bad outcome allround (confusion in the market, divided resources, duplicated features), whereas competing products might bring out the best in each other. Also it does seem a little odd to me to see people suggesting that Docker needs to be more stable and "boring" (from this article https://medium.com/@bob_48171/an-ode-to-boring-creating-open-and-stable-container-world-4a7a39971443#.gux8c0bx2 https://medium.com/@bob_48171/an-ode-to-boring-creating-open... referenced in the main link) to fit in with other projects in this space like Kubernetes, when it seems that most/all of these projects including Kubernetes are moving as fast as each other...
- gtirloni 10y ago
  The container runtime is a basic building block. If it moves too fast (and in broken ways), stuff on top of it breaks. If Intel processors came with a completely new instruction set in every generation, it'd be hell. I don't think people are suggesting that Docker Inc. should be boring. The criticism is more targeted towards Docker Engine, the container runtime.
  - raesene6 10y ago
    Personally I think the entire container space moves too quickly to be a good target for stable long lived services. Pretty much every element is under fast development. Stability is more the attribute of more mature services like Virtual machines, which have been around as a heavily used technology for quite a long time now...
- alauda 10y ago
  I don't think rkt is a valid candidate. People are already used to the basic of Docker command. There is no reason to change to something else. If rkt decides to reproduce the feature set, how is that different from a fork?
  - raesene6 10y ago
    So the challenge, to me, is that if you fork docker, then people are going to have to get used to a different command structure anyway as the forks will diverge. One of the reasons to avoid a fork is the confusion caused by two kind of similar but not quite the same implementations that diverge slowly over time. rkt is unlikely to just copy the feature set of Docker, but they provide competition in implementing new ideas and as it's not intended to be identical there's less confusion.
  - creshal 10y ago
    > People are already used to the basic of Docker command. The tiny amount of existing early adopters can be made to adopt something else one more time.
    - lmickh 10y ago
      Not to mention that they constantly break the Docker api and interactions. Knowing the commands today is not helpful in the future. Once you get past "docker run <image>" so much has changed the last couple of years that it is pointless to hold that up as a virtue.
  - Svenskunganka 10y ago
    People being used to the Docker commands is a very weak reason rkt isn't a valid candidate. Let's not forget the most important aspect of rkt, and that is that it follows the container spec standard.
- falcolas 10y ago
  IMO, they shouldn't get behind rkt, because it too is owned and primarily developed by a company who uses it as a commodity to sell their own products as well, and the same concerns arising from Docker wholly owning development against Docker Engine could very easily arise against rkt as well. I believe an independent project managed by a board of shareholders would be better for us all.
  - raesene6 10y ago
    I'd agree that if it seems that containerization is a fundamental part of an OS that it would make sense to have a neutral platform for it. That said there were containerization efforts in this area in the past (e.g. LXC) which never really seemed to attract the same kind of traction as Docker. Ultimtely if people want to create containers, it's entirely possible to do with pure linux commands and no upper-level software at all, it's just Docker makes it much easier/nicer to achieve :)
    - bogomipz 10y ago
      I think that LXC was on a good path if you were an Ubuntu shop, however I think that tying LXD to Openstack was an odd choice.
      - tribaal 10y ago
        How is LXD tied to openstack? You can use LXD in exactly the same way you used LXC (with a nicer CLI interface, no less). nova-lxd adds lxd as a "hypervisor" choice for openstack, but it's a completely optional way to use it. Try it on ubuntu right now: sudo apt-get install lxd; lxc list (yes, the client for lxd is called lxc, it's kind of confusing. Sorry.) Disclaimer: I work for Canonical, but not on LXD (I use it daily outside of openstack though)
    - falcolas 10y ago
      > Ultimately, if people wanted to create [text files], it's entirely possible to do with pure linux commands with no upper level software at all, it's just [Sublime Text] makes it much easier/nicer to achieve. It's absolutely possible (see: Bocker), but not a very productive way to go about things. It's much more productive to take an existing technology and make it better than to start from scratch (yet again), especially with permissive licenses like those used in Docker Engine.
- jjuel 10y ago
  The funny part about this is CoreOS is talked about being one of the players in the article, and they are the developers of rkt.
  - raesene6 10y ago
    Indeed, I did think that was rather odd...
  - robszumski 10y ago
    From the article: > Spokespeople from ... CoreOS denied any knowledge of Docker-related talks.
jondubois 10y ago
That sounds like a bad idea to me. I do agree that Docker rushed things a bit with Swarm (on the orchestration front) but I think that they're doing an excellent job with the containers themselves. I don't think a fork will help - I think a fork would make sense if there were concerns about Docker's level of 'openness' but I think that's not the problem here. Forking/duplicating a technology whose main premise is being "a single consistent environment for running apps" sounds like a contradiction to me.
- sjellis 10y ago
  There are concerns at every level about the decisions coming from Docker, Inc. and there have been consistent issues for a long time. Swarm is just the latest issue, and the arguably the worst, since none of the key decisions are defensible - Why is it there in the core product? Why was it added in a point release? Why was it included at all when it is clearly not stable? Did any major contributor outside Docker, Inc. have any input into this? Ultimately, forking is what happens when the contributors can't work with the maintainer, and it seems pretty clear that Docker, Inc. can't act as responsible maintainers.
- PaulKeeble 10y ago
  I don't feel like that. The Windows release can cause the machine to permenantly loose networking and on Ubuntu 15 the service is causing ridiculous CPU usage on some machines and locking up. Something is broken in the recent releases of the basic engine, its not stable.
Philipp__ 10y ago
Every time I think of Docker recently, the image of huge container ship accident shows up in my head. This thing needs to be standardized, and things are not going that way at the moment.
valarauca1 10y ago
Makes sense. Since the late 90's early 00's when Linux won the data center. Most people became really enjoyed the we don't break user land motto. Once a kernel interface went live, it stayed that way. Ugly spots and all. Containers are starting to become a fairly important part of IT/Cloud infrastructure. Easily compariable to the OS itself. Logically those involved with maintainence would demand the same. Yes I'm aware Docker is more a control program for interacting with Cgroups, setting quotas, installing packages, and isolating processes. Not the OS itself. It is an abstraction over the OS, hence for most developers it feels like part of the OS. So logically they'd demand it be as robust as the OS.
- jwr 10y ago
  I think this is part of a more general trend of companies trying to use software that definitely isn't ready for prime time. Sure, it's trendy and being hyped, but those are not sufficient reasons to use it in production. These days some new technologies become "trendy" (on HN and elsewhere) and start being used by developers. That in itself is great, but many of those developers are also young and inexperienced and do not realize that production systems have different requirements. There are many symptoms: the docker situation, npm (need I say more), libraries like Semantic UI that can't be built in a CI environment from the command line (require user interaction). Even small things, like tools that change their behavior based on files in one of the parent directories (npm again, but not only), or the proliferation of fancy progress bars and useless drivel being spewed to the terminals, are symptoms. Those are tools designed by developers working on their laptops, for developers working on their laptops, and do not (at this stage) fit the requirements of a production server environment. Maturity and stability are valuable traits in software, especially in larger systems.
  - scrollaway 10y ago
    The one that springs to mind for me is terraform. We made the decision to use it in production and it is costing us a lot of time and money. It feels like it will continue costing us a lot of time and money for a long time. It 100% feels like alpha software, yet it's being hyped and overhyped by the tech community. I personally think using it was the right call regardless (the alternatives are worse in the long run), but it's such a massive upfront investment, I couldn't recommend it. One thing though: > tools that change their behavior based on files in one of the parent directories You mean like git? I agree with your general sentiment but you're backing it up very weakly, with essentially irrelevant things. Terminal interactivity is not a bad thing; TUI software is built for humans as well as machines and well behaved components will detect when they are not in a tty.
CSDude 10y ago
Docker's mistake is bundling swarm and throwing away regular docker-compose with services. The bigger mistake was presenting them as they worked perfectly, just because in the sake of a badly timed DockerCon (seriously why the hell do we need 6-month spaced dockercons) they released something that was not complete and fundementally different from previous way of running containers. I feel their urge to monetize but events like this really leaves bad memories. By the way, does anyone remember the service command that was introduced in ~1.8 or 1.9 and just vanished? It was a similar mess.
- bogomipz 10y ago
  Wait did they throw away docker-compose with services in this latest release? I'm not totally up on this release obviously.
  - CSDude 10y ago
    Not actually, but swarm services with docker application bundle (dab) seems like a replacement for docker-compose and makes it redundant. All they had to do was promote compose from a cli tool to docker daemon itself and it would be great, not a major fundemental change. Now, I cannot even get the logs of a service because it is failing too fast and I can't catchup with it.
  - deleted 10y ago
    [deleted]
kozikow 10y ago
Imagine there would be "docker engine for running in production" outside of control of docker inc, with backing from the rest of orchestration industry. It may be considered as a tool for compelling docker inc. to play more nicely, rather than the total fork. - Developers interested only in the docker engine would consider using it for higher reliability, less breaking and rushed changes or force-bundling of things they don't want. - If enough developers are using it, docker inc. would be compelled to maintain compatibility to avoid "mainstream" docker ending up as the tool only for dev/CI.
bootload 10y ago
"What’s happening right now, if we are not careful, will fragment the container ecosystem, and it make it impossible for single containers to target multiple runtimes," UNIX had this problem and look how long it took before things settled. Linux was the result. Maybe this is a good thing?
- pjmlp 10y ago
  Have they really settled? In the 90's we had the UNIX wars. Nowadays we have the GNU/Linux wars. Each distribution does its own thing and every disagreement leads to yet another fork.
  - malingo 10y ago
    Right, so in that context who is the FreeBSD of containers?
    - _delirium 10y ago
      Illumos (formerly OpenSolaris) containers perhaps?
      - Annatar 10y ago
        Those are the ones!
    - Annatar 10y ago
      SmartOS. Solaris zones which SmartOS sports were inspired by BSD jails. I upvoted your question because as far as I can tell, you are the only person here to ask it.
  - deleted 10y ago
    [deleted]
  - randallsquared 10y ago
    The various distros have converged enough that you can typically run any userland program on any recent version of any distro. The recent adoption by virtually everyone of systemd is a sign of this, it seems.
Mizza 10y ago
I feel bad for shykes. This can't have been a very fun release. He tries really hard, and I get the feeling he takes a lot of the feedback to heart.
- subway 10y ago
  He made his bed.
- mentat 10y ago
  He's aggressive and isn't super consistent. In the end I think the conclusion of the Twitter conversation I had with him was good but then you look at the rest of the it and it's just aggressively negative. Conspiracies everywhere.
awinder 10y ago
Beyond API flux, one thing docker could really focus on to alleviate a lot of pain would be to have some more stable / sane version management. If you need to break the API to bring in new features so be it, but maybe a former API client should be able to still interface with newer versions through backwards API support. When docker was new there was maybe a case to be made for stricter version matching, but it's just a sign of immaturity at this point that new versions of dockers upset the rest of the ecosystem so greatly.
- coredog64 10y ago
  Something like the "tick-tock" strategy that Cassandra has adopted?
- digi_owl 10y ago
  You are talking about the web generation here, no F-ing way do they care about API backwards compatibility...
- cyphar 10y ago
  I'm fairly sure that old Docker clients can communicate with new Docker servers (the docker.sock API is versioned and is backwards compatible). If that doesn't work, you should file a bug (there's lots of code inside the API handlers that deals with setting older API version defaults).
falcolas 10y ago
I'm not developing anything against Docker except for automation tooling, and I would kill for a stable Docker Engine; stable disk drivers, stable CLI arguments, stable configuration file formats, a stable daemon, and so on. That said, it's a hard problem, and I certainly don't have the time to work on it myself; nor can my employer spare me to work on them either.
brudgers 10y ago
I'm not saying those looking to fork Docker are wrong. I don't think that they are. But I think Docker's approach to Swarm is more useful than the roadmap that those organizations considering a fork wish to pursue. Kubernetes, Mesos, etc. appear to be great orchestration tools for an organization with a few [or many] engineers dedicated to operations. Their not so great for a small team [or individuals] who are just trying to deploy some software. As I see it, Swarm seeks to solve orchestration analogously to the way Docker seeks to solve containers. Before Docker, LXC was around and the Google's of the world had the engineer-years on staff to make containers work. Docker came along and improved deployment for the ordinary CRUD on Rails developer who just wants to go home at night without worrying about the pager going off. To put it another way, it looks to me like the intent of Swarm is to provide container orchestration for people who don't run a data center. Like Docker, it is an improvement for those scaling up toward clusters not down from the cloud. None of which is to say that moving fast with Swarm isn't a business strategy at Docker. There's a whole lotta' hole in the container market and part of that is because the other organizations currently supporting development of container orchestration tools has business interests at a much larger scale...Google doesn't see a business case for pushing Kubernetes toward the Gmail end of the ease of use spectrum. The desire to fork is based on the needs of the cathedral not those in the bazaar.
- deleted 10y ago
  [deleted]
- sappapp 10y ago
  I work on a small team. We use Mesos and it works for us.
- subway 10y ago
  Docker Inc. is the poster child of the cathedral.
- kislotnik 10y ago
  So what should cathedrals do? Rely on the unpredictive bazaar? They're [Kubernetes, Mesos, etc] not so great for a small team [or individuals] who are just trying to deploy some software The industry consists not only of small teams and individuals, we (by this I mean all IT) also use services provided by cathedrals (AWS) which have to have something stable to rely on
coding123 10y ago
The real reason everyone is upset is that I can now say.. goodbye kub, goodbye mesos, goodbye coreos, your are all complicated. I'm thrilled about docker 1.12 and swarm mode.
- iamthemuffinman 10y ago
  That's not why. Good for you on using Docker 1.12 with Swarm mode, if that's what works for you. Have fun in production.
- raarts 10y ago
  I agree. The big guys are scared. I played with it a lot and the new Docker Swarm mode is really, really great. It's the Digital Ocean of orchestration. Granted, 1.12 is the first incarnation, has flaws and is unfit for production, but that will change. I can wait a few months.
ThePhysicist 10y ago
While Docker is probably not the last word in containerization technology (which is a good thing), the idea behind it is quite powerful: Small, lightweight, self-contained objects that perform a given function and that we can plug together in many ways. I think the impact of having something like this will not be limited to traditional DevOps but will permeate many other areas as well, like data analysis and the delivery of end-user applications.
- metamet 10y ago
  > Small, lightweight, self-contained objects that perform a given function and that we can plug together in many ways. So Unix philosophy?
  - technofiend 10y ago
    You bring up a really good point - that is the UNIX philosophy, but UNIX didn't win the datacenter wars: Linux did. And Linux doesn't entirely share that philosophy; depending on the Linux release it can be the polar opposite; piling on feature after feature into a monolithic block like systemd. That's not an indictment of systemd... it's just an example of how I'm not sure everyone has glommed on to the fact that just a GNU isn't UNIX neither is Linux.
    - felixgallo 10y ago
      systemd is a really recent development. Linux won the datacenter wars well before any of the recent desktop stuff started encroaching, and it did it on the back of being a free Unix clone.
      - digi_owl 10y ago
        Yep. Linux offered a free unix that was not touched by the AT&T lawsuit and could run on commodity hardware. Then we had the whole dot-com bust that freed up a whole lot of hardware to run LAMP stacks on, and things really got rolling.
      - 10y ago
Halienja 10y ago
I hope rkt, runc and similar get donated to the CNC Foundation and get a direction there
- iamthemuffinman 10y ago
  I agree. I said the same thing on a Reddit post.
- cyphar 10y ago
  runC is part of the Open Containers Initiative (which is a project by the Linux Foundation). So there wouldn't be much sense moving runC between two different Linux Foundation projects (especially since the same person [Chris Aniszczyk] is currently managing both projects). Also, since Kubernetes is part of the CNCF I'm hoping that will mean we'll get some support to adding OCI support to Kubernetes (something that we're currently working on).
kharms 10y ago
This seems rather manufactured. In the span of days, we've seen article after article coming out and condemning docker, advising kubernetes, and now this fork. Who benefits?
- mentat 10y ago
  People who want a stable container orchestration engine and through that, the users.
csears 10y ago
I doubt they would ever consider it, but I think Docker Inc's best move would be to push reset for Docker 2.0: - Fully embrace Kubernetes for orchestration - Drop Swarm - Roll Docker Engine back to its pre-1.12 scope - Get on board with standardizing the image format, now - Stop fighting Google and instead let them help you succeed A Docker distro of Kubernetes would do very well in enterprise on-prem or private cloud environments. They already have a great developer experience. Companies will pay for support on both. Continuing to oppose Kubernetes risks damaging the significant brand equity they've accrued as containers in production become mainstream.
- hosh 10y ago
  As the proverb goes, "Choose, or someone will choose for you." rkt is getting into Kubernetes as an alternative runtime engine: http://thenewstack.io/kubernetes-chief-we-back-docker-although-appc-might-have-merit/ http://thenewstack.io/kubernetes-chief-we-back-docker-althou... (2015) http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-container-engine-to-Kubernetes.html http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-contai... (2016) Back then it was, "It's sad to see so much drama; Docker engine has much more traction." Remember all of that? The story is now, "hey, rkt lets us test out our framework for supporting alternative runtime engine". There's a shifting attitude there. Goodwill from the community is eroding. I don't know how long this window will remain open, but it won't remain open indefinitely.
  - amouat 10y ago
    I think there's also momentum to add runc as an alternative runtime engine, which makes sense. Also, Mesos have started shipping their own container runtime. This feels like an inflection point in the history of containers.
    - cyphar 10y ago
      > I think there's also momentum to add runc as an alternative runtime engine, which makes sense. Actually, we're working on getting generic OCI runtimes supported (runC being an example of such a runtime). In principle, you should be able to swap out the OCI runtime and still get Kubernetes to work with that runtime. It's an exciting time. :D
hosh 10y ago
I think a lot of these issues were already nascent when CoreOS decided to fork Docker. People are asking for 'boring container infrastructure' -- and it's called rkt. I remember the bruhaha at the time, with the Docker folks pissed at the CoreOS folks for doing so. That was Dec 2014. It looks like the way Docker handled the 1.12 release is shifting the sentiment. For example: I ended up writing this to ask the Docker team for more transparency on this issue: https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/148 https://forums.docker.com/t/file-access-in-mounted-volumes-e... And they responded with an awesome reply addressing it: https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/158 https://forums.docker.com/t/file-access-in-mounted-volumes-e... and it went a long way towards helping the community understand the issue what to do about helping. However, there are also threads like these that asks for the same issue: https://forums.docker.com/t/should-docker-run-net-host-work/14215 https://forums.docker.com/t/should-docker-run-net-host-work/... https://forums.docker.com/t/access-host-not-vm-from-inside-container/11747/9 https://forums.docker.com/t/access-host-not-vm-from-inside-c... https://forums.docker.com/t/explain-networking-known-limitations-explain-host/15205 https://forums.docker.com/t/explain-networking-known-limitat... They kinda left the community in a limbo here, and quietly added a line in the documentation saying it won't happen. But without the transparency, we don't really know what's going on here. Back then with the rkt split, the Docker design was to gear towards users so that there is as little friction as possible. It worked all right when it was just Docker Engine on Linux. Over time, due to differences in distros, you can see the container abstraction leaking here and there. Generally manageable. In the 18 months since, it's becoming clearer that Docker is drunk on their story. Seems like more and more of the leaks from the abstraction are getting swept under the rug while they are trying to make a land grab for the orchestration. Yet Docker is doing it in a way that is sacrificing the goodwill from the community. It first starts with the third-party vendor relationships, but as you can see from these forum posts, it is starting to leak into the relationship with end-users as well -- the developers. There's still time to turn the (ahem) ship around. But a big part of what is driving Kubernetes success isn't that their abstractions are brilliant, but rather, that project is very transparent and communicative of what they are doing and what they are intending with the community. I get Docker is trying to do that with Docker Swarm, yet I think they missed a critical part of why and how Kubernetes gained so much traction so quickly.
syshum 10y ago
Didnt this happen like 2 years ago when CoreOS created the Rocket Project? https://github.com/coreos/rkt/ https://github.com/coreos/rkt/
- digi_owl 10y ago
  When i noticed the posting mentioning CoreOS and Red Hat i found myself thinking that both of them would not mind seeing Docker go belly up. This because both are in deep with Systemd, and it is at this point offering a straight up competitor to Docker.
jaboutboul 10y ago
I think this is all a push by Docker's management to get the company acquired
geggam 10y ago
I am sort of curious. 1. Who is running docker in production. 2. If you are running docker in production what sort of money are you making with it ?
dmourati 10y ago
This sounds like a bluff to me. "Oh, you want fast moving changes, mobility up the stack, and centralized control? We want none of those things. Either you soften your stance and start listening or we'll fork."
joostdevries 10y ago
Sounds like the Docker container format should be split of into an independent foundation. Because everybody wants to use it but there's no money to be made of it. Then companies can compete on how to run Docker in production.
- gtirloni 10y ago
  That is/was supposed to be what OpenContainers.org (OCI) is all about.
  - joostdevries 10y ago
    Good point. I guess there's more that should be a shared commonly funded resource: probably the core engine.
duncanjw 10y ago
See also https://news.ycombinator.com/item?id=12364123 https://news.ycombinator.com/item?id=12364123
Annatar 10y ago
So instead of going to working, stable alternatives to Docker like SmartOS, people still cling on to it and try everything and anything to save it! I'll be damned if I understand why someone would continue to cling on to broken software[1] when there is a working alternative. Can someone explain this irrationality in terms which I can understand? [1] https://news.ycombinator.com/item?id=12377457 https://news.ycombinator.com/item?id=12377457
twblalock 10y ago
Maybe Docker should do what Ubuntu does: periodic LTS releases with a guaranteed support timeframe. They can experiment with the newer releases, and the LTS releases will be there for people who need stability and don't need bleeding-edge, unproven features.
madmax96 10y ago
> The Docker orchestration capabilities are opt-in; they must be activated by the user. Though not opting in may lead to backward compatibility issues down the road. Whoa, citation needed! Not activating swarm features has the same probability of causing problems as relying on fork() to create a process. Maybe not, but I don't see Docker suddenly forcing everyone into using swarm. It seems unreasonable to even suggest this, and a bit of a scare tactic.

Support for legacy OSes in newer releases would be wonderful but I don't know how hard that is... There's a lot of talk about how the older kernel makes it really difficult. If you're using CentOS 6 you're stuck with Docker 1.7. There are a lot of enterprise companies out there (I'm looking at you big banking) that aren't ready to move to CentOS / RHEL 7 and trying to get stable usage out of Docker 1.7 doesn't "Just Work" in my experience. Anyone here use rkt with CentOS 6??

raesene6 10y ago

I'm not really sure why the proponents of this split don't just put their efforts into improving one of the alternatives which are already available (e.g. rkt). A split would seem to be a bad outcome allround (confusion in the market, divided resources, duplicated features), whereas competing products might bring out the best in each other. Also it does seem a little odd to me to see people suggesting that Docker needs to be more stable and "boring" (from this article https://medium.com/@bob_48171/an-ode-to-boring-creating-open-and-stable-container-world-4a7a39971443#.gux8c0bx2 https://medium.com/@bob_48171/an-ode-to-boring-creating-open... referenced in the main link) to fit in with other projects in this space like Kubernetes, when it seems that most/all of these projects including Kubernetes are moving as fast as each other...

gtirloni 10y ago
The container runtime is a basic building block. If it moves too fast (and in broken ways), stuff on top of it breaks. If Intel processors came with a completely new instruction set in every generation, it'd be hell. I don't think people are suggesting that Docker Inc. should be boring. The criticism is more targeted towards Docker Engine, the container runtime.
- raesene6 10y ago
  Personally I think the entire container space moves too quickly to be a good target for stable long lived services. Pretty much every element is under fast development. Stability is more the attribute of more mature services like Virtual machines, which have been around as a heavily used technology for quite a long time now...
alauda 10y ago
I don't think rkt is a valid candidate. People are already used to the basic of Docker command. There is no reason to change to something else. If rkt decides to reproduce the feature set, how is that different from a fork?
- raesene6 10y ago
  So the challenge, to me, is that if you fork docker, then people are going to have to get used to a different command structure anyway as the forks will diverge. One of the reasons to avoid a fork is the confusion caused by two kind of similar but not quite the same implementations that diverge slowly over time. rkt is unlikely to just copy the feature set of Docker, but they provide competition in implementing new ideas and as it's not intended to be identical there's less confusion.
- creshal 10y ago
  > People are already used to the basic of Docker command. The tiny amount of existing early adopters can be made to adopt something else one more time.
  - lmickh 10y ago
    Not to mention that they constantly break the Docker api and interactions. Knowing the commands today is not helpful in the future. Once you get past "docker run <image>" so much has changed the last couple of years that it is pointless to hold that up as a virtue.
- Svenskunganka 10y ago
  People being used to the Docker commands is a very weak reason rkt isn't a valid candidate. Let's not forget the most important aspect of rkt, and that is that it follows the container spec standard.
falcolas 10y ago
IMO, they shouldn't get behind rkt, because it too is owned and primarily developed by a company who uses it as a commodity to sell their own products as well, and the same concerns arising from Docker wholly owning development against Docker Engine could very easily arise against rkt as well. I believe an independent project managed by a board of shareholders would be better for us all.
- raesene6 10y ago
  I'd agree that if it seems that containerization is a fundamental part of an OS that it would make sense to have a neutral platform for it. That said there were containerization efforts in this area in the past (e.g. LXC) which never really seemed to attract the same kind of traction as Docker. Ultimtely if people want to create containers, it's entirely possible to do with pure linux commands and no upper-level software at all, it's just Docker makes it much easier/nicer to achieve :)
  - bogomipz 10y ago
    I think that LXC was on a good path if you were an Ubuntu shop, however I think that tying LXD to Openstack was an odd choice.
    - tribaal 10y ago
      How is LXD tied to openstack? You can use LXD in exactly the same way you used LXC (with a nicer CLI interface, no less). nova-lxd adds lxd as a "hypervisor" choice for openstack, but it's a completely optional way to use it. Try it on ubuntu right now: sudo apt-get install lxd; lxc list (yes, the client for lxd is called lxc, it's kind of confusing. Sorry.) Disclaimer: I work for Canonical, but not on LXD (I use it daily outside of openstack though)
  - falcolas 10y ago
    > Ultimately, if people wanted to create [text files], it's entirely possible to do with pure linux commands with no upper level software at all, it's just [Sublime Text] makes it much easier/nicer to achieve. It's absolutely possible (see: Bocker), but not a very productive way to go about things. It's much more productive to take an existing technology and make it better than to start from scratch (yet again), especially with permissive licenses like those used in Docker Engine.
jjuel 10y ago
The funny part about this is CoreOS is talked about being one of the players in the article, and they are the developers of rkt.
- raesene6 10y ago
  Indeed, I did think that was rather odd...
- robszumski 10y ago
  From the article: > Spokespeople from ... CoreOS denied any knowledge of Docker-related talks.

jondubois 10y ago

That sounds like a bad idea to me. I do agree that Docker rushed things a bit with Swarm (on the orchestration front) but I think that they're doing an excellent job with the containers themselves. I don't think a fork will help - I think a fork would make sense if there were concerns about Docker's level of 'openness' but I think that's not the problem here. Forking/duplicating a technology whose main premise is being "a single consistent environment for running apps" sounds like a contradiction to me.

sjellis 10y ago
There are concerns at every level about the decisions coming from Docker, Inc. and there have been consistent issues for a long time. Swarm is just the latest issue, and the arguably the worst, since none of the key decisions are defensible - Why is it there in the core product? Why was it added in a point release? Why was it included at all when it is clearly not stable? Did any major contributor outside Docker, Inc. have any input into this? Ultimately, forking is what happens when the contributors can't work with the maintainer, and it seems pretty clear that Docker, Inc. can't act as responsible maintainers.
PaulKeeble 10y ago
I don't feel like that. The Windows release can cause the machine to permenantly loose networking and on Ubuntu 15 the service is causing ridiculous CPU usage on some machines and locking up. Something is broken in the recent releases of the basic engine, its not stable.

Philipp__ 10y ago

Every time I think of Docker recently, the image of huge container ship accident shows up in my head. This thing needs to be standardized, and things are not going that way at the moment.

valarauca1 10y ago

Makes sense. Since the late 90's early 00's when Linux won the data center. Most people became really enjoyed the we don't break user land motto. Once a kernel interface went live, it stayed that way. Ugly spots and all. Containers are starting to become a fairly important part of IT/Cloud infrastructure. Easily compariable to the OS itself. Logically those involved with maintainence would demand the same. Yes I'm aware Docker is more a control program for interacting with Cgroups, setting quotas, installing packages, and isolating processes. Not the OS itself. It is an abstraction over the OS, hence for most developers it feels like part of the OS. So logically they'd demand it be as robust as the OS.

jwr 10y ago
I think this is part of a more general trend of companies trying to use software that definitely isn't ready for prime time. Sure, it's trendy and being hyped, but those are not sufficient reasons to use it in production. These days some new technologies become "trendy" (on HN and elsewhere) and start being used by developers. That in itself is great, but many of those developers are also young and inexperienced and do not realize that production systems have different requirements. There are many symptoms: the docker situation, npm (need I say more), libraries like Semantic UI that can't be built in a CI environment from the command line (require user interaction). Even small things, like tools that change their behavior based on files in one of the parent directories (npm again, but not only), or the proliferation of fancy progress bars and useless drivel being spewed to the terminals, are symptoms. Those are tools designed by developers working on their laptops, for developers working on their laptops, and do not (at this stage) fit the requirements of a production server environment. Maturity and stability are valuable traits in software, especially in larger systems.
- scrollaway 10y ago
  The one that springs to mind for me is terraform. We made the decision to use it in production and it is costing us a lot of time and money. It feels like it will continue costing us a lot of time and money for a long time. It 100% feels like alpha software, yet it's being hyped and overhyped by the tech community. I personally think using it was the right call regardless (the alternatives are worse in the long run), but it's such a massive upfront investment, I couldn't recommend it. One thing though: > tools that change their behavior based on files in one of the parent directories You mean like git? I agree with your general sentiment but you're backing it up very weakly, with essentially irrelevant things. Terminal interactivity is not a bad thing; TUI software is built for humans as well as machines and well behaved components will detect when they are not in a tty.

CSDude 10y ago

Docker's mistake is bundling swarm and throwing away regular docker-compose with services. The bigger mistake was presenting them as they worked perfectly, just because in the sake of a badly timed DockerCon (seriously why the hell do we need 6-month spaced dockercons) they released something that was not complete and fundementally different from previous way of running containers. I feel their urge to monetize but events like this really leaves bad memories. By the way, does anyone remember the service command that was introduced in ~1.8 or 1.9 and just vanished? It was a similar mess.

bogomipz 10y ago
Wait did they throw away docker-compose with services in this latest release? I'm not totally up on this release obviously.
- CSDude 10y ago
  Not actually, but swarm services with docker application bundle (dab) seems like a replacement for docker-compose and makes it redundant. All they had to do was promote compose from a cli tool to docker daemon itself and it would be great, not a major fundemental change. Now, I cannot even get the logs of a service because it is failing too fast and I can't catchup with it.
- deleted 10y ago
  [deleted]

kozikow 10y ago

Imagine there would be "docker engine for running in production" outside of control of docker inc, with backing from the rest of orchestration industry. It may be considered as a tool for compelling docker inc. to play more nicely, rather than the total fork. - Developers interested only in the docker engine would consider using it for higher reliability, less breaking and rushed changes or force-bundling of things they don't want. - If enough developers are using it, docker inc. would be compelled to maintain compatibility to avoid "mainstream" docker ending up as the tool only for dev/CI.

bootload 10y ago

"What’s happening right now, if we are not careful, will fragment the container ecosystem, and it make it impossible for single containers to target multiple runtimes," UNIX had this problem and look how long it took before things settled. Linux was the result. Maybe this is a good thing?

pjmlp 10y ago
Have they really settled? In the 90's we had the UNIX wars. Nowadays we have the GNU/Linux wars. Each distribution does its own thing and every disagreement leads to yet another fork.
- malingo 10y ago
  Right, so in that context who is the FreeBSD of containers?
  - _delirium 10y ago
    Illumos (formerly OpenSolaris) containers perhaps?
    - Annatar 10y ago
      Those are the ones!
  - Annatar 10y ago
    SmartOS. Solaris zones which SmartOS sports were inspired by BSD jails. I upvoted your question because as far as I can tell, you are the only person here to ask it.
- deleted 10y ago
  [deleted]
- randallsquared 10y ago
  The various distros have converged enough that you can typically run any userland program on any recent version of any distro. The recent adoption by virtually everyone of systemd is a sign of this, it seems.

Mizza 10y ago

I feel bad for shykes. This can't have been a very fun release. He tries really hard, and I get the feeling he takes a lot of the feedback to heart.

subway 10y ago
He made his bed.
mentat 10y ago
He's aggressive and isn't super consistent. In the end I think the conclusion of the Twitter conversation I had with him was good but then you look at the rest of the it and it's just aggressively negative. Conspiracies everywhere.

awinder 10y ago

Beyond API flux, one thing docker could really focus on to alleviate a lot of pain would be to have some more stable / sane version management. If you need to break the API to bring in new features so be it, but maybe a former API client should be able to still interface with newer versions through backwards API support. When docker was new there was maybe a case to be made for stricter version matching, but it's just a sign of immaturity at this point that new versions of dockers upset the rest of the ecosystem so greatly.

coredog64 10y ago
Something like the "tick-tock" strategy that Cassandra has adopted?
digi_owl 10y ago
You are talking about the web generation here, no F-ing way do they care about API backwards compatibility...
cyphar 10y ago
I'm fairly sure that old Docker clients can communicate with new Docker servers (the docker.sock API is versioned and is backwards compatible). If that doesn't work, you should file a bug (there's lots of code inside the API handlers that deals with setting older API version defaults).

falcolas 10y ago

I'm not developing anything against Docker except for automation tooling, and I would kill for a stable Docker Engine; stable disk drivers, stable CLI arguments, stable configuration file formats, a stable daemon, and so on. That said, it's a hard problem, and I certainly don't have the time to work on it myself; nor can my employer spare me to work on them either.

brudgers 10y ago

I'm not saying those looking to fork Docker are wrong. I don't think that they are. But I think Docker's approach to Swarm is more useful than the roadmap that those organizations considering a fork wish to pursue. Kubernetes, Mesos, etc. appear to be great orchestration tools for an organization with a few [or many] engineers dedicated to operations. Their not so great for a small team [or individuals] who are just trying to deploy some software. As I see it, Swarm seeks to solve orchestration analogously to the way Docker seeks to solve containers. Before Docker, LXC was around and the Google's of the world had the engineer-years on staff to make containers work. Docker came along and improved deployment for the ordinary CRUD on Rails developer who just wants to go home at night without worrying about the pager going off. To put it another way, it looks to me like the intent of Swarm is to provide container orchestration for people who don't run a data center. Like Docker, it is an improvement for those scaling up toward clusters not down from the cloud. None of which is to say that moving fast with Swarm isn't a business strategy at Docker. There's a whole lotta' hole in the container market and part of that is because the other organizations currently supporting development of container orchestration tools has business interests at a much larger scale...Google doesn't see a business case for pushing Kubernetes toward the Gmail end of the ease of use spectrum. The desire to fork is based on the needs of the cathedral not those in the bazaar.

deleted 10y ago
[deleted]
sappapp 10y ago
I work on a small team. We use Mesos and it works for us.
subway 10y ago
Docker Inc. is the poster child of the cathedral.
kislotnik 10y ago
So what should cathedrals do? Rely on the unpredictive bazaar? They're [Kubernetes, Mesos, etc] not so great for a small team [or individuals] who are just trying to deploy some software The industry consists not only of small teams and individuals, we (by this I mean all IT) also use services provided by cathedrals (AWS) which have to have something stable to rely on

coding123 10y ago

The real reason everyone is upset is that I can now say.. goodbye kub, goodbye mesos, goodbye coreos, your are all complicated. I'm thrilled about docker 1.12 and swarm mode.

iamthemuffinman 10y ago
That's not why. Good for you on using Docker 1.12 with Swarm mode, if that's what works for you. Have fun in production.
raarts 10y ago
I agree. The big guys are scared. I played with it a lot and the new Docker Swarm mode is really, really great. It's the Digital Ocean of orchestration. Granted, 1.12 is the first incarnation, has flaws and is unfit for production, but that will change. I can wait a few months.

ThePhysicist 10y ago

While Docker is probably not the last word in containerization technology (which is a good thing), the idea behind it is quite powerful: Small, lightweight, self-contained objects that perform a given function and that we can plug together in many ways. I think the impact of having something like this will not be limited to traditional DevOps but will permeate many other areas as well, like data analysis and the delivery of end-user applications.

metamet 10y ago
> Small, lightweight, self-contained objects that perform a given function and that we can plug together in many ways. So Unix philosophy?
- technofiend 10y ago
  You bring up a really good point - that is the UNIX philosophy, but UNIX didn't win the datacenter wars: Linux did. And Linux doesn't entirely share that philosophy; depending on the Linux release it can be the polar opposite; piling on feature after feature into a monolithic block like systemd. That's not an indictment of systemd... it's just an example of how I'm not sure everyone has glommed on to the fact that just a GNU isn't UNIX neither is Linux.
  - felixgallo 10y ago
    systemd is a really recent development. Linux won the datacenter wars well before any of the recent desktop stuff started encroaching, and it did it on the back of being a free Unix clone.
    - digi_owl 10y ago
      Yep. Linux offered a free unix that was not touched by the AT&T lawsuit and could run on commodity hardware. Then we had the whole dot-com bust that freed up a whole lot of hardware to run LAMP stacks on, and things really got rolling.
    - 10y ago

Halienja 10y ago

I hope rkt, runc and similar get donated to the CNC Foundation and get a direction there

iamthemuffinman 10y ago
I agree. I said the same thing on a Reddit post.
cyphar 10y ago
runC is part of the Open Containers Initiative (which is a project by the Linux Foundation). So there wouldn't be much sense moving runC between two different Linux Foundation projects (especially since the same person [Chris Aniszczyk] is currently managing both projects). Also, since Kubernetes is part of the CNCF I'm hoping that will mean we'll get some support to adding OCI support to Kubernetes (something that we're currently working on).

kharms 10y ago

This seems rather manufactured. In the span of days, we've seen article after article coming out and condemning docker, advising kubernetes, and now this fork. Who benefits?

mentat 10y ago
People who want a stable container orchestration engine and through that, the users.

csears 10y ago

I doubt they would ever consider it, but I think Docker Inc's best move would be to push reset for Docker 2.0: - Fully embrace Kubernetes for orchestration - Drop Swarm - Roll Docker Engine back to its pre-1.12 scope - Get on board with standardizing the image format, now - Stop fighting Google and instead let them help you succeed A Docker distro of Kubernetes would do very well in enterprise on-prem or private cloud environments. They already have a great developer experience. Companies will pay for support on both. Continuing to oppose Kubernetes risks damaging the significant brand equity they've accrued as containers in production become mainstream.

hosh 10y ago
As the proverb goes, "Choose, or someone will choose for you." rkt is getting into Kubernetes as an alternative runtime engine: http://thenewstack.io/kubernetes-chief-we-back-docker-although-appc-might-have-merit/ http://thenewstack.io/kubernetes-chief-we-back-docker-althou... (2015) http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-container-engine-to-Kubernetes.html http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-contai... (2016) Back then it was, "It's sad to see so much drama; Docker engine has much more traction." Remember all of that? The story is now, "hey, rkt lets us test out our framework for supporting alternative runtime engine". There's a shifting attitude there. Goodwill from the community is eroding. I don't know how long this window will remain open, but it won't remain open indefinitely.
- amouat 10y ago
  I think there's also momentum to add runc as an alternative runtime engine, which makes sense. Also, Mesos have started shipping their own container runtime. This feels like an inflection point in the history of containers.
  - cyphar 10y ago
    > I think there's also momentum to add runc as an alternative runtime engine, which makes sense. Actually, we're working on getting generic OCI runtimes supported (runC being an example of such a runtime). In principle, you should be able to swap out the OCI runtime and still get Kubernetes to work with that runtime. It's an exciting time. :D

hosh 10y ago

I think a lot of these issues were already nascent when CoreOS decided to fork Docker. People are asking for 'boring container infrastructure' -- and it's called rkt. I remember the bruhaha at the time, with the Docker folks pissed at the CoreOS folks for doing so. That was Dec 2014. It looks like the way Docker handled the 1.12 release is shifting the sentiment. For example: I ended up writing this to ask the Docker team for more transparency on this issue: https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/148 https://forums.docker.com/t/file-access-in-mounted-volumes-e... And they responded with an awesome reply addressing it: https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/158 https://forums.docker.com/t/file-access-in-mounted-volumes-e... and it went a long way towards helping the community understand the issue what to do about helping. However, there are also threads like these that asks for the same issue: https://forums.docker.com/t/should-docker-run-net-host-work/14215 https://forums.docker.com/t/should-docker-run-net-host-work/... https://forums.docker.com/t/access-host-not-vm-from-inside-container/11747/9 https://forums.docker.com/t/access-host-not-vm-from-inside-c... https://forums.docker.com/t/explain-networking-known-limitations-explain-host/15205 https://forums.docker.com/t/explain-networking-known-limitat... They kinda left the community in a limbo here, and quietly added a line in the documentation saying it won't happen. But without the transparency, we don't really know what's going on here. Back then with the rkt split, the Docker design was to gear towards users so that there is as little friction as possible. It worked all right when it was just Docker Engine on Linux. Over time, due to differences in distros, you can see the container abstraction leaking here and there. Generally manageable. In the 18 months since, it's becoming clearer that Docker is drunk on their story. Seems like more and more of the leaks from the abstraction are getting swept under the rug while they are trying to make a land grab for the orchestration. Yet Docker is doing it in a way that is sacrificing the goodwill from the community. It first starts with the third-party vendor relationships, but as you can see from these forum posts, it is starting to leak into the relationship with end-users as well -- the developers. There's still time to turn the (ahem) ship around. But a big part of what is driving Kubernetes success isn't that their abstractions are brilliant, but rather, that project is very transparent and communicative of what they are doing and what they are intending with the community. I get Docker is trying to do that with Docker Swarm, yet I think they missed a critical part of why and how Kubernetes gained so much traction so quickly.

syshum 10y ago

Didnt this happen like 2 years ago when CoreOS created the Rocket Project? https://github.com/coreos/rkt/ https://github.com/coreos/rkt/

digi_owl 10y ago
When i noticed the posting mentioning CoreOS and Red Hat i found myself thinking that both of them would not mind seeing Docker go belly up. This because both are in deep with Systemd, and it is at this point offering a straight up competitor to Docker.

jaboutboul 10y ago

I think this is all a push by Docker's management to get the company acquired

geggam 10y ago

I am sort of curious. 1. Who is running docker in production. 2. If you are running docker in production what sort of money are you making with it ?

dmourati 10y ago

This sounds like a bluff to me. "Oh, you want fast moving changes, mobility up the stack, and centralized control? We want none of those things. Either you soften your stance and start listening or we'll fork."

joostdevries 10y ago

Sounds like the Docker container format should be split of into an independent foundation. Because everybody wants to use it but there's no money to be made of it. Then companies can compete on how to run Docker in production.

gtirloni 10y ago
That is/was supposed to be what OpenContainers.org (OCI) is all about.
- joostdevries 10y ago
  Good point. I guess there's more that should be a shared commonly funded resource: probably the core engine.

duncanjw 10y ago

See also https://news.ycombinator.com/item?id=12364123 https://news.ycombinator.com/item?id=12364123

Annatar 10y ago

So instead of going to working, stable alternatives to Docker like SmartOS, people still cling on to it and try everything and anything to save it! I'll be damned if I understand why someone would continue to cling on to broken software[1] when there is a working alternative. Can someone explain this irrationality in terms which I can understand? [1] https://news.ycombinator.com/item?id=12377457 https://news.ycombinator.com/item?id=12377457

twblalock 10y ago

Maybe Docker should do what Ubuntu does: periodic LTS releases with a guaranteed support timeframe. They can experiment with the newer releases, and the LTS releases will be there for people who need stability and don't need bleeding-edge, unproven features.

madmax96 10y ago

> The Docker orchestration capabilities are opt-in; they must be activated by the user. Though not opting in may lead to backward compatibility issues down the road. Whoa, citation needed! Not activating swarm features has the same probability of causing problems as relying on fork() to create a process. Maybe not, but I don't see Docker suddenly forcing everyone into using swarm. It seems unreasonable to even suggest this, and a bit of a scare tactic.