dockerwhalehero.jpg

Image: ZDNet

Using Docker containers makes for an incredibly easy way to roll out apps and services onto your network. With this, you can extend the offerings of your business or quickly test a new server or service. With these apps as containers, it becomes possible to cut down on sysadmin overhead, thanks to no longer having to manage applications through package managers or installing from source. By installing the likes of NGINX as a Docker container, you can simply replace the image when new updates arrive.

But how do you deploy NGINX as a Docker container? Let me walk you through the process. I will demonstrate on Ubuntu 16.04 and will assume you already have docker installed and ready to go.

The big challenge

Running a Docker container isn’t challenging. What is slightly challenging, however, is making that container available to your local network (something important when working with a server). The process isn’t all that difficult, you just have to know how to work the right command-fu to make it happen.

Pulling the image

We are going to pull the official NGINX image with the command:

docker pull nginx

Note: If you have not added your standard user to the Docker group, do so with the following command:

sudo gpasswd -a ${USER} docker

After that command executes, logout and log back in. Now you can run Docker without having to use sudo.

Exposing the port to your network

Now we have to run the NGINX image such that it will expose the Docker container port to the network port. To do this, we run the image with the command:

docker run --name docker-nginx -p 80:80 nginx

The breakdown of that command is:

  • docker – the actual Docker command
  • run – this instructs docker we are running an image as a container
  • —name – this tells Docker what we want to name our container
  • -p 80:80 this informs Docker how we want to expose the port (in the form of network port:container port)
  • nginx – this tells Docker which image to use for the container

You can now point a browser on your network to the IP address of the server hosting the NGINX Docker container to reveal the NGINX splash page.

Say you already have port 80 used on the machine hosting Docker (possibly for Apache or another server). Should that be the case, you’ll have to expose a different external port to port 80 on the container. Let’s expose port 80 on the container to port 8080 on the host. The command for this would be:

docker run --name docker-nginx -p 8080:80 nginx

Pointing a browser on your network to the IP address of the host machine, at port 8080, will display the NGINX splash page.

Running in detached mode

You might want to run that container in detached mode (otherwise you won’t get your command prompt returned without killing the container. To run this container in detached mode, the command would be:

docker run --name docker-nginx -p 8080:80 -d nginx

Your prompt will return (displaying a container ID) and you’re ready to work.

Accessing the container

Although most containers are created to be pre-made environments, you might want to gain access to the running container, so you can do a bit of configuration. For that you would issue the command:

docker exec -it CONTAINER_ID bash

Where CONTAINER_ID is the actual ID of the running container. You can now work within that container as if you were working locally. Chances are you will need to install the tools necessary to work within your container (such as vi or nano). These are installed by the usual means (i.e. apt-get install nano). However, you will run into an error that will not allow files to be displayed through the usual means (vi, nano, less, etc.). To get around this, you must change the container run command to set the xterm variable, like so:

docker run --name docker-nginx-new -p 8080:80 -e TERM=xterm -d nginx

Now when you enter the container, you can install your editor of choice and actually work with it.

Containers made easy

There it is; you have a working instance of NGINX, via Docker container, that can be reached from your local network. That wasn’t terribly challenging, now was it? You have taken your docker container skills to a whole new level, with ease.

Also see



Source link