Dockerize RedwoodJS

Get Help and Help Others
21

Just to clarify, do you mean maintain a official one for the web, e.g. build and publish redwoodjs/web:0.37.0-nginx? If so, we’re defo on the same thought train :slight_smile:

1 Like
22

Yes, with boilerplate settings baked in!

2 Likes
23

3 Likes
24

@ajcwebdev @realStandal @thedavid @doesnotexist
I sent you a collaboration invitation to a redwoodjs-docker repo.

3 Likes
25

I’ve started looking at reviving the gcp deploy with dockerfile (feat(gcp): adding support for GCP project generation by bcoe · Pull Request #1225 · redwoodjs/redwood · GitHub) but haven’t finished getting a working deploy yet. I’ll let you know how it goes. I also wanted to try out the buildpack gcp to compare, but there’s a possibility that could just use the common dockerfile for this as well.

3 Likes
26

Please do! Are you uploading it to their container service, I glanced at the PR it looked more like something with Firebase?

How difficult would it be to include start up time in the size/build-time comparisons?

27

It’s using Firebase for the web hosting but the API is on Cloud Run which I think is what you are referring to by Google’s container service.

1 Like
28

I figured out a Docker Compose setup, will do a full write up soon but in the meantime check out the repo here.

version: "3.9"
services:
  web:
    build:
      context: .
      dockerfile: ./web/Dockerfile
    ports:
      - "8910:8910"
  api:
    build:
      context: .
      dockerfile: ./api/Dockerfile
    ports:
      - "8911:8911"

Edit: Write up can now be found here.

2 Likes
29

Beautiful stuff @ajcwebdev!

I’m a bit behind my contributions, but I’ll catch up soon. Feel free to send a PR to jeliasson/redwoodjs-docker when the write up is done, or ping me and I’ll do it :slight_smile:

30

Will do, I’ll also upgrade the project in the repo to the current version, there’s some slight tweaks we’ll need to make to the current Dockerfiles. Nothing major, I think we just need to remove the babel.config.js files since we no longer have Babel config files in the root of the project.

2 Likes
31

The docker repository has been moved to the RedwoodJS org under redwoodjs/docker.

For those who have a production or experimental Docker setup, please have a look at Community: How does your Dockerfile(s) look like?

1 Like
32

@jeliasson

The explanations @ GitHub - ajcwebdev/redwood-docker-compose: An example RedwoodJS application with Docker Compose make it difficult to dev because of the [necessary for all but dev] apiUrl of “http://localhost:8911/api” in the redwood.toml file

I’m going to try to add a docker.toml file

1 Like
33

Hey @ajoslin103

I had a chat with some people in today’s Redwood Office Hours, and @dthyresson mentioned that you can use environment variables in your redwood.toml. Do you think something like this would work?

redwood.toml

[web]
  apiUrl = "${API_ENDPOINT}"

.env.default

API_ENDPOINT=/.redwood/functions

And then on your production side of things, you’ll set the environment variable API_ENDPOINT that points to the production api?

1 Like
34

That feels more complicated. We already use .toml files (i.e. netlify.tom)

Ii’ve not had time to see what happed when I tried this earlier today

COPY package.json .
COPY docker.toml ./redwood.toml  ## use docker.toml file as our redwood.toml file
COPY yarn.lock .
35

I haven’t used anything else but redwood.toml, as I don’t need to override the behavior in this file depending on environment, so I guess it boils down to personal preference here. :slight_smile:

36

@jeliasson Idea for next step to make Docker integration more “official” — could we setup up a docker/ project over here GitHub - redwoodjs/deploy-target-ci: Testing supported RedwoodJS deploy targets using canary packages

?

37

@jeliasson I’ve PR’d what works for me for (Docker & Dev side-by-side) to redwoodjs/docker

I’ll likely stay in redwoodjs/docker for another round - @thedavid I’ll get here eventually, looks great

2 Likes
38

@thedavid Absolutely, but it’s a bit early for that imo. I suggest we continue to evaluate the implementations and builds in redwoodjs/docker. We currently only have three implementations, and a fouth one incoming from @ajoslin103.

Path forward;

  1. Make sure CI build work ( Minor changes after repository move - this needs your attention, David :slight_smile: )
  2. Get more community examples (@ajcwebdev etc)
  3. Have a discussion on what ‘offical’ image(s) would look like (Define official Docker images)
  4. Figure out how to make those images as slim as possible, and have them pass initial CI.

After that, or somewhere in between, we can bring in various images to build in redwoodjs/deploy-target-ci - and add dev and more complex setups as you mentioned.

Thoughts on this path?

3 Likes
39

Couple things I’d add:

  1. Get a review/feedback from the Fly.io team. They’re wizards with Docker and can help us think through making this robust as well as what doesn’t matter
  2. How can we promote this during Launch Week? We can mark it as Experimental/Preview/Whatever… but we should get the work out.

Well done, everyone. This is just great!!

40

Hey everyone, I’ve been setting up Docker with Yarn 3 - both api and web in single image. Here’s the final image size (391MB):
Screenshot 2022-05-09 at 1.59.22 PM

Project setup:

  • default Redwood’s test-project (yarn run build:test-project <project directory> from RW Framework Repo)
  • upgraded RW to v1.3.1
  • docker build --platform linux/amd64 .

The major difference from other implementations is in the last two layers. Prisma and Yarn create cache directories in the root which takes quite a bit of size.

Screenshot 2022-05-09 at 1.20.02 PM
Screenshot 2022-05-09 at 1.20.02 PM850×212 49.9 KB

I could have deleted these temp directories but in future, there could be some other dependency which may create some different cache directory AND it’s good to have this layer cached in docker for future builds. So, including explicitly what goes in the image (node_modules + other deps) seems a better choice, if there’s some upstream change which requires another dir - build should break, so there’ll be no surprises.

I think a similar implementation should also help Yarn 1 projects.

Here is the Dockerfile: .dockerignore · GitHub

EDIT: Try this! An alternate implementation which is also similar in size is to put these temp files in buildkit cache - got to know by existing fly’s lauch Dockerfile. Maybe even better for consecutive builds: .dockerignore · GitHub

Next steps can be, if there isn’t anything I missed here:

  • PR to redwoodjs/docker
  • Update Dockerfile in fly.io
4 Likes