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

Running containers without Docker

jvns.ca

Post reply on HN
Print view View original

91–100 of 140 posts

Re: Running containers without Docker

#91

Post by cyphar »

Note that you can use runC (the underlying runtime for Docker) in a similar way to rkt (except you also don't have to deal with images if you don't want to -- runC just runs a rootfs). And runC doesn't have a daemon as well, and is the canonical implementation of the Open Container Initiative runtime specification. We're also working on ocid, which is a way to run kubernetes purely on an OCI stack (no Docker required).

Though, shoutouts to the rkt guys. They really are awesome and have been helping out a lot in the OCI effort.

Re: Running containers without Docker

#92

Post by cyphar »

wlamartin wrote: post #86
alex- wrote: post #19

I was introduced to linux cgroups and namespaces via my use of docker. It is a fantastic tool for using these concepts quickly and I don't currently see rocket etc overthrowing dockers dominance in the market place. However I do sense (and feel my self at times) a growing upset with the usability/ stability of the docker engine. The OCI (Open Container Initiative) should allow new solutions to come to market without…

Yep, the OCI is doing great stuff. At the bottom of the Cloud Foundry stack we have Garden-Runc ( https://github.com/cloudfoundry/garden-runc-release ). In past we had our own homegrown containerization technology and we're super happy to have been able to swap that out entirely in place of runc - it allows us to make use of the significant engineering talent contributed and has enabled us to move faster and reduce r…

> Yep, the OCI is doing great stuff. At the bottom of the Cloud Foundry stack we have Garden-Runc (https://github.com/cloudfoundry/garden-runc-release). In past we had our own homegrown containerization technology and we're super happy to have been able to swap that out entirely in place of runc - it allows us to make use of the significant engineering talent contributed and has enabled us to move faster and reduce risk.

Hi! I'm one of the maintainers of runC and I wanted to say that the CF stuff around runC is awesome. Keep it up. :D

> I believe the Kubernetes team is working on a simple implementation of the Kube API which is a thin wrapper around runc as well - so you're right, there are some cool things coming around as a result of the OCI.

Actually, ocid is mostly being worked on by people from the OCI community (runcom, mrunalp, myself and others). Though we are getting support from the Kubernetes folks with it, which is pretty cool. :D

Re: Running containers without Docker

#94

Post by luca_ing »

tlrobinson wrote: post #75
throw2016 wrote: post #51

I think when it comes to containers HN has been guilty of a shocking lack of scrutiny and unilaterally hyping Docker. For example Docker was based on LXC till 0.9 but was so successful in hype and misdirection of the project it's based on that till today most commentators here do not seem to have a proper idea of the LXC project and whatever ideas they have are negative. How did this come to be? I don't know how heal…

Docker is a case where "the whole is greater than the sum of its parts". Yes, LXC and cgroups and aufs and overlayfs and whatever else do a lot of the heavy lifting, but Docker glued it all together in a way that was approachable by any developer, not just Linux geeks. I remember briefly looking into LXC ~6 years ago and being totally lost. Then Docker came along with a simple command line interface and growing repos…

> but Docker glued it all together in a way that was approachable by any developer, not just Linux geeks.

> I remember briefly looking into LXC ~6 years ago and being totally lost. Then Docker came along with a simple command line interface and growing repository of images.

I'm not trying to discount your experience in any way, but, remarkably, my impression of Docker was exactly the opposite.

I personally find LXC to be very plain, simple and easy to understand, whereas docker seems intimidatingly opaque and confusing.

But then again, I am a Linux geek :-)

Re: Running containers without Docker

#95

Post by dustinmoris »

I don't get the author. So to sum it up, they like what Docker did with containers, but they don't want to use Docker, at least not immediately, because it requires to learn a few Docker commands and a bit other stuff and therefore they decided to build their own hybrid shit, which will take them probably more time to build than to learn Docker and then on top of that still need to train their employees on that as well, instead of using a well working, vibrant, healthy eco system, build by someone else, for free?

I cannot help myself but that sounds like the worst idea ever and totally backwards. Particularly when they she said that they want to run containers reliably in production, how do they think they are going to do this? The reason why Docker is a "little" bit more than just `Docker run` is so you can run containers reliably and in case of a fail over recover quickly. So how are they planning to run containers reliably in production without adopting an existing, well tested, well working framework?

Re: Running containers without Docker

#96

Post by imtringued »

moondev wrote: post #29
zzzcpan wrote: post #26

Earlier quoted context omitted.

Recently tried to run docker on Ubuntu Desktop 14.04. After googling a bunch of errors, trying different versions, but still failing decided to try rkt. That one worked out of the box, but apart from a bunch of simple images failed to run the caffe docker image. So, my motivation of running without docker would be to understand every little thing they do to actually be able to use them and rely on them.

curl -sSL https://get.docker.com/ | sh sudo usermod -aG docker $your_user There ya go. In newer distros its as easy as apt-get install docker.io

Adding a user to the dockergroup is a bad idea on a desktop.

Re: Running containers without Docker

#97

Post by fauigerzigerk »

dustinmoris wrote: post #95

I don't get the author. So to sum it up, they like what Docker did with containers, but they don't want to use Docker, at least not immediately, because it requires to learn a few Docker commands and a bit other stuff and therefore they decided to build their own hybrid shit, which will take them probably more time to build than to learn Docker and then on top of that still need to train their employees on that as we…

>Particularly when they she said that they want to run containers reliably in production, how do they think they are going to do this?

As I understand it, they keep doing what they have been doing all along, including everything that currently makes their system reliable, and gradually add some of the desirable features of containers in a way they can fully understand.

That doesn't sound like the worst idea ever to me. The danger of ending up with too much of a homegrown snowflake is of course real. You're not wrong about that. But she described the risks of the alternative approaches pretty well I think.

Re: Running containers without Docker

#98

Post by dustinmoris »

fauigerzigerk wrote: post #97
dustinmoris wrote: post #95

I don't get the author. So to sum it up, they like what Docker did with containers, but they don't want to use Docker, at least not immediately, because it requires to learn a few Docker commands and a bit other stuff and therefore they decided to build their own hybrid shit, which will take them probably more time to build than to learn Docker and then on top of that still need to train their employees on that as we…

>Particularly when they she said that they want to run containers reliably in production, how do they think they are going to do this? As I understand it, they keep doing what they have been doing all along, including everything that currently makes their system reliable, and gradually add some of the desirable features of containers in a way they can fully understand. That doesn't sound like the worst idea ever to m…

I don't get what the issue is with the migration plan to Docker either. You have a big system with many components. The best way to start is build a Hello world app on Docker and orchestrate it with whatever framework you think suits best your requirements, let's say Kubernetes. Then run that hello world stuff for a while to get a POC and make yourself familiar with the sytem. After that start converting 1 of the many services to a dockerized service and run it side by side in your new infrastructure. Maybe even load balance some of the traffic progressively over to the new stuff until you are confident enough to run 100% load on that migrated servcie. By then you should be pretty experienced with the most part and have a great recipe to migrate the rest slowly over. I don't see a reason why you would want to start with a homegrown solution at any point in this process.

Re: Running containers without Docker

#99

Post by lmm »

dustinmoris wrote: post #98
fauigerzigerk wrote: post #97

Earlier quoted context omitted.

>Particularly when they she said that they want to run containers reliably in production, how do they think they are going to do this? As I understand it, they keep doing what they have been doing all along, including everything that currently makes their system reliable, and gradually add some of the desirable features of containers in a way they can fully understand. That doesn't sound like the worst idea ever to m…

I don't get what the issue is with the migration plan to Docker either. You have a big system with many components. The best way to start is build a Hello world app on Docker and orchestrate it with whatever framework you think suits best your requirements, let's say Kubernetes. Then run that hello world stuff for a while to get a POC and make yourself familiar with the sytem. After that start converting 1 of the man…

The whole "vertical change vs horizontal change" section of the article is literally all about this exact subject.

Re: Running containers without Docker

#100

Post by dustinmoris »

lmm wrote: post #99
dustinmoris wrote: post #98

Earlier quoted context omitted.

I don't get what the issue is with the migration plan to Docker either. You have a big system with many components. The best way to start is build a Hello world app on Docker and orchestrate it with whatever framework you think suits best your requirements, let's say Kubernetes. Then run that hello world stuff for a while to get a POC and make yourself familiar with the sytem. After that start converting 1 of the man…

The whole "vertical change vs horizontal change" section of the article is literally all about this exact subject.

Yeah and I don't see how that is any good. Making small changes across your entire infrastructure means that everything will move extremely slowly. I cannot imagine that the entire infrastructure even deserves to be moved. What's wrong by just leaving some really old, solid working, but less critical stuff just on the old infrastructure until it gets phased out one day? It feels like a waste of time and resources to force a horizontal move across everything. Also technologies like containers and Docker are extremely fast moving at the moment. It might very well be that some parts cannot be moved immediately today, but in 6-12 months time they can and if you follow their migration plan then meanwhile a whole lot of other stuff which could really benefit from the new infrastructure will have to miss out. Also if you discover an issue very late then you ended up with moving a lot of things back and fourth, even if it is just a small step.
Post reply on HN