Add docker file, docker-compose, and env changes

[theref]

This is an attempt to simplify the dev process for newcomers. To test, follow the instructions in the README regarding updating package.json and .env, then: docker-compose run --build. First build will take a while, but after that should be very quick.

Example logs can be seen here https://app.warp.dev/block/qnf8YCpPJIuxvSQRwnRJ1i

[github-actions]

Preview uploaded to https://preview.dashboard.test.threshold.network/docker/index.html.

[beaurancourt]

Hey @theref, thanks for opening this up!

Can you include in the PR description some context (what the change is and why you're making it), testing procedures, and a screenshot of docker running beautifully in the console?

It doesn't have to be too in-depth, but it's nice for our future selves to have the record :D

[github-actions]

Preview uploaded to https://preview.dashboard.test.threshold.network/docker/index.html.

[manumonti]

I had some troubles running the docker-compose command. Maybe these changes can help to make it more clear.

[github-actions]

Preview uploaded to https://preview.dashboard.test.threshold.network/docker/index.html.

[manumonti]

LGTM 🙌

[derekpierre]

@theref , looks good.

Couple questions:

1. Does it make sense to tuck the docker-compose.yml and Dockerfile.dev files into a docker folder or some other named folder instead of having them directly in the base directory? If so, may need to update paths used in config files.
2. Is it helpful to sneak docker-compose run --build or docker-compose run -f ./docker/docker-compose.yml run build (if you move the files from 1. above) into a yarn script command in the package.json, so then the user runs yarn docker-run or something like that? This is meant to be phrased as a question, not a suggestion - I'm less familiar with yarn best practices.

[theref]

This PR is no longer ready as the build is no longer successful. There seems to have been a lot of changes in upstream packages that are causing issues here. I am attempting to narrow them down. As I make discoveries I will continue to post them here.

EDIT - fixed

[piotr-roslaniec]

Adding node_modules to .dockerignore instead would also have an additional benefit of a smaller build context. (Even thought we don't COPY it, docker still has to index it before starting a build process).

[piotr-roslaniec]

We've already set these up in Dockerfile.dev. Any reason why we set these in two different places?

[piotr-roslaniec]

Could we document the motivation for using this Node.js flag?

[piotr-roslaniec]

Node.js 14 has already reached the end-of-life, and Node.js 16 is going to reach EOL shortly.

I suggest using node:16-buster-slim since it looks from the contents of package.json

"@types/node": "^16.9.1",

Suggested change

	FROM node:14-buster-slim
	FROM node:16-buster-slim

We can address transition from 16 to 18 (the next LTS version) in another PR.

[piotr-roslaniec]

You may want to consider using multistage builds to slightly speed up the building process. Not sure if this is helpful here, just dropping a hint:

# The first stage is for installing dependencies
FROM node:14-buster-slim  AS build-stage

WORKDIR /app

RUN apt-get update && apt-get install -y python3 make g++ git openssh-client ca-certificates && \
    git config --global url."https://".insteadOf git:// && \
    rm -rf /var/lib/apt/lists/* && \
    apt-get clean

ENV PYTHON=/usr/bin/python3
ENV NODE_OPTIONS=--max_old_space_size=3072

COPY package*.json yarn.lock ./

RUN yarn install

# Start a new stag
FROM node:14-buster-slim

WORKDIR /app

# Copy needed files from the previous stage
# This works like a cache, effectively
COPY --from=build-stage /app ./

# Expose port 3000
EXPOSE 3000

[theref]

replaced by #625