Local .env Configuration File
Now that we have the development environment hot, let's make sure our local configuration file .env
is set up correctly.
As explained before, we need to copy the default configuration file provided in the Git project into it. In the host shell:
cd C:/docker-vol/demo-gql-mongo
or
cd ~/docker-vol/demo-gql-mongo
then
cp .default.env .env
You can also use Copy functionality of Explorer in your local VSC IDE.
Unless you use a different MongoDB setup from the one described in the previous chapter, you would not need to change anything in the .env
file, let's just review it:
PORT=80
- indicates that the HTTP server in NodeJS will run on port 80. As you recall, container port 80 in thedocker run
command is mapped to port8080
of the hostDB_URI=mongodb://172.17.0.1:27017
- sets the MongoDB URI for the NodeJS application. From inside the NodeJS container, the path to MongoDB is via port27017
of the docker host.
In the "Docker Networking …" lesson you learned that172.17.0.1
is the IP of the host on the default Docker network that both of our containers run in. How do we know the containers are running in the default Docker network? First, because we haven't configured any additional Docker network on our host. Second, in thedocker inspect node-dev
output,"NetworkSettings"
, you can see the details, e.g.,"Gateway": "172.17.0.1"
. Now, on the MongoDB container side, local port27017
is mapped to port27017
on the host. So, host's port27017
in effect is the port that our dev MongoDB is listening on.
This is the classic way of orchestrating multiple services and servers running on a Docker host. Simple and powerful.
As a disclaimer, the database is not secured, so don't put any sensitive info in it and don't expose your host's port27017
to the open Internet. Even if you configure this DB with a password, you'll end up saving it in the open in the.env
file. So, don't bother, just don't keep anything confidential in your dev DB. As we discussed in the "Project Custom Configuration File" lesson, the Production environment is well protected by virtue of running your Docker Production containers and services inside a secured orchestration framework. In dev, it's all on your laptop - with the intent that you can develop efficiently. Unless you know how to absolutely secure access to your laptop - don't copy your production database down into it to seed the development. Not a good practice.DB_NAME=web_dev
- defines the name of the MongoDB database. The database will be automatically created if it doesn't exist - the first time we hit the DB server loading data into it
Next, on to the install
step in our project lifecycle!