6 minute read

This article is part 1 in a series: Docker



Some people have asked me to write a post about docker, I’ve been pushing it ahead for a while, so I thought I’d get too it now…
I will in this series try to cover the basics (and a bit of the more advanced parts) of docker and also docker-compose, because I find that tool being very useful!

What is docker?

Docker themselves say that docker is

the world’s leading software container platform.

Now, by reading the information that docker provides about their platform I’m sure that someone with knowledge in containers would get a good grasp on the subject, but people who have never before used anything like this, it might be a bit hard to understand.

Docker is a software which runs containers. A container is a “isolated package” including a piece of software.
A container does not include a full OS, but rather just the parts that it needs to run the software itself.
This makes a container a whole lot smaller than a traditional virtual machine and a whole lot less resource hungry.

Easiest way to “explain” docker is to say that its much like a virtual machine.
It’s not entirely true, but we go with it anyways, because that way anyone whom are used to VM’s will feel safe!

Now, the best thing with a container, is that its exactly the same on all computers that runs it, regardless OS! That means that it will run the same on a linux computer as on windows or mac!

To use docker

First off, you will need to install docker. I’m not going to explain this step though, I think you can manage that yourself!

Every container you run will be using a docker image. A image is a pre-built package on which the container will be based. Images can be built locally or by using a hosted alternative like docker hub.
Building your own images will let you customize the containers a whole lot more than using pre built images, but in this first part we will just use images from docker hub rather than jump in to writing docker files right away!

Note: I will cover the Dockerfile and the docker build command in a later post of this series.

Retrieving pre-built images

On docker hub one can find images for most things that one could want. In our first example, we will use the official docker tutorial image called hello-world. The first thing we have to do is to fetch the image to the computer and your local docker service.
No! this is not done by using curl, it’s already built in to the docker engine!
Fetching the image is done by using the docker pull command:

docker pull hello-world

Note: its also possible to just run the image, docker will fetch it, but pull is a good thing to start with.

It can take some time to pull a docker image over the net, but this image should be one of the faster (its under a kb in size).
When we got the image we can start a container based on the image.

Running the image

Starting a container for the first time is done by using the docker run command, and there are a few important arguments that one can or even should apply.

docker run --rm --name hello hello-world

When running the command like this, we will start a container which we have named hello, when the container is stopped for some reason, it will be removed we have ensured this by the --rm argument. If you want the container to keep on existing after it has stopped (so that it can be started again), just omit the --rm argument!

Further down the rabbit hole

Running a hello-world application like this might not be very fun, so we could go on with something a bit more useful.
How about installing dependencies in a composer project? That could be useful I bet!

You do not have to install composer or anything locally for this, all that is done in the container.
First off we need a composer file, cause that is the project “base”.

Example:

{
  "name": "my/project",
  "description": "Just testing docker!",
  "require": {
    "jitesoft/math": "1.0.*"
  }
}

Put the file in a empty directory and open the terminal there.
After creating a composer file we will need to find a composer image that we like. I personally always use one I made myself which can be fetched with docker pull jitesoft/composer.

When we got the composer image we will want to run the image… but we need to add the files to the image someway…
Docker and volumes (filesystem) is kind of a special thing and there is a whole lot of stuff to learn about it but in this case we will go the easy way and just share a volume!
Sharing a volume with a container is done when its started and the command looks something like this:

docker run --rm -v $(pwd):/app jitesoft/composer install --no-interaction

This will start a container which is based on the jitesoft/composer image, the image will have the current directory ($(pwd) will put that into the command) to the /app directory in the container, it will run composer install --no-interaction and install the dependencies that is required, then it will stop and clean up itself (remove due to --rm).

More run arguments!

There are a few more arguments in the docker run command that I find very useful to know about:

Detached:

-d

The -d argument tells the docker container that you want to be detached from it. This can be useful when running containers that are supposed to be long lived.

Port:

-p <local-port>:<container-port>
--port=<local-port>:<container-port>

With the -p argument you can map a port from the container to the local computer. Say for example that you want to open the containers port 80 (standard http port) to your local machines port 8080 you would write something like:

docker run -p 8080:80  nginx

Memory:

--memory=<size>

With this argument you can limit the amount of memory that the container is allowed to use. I always try to set this argument to make sure that the computer don’t run out of memory if I made something very wrong! (yes it has happened, on a live server!).

You can find all the arguments at the official documentation.

Now what?

Well, if you feel like it, go explore docker by yourself. Or wait a while and I will post another post about it which will go even further down the rabbit hole, hopefully at the end we will find the white rabbit, so we can beat it up because docker is so confusing!
No, in all honesty, I hope that the posts I write here will clear up most of the confusing about this great and useful tool!

Let me know if you find any errors in the text and I’ll correct them as soon as possible.