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

31–40 of 51 posts

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

#31

Post by pensatoio »

jrochkind1 wrote: post #21
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…

> It seems more approachable to developers than ssh and working with real servers. I think the problem with "ssh'ing into real servers" is reproducibility, right? I say this as someone who does not use Docker and does not understand it and is scared of it, heh. But the reason I think I probably should/will have to eventually learn it and use it, is I'm not sure there's a better solution to reproducibility, meaning ba…

Yeah, you nailed it. Definitely take the dive yourself. Docker has made it so that we can run any of our tens of services locally with nothing more than a git clone and make up. It’s a great feeling!

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

#32

Post by number6 »

jrochkind1 wrote: post #21
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…

> It seems more approachable to developers than ssh and working with real servers. I think the problem with "ssh'ing into real servers" is reproducibility, right? I say this as someone who does not use Docker and does not understand it and is scared of it, heh. But the reason I think I probably should/will have to eventually learn it and use it, is I'm not sure there's a better solution to reproducibility, meaning ba…

You can "ssh" into a docker image and then commit it. Than you can ship the binaries __or__ you can write down all the steps and ship the source (Dockerfile).

So it's something like a mix out of infrastructure as code, vms and baremetal. Something like vagrant but with lesser overhead.

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

#33

Post by pacifika »

leetrout wrote: post #2

So this is for me to easily manage all my linters, formatters and such in one image from a group of upstream, published images, right?

Looks like it. When developer tooling causes conflicts to install globally and tricky to configure with the project (say phpunit) then this can all be taken care of by building it within a docker container. However if the linting also dependent on a specific version of a programming language to test its code now you are no longer testing the production environment.

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

#34

Post by TheDong »

rsa25519 wrote: post #23

See also Nix, which can declaratively generate Dockerfiles (example on home page) :-) https://nixos.org

> declaratively generate Dockerfiles

This is inaccurate, assuming you are referring to the 'dockerTools.buildLayeredImage' function in the nixpkgs repository.

That builds docker images declaratively, not dockerfiles.

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

#37

Post by gingerlime »

nine_k wrote: post #20
dfee wrote: post #15

Earlier quoted context omitted.

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 a…

And if the answer is No ?

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

#38

Post by csunbird »

donut wrote: post #5
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…

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

I second this. This can also be applied to a jar/script that somebody built 5 years ago and nobody knows how to update it.

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

#39

Post by aasasd »

aasasd wrote: post #17
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?

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

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

#40

Post by pydry »

mixologic wrote: post #24
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…

Sure it seems complex, but we're solving insanely complex problems that didnt even remotely exist during the halcyon days of "beautiful simplicity" of the ol' Unix philosophy. That philosophy was borne out of tools to process text files. It's closest proxy in the ops world might be microservices, but if you compare the amount of labor it used to take to set up a datacenter in even something so recent at the first dot…

There were just as many tools that existed during those "halcyon" days that didn't adhere to the UNIX philosophy. They just didn't tend to survive.

The one thing that hasn't changed is commercial (& ego) pressure to make the "one tool to rule them all", which has been pretty much immutable throughout the years, while on the other hand there is the reality of trying to string all of these things together.

Small, self contained tools with good APIs have persisted and will stand the test of time while the monoliths always die eventually (maybe with the exception of excel, which has really managed to cling on).

I don't think kubernetes or docker really have a bright future because they both have an ambition to be "the one tool to rule them all" and they simply can't.

Post reply on HN