forked from OpenNeo/impress
Matchu
271d477110
I just restarted the impress app in production! First I logged in to see why it wasn't responding, and I saw that there was almost no free RAM left, and that the Rails app had grown to eat it all up! So in this change, we set a memory limit: if the impress app is taking up more than 75% of the machine's RAM, systemctl will try to shrink it down; if it can't, then it will kill the app at 80%. I'm not totally sure whether these bounds are tight enough? I didn't look closely enough at the numbers to see what the app's actual usage was according to systemctl at the time (`sudo systemctl status impress`), so my hope is this is enough. But if we run into a memory leak crash like that again, because it turns out even existing at 75% RAM freezes the machine when running alongside its other processes, we can decrease these numbers! I also don't know the nature of the memory leak, and that could be worth investigating—the app pretty cleanly fits into ~500–600MB when it starts up, but then does seem to slowly but steadily grow. If it could be kept at that size, it's possible we could downgrade the server and save some costs—but that's a question for another day, since making sure we handle memory leaks when they *do* happen is a more important robustness fix! |
||
|---|---|---|
| .. | ||
| files | ||
| deploy.yml | ||
| inventory.cfg | ||
| README | ||
| setup.yml | ||
Dress to Impress is deployed to a VPS server. We use this Ansible Playbook to automate the environment setup! We expect to be deploying to Ubuntu 20.04 LTS, initially with nothing installed. The user you deploy with should have sudoers access. That should be all it takes! First, run `yarn deploy:setup` in the app root, to run the `setup.yml` playbook. This will prompt you for your root password, to set up system dependencies. It should be safe to re-run this, including if you add a new dependency to the playbook, because the steps are non-destructive and Ansible will skip steps that are already satisfied. Then, to deploy a new version of the app, run `yarn deploy`. This will build the app from the code on your machine, then send the source and build output to the remote machine, and switch it to be the new production version. Nice! Note that the setup script references a file named `production.env`, which is gitignored because it contains sensitive information, like database passwords. You should create a `production.env` file in the local `deploy/files` directory, to be copied to the remote server and used as its environment variables.