[pikchurn]

Posting here rather than the blog because I don't have a google account:

What about adding sshd to the minimal install? If the purpose of this is minimal installs of containers and cloud servers and such, that seems like quite an omission.

[bryanlarsen]

If you have SSHD in the minimal image then you have to deal with host keys.

- on embedded and some other places where minimal images are used, generating the host key on first run can cause a very significant startup delay.

- on some container environments, environments are so identical that you might not have enough entropy to generate sufficiently unique keys.

- if somebody generates a host key and then creates an image from a running container, then you might end up distributing a host key, making what should be private public.

I've probably got some of these details wrong and am going to be promptly corrected, but there are some very good reasons for excluding sshd.

[the8472]

Container/VM management software may already provide a way to remote into them, so that would be redundant.

Plus it's a minimal image, you can build your own intermediate one on top of that with SSH added.

[sofaofthedamned]

They don't necessarily give you a way of getting into the node, especially if it's in a broken state (which is the time i'd want to have a look)

EDIT: I was wrong, this is made to be a container base, not for the nodes themselves (there is no init system)

[acomar]

This is supposed to run inside of a container. Why would you want sshd inside of a container?

[pikchurn]

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.

[verst]

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.

[moondev]

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

[isostatic]

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

[acomar]

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.

[dustinkirkland]

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!

[unethical_ban]

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.

[kstenerud]

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

[cookiecaper]

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.

[bchallenor]

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.

[Serow225]

Thanks for posting that!

[tomc1985]

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?"

[lox]

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.

[unethical_ban]

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.

[lox]

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".

[sofaofthedamned]

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 :)

[hosh]

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.

[sofaofthedamned]

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.

[dustinkirkland]

You're looking for Ubuntu Core.

[hosh]

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.

[riffic]

I don't want an sshd installed by default in my containers. What's your use case?

[pikchurn]

I'm not saying by default. I'm saying have it on the CD.

[geofft]

I often boot machines connected to the public internet or to a coffeeshop / other public wifi with the Ubuntu live CD, so I wouldn't like the live CD to have an sshd with a well-known password out-of-the-box. So if you're going to have to log into the machine to customize authentication anyway, you already have enough access to `apt-get install openssh-server`.

(It would be nice to have a one-click tool that builds you a customized image with your own SSH public keys baked in. Ubuntu doesn't have to run this tool - actually there's probably a cool project idea for someone in standing up a little website to do this, either by letting you paste in public keys or grabbing them from the GitHub public API.)

[pikchurn]

As I said, I just want the .deb file on the iso.