A number of people over time have asked to be able to deploy multiple instances of an app to the same server. (Without resorting to containers to create new namespaces. We can argue offlist about that)
I wound up wanting to do this, particularly because I wanted to disable all
the mgmt functions of an application on the publically facing URL, but of
course point at the same database behind. I also wanted two instances.
Some people wanted 1000s of instances.
So I scratched my itch.
Additionally, it's nice if each instance has it's own user.
While one can write a shell loop with different deploy_to settings, that
seems daft. Ideally a future enhancement would share a read-only repo across
instances...
The core is getting deploy_to to look at @host for a custom :deploy_to
property. I thought that I could just hack it noticing that the Thread
variables contain the right info:
Thread.current["sshkit_backend"].host
but, this was not reliable for a couple of reasons. One is that not all
calls occur within a thread, and there are a number of things which
fetch(:deploy_to), and then set a variable.
So that variable now needs to be per-host as well.
The second issue that I realized is that "on" fabricates a temporary host
so that some settings can easily be overriden in the task, without losing the
globals. Some settings like release_path needed to get remembered.
I also had trouble with the generated /tmp/git-ssh-app-env-user.sh file.
I had to move it to deploy_to/tmp, because /tmp conflicted. One could use
/run/user/XXXX, but I'm not sure how to easily get the right path; I suspect
that there is some variable ($XDG_RUNTIME_DIR), but I didn't figure out if
it gets set correctly.
I wound up making a mess where I pass host (often called "role") into various
functions in order to make it available at the bottom. Maybe this is really
the best way to do this without thread hacks;
A lot of small patches that do stuff like:
on release_roles :all do |role|
... use role
end
---> advice is sought <---
It seems like there ought to be a better way.
https://github.com/mcr/capistrano/commit/80fc662607d469cd07f1725f7e2e1f3ce8d3dbce#diff-fbe96d6b569c70be813c99cb331eda79R22
Vagrant/Virtualbox and KVM do not play well on a desktop, and I have
KVM stuff happening on my Linux devuan desktop(s), and I didn't succeed (yet)
in getting the right VMs up to run the capistrano rspecs.
Very happy to see this level of testing!
I will boot off an ubuntu X VM to try again.
I noticed that vagrant has an AMS option, but I didn't figure out how to
install that. I think that if I'm just running the right popular desktop
that I can have vagrant:libvert and it will do the right KVM stuff.
(My code works, btw, at this point)
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/capistrano/16304.1508949001%40obiwan.sandelman.ca.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
