We're now using the same version we used to generate our Gemfile.lock.
Using the latest bundler we got a deprecation warning, which might turn
into an error in the future:
[DEPRECATED] The `--deployment` flag is deprecated because it relies on
being remembered across bundler invocations, which bundler will no
longer do in future versions.
We could also upgrade to bundler 2.x, but since we're using Ruby 2.4 and
Ruby 2.6 comes with bundler 1.17, we've decided to keep this version.
The task `deploy:restart` was doing nothing since we moved from unicorn
to puma.
Now we're also restarting delayed jobs on `deploy:restart`, which is
probably what's expected in most cases.
We need to download the most recent CONSUL and check its `.ruby-version`
file before installing Ruby.
The `rvm1-capistrano` gem knows it and was invoking the `updating` task
before installing Ruby. So we were getting a warning in Capistrano about
the `updating` task being executed twice.
New CONSUL instances who didn't use the newest installer and haven't
done any deployments with capistrano would get an exception because the
`current` capistrano folder doesn't exist yet.
We were using Capistrano's shared folder because it was the default
folder used by the capistrano-puma gem. However, it's easier to manage
it if it's under version control.
So we're moving the old `puma.rb` to `puma/development.rb`, and we use
the new `puma.rb` file for all environments except development. Anyone
installing CONSUL can change these files at will or change the specific
files for preproduction, production and staging environments.
Deploy environment files were loaded after config/deploy.rb was loaded,
meaning if we used settings like `deploy_to` or `current_path` to set
variables inside the config/deploy.rb file, we'd be using the default
settings instead of the ones dictated by the deploy environment files.
This is the same configuration we had with unicorn.
With several workers, we've got two basic configuration options:
* Preload the application and use a hot restart
* Don't preload the application and use a phased restart
I've decided to preload the application because using a hot restart
changes are available immediately, while with a phased restart there are
a few seconds when both workers for the old code and workers for the new
code exist.
Using a phased restart also has advantages, so some forks might want to
disable the `puma_preload_app` setting in order to use it.
Old versions of the installer created this file as root, making it
impossible to change it as a regular user.
So for old installations we need to make sure we've got write access to
this file.
We're using `sudo` because in these applications the installer gives
`sudo` access to the deploy user, so everything works fine with the
default configuration.
While this is not a secret and in theory should be in a file under
version control, currently the CONSUL installer disables delayed jobs by
default, meaning we were keeping two versions of the delayed jobs
configuration file, and some existing configurations have their settings
defined in a file in capistrano's `shared` folder.
So we're moving existing settings to the secrets file.
We were copying the current SMTP and SSL settings to the secrets file
after overwriting them, but we need to copy them before overwriting
them.
The workaround I've found is to copy the tasks to the folder of the
previous release and execute them there.
Existing installations having their configuration settings in the
capistrano shared folder needed this migration.
Note we can't just use `YAML.load` because we'd lose the anchors defined
in the file. So we have to parse the file the hard way.
Since SMTP passwords should not be in a file under version control, and
they're usually configured in the production.rb file (which is under
version control), the natural place to configure it is the secrets.yml
file.
Until now we were using the capistrano shared folder, but that's a bit
inconvenient since changes we've done to the production.rb file (like
changing eager_load_paths when we upgraded to Rails 5) won't take effect
after a deployment.
We're going to upgrade our ruby version, and we need these tasks.
Note we now get a warning caused by `rvm1:install:ruby` invoking
`deploy:updating`. It doesn't seem to be an issue because we don't add
any hooks to `deploy:updating`, and neither do the rest of the gems we
use.
Old CONSUL nginx configurations will probably have a reference to a
unicorn socket. Making that file a symbolic link to a puma socket makes
it possible for the application to keep working without updating the
nginx configuration file.
Puma was adding commands to `rvm_map_bins`, which meant RMV1 wasn't
using the default value of `rvm1_map_bins`.
Changing the order we use to require `rmv1/capistrano3` and
`capistrano/puma` did not fix the issue.
Puma is the server we use in the development environment, so this way we
don't need to maintain two servers. Furthermore, puma seems to offer a
few advantages over unicorn (like multithreading) and no disadvantages.
Images uploaded with CKEditor go to a folder that was not linked, so
every new deploy with capistrano the reference to those images was
lost.
By linking the directory the references to the images remain after a
new deploy.
Ruby and bundler should already be installed in the system
Before we can bring back these commands we need to review them, right now they are raising an interesting exception
