tobbyb

ttyrec is a tiny terminal utility that does this on your terminal. It was released in 2000, it's one of those nice little gems one is glad to discover. It records and playbacks terminal sessions. The recorded files are in kb's. [1]

It's simple to use. 'ttyrec filename' starts recording, ctrl-c to stop recording. 'ttyplay filename' to playback.

Of course with asciinema.org, you get the benefit of an html player for the files, that you can link and playback on your own website.

[1]http://0xcc.net/ttyrec/index.html.en [2]http://manpages.ubuntu.com/manpages/maverick/man1/ttyrec.1.h...

Docker is an opinionated way to use containers. You don't need to adopt that to get the benefits of containers. A lot of the messaging, hype and marketing conflates the 2 and it suits the docker ecosystem to do that but it does not benefit informed discussion.

By eschewing plain containers in favour of Docker you are embracing some complexity and it would help to have more discussions on the tradeoff and benefits of every approach, rather than just conflating containers to Docker.

The LXC project in development since 2009 on which Docker was based and now Systemd-nspawn give you pretty advanced containers with mature management tools, multiple container OSs, full stack linux networking, storage options, cloning, snapshotting etc. [1]

LXC and soon Systemd-nspawn (version 220) support unprivileged containers [2] that let's non root users run containers. That's a pretty big step forward for container security.

There is lot of innovation happening outside the hype of Docker. But these projects are not opinionated and stop at giving you container technology as lightweight VMs like KVM, Xen, Vmware stop at giving you virtualization.

Docker takes that as a base and restricts the container OS template to a single app, builds the container as layers using aufs, btrfs, device mapper, and enforces storage separation. This is not rocket science, you can do this yourself with overlayfs, aufs, btrfs, build single app containers etc [3]

By adopting the Docker way you are immediately taking away seamless migration of VM workloads and embracing some complexity. There are both upsides and downsides to this. For a lot of use cases the Docker approach may help, in others it may add unnecessary complexity. We have an indepth [4] look at the differences between LXC and Docker here for those who are interested.

Disclosure I run flockport.com that provides an app store for servers based on Linux containers.

[1] https://flockport.com/guides

[2] https://www.flockport.com/lxc-using-unprivileged-containers/

[3] https://www.flockport.com/experimenting-with-overlayfs

[4] https://www.flockport.com/lxc-vs-docker

LXC is really quite simple and makes a lot of sense when you need a lightweight VM, that behaves like a VM. Docker takes a very specific view of containers with layers, a modified container OS template and init that limits the container to running a single app. This may be great for deployment or PAAS specific use cases but adds needless complexity for more general use cases.

There is more to containers than running a single app. Their potential as lightweight, efficient and portable alternatives to VMs is immense. We have tons of resources on LXC at Flockport, including ready to use containers [1]

VM workloads can transition seamlessly to LXC containers. And the large ecosystem of Linux tools and apps that work on VMs and systems work perfectly in LXC. And you do not need to find a container specific way to do things.

Take networking, overlay networks or clustering that works in VMs work as well in containers. We have a largish number of tutorials on multi host container networking over both layer 2 and 3 with GRE, L2TP, VxLAN, IPSEC, tinc and more [2] A lot of Docker specific tools use these under the hood but they are easy enough to use on their own.

The LXC team are trying to move the needle with LXD. It uses unprivileged containers by default (non root users can run containers, this is not capabilities drop) multi host management with a REST api so you can query the LXD daemon for container orchestration across hosts and live migration. These are big steps forward and they really do need the support of the community. They have been doing this for 7 years and is thanks to then containers exist.

[1] http://www.flockport.com/containers

[2] http://www.flockport.com/news

Container networking is not special or different from VM networking. There are tons of proven and widely used technologies available in the open source ecosystem.

We have been building out a series of networking tutorials at flockport from basics; static, public, private IPs, NAT, bridging etc to multi-host container networking with GRE, L2TP, VxLAN, IPSEC focussed on LXC but these will work with VMs and containers in general.

They don't need any special tools, just IP tools and the kernel and deliver performance and security. A lot of the Docker centric networking projects use these under the hood but they are easy enough to use on their own.

http://www.flockport.com/news

LXC is generic container technology like KVM OR Xen are generic virtualization technologies. LXC virtualizes the OS environment and gives you lightweight containers that you can seamlessly transition your VM workloads to, or use as a lightweight portable alternative to VMs, so its use case is general and not a narrow focus on paas or deployment centric technology.

Users can then decide how they want to deploy. Docker takes that base container and adds layers of aufs, constrains the container OS template to single app by modifying the container OS's init, gives you the dockerfile and focuses on deploy centric functionality with immutability idempotency etc, and this makes it much more complex to use than LXC. Its a use case built on Linux containers, not containers itself.

LXC is not 'low level kernel capabilities' [1] as Docker misleadingly refers to it on it's website. This has resulted in a lot of confusion about LXC in the Docker ecosystem with folks thinking its 'difficult to use' or 'just low level stuff'. A tad unfair to LXC given Docker was based on it till 0.9 and knew exactly what it was, and is as accurate as referring to docker or nspawn as low level capabilities.

That would be kernel namespaces and cgroups that LXC uses to give end user containers, like Docker uses post 0.9 directly with libcontainer and systemd-nspawn uses for its containers.

Docker builds on containers to deliver additional functionality. There is an additional cost in complexity but if that is your use case the trade off may be worth it, but for other use cases the complexity may be overkill.

You can simply make a VM image of LXC installed and you have boot2lxc, the vast ecosystem of orchestration technology that works in VMs and systems works in LXC, you don't need specific tools to be designed just for LXC. its not opinionated or exclusive like the tools built around the Docker ecosystem that are finely focussed on a specific use case and typically support Docker only.

[1] https://linuxcontainers.org

This is what normal LXC containers has always done. Systemd nspawn does not yet provide a toolset to wrap these capabilities like the LXC project. Things like userland tools, library of OS templates for containers, networking, features like unprivileged containers that allow non root users to run containers etc.

Lennart Poettering has spoken about containers and btrfs subvolumes and easy snapshots, this could be the direction systemd goes in future for managing the OS with apps in btrfs subvolume containers, with rollback, management etc so this seems like it may mature fairly fast, except unprivileged container support which Lennart does not seem to like.[1]

[1]https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...

Hi, Thanks for your comments. It's nice to hear from someone who is well informed and can tell the difference.

Unfortunately as any container thread on HN itself will show and a lot of persistent questions we get on flockport.com confirm, there is still lot of needless confusion.

And that post was written for new users to the world of containers who may not know for instance that you DO need a process manager or a script to run multiple apps in Docker. You do not 'think about running, installing a process manager' in LXC. It a default like any OS environment the average user would be used to for instance on their system or a VM.

As an experienced user you can appreciate that distinction for new users. Also Docker was designed with the single app restriction. It's a significant difference with LXC. The Docker OS template is intentionally restricted to do this. You can work around it but if it is your intention to multiple apps why not just use LXC itself? It's there for a purpose which the Docker site, and ecosystem articulate.

A lot of your other points are coming from an in-depth understanding of both LXC, Docker and the operating system. A lot of users do not have this perspective to being with. That post merely draws this out and hopes to inform.

An app container is pared down to run a single app. That's why you need a third party process managers like runit, supervisor or a script to run multiple apps in a single app container format like Docker.

A system container is similar to a VM, you can use it more or less as a VM environment, run multiple apps, ssh, schedule jobs, cron etc.

A system container gives you a more complete OS environment within the constraints of a container. I have a post that goes into some depth comparing LXC to Docker, it's not updated to include LXD but could help.

http://www.flockport.com/lxc-vs-docker/

The persistent misconception about containers on hackernews is unfortunate. The open source Linux container project (LXC) dates 2009, has been supported by Ubuntu since 2012, and has mainly been developed by Stephane Graber and Serge Hallyn. They have now developed LXD that builds on LXC.[1] It's far away from a 'me too' and to suggest so is an disservice to the folks working on the LXC project over the last 7 years. LXD uses unprivileged containers by default and is designed to support multiple hosts and live migration out of the box.

The LXC container project only matured with the 0.9/1.0 release around 2013, around the same time that Docker decided to use it as a base to develop a read only app container built with layers of aufs that LXC supported. Docker has not contributed to the LXC project or even attributed properly, it's website still refers to the LXC project as 'low level kernel capabilities' which in many ways is partly responsible for the widespread misconceptions about LXC in the docker ecosystem.

These 'low level kernel capabilities' are namespaces and cgroups that were mainly developed to support containers. The LXC project used these to provide userland containers along with container management tools and OS templates. This is what Docker used untill version 0.9 when it switched to its own libcontainer format to directly interface with kernel namespaces and cgroups. Referring to the LXC project as 'low level kernel capabilities' when it was as functional and in many ways easier to use than Docker is as inaccurate as referring to Docker as low level kernel capabilities.

Docker is a funded project and could take itself to market and gain adoption much more aggressively than the low key LXC project. This is something for open source projects to think about.

Immutability, idempotency and restricted single app containers made of read only layers are not the only way to use containers. They provide benefits for some use cases but also add complexity. It makes business sense to try to own the 'format' and there is an unfortunate tendency even for the technical minded to fail to consider not everyone needs these deployment centric addons, and disregard the complexity it adds.

For the average user used to VMs and complete OS environments, LXC containers are far easier, simpler and straightforward to use and offer a gentler transition. They behave more or less like your VMs, only more portable and lightweight. Immutability, idempotency or grappling with the complexity of single app containers of read only layers can be saved for later when and if the need arises.

Containers as a fast and lightweight alternative to virtualization with easy to use tools now across hosts with LXD and a wide choice of container OS templates seems to be an good option to have. Upstream features like unprivileged containers and live migrations is icing on the cake.

Disclosure - I run flockport.com that provides ready to deploy LXC containers.

[1]https://linuxcontainers.org

We[1] have a multi-domain mail server container with imap, pop, GUI admin, webmail, and spam lists that is basically ready to go, based on LXC.

You can launch the container in seconds and should be the fastest and perhaps easiest way to have a fully functioning mail server. There is a starter guide [2] and even a [3] video to get you going.

However a mail server unlike most other apps is not only complex to install - which we try to address - but also complex to run.

For most if not all users mail just can't fail and this needs a fair bit of knowledge of dns, smtp, spam prevention, security. I think in all but the most committed cases it can prove a bit overwhelming for the average user.

[1]http://www.flockport.com/containers [2]http://www.flockport.com/using-the-flockport-mailserver/ [3]https://www.youtube.com/watch?v=ysUswy8rGwM

This is actually quite similar to using LXC containers to run GUI apps. Something like Wine would be a good candidate to run in a container, perhaps others too. And you can use both privileged and unprivileged containers for this.

I have a guide on running accelerated GUI apps in both privileged and unprivileged containers: http://www.flockport.com/run-gui-apps-in-lxc-containers and here's one more by Stephane Graber, lead developer of LXC using only unprivileged containers: https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-container...

Hi author here, thanks, glad you liked it! Flockport provides ready to deploy containers of popular apps based on LXC. We like the simplicity of LXC containers and find it easier to use.

The comments are spot on, most networking gurus appear to be strictly against extending layer 2 as we note in the post but we wanted to put the options out there. You definitely need to address latency and mtu issues across remote hosts that will crop up, but with standards like VXLAN based on extending layer 2 perhaps we will soon start seeing interesting workarounds.

Or it could mean as a funded company Docker has more resources than a low profile open source project like LXC to reach out and generate interest and adoption.

There is undeniable confusion about LXC and Docker with a lot of folks whose first introduction to containers is via Docker who seem to think LXC is 'low level kernel capabilities' as it is mistakenly referred to on the Docker website, and since Docker was based on LXC they at least should be clear what LXC is.

The fact that LXC is an advanced project baking since 2009, supported by Ubuntu since 2012 which provides perfectly usable Linux containers, wide choice of OS templates, features like unprivileged containers and is easier to use than Docker is often lost in the noise.

LXC provides you system containers, Docker takes that base that to provide app containers, and there is definitely interest and value in that but it's a single use case of Linux containers. Would you want to reduce a container to an app for all use cases?

To conflate a single use case to container technology itself is a mistake, apart from the fact that once you go down a custom container format you will need to expend engineering resources to figure out how to make a lot of things like clustering, services, apps, networking that expect a normal OS environment work with the constraints.

Hi Zancarius, my apologies, I mistakenly replied to you when it was intended for neilellis.

Imho if your use case is not statelessness and you need a container as a lightweight VM, LXC tools are actually quite simple and easy to use.

Nielellis - I am sorry you feel the article is misleading. It describes the default behavior. The default Docker template has limitations, that the user should be aware or you get questions like this - http://stackoverflow.com/questions/21280174/docker-centos-im...

I would suggest you have a look at rationale for Phusion base image here - http://phusion.github.io/baseimage-docker/

Docker base template is not a multi process multi app environment, it executes the application specified on the docker command line and exits. Which is why you can't run apps in daemon mode and have to explicitly disabled, and need a separate process manager.

Hi, this is what is stated in the article

'Docker restricts the container to a single process only. The default docker baseimage OS template is not designed to support multiple applications, processes or services like init, cron, syslog, ssh' When it comes to applications for a LAMP container you would need to build 3 containers that consume services from each other, a PHP container, an Apache container and a MySQL container. Can you build all 3 in one container? You can, but there is no way to run php-fpm, apache and mysqld in the same container without a shell script or install a separate process manager like runit or supervisor."

It's all in the same paragraph. There is no attempt to mislead. This is how Docker works.

That's why you need runit or supervisor to run multiple apps. https://docs.docker.com/articles/using_supervisord/

And this issue has been heavily discussed in Hacker News itself in the article about Docker Phusion base image - https://news.ycombinator.com/item?id=7258009

This article is not meant to trash Docker and I urge readers not to read it as such. It does not do that.

I have tons of respect for Docker, and any project involving hundreds and thousands of man hours of effort. It's an interesting use case of containers to build stateless applications, but its a single use case.

While researching this piece I came across significant confusion online including by technically minded folks and entire projects that persistently misrepresent LXC as 'low level kernel capabilities' or Docker as a 'front end user friendly' interface to LXC.

This kind of confusion does a disservice to both projects by not articulating Docker's core stateless benefits on top of normal LXC containers and misrepresent the LXC project, and undermine informed discussion on Linux containers.

Hi, I am the author of the article. It does not state containers encapsulate applications from a 'security sense'. You make a point which is not stated to draw conclusions which were not made.

It states 'Containers decouple your applications from the host OS, abstracts it and makes it portable across any system that supports LXC'. You can run the app in the container in any other system that supports LXC, isn't that what decoupling is?

I think you are looking at this from a technical perspective and not an end user perspective. Why don't you download and try some of the Flockport containers available on the website, those apps are decoupled from your Linux OS and will work in any LXC environment.

This is an article about containers for end users, not technical users, to help them understand the concept of containers and how LXC differs from Docker.

If security, multi-tenancy, running other OS's or specific kernels are your core use cases, virtualization makes more sense as is stated a few paragraphs below that quote, and in the LXC getting started guide on the same site.