-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Docker Fixes #3657
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
base: master
Are you sure you want to change the base?
Docker Fixes #3657
Conversation
The ubuntu.cs.utah.edu mirror appears to be obsolete; trying to use it produces error messages along the lines of: Ign:2 https://ubuntu.cs.utah.edu/ubuntu jammy-updates InRelease Err:2 https://ubuntu.cs.utah.edu/ubuntu jammy-updates InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 155.98.64.89 443] W: http://ubuntu.cs.utah.edu/ubuntu/dists/jammy-updates/InRelease: No system certificates available. Try installing ca-certificates. These messages don't make it completely obvious what the problem is, and it's also a rather obscure setting; you have to carefully read the Dockerfile to find it. Due to issues like this, and changing mirrors over time, it's best just to drop attempts to use a specific mirror and use whatever the default you get for archive.ubuntu.com etc. The package downloads generally happen only once per host, anyway, since Docker will keep not only the final image, but also the layers used to generate it: if the final image is deleted or anything in the Dockerfile after the OS package updates is changed, these cached layers will be used.
On my system, even without using local mirrors, the build is only two minutes, even though I have only a 1 Gbps Internet connection and I'm half-way across the world in Tokyo. There probably are still users with much slower Internet connections where the build could take eight minutes or more, but "several" still covers that.
bd5b1be
to
70fb5cb
Compare
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 PR mixes in many things, and some of them are unnecessary or related to different preferences. I suggest refocusing on the key parts that actually need adjustment.
- https://www.docker.com/ | ||
- https://docs.docker.com/ | ||
[dr-docs]: https://docs.docker.com/ | ||
[dr-web]: https://www.docker.com/ |
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.
I don't see the reason to reverse the order here; we should keep the diff to a minimum.
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.
I sorted in alphabetical order, as I generally do with my reference definitions. That said, I have no problem swapping the two, but you'll still end up with the same number of lines of diff.
|
||
# Pick a Ubuntu apt mirror site for better speed | ||
# ref: https://launchpad.net/ubuntu/+archivemirrors | ||
ENV UBUNTU_APT_SITE ubuntu.cs.utah.edu |
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.
The mirror looks functional. Please provide broken proof of the "bad mirror".
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.
The proof is in the error messages I gave in the commit message. Did you read those? How did you replicate this to have it working for you? Did you use docker build --no-cache
to ensure you were actually rebuilding those layers? If that worked for you, I suppose there is a possibility that this is somehow related to geolocation (I'm in Tokyo), though I can't really see how that would be.
Nonetheless, setting a proxy that is likely to be worse for most people (I expect that Canonical has far better network connectivity than a mid-level university) in a place where users are unlikely to come across it is a bad idea anyway.
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.
I checked its certificate, and it's correct, but I should test it another way to make sure we are on the same page, yes. Will do it later.
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.
You probably already know this, but just in case, remember that you need to try to validate the remote cert using apt
in the container itself. Just because it works in the web browser on your laptop doesn't mean that that cert can be validated using the cert store built into the image. (Which is, after all, more than three years old now.)
Just doing a docker build --no-cache -t temp0 .
at the head of master
should demonstrate the problem. If it doesn't, that's very mysterious to me. I just checked this again right now and still see the issue.
I believe the commits here separate the changes into properly separate groups of related changes. Which commits are you proposing should be split? Or did you want each commit to go into a separate PR? Oh, and one more note: if you're reviewing the full set of diffs for the entire PR, it's likely to be somewhat messy and confusing, and mixing concerns. Try reading the diff for each individual commit; these along with the commit message should tell a very clear story about exactly what I'm doing, step by step. |
Yes, it has indeed been split into several different commits. In my view, style- or preference-related adjustments are somewhat different in nature from actual fixes. |
I agree, which is why I put them into separate commits. |
* Add `--name` to `docker run` command to make the container easier to manipulate. (This will produce collisions if two developers both try this on the same system, but it's not worth a lot of extra documentation to try to sort out the few developers who can't figure out what's going on from the error messages.) * Explain better that the current repo and working copy are copied to ~/.nvm/ inside the container. * Explain that the container is not deleted when you exit, and how to re-enter and delete it. * General improvements to the language.
70fb5cb
to
19efb47
Compare
The Docker image build was broken due to using a bad mirror; remove the mirror to fix this in a way that it's unlikely to recur. Fix a few bugs in the documentation for the Docker image/container and then do a general cleanup on it.
See the commit messages for full details.