TL;DR: Needed a way to easily deploy and manage legacy and new sites without spending a lot of money. Dokku gives me the awesome Heroku developer experience on a cheap VPS box. Since I started working on the web, I've been publishing small sites. Usually I use these pet projects to try out new technologies, so most of them don't share the same technology. Some are almost 10 years old. Of course, I don't have the time to maintain them and their owners are not interested in spend more resources to bring them up-to-date. So I'm stuck maintaining the hosting for very different projects.

To save on expenses and time I used to host them all in one cheap VPS, but things were becoming complicated as language versions become deprecated. Keeping them in a shared environment is a challenge because different applications use different versions of PHP, databases (some use mysql, others Postgres). I even have .NET core sites running.

This year I decided to find a better solution, where I can keep all together and still make it easy to deploy or create resources on the server. So I tried Azure, AWS, Heroku and several others.

The best ones, of course, were not cheap. I think Heroku is still one of the best one in terms of developer experience. So looking around I came to know Dokku, which is an open source platform similar to Heroku (and it even uses their Buildpacks).

What's in a Buildpack

Heroku works using Buildpacks. You can picture them as the instructions on how to build and deploy an application. Dokku use these Buildpacks too to create container images and run them.

But, what about the ones with specific requirements? I have some sites that require wkhtmltopdf. Well, it turns out that it is possible to customize the image that Dokku builds by using deploy scripts that run at different stages in the deployment process.

OK, How does it look like?

To deploy a new PHP application that uses a MySQL database, this would be enough (assuming you installed and configured the Dokku bash client):

# Create a database
dokku mysql:create myphp_db
# Create a new application
dokku apps:create myphp_app
# Allow the application access the database
dokku mysql:link myphp_db myphp_app
# Deply the application
git push dokku master

Dokku identifies it is a PHP application if it finds a composer.json file. In it, you can specify the PHP version to use and if you need special extensions, like bcmath.

For example:

"require": {
  "php": ">=7.1",
  "ext-bcmath": "*"
}

You can then configure your PHP application to read the database connection details using environment variables. Once a database is linked to your application you will have in the DATABASE_URL environment variable a full DSN to connect to it. If you need to, you can declare more environment variables like this, not necessarily related to the database:

dokku config:set MYSQL_DBNAME=myphpapp MYSQL_USERNAME=mysql ...

Advantages

1. The developer experience. It allows me to manage sites and its resources without leaving the terminal. The experience is very similar to Heroku.

2. It can be fully automated. For example, pulling database dumps to a development environment, schedule nightly backups and SSL certificate renewals.

3. Zero downtime deployments.

Kubernetes

But... Dokku works using docker... that's so 2014. Dokku is already working on Kubernetes support (and should be functional at this point), although I don't mind to use and old technology if it works. However, I wish it could use podman to avoid the security risk of having a docker daemon running.

#devops

I normally work on different and very active projects in several testing environments. I needed a simple and fast way to generate visual regression tests between them, or even to just to compare my local environment to an integration server. However, it was cumbersome to edit backstop configuration files frequently just to change servers, thus I created a tool that simplifies the task a lot:

https://github.com/arturolinares/easy-vrt

It is a Symfony console application that wraps Docker backstop containers to run the tests. The application reads a list of URLs from a CSV file to generate the JSON configuration files for BackstopJS.

Usage

Once the project is installed you will want to compare two sites. Follow these steps:

1. Generate the backstop scenarios using a CSV file containing the routes to visit.
2. Run the tests.
3. Browse the results to visualize the differences.

To generate the scenarios use the command vrt:gen. It will use a CSV file with the routes to generate them:

bin/console vrt:gen path/to/routes.csv --ref-domain=http://prod.com --url=http://my-qa.com

You can find a sample of the CSV file in the sample directory. The file has two fields: the route and an optional label. For example:

/,"The Homepage"
/category/tag,
"/about-us", "About US"

You can set the reference domain using the flag --ref-domain. This is normally production. Use the flag --url to specify the domain you want to compare.

Sometimes you need to create several scenarios for the same route but different prefix. For example, when using multilingual sites. To specify the prefixes you can use the --prefix (-p) option:

bin/console vrt:gen path/to/routes.csv -u [http://my-qa.com](http://my-qa.com) -r prod.com -p es -p en -p fr

The above will generate scenarios for these urls:

/es/
/en/
/fr/
/es/category/tag
/en/category/tag
/fr/category/tag
/es/about-us
/en/about-us
/fr/about-us

Until now, you only have configured backstop. To actually run the tests use vrt:run. This command will run backstop using a Docker container. Also, if you want to see what the script is doing, you can change the verbosity with -v, -vv and -vvv.

Finally, to see the report, use vrt:server to browse the diffs.

#devops #testing