Does it expose OpsWorks ENV variables to a sidekiq process?

[ypadlyak]

No description provided.

[wzcolon]

I have a similar issue. It doesn't seem that OpsWorks ENV variables are available in the delayed job workers.

[srteyo]

Hi wzcolon,

what do you mean they're not available? I can access them just fine from this cookbook by using the environment_variables hash inside node[:deploy]. For me, the delayed_job workers weren't sending any emails because the workers themselves needed to be started with the SMTP password as an ENV variable. I don't know if there's a better or cleaner way to do this, but in my case the only way I found to make it work was this in delayed_job.monitrc.erb:

[...] -c 'cd <%= @deploy[:current_path] %> && SMTP_PASSWORD=<%= @deploy[:environment_variables][:SMTP_PASSWORD] %> RAILS_ENV=<%= @deploy[:rails_env] %> bundle [...]

I hope someone finds this useful!

[joeyAghion]

I haven't used Opsworks' environment variables feature because they were limited in number and/or length. (I don't recall which... and it's possible they've been fixed in the meantime.)

I'd happily review a pull request that employed the Opsworks-provided environment variables, if you're interested in working on that. As far as how it would be implemented, you'd probably have to write the environment variables to a file, and then source them from the start script.

I've used the opsworks_custom_env custom cookbook in combination with the figaro gem to automatically load variables from a config/application.yml file into our Rails app's ENV. This works for both the web apps and the delayed_job processes.

[asross]

I noodled around with trying to modify this library to pass in environment variables, but it's a bit tricky to make that work without rewriting the monit template on every deploy.

Instead, since we were already using dotenv-rails in development, we just extended it to production and added the following to deploy/before_migrate.rb:

file ::File.join(release_path, '.env.production') do
  content new_resource.environment.map { |k, v| "#{k}=#{v}" }.join("\n")
end

This (redundantly) copies all of the opsworks environment variables into a file, which Dotenv picks up and makes accessible to the worker processes.

[joeyAghion]

I could see this working. It's similar to what we accomplish with figaro, described above.

If you do want to update the monit configuration that this cookbook writes out, I don't think "rewriting the monit template on every deploy" will be a problem. The deploy recipe already includes the setup recipe, which will update the configuration and signal monit to reload it if the template's generated results are different at all from what's already on disk:

opsworks_delayed_job/recipes/setup.rb

Line 35 in 3e6519a

notifies :reload, resources(:service => "monit"), :immediately

[asross]

This is what I did to inject environment variables directly into the monit template, but after some discussions we decided to go with the .env file because it would also allow us to run rails console and potentially other services with the environment loaded. But it might be helpful to others in the future.