Docker Fixes - #3657
Conversation
bd5b1be to
70fb5cb
Compare
PeterDaveHello
left a comment
PeterDaveHello
left a comment
There was a problem hiding this comment.
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.
|
|
||
| # 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.
The mirror looks functional. Please provide broken proof of the "bad mirror".
There was a problem hiding this comment.
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.
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.
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. |
70fb5cb to
19efb47
Compare
This comment was marked as spam.
This comment was marked as spam.
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.
* 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.
19efb47 to
6980aad
Compare
|
@slow6r I am unclear as to what your comment means; it looks as if you cut and pasted something done by a robot on another PR? But at any rate, thanks for poking this; it has been sitting around for a while. I've rebased the branch on to the latest tip of @PeterDaveHello I'm sorry that my PR seems so difficult to review that even after nine months it's still not done. Is there anything I can do to help out with this? I get the sense that you might find it easier if I split this into four PRs, one per commit; I'm happy to do that if it helps you out. |
3 participants
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.