I have a client that really wants me to use AWS to deploy an internal company database app. He seems really convinced I should be able to do this with ssh access into a single EC2 instance, aka without access to the AWS account itself. How do I explain that I cant do what hes asking without an AWS RDS or AWS terminal access. He says I can load postgres onto the EC2, which I haven’t seen on any deployment guide I’ve looked at so far.
I have it in a testing environment on gigalixir but he “doesnt want it hosted on someone else’s site.” I told him I could use his DNS and an AWS RDS alongside gigalixir and he said it needs to all be on AWS for reasons I dont think he understands.
NervesHub is deployed on AWS. https://github.com/nerves-hub/nerves_hub_web this is the repo. I don’t know very much about how it is deployed, other than docker and CircleCI are involved
So, you have access to an instance? You can install whatever you want, its not recommended, but if its what your client needs
The way I see he wants to install everything in one machine, a local pgsql alongside your app, very manual maintenance
Although the answer is always “It depends”, your client is right that you can run your own copy of Postgres on an instance, and do so right next to your elixir app. A few things that come with that:
You don’t get any managed backups, maintenance, patches, etc. If the node fails, and you’re not backing up properly, then you lose all the data. That’s what RDS aims to be.
It’s not replicated for backups across availability zones. If an AZ goes down, you may not lose data but you won’t be online either.
You won’t get HA for the Elixir App either if it’s just running on one node.
Simply put, it’s not a great production setup. That said, I run some side projects on a single VM including elixir and Postgres, and it’s fine if you’re okay with some of those caveats, or if you can articulate that to your client and they say, “Nope, I really want it this way on AWS”.
My personal preference is to deploy stuff like this with Docker. I prefer it for keeping isolated environments on the same overstuffed VM. https://hub.docker.com/_/postgres has the details on how to get the image up and running, but it’s not an exhaustive crash course on all things docker if you are not familiar with it.
on local, we’re using the config/dev.exs setup. This has postgres and the app running on the same localhost. In prod, how are you configuring credentials: username/password/hostname/database? Are you copying this setup to config/prod.exs? I’m stuck here
❯ cat config/dev.exs
import Config
# Configure your database
config :beefcharts, Beefcharts.Repo,
username: "postgres",
password: "postgres",
hostname: "localhost",
database: "beefcharts_dev",
stacktrace: true,
show_sensitive_data_on_connection_error: true,
pool_size: 10
# For development, we disable any cache and enable
# debugging and code reloading.
#
# The watchers configuration can be used to run external
# watchers to your application. For example, we can use it
# to bundle .js and .css sources.
config :beefcharts, BeefchartsWeb.Endpoint,
# Binding to loopback ipv4 address prevents access from other machines.
# Change to `ip: {0, 0, 0, 0}` to allow access from other machines.
http: [ip: {127, 0, 0, 1}, port: 4000],
check_origin: false,
code_reloader: true,
debug_errors: true,
secret_key_base: "xxxxxxx",
watchers: [
esbuild: {Esbuild, :install_and_run, [:beefcharts, ~w(--sourcemap=inline --watch)]},
tailwind: {Tailwind, :install_and_run, [:beefcharts, ~w(--watch)]}
]
...
Generate IaC code which you run on your own terraform setup. (we currently support AWS / DigitalOcean out of the box and currently developing Azure support as well).
Generate all the app build configuration and github action workflows (a buildpack of sorts).
Setup the deployment pipeline.
Handle containerization.
Handle upgrades via git push.
Handle database provisioning. (in the case of AWS we use RDS)
Handle S3 bucket provisioning.
Essentially you get to setup your own Render / Heroku / Vercel on your own cloud provider and have full control over everything with all the DevSecOps best practices.
You can setup a cheap 1 box server or go all the way to High availability setup that complies to standards.
