Setting up your own database on DigitalOcean or Vultr or other generic VMs

rubyonrails-talk
1

Hi everyone, I would love to hear your experience setting up Mysql or Postgres on cloud VMs.

  • How easy was it for you to set it up? I am thinking about hosting the DB in the same box using Docker. Would it be too slow if I did that, or if I were to use bigger instance, it’ll be ok?
  • Is there any security consideration I should think about? I am worried that I won’t do a good job in this area. What are some basic things I must do to prevent intrusion?
2

Hi,

I am using PostgreSQL and don’t have any trouble using it on the cheapest cloud VMs. These are hobby projects, though, and we always had managed databases at work.

How easy was it for you to set it up?

Because I depend on the pre-packaged PostgreSQL from Fedora or CentOS, the setup is not as difficult, although it can get complicated with extensions. RPM packages will come with the default configuration (like pg data path) and right SELinux settings etc.

I am thinking about hosting the DB in the same box using Docker.

Although you can use Docker nowadays, I have to ask why? You can still keep your app in Docker if that’s what you already have and use the native package for the database.

Would it be too slow if I did that, or if I were to use bigger instance, it’ll be ok?

As said, I run a Rails app with PostgreSQL together on the cheapest instance of Digital Ocean. I don’t know what kind of load are you expecting, but you can start small. I say, keep it simple and run it together in the beginning.

Is there any security consideration I should think about? I am worried that I won’t do a good job in this area. What are some basic things I must do to prevent intrusion?

I strongly recommend studying this a bit more if your service goes to production. Databases are a very sensitive part of your application, most likely containing your customers’ secrets (like hashed passwords). You don’t want to mess it up!

Here are some basics to get you started. My recommendations will depend on whether you expose your database or not (by exposing, I mean binding it to non-localhost addresses and opening the port in the firewall settings).

If you will hide your database from the outside world, bind to localhost, and authenticate your app using the peer or scram-sha-256 strategy. You can access your database from your workstation with SSH tunneling. This way you can avoid setting up TLS certificates for the database.

If you need to expose your database (e.g. making it a standalone server), bind to a trusted subnet, authenticate your app using scram-sha-256 and set up TLS certificates for accessing the database using psql.

Note that these recommendations are for packaged PostgreSQL in Fedora and CentOS. Otherwise you need to take care of running them as separate user, use a process manager, create SELinux rules, and more…

I cover both of these use-cases (and much more) in my upcoming book Deployment from Scratch. It should have a pre-release within few weeks.

It will also have 2 relevant examples:

  • A complete full-featured Rails application deployment with a local database on the same server
  • A standalone PostgreSQL cluster with self-signed SSL/TLS and firewalld service

These examples will be scripted! You can run a bit of Bash code, and you will have a secure instance of PostgreSQL up and running (even including automatic system updates and log rotation for everything).

1 Like
3

Thank you for the response. Your books sound good!