Hacker News new | ask | show | jobs
by nuerow 1691 days ago
> But that's not why people use containers. People use containers because they want to deploy random crap from the internet at the press of a button.

No, it really isn't. At all. In fact, your comment is so out of touch it actually reads like a poor attempt at trolling.

People use containers because they offer an easy and very convenient and self-contained platform to build, deploy, configure, and run multiple instances of the same application, regardless of node or platform.

In fact, if you ever manage to get any experience with containerized applications you'll eventually notice that in all containerized apps the bulk of applications, specially microservice-based applications, are comprised of apps developed in-house.

On top of that, there is a wealth of container orchestration systems that provide support for blue-green deployments, autoscaling, system introspection, auditing, and even secrets management, not to mention networking.

Your assertion makes as much sense as claiming that people use Linux distros a because they want to deploy random crap from the internet at the press of a button, just because they provide a package management system.

1 comments

You're going a bit far the other way, I think. People definitely use containers because they're a nice workflow, and yes a lot of containers are shipping all in-house code. But to ignore the popularity of Docker Hub and claim that people aren't also jumping head first into containers because they make it easy to grab random unvetted binaries is a step to far.

> Your assertion makes as much sense as claiming that people use Linux distros a because they want to deploy random crap from the internet at the press of a button, just because they provide a package management system.

If a major reason were using Linux was for the AUR, then that'd be a valid criticism. In practice, most distros ship a package manager that only pulls from official repos, and changing that requires jumping through hoops (even Arch with the AUR requires manual work to build an AUR package). And in practice, a lot of people are pulling random unofficial images off Docker Hub (and gcr.io and such) and just running them without review.

You could make the same analogy with github or npm or whatever unvetted repository. Nothing specific to containers here.
To varying degrees yes you can, and should, and those are absolutely worth caution - we do have semi-regular issues with malicious stuff getting uploaded to NPM; that github somehow has escaped major (publicized) problems is the real surprise.
I agree, and to be clear, that's precisely my point--your claim that "Docker Hub makes it easy to download unvetted [executables]" is a property it shares with all unvetted executable repositories--nothing to do with containers in particular. :)
> You're going a bit far the other way, I think. People definitely use containers because they're a nice workflow, and yes a lot of containers are shipping all in-house code.

Containers might have provided a convenient way to package, distribute, and deploy software, but that's just a nice-to-have complementing the whole reason anyone adopts containers.

To put things in perspective, while Docker is practically a household name, does snap ring a bell to anyone? Does anyone bother at all with snap?

> But to ignore the popularity of Docker Hub and claim that people aren't also jumping head first into containers because they make it easy to grab random unvetted binaries is a step to far.

This assertion is proven false with the inception of container registry services provided by service providers such as GitLab, GitHub, and all major cloud service providers such as AWS, Google Cloud, and Azure, and even lesser services such as Alibaba cloud and IBM cloud. These services might make container images available to the public, but their main role is to allow people like you and me to push their own container images to be pulled by your container orchestration services. In fact, even if you adopt third-party services you end up either using the official images made available by each project or repackaging the software yourself to reflect your own config and deployment needs.