Articles on Devops

Heroku sent us an email about the database behind ips.fastruby.io opens a new window , a small app we run for sharing benchmark-ips opens a new window results. That database runs Postgres 15, and the email gave it an end-of-life date on Heroku of January 20, 2027. If we do nothing before December 20, 2026, they will upgrade it to Postgres 18 for us.

Staying in control of when that happens beats finding out on Heroku’s schedule, so I upgraded it that same night. I skipped the method Heroku recommends for a documented one that suited this database better, and still finished the job with commands that are not in their documentation.

In this article, you will learn how we moved a Heroku Postgres database off a deprecated version, why we copied the data into a new database instead of upgrading in place, how much downtime to plan for, and which parts of Heroku’s tooling failed on us. We upgraded from Postgres 15 to 18, but the steps are much the same whichever version you are leaving behind.

Docker has made it easy to use the same environment everywhere, from development to production. But the most basic Dockerfile, where all your dependencies are lumped together in one image, has hidden costs. In this article, we’ll learn the advantages of multi-stage Dockerfiles both from a security and a performance standpoint, primarily for production images.

In earlier versions of Elasticsearch, types were a convenient way to categorically organize documents within a single index. However, types were eventually deprecated, pushing developers toward a type-less structure in Elasticsearch 7 and later versions. Recently while working on a project to migrate a Rails application from Elasticsearch 2 to OpenSearch 2, we faced the challenge of identifying a way to replicate this behavior in a way that is allowed with OpenSearch. In this blog we will discuss how types were used for document organization and how to achieve the same behavior in OpenSearch.

Need help executing a GitHub Actions workflow for your Rails application, especially when dealing with a MYSQL database? Whether you’re just starting or transitioning from another CI service, navigating potential pitfalls can be challenging. If you’ve found yourself nodding along, then this blog post is tailored just for you.

A default Rails application is typically built with a relational database, such as PostgreSQL or MySQL, as its default data store. Building a Rails application with a NoSQL database can bring some benefits.

Recently, Robby Russel posted opens a new window posted on Twitter asking for Heroku alternatives for small Rails apps. Since it got quite a bit of traction, I decided to explore some options and post my experiences as blog posts.

For my first post, I’ll go for one that I’ve already used in the past and liked it very much: Fly.io

I like them because they’re dead simple and have great docs. The dashboard is pretty good too, but since I’m not one to have too many requirements around my apps, the simplicity of use is what I like the most.

As of May 1st, 2023, Heroku will no longer be supporting the Heroku-18 stack. The reason for this deprecation is to maintain synchronization with the Ubuntu Long Term Support releases. If you are currently running your Rails application on this stack, when you navigate to the Heroku dashboard you will notice a warning to upgrade to either Heroku-20 or Heroku-22 before the end of the Heroku-18 stack life on April 30th, 2023.

While Heroku-18 will not be supported, do not be alarmed or concerned that the apps running on this stack will stop working. Heroku has confirmed that all existing applications will not be interrupted and non-build functionality will still be available. However, to maintain access to security updates, technical support and the ability to perform new builds, an upgrade will be necessary and is highly recommended.

If you search online for using SSH keys with Docker, to access private Github repositories, you will get a lot of search results, but the solutions you’ll find are almost all out of date, insecure, or fragmentary (i.e. they provide a small snippet of information but not a complete solution). Given how popular both Docker and Github are, I found this quite surprising. We recently had to set up Docker with a Rails application that fetches gems from private repositories. We’re also using Docker Compose, which added to the challenge. This comment on the Docker project opens a new window , which is from February 2021, unfortunately is still accurate:

There are several questions and answers out there about how to pull from a private repository (using the hosts ssh key & config). A lot of them are not working, not secure or unanswered

After several hours of research and testing, we have a good solution to share. But first let’s take a look at the different approaches to consider.

Recently I worked on a client project that required me to implement good code conventions across the project. One of the tasks besides implementing the Rubocop standard cops was to write a custom cop for two different Datetime methods, so in this article I will explain how I created a custom Rubocop opens a new window cop that solved that problem.