Tiny helper script to start Livebook connected to production (fly.io) or development

zachallaun

Hey friends, wanted to share a tiny shell script I’ve been using to start Livebook with easy access to either a running production server or a development server. This is based on the fly.io guide and offers nothing really new or novel beyond some small conveniences:

Starts Livebook with a default data directory set.
Sets the default runtime to be Attached, configured for your development or production server, so that you can immediately get going in that environment without having to set anything up.

Pre-reqs for development server:

For Livebook to connect, you need to start it with an sname and cookie:

$ iex --sname my-server --cookie my-server-cookie -S mix phx.server

Pre-reqs for production fly.io server:

You’ll need to have set a static cookie.
You need to have set up your fly.io Wireguard tunnel.

Script:

#!/bin/sh
# connect-live.sh

fly_app=my-fly-app
fly_cookie=$ERL_COOKIE
dev_app=my-server
dev_app_cookie=my-server-cookie
data_path=notebooks
home=notebooks

case "$1" in
  "prod")
    ip=$(fly ips private --app $fly_app | cut -f 3 | sed -n 2p)
    node=$fly_app@$ip

    ERL_AFLAGS="-proto_dist inet6_tcp" \
      livebook server \
        --name livebook@127.0.0.1 \
        --default-runtime attached:$node:$fly_cookie \
        --data-path $data_path \
        --home $home
    ;;

  *)
    node=$dev_app@$(hostname)
    livebook server \
      --default-runtime attached:$node:$dev_cookie \
      --data-path $data_path \
      --home $home
    ;;
esac

Make sure to chmod +x connect-live.sh, then getting things going is as easy as:

$ ./connect-live.sh # start with development defaults
$ ./connect-live.sh prod # start with production defaults

As a final note: I do next to no shell scripting and the above may be total crap, but it took me a bit longer than I’d like to get this kind of thing set up in the first place and now it’s very convenient & easy, so I thought I’d share!

4 comments

/livebook #deployment

8 1648 4

2023-02-04 10:17:25 UTC

Showing Posts 1 to 4

Show Best Posts
Show All (oldest first)
Show All (newest first)

zachallaun

Script updated for Livebook 0.8.1 using environment variables instead of flags:

#!/bin/sh

# Usage:
#
# Development:  ./connect-live.sh
# Production:   ./connect-live.sh prod

fly_app="my-app"
fly_cookie=$ERL_COOKIE
dev_app="my-app"
dev_cookie="dev-cookie"

export LIVEBOOK_HOME="notebooks"
export LIVEBOOK_DATA_PATH="notebooks"

case "$1" in
  "prod")
    echo "[PROD] Starting Livebook..."
    fly_ip=$(fly ips private --app $fly_app | cut -f 3 | sed -n 2p)
    fly_node="$fly_app@$fly_ip"
    export LIVEBOOK_DEFAULT_RUNTIME="attached:$fly_node:$fly_cookie"
    export LIVEBOOK_NODE="livebook@127.0.0.1"
    export LIVEBOOK_DISTRIBUTION="name"
    export ERL_AFLAGS="-proto_dist inet6_tcp"
    ;;
  *)
    echo "[DEV] Starting Livebook..."
    dev_node="$dev_app@$(hostname)"
    export LIVEBOOK_DEFAULT_RUNTIME="attached:$dev_node:$dev_cookie"
    ;;
esac

livebook server

Post #1

linusdm

That’s a nice alternative to doing all that manual setup to connect to a remote fly app. I recently was thinking of something similar.

If you keep your secrets in a password manager like 1password, you could use their cli to inject the cookie too. You’d be prompted for a password, and nothing else. I like to keep all secrets related to one deployment in a secured note (there are probably better ways to do it though).

Just out of curiosity: what kind of things do you do when connected to a remote host?

Post #2

zachallaun

Nice tip on the password manager! I personally use direnv, so project secrets are kept in an .envrc that’s gitignored.

Some context first: my primary project is a site for our business of which I’m the sole developer, so I’m able to play some things a little more fast-and-loose than I might otherwise.

Two primary use-cases for me:

Debugging. When something’s reported, it’s really convenient to just be able to poke around and see what’s up, what state things are in, etc. instead of having to rely on what Zach of yesterday thought to log.
Performing one-off or infrequent tasks that I haven’t gotten around to making a UI for. Basically using Livebook as a bespoke admin interface. There are some things that are really easy in code, e.g. nested data structures, that are kind of a pain in the ass otherwise, e.g. nested forms. This lets me play around with new features that have a business-logic implementation but don’t yet have a nailed down UI.

Overall I’ve found it extremely productive and pretty indispensable as a solo dev! As mentioned, if I were working on a larger team and hadn’t written literally all of it myself, I’d exercise more caution on making sure that I don’t break something.

That said, I do have a scratch notebook that I use for all this that has this nice warning at the top:

Post #3

linusdm

Those are the usages I had in mind too! It’s much nicer than a plain IEx session. And the notebook allows to set up some scenario’s that you can easily repeat.

That screenshot is great good reminder of the responsibilities that come with this power…

Post #4

— All posts loaded —