Show HN: Dockerfiler: declarative management of images built from Dockerfiles
1–10 of 51 posts
Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles
#2So this is for me to easily manage all my linters, formatters and such in one image from a group of upstream, published images, right?
Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles
#3I think I may be a bit slow -- I don't get it =/
Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles
#4I 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're building a skyscraper on a floating pier and trying to reach the moon before the tide changes.
I know this is the way, but I am having a hard time because it just doesn't make sense. This doesn't feel like process. It feels like compounding of reactions. Is it just me? My company? Or is this a general feeling?
Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles
#5I 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…
> shipping on five year old containers that everyone is afraid to update and no one remembers how to build them.
That's bad. This is not the way to do it. And honestly, this isn't the fault of Docker, Kubernetes, Rancher, or any tech. Sounds like the org is broken...
Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles
#6I 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…
If you can't rebuild the docker containers... I think you're doing things wrong...
I always start from an official container base from a reputable source (Debian, Apache, nginx, Alpine)... Or I branch off one of my creations that is based on these... If I want to use someone else's work from an untrusted source, I make my own image and build pipeline for it so I'm in control.
This is my philosophy... I don't have any containers I'm afraid to rebuild... But I don't use kubernetes or rancher, just raw docker, docker compose, and ansible/terraform
Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles
#7We'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 away everything and start from scratch to which the interviewer asks, how often? Jim responds that currently chip architectures are re-done every 10 years but it should be more like every 5 years[1].
Just like any evolutionary process, there comes a point of diminishing returns because mistakes made cannot be corrected due to many other things that get piled up on top of it. So, it is difficult to track back. What happens is more shit gets piled up on top just to patch up old mistakes. Like our laryngeal nerve that loops around from the brain, all the way to the cervical area and goes back to the voicebox[2]. It is even more evident in a Giraffe. A good architect wouldn't design anatomy like this. The reason why it is the way it is, is because evolution has no hindsight and marginal cost of undoing the nerve is higher than just slightly increasing the length of the nerve. This is what we do in software. A good architect wouldn't design software like this. Sorry for the diversion, but I just feel so much pain with Docker, Kubernetes, Terraform and a whole load of AWS complexity. Holyshit.
[1] https://www.youtube.com/watch?v=1CSeY10zbqo
[2] https://en.wikipedia.org/wiki/Recurrent_laryngeal_nerve#/med...
Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles
#8From the article:
> Docker is an excellent means of distributing those sorts of tools.
No, package managers are excellent means of distributing and managing installed tools. Docker is an excellent way to package the tools, but it's distribution and management are terrible. There isn't even a command to simply show which containers are considered "outdated" without having to repull all your images, which can take 10+ minutes on 30 images.
Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles
#9I 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…
you are not alone.
i am growing very tired and weary of all these abstractions. i use them because, well, i want people i work for and esteem to succeed. but all this feels like non-sense from engineers at these big techs trying to justify what they did for their performance review.
folks, we are not actually solving much!
i feel like we should start over at this point with everything we learned. but that's just too much to ask because many have invested so much in all this already.
Re: Show HN: Dockerfiler: declarative management of images built from Dockerfiles
#10I 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…
Your company, certainly.
I've been to a number of places, big and small, and the ability to maintain and build every part of prod has been seen as important everywhere.
I'm pretty picky, though; one of the questions I ask at interviews is whether the potential employer does deployments on Fridays.