Setup your deployment using Dokku

Production deployment environments come in all sorts of variations nowadays. The configuration architecture is mainly influenced by the size of the application and the budget but also about the process flow and how easy it is to do the deployment. Quite often, at the beginning phase of application/business, it is quite reasonable that you might not need a full-fledged cloud deployment setup. This post assumes that you have small infrastructure requirements but you want a smooth deployment process.For a simpler scenario when you need a single server or few of them, Dokku does a great job by making it possible to push code to production by a simple git push.

Dokku is a Heroku on your own infrastructure. It allows easy management of the deployment workflow of your application by managing applications in docker containers. It also uses an Nginx reverse proxy but as its configuration is managed by dokku itself, you barely notice it. After you deploy your application, you can scale your application up and down with a single command. Through Dokku plugins, you can also create and manage database instances (e.g. Postgres or MySQL), schedule automatic backups to AWS S3, create redis instances and configure HTTPS using Let’s Encrypt.

Some cloud infrastructure providers like Digital Ocean offer a ready-made server image of Dokku which you can instantiate in minutes and start using it right away. In this post, I will go through the process of installing and setting up your own Dokku environment. For this writing, I’ll suppose you have an Ubuntu Server with ssh enabled already in place. For your information, I have a virtual machine (VM) on VirtualBox running Ubuntu 16.04, but you can do the same on any instance of Ubuntu running anywhere. Off we go…

Step 1: Installation of dokku

To do the installation, we follow these commands:

The first line will download the installation script and the second line will actually do the installation. Downloading the script will be fast, but the installation itself will take few minutes (depending on the performance of your server). Please check the this page to find out the most recent version.

dokku setup page

Here in the “Public Key” field, we should paste our public key (mine is at ~/.ssh/id_rsa.pub) and then click Finish Setup button. As of this step, our dokku is set and ready.

Step 3: Creating and deploying an application

Now that we have dokku ready, we want to deploy our first app. Setting up the application is a one-time thing which we need to do from the server’s console. After we are connected to our server using ssh, we can create and configure the application in two steps:

    • Run  dokku apps:create name_of_app to create the app. We can verify that the app is created by running  dokku apps:list
    • Run  dokku domains:add hello hello-world-app.com to configure the domain of the app.

In order to serve the app, nginx needs to have a domain configured for the app. If you have a domain to configure, go for it. For this post I will use a fake domain which I will map in my /etc/hosts file to the IP address of my VM. So for this example, I will use hello-wold-app.com domain.

Next, we need to set the git remote for the dokku environment. We do this by running  git remote add remote_name dokku@dokku_server:name_of_app. Here,

  • remote_name is the name we want to give to our deployment environment, this could be anything you like e.g. production, staging, etc.
  • dokku_server is the IP address or the URL of the dokku server we just configured
  • name_of_app is the name we specified when we created the app.

Now that we have it ready, we can deploy our app by running  git push dokku_server master. When the deployment is finished, you can test you application by visiting http:://hello-world-app.com

p.s. if you don’t have a ready application to deploy, go ahead and download a hello world web application from my github account.

 

Step 4 (optional): Scaling your application

Now that we have our web application deployed, it is running in a single instance of a docker container. For a production deployment we probably would want to scale it to more instances to have a better performance. As an optimal configuration, probably we would want to scale the app to as many instances as the number of processor cores we have. Assuming we have an 8 core processor in our server, we could scale our app to 8 instances by running

dokku ps:scale name_of_app web=8

after that we can check the instances by running dokku ls either  or sudo docker ps.

Conclusion

When setting up new applications, I try to take the pragmatic approach and keep it as simple as possible. In my opinion, dokku is a good starting point. It makes the deployment process dead simple as well as gives us the flexibility to scale it as we need. As the application starts facing a lot of traffic and this infrastructure starts to have a hard time coping with it, then I think about more advanced deployment workflows.

If you have followed the steps and tried your own installation, I’d like to hear about your experience. Please post a comment and share it with us.

Hope it helped!

Backup your database

To backup your database regularly is one of the tasks that can be very easily accomplished but is quite often neglected until the minute you face the first disaster. Backup solutions can be of very complex types which you might engineer to simple ones like copy and pasting. Depending on your application, the necessity for complex solutions might vary. So what could be a minimum solution that is viable and stable?

The simplest solution in my opinion should contain these elements:

  • Create a dump of the database
  • Copy the dump to another location (different from the DB server)

Now depending on your RDBMS and operating system, you can take different approaches to implement these two tasks. On a Linux system with a MySQL or PostgreSQL, my approach would be to write a shell script which does these two functions. One such a script might look like this

Line no. 3 creates the DATE variable which holds the current timestamp. It is used to construct the name of the backup file. Line no. 5 creates the FILE variable which holds the complete path of the backup file. Line no. 7 is the MySQL command to dump the database named “db_name” to the path determined in line no. 5.

So far, this code completes the first task of backup up the database. The next task is to copy it somewhere else so we don’t have the db and backup on the same disk. Now this “somewhere” could be some other server, some other disk, or somewhere else e.g. cloud storage. My preferred choice would be to put it to a cloud storage like AWS S3. Having aws cli installed, copying the backup file to an AWS S3 bucket is a one line code

The complete file would look like:

Conclusion

I know a lot of people might not agree with me that this is a good solution, but in my opinion, this is the minimum code that does the work. What you need to do next is add this script to /etc/cron.daily folder and your script will execute daily and do the backup for you (please make sure that permissions are correctly set so it can be executed). It is not the most elegant solution but does the job.

As a bonus point, I would also add a “done” notification to a script which would send an email or post to a slack channel or whatever notification that suits you so you know that your script has executed.