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

71–80 of 140 posts

Re: Running containers without Docker

#71

Post by simstein »

schmichael wrote: post #36
random567 wrote: post #32

I don't get the differentiation between "rkt" and "docker". What complexity does Docker add? Separate networking? Difficulty communicating between processes? Just trying to understand why rkt is less overhead...

One large difference is that docker has a daemon that exposes an HTTP API and acts more or less like an init for containers. The docker daemon has historically had some stability issues as well as some security implications. Running a command line tool like rkt is a vastly smaller attack surface and less complex stack overall.

Could you please give a hint on what kind of stability issues you experienced? Do they still exist? My team is thinking about using Docker for high loaded system in production, and stability is one of our priorities here.

Re: Running containers without Docker

#72

Post by 2trill2spill »

indexerror wrote: post #67
2trill2spill wrote: post #60

Earlier quoted context omitted.

> How can Docker run on FreeBSD when FreeBSD has no cgroups? I think you misread/misinterpreted your reference. FreeBSD can run 64 bit and 32 bit Linux binaries via it's Linux emulator[1]. Plus FreeBSD has had containers since FreeBSD 4 which was released in March of 2000, except containers on FreeBSD are called jails. > If MacOS doesn't have certain linux kernel features, neither does FreeBSD. Just because one opera…

Jails are considerably different than containers. Jails are more like chroot jails on linux instead. Edit: My viewpoint was focused more on the composability aspect of containers. But I stand corrected otherwise.

> Jails are considerably different than containers. Jails are more like chroot jails on linux instead.

Thats incorrect both jails and "containers" are examples of OS level virtualization[1]. Instead of virtualizing the hardware you virtualize the operating system, ie system call table.

[1]: https://en.wikipedia.org/wiki/Operating-system-level_virtual...

Re: Running containers without Docker

#73

Post by seabrookmx »

vacri wrote: post #68
nzoschke wrote: post #49

Earlier quoted context omitted.

Convox founder here. Thanks for the shout out! We are indeed building a private Heroku like platform so you don't have to. It's a simple of layer around AWS so it doesn't add extra craziness some other approaches do. As for the OP, her approach is spot on! Containerizing your app is the first step in future proofing it. Doing so correctly will remove layers and therefore simplify things. You now are looking at a pack…

I hate nagios as much as the next op, but what is so magical about containers that your services will no longer require an outage alerting mechanism?

> run containers on ECS

Presumably ECS has its own alerting mechanisms similar to CloudFormation and ElasticBeanstalk (I've only used the latter two, not the former).

Re: Running containers without Docker

#74

Post by vacri »

seabrookmx wrote: post #73
vacri wrote: post #68

Earlier quoted context omitted.

I hate nagios as much as the next op, but what is so magical about containers that your services will no longer require an outage alerting mechanism?

> run containers on ECS Presumably ECS has its own alerting mechanisms similar to CloudFormation and ElasticBeanstalk (I've only used the latter two, not the former).

In my experience, AWS alerting only sends one alert once per issue. If you're asleep when the single SMS comes through, tough. Nagios will nag you until you do something about it...

Maybe ECS is different. I haven't played with it, but I imagine it's "make an SNS topic" like everything else.

Re: Running containers without Docker

#75

Post by tlrobinson »

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 repository of images.

If you want to be popular among developers, the "hello world" developer experience should be extremely simple. See: Stripe, Twilio, Docker, GitHub, etc.

That said, I do think it's too bad that the Docker client/daemon are the lowest-level building block most people are interacting with. It doesn't seem to follow the Unix philosophy of doing one thing well.

Re: Running containers without Docker

#76

Post by aorth »

masterleep wrote: post #37

Try systemd containers (e.g, systemd-nspawn) if you're on a systemd distro like Ubuntu 16.04.

systemd-nspawn is great! The workflow feels much more native than Docker on GNU/Linux host. The easy integration with networking, BTRFS snapshots, etc is very powerful.

Re: Running containers without Docker

#77

Post by elsonrodriguez »

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…

That's the main issue with Docker right now. They've built an amazing static compiler that works with any language, but there's a question as to whether that compiler is worth 1B.

Re: Running containers without Docker

#78

Post by shykes »

chc wrote: post #66
sysexit wrote: post #55

Earlier quoted context omitted.

> Kubernetes started out as an extension/modification of Docker, and over time Docker has evolved some of the same features as its kub-based competitors. The result is an uncomfortable integration between partially competing platforms. That's quite inaccurate. It's is like saying that OpenStack started out as an extension to KVM. Both had very different (original) scopes. > Whether the Kubernetes community continues…

All of the early Kubernetes resources I can find describe it as involving Docker. Was running it without Docker really a thing early on?

No. Kubernetes was launched at the first Dockercon, with a very specific focus of "we want to help expand what can be done with Docker by leveraging the significant operational experience we accumulated at Google". They delivered very successfully on that promise.

The focus on diversifying away from Docker is very recent, and is the direct result of the competitive tension I talk about earlier in the thread. It's completely understandable.

EDIT: A perfect example of that competitive dynamic is actually this very thread! the GP (`sysexit`) works at a competing vendor. You can tell in his post that de-emphasizing the dependency on Docker is important to him. In fact that talking point is so recognizable that I knew where he worked before even looking him up. There is nothing wrong with that, every vendor has an "official party line", and Docker is no exception. The point is, this is a delicate issue which has more to do with inter-personal and business dynamics than with code. And you should definitely verify the credentials and agenda of everyone speaking of authority on the topic of containers platforms. We vendors are everywhere, and we are biased as hell.

Re: Running containers without Docker

#79

Post by tarmstrong »

peterwwillis wrote: post #64

So, in general, tools like Docker are crap because they're like the Apple iPod equivalent of old standard Unix-style tools: bloated monolithic slapped together crap that's crammed with non-extensible non-intuitive extras, designed for people who don't want to know anything about how the sausage is made. But if you do want to do fancy production things, it's nice to have a tool that thousands of people have used for t…

> The only thing better that I would recommend is to actually make your own Docker. It's not that difficult, you're basically just slapping together some system calls and execvp()ing some other standard tools, which is what Docker does

Not sure if you've seen this, but the author wrote a great post about the Linux primitives that Docker is built on: http://jvns.ca/blog/2016/10/10/what-even-is-a-container/

Re: Running containers without Docker

#80

Post by TheDong »

indexerror wrote: post #69
schmichael wrote: post #36

Earlier quoted context omitted.

One large difference is that docker has a daemon that exposes an HTTP API and acts more or less like an init for containers. The docker daemon has historically had some stability issues as well as some security implications. Running a command line tool like rkt is a vastly smaller attack surface and less complex stack overall.

> docker has a daemon that exposes an HTTP API This API has to enabled explicitly. Docker daemon works by using a unix socket instead ( "/var/run/docker.sock" ). > acts more or less like an init for containers There is Docker daemon and there is Docker CLI. Both have separate scopes.

The unix socket actually serves an HTTP api (just not over tcp) as well, so the statement was true either way.
Post reply on HN