A server with Docker, part 2: A new Droplet

After stating what the end result is supposed to be in part 1, we are going to deal with the setup of a basic droplet (virtual machine) on Digital Ocean (DO). If you want to go along with the steps described further on, you can setup an account at DO in a manner of minutes.

The result of the following steps will be a solid foundation for the later installation of Docker and other packages in a server environment. If you are familiar with setting up a Linux server and the baseline of what DO has to offer, you probably know most of the details and gotchas I will mention below. Do not be alarmed, the next posts are bound to be more technical as the projects begins to take shape beyond basic configurations. As always, I am very interested in suggestions and opinions on how to improve the processes I rely on. If you disagree with any step or think I forgot to mention something essential please voice your concerns!

##First Things First After signing up and logging into the DO control panel for the first time, it is a good time to familiarize yourself with this new tool. One can (and should in the long run) setup 2-factor authentication, take a look at the most important views such as Settings and Billing. If you are like me, you will probably need to invest a few moments into appreciating how clean and tidy everything looks.

Before creating a droplet, it makes sense to upload your public SSH key through the DO control panel. When a droplet is created and no SSH key was provided, you simply get an email with root login credentials for the new server in plain text. After this you will certainly have to at least change the user password (and live with the guilt and risk of allowing password logins) or (a little better) have to go through the process of uploading a key in the usual fashion for every new droplet.

In case you don’t have a key handy and are on a POSIX-compliant system, the following will probably work for you. Make sure you have the openssh package installed. To generate a key, open a terminal and execute:

$ cd ~/.ssh/
$ ssh-keygen

Best practices for generating a new SSH key

  • Choose an informative name (id_rsa_do for example)
  • Make sure not to overwrite any existing keys
  • Do set a passphrase

This should generate a pair of file in your ~/.ssh/ folder, id_rsa_do and id_rsa_do.pub if you chose to name them thus. The plain text in the id_rsa_do.pub file is your public key that should be entered in the SSH Keys view of the control panel .

##The Choice Of Distribution On Digital Ocean, several basic Linux distributions and application images can be used to start a new droplet. In the case of distributions that are not based on rolling releases, a certain version can to be chosen. Ubuntu has the benefit of being officially recommended and supported by Docker, of course it is still possible to run Docker on other distributions and platforms. This is very well explained in the official Getting Started section of their website. Even if you decide to go with Ubuntu, this particular page might be relevant, in case you want to set Docker up on you local machine for development work and for first experiments with Dockerfiles.

For the new server, I chose to go with Ubuntu 12.04 “Precise Pangolin”. It is a stable LTS (Long Term Support) version and will be in reliable working condition until the later part of 2017. A new LTS release, 14.04 “Trusty Tahr”, will be out in April of this year. As soon as it is released and the Docker team will have gone through the efforts to be able to say they officially support it, this upcoming release will be a viable choice. In case 12.04 looks aged to you, don’t worry. If you need the newest version of some package there are always ways to get the cutting edge without relying on packages provided by the distribution. Personal Package Archives (PPAs) are a very convenient way to install recent versions of relevant packages and keep them up to date. For any popular application there are well maintained PPAs that can be easily found here.

##Creating The Droplet Now that a release is chosen and the necessary precautions have been taken, it is time to create a droplet. After opening the Droplets view of the DO control panel and clicking the Create Droplet, the process is mostly self-explanatory. The chosen hostname will be how the new server will be called and how it will introduce itself to the outside world. Something proper, lower-case and memorable is advisable here. The smallest droplet size will do for the project at hands. As server region you probably want to choose something close to your actual location.

The choice of the image from which the droplet will be created warrants some more attention. To get a quickly setup server with a certain service of you choice (Dokku or Redmine for example) you could pick one of the preconfigured images from the Applications tab. Even though Docker is one of them, it is based on Ubuntu 13.04 which will not be officially maintained much longer than the beginning of 2014. My choice here was a simple Ubuntu 12.04 with a x64 architecture found in the Linux Distributions tab.

Make sure the SSH key you created is selected in the Add optional SSH Keys section, if the button is blueish, it is activated. The last step is to enable backups if you feel you will need them. Currently, it is not possible to enable them after the droplet is created. Having backups enabled raise the running cost of the droplet relative to its size. As an alternative, snapshots can be used to secure your data later on. They are billed independently of the droplet, based on the storage space. Unlike with backups, the droplet needs to shut down for a snapshot to be created.

After making all choices and pressing the friendly Create Droplet button, the droplet takes about a minute to come into existence. In the Droplets view, you can navigate to it and inspect all kinds of information and stats, which you should do. To prevent possible surprises: in case you want to stop being billed for a droplet, it is not enough to power it off but it needs to be destroyed as well.

If everything looks fine, the last preparation step before connecting to the droplet is to make SSH-ing to it convenient. Edit your ~/.ssh/config file and add the following lines to it, replacing the all-caps fillers with appropriate values:

Host HOSTNAME #how you want to call the server on your machine
    HostName DROPLET_IP
    Port 22 #this will change soon
    IdentityFile KEYFILE #for example ~/.ssh/id_rsa_do
    User root

The HOSTNAME in this file can be independent of what you chose earlier, and may be as short as needed. With these additions, connecting to your new server is as simple as issuing the command


accepting the server fingerprint on the very first connection attempt and unlocking your ssh key upon request. Welcome to the new droplet.

##Most Basic Configurations Now we have a basic Ubuntu server, running somewhere not-too-far. Neat. The real work is about to begin soon, but before that I would like to go through a few basic things I tend to change on a new server. There are other excellent sources about what can or should be done, this particular link is an excellent read. As always the decision whether particular steps are really necessary depends on taste, project requirements, acceptable complexity and a trade-off between usability and security.

There are two steps that fit into this post, before the real configuration work starts. The first thing I would like to do, is to get rid of lazy brute force login attempts that tend to occur on the default SSH port 22. As fail2ban would be a little overkill for the current setup, a simple solution to reduce the exposure is to switch to a non-standard SSH port. This is not meant to achieve any great improvement of security, obscurity seldomly does. Anybody who is interested in your server will get up to speed on what listens where soon enough, this step is just taken to prevent the accumulation of annoying log entries as a first measure. Edit /etc/ssh/sshd_config with the editor of your choice, and make sure it contains the following lines:

Port 5060
PasswordAuthentication no
ChallengeResponseAuthentication no

The new port number can be anything above 1024 and below 65537. The rest is there to explicitly forbid password logins. After saving the file, you need to restart the ssh daemon on the server for the changes to take effect:

$ service ssh restart

Do not close the initial ssh session with the server before you are certain that everything is working correctly, otherwise you may lock yourself out. In your local ~/.ssh/config file, the value of the Port entry for the server needs to be adjusted. After this, open up another terminal and try to ssh into the server with the new settings in place. If you can establish a new connection, everything is shiny.

The second thing has mostly to do with feeling a little more at home and in control on the machine. I like the information shown upon login (known as motd), to be brief and free from clutter. This can be achieved by manipulating files located in /etc/update-motd.d/. The file 10-help-text can be removed, the line containing landscape-sysinfo in the file 50-landscape-sysinfo needs to be changed to:

/usr/bin/landscape-sysinfo --exclude-sysinfo-plugins=LandscapeLink

These changes disable the obnoxious “Graph this data…” line and the one printing a help link. If you login the next time, the server greeting will be much cleaner.

##Security And Maintenance There are lots of things that can be done here and as stated before, opinions and best practices are numerous. The single best thing you can do, is being vigilant and up to date with security issues. For this, it is not strictly necessary to be fancy and setup an automated updating scheme. In fact there are vocal opponents of such procedures, as updates can induce problems from time to time. My advice would be to subscribe at least to the Ubuntu security list, and update manually when packages you use are in trouble.

Depending on your preferences, it might make sense to create an additional non-root user and disallow direct SSH access the root user. This is not really needed if only one person has access to the machine, as such a setup primarily is meant to provide accountability. If you do not like to yield root powers at all times, configuring sudo can give a little peace of mind.

Setting up UFW or adjusting iptables directly is a good thing to do in the long term, but as there are no unwanted services listening to external ports due to sane defaults it can be delayed for now. Taking care of a firewall and other security relevant settings will be covered in a future posts, when the need for them arises.

After all is said and done, the droplet is created and minimally groomed. It is ready to be used for something interesting, besides behaving well and being nice to log into. Installing and configuring basic packages as well as Nginx and Docker itself will be the topic of the next post.

Struggling to "get" Docker? Level-up with my new book.
It will help you to fix your knowledge gaps, get an overview of Docker and understand the "why" behind container technology.
Get Better With Docker

Subscribe to get useful Docker tips and tricks via email.

     (About the content, privacy, analytics and revocation). 

    We won't send you spam. Unsubscribe at any time.

    Powered By ConvertKit