Category Archives: DevOps

Post navigation

You can experiment this by starting a basic ubuntu image and create a test file or dir. The soon you exit the container all your changes will disappear.

Shell

1

2

3

4

docker run-t-iubuntu/bin/bash

touch/my_file

ls->you will see my_file

exit

Let’s try to bring that container up again:

Shell

1

2

docker run-t-iubuntu/bin/bash

ls->my_file isGONE

Thankfully Docker provides the solution to keep data persistent.

Docker Data Volumes

Docker data volumes are used when:

You want to persist data, even through container restarts

You want to share data between the host filesystem and the Docker container

You want to share data with other Docker containers.

Data persist

There’s no way to directly create a “data volume” in Docker, so instead we create a data volume containerwith a volume attached to it. For any other containers that you then want to connect to this data volume container, use the Docker’s –volumes-from option to grab the volume from this container and apply them to the current container.

Le’s create a data volume container to store our volume:

Shell

1

2

docker create-v/data--name datacontainer ubuntu

docker volume ls

Shell

1

2

DRIVER VOLUME NAME

local c8b7031de3a7504c677b38617426ee22b28e3718c87331758d5022fd485b1e26

This created a container named datacontainer based on ubuntu image and in the directory /data.

If we reiterate our initial test with –volumes-from flag, anything we write to /data directory into current container will be saved to the /data volume of our datacontainer.

Shell

1

docker run-t-i--volumes-from datacontainer ubuntu/bin/bash

Shell

1

2

root@60c6e7f8307c:/# touch /data/my_file

exit

Now rerun the container and check if /data/my_file is persisted.

Shell

1

2

docker run-t-i--volumes-from datacontainer ubuntu/bin/bash

ls/data/

You can also create as many data volume containers as you’d like but you are restricted to choose the mount inside the container (/data in our example).

Sharing data between containers – shared volumes

There is the need to share data between host and container itself. Docker gives you the option to run a container and override one of its directories with the contents of a directory on the host system.

Let’s imagine you’re running your application and you want to keep the logs out of container.

C#

1

2

mkdir~/nginxlogs

docker run-d-v~/nginxlogs:/var/log/nginx-p8080:80-inginx

We set up a volume that links the /var/log/nginx directory from the nginx container to ~/nginxlogs on our host.

C#

1

2

curl localhost:80800

tail~/nginxlogs/access.log

If you make any changes to the ~/nginxlogs folder, you’ll be able to see them from inside the Docker container in real-time as well.

Docker is a great tool but for complex applications with a lot of components, orchestrating all the containers to start up and shut down together (not to mention talk to each other) can quickly become difficult.

Docker Images

Docker at its core is a way to separate an application and the dependencies needed to run it from the operating system itself. To make this possible Docker uses containers and images.

A Docker image is basically a template for a filesystem. When you run a Docker image, an instance of this filesystem is made live and runs on your system inside a Docker container. By default this container can’t touch the original image itself or the filesystem of the host where Docker is running. It’s a self-contained environment.

Containers

Docker containers wrap up your application in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.

Containers are for software, not for data

Docker containers are consumables. Docker containers should be used to scale applications, for firing more app servers with the same setup etc. Data belongs onto the filesystem but not into a container that can neither be cloned in an easy way nor incrementally backed up in a reasonable way. Containers are for software, not for data.

SSH keys are a more secured way to connect to your servers / VPS, compared to simple password authentication. Once you’ve setup a SSH key pair they can be deployed on all your servers in order to allow secured access. To add an additional layer of protection you can also password protect your SSH keys.

Creating SSH keys

There are few options and tools to generate SSH keys, but for windows based systems the PuTTYgen is the way to go.

I use SSH-2 RSA and 2048 bits for generated key (increasing the bits makes it harder to crack the key by brute-force methods).

After generating the keys you should store them in a safe place (specially the private one). If you lose your keys and have disabled username/password logins, you will no longer be able log in!)

NOTE: PuTTY and OpenSSH use different formats for public SSH keys. If the SSH Key you copied starts with “—- BEGIN SSH2 PUBLIC KEY …”, it is in the wrong format. Be sure to follow the instructions carefully. Your key should start with “ssh-rsa AAAA ….”

Deploy the Public Key on your Server

You need to upload the public key in the file ~/.ssh/authorized_keys on your server.

Disable Password Login

You can go further and add the extra security that SSH keys offer by disabling password login to your server. Before you do this it is essential you keep your SSH key files in a safe place and take a backup… in another safe place.

When password login is disabled you won’t be able to login without these keys.

On debian/Ubuntu systems the SSH password authentication can be disabled by editing /etc/ssh/sshd_config.

Shell

1

2

3

4

5

[...]

PasswordAuthentication no

[...]

UsePAM no

[...]

Please don’t forget to restart your SSH daemon service:

Shell

1

service ssh restart

Now your servers should be secured with SSH keys.

If you’re on linux as a client, things are much easier:

Shell

1

ssh-keygen-trsa

The public key can now be traced to the link ~/.ssh/id_rsa.pub

Now it’s time to place the public key on the server that we intend to use:

Shell

1

ssh-copy-iduser@xxx.xxx.xxx.xxx

While a password stands the risk of being finally cracked, SSH keys are rather impossible to decipher using brute force.