-
Notifications
You must be signed in to change notification settings - Fork 438
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Dockerfile variant for clustered deployment on Fly.io #2286
Conversation
Uffizzi Preview |
~S""" | ||
# Custom startup script to cluster multiple Livebook nodes | ||
RUN printf '#!/bin/bash\n\ | ||
export ERL_AFLAGS="-proto_dist inet6_tcp"\n\ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we move the static variables out of the script?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a specific reason? If we could move them all that would make sense, but since LIVEBOOK_NODE
is runtime, I would keep together for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea was to keep only runtime ones in the runtime script. Also, any thoughts in an approach like this?
ENV ERL_AFLAGS "-proto_dist inet6_tcp"
ENV LIVEBOOK_DISTRIBUTION name
CMD [ 'sh', '-c' , 'LIVEBOOK_NODE="${FLY_APP_NAME}-${FLY_IMAGE_REF##*-}@${FLY_PRIVATE_IP}" LIVEBOOK_CLUSTER="dns:${FLY_APP_NAME}.internal" /app/bin/livebook start']
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea was to keep only runtime ones in the runtime script.
Yeah, the practical difference is whether the env vars are set globally, which I don't think they necessarily should be? Also, normally all of these would go to env.sh.eex
, that's why I prefer to keep them together.
I considered CMD, which we could even break it into multiple lines, but what I like about creating a startup file is that usually you'd have that file alongside and COPY
it, so it's the closest to that (and if the user wants to do that, it's easy). Also for CMD you actually must use double quotes, because because technically it is parsed as a JSON array 🙈
# Custom startup script to cluster multiple Livebook nodes on Fly.io
RUN printf '\
#!/bin/bash\n\
export ERL_AFLAGS="-proto_dist inet6_tcp"\n\
export LIVEBOOK_DISTRIBUTION="name"\n\
export LIVEBOOK_NODE="${FLY_APP_NAME}-${FLY_IMAGE_REF##*-}@${FLY_PRIVATE_IP}"\n\
export LIVEBOOK_CLUSTER="dns:${FLY_APP_NAME}.internal"\n\
/app/bin/livebook start\n\
' > /app/bin/start.sh && chmod +x /app/bin/start.sh
CMD [ "/app/bin/start.sh" ]
vs
# Custom startup script to cluster multiple Livebook nodes on Fly.io
CMD [ "sh", "-c" , "\
ERL_AFLAGS=\"-proto_dist inet6_tcp\" \
LIVEBOOK_DISTRIBUTION=\"name\" \
LIVEBOOK_NODE=\"${FLY_APP_NAME}-${FLY_IMAGE_REF##*-}@${FLY_PRIVATE_IP}\" \
LIVEBOOK_CLUSTER=\"dns:${FLY_APP_NAME}.internal\" \
/app/bin/livebook start" ]
Co-authored-by: José Valim <[email protected]>
This reverts commit 887f81a.
Co-authored-by: José Valim <[email protected]>
Preview
There is still an issue related to booting apps that I need to address.