Cloud 66 for Rails switching to systemd
For many years we are have relied on Bluepill to manage processes on the Rails servers we deploy, and it has done the job excellently. However, as both our business and our platform have evolved, we've come to the point where we need to replace Bluepill. We've chosen to keep things simple and transition to using systemd - Ubuntu's default (and optimal) process manager.
Why are you changing?
We've been maintaining a fork of Bluepill for several years and, as frameworks and operating systems have changed, it has become increasingly difficult to maintain. Over the same period Ubuntu replacing their own manager (called "upstart") with systemd, which is a much better process manager, and can handle everything that Bluepill currently does.
Faced with having to rewrite our fork of Bluepill, or transitioning to the community-backed certainty of systemd, the choice was obvious to us. Our main concern now is ensuring that our loyal customers understand how this transition will affect their servers, and how we will be managing the process of migrating across to systemd.
What does this mean for me?
First and foremost, existing applications DON'T need to change! We understand intimately that change can be a pain, and very disruptive, especially when not originating internally. You can of course opt to upgrade your existing servers at any time, if you wish.
As of now, any new Rails applications created will be backed by systemd - please get in touch with us if you have any questions or concerns around this. If you're a new Cloud 66 customer (joined in June 2020 or later), then your servers should already be using systemd, so you don't need to do anything.
If you're accustomed to managing your web server directly via terminal commands (stopping, starting, reloading etc), you will need to use systemd syntax when doing so for systemd backed servers. Please read our how-to guide on the subject.
No more daemonized processes
The single most important difference, from the perspective of a Cloud 66 user, is that our systemd doesn't support processes that daemonize themselves - for example by starting a process with the -d flag. This is part of a long term move away from self-daemonizing processes. The new method is much cleaner and more reliable. Persistent processes are managed and kept running by systemd exclusively.
What this means, in practical terms, is that any existing Cloud 66 users that have commands or processes that rely on self-daemonization will need to update those commands before they migrate to systemd, or they will cause errors. We'll go into more detail in our migration plan below.
Migrating existing Rails Applications
By default we will not make any changes to your existing applications or servers. You can, however, opt to manually migrate your own application at any point from Bluepill to systemd.
If you wish to migrate, follow our checklist below. These actions require the user to have admin permissions for the given application.
To migrate and existing Rails Application from Bluepill to systemd you need to:
- Ensure none of your process initialization strings in your Procfile use daemonization flags like -d or -daemonize. Using these flag with systemd will cause the process to terminate prematurely.
- Check and update any of your config files that enable daemonization. This is particularly relevant for users with the custom web servers: Puma, Unicorn, or Thin.
- Set your application(s) to migrate to systemd either:
- Using the web Dashboard :
Click "Settings & Information" in the right-hand panel of your stack page, then click "Switch to Systemd" (in the Process Manager line)
- Using your Cloud 66 Toolbelt :
cx settings set -s APPLICATION_NAME migrate.bluepill.to.systemd true
- To apply your changes, its best to redeploy your application.
NOTE: As always, we recommend testing your changes in a non-production environment before updating your live application.
Example
If you're currently using Puma as your web server you are probably running it using a command similar to this one:
custom_web: bundle exec puma -d
In order for this process to work with systemd, the command would need to look like this:
custom_web: bundle exec puma