I use containers as lightweight VMs in many places. Generally I see this as a way to get a minimal install that other tools can then configure appropriately, with up to date packages fetched from upstream mirrors directly, instead of installed from CD and then upgraded.

I currently use packer.io to script the creation of a bunch of server images, and for ubuntu I've missed the "minimal install CD" that other distros have. Instead packer has to download a 800MB CD image, in order to install only a few hundred megabytes of uncompressed packages in a bare-bones install, which is then provisioned using some orchestration tool that at its heart uses ssh to login to the virtual machine.

Not having SSH means you need to add in some sort of serial-attach step to manually install sshd, or hook into the install scripts to download sshd as part of the install or whatever. Either way that's additional custom work that is probably common to a great many use cases.

So why not build your own version with a SSH daemon if you really need it? I don't think most people need the SSH daemon in their container image.

Your Dockerfile could be something like this:

  FROM ubuntu:bionic
  RUN sudo apt-get install openssh-server -y && sudo service ssh restart

These are definitely not the complete steps for setting up SSHd but you get the idea.

This is meant as a base image for containers. There's not even a kernel or init

Just do a netboot with a preseed file (have your own local cache - either with apt-cacher or something more independent)

Our server preseed has the following line

d-i pkgsel/include string openssh-server build-essential iperf htop screen sysstat vim-nox

And a couple of internal packages which have their own dependencies (including lldp, snmpd etc) which do a variety of things including user management (active directory based), automatic registration into our asset database and monitoring systems

You're running these containers in an orchestrator, right? That should give you API access to the running container, allowing you to get shell. E.g. with kubernetes, `kubectl exec` will get you into the container.

But the sibling comment about using a Dockerfile to install/start sshd works if you're running these containers on a remote host without any kind of access to the running container.

LXD containers make fantastic replacements for VMs! Just try 'lxc launch ubuntu:'. Then 'lxc list'. And then you can either exec into, or ssh into your machine container!

Not arguing that point for this image, but I use containers as lightweight VMs, not only as stateless-horizontally-scalable-try-to-be-google app servers.

Docker is awesome for making virtual desktop systems. My dev environment + all required IDEs and apps is a docker image running xrdp, x2go, and google remote desktop, and my home directory is mounted as a volume. Works great!

Now when I need to move my dev environment to another computer (travel), I just copy the home dir, docker build, and I have the exact same environment ready to go.

My dev environment is 100% deterministic, backed up to git, and serves as documentation for what I need installed to do my work. If I find I need something else added, I modify the Dockerfile, commit, rebuild and redeploy. If something messes up my environment, destroy and rebuild is only a couple of commands away.

For anyone interested: https://github.com/kstenerud/docker-desktops

For the record, LXC containers are much more cooperative as non-emulated VMs than Docker containers. I'm sure this is also the case with Virtuozzo, etc. (though I haven't tried them). These other container systems function nearly identically to an emulated VM, which is what most people actually want out of containers -- thin VMs.

I didn't know about the --init flag to docker run, thanks! Looks like that was added last year with 1.13.0. Going to have to try this myself, now.

Thanks for posting that!

It's stupid that you've been downvoted. It is so tiresome to see people ask such useless questions like "what? you want to use this thing in some way that my tiny brain cannot envision? what is this madness?"

His reply was snarky and created a false dichotomy. The 90% usecase exists in between “lightweight VM’s” and google scale horizontal app deployment. Consider that the former is just as much an outlier as the latter. This post is about a pragmatic minimal Ubuntu base image, which would meet neither case well.

It was snarky. But there is a dichotomy: It's either stateless or stateful. Either I'm supposed to SSH to it or I'm supposed to destroy and redeploy.

Again, consider that you are creating this dichotomy, not the tools, or vast majority of practitioners in this space. Docker comes with (and encourages) lots of ways to persist state, as do orchestration environments like Kubernetes and ECS and you should choose the approach that suits the problem you are solving. If you want containers as lightweight VM's, there are a ton of ways to do that and they are actively supported.

I'm reluctant to get off-topic here, because the narrative relating to the actual post should be "Does it makes sense to have openssh in a minimal ubuntu base image", to which the answer is "No, obviously".

It isn't clear afaik. Maybe i'd like this as an alternative to CoreOS or whatever for my k8s nodes?

EDIT: Good point, you're right, it has no init system etc and is meant to be used in a container. Point conceded :)

I wouldn't be surprised if Ubuntu started a project similar to Redhat Atomic (and now CoreOS/ContainerOS).

On GKE, one advantage of using Ubuntu as the node OS is you can get access to Sysdig or OpenEBS.

We've moved at work to mainly Alpine based k8s containers, which is awesome, but you lose a lot of debug ability.

Thinking about it - with Linux KSM the overhead of full-fat containers based on Ubuntu (for example) isn't massive. We may have to look at the metrics I reckon.

You're looking for Ubuntu Core.

Looking at Ubuntu Core, not sure it is doing the same kind of things that CoreOS ContainerOS, Google's ContainerOS, and Redhat Atomic is doing.