Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

11–20 of 51 posts

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

#11

Post by chomp »

digitalsushi wrote: post #4

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…

You aren't alone. But if it wasn't Docker, it'd be VMs, unreproducable golden images, and whatever VM orchestration you use. If it wasn't VMs, it would be bare metal, and piles of unmaintainable post provision scripts.

You can always do it wrong, it's not always the tech. Your description sounds like frustration mixed with some amount of wrongness. But I do agree that after being in the industry for about 15 years, there seems to be a diminishing returns of sorts of complexity to net org gain with the current "meta".

Always remember, KISS.

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

#12

Post by jbergknoff »

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 that we have for distributing and running dev tools. Here's an article making that argument: https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc....

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

#13

Post by ldoughty »

chomp wrote: post #11
digitalsushi wrote: post #4

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…

You aren't alone. But if it wasn't Docker, it'd be VMs, unreproducable golden images, and whatever VM orchestration you use. If it wasn't VMs, it would be bare metal, and piles of unmaintainable post provision scripts. You can always do it wrong, it's not always the tech. Your description sounds like frustration mixed with some amount of wrongness. But I do agree that after being in the industry for about 15 years, t…

I don't consider myself a docker fanboy, but between bare metal, VMs, and docker... I think docker works better than most solutions thus far primarily because developers can run and test their code locally... But as you move more towards complicated solutions, docker becomes more than a 1-3 day training session, if it can even be tested locally anymore...

Despite dockerfile being essentially shell scripts on a clean basic install... It seems more approachable to developers than ssh and working with real servers.

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

#14

Post by u801e »

ldoughty wrote: post #13
chomp wrote: post #11

Earlier quoted context omitted.

You aren't alone. But if it wasn't Docker, it'd be VMs, unreproducable golden images, and whatever VM orchestration you use. If it wasn't VMs, it would be bare metal, and piles of unmaintainable post provision scripts. You can always do it wrong, it's not always the tech. Your description sounds like frustration mixed with some amount of wrongness. But I do agree that after being in the industry for about 15 years, t…

I don't consider myself a docker fanboy, but between bare metal, VMs, and docker... I think docker works better than most solutions thus far primarily because developers can run and test their code locally... But as you move more towards complicated solutions, docker becomes more than a 1-3 day training session, if it can even be tested locally anymore... Despite dockerfile being essentially shell scripts on a clean…

> I think docker works better than most solutions thus far primarily because developers can run and test their code locally

That can also be done with a locally run VM on the dev machine and provisioning it with config management like chef or ansible.

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

#15

Post by dfee »

nine_k wrote: post #10
digitalsushi wrote: post #4

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…

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.

Well, don’t leave us hanging. When do you if the answer is yes or no to a Friday deploy?

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

#16

Post by ffreire »

u801e wrote: post #14
ldoughty wrote: post #13

Earlier quoted context omitted.

I don't consider myself a docker fanboy, but between bare metal, VMs, and docker... I think docker works better than most solutions thus far primarily because developers can run and test their code locally... But as you move more towards complicated solutions, docker becomes more than a 1-3 day training session, if it can even be tested locally anymore... Despite dockerfile being essentially shell scripts on a clean…

> I think docker works better than most solutions thus far primarily because developers can run and test their code locally That can also be done with a locally run VM on the dev machine and provisioning it with config management like chef or ansible.

Indeed, and the meta at the time was Vagrant on top of Virtualbox!

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

#17

Post by aasasd »

fermienrico wrote: post #7

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…

> 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?

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

#19

Post by WrtCdEvrydy »

digitalsushi wrote: post #4

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…

The technology industry is broken in every level... we layer more and more abstraction to try to fix issues with previous technology...

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

#20

Post by nine_k »

dfee wrote: post #15
nine_k wrote: post #10

Earlier quoted context omitted.

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.

Well, don’t leave us hanging. When do you if the answer is yes or no to a Friday deploy?

If they say that they do deploy on Fridays, I ask whether they do multiple deploys a day as a routine. Some SRE orgs have their gears oiled so well that deploying stuff is trivial, and rolling stuff back is also trivial (and may even be automatic). If so, I'm glad and continue with the interviewing process.

If the answer is "yes, when the deadlines are tight", then I cancel further interviews. This means inevitable and regular overtime on weekends (because deadlines are always tight), and I need my weekends for my family.

Post reply on HN