Docker without Docker
51–60 of 101 posts
Re: Docker without Docker
#52Earlier quoted context omitted.
What they mean is when the slides were made, Debian 8 was about to be released in "stable" with systemd. With debian 8 released the only oddball is ubuntu with their own early fork of systemd called upstart. It means from this day forward the things you see in the demo are already or inevitably available on every install of linux. You don't need to install anything special to do what he's doing there. http://upload.w…
1. Upstart is not a fork of systemd, and was started a fair amount of time before systemd. 2. Ubuntu 15.04 just shipped with systemd as the default init system (although installing "upstart-sysv" the system should revert to using upstart).
Re: Docker without Docker
#53Author here - I'm working on a blog post for this and didn't expect this to be posted on HN so soon, but I guess that's what I should expect for posting a link to it in another HN comment! :) These slides correspond to a workshop I conducted a week ago demonstrating the internals of Docker and how Docker containers can be run without using any of the Docker tools or runtime. Docker is a great tool, and I'm glad it's…
Re: Docker without Docker
#54http://www.freedesktop.org/software/systemd/man/machinectl.h...
With proper handling of access (allowing unprivileged users to start containers) along with --bind for the home directory, this could be a viable alternative to Debian's schroot [s].
There's also a complimentary lwn article from 2013 that's worth reading:
https://lwn.net/Articles/572957/
That also contains a quote that explains a bit about systemd (if read maliciously): "As part of the development of systemd, the team looked at various kernel features to see if they were relevant to the project."
At least with this (containers w/log handling etc) we get something for our complexity. Still, having had two seperate machines fail to boot/even come up with a text console with some sensible errors - I'm far from sold on the idea that I want all these features in PID 1.
[1] changed user "foo" to "root" to be a little more clear. Maybe "user1" would work as well - but systemd (unlike lxc etc) requires root?).
[s] https://wiki.debian.org/Schroot
Reminds me that I should probably make write-up of how I set up schroot to allow "source"-access for root, and automagic sessions for a standard user backed by lvm -- the documentation is a bit dense.
Re: Docker without Docker
#55Re: Docker without Docker
#56Author here - I'm working on a blog post for this and didn't expect this to be posted on HN so soon, but I guess that's what I should expect for posting a link to it in another HN comment! :) These slides correspond to a workshop I conducted a week ago demonstrating the internals of Docker and how Docker containers can be run without using any of the Docker tools or runtime. Docker is a great tool, and I'm glad it's…
Just a small FYI - whatever slide software that is - it doesn't render properly on mobile devices. On my 6+ half the slides are off the screen and it scrolls horizontally rather than vertically (that may be intended).
Edit: arrow keys are your friends.
Re: Docker without Docker
#57Author here - I'm working on a blog post for this and didn't expect this to be posted on HN so soon, but I guess that's what I should expect for posting a link to it in another HN comment! :) These slides correspond to a workshop I conducted a week ago demonstrating the internals of Docker and how Docker containers can be run without using any of the Docker tools or runtime. Docker is a great tool, and I'm glad it's…
Off topic: how do I create slides like this? What did you use to create 'em?
Re: Docker without Docker
#58Earlier quoted context omitted.
Or chroots, jails, libvirt-sandbox, etc etc.
chroot's aren't namespaced, which is a big important difference. Being able to kill the entire container by killing it's init process (and keep it's processes out of the host namespace) is a huge deal.
Re: Docker without Docker
#59We're back to chroot jails again?
Everything that is old is new again. For full disclosure i went from support Linux/Solaris (sysadmin) to mainframe middleware (CICS/WebSphere app server).
I've seen them used in good and bad ways, but mostly the former. It's good to see something that actually solves real problems coming back in to use again. Added bonus, it's an extremely mature (from a tech perspective) way of doing things. Chroot jails have been around for decades.
Re: Docker without Docker
#60Earlier quoted context omitted.
chroot's aren't namespaced, which is a big important difference. Being able to kill the entire container by killing it's init process (and keep it's processes out of the host namespace) is a huge deal.
Most of these implementations actually kill all processes in the namespace, not just init. First, there may not be an init (the root process could be the service, which is actually a best practice with respect to containers); and second, the signal may not be propagated to its children, especially if a non-trappable signal (e.g. SIGKILL) is sent.