Start postgres docker: docker-compose up -d
Stop postgres docker: docker-compose down
Reset db (unmigrate => migrate => seed): npm run reset-db
Migrate tables: npm run migrate
Rollback tables: npm run unmigrate
Seed NDI table: npm run seed
Run test: npm run test
Start API: npm run start
# Clone the project by running git clone.
$ git clone <REPO_LINK>
# Install the node dependencies by running
$ npm install
# Create a .env file based on .env.example
$ cp .env.example .env
# Start Postgres and Adminer by running
$ docker-compose up -d
# Start the API on localhost:3001 (if nothing changed in .env.example)
$ npm start
The environment component name follows this format: <ACCOUNT_ALIAS>@<COMPONENT_NAME>
.
All local repository changes are pushed to new branches in the GitHub remote repository. These changes are reviewed and merged into the 'master' branch.
A separate CodePipeline project is created for each production environment. The pipeline consists of 2 stages:
master
.master
branch. (Troubleshooting: Manually trigger a release in CodePipeline)Skip the build stage. It's not needed.
In Elastic Beanstalk (EB) a different environment is created for each game instance. In each environment, the node application is running inside a docker container so an existing Dockerfile inside the source code is necessary for EB. The docker image is created using the Dockerfile in the root. Once the deployment is compleated, the API will be live.
To create a new Elastic Beanstalk environment follow these steps:
production
, development
. (DEVNOTE: for local development it can be test
. If the given value is test
the server will reset the Postgres Database on each restart.)A Postgres Database is created to store the data for each environment. When creating a DB for an Elastic Beanstalk environment, by default the database created will get a name like this awseb-e-<Environment ID>-...
. The default name of the RDS database is ebdb.
Database settings:
This DB is only available for the EC2 instance running inside the EB environment. In order to connect to the DB from a different client, port forwarding must be configured. In order to create an ssh tunnel and forward the traffic from the DB to locahost run to following commands:
# Create the tunnel using ssh. Please note that you need the private key for this command.
$ ssh -N -L 5432:aa1p6s0h1so0mf9.cp0uibxnlhse.us-east-2.rds.amazonaws.com:5432 ec2-user@3.133.74.121 -i <PRIVATE_KEY>
# Connect to the DB on localhost:5432
$ psql -U cybersim --password -h 127.0.0.1 -p 5432
The application relies on a PostgreSQL database, but the initial data is sourced from an Airtable base. If you wish to customize the data for a new game, including events, locations, actions, and more, you can achieve this by modifying the data within the Airtable base.
Before running a new game with modified data, it is essential to perform a "migration" from Airtable to the PostgreSQL database.
Go to the <host>/migration
page (e.g. (https://cybersim.demcloud.org/migrate)[https://cybersim.demcloud.org/migrate]) and follow the step-by-step guide below to complete the migration process:
Master Password
MIGRATION_PASSWORD
environment variable in the backend application to access the master password needed for the migration process.Access Airtable
Navigate to Developer Hub
Generate a Personal Access Token
Retrieve Airtable Base ID
Initiate the Migration
By following these steps, you can successfully migrate data from Airtable to the PostgreSQL database, ensuring that your new game incorporates the customized data you have prepared.
In the game, mitigations are organized into groups according to their category. You can customize the order of these mitigations using the following steps:
Currently, the game exclusively accommodates exactly two locations. You have the flexibility to name these locations as you desire within the "locations" table.
:warning: Please exercise caution and refrain from modifying the "location_code" fields. Altering the default values ('hq', 'local') here can disrupt the application's functionality! :warning:
Changing the names of the locations in this section will solely impact how they are displayed in the header menu, tabs, and action titles. Role names (e.g., "HQ IT Team") remain distinct and should be configured separately within the ROLES table.
You have the ability to modify the terminology associated with "polls" in this section. For instance, you can replace "poll" or "budget" with alternative words. To introduce a new synonym, simply edit the synonym column as needed.