-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Docker : Create official image #3356
Comments
Ry has denoland on dockerhub. I think we should solve glibc issue on Alpine before shipping, as I think Alpine is preferred target. #3243 On https://github.com/hayd/deno-docker GitHub actions has my docker hub API key and pushes on tags to docker hub, very easy. See release.yml. Deno could do both :latest (every commit) and :VERSION. |
Targeting x86_64-unknown-linux-musl might make this work... And also mean the Amazon Linux (Lambda) build becomes trivial (at the moment it's kinda a pain/slow to create a compatible binary). |
Currently trying out https://github.com/hayd/deno-docker |
This has worked for me too. Docker Hub link: https://hub.docker.com/r/hayd/deno |
Keenly following the progress of this. Alpine Deno image is essential :-) |
Note that several people have had performance problems when using rust on musl: https://andygrove.io/2020/05/why-musl-extremely-slow/ |
I am happy to help move over hayd/deno-docker to denoland, if that was desired. Most are a very thin wrapper, extract the binary, create user and deno-dir, set up entrypoint: @kesor created a musl built image recently! My suspicion is it makes sense to incorporate some of that into BUILD.gn/gn-args instead of maintaining a patch to apply: It'd be great to have some deno-specific benchmarks before dismissing musl here... however one concern is currently alpine offers llvm9 which means a larger deno binary (since no_inline_line_tables=false), so atm the musl alpine image is larger than alpine w/ glibc. |
I mean 27MB is quite slim really. |
I think once this is decided on and stable we could PR the official docker repo. |
Also we can push to docker registry and also github registry don't you think? |
It's also standard to have the OS part of the tag instead of the repository name. Is it possible to get |
Deno image based on the buster is needed for development |
Will we create a new reop just for dockerfile? |
Just wanted to try this out, found out that there's no official image yet. What's the workaround? |
We can make a proposal to Docker to have an official image and then both deno and Docker will help work on the image to make it as efficient and stable as possible. Updates are also managed by Docker. It's probably better to do it from the start so people don't have to move from a deno image to an official image and there will almost definitely be confusion with the differences. |
Working on this repository atm: https://github.com/lucemans/docker-deno |
That's not how Docker images are meant to be designed... Everything should be installed beforehand not while creating the container |
@nihaals what is the route for such a proposal? |
The first step is to create our final images. I've created a repo which can house the images while they are being developed and reviewed. What will happen is first we will need to create the images (I think @hayd will probably be able to kickstart this). Once we have a set of images that work, I can create a PR to the official images repo. This kickstarts the proposal. During this time, people who know a lot more about maintaining secure and efficient Docker images will give feedback which will then be implemented (they may PR, I think it would most likely require us to implement the changes ourselves), and once the images are good enough, they will be accepted. Every update the images will be updated and a new PR will be made giving the new GitHub commit with the newer images. These images will again be verified (most likely with less feedback), and then updated on Docker Hub. It's this reason why anyone can host the repo during this phase, as every update will be manually verified by them. It's usually standard to build from source in images and making sure to delete any kind of caches. I can also implement a testing system to make sure any images actually work as there may be a large number of PRs initially. I personally think we should focus on Once the first proper images are done, automation just needs to be used to make sure they are updated with the latest version of deno (possibly also updating any checksums). We can take inspiration from the Node and Python images as they're very optimised. The main thing I'm unsure on is architecture support, the rest I've played around with. Part of the proposal is listing the supported architectures and if one requires a different image, listing that too. It may also be useful to move the repo to some kind of Also, a modification for some of the 3rd party images will be needed to work here: we should be using official base images, as this will increase our likelihood of being accepted. |
We also need a member to confirm whether they are or aren't interested in maintaining the image (either a member needs to be related to the repo or we need to have "contacted" them (assuming this means we need permission)). We shouldn't even really consider moving forward until we get some response as this will block it from happening at some point and it might be that they would prefer to be the main maintainers. |
I've also got a vested interest in seeing a musl-compatible binary for release on alpine. It could also be extrapolated to be run on If there's anything I can do to help with troubleshooting the Dockerfile give me a holler. |
Any movement on this? |
Just waiting on a response from a project member |
Just waiting on a response from a project member +1 |
@bartlomieju Do you think we can move the @hayd project in the official Deno repo in the future? Seems like it's mature enough. |
I’m not sure if that makes much sense if it doesn’t follow the official docker image guidelines |
Are there some specific things hayd/docker-deno images are doing/not doing? Either way we can address these as GitHub issues ... Atm it seems like there's been no indication the correct docker team is watching/interested in managing a deno image (yet). Moving to denoland seems positive way forward. |
I already explained in my write-up. It's obviously up to the project members to decide, they may not want to even have an official image for whatever reason. The key point is that it's up to them. It's their project, they have the final say, even if it's open source |
When you say "project member" do you mean of deno(land)? or a member of the docker official images team? |
I'm quoting Docker's docs, I believe they say member of upstream, which I guess in this case would be a member of the denoland org |
I see (the original link you posted)
This reads like it's a good start for dockerfiles to be moved to denoland if we want a deno Official Image in the future. |
I agree, the only reason I'm hesitant is that it could actually delay progress since it would be rewritten from scratch (not all the current main images are built from source and use official base images) As Docker images don't seem to be a current priority, this possible further delay could mean that we don't get official images for a further 6 months due to miscommunication or misunderstandings of the requirements of official images, compared to having a space where these images are already defined, so having them available to everyone could be as simple as getting an OK from a member or transferring the repo |
I don’t think we (denoland) are going to do an official docker image right now. Mostly because I’m not sure we have the bandwidth to manage it. My attempt to manage the vscode extension, for example, has not been going well. Andy’s image is working fine. Maybe in the future if it makes sense. |
Does this also mean hold back on a "Docker Official" image or are you giving permission for someone else to work on and submit it? Anyone is allowed to submit one for review as long as they have permission afaik |
Permission is not a prerequisite... at least it's not mentioned in the docs. I'm happy to take any feedback in order for hayd/deno-docker to meet any Official requirements, please create separate GH issues on that repo. That way we could more easily move it to denoland or Docker Official in the future. (@ry Atm updates are bumping the version number and tagging releases, so docker would be much less arduous than vscode... But it would still be "another thing" to maintain!) |
Just to note, if there is some suggestion this is important/useful for Official Images, @lucacasonato is a maintainer of hayd/deno-docker and also a member of denoland. Anyway, perhaps let's move this discussion there for now. |
@ry It already makes sense now IMO. I think that having ASAP an official image will remove some frictions to production... As a Kubernetes user, I would be more confident to ship
I hope that many others share the same opinion about such an important topic :-) |
So what's holding the "Deno" team to publish official image on Docker Hub? or it's not really up to Deno team? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
I don't think it makes sense to close this issue, as it remains an issue. |
I totally quote @jiraguha, I'm new to Deno, and I'd like to try it within a Docker container first. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
Oh No! :( |
Hy, |
Huge thanks to @hayd who's been maintaining Docker images for the past two years. Today these images were transferred to |
@hayd started a while https://github.com/hayd/deno-docker
This can be ported to be integrated as the Official Deno docker image. So 3 steps are needed:
Also do we plan to release on docker hub only or we push it to github registry also? It's just a matter of URL in the command in the CI but @ry and @piscisaureus have to create / set credentials in the project.
The text was updated successfully, but these errors were encountered: