Workflow: publish Argus, Colossus and QueryNode as docker images#4780
Workflow: publish Argus, Colossus and QueryNode as docker images#4780
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
53e1765 to
5cd1bb4
Compare
5cd1bb4 to
ce431f9
Compare
|
After updating from master, storage-node as docker image is failing: Looking into it. |
|
Resolved it by reverting to older verision of mkdirp in storage-node. As there was a conflict with with version used in query-node/codegen. I think we really need to break out the query node into its own repo as it wrecks havock with package dependencies in the yarn worksapce. |
|
For some reason in the integration test (content-directory scenario) with the docker images built the CLI is failing to connect to distributor Tested locally without issues. Something specific to github runner maybe? |
Again it was dependency issue on building monorepo before docker images. Will add build step for the storage-node-client in distributor dockerfile. |
zeeshanakram3
left a comment
There was a problem hiding this comment.
query-node generated schema.graphql is now placed in the storage-node, distributor-node package so we don't require building query-node ahead of the docker images.
- I see that
schema.graphqlhas also been committed totests/network-testspackage, since integration test has direct dependency on building & running the QN, so maybe thetests/network-tests/src/graphql/schema.graphqlcan be gitignored? - I think same can be said about
clipackage too, as during local development it has dependency on QN and most of the commands require running QN, so I think it does not make much sense to commit auto-generated code to the repo and it generally also aligns with the decision we made a while ago to un-commit auto generated files (#4640)
TS compiler was not copying openapi spec files into compiled lib/ destination (why is not needed when running from the monorepo?) Is it because of not installing dev dependencies?
First, tsc does not copy non .js/.d.ts files into the outDir directory defined in tsconfig.json (only exception to this is I think .json files).
Now, when running the storage/distributor nodes locally or with docker-compose's bind mount setup, the OPENAPI_SPEC_PATH resolves to the api-spec file in the src directory and not in the lib directory so the nodes bootstrap successfully.
This is because, by default oclif tries to run a typescript project directly using ts-node without compiling to js artifacts. From the oclif documentation:
We generate CLIs and plugins that use ts-node to make it fast to run the TypeScript code without a compilation step. You won't have to mess around with build configuration using oclif.
So why it does not work in the new docker steup? My hunch is that if oclif can't find ts-node in node_modules it would fallback to running the js artifacts In the /lib dir. And since ts-node is defined as devDependency in the package.json, and the docker image is only installing the dependencies (specified by --production flag to the yarn install), and not the dev dependencies.
Update to use node18 -> better performance/security fixes
Shouldn't we also update the compatible node versions in package.json file
Lines 67 to 74 in d61783a
colossus.Dockerfile
Outdated
| RUN yarn workspace @joystream/types build | ||
| RUN yarn workspace @joystream/metadata-protobuf build | ||
| RUN yarn workspace storage-node build | ||
| RUN find . -name "node_modules" -type d -prune |
There was a problem hiding this comment.
Why this command is added here? It seems like a debug relic. This command is looking for all directories named "node_modules" starting from the current directory and printing it on console, the same command also exists in distributor-node.Dockerfile
Here is the response of the above command
./query-node/generated/graphql-server/node_modules
./query-node/node_modules
./query-node/codegen/node_modules
./query-node/mappings/node_modules
./devops/prettier-config/node_modules
./devops/eslint-config/node_modules
./types/node_modules
./node_modules
./tests/network-tests/node_modules
./utils/migration-scripts/node_modules
./utils/api-scripts/node_modules
./cli/node_modules
./metadata-protobuf/node_modules
./joystreamjs/node_modules
./storage-node/node_modules
./storage-node/client/node_modules
./distributor-node/node_modules
./distributor-node/client/node_modules
There was a problem hiding this comment.
interesting, perhaps the output was supposed to be piped to xargs to apply rm -fr?
I'll remove it.
colossus.Dockerfile
Outdated
| COPY ./package.json package.json | ||
| COPY ./tsconfig.json ./tsconfig.json | ||
|
|
||
| RUN yarn --frozen-lockfile |
There was a problem hiding this comment.
The way Dockerfile is structured, the npm dependencies will be installed even if only the code changed and, no new dependencies were added in the package.json files (in short all the subsequent layers needs to be build again after COPY ./storage-node storage-node even if there was only one liner change in storage-node package). Ideally the following build layers should be placed at the top of the Dockerfile,
COPY ./yarn.lock yarn.lock
COPY ./types/package.json types/package.json
COPY ./metadata-protobuf/package.json metadata-protobuf/package.json
COPY ./storage-node/package.json storage-node/package.json
COPY ./package.json package.json
RUN yarn --frozen-lockfileso that cached node modules layer can be used whenever there was no change in yarn.lock/package.json files, this approach considerably improves the build time of the images.
I think similar docker build optimisations can also be made in distributor-node.Dockerfile
There was a problem hiding this comment.
Great, I'll apply your suggestions and test it out.
zeeshanakram3
left a comment
There was a problem hiding this comment.
Looks good. Just one thing, did you see the last comment from #4780 (review)
Shouldn't we also update the compatible node versions in package.json file
...
WDYT?
Sorry I totally missed that. Thanks for explaining the oclif/ts-node matter about the openapi spec file not being copied 👍 Regarding checking in the schema.graphql I take your point. I'll revert for cli and integration tests. |
Running a storage-node and distributor-node currently requires
This is not practical for many reasons, and although is great for development cycle it is not a proper production setup. So in this PR we are making the two nodes build-able into proper independent docker images that will get published to docker hub giving operators more flexibility and deployment options in cloud, k8 clusters etc.
lib/destination (why is not needed when running from the monorepo?) Is it because of not installing dev dependencies?schema.graphqlis now placed in the storage-node, distributor-node package so we don't require building query-node ahead of the docker images.The images can be tested by running integration tests with the
docker-compose-no-bind-volumes.ymldocker compose file.Successful run:
https://github.com/Joystream/joystream/actions/runs/5437536353
you should be able to pull the images:
I've prepared a standalone repo for running query-node from built docker image. https://github.com/mnaamani/query-node-standalone