Live data from Hacker News

Show HN: Dockerfiler: declarative management of images built from Dockerfiles

github.com

41–50 of 51 posts

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#41

I am growing my anxiety as more layers to the Docker onion grow faster than I can stay current. In the past 2 years my company adopted kubernetes to manage our already confusing Docker infrastructure design, and then they added Rancher to it because no one was making sense of kubernetes. Meanwhile we're shipping on five year old containers that everyone is afraid to update and no one remembers how to build them. We'r…

> no one remembers how to build them

For a long time I didn't know about:

  docker history

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#42
post #39
post #17

Earlier quoted context omitted.

> Instead of the beautiful simplicity based on UNIX philosophy, modern devops feels like a mishmash of ideas plopped together, tied with a bunch of yaml tape So... it's simpler tools tied together? Are you arguing that simple tools must instead stay apart? Is the developer supposed to build their thing invoking each basic tool one-by-one? Maybe makefiles and shell scripts should also be verboten, then?

> we need to throw away everything and start from scratch Wait a minute, this part is even funnier. So Docker allows you to build your quasi-VMs using all those Unix tools, by talking to Linux that's been put inside your Linux. But apparently this is not what you meant by ‘Unix philosophy’ and it all should be thrown away. Huh.

Being on unix =/= Unix philosophy. It seems like the perceived irony is drawn from conflating the two.

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#43
post #26
post #25

Earlier quoted context omitted.

Maybe I am stupid, but is there a problem in Docker build design? By default you should get both a Docker image and an artifacts.zip of binaries that it downloaded so you can pin them? The cache isn't just for speed. It allows for reproducible builds.

Also, Docker should have a reproducible flag that creates binary reproducible images. Timestamps and local system info would have to be nerfed to some default or fed in statically with a config file.

You can already make reproducible images of e.g. NixOS. I don't know if there's a good way to tackle the problem at the docker level without sacrificing container OS agnosticism.

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#44
post #3

I think I may be a bit slow -- I don't get it =/

You write declarative manifests that include source repos/tags and destination repos/tags and build arguments, and this thing figures out what commands are needed to get your container registry in the desired state. It outputs those commands. You'd then pass then to an environment that has access rights to make the necessary changes.

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#45
post #26

Earlier quoted context omitted.

Also, Docker should have a reproducible flag that creates binary reproducible images. Timestamps and local system info would have to be nerfed to some default or fed in statically with a config file.

You can already make reproducible images of e.g. NixOS. I don't know if there's a good way to tackle the problem at the docker level without sacrificing container OS agnosticism.

My OS is a docker image, booted bare metal.

https://godarch.com/

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#46
post #3

I think I may be a bit slow -- I don't get it =/

You write declarative manifests that include source repos/tags and destination repos/tags and build arguments, and this thing figures out what commands are needed to get your container registry in the desired state. It outputs those commands. You'd then pass then to an environment that has access rights to make the necessary changes.

Ohhhh.

So the example in the repo being, you have some set of tools which you may want to run in CI/CD, or maybe every developer to have the same version of (linters, deployment tools, test runners, etc) and this will figure out the optimal way of pulling them so they're available?

Thanks, makes sense now I think.

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#47

Earlier quoted context omitted.

You write declarative manifests that include source repos/tags and destination repos/tags and build arguments, and this thing figures out what commands are needed to get your container registry in the desired state. It outputs those commands. You'd then pass then to an environment that has access rights to make the necessary changes.

Ohhhh. So the example in the repo being, you have some set of tools which you may want to run in CI/CD, or maybe every developer to have the same version of (linters, deployment tools, test runners, etc) and this will figure out the optimal way of pulling them so they're available? Thanks, makes sense now I think.

Yep! Not only pulling them, but also building them and pushing them if needed.

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#48

Hi, I'm the author. Thanks for taking a look. This is basically a tool to help manage a "Dockerfile" repo (along the lines of https://github.com/jessfraz/dockerfiles ), where you build any tools you want into images that you control. This can be really useful for personal use or within a company. Why build tools into Docker images? Love it or hate it, there are many senses in which Docker is currently the best medium…

this description is a lot clearer to me than the one from readme :)

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#49
post #48

Hi, I'm the author. Thanks for taking a look. This is basically a tool to help manage a "Dockerfile" repo (along the lines of https://github.com/jessfraz/dockerfiles ), where you build any tools you want into images that you control. This can be really useful for personal use or within a company. Why build tools into Docker images? Love it or hate it, there are many senses in which Docker is currently the best medium…

this description is a lot clearer to me than the one from readme :)

Thanks for that feedback! I'll update the readme.

Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles

#50

We've made all this so complicated. Instead of the beautiful simplicity based on UNIX philosophy (arguably), modern devops feels like a mishmash of ideas plopped together, tied with a bunch of yaml tape and god forbid if you ever want to look inside the stack of mess. Containerization is a great idea but flawed in its interface. I like what Jim Keller (chip architect) says about complexity - that we need to throw awa…

> we need to throw away everything and start from scratch

This has already happened back in the 1990s with Plan 9 from Bell Labs[1] and Inferno[2], but it didn't take due to various factors. With Docker and Kubernetes we are slowly wrangling the current Linux ecosystem to be more akin to Plan 9 environment with private namespaces and networked environment, with "compute" and "storage" servers. But the issues these tools are trying to fix and improve are buried deep in the stack, at the kernel level - fixing them would mean throwing away years of work put into Linux and starting almost from scratch.

Plan 9 was definitely ahead of its time. The original authors learned from their UNIX choices back in the 1970s and looked into the future with a fresh set of eyes. Private process namespaces, lack of a superuser account with full privileges, transparent networking, split of the monolithic system architecture into CPU (compute), fileserver (storage) and terminal with CPU and storage being in the data center on a fast network and terminals being out there used by the users... I would say that this is pretty spot on with 2020s world where cloud and data centers are used almost all the time and end users rely on lightweight (both in a "weight" and in a "computing power" sense) devices to engage with the system at large.

Of course there were missteps as well, nobody's perfect. A byzantine graphical user interface with overfocus on the mouse (today's world overwhelmingly uses touch-based interface instead) probably hinders the newcomers the most. But apart from that, its hard to pick anyhing else that is wrong with the platform in the current world, and most of the things offered at the operating system level are very attractive in today's environment where user applications need to be protected from each other.

Today Plan 9 still lives on[3] and waits for its time to shine. If enough people are fed up with Kubernetes, I would hope that they could see the future elsewhere. There are definitely issues with current Plan 9 ecosystem and its forks that prevent many people to consider it for work, like its graphical interface stuck in the 1990s era when the rest of the computing world evolved and improved. But this can change, new graphical interface can be implemented to scratch someone's itch - that's how most of the current Linux server and desktop environments came to be. So I would say, look at what the OS provides, trim the bad parts away if you don't like them and start working in a fresh environment with good ideas.

[1]: https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs [2]: https://en.wikipedia.org/wiki/Inferno_(operating_system) [3]: https://youtube.com/watch?v=6m3GuoaxRNM

Post reply on HN