elk-zone
feat: add docker support
![bolt-new-by-stackblitz[bot] avatar](https://avatars.githubusercontent.com/in/182710?v=4 "Published by a pub.dev verified publisher"){kind=small}
Deploy Preview for elk-docs ready!
| Name | Link |
|---|---|
| Latest commit | 8c8e434e1b4fbd6d53ea5a9577752a2e6a4f9f31 |
| Latest deploy log | https://app.netlify.com/sites/elk-docs/deploys/63c60b408043ae000a672729 |
| Deploy Preview | https://deploy-preview-1052--elk-docs.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
Deploy Preview for elk-zone ready!
| Name | Link |
|---|---|
| Latest commit | 34b8764eaa1526dbee3148d7fbb94bf347507068 |
| Latest deploy log | https://app.netlify.com/sites/elk-zone/deploys/63c1146556458f0008717239 |
| Deploy Preview | https://deploy-preview-1052--elk-zone.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
I'm not very familiar with docker. Is there a way to pass a
.envfile?
If for production running, yes, use volume map like ./.env:/elk/.env:ro should be OK
And the .env file (if any) seems to be copied automatically during build process by COPY . ./ , so it should be fine
Also, we could publish a docker image to GitHub Packages using GitHub Actions when releasing a new version.
Docker Hub is charged for the organizations.
And the .env file (if any) seems to be copied automatically during build process by
COPY . ./, so it should be fine
Is that safe though? If docker image is published, it will include private information.
Also COPY . ./ would copy node_modules tree, which is then overridden by pnpm I.
Also, pnpm i installs new dependencies, which might introduce bugs. Should command be pnpm i --frozen-lockfile instead, installing last known working versions of all dependencies, which is pnpm version of npm ci?
Docker Hub is charged for the organizations.
Only for private packages. It is free for open source stuff.
@cyberalien But I didn't see a free option
Weird. I have one for Iconify that has "Docker Free Team" subscription. Looks like they've changed sign up form.
Found this though: https://www.docker.com/community/open-source/application/
@cyberalien Yeah I think they've changed policy before.
I didn't see any particularly benefit of using Docker Hub, so I would prefer to use GH Packages directly than apply a "sponsored" Docker Hub with a very detailed form.
A suggestion for this PR - maybe we can move the Dockerfile to the docs rather than directly in the repo? There will also be other ways of deploying elk and it could get cluttered.
Just created a free docker hub org ( elkzone ), please give me a username to send invitation? Thanks.
@Candinya sanxiaozhizi
Can we change the organization id to elk-zone? (as the same as GH org)
@Candinya
sanxiaozhiziCan we change the organization id to
elk-zone? (as the same as GH org)
Invitation sent ;)
Sadly docker hub doesn't support dash in username, so I'm afraid we cannot use the same org name 🥲
Is that safe though? If docker image is published, it will include private information.
Yes, this will have security issues, so for official repository we won't recommend including .env file (which always contain private keys etc.). And this repo ignores this, so it's OK.
But users can customize their docker image freely with their own CI settings.
Also
COPY . ./would copynode_modulestree, which is then overridden bypnpm I.
Yes, we need an .dockerignore file to prevent such ignored files, I'd like to add one.
Also,
pnpm iinstalls new dependencies, which might introduce bugs. Should command bepnpm i --frozen-lockfileinstead, installing last known working versions of all dependencies, which is pnpm version ofnpm ci?
Good idea! I'll add this too.
A suggestion for this PR - maybe we can move the Dockerfile to the docs rather than directly in the repo? There will also be other ways of deploying elk and it could get cluttered.
It's a good idea! Move files to function-oriented directories can keep the repo tree clean.
But on many occations, place the Dockerfile in the repo root can bring benefits to simplify workflow settings (the default Dockerfile usage, also easy for docker-compose bu simply specifying build: . ). and is also good for others who wants to fork their own version ( they can easily find this file and modify as they want ).
If there's any updates (like decide to place Dockerfile in subdirectory (like deploy) or something else), don't hesitate to let me know. :D
@Candinya I think so. Let's leave it in the root directory first.
More opinions are welcome.
I would prefer a page in the docs, from a personal point of view, as we also will need nginx configuration, for example, and possibly pm2. (And we can link through to Nitro deployment information also.)
Hmmm, how about putting it to /docker/Dockerfile or /container/Dockerfile? I don't think it's a good idea for putting Dockerfile on docs only.
I think general best practice for Dockerfile's is to have them at the root of the project (if the project produces a single artefact).
Personally I'd prefer an officially produced image that can be relied upon, though I appreciate the administration overhead that will add, as just having it as a documented thing with no official builds means Dockerhub will be awash with unofficial versions. Like mine, should that not happen 😄
Then let's add it at root of project and generate a docker image - wdyt @elk-zone/team?
Split the pnpm install before & after file copy (let's call them Pre and Post), but with some compromise, here's the reason:
- A post-install script is specified in package.json, which requires some project files to work, and simply include those involved files in
Premight break the cache optimize idea if any of them changes. - Meanwhile pnpm cannot skip one specific post-install script (like just ignore the package.json specified one, and run all others in deps), so they can only be skipped together, with --ignore-scripts option.
And I'm not sure why with --ignore-scripts option pnpm somewhat installed just 1302 packs, it's a little smaller than the ordinary deps number (like 1471)
But this still works because the Post reused 1287 packages and only downloaded 165 more, which should save a lot time with cache option.
Here's the log of this command if you'd like to analyze it 😄 elk-build-logs-8c8e434e.log