I hope it helps you experience the goodness and power of a globally connected and distributed Elixir cluster! Even if you don’t need to cluster anything, it can help you get up and running quickly.
Nice! I was looking for the SSH/IEx bit earlier when I was following this guide, so great timing there! What’s the reason for moving those lines of code into rel/env.sh.eex from entrypoint.sh out of interest? Love your podcast BTW!
The reason for moving the ENV out of entrypoint.sh is the ENV was only getting set when the application launched (using the Dockerfile CMD command). This worked fine for launching the application.
When logging in via SSH and running app/bin/hello_elixir remote, the ENV values weren’t set and it would fail to connect to the local running node. The hello_elixir part of the command is a generated shell script. When moving the config to rel/env.sh.eex, it gets generated into a env.sh script that gets auto-executed when running any release command. So it’s really the right place for it to live. Hope that makes sense!
I’m glad you like the podcast! I’d love to figure out a way to get more regular interaction with interested listeners. Maybe a Discord server?
Thanks for the explanation, that definitely makes sense. I’ll make these tweaks you’ve mentioned, having SSH/IEx so easily will be really useful. And FWIW I’d definitely be interested in joining a Discord server for Thinking Elixir
I’ve just made the same updates to my app and it’s working great, SSH and IEx worked no problems. Really nice! ssh-agent and fly ssh issue --agent is really slick too.
My only question, might be a long shot! but is there any way to get an Erlang observer pointing at an Elixir app on Fly? Perhaps using Wireguard like how I connect to Postgres in Fly locally?
That is a good question. I don’t know yet. That would be really cool to get working. In the short-term, check out observer_cli
Add it to your project, then you can :observer_cli.start and get a nice terminal view of most of the information. It even adds some recon scripts for things like “top 5 processes for memory”, etc.
@mcintyre1994 I got a Wireguard tunnel setup and an Observer session open to remote node! So yes, it works. However, it’s not entirely straight forward. I think most of it can be wrapped up into a script to make it easier. I’ll keep playing with it.
Wauw! Just went through the entire guide, and much to my surprise, everything just worked! Thanks for a superb guide, with great explanations. It was fairly easy to follow and I really liked that you took the time to explain the different steps.
Would be great to see an example/tutoral of how to configure libcluster as well and deploy the app as a distributed elixir cluster.
Thanks @mscno! I’m glad to hear it worked for you! I love the idea of going in to clustering, but that felt like overwhelming the guide. I should write that up separately and link to it.
@Mark, thanks for the guide. Surprisingly easy to get clustering set up!
A couple of minor things:
Although likely obvious to many, might it be helpful to state when the second fly deploy is required, after the libcluster config has been added?
When deploying or re-deploying, though the nodes are connected (I checked by accessing the interactive shell as per the guide) I get warnings in the logs (datacentre name made bold here for ease of reading):
2021-06-22T13:04:55.765712833Z app[47501f25] ams [info] 13:04:55.762 [warn] [libcluster:fly6pn] unable to connect to :“{app name}@{ip address}”
2021-06-22T13:04:55.816219860Z app[47501f25] ams [info] 13:04:55.813 [warn] [libcluster:fly6pn] unable to connect to :“{app name}@{ip address}”
Is this expected? If so, perhaps it’s worth mentioning them so that they don’t cause undue concern.
It seems like the connection “failure” warnings and errors are all in regard to connection from one of the two nodes to the other, and not in the other direction, so I’m thinking these warnings may occur because a connection has already been made.
Edit: Erlang 24.0.2 is now available, in case you want to update the guide to use that.
Thanks @DavidO for the feedback! Your #1 is an easy one to do and a good idea.
As for #2, there are a couple things that can be at play here. If the clustering cookie isn’t explicitly given, then it is re-generated during the build/deploy process. This means the new nodes can’t connect to the old nodes because the cookies don’t match. It might also be that a shutting down node is rejecting connections because it is shutting down. When deploying a new release, it is common to see some log churn about connections being broken and rejected.