Multiple builds

[supabase]

Multiple builds

[awalias]

@soedirgo just spoke to paul, the first step here is to actually just automate the building and releasing of the realtime app as a binary

so can forget about all the VM stuff and digital ocean for a moment (although this will probably be the next step)

What we need is that each time somebody tags a release, github builds the app for each environment (for starters just ubuntu and osx is fine), and creates a release with the binaries attached (for example: https://github.com/setvisible/DownZemAll/releases)

this can all be achieved with github actions: https://github.com/features/actions

If you want to start by forking this repo and experimenting on your own fork - then we can merge the actions back into this repo when you've got it up and running

this looks like a good template to get started: https://github.com/actions/create-release

you should start by just building the realtime app on your own OS to get a feel for what dependencies are required (mix etc.) and then here is an example of how the realtime app is built with ansible, so may be able to copy over some of the steps: https://github.com/supabase/kps/blob/master/ansible/tasks/setup-supabase.yml

[kiwicopple]

Quick question - this part sticks out to me:

Build the Phoenix app through ansible (within the builder, not the final image)

Does this mean that you're building the phoenix application on the DO image? eg - installing elixir/mix etc, then running a build?

For this question:

Is realtime usually on the same machine as the DB?

No - this is a standalone server, so it will only run realtime and connect to a separate database specified by env_vars

[kiwicopple]

Just get the binary! Decrease the surface area. Probably better if we switch the docker to do the same - then we can use a slim image

[awalias]

@dragarcia might have some learnings here from the AWS and DO listing processes - I saw one thing which said make sure you don't use standardized defaults for secure seeds / passwords etc.

[awalias]

@kiwicopple this would be an Ubuntu image with just the realtime app installed - would you expose the realtime port directly? Or would we still want kong with single route? (thinking about apikeys/rate-limiting etc.)

[awalias]

also just for clarity, we only want to build the realtime server for now, so everything found within this folder: https://github.com/supabase/realtime/tree/master/server

[kiwicopple]

@soedirgo this one is done now right? nothing remaining?

[soedirgo]

Still, working on 3 and 4, should be done today

[kiwicopple]

all good! take your time and let me know if you get stuck

[soedirgo]

Ack, okay, this is more difficult than I thought. (And I should stop saying "today" or "this week")

What I've done:

• Build from a base image (only testing on DO for now)
• Let the user pass user variables for DB_HOST, DB_PASSWORD, DB_PORT, etc. to ansible
• Build the Phoenix app through ansible (within the builder, not the final image)
• Connect to a database from DB_HOST (again, within the builder)
  I'm using a supabase/postgres droplet for this, and can only say it "sorta works" because realtime said something along the lines of "no table named todos" when I connected to it from the next.js example.

Blockers:

• IIUC the realtime binary needs envars to work. How is this usually done? /etc/profile? Embed into a shell script?
• I need realtime to run on startup. Seems to do with systemd, and on a related note, kps and postgres seem to use systemd slices which I'm new to.
• Is realtime usually on the same machine as the DB? And if so, do we maybe want to build the image with a supabase/postgres base? (Probably for the next step)

[soedirgo]

Does this mean that you're building the phoenix application on the DO image? eg - installing elixir/mix etc, then running a build?

Yeah, I could just get a binary from the releases, but unsure if that's gonna cause incompatibility issues. (Was mostly copying how it's done with Docker)

[awalias]

hey @soedirgo this is a really good intro and cheatsheet to systemctl - the tool we use to manage systemd: https://www.linode.com/docs/quick-answers/linux-essentials/introduction-to-systemctl/

here is the realtime systemctl file from KPS: https://github.com/supabase/kps/blob/master/ansible/files/supabase.service.j2

on the question of env vars the above file also shows how you can specify which file to put the env vars in, so can be app specific

on how to pass them in at run/provisioning time we use cloud config

scroll down and find the write_files directive, we basically just copy a string of the env vars into /etc/supabase.env as per the .j2 file above

[soedirgo]

Gotcha, will grok into those!

On that note, what kind of hardening should I use? Just as a bare minimum. I know postgres uses UFW to block anything but 22 and 5432.

[dragarcia]

aye let me document a checklist for the marketplaces that we're in so far and share it here later on.

[dragarcia]

Hope this helps!
https://github.com/supabase/home/issues/17

[soedirgo]

Awesome, everything in one place. Thanks!