Hacker News new | ask | show | jobs
by chrissoundz 3021 days ago
Why not just `git push`, `docker build`, `kubectl set image`?
3 comments

Lots of reasons:

- A local Docker build might have issues due to your local computer's environment that cause mysterious or hard-to-replicate problems.

- You might not have permission to push new images to your organization's Docker repo from your computer.

- You might be on slow internet, or your docker images large enough, such that pushing on the cloud is 10-100x faster than pushing locally. (this is my pain point)

- You need to remember, and use, whatever Docker image tagging scheme your organization requires.

> A local Docker build might have issues due to your local computer's environment that cause mysterious or hard-to-replicate problems.

This always comes and bites us back isn't it? The whole promise of Docker was that we would be freed form these pains... But yet here we stand :(

Wondering what kind of issues you're running into. The first one that comes to mind for me is Kernel version mismatches. Though those shouldn't always cause that much trouble due to the "Dont break userspace mantra" that Linus has

> This always comes and bites us back isn't it? The whole promise of Docker was that we would be freed form these pains... But yet here we stand :(

Exactly. Using a separate build host makes builds more independent but on the other hand you'll be running images that the dev did not check.

By the way, are docker image identifiers derived from the actual contents? (Are they reproducible?)

This would suggest they are not:

> Docker images are non-reproducible: each "layer" identifier is a random hex string (and not cryptographic hash of the layer content),

Source: https://blog.bazel.build/2015/07/28/docker_build.html

That's a bit out of date - today layer IDs are for the most part sha256's of the contents of the layer tar.gz.

However, it's still very difficult to generate the same layer ID twice. Timestamps permeate the layer contents itself in the form of file mtimes. The final image metadata itself also contains several timestamps.

Docker has a local cache of layers that helps simulate reproducibility. But if you clear that cache or use a different build machine, you will have a very hard time ever generating the same layer ID again.

Because why not just `git push` :)
I'm not the author but I would imagine - this allows more room for automation. You should be able to setup a CI/CD system around it with webhooks from your git repo.