91–100 of 188 posts
Earlier quoted context omitted.
BTW, were these cool systemd features invented after Docker by any chance?
According to the "Initial release" dates on Wikipedia, systemd is 3 years older than Docker (2010 vs 2013). And one of the core objectives of systemd was to take advantage of then-still-new Linux kernel features like cgroups.
Earlier quoted context omitted.
until you realize the firewall is the same iptables that you use to isolate the network in docker containers
Not at all. IP tables is used to route traffic between containers, yes, but the isolation is done by network namespaces.
Or... you create a network with namespaces and use iptables aka the firewall to network that to the other networks you created with namespaces ?
Think about it logically... when you use TCP you share the connections... your namespace isolation is exposed by the very thing that firewalls it... make sense ?
Earlier quoted context omitted.
This right here. Can confirm, the #1 benefit of using Docker is that 98% of our "Ops" issues has gone away.
No they haven't. They are lurking around the corner waiting to hit you when you least expect it. The mugging you are about to get is what your ops team has had and are trying to prevent. Enjoy the learnings...
The point of Docker is basically that the container-image developer is specifying the sandbox, instead of the sysadmin specifying the sandbox. None of the things mentioned solve the problem of the sysadmin having to "design" the solution from the top down. Docker does. A Docker image is an appliance. You don't architect it; you just configure it. You don't have to care which OS it's running inside. Docker images runn…
You do have to care which OS it's running inside if only to know when to patch it for $vulnerability_of_the_day. It sure is convenient to consider it as a blackbox that you 'just' need to configure, but that's just pushing responsibility to the developer(s). In my short experience, the latter seldom care about security. When a security breach occurs, who is going to take the fall ? The sysadmins that supposedly run o…
Earlier quoted context omitted.
No they haven't. They are lurking around the corner waiting to hit you when you least expect it. The mugging you are about to get is what your ops team has had and are trying to prevent. Enjoy the learnings...
There is only one possible place where this can really grow to be that kind of a problem: It's when ops isn't being involved. (And if the relationship between development and ops has broken down to the point that each one is trying to work around rather than with each other, you're already screwed. The rest is just details.) If ops is involved, then there's no real reason they can't take charge of making sure that an…
If ops does their job well, that's great. A lot of people aren't that effective at their jobs, and if someone in ops is stuck in PHP Land, unwilling to learn Docker, they're going to become a huge bottleneck in short order. Some people are incompetent, but there is a lot of people who don't particularly like their jobs yet get a sadistic joy out of playing the gatekeeper role, being the ultimate decider of whether someone else gets what they want. All the worse if upper management sides with them by default since, well, they're the "webmasters".
Yeah, I'm pretty biased because I've had situations like that on a few occasions.
I'm not necessarily saying that the production situation is always improved by Docker, but what I described is not an uncommon situation and I think it often leads to teams gravitating towards Docker when their last person in ops finally leaves.
The point of Docker is basically that the container-image developer is specifying the sandbox, instead of the sysadmin specifying the sandbox. None of the things mentioned solve the problem of the sysadmin having to "design" the solution from the top down. Docker does. A Docker image is an appliance. You don't architect it; you just configure it. You don't have to care which OS it's running inside. Docker images runn…
You do have to care which OS it's running inside if only to know when to patch it for $vulnerability_of_the_day. It sure is convenient to consider it as a blackbox that you 'just' need to configure, but that's just pushing responsibility to the developer(s). In my short experience, the latter seldom care about security. When a security breach occurs, who is going to take the fall ? The sysadmins that supposedly run o…
I think grandparent was using "you" to refer to the docker container developer, not the host OS maintainer.
Earlier quoted context omitted.
There is only one possible place where this can really grow to be that kind of a problem: It's when ops isn't being involved. (And if the relationship between development and ops has broken down to the point that each one is trying to work around rather than with each other, you're already screwed. The rest is just details.) If ops is involved, then there's no real reason they can't take charge of making sure that an…
Your last argument is true of any software outside of the Docker ecosystem. Are you really going to read through every single directory in node_modules/ to make sure you know exactly what you're running? I don't believe anyone who answers yes, besides in the sense that NPM will produce vulnerability reports. If ops does their job well, that's great. A lot of people aren't that effective at their jobs, and if someone…
What, you don’t? Each dependency comes with a license notice. Everything needs to be pinned. The npm mess that comes out of pinning and unbounded versioning is precisely why we steer clear of it.
Earlier quoted context omitted.
There is only one possible place where this can really grow to be that kind of a problem: It's when ops isn't being involved. (And if the relationship between development and ops has broken down to the point that each one is trying to work around rather than with each other, you're already screwed. The rest is just details.) If ops is involved, then there's no real reason they can't take charge of making sure that an…
Your last argument is true of any software outside of the Docker ecosystem. Are you really going to read through every single directory in node_modules/ to make sure you know exactly what you're running? I don't believe anyone who answers yes, besides in the sense that NPM will produce vulnerability reports. If ops does their job well, that's great. A lot of people aren't that effective at their jobs, and if someone…
Of course we are.
Not manually, of course, but we've got automated tools that generate a report of every dependency, including transitive dependencies, and its license and version, for all the platforms we use. We definitely keep an eye on these reports.
"But it's haaaaarrrrd" isn't a great excuse for letting things get out of control. We're developers. Taking obnoxious labor-intensive manual processes and making them quick and easy is the entire reason why our profession exists in the first place.
(Granted, the fact that a single import can bring in hundreds or even thousands of transitive dependencies to worry about is a big reason why I avoid the Node ecosystem like the plague. So there is that.)