Container ~= process which has been isolated from the host system using linux specific kernel features. If you launch systemd and all ubuntu services, yes, it will effectively run the whole os, otherwise, it's just a process like any other with no overhead. Why the image? Well it contains the filesystem of your container - all the libraries your process needs to convert its' logic to kernel syscalls, all in their own filesystem bubble, so there are no clashes, wrong versions, etc.

Imagine that you copied all the files from your friend's hard drive onto your computer that is running a different version of linux and then executed a single program from it. In that case, you've copied an entire operating system onto your computer, but you certainly didn't execute another operating system.

Of course, the program would likely fail to start because things would be in unexpected paths, it'd see unexpected versions of libraries, etc. So now imagine that there's a Linux feature that allows you to remap filesystem paths for this process and all its children. This is called a mount namespace, but the old school feature called chroot achieves similar goals. If you then add on a few more isolation features, you have a modern container.

It's possible to do this because both of these systems are linux systems and the linux kernel's program-facing surface area maintains compatibility across a wide variety of versions, so the programs don't care very much about the underlying kernel version. With containers, the same kernel is just presenting a different view of the system to different applications.

depends what you mean by running an entire ubuntu os.

It's not running systemd, its just running that one process you asked for. It be as if you booted ubuntu kernel and instead of running systemd to run all sorts of services, you run the single process you wanted. You're running on "ubuntu", but not really, i.e. the file system is provided by ubuntu, but you're not using the normal ubuntu environment with all the services that would start at boot.

You can also have docker containers run systemd if you want, but that's a much more advanced use case.

You need to stop thinking of it as an OS. It's just an easy/lazy way to grab all the dependencies your process may need. Here's a silly analogy:

You're trying to containerize a simple football game. To run the game you need to provide a playing field that meets all the requirements of the rules, your dependencies.

You could go through all the rules one by one and write down what is required, like you need a line here of that length, another there that has to be at least x far away, but no more than y, and so forth. After the tedious task of collecting all your dependencies you give it a test run and it all looks good, but then boom the game suddenly stops. Whoops you forgot a dependency and didn't provide the goals, or added the wrong ones.

Alternatively you can take the easy route. You know they play regulation football in Ubuntu stadium, so you just take a copy of that. It comes with a lot of overhead - you don't need the ranks, concession stands or parking lots to simply play football without all the faff, but it's included because league football needs it.

Edit: When you do take the base image of Ubuntu stadium and docker run it, the default is set to play a game of football, because that's the most likely thing you want to do there. It doesn't activate the media coverage and stadium announcer, doesn't sell tickets and fills up the parking lot because none of that is required to play. You could if you wanted to, but you could also tear it all out and the default game would still run.

No, it probably only starts a bash shell in the container. In most cases docker containers only run a single application, not the entire os. It is possible to run everything, but that kind of eliminates on of the big advantages of docker.