32

I'm following the CoreOS Docker Documentation and it mentions starting containers with commands like:

docker run someImageName /bin/somebinary

Where someImageName is an image. When /bin/somebinary exits, the image will no longer be running.

I would simply like to run an image, without specifying any binaries to run. Instead, I simply want to run the services (eg, systemd / sysvinit) that are normally run inside the images OS.

This seems like the most common thing anyone would ever want to do with Docker, but trying to run an image without a command returns:

2014/02/05 14:49:19 Error: create: No command specified

How can I start a Docker container and run a full OS, rather than specifying a command?

mikemaccana
  • 3,470

4 Answers4

26

As documented here, you simply run /sbin/init as the command just like any other unix booting from single user to multi-user mode.

https://stackoverflow.com/questions/19332662/start-full-container-in-docker

Containers can be full blown OS's, they just don't have to be (neither do VMs for that matter, it's just more complicated to configure and manage).

I would say the whole point of Docker is to make application containers easy, so that you only have to configure an app, not the whole OS.

Community
  • 1
Fred the Magic Wonder Dog
  • 2,095
  • Thanks. After starting the image with /sbin/init, I ran docker ps -notrunc, to get the container ID, then sudo /usr/sbin/lxc-attach -n containerID to get into the running image. As the other poster mentions, I don't really need a second init, so I'll check out single-command containers next... – mikemaccana Feb 05 '14 at 15:35
  • 2
    Saying that you don't need to run a full blown OS in a VM is like saying that you don't need to run a full blown OS in a physical machine, yes that's true that the kernel is basically just a regular x86/C program that runs without the stdlib and so do init, but it's – Lie Ryan Jan 15 '15 at 10:52
  • What would you suggest for testing a new systemd unit without using a host system? – Coder Guy Feb 18 '20 at 02:34
12

Docker is a system for management and deployment of application containers, not operating system containers. It seems as if you're conflating running a docker container with booting an operating system.

Your Docker containers should be single-purpose, very narrowly-scoped applications that can be started with a single command. If you're looking for something more complex than that, then Docker is not the solution you're looking for. In that case, check out KVM, ESXi, OpenVZ, LXD etc.

If you're just looking for how you can specify a default CMD and ENTRYPOINT for your containers, you can do that at build-time using a Dockerfile.

Dustin Kirkland
  • 626
EEAA
  • 109,904
  • 7
    I'm aware of what Docker is. I will point out that application containers are based on operating systems, eg, Fedora or Ubuntu. Persistent applications on Unix - even userspace only Unixes like Docker containers - are started from either initscripts or systemd unit files. For example, if my app crashes, I would like it to restart automatically, with a threshold - like systemd provides. – mikemaccana Feb 05 '14 at 14:56
  • 5
    You're trying to cram too much into your containers - they aren't an operating system. Process supervision should be handled outside of each container. – EEAA Feb 05 '14 at 15:02
  • 1
    So if a process dies... just restart the whole container? I guess that's not so expensive so that might be OK. It kinda feels weird - my container has an /sbin/init, but it never gets used... – mikemaccana Feb 05 '14 at 15:06
  • 1
    Yes, that's the idea. Your container has an /sbin/init, but it doesn't have to have it. You likely used a default ubuntu container or something like that. There are a lot of bits in these containers that can be removed if you desire. – EEAA Feb 05 '14 at 15:08
  • Thanks, that last comments explained it perfectly. Alas I can only award one tick, so have upvotes for all your comments. – mikemaccana Feb 05 '14 at 15:22
  • 1
    @mikemaccana we use runit for ensuring processes restart if they die. It's very simple and lightweight. – MikeyB Apr 04 '14 at 21:38
  • 1
    If you do want to run an "operating system" in a container, then check out LXC/LXD --> linuxcontainers.org. That's exactly what we've designed them for! – Dustin Kirkland Aug 03 '16 at 14:01
  • 1
    This is incorrect. Docker and containers generally can certainly also be used to run operating system containers, and it often makes a lot of sense too. – Make Mark Feb 16 '17 at 21:03
  • 1
    @ValkoSipuli You're certainly free to hold that opinion. I still maintain that running more than one process inside a container negates much of the reason for using containers in the first place. Is there a place for running an OS inside a container? Probably. That's an exception, though, and shouldn't be done without much deliberation on pros/cons. – EEAA Feb 16 '17 at 21:34
  • 2
    @EEAA Answers should try to be based on facts, not opinions. So if you agree that both application and operating system containers are reasonable choices (depending on the use case), then the answer should focus on helping the original poster out in a friendly way instead of trying to turn them away into some other direction. Docker single application per container feels like cargo cult. – Make Mark Feb 16 '17 at 21:43
  • @ValkoSipuli Feel free to post an answer. – EEAA Feb 16 '17 at 21:50
  • 1
    @EEAA you have a very narrow view on the use of containers. Linux is quite new to the container scene, as FreeBSD and Solaris have been doing them in production since the the early naughtys. You can argue mainframes did it even earlier. They are used in many different ways. eg I worked on a project we we reduced several 10 hardware based solaris platforms to a big cluster running zone. The users of these systems were totally unaware they we now containerised as all the services remained unchanged. It was a lot more efficient to do it this way than run full virtualization. – krad Feb 22 '18 at 10:49
  • Admittedly docker isnt particularly geared up for that sort of thing, but the world is a bigger place than devops right now, even if a lot of stuff is heading that way. – krad Feb 22 '18 at 10:51
8

To run a full operating system in a container create the following Dockerfile:

FROM fedora:25

CMD /sbin/init

Then build and start the container and enter a shell inside it to explore the services running inside it:

docker build -t os .
docker run -d --privileged --name os os
docker exec -it os bash

Full systemd services inside the container. Beautiful.

Make Mark
  • 1,994
  • 3
  • 15
  • 15
3
docker pull ubuntu

Just run from the same image as many times as needed. New containers will be created and they can then be started and stoped each one saving its own configuration. For your convenience would be better to give each of your containers a name with "--name".

F.i: 

docker run --name MyContainer1 <ubuntu image>
docker run --name MyContainer2 <ubuntu image>
docker run --name MyContainer3 <ubuntu image>

That's it.

$ docker ps
CONTAINER ID        IMAGE            CREATED          STATUS               NAMES
a7e789711e62        67759a80360c   12 hours ago     Up 2 minutes         MyContainer1
87ae9c5c3f84        67759a80360c   12 hours ago     Up About a minute    MyContainer2
c1524520d864        67759a80360c   12 hours ago     Up About a minute    MyContainer3

After that you have your containers created forever and you can start and stop them like VMs.

docker start MyContainer1

To get in the container and do what you wanna do:

docker exec -it MyContainer1 bash
DimiDak
  • 128
  • 3