3 ms·
> In docker and vagrant you do it the same way, the hash of the specific artefact. No, in nix you pin the commit hash of nixpkgs, which gives you the exact sam
by kreetx 3y ago
> In docker and vagrant you do it the same way, the hash of the specific artefact.
No, in nix you pin the commit hash of nixpkgs, which gives you the exact same package set every time. But with a Docerfile, even if you add it to your project's repo then any `apt-get install something` will still give you a different something depending on when you build the image. In nix, you always get the same something.
> That is why I wrote about the specific exception for CI
I meant that you keep the dev environment the same as CI because if you develop in a different environment than the CI then whenever CI runs then you'll get new issues (because you weren't using the same environment).
- oneplane 3y agoI wasn't referring to Nix, how Nix uses hashing, what specific hash, or source implementation it is using, or that it might be using an artefact hash. I was referring to the referencing method: a hash. This is the same method in the three mentioned products (nix, docker, vagrant): an immutable pointer to a specific resource. As for CI, dev environments, not relevant here. I only mentioned in passing because CI is a common use case for hardcoded immutable reference. We're talking about someone wanting a box to experiment in, not CI. Not even software engineering either.
- kreetx 3y agoWhat hashes do you use in docker or vagrant?
- oneplane 3y agoSHA256, generally. So for example, you might use 5c15a6e5c0bf02e6c0eaa939cb543c41d7725453064c920b9a4faeea7c357506. (This is a digest hash you'd use in Docker, as an example) You can both consume that specific one, but also reproduce it locally if you want to. Depending on your intent, bandwidth and trust you can pick the method you desire.
- kreetx 3y agoI mean hashes of what, not which hash algorithm. If you build the same Dockerfile, then I don't think you'll get the same hash, so I'm not sure what the use of that hash would be. (Did you mesn a hash of some other thing?)
- nunez 3y agoSee my post above. Those hashes are a checksum of the image as seen by the registry plus some additional magic.
- kreetx 3y agoYes, but every other thing you install in the container you'd somehow need to manage the hashes for, too.
- oneplane 3y agoThe hash of the image. So you cannot get the same hash if you change something in the image. This is also why you have reproducible builds, the source should always result in the same hash, otherwise the build would not be reproducible. So building the same Dockerfile twice gets you the same hash. This does of course not work if you change something each build, like pulling in some random dependencies that you didn't also pin to a hash, or if you don't use a fixed point in time for the filesystem. We also sign the images so you get some protection against (future) hash collisions. Works for about 900 different images in our internal registries so far. We also used nix, but only a handful of developers actually enjoyed it, so that project got killed off. You can use any search engine and search for "Dockerfile reproducible build" if you want to learn more.
- kreetx 3y agoYou get the same hash only if you build the image when none of your dependencies were updated in the mean time. If you `apt-get install something` in a month, the resulting image will most likely not have the same hash. Docker itself doesn't really get you reproducible builds. I assume you haven't actually tried to achieve it if you still believe it. Docker is like any arbitrary linux machine you start installing things on: you need some other system to get reproducibility.