Karolis Scerbiakas

Let's clean up or tips how to run your infrastructure

Karolis Ščerbiakas -

Note: Article might be little bit dated depending on your perspective. But I think it still might be useful. I also updated it to be more relavant.

Let’s admit it. Every developer or sys admin or whoever had this “production” server which never felt right. Bloated with packages you don’t need, languages you don’t use, dependencies you wonder how they ended up on your machine in the first place. And now you want to do it properly, optimize your server for performance to get the most of your hosting plan. Let’s be honest here there is very little to gain from optimisation your app if server on which it is running is trashed with things it don’t need and eating up resources in the background.

Service vs Do it yourself

You can start fresh and do everything your self for your application, but I’m writing with Laravel in mind, which is one of the most popular web frameworks today. And Laravel ecosystem happens to include server provisioning tool — Laravel Forge or for Wordpress serverpilot.io . A service which connects to your hosting provider via API key and sets everything up. Creating and configuring a server. It also integrates with Bitbucket, GitHub and GitLab.

So what Laravel Forge does exactly behind the scenes ?

It installs LEMP stack (Linux, NGINX, MySQL, Php), UFW (simplified firewall rule management tool), NodeJS, sets up SSH with password login disabled. Creates user and manages permissions etc. This is is fairly simple setup, given in mind that Forge keeps your app and OS with latest security updates. Too bad it doesn’t support other applications by default like node apps or swift. (But its not complicated to get them running)

But when from time to time developers have to wear devops/sysadmin hats. This is where fun starts!

Like setting up Nginx to setup properly can take like from 10–40 minutes. When you get 502 or your domain from browser won’t load any content (even error message), other 500ish errors start popping up can also add up to your joy or no errors at all. Probably you forgot to open up 443 port. But you have figured that out like 30 minutes later.

MySQL and PHP probably one of the easiest things to configure because every developer had to go though it before building an app in the first place.

UFW when you use latest OS version adds main rules by default and adding them isn’t that difficult in the first place, but often overlooked step when deploying your server but it shouldn’t be hard to add them via your server management console (forge or smilliar)

Migrating projects to a new server

So basically what you need to do is to have all your project files in git repository and database exported in sql file.

Add public SSH key to Forge’s account under Servers > SSH Keys. You can add public key at your home directory in .ssh folder open terminal and run this command.

cat ~/.ssh/id_rsa.pub

If you have other named keys, just add the one which ends with .pub. Just don’t mix up with private key.

So import SQL file and get off going! Don’t forget to enable SSL!

Tips for running in app production

Managed database

Most cloud providers support managed databases as a service. If you can afford get one, and if your business depends on it, just get it. It’s not worth a headache when monolyth fails. Not if, but when. Managed databases are secure, isolated, scalable and replications etc. Everything you need it’s all there. Oh and you can scale better down the road, or update or change server provider.

Docker

Ideally you’d want to isolate your app or parts of it. Not microservices. For example: frontend and backend of a web app. #Microservices one of #hypeWords these days and very few apps really need it and even fewer teams understand how to use it. What usually happens team ends up with sewed up monolyth talking over TCP or HTTP. What you really want to do is run your app in docker container. You are getting these benefits:

  • on the server for production, on your team’s dev machines during development. Environments would match and you would have as less as possible “works on my machine” type of scenarios.
  • You change hosting provider easily. From your ubuntu machine to Google Cloud run. (Note: Managed Cloud Run don't support database over TCP. Just through unix web socket via Google Cloud SQL proxy).
  • If there is outage in that part of the region where your machine is hosted you could get up and running in matter of minutes on the other server. (Assuming database wasn’t hosted on the same server or surface area of an outage)

Bucket for media storage

Amazon S3 is the standard. This is what majority of apps use. But DigitalOcean uses the same API. So all packages written for s3 should work pretty much out of the box. Anyway to the point:

  • cost per GB is significantly cheaper than using server storage.
  • You don’t need to worry if you loose files during outage of server.
  • Upload is slower then uploading to server and storing it there. But to workaround this you can upload directly from a client. Just use presigned urls.

Have a nice day.