Docker setup

Background

Using containers to manage the different portions of the application makes it easier for developers to get started and for deploying to different platforms.

Current setup

We have Dockerfile's for each section of the app:

• ui-components Storybook
• Public NextJS app in sites/public
• Partner NextJS app in sites/partners
• Backend NestJS app in backend/core

Due to the fact that we're using Yarn workspaces, any dependencies that are shared are created in the top level directory instead of inside the root of the NextJS app. So in order for the Dockerfile to be able to access files from the top level directory, it must sit in the top level directory. backend/core is standalone enough that it doesn't need to have its Dockerfile in the top level directory.

docker-compose.yml

docker-compose is useful for bringing up and connecting all of these separate Docker containers together into a coherent site running locally.

!! Important Note !!

The docker-compose is set up in such a way that only the development stages of the containers are run. This means that you could have a working docker-compose up but still fail if you attempt to deploy the containers. This would mean that there is likely a problem in the production stage of the Dockerfile and to debug, you should start some portion of the containers with docker-compose up <service1> <service2> and then attempt to build and run the container you're debugging by itself. This will ensure that you're running with the production version. Alternatively, we could create a separate docker-compose.yml to use for testing production builds.

Inside the file are definitions and overrides, such as:

• Addressing the containers by name instead of localhost, e.g. postgres://postgres:5432/bloom for DATABASE_URL.
• Connecting the containers by specifying networks.
• Mounting local volumes into the container for edit/refresh.
• Selecting the appropriate stage of build for the container image.

Recipes

docker-compose

• docker-compose up - starts all containers in the docker-compose.yml file.
• docker-compose up <container> <container> - starts only the services explicitly listed as well as any dependencies of those services.
  • Note: Docker will not show you logs for the dependent containers, only the ones you explicitly list.
• docker-compose up --build -V - rebuild all containers and remove all anonymous volumes (which are how the node_modules/ directories are mounted in the containers).

General docker

• docker network ls - list all the available docker networks.
• docker build --no-cache - build an image and don't use the cache for intermediate steps.
  • Can be useful if you are trying to rebuild the getStaticProps().
• docker images - view all images docker has built
• docker image prune - prune any unused images; useful for freeing up disk space.

Individual containers

• docker build -t my-app . - build an image and tag it with my-app from the current directory's Dockerfile.
• docker build -f Dockerfile.sites-public -t public-standalone . - build the sites/public image from Dockerfile.sites-public and tag it with the label public-standalone.
• docker build --network=host -f Dockerfile.sites-public -t public-standalone . - build the sites/public image but use the localhost networking during build time.
  • Useful if your getStaticProps() are failing because building the container by itself tries to reach localhost, which does not address your workstation's localhost but addresses the docker container itself.
• docker run --env PORT=3000 -p 3000:3000 public-standalone - run the image tagged public-standalone, pass in the environment variable PORT, and map the docker container's port 3000 to localhost:3000.
• docker run -it public-standalone /bin/sh - open an interactive shell inside the docker image tagged public-standalone.
• docker run --env-file=".env" --network=bloom-detroit_backend backend-core-standalone - run the image tagged backend-core-standalone with the environment variables defined in .env and connecting it to the docker network bloom-detroit_backend.
  • This is particularly useful if you're testing a standalone image but want to connect it up to some backend containers that you have running via docker-compose.
• docker run --env-file=".env" --network=host backend-core-standalone - run the image tagged backend-core-standalone but use the host's networking to resolve DNS.
  • This is useful in case you want the container to talk to ports on your local machine that are being used by other services not running in a docker container (and thus are not addressable via docker's internal networking).

UI components

• docker build -f Dockerfile.ui-components -t ui-components .
• docker run -p 40953:40953 ui-components