-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add experimental docker setup command #9024
Conversation
|
||
import { getEpilogue } from './util' | ||
|
||
export const EXPERIMENTAL_TOPIC_ID = null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reminder to replace this when I make a post on the forums
.option('verbose', { | ||
alias: 'v', | ||
default: false, | ||
description: 'Print more logs', | ||
type: 'boolean', | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't used this flag for anything yet
{ | ||
title: 'Adding the experimental Dockerfile...', | ||
task: () => { | ||
const dockerfileTemplateContent = fs.readFileSync( | ||
path.resolve(__dirname, 'templates', 'docker', 'Dockerfile'), | ||
'utf-8' | ||
) | ||
|
||
return [ | ||
writeFile(dockerfilePath, dockerfileTemplateContent, { | ||
overwriteExisting: force, | ||
}), | ||
] | ||
}, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Todo: think about collapsing these writeFile
tasks into one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file needs more comments explaining what's going on
|
||
services: | ||
redwood: | ||
user: node |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Josh-Walker-GM do we need to specify user here? We don't in the prod compose
@jtoar to use |
yes that's right |
The compose-dev works very smooth but I've run into some issues with the compose-prod.
It's still possible to have them if you add a line to the Dockerfile at the end of the base target.
and pass them in the docker-compose like this:
instead of like this:
It might be good to add this to the readme and save a few headaches. |
thanks for the feedback @xmaxcooking i really appreciate it! i was out last week and was getting caught up this week, fixing a few bugs. i'll turn my focus back to this now |
1852e4f
to
f838940
Compare
f838940
to
230e72c
Compare
Adds an experimental setup command to add a Dockerfile and compose files: ``` yarn rw exp setup-docker ``` The Dockerfile is near enough complete that we should release it experimentally so that we can get feedback from the community. I've successfully deployed it to Coherence and Fly. As far as I can tell, Render has half support. The api side runs just fine, but the web side has a static runtime, and I'm not sure how to get it to take the files from the web build stage. There's a known sticking point here: seeding and data migrations. I understand the problem clearly now. On all providers, seed and data migrations run using the image built from targeting api serve. There's only production dependencies in that image—`yarn rw exec` won't work for a number of reasons, but the main one is that `@redwoodjs/internal` isn't around. It's looking like we'll have to move `yarn rw exec` into it's own package and that we'll have to finish #8572. The docs are there but are very much a WIP.
Adds an experimental setup command to add a Dockerfile and compose files:
The Dockerfile is near enough complete that we should release it experimentally so that we can get feedback from the community. I've successfully deployed it to Coherence and Fly. As far as I can tell, Render has half support. The api side runs just fine, but the web side has a static runtime, and I'm not sure how to get it to take the files from the web build stage.
There's a known sticking point here: seeding and data migrations. I understand the problem clearly now. On all providers, seed and data migrations run using the image built from targeting api serve. There's only production dependencies in that image—
yarn rw exec
won't work for a number of reasons, but the main one is that@redwoodjs/internal
isn't around. It's looking like we'll have to moveyarn rw exec
into it's own package and that we'll have to finish #8572.The docs are there but are very much a WIP.