You may notice that the container is running in the foreground, which is not very useful because your console will be blocked until the service ends. Because our service is supposed to never stop, we should try running the service in the background. If you open another console and list the running container processes, you'll see that it's running:

You can see the CONTAINER ID, which, along with the container name, can be used to perform several actions such as restarting and removing containers, as well as the image, and its status and uptime.

Let's stop our container and measure the time to stop it. You'll notice that it won't stop  immediately:

It took 10 seconds, which is a lot if you just made a change and want to restart it. This is because our service is ignoring any environment signals.

When trying to stop a container, Docker sends a SIGTERM signal and waits 10 seconds for it to stop. If it doesn't, Docker then sends a SIGKILL, which will escalate to the kernel and which, in turn, will immediately stop our service and the container will stop.

We can change this behavior and try to stop gracefully. Change our app.listen line to something along the following lines:

app.listen(3000, () => {
    console.log("ready");
});

process.on("SIGTERM", () => {
    db.end(() => {
        process.exit(0);
    });
});

This adds a ready line when starting the container and tries to close both the database connection and the HTTP server when receiving a SIGTERM. Let's build our image again (because we changed our service), this time as version 0.0.4, and run it again:

Head to the other console and try to stop the container again:

That was way faster. It could be even faster, but it's better to stop gracefully. We're just stopping the database connection, but you could also stop Express from accepting more connections and then wait some seconds while it handles the active connections before closing gracefully.

We can now continue to improve on our deployment by changing our container to run in the background instead of just blocking our console. This way, we don't need two consoles to deploy and manage our container. To run this in the background, we use the -d options, which enables detached mode.

Our updated command is now:

docker run -d -v $(pwd)/settings.json:/opt/app/settings.json imagini:0.0.4

If you try it out, Docker will inform you of the full CONTAINER ID and turn you back to the console:

If you check the running containers, you'll see our container, with the short ID (which corresponds to the first 12 characters) and some more information. Something that is actually important and is empty is the PORTS column, which indicates the container ports that are linked to ports on our host.

That column being empty means you have no access to the container other than through Docker itself, which is actually useless. We can't access our HTTP interface.

We need to change our image again and expose a port. To do that, we must use the EXPOSE instruction and pass the port we want to expose. Our service listens on port 3000, so we need to expose it:

FROM node
MAINTAINER Diogo Resende

ADD imagini/imagini.js /opt/app/imagini.js
ADD imagini/package.json /opt/app/package.json
ADD imagini/settings.json /opt/app/settings.json

WORKDIR /opt/app
RUN npm i

EXPOSE 3000

CMD [ "node", "/opt/app/imagini" ]

You can now build the image, but before using our new version, we need to change our run command. Just because we're exposing a port does not mean the person using our image wants those ports exposed. We need to specify what host ports we want to connect to the container ports. To accomplish that, we're going to use -p, which allows us to configure incoming ports. The syntax is similar to the previous -v but for ports:

docker run -d -p 80:3000 -v $(pwd)/settings.json:/opt/app/settings.json imagini:0.0.5

In this case, we're exposing local port 80 to port 3000 of the container:

You can see that the container is running and that the address 0.0.0.0:80 (all our addresses at port 80) point to the container port 3000. We should be able to try it out and see if it's running correctly. Open a web browser and point it to the stats path:

We can now manage our container in a similar fashion to the service management on the current operative systems. You can start, stop, and restart it:

Every time you change one or more container's states, Docker returns the container IDs that have changed state. This allows you to, for example, to script actions and pipe the output of one command to the next.