Define official Docker images

[jeliasson]

This issue seeks to define what official RedwoodJS Docker images should be supported and maintained by the community.

Production

Discussion on Dockerfiles and it's implementation

Suggestions

1. One image

• yarn rw serve - example standal-cli-both

2. Two images

• api - example standal-ce-nginx, jeliasson-nginx
• web - example standal-ce-nginx, jeliasson-nginx

2. [Adding more as suggestions come in]

Todo

Overall

• Define official image(s) path
• Review and feedback from community and hosting providers
• If possible, use yarn rw-server api over yarn rw serve api

Build tracking

Workflow	Build status
standal-ce-nginx
standal-cli-both
jeliasson-nginx

[realStandal]

Just to confirm, these would be images which an application would extend FROM in its Dockerfile?

Just a thought, what if we support an eject command which gives the application the "bare" Dockerfile, should they require it? (I haven't done too much to modify existing images, so I'm not sure if that's an acceptable route and we don't need eject - feel free to educate). Some way to extend the base image or redefine it, depending on the needs of an app. Perhaps this covers the "special Dockerfiles"?

I'm tempted to suggest docker-compose.yml be a separate feature to what we're discussing here. What we're discussing here feels like "the setup and steps to build (a basic?) RW application into an image". Compose, I think, could be considered a deployment target to run that image as a container, alongside K8s, KNative, EKS, ...

[realStandal]

There are two things that kinda "stump" me:

• Are we going to choose Nginx and say "this is Redwood's official way of containerizing your web-side"
  • Using Nginx, Caddy, or even http-server is going to dramatically reduce the final image size, but do we want to write off a choice as "Redwood's opinion, deal with it"?
• Are we going to say it's web-nginx, and allow for other builds (web-caddy, web-rw-server, ...)

I think the API makes the decision for us. Using rw-server api is probably going to be the most viable ENTRYPOINT.

[jeliasson]

Just to confirm, these would be images which an application would extend FROM in its Dockerfile?

In the perfect world, yes. e.g.

FROM redwoodjs/web:0.49.1

COPY web .
COPY yarn.lock .
...

I'm not entirely sure how or if this could be done (including boilerplate and building) but it would definitely be awesome if possible and without to much complexity.

Just a thought, what if we support an eject command which gives the application the "bare" Dockerfile, should they require it?

I'm not entirely sure what you mean by eject. Care to elaborate? 🙂

Some way to extend the base image or redefine it, depending on the needs of an app. Perhaps this covers the "special Dockerfiles"?

When it comes to "special Dockerfiles", it would be neat with a yarn rw setup docker [...] command that list a few variations that could be generated - maybe show official supported and maintained, and community made (which would allow show-casing different web servers). There is not one to rule them all. 🧙🏻‍♂️

I'm tempted to suggest docker-compose.yml be a separate feature to what we're discussing here. What we're discussing here feels like "the setup and steps to build (a basic?) RW application into an image". Compose, I think, could be considered a deployment target to run that image as a container, alongside K8s, KNative, EKS, ...

I agree. I often see docker-compose as part of the development cycle and sometimes forget that it's also a part of some production deployments, and definitely a valid approach. I'll remove it from this Issue and put it in another one. 💖

There are two things that kinda "stump" me:

Really good points! I'm not sure. Maybe the officially supported one is basically yarn rw serve web (follow the framework) whereas the "special Dockerfiles" would hold the more alternatives? Hopefully we can get some input from the community 😊

I think the API makes the decision for us. Using rw-server api is probably going to be the most viable ENTRYPOINT.

+1

[pi0neerpat]

Im also a fan of yarn rw setup docker [...] to let people choose their own path. I don't think its high priority though, since this repo is a good enough resource, and people will likely need customization until we find the best "out-of-the-box" solution

Having a base layer redwood image to start with would be great! However there are two issues which need to be addressed:

• You have to install everything anyways, unless there is a way to cherry-pick only new dependencies
• Mismatch redwood versions between the base image and the app can cause problems. It creates another item which devs must keep track of, rather than just building an image from scratch. Tangentially related example: I just had an issue with redwood version mismatch in a global install vs the app Cannot find module 'terminal-link' redwood#5584

[jeliasson]

[...] I don't think its high priority though, since this repo is a good enough resource, and people will likely need customization until we find the best "out-of-the-box" solution

Agreed

[...] You have to install everything anyways, unless there is a way to cherry-pick only new dependencies

I guess there could be some build time to save, if the base image would only hold some dependencies to copy in, but ultimately might just be a headache to maintain. I'll see if I can throw together something.

[...] Tangentially related example: I just had an issue with redwood version mismatch in a global install vs the app.

Yeah, thanks for creating that issue. While I don't mind switching over to canary from time to time, I ended up doing this to globally install with the appropriate version.

[...]

# Install jq
RUN apk update && apk add jq && rm -rf /var/cache/apk/*

# Get Redwood version from api/package.json and it's @redwoodjs/api dependency
# Also, let's remove potential `^` character from the version.
RUN RW_VERSION=$(jq -r '.dependencies["@redwoodjs/api"]' api/package.json | sed 's/\^//')

# Install dependencies
RUN yarn install

# Install additional dependencies
RUN yarn add @redwoodjs/api-server@${RW_VERSION} @redwoodjs/internal@${RW_VERSION}

[...]

Edit
To skip the jq dependency, here is a not-so-pretty way of doing it instead.

RUN RW_VERSION=$(cat package.json | grep "@redwoodjs/api" | cut -d ":" -f2 | sed 's/[^a-zA-Z0-9\.\-]*//g')

[jeliasson]

Closing issue in preparation for archiving.