Ready to go

This commit is contained in:
Luke Berndt
2021-02-15 21:56:19 -05:00
parent b78f47f0fa
commit 5ecc438ffe
312 changed files with 122 additions and 73935 deletions

141
README.md
View File

@@ -28,47 +28,66 @@ There are a lot of different components that make up the system. All of the serv
## Operations
You can run things in 2 different modes, `test` and `prod`. The big difference is that `prod` expects all of the calls to be https and gets cranky when they are not. I have gotten `test` to run fine on my laptop, so that is probably a good starting point.
You can run things in 2 different modes, **test** and **prod**. The big difference is that **prod** expects all of the calls to be https and gets cranky when they are not. I have gotten **test** to run fine on my laptop, so that is probably a good starting point.
Currently, both `test` and `prod` expect to use S3-based storage instead of local storage. Switching to use local storage would be relatively easy - but for the sake of testing, let's just say use something S3-compatible. Make sure that ~/.aws/credentials has the credentials you'd like to use with your S3-compatible storage provider.. IE:
### DNS Entries
You should have a domain name pointing to the IP address of the server you are going to use.
CNAMEs also need to be created for the various services. Create the CNAMEs below with your DNS host:
- api
- account
- admin
After doing this, you should have the following domains: `api.domain.com`, `account.domain.com`, `admin.domain.com`
### S3 Storage
Currently, both **test** and **prod** expect to use S3-based storage instead of local storage. Switching to use local storage would be relatively easy - but for the sake of testing, let's just say use something S3-compatible. Make sure that ~/.aws/credentials has the credentials you'd like to use with your S3-compatible storage provider.. IE:
```
[default]
aws_access_key_id = [..]
aws_secret_access_key = [..]
```
Copy docker-test.sh.example to docker-test.sh, and/or docker-prod.sh.example to docker-prod.sh.
### Configure
The configurations for both **test** and **prod** come from environment variable files that are read in before the containers are started.
Copy the example files and fill in the required info:
```bash
cp test.env.example test.env
cp prod.env.example prod.env
```
Fill in:
- MailJet information
- S3 information
- Site name
- Admin Email (The email will appear to come from this email. You should make sure it matches the domain MailJet is configured for)
- How many days calls will be archived for.... this is just a UI thing, you need to create some S3 rules to make sure they are deleted
### Scripts
`./docker-test.sh` - sets up docker-compose to run with the correct environment variables for testing
`./docker-prod.sh` - sets up docker-compose to run with the correct environment variables for production
Fill out the Environment variables in both these files. S3_PROFILE should match the profile that is defined in the aws/credentials file. You don't need to worry about the Stripe stuff, since that is dormant.
If you are doing frontend work, you can turn off the de-obfuscation. To do this, edit the Dockerfile for the server you are working with. Change the CMD to:
`CMD ["npm", "run", "start:dev"]` Just remember to turn it off when you make the code public.
### Hosting
I use Digital Ocean and they have been pretty great. If you need hosting, give them a try and use my referal code: https://m.do.co/c/402fa446f7a6
### Service I Like
- 💻 I use Digital Ocean and they have been pretty great. If you need hosting, give them a try and use my referal code: https://m.do.co/c/402fa446f7a6
You get $100 of credit to use in 60 days.
If you need storage, give Wasabi a try. The have been mostly reliable and you can't beat the price: https://wasabi.com
- 💾 If you need storage, give Wasabi a try. The have been mostly reliable and you can't beat the price: https://wasabi.com
- 📨 I use Mailjet... and you need to also. It makes it easy to send out email address confirmations: https://www.mailjet.com
- 🔒 I use Let's Encrypt. It works.
### HTTPS
I use Let's Encrypt. It works.
## Local Testing
### For Local Testing:
- In root dir, run: `./docker-test.sh build`
- `./docker-test.sh up -d`
### Local DNS
You can then browser to:
- openmhz.test
- admin.openmhz.test
It helps to have similar subdomains mapping to localhost/127.0.0.1. I used the domain `openmhz.test`. Feel free to use this, or come up with something clever. If you do something different, make sure you use that instead in the commands below.
Make sure the following is in: */etc/hosts*
On MacOS, make the changes in: */etc/hosts*
````
##
@@ -80,23 +99,15 @@ Make sure the following is in: */etc/hosts*
127.0.0.1 localhost
127.0.0.1 openmhz.test api.openmhz.test admin.openmhz.test media.openmhz.test
````
### Default user name, for Test:
- test@test.com
- password: password
Then load these values into local DNS: `dscacheutil –flushcache`
### DNS Entries
CNAMEs need to be created for the various services. Create the CNAMEs below with your DNS host:
- api
- account
- media
- admin
After doing this, you should have the following domains: api.domain.com, account.domain.com, media.domain.com, admin.domain.compose
- In root dir, run: `./docker-test.sh build`
- `./docker-test.sh up -d`
You can then browser to:
- openmhz.test
- admin.openmhz.test
### Debugging React Apps using Hot Reloading
If you are trying to make changes to any of react frontends, it is a huge pain to have to compile to site and rebuild the container each time you make a change. Instead, simply run the react app in development mode. This will work for the frontends for the:
@@ -109,24 +120,20 @@ First, start up all of the containers as described above. You will still the bac
Now go into the respective sub directory for the component you are interested in and run:
````
source ../test.env
yarn install #only need to do this the first time, it installs the Node packages locally
yarn start
````
This should build the frontend and open a browser. In order to have all the cookies work correctly, you have to use the same domain name. Make sure you have setup the local domains as described above. Then goto the base domain, for me that is openmhz.test, at port 3000 `openmhz.test:3000`
### Mailjet
Sign up for MailJet!
https://www.mailjet.com
### Managing MongoDB
## Managing MongoDB
MongoDB is used in the backend to store data. It is pretty fast, flexible and has worked well enough for me.
All of the files that MongoDB uses to store the DB are in the */data* directory, which gets mapped into the contianer.
Mapping this directory makes sure that the data persists each time you run the mongo container.
#### Working with the MongoDB Container
### Working with the MongoDB Container
From the Host OS run:
```bash
@@ -137,9 +144,7 @@ There are a few scripts included with the container:
- **clean.js** This script removes all Calls that are over 30 days old
- **totals.js** Lists different system stats
#### Compact a collection
### Compact a collection
When you run clean.js it doesn't actually remove the files off storge. You can use this command from the mongo cli tool.
First, launch the tool: `mongo`
@@ -149,10 +154,48 @@ And then the compact command on the **Calls** collection:
```
db.runCommand({compact:'calls'})
```
This blocks all calls to the DB, so the site will not work while this is being run.
This blocks all calls to the DB
### Add an Index
Adding an index will make it quicker to search calls by date, talkgroup and whether there are stars.
First, launch the tool: `mongo`
Then switch to the scanner db: `use scanner`
And then add an index:
```
db.calls.createIndex( {shortName: 1, time: -1, star: -1, talkgroupNum: 1})
```
### Upgrading MongoDB
It is a huge pain to upgrade MongoDB in place. It turns out to be easier to dump backup of the database, wipe everything out and then restore into a new database for the latest version of Mongo.
Rough Playbook (use common sense, I may not have this exact):
- get into the shell of the mongo container
- `mongodump --db scanner —out /data/db/backup`
- exit contianer and go back to host machine
- `cd data/db`
- `rm *` erase everything... but not the sub-directories because that is where the backup is
- upgrade to the latest version of mongo
- build and launch the mongo container, which will create an empty DB
- get into the shell of the mongo container
- `mongorestore --db scanner --drop /data/db/backup/`
## Setting up Logging
I have had good luck with Loggly. Their free tier provides enough capabilities for most small sites.
The Doocker Logging Driver works well and is easy to install:
https://documentation.solarwinds.com/en/Success_Center/loggly/Content/admin/docker-logging-driver.htm
### Move a DB
## Move a site to a new server
### Setup aws credentials
Here is the general list of things to do:
- Copy over ~/.aws
- Copy over ~/.secrets
- Do a mongodump on old machine
- Scp the mongo backup to the new machine
- Launch the MongoDB container on the new machine
- Do a mongorestore
- Launch all the conatiners
- Change the Floating IP to point to the new machine