setup local docker compose mongo replicaset (#773)

* setup local mongo replicaset

* update datapuller docs

docker-compose.yml

@@ -3,18 +3,6 @@ networks:
   bt:
     name: bt
 services:
-  datapuller:
-    build:
-      context: .
-      target: datapuller-dev
-    depends_on:
-      - mongodb
-    networks:
-      - bt
-    restart: no
-    volumes:
-      - ./apps/datapuller/src:/datapuller/apps/datapuller/src
-      - ./.env:/datapuller/apps/datapuller/.env
   backend:
     build:
       context: .
@@ -40,14 +28,22 @@ services:
       - ./packages/theme/src:/frontend/packages/theme/src
       - ./apps/frontend/public:/frontend/apps/frontend/public
   mongodb:
-    image: mongo:5
+    image: mongo:7.0.5
+    command: ["--replSet", "rs0", "--bind_ip_all", "--port", "27017"]
     networks:
       - bt
     ports:
       - 27017:27017
-    restart: always
+    healthcheck:
+      test: echo "try { rs.status() } catch (err) { rs.initiate({_id:'rs0',members:[{_id:0,host:'mongodb:27017',priority:1}]}) }" | mongosh --port 27017 --quiet
+      interval: 5s
+      timeout: 30s
+      start_period: 0s
+      start_interval: 1s
+      retries: 30
     volumes:
-      - ./db:/data/db
+      - ./data/mongodb/db:/data/db
+      - ./data/mongodb/configdb:/data/configdb
   nginx:
     depends_on:
       - backend
@@ -61,9 +57,9 @@ services:
     volumes:
       - ./nginx.conf:/etc/nginx/conf.d/default.conf
   redis:
-    image: redis:6
+    image: redis:7.2.4
     ports:
       - 6379:6379
-    restart: always
     networks:
       - bt
+    restart: always

docs/src/core/datapuller/local-remote-development.md

@@ -2,21 +2,7 @@
 
 ## Local Development
 
-The nature of the `datapuller` separates it from the backend and frontend services. Thus, when testing locally, it is quicker and easier to build and run the `datapuller` separately from the backend/frontend stack.
-
-The `datapuller` inserts data into the Mongo database. Thus, to test locally, a Mongo instance must first be running locally and be accessible to the `datapuller` container. Make sure the `MONGO_URI` value in `.env` is correct.
-```sh
-# Run a Mongo instance. The name flag changes the MONGO_URI.
-# Here, it would be mongodb://mongodb:27017/bt?replicaSet=rs0.
-docker run --name mongodb --network bt --detach "mongo:7.0.5" \
-    mongod --replSet rs0 --bind_ip_all
-
-# Initiate the replica set.
-docker exec mongodb mongosh --eval \
-    "rs.initiate({_id: 'rs0', members: [{_id: 0, host: 'mongodb:27017'}]})"
-```
-
-To run a specific puller, the datapuller must first be built, then the specific puller must be passed as a command[^1]. After modifying any code, the container must be re-built for changes to be reflected.
+The `datapuller` inserts data into the Mongo database. Thus, to test locally, a Mongo instance must first be running locally and be accessible to the `datapuller` container. To run a specific puller, the `datapuller` must first be built, then the specific puller must be passed as a command[^1]. After modifying any code, the container *must* be re-built for changes to be reflected.
 
 ```sh
 # ./berkeleytime
@@ -31,6 +17,19 @@ docker run --volume ./.env:/datapuller/apps/datapuller/.env --network bt \
 
 The valid pullers are `courses`, `classes`, `sections`, `grades`, `enrollments`, and `main`.
 
+> [!TIP]
+>  If you do not need any other services (backend, frontend), then you can run a Mongo instance independently from the `docker-compose.yml` configuration. However, the below commands do not allow data persistence.
+> ```sh
+> # Run a Mongo instance. The name flag changes the MONGO_URI.
+> # Here, it would be mongodb://mongodb:27017/bt?replicaSet=rs0.
+> docker run --name mongodb --network bt --detach "mongo:7.0.5" \
+>     mongod --replSet rs0 --bind_ip_all
+>
+> # Initiate the replica set.
+> docker exec mongodb mongosh --eval \
+>     "rs.initiate({_id: 'rs0', members: [{_id: 0, host: 'mongodb:27017'}]})"
+> ```
+
 [^1]: Here, I reference the Docker world's terminology. In the Docker world, the `ENTRYPOINT` instruction denotes the the executable that cannot be overriden after the image is built. The `CMD` instruction denotes an argument that can be overriden after the image is built. In the Kubernetes world, the `ENTRYPOINT` analogous is the `command` field, while the `CMD` equivalent is the `args` field.
 
 ## Remote Development