DEV Community

keinzeit
keinzeit

Posted on

working with docker, part 2

need to unpack this line of code:

docker run -dp 3000:3000 \
     -w /app -v "$(pwd):/app" \
     node:18-alpine \
     sh -c "yarn install && yarn run dev"
Enter fullscreen mode Exit fullscreen mode

the docs explain it as such:

  1. -dp 3000:3000 - same as before. Run in detached (background) mode and create a port mapping
  2. -w /app - sets the “working directory” or the current directory that the command will run from
  3. -v "$(pwd):/app" - bind mount the current directory from the host into the /app directory in the container
  4. node:18-alpine - the image to use. Note that this is the base image for our app from the Dockerfile
  5. sh -c "yarn install && yarn run dev" - the command. We’re starting a shell using sh (alpine doesn’t have bash) and running yarn install to install all dependencies and then running yarn run dev. If we look in the package.json, we’ll see that the dev script is starting nodemon.

ok, so what i understand:

  1. point (1): detached mode, port mapping, that makes sense
  2. point (3): we are working with bind mounts, which exposes a directory on the host to the container. here we expose the source code to the container
  3. point (4): it's unclear to me where the particular node name "18-alpine" comes from, but i understand the aspect of specifying the image to use for starting this container

ok, so what i don't understand:

  1. point (2): what command is being run? the yarn commands in point (5)? also, this looks like a command being run in the container.
  2. point (5): i don't know what yarn does. seems like it can run scripts though. dev is a script defined in package.json. i guess somehow, yarn knows to look in package.json, look in the scripts section, and run the dev line.
{
  ...
  "scripts": {
    "prettify": "prettier -l --write \"**/*.js\"",
    "test": "jest",
    "dev": "nodemon src/index.js"
  },
  ...
}
Enter fullscreen mode Exit fullscreen mode

i guess the last thing i need to understand is what nodemon does, and also what's contained in src/index.js. i'm pretty sure this is related to how the containerized app can update itself automatically when we make a change to the source code.

asked chatgpt: nodemon is a utility for monitoring any changes to source code and restarting the server automatically. basically, it's what allows changes to the source code to be reflected in the web app upon saving.

taking a look at src/index.js, it seems to have instructions for watching the port through which the app is running (port 3000, same as the ports used by our container). i'm not sure if that javascript includes instructions on restarting the app - i think it stops at defining how to stop the process, and nodemon itself handles the restart?

asked chatgpt: apparently, index.js is supposed to be the entry point to your application. so, if i were to run my application without nodemon, i'd still be invoking index.js.

from the nodemon github:

nodemon wraps your application, so you can pass all the arguments you would normally pass to your app:

> nodemon [your node app]
Enter fullscreen mode Exit fullscreen mode

which supports the information provided by chatgpt!

finally, why did we use yarn to run this nodemon line of code?

from chatgpt:
The yarn run command is used to execute scripts defined in your package.json file. This allows you to define a set of scripts that can be run with a single command, without having to type out the full command each time. ahh!!

so summary of nodemon src/index.js

  • nodemon is the utility that lets our container restart the app upon changes to source code
  • src/index.js is the entry point to our app: you'd run this file to run the app
  • yarn is a package manager (like npm), but it can also be used to easily run predefined scripts

Just an aside: it dawned on me that we want to be able to unit test using Docker. obviously, local machine unit testing will still happen. but unit testing on a container just makes sense. like, why wouldn't you do it if you could? especially since it can be automated on a commit to a bug fix/ feature implementation branch. the link below is for java specifically, but i'm sure we can find another article that's applicable to python. and i'm sure there's useful information to be gleaned from it as well
https://docs.docker.com/language/java/run-tests/

Top comments (0)