![]() |
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Imagine, in order to roll out a website, that you don’t have to install a full-blown server from bare metal up. Instead of installing the operating system, followed by the server software, followed by the deployment of your perfectly-crafted app or site, you could simply develop everything in a self-contained bundle and roll it out with a single command.
That’s one of the many benefits of using containers. They make the dev and deploy cycle incredible efficient. But how do you deploy those containers? I want to walk you through that process here. We’ll focus on deploying a basic NGINX web server, as a container, on Ubuntu Server 18.04. All of this will be done with the help of Docker.
In order to successfully deploy NGINX as a container, you’ll need to have the following:
That’s it. With those two pieces in hand, you’re ready to go.
Every container you deploy will be based on an image pulled from DockerHub. You can pull down a single image and use it as often as you like. There are also numerous images on DockerHub for a single application or platform. Take, for instance, NGINX. If you search for NGINX on DockerHub, you’ll come up with around 56,172 entries. That doesn’t mean each of those entries is a viable image for you to use.
Images are named like so:
name/descriptive-name
For example, with NGINX, you might find an image named:
bitwarden/nginx (a reverse proxy NGINX image)
Or you might find:
nginx/nginx-ingress (NGINX Ingress controller for Kubernetes)
So you see, there are images for just about every need.
At this time, there is only one image you want to focus on. That image is the official release from NGINX.
Before you can use an image, it has to be saved on your local drive. There are two ways to do this:
To pull an image from DockerHub, you would open a terminal window and issue the command:
docker pull nginx
If you wanted to pull the Ingress image, that command would be:
docker pull nginx/nginx-ingress
Once you’ve pulled down the image you want, you can make sure it’s there with the command:
docker images
The above command will list out all of the images you’ve pulled (Figure A).
Do use caution when pulling down random images. Why? Because you never know what went into creating them. A container could contain malicious code, which could wreak havoc on your network or data. Because of this, it’s always best to only work with the official images (such as the NGINX image).
It’s now time to deploy the container. Had you not already pulled down the image, the requested image would be pulled down during the deployment phase. Since we pulled down the official NGINX image, we’ll be using that.
To deploy a container, you use the docker command like so:
docker run --name NAME -p PORTS IMAGE
Where:
So, the very basic command to deploy our NGINX container would be:
docker run --name nginx-webserver -p 80:80 nginx
The container would be deployed and the NGINX web server would be available to your local network on port 80. What if, however, port 80 was already taken on the server being used to deploy the container? You could deploy it on network port 8080, like so:
docker run --name nginx-webserver -p 8080:80 nginx
At this point, you might see the next issue. After running one of the above commands, the bash prompt isn’t returned (Figure B).
Figure B: The container gives us feedback as the NGINX-powered site is visited, but it doesn’t give us our prompt back.
How do you run a container, and get your bash prompt back? To do this, you must run the container in detached mode. Before you do that, you have to kill the current container with the keyboard combination [Ctrl]+. That combination will give you back the prompt and kill the container.
To make sure a container isn’t still running, issue the command:
docker ps -a
This will list out all containers and their status (Figure C).
👁 Image
If the container were still running, we’d have to kill it before we could deploy another container on the same port (otherwise the ports would conflict, preventing the container from deploying). To kill a running container, you first need the Container ID (a random string of characters). This string is presented when the docker ps -a command is issued. To kill a running container, issue the command:
docker stop CONTAINER_ID
Where CONTAINER_ID is the ID of the container in question.
You can then delete the container with the command:
docker rm CONTAINER_ID
Where CONTAINER_ID is the ID of the container in question.
Do note, you don’t have to type out the full Container ID, as the first four characters of the string will suffice.
Now, to deploy the container in detached mode, the command would be:
docker run --name nginx-webserver -p 80:80 -d nginx
This time you’ll not only get your prompt back, but Docker will display the Container ID for you (Figure D).
What if you wanted to work on the running container? Say you want to make changes to NGINX or even start developing the website it will display? To do that, you have to access the container. For this, you need the Container ID. With the ID in hand, issue the command:
docker exec -it CONTAINER_IT bash
Where CONTAINER_ID is the ID of the container.
You should now be in the running container prompt (Figure E), where you can start working on the NGINX server.
To exit the container, simply type the command exit.
Hopefully, by now, you’re seeing that container deployment isn’t nearly as challenging as you thought. With the help of Docker, you can be rolling out apps and services like a pro … in minutes.