During some recent research, I made a list of all the Rails/ActiveJob compatible queue backends I could find.
I started with the list from Rails, which is just the queues with adapters built-in to Rails, then added anything else I could find that wasn’t obviously dead (mostly determined by lack of commits for an extended time).
Additions and corrections are welcomed.
0 commentsRecently, when upgrading the Docker base image for a Ruby on Rails app, the app suddenly started raising SSL error: certificate verify failed exceptions when attempting to connect to Postgres. Unfortunately, the error message doesn’t describe why verification failed.
The base image was being upgraded from Debian 9 (Stretch) to Debian 10 (Buster). The Postgres 11 instance (which started life on 9.x, so it’s older) is hosted by AWS RDS and configured to require TLS connections.
It turns out that AWS RDS only supports TLS 1.0. However, Debian 10’s openssl config defaults to requiring TLS 1.2+. The result is the certificate verification error above.
The quick fix is to modify /etc/ssl/openssl.cnf (as this is what changed between Debian 9 and 10) to allow TLS 1.0. Near the bottom of the file, change
1MinProtocol = TLSv1.2to
1MinProtocol = TLSv1.0Or, run this simple one liner:
1sed -i -e 's/TLSv1.2/TLSv1.0/' /etc/ssl/openssl.cnfThe better fix is to upgrade/replace the Postgres server to support TLS 1.2+ since TLS 1.0 and 1.1 are being deprecated.
0 commentsRails 6.0 adds support for multi-environment credentials. Here’s a quick summary of how it works:
By default, behavior is the same as Rails 5.2. To configure credentials for another enviornment, just add --environment <env>.
rails credentials:show [--environment <env>]rails credentials:edit [--environment <env>]rails credentials:helpExample: rails credentials:edit --environment production
(Hint: RAILS_ENV=<env> rails credentials:show won’t work. --environment must be used instead.)
Rails continues to use the 5.2-compatible files (config/master.key & config/credentials.yml.enc) in the absence of an environment-specific file.
If an environment-specific file is available, then that is used instead (and the default file is ignored – they are not merged). This is convenient when you want multiple environments, eg: development and test, to both use the same file. In this example, use the default file for those two environments, and then provide an environment-specific file for production only.
For reference, Rails will look in the following places for the master key for decryption:
ENV['RAILS_MASTER_KEY']config/credentials/<env>.keyconfig/master.keyAnd it will look for the actual encrypted credentials at these locations:
config/credentials/<env>.yml.encconfig/credentials.yml.encMy last post was about using webpacker v3 on Rails 5.1.
This time I want to explore how to replace the traditional sprockets-based asset pipeline completely.
Our goal will be to add Bootstrap v4 and jQuery v3 to an app, handled entirely through webpacker. We won’t even install the sprockets related gems.
We’ll also enable rails-ujs, turbolinks, and even images using webpacker.
I recently started a new Rails 5.1 project. I wanted to try out webpacker, which is now at version 3. Turns out, the webpacker team has been working hard to simplify things and they’ve accomplished quite a bit. Most posts online talk about v1 or v2, and they include a lot more steps than are now necessary.
My goal here is to show how to use webpacker alongside the traditional asset pipeline (sprockets). The next post will show how to completely replace the asset pipeline with webpacker.
For reference, I’m working with ruby 2.4.2, rails 5.1.4, webpacker 3.0.2, node 8.7.0, and yarn 1.2.1.
Let’s dive into the now-simplified webpacker world.
0 comments