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

21–30 of 51 posts

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

#21

Post by jrochkind1 »

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…

> 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 basically "infrastructure as code", which really means "the state of the infrastructure as code".

Ansible/chef/etc are not great solutions. I haven't used Docker much yet, but my impression is that this is what leads people to Docker, liking it better than these alternatives specifically for reproducibility/"infrastructure as code"?

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

#22

Post by peterwwillis »

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…

It's your company. I've seen it a lot. They want to go whole-hog on some new technology, but they never learned how. So then they adopted more new technology to solve not knowing how to use the previous technology.

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

#24

Post by mixologic »

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 dotcom era, its insane what we can accomplish with a cloudformation yaml file or a terraform configuration file in a similar amount of time. The reproducability, the change management, all of it is light years better than it used to be. Every one of these 'yaml messes' all evolved out of drastically shittier shellscripts, duct tape, hope, and weekend pagers blowing up.

It might seem complex, and obtuse, but its turtles all the way down, and everything all the way back to to the original von Neumann architecture could definitely be looked at again and redesigned, but otoh, we're still doing weird shit like dividing our day into 24 hours and 60 minutes and 60 seconds for no other reason than 'its always been that way' and if we had a chance to actually design a sensible time system we could eliminate a lot of the complexity that has piled up on top of that system.

But yeah, no way would I ever want to go back to the way things were before all these layers existed.

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

#25

Post by crb002 »

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…

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.

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

#26

Post by crb002 »

crb002 wrote: post #25
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…

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.

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

#27

Post by vladsanchez »

ldoughty wrote: post #6
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…

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…

I like and align with your simple approach: Docker Compose, Ansible and Terraform.

K8s is too complicated for my competence and needs.

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

#28

Post by crb002 »

crb002 wrote: post #25
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…

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.

Perhaps mount an external directory and extract all artifacts to it as a zipfile at the end of the build.

https://access.redhat.com/documentation/en-us/red_hat_enterp...

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

#29

Post by zapita »

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…

I think that's exactly right.

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

#30

Post by codegladiator »

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…

That's like losing the source code and blaming the language ?
Post reply on HN