-
-
Notifications
You must be signed in to change notification settings - Fork 4
DevOps
En Rong edited this page Nov 19, 2022
·
3 revisions
We are currently hosting the backend on AWS.
- Connect to the server (get the connection details from En Rong)
- Pull the latest backend build on the
dist-dev
(dev
build) ordist
(main
build) branch after CI has completed- E.g.
git fetch origin dist-dev
followed bygit checkout origin/dist-dev
- Use
git log
to check that you are on the correct branch head
- E.g.
- Run
yarn reload:stg
oryarn reload:prod
to redeploy the main backend- WARNING: new migration files are automatically run
- Run
reload:stg:cronjob
orreload:prod:cronjob
to redeploy the cronjob microservice
-
pm2 monit
to check the status of each deployed instance -
pm2 list
for a quick list overview of all deployed instances -
pm2 logs
to see the latest logs
- Connect to the server
- Setup the repo
- Clone the repo: E.g.
git clone <repo-url>
- Fetch the latest dev build: E.g.
git fetch origin dist-dev
(ordist
branch for themain
build) - Checkout the build branch: E.g.
git checkout origin/dist-dev
- Clone the repo: E.g.
- Setup the environment variables
- Create a new env file in the root of the repo directory
-
.env.staging
for staging -
.env.production
for production
-
- Create a new env file in the root of the repo directory
- Run
yarn deploy:stg <num-instances>
oryarn deploy:prod <num-instances>
to deploy the main backend with the specified number of instances behind a round robin load balancer- This will create the database if it does not yet exist and run the database migrations
- Run
yarn seed:stg
oryarn seed:prod
to run the database seeds in the respective environments - Run
yarn deploy:stg:cronjob 1
oryarn deploy:prod:cronjob 1
to deploy a single instance of the cronjob microservice
-
Write a CI/CD pipeline to automatically build and deploy the backend without having to ssh manually
- We can dockerize the application and follow the GitOps model with IaC
- Use image tagging in ECR to deploy to prod instances
- Shift to K8s
-
Logging pipeline
- Shift to a proper logging pipeline such as the ELK stack
-
Metrics and Analytics
- Track usage patterns and behaviours
- Aggregate them in dashboards for analysis
- Explore SaaS options like Mixpanel
-
Trace Data (low priority)
- Instrument application telemetry to track and trace control flow throughout our backend when an API endpoint is hit
- Trace spans are useful for analysing bugs in prod, and for optimizing the backend in the future
- E.g. OpenTelemetry
- Overkill at the moment as we are still small, but a possible area we can look into as the application grows in complexity
-
Application Monitoring (low priority)
- Alerts and monitoring on our infra
- E.g. Prometheus
- Overkill at the moment as we are still small, but a possible area we can look into as the application grows in complexity and user load grows