undefined | Better HN

0 pointsstyfle8y ago0 comments

As a developer, I find containers much easier to update, especially in scenarios where you need to update to a new patch with a fix for OpenSSL.

The solution, is to bump the version in the dockerfile, rebuild, and deploy.

This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines.

Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs.

Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.

0 comments

gcb08y ago

when it works for containers, it would have worked just the same for shared lib, but with one less step.

containers: update the lib, rebuild.

sane software: update the lib.

now, to the complicated case which containers claim to solve, when the lib update breaks compatibility.

container: update lib, application dont compile, leave like that because we think we are not vulnerable anyways.

sane sotware: update lib, application break, have to fix application because shared lib will be updated no matter what.

AluminiumPoint8y ago

Sort of. You are missing the ephemeral of containers, which has a net security advantage. Ephemeral containers mean that its harder for an attacker to obtain persistence, and easier to cycle out and swap bad containers than it is to patching servers.

I would argue that container orchestration infrastructure is objectively more secure than plain old servers; I get where you are coming from, but this tech is solving real problems, the cool aid is good

gcb08y ago

with shared libraries containers are an option just fine

xorcist8y ago

Everything is easy when you are one person caring for your own software. That's not a problem that needs solving.

j / k navigate · click thread line to collapse

0 pointsstyfle8y ago0 comments

As a developer, I find containers much easier to update, especially in scenarios where you need to update to a new patch with a fix for OpenSSL.

The solution, is to bump the version in the dockerfile, rebuild, and deploy.

This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines.

Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs.

Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.

0 comments

gcb08y ago

when it works for containers, it would have worked just the same for shared lib, but with one less step.

containers: update the lib, rebuild.

sane software: update the lib.

now, to the complicated case which containers claim to solve, when the lib update breaks compatibility.

container: update lib, application dont compile, leave like that because we think we are not vulnerable anyways.

sane sotware: update lib, application break, have to fix application because shared lib will be updated no matter what.

AluminiumPoint8y ago

gcb08y ago

with shared libraries containers are an option just fine

xorcist8y ago

Everything is easy when you are one person caring for your own software. That's not a problem that needs solving.

j / k navigate · click thread line to collapse