Please watch the videos under Resources before class.
Changes to the Final Project Instructions
Removed Cloud Based Deployment as an elective option from the Final project instructions. I realized that fly.dev updated their pricing model and free servers are now a thing of the past. I am ethically against a pay for credit model, thus the option to earn 5% of the finaly project grade by deploying to the cloud has been removed for all students.
Releases (3 points)
We will still practice releases though - the system of deployment that almost all cloud hosting and custom providers use.
From the official phoenix documentation:
Our main goal for this guide is to package your Phoenix application into a self-contained directory that includes the Erlang VM, Elixir, all of your code and dependencies. This package can then be dropped into a production machine.
We are going to mainly follow the official phoenix guide with some alterations.
Please start with either a new phoenix project or reuse the phoenix_react project from the last assignment (recommended). Make sure you open it in VS Code by either creating a new workspace or opening the folder phoenix_react or that of your new project.
We want to see the files on the left resemble the new project, not your semester-long class project.
Lets first prepare our environment. If you open runtime.ex you will find that the server will not start unless two environment variables DATABASE_URL and SECRET_KEY_BASE are set.
We should have set SECRET_KEY_BASE already as part of the initial class instructions to get phoenix running. We can reuse the same variable.
Lets now look what we have by opening either
~/.zshenv(if you use mac or zsh shell)~/.bashrc(if you use unmodified WSL)
You should see SECRET_KEY_BASE alread set up, if not create an entry like this:
mix phx.gen.secret
REALLY_LONG_SECRET
echo 'export SECRET_KEY_BASE=REALLY_LONG_SECRET' >> ~/.zshenv
For the DATABASE_URL we will use our postgres user on localhost:
echo 'export DATABASE_URL=ecto://postgres:postgres@localhost/phoenix_react_prod' >> ~/.zshenv
If you don't reuse the phoenix_react project you will need to replace the database name phoenix_react_prod with something more appropriate. Just make sure it doesn't clash (equals) what you use for your main web application.
With both environment variables configured we can source the file and move on.
source ~/.zshenv
First we want to compile all dependencies again for production:
MIX_ENV=prod mix compile
This will optimize some parts as ommiting debug messages during compilation and more.
We also like to compile our frontend assets for production which will minimize and gzip css and javascript files and create a cache_manifest that contains a mapping of renamed files with their sources:
MIX_ENV=prod mix assets.deploy
Now we are ready to generate a release:
mix phx.gen.release
As you can see a few new files have been created. Those are binaries to run and migrate the server. Before we can do that however, we need to still build the actual release:
mix release
Stop your dev server if it is still running and then try:
./_build/dev/rel/phoenix_react/bin/server
Vola, go to localhost:4000 and find the server running via binary optimized for production!
This is a binary which means we could use the operating system to create a service or a daemon out of it to keep it running permanently, even after rebooting the system. But that is outside the scope of building releases.
You will get points for being able do demonstrate that your phoenix project is running via release.
Comparison (4 points)
Now we have seen three variants to run a phoenix server:
- via development mode (local development)
- via production mode (linux remote deployment)
- via release binary (regular deployment)
You can do all three on your localhost.
In this final objective I do want you to display memory usage and thread count for all three variants and display them via screenshots on either a controller page or the react app homepage.
Please start your server in all three variants and open Activity monitor (MacOS) or Task Manager (Windows) and find your running phoenix server. You will see something like this:
Now this should help you figure out what tier of memory we would need to use for a cloud service provide.
Also discuss briefly on your page the differences you find in terms of memory usage between releases / running in dev / running in production. (if there are any).