Execute a task on multiple hosts with different environment variables

78 views
Skip to first unread message

Francesco Belladonna

unread,
May 4, 2019, 2:50:12 AM5/4/19
to Capistrano
Versions:
  • Ruby 2.6
  • Capistrano 3.11
  • Rake 12.3, Rails 4
Platform:
  • Working on Ubuntu
  • Deploying to Ubuntu server

Is there any way to set different default_env per host? My capistrano deploys to 4 different servers (exactly the same application), but I need to run a rake task on all 4 hosts with a few different environment variables per-host, including rails migrations (it's not the DB config).

Ideallly I'd like to avoid storing the env variables in a file because I'm already storing those in the systemd config

Lee Hambley

unread,
May 6, 2019, 3:39:18 AM5/6/19
to capis...@googlegroups.com
Hi Francesco,

If you have server specific configuration, our standard advice would be to roll that out and deploy it as part of your server configuration management, then the Capistrano tooling can work correctly in the context of the environment where it is being used.

The documentation here https://capistranorb.com/documentation/faq/why-does-something-work-in-my-ssh-session-but-not-in-capistrano/ has a nice graphic to help you understand which files Capistrano may load, and why, when.

Lee Hambley


--
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/0c6b412d-d355-42d3-acc8-b603cc22cbcb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Francesco Belladonna

unread,
May 6, 2019, 2:25:31 PM5/6/19
to capis...@googlegroups.com
I'm aware of that behaviour, I wouls till like to supply environment variables per-host, especially for one-time tasks.
Creating a whole config file for that purpose is definitely excessive.

You received this message because you are subscribed to a topic in the Google Groups "Capistrano" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/capistrano/hiha6TXqp-A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to capistrano+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/CAN_%2BVLWjd_4ZZu7pPfTLiO0O7YFHGyoEby4ObN6w_WB-r_jqJQ%40mail.gmail.com.

Michael Richardson

unread,
May 6, 2019, 4:57:03 PM5/6/19
to Capistrano

I did some hacks to attempt to get different settings per-server, for the case where I was deploying an app multiple times for different tenants on the same host system.  I wanted to change the user, deploy_to, and annoyingly, I had to have a different git_wrapper_path, because otherwise they get deployed to /tmp, and conflict with each other.
Many would suggest this is an ideal use case for containers, and maybe I'll back and do that, but at the time containers were just too immature on the target platforms I cared about.
I'm not clear if you are trying to do something similar or not.

While I eventually got it working well enough for my needs, I what I found is that the places where certain variables were set/initialised or defaulted made it rather difficult.  I think that I have a pull request lingering if you really want it.

My suggestion is to attempt to localise the things you need to do, and then create a task that runs config/deploy/${HOSTNAME} to do the things you need to do which are server specific.

Lee Hambley

unread,
May 7, 2019, 9:16:30 AM5/7/19
to capis...@googlegroups.com
Thanks for your suggestions Michael,

The fact is that Capistrano wasn't designed with this case in mind. There are easy workarounds by overriding the shell, and making sure that the host is capable of sourcing specific files, or uploading files as part of an early step before changing the shell, but because the underlying host system is designed to be customizable in this regard, Capistrano, by design leaves those configuration parameters to the host machines.

I strongly second the suggestion to think about using containers, on platforms where they work, they are infinitely better than Capistrano and as the maintainer for over 10 years now I can say that containers (or, any technology giving you control over your environment absolutely) are an incredible productivity, security and predictability win.

Regards,
--
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages