Launching Dev Environment on Linux

Launching Dev Environment Docker Containers on Linux

Please read the Launching on Windows section if your desktop OS is not Linux

MongoDB

Make sure that port 27017 on your dev box is not already used by another local instance of MongoDB. You can change the left-side (host side) port number in the docker run command below to use a different port instead. If the port you are trying to use is already engaged - you'll get an error message when launching the container. If you do, remove the container (docker rm mongo), troubleshoot the port problem and launch the container again.

In the terminal shell, from any folder (applies to all commands in this section), run

docker run -d --name mongo -p 27017:27017 -v mongodata:/data/db --restart unless-stopped mongo:3.6

The command options used are:

• -d - run the container in the daemon mode, meaning that it keeps on running for as long as we need it
• --name mongo - the container name we can refer to it by in other docker commands
• -p 27017:27017 - host port 27017 is mapped to the container port where MongoDB is listening on (27017, as per mongo official image docs)
• -v mongodata:/data/db - map mongodata docker volume on the host to the /data/db folder inside the container. Docker volume is automatically created if it doesn't exist. /data/db is the documented folder where containers launched from the official mongo image keep their database files.
  Note that the container's startup process is designed to reuse existing database files in the folder. This is a typical feature that allows seamlessly restarting or relaunching containers over the same database content. If the folder is empty, the database is initialized with the documented defaults. The downside of reusing is that if the files are corrupted or wrong, the container may fail. In that case, cleanup or removal of the docker volume resolve the issue
• --restart unless-stopped - restart the container if it is not running, unless it was explicitly stopped via the docker stop command. We want the running container auto-restarted on system's reboot or docker daemon restart
• mongo:3.6 - the name of the image for the container: official MongoDB version 3.6 Docker image

Note that we do not provide any command override to the container that would go after the image name at the end of the docker run statement. In this case, the default startup process defined in the image is launched.

If you haven't used mongo:3.6 image on the box before, docker will pull it from dockerhub. You'll see this message

Unable to find image 'mongo:3.6' locally
3.6: Pulling from library/mongo

Once the container is started, Docker prints the long container ID and returns back to the shell prompt. The absence of any other messages would indicate that the container was likely launched successfully.

At this point, docker ps --all should show the mongo container running. CREATED and STATUS should be off by a second or so. Repeat docker ps a few times to ensure that the container keeps running - the STATUS seconds count should steadily grow as you're retrying docker ps. What you're looking for is to make sure that the container is not restarting due to some errors. With --restart unless-stopped set, if the process inside the container errors out after the container initially starts up - Docker daemon will keep restarting it. Note that if the port is occupied or Docker encounters some other configuration issues - the container won't start at all, and you'd get a message in the console. Restarts don't generate console messages, so you should monitor docker ps and then check the container's log: docker logs mongo. Ignore the MongoDB performance warnings in the log - this is just a dev db. The log is your source for troubleshooting if the container keeps restarting.

docker logs mongo outputs the log (ignore the warnings in the log - this is just a dev db). Can also be used for troubleshooting if the container exits.

docker volume ls outputs a bunch of lines, including one with mongodata - the name we used on the left side of the -v parameter.

docker volume inspect mongodata shows the folder where docker created the drive, e.g., "Mountpoint": "/var/lib/docker/volumes/mongodata/_data"

docker inspect mongo shows details of the running container.

On failures or when you want to clear everything out, docker stop mongo and docker rm mongo remove the container. You can view the log of a stopped container, but the log is gone once the container is removed.

The shared volume will be automatically reused when you relaunch the docker run command for the container. The data on the volume is supposed to be preserved when you stop or remove the container. You can remove the volume via docker volume rm mongodata if you want to start fresh or wrap up.

NodeJS

Let's assume you cloned the demo project repository into ~/docker-vol/demo-gql-mongo on your dev box. Then your container launch command should be as follows:

docker run -d --name node-dev -p 8080:80 -v ~/docker-vol/demo-gql-mongo:/myapp --restart unless-stopped node:8 tail -f /dev/null

We're exposing container's port 80 on host port 8080.

Note that -v ~/docker-vol/demo-gql-mongo:/myapp contains a path on the left (host) side - this indicates sharing a specific folder vs. using a Docker volume as we did for the mongo container. Alternatively, a Docker volume can be created ahead of time, linked explicitly to the folder we need to share.

tail -f /dev/null is a dummy daemon command that puts the container into an infinite waiting loop. Run docker stats command to see the resource utilization by the containers. node-dev takes up a tiny memory slice and zero CPU when running in this "dummy" daemon mode.

Now, let's get into node-dev shell. From the host's terminal shell CLI, run:

docker exec -it node-dev bash

A command prompt like root@<container ID>:/# will indicate that we're inside the container's shell. Note, we are the root in the container. If you're curious what Operating System you're working in, run cat /etc/*-release.

Run

cd /myapp
ls -la

/myapp is the folder inside the container that is mapped to the host's folder with the demo project files, per -v ~/docker-vol/demo-gql-mongo:/myapp. ls -la should list the project files and directories. Note the user and group that node-dev sees them owned by. The ownership UID/GID was set on the host when you cloned the project locally, so what you see in the container are the container-OS names corresponding to those IDs. E.g., if your UID on the host is 1000, it corresponds to the node user in the container. The rule on Unix - everything goes by the ID. Why they even bother assigning names? Docker perfectly illustrates what confusion the names cause.

You don't want to be creating any important files in the project dir from the container as they'd become owned by root. You certainly can launch this node-dev container under the UID matching the one you use on the host, but it's out of scope for this course. If you are interested to see how it can be done - check out the EXLskills Services Devstack.

Along the same lines, we build our own image from node:8, we can set /myapp as the default entry folder and save ourselves effort switching to it every time we re-enter the shell. A homework for you.

exit ends your terminal bash session and puts you back into the host's shell.

What is -it in the docker exec (may also be seen in docker run)? One answer can be that -it means that we're using the IT Professional mode. In practical terms, -it is the opposite of the -d daemon mode of the container: you get both -i input open and -t for tty, so you can use the container's terminal. You can either launch a container in the -it mode and start bash form the get go, or you can exec bash in the -it mode on a container launched in the -d mode. Note that some Unix containers are built from images that do not have bash enabled, so you'd need to try other shells.


Now that we have the dev containers running, we are finally ready for the action!