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

The sad state of sysadmin in the age of containers (2015)

vitavonni.de

Post reply on HN
Print view View original

321–324 of 324 posts

Re: The sad state of sysadmin in the age of containers (2015)

#321

Post by takeda »

GordonS wrote: post #255
takeda wrote: post #201

Earlier quoted context omitted.

I have seen this many times, generally the high profile containers do that, and these issues are more common among my peers. This requires self discipline and containers were pushed as a panacea for environments where the discipline is lacking.

Do you have any examples of high-profile images that do this? I really just haven't seen this with the ones I use.

Sorry, I see that my response looks ambiguous.

I meant the opposite. The high profile containers generally do the right thing, but containers created by peers rarely do it.

There's no mechanism to make things reproducible you need to implement it yourself, and from my experience most people (not the ones that release something publicly, but ones that work for a companies that use it) don't do it.

Re: The sad state of sysadmin in the age of containers (2015)

#322

Post by takeda »

gmueckl wrote: post #235
takeda wrote: post #201

Earlier quoted context omitted.

I have seen this many times, generally the high profile containers do that, and these issues are more common among my peers. This requires self discipline and containers were pushed as a panacea for environments where the discipline is lacking.

What is the point of storing the hash of an external file instead of checking the file into local version control? You're making it a part of your sources either way.

People who want to run docker don't want to run artifactory.

I'm not saying it's a good thing, but that's what I observed.

Re: The sad state of sysadmin in the age of containers (2015)

#323

Post by m463 »

onion2k wrote: post #15

Ever tried to security update a container? The whole point of using a container is that you can destroy it and build a new one easily. The new one should be built using up-to-date packages with security patches applied (and tested, obvs). Using the 'pets versus cattle'[1] analogy, patching a container feels like you're treating it like a pet. You should just kill it and get a new one instead. [1] https://thenewstack.…

It depends on where you're getting the new one from.

You could be getting mad cows every time.

I think it would be nicer if you could build containers from scratch that didn't tie into a cloud based website or someone's business model.

Sort of like a Dockerfile, but for the prerequisites. Maybe go even deeper to gentoo level.

Re: The sad state of sysadmin in the age of containers (2015)

#324

Post by chefandy »

u801e wrote: post #244
chefandy wrote: post #198

Earlier quoted context omitted.

I've worked with developers that have used git for 10 years who didn't fully realize what all of the 'git reset' options entailed, and I don't blame them. Git is complicated and you could certainly have a perfectly effective workflow with it for your whole career without using most of the features. If you'd only worked in environments in which code was entirely managed in GitHub, you probably wouldn't know that eithe…

> I've worked with developers that have used git for 10 years who didn't fully realize what all of the 'git reset' options entailed While knowing some of them, if you use git reset on a frequent basis is expected, knowing where to find information on the other options is essential. I frequently go back and read through the man pages for various git commands so that I understand what will happen if I use a particular…

Right. Assuming that they're not competent because they can't recall a slice of domain-specific knowlege from memory is not good.
Post reply on HN