v3, correction commit

README.md

@@ -1,8 +1,13 @@
-# DeepPhe Stream Multi-Container Stack
+# DeepPhe Stream Multi-Container Stack - release branch
+
+## Changes needed to make a release
+
+- 1: Place the source code zip file, for instance `v0.3.0-cr-release.zip`, to the directory `dphe-stream`. And this zip file will be used to build the `dphe-stream` docker image. 
+- 2: Edit the `dphe-stream/Dockerfile` and specify to use the target release version, for instance `0.3.0`. 
 
 ## Overview of components and architecture
 
-This multi-container docker stack consists of the following 2 containers as shown in the diagram: 
+This multi-container docker stack consists of the following 2 contaienrs as shown in the diagram: 
 
 - 1 : `dphe-stream-nginx`
 - 2 : `dphe-stream`
@@ -13,6 +18,7 @@ This multi-container docker stack consists of the following 2 containers as show
 - As a requirement, we do not persist information anywhere except temporarily within the jvm of the  `dphe-stream` container. We only use an embedded instance of neo4j for the system to read the static ontology graph.
 - The REST API in the `dphe-stream` container is just a thin wrapper that exposes the endpoints to accept requests of document and patient summarizations, and it is the backend NLP pipeline that does the heavy lifting as well as returns the extracted information.
 
+
 ## Overview of tools
 
 - [Docker Engine](https://docs.docker.com/install/)
@@ -30,32 +36,15 @@ If you're using Linux and you don't want to preface the docker command with sudo
 sudo usermod -aG docker $USER
 ````
 
-The log out and log back in so that your group membership is re-evaluated. If testing on a virtual machine, it may be necessary to restart the virtual machine for changes to take effect.
+Then log out and log back in so that your group membership is re-evaluated. If testing on a virtual machine, it may be necessary to restart the virtual machine for changes to take effect.
 
 Note: the following instructions with docker commands are based on managing Docker as a non-root user.
 
 These permissions do not appear to be a concern on OS X and Windows. 
 
 ## Build docker images
 
-### Dedicated private SSH key
-
-This is a deployment SSH key generated and used for pulling the private github repos during creating the `deepphe/dphe-stream-base` image. The image build will fail without this key. 
-
-### Build base image
-
-First you'll need to git clone this repository and build the `deepphe/dphe-stream-base` base image. You'll need the dedicated private key attached to the github machine user from the host machine (E.g., `PATH/deepphe-machine-user-ssh-private-key.txt`) and pass it as a build argument as below:
-
-````
-cd dphe-stream-base
-docker build --no-cache --build-arg SSH_PRIVATE_KEY="$(cat PATH/deepphe-machine-user-ssh-private-key.txt)" -t deepphe/dphe-stream-base:latest .
-````
-
-Note: replace the `PATH` with the actual directory path where this private SSH key can be found.
-
-We are using Docker's multi-stage build and the private SSH key is only used by the intermediate image and won't leave traces inside of the final base image.
-
-### Specify auth token
+### Specify auth token (optional)
 
 Before starting building the child images, specify the auth token in `dphe-stream/deepphe.properties`. This auth token will be used later when interacting with the REST API calls via the standard HTTP request `Authorization` header with the Bearer scheme:
 
@@ -72,11 +61,10 @@ A default token is provided in the `dphe-stream/deepphe.propertiers` file. For g
 Next go back to the project root directory where you can find the `docker-compose.yml`:
 
 ````
-cd ..
 docker-compose build --no-cache
 ````
 
-### Vulnerability scanning for local images
+### Vulnerability scanning for local images (optional)
 
 Vulnerability scanning for Docker local images allows us to review the security state of the container images and take actions to fix issues identified during the scan, resulting in more secure deployments. The `scan` command is available by default in Docker version 20.10.x and newer.
 
@@ -88,8 +76,8 @@ docker scan --login
 Once logged in, you can run the scans as follows:
 
 ```
-docker scan --dependency-tree --file ./dphe-stream/Dockerfile dphe-stream:0.4.0
-docker scan --dependency-tree --file ./dphe-stream-nginx/Dockerfile dphe-stream-nginx:0.4.0
+docker scan --dependency-tree --file ./dphe-stream/Dockerfile dphe-stream:0.2.0-cr
+docker scan --dependency-tree --file ./dphe-stream-nginx/Dockerfile dphe-stream-nginx:0.2.0-cr
 ```
 
 ## Start up services
@@ -110,10 +98,11 @@ In security practice, the processes within a running container should not run as
 ````
 docker-compose up -d
 ````
+This command spins up all the services (in the background as detached mode and leaves them running) defiened in the `docker-compose.yml` and aggregates the output of each container.
 
-This command spins up all the services (in the background as detached mode and leaves them running) defiened in the `docker-compose.yml` and aggregates the output of each container. Make sure the port `8080` and `8181` are not already allocated, otherwise the containers would fail to start.
+Note: Make sure the port `8080` and `8181` are not already allocated, otherwise the containers would fail to start.
 
-Note: the initialization of containers takes some time, you can use the following command in another terminal window to monitor the progress:
+Note: Container initialization takes some time, you can use the following command in another terminal window to monitor the progress:
 
 ````
 docker-compose logs -f --tail="all" 
@@ -139,7 +128,7 @@ You will have the following API base URL for the REST API container:
 
 - `dphe-stream`: `http://localhost:8080/deepphe`
 
-Please remember that you'll need to send over the auth token (specified prior the docker build) in the `Authorization` header for each HTTP request:
+Note: You will need to send over the auth token, specified in `dphe-stream/deepphe.properties`, in the `Authorization` header for each HTTP request:
 
 ````
 Authorization: Bearer <token>
@@ -201,7 +190,7 @@ A patient summary can only be created using document information that was cached
 
 ## Manage the contaners
 
-### Shell into the running container
+### Shell into the running container (optional)
 
 Sometimes you may want to shell into a running container to check more details, this can be done by:
 
@@ -233,7 +222,7 @@ This command stops both containers of this project and removes them as well the
 Note: At this time DeepPhe Stream could be run with a single container.  The multi-container stack exists to facilitate addition future workflows that may require additional containers.   
 
 
-## Integration tests
+## Integration tests (optional)
 
 Once the containers are up running, we can execute some integration tests written in Python to verify the pipeline output by submitting some sample reports to the REST API. The tests will be executed against the `dphe-stream-nginx` container, which proxies the requests to the backend REST API service.
 

docker-compose.yml

@@ -5,7 +5,7 @@ services:
     build:
       context: ./dphe-stream
     # Build the image with name and tag
-    image: deepphe/dphe-stream:0.5.0
+    image: dphe-stream:0.3.0-cr
     hostname: dphe-stream
     container_name: dphe-stream
     init: true
@@ -19,14 +19,14 @@ services:
       - "8181:8080"
     volumes:
       # Make log accessible on host
-      - "./dphe-stream/logs:/usr/src/app/dphe-stream-rest/logs"
+      - "./dphe-stream/logs:/usr/src/app/v0.3.0-cr-release/dphe-stream-rest/logs"
     networks:
       - dphe-stream-network
 
   dphe-stream-nginx:
     build: ./dphe-stream-nginx
     # Build the image with name and tag
-    image: deepphe/dphe-stream-nginx:0.5.0
+    image: dphe-stream-nginx:0.3.0-cr
     hostname: dphe-stream-nginx
     container_name: dphe-stream-nginx
     init: true
@@ -55,7 +55,7 @@ services:
       # Mount the integration test
       - "./dphe-stream-nginx/integration-test:/usr/src/app/integration-test"
     # Nginx reverse proxy forwarding requires the upstream service to be running and ready to accept requests
-    # Otherwise we'll get 502 error
+    # Otherweise we'll get 502 error
     # This 'depends_on' will run the containers in sequence, but it has no way of knowing 
     # when the upstream service is actually ready to receive requests
     depends_on: