131–140 of 180 posts
I use Docker mainly in situations where the required dependencies (Java, GTK, etc) conflict with the versions on my system. In this case, the service running in the container is required, unless I want to upgrade the operating system, and I'm on CentOS 7 for a reason (stability and security).
Earlier quoted context omitted.
It pushes thinking up to the app/middleware stack and away from server instances.
The odds are you are running on VMs in AWS, GCS, Azure or even DO. If that's the case, why on earth is your building block not a VM?
* Overhead. It might be getting smaller but it's certainly still there. Not just the application but all the OS services that are duplicated are extremely wasteful when you're billed for your resources directly.
* Your vendor distributes applications as docker containers.
* Your developers are building and testing in docker.
* Clustered resources are dead simple with swarm. It can obviously be done with VMs but it's work.
* Devs and sysadmins alike enjoy using off-the-shelf services that are maintained by someone else.
Earlier quoted context omitted.
In my observation, Docker skills is a modern day ability to type "make", without being able to actually write a Makefile or debug a Makefile.
Yes. Each time you start a container, you are basically saying “make clean” as well.
Well, the author is definitely missing the point. In scenario 1, I put a Go binary onto a server and make a systemd unit file. In scenario 2, I put a Go binary in a docker container and launch it on a Kubernetes cluster. Scenario 2 is wasting a ton more cycles and RAM, but other than that, what's the difference? * With containers I can put a Python app right alongside my binary but with total isolation. No need to fu…
"Systemd can use Cgroups to limit RAM or CPU, but schedulers like Kubernetes can also use your CPU and RAM limits to schedule containers. As far as I know, there's no equivalent tooling for doing this with fat binaries." They're called cgroups. You don't need systemd, Docker or Kubernetes to use them.
Earlier quoted context omitted.
Companies don't have a moral responsibility to do that, but it's a smart retention strategy. If good devs feel like they're learning useless non transferable skills, they'll be more likely to leave for the sake of their career. If they feel like the business is investing in them, they'll be more likely to stay.
Resume Driven Development can be just as bad for everyone involved.
Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing.
Of course, there is a balance here. Sometimes frustrating tasks must be done. In that case, ideally the end goal is sufficiently motivating.
Earlier quoted context omitted.
Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they? The most secure isolation is provided with physical separation. Second best is VMs. Containers are a distant third.
> Second best is VMs. Containers are a distant third. I will grant you that containers are harder to isolate since it's same problem as isolating individual processes. But there isn't really a meaningful difference between a kernel exploit and a hypervisor exploit.
Take a look at Clear Containers (despite the name, actually using VMs) and their qemu-lite minimal machine type.
Earlier quoted context omitted.
Yes, and we all know every shop in town has resources comparable to Facebook‘s...
You can compile a statically linked PHP interpreter. Probably a bit of messing around with configure and makefiles, but doable.
Earlier quoted context omitted.
I think that the main point was that docker skills are transferable, i.e. you can expect a new hire to be productive in less time. Too many companies still have in-house build/deploy systems that are probably great for their purpose but don't offer valuable experience that would be usable outside that company.
If a company has existing in-house systems that are working well, why should they care about "valuable experience that would be usable outside the company"? Unless you think it's their responsibility to train people so those people can then leave and take the benefit of that training to some other, possibly competing, business?
While a very large company can get away with building a custom in-house ecosystem that takes months for a new employee to come up to speed on, most companies find it more palatable to use industry standard products/systems that a new employee is already familiar with and can come up to speed on quickly.
Earlier quoted context omitted.
> but other than that, what's the difference? The need to configure, manage, monitor and maintain a whole extra set of programs. Also, systemd can just as easily start the binary in a cgroup, eliminating most of the following concerns. > The isolation is broken Worth noting that behind the scenes, Linux is using the same in-memory versions of libc, even for containers. That isolation you speak of already doesn't exis…
> Kubernetes was built for Google's use case, in Google's environment. Attempting to use it with other restrictions and requirements is a nightmare. That's a tremendous overstatement. The first part is just wrong, as was pointed out in earlier responses. The second part just smacks of your having been soured by a poor experience. We started with kubernetes in production at very small scale, just a few supporting serv…
I admit: I find the argument for "fat binaries"[1] over containers compelling. There's just one problem... ...let's say I'm working on an existing code base that has been built in the old-style scripting paradigm using a scripting language like Ruby, PHP, or (god help us) node.js. Let's say we're well aware of the shortcomings are are looking for a migration path to move into the future. I can just about see how we c…
Containers offer a standard where you can deploy your applications in a language-independent way, so they avoid this scaling problem.
The same is true for most OS-level packages (like rpm and deb), except that they provide much less isolation.