7 ms·
> * If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a
by notyourday 9y ago
> * If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write.
Of course you do, you just moved the logic into the "orchestration" and "management" layer. You still need to write the code to correctly handle it. Throwing K8S at it is putting lipstick on a pig. It is still a pig.
> * We have a whole lot of HTTP services in a range of languages. Managing them all with fat binaries would be a chore - the author would have to give me a way to set port and listen address, and I have to keep track of every way to set a port. With a net namespace and clever iptables routing, docker can do that for me.
Nope, you wrote a set of rules and as long as everyone adheres to those rules things kind of work ( in a clever way ). Of course if you had the same kind of rules written and followed in any other method, you would arrive at the exactly the same place. In fact, you probably would arrive at a better place because you would stop thinking that your application works because of some clever namespace and iptables thing.
> * sometimes, I have to deploy and insecure app. Usually, it's a badly configured memcache or similar. With net namespaces, I can make sure only a certain server has access to that service, and that the service cannot ruin my host server.
You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container.
> load balancing. Luckily, I don't have to deal with extreme network loads which would require hand-made solutions, but just pushing up that number a little to do ad-hoc load balance makes things a lot easier
The time to build a template and instrumentation for your haproxy/nginx/varnish layer is when you don't have enough traffic and enough complexities.
- snuxoll 9y ago> You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container. I can guarantee it pretty well on my RHEL and CentOS systems, SELinux prevents containers from accessing things they shouldn’t just like it prevents Apache from dumping /etc/passwd.
- lightedman 9y ago"I can guarantee it pretty well on my RHEL and CentOS systems" Slashdot tried that with CentOS and failed miserably. I have my doubts regarding your guarantee.
- Spivak 9y agoLink? I want to see what they actually tried.
- anilakar 9y agoI 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.
- notyourday 9y agoIn my observation, Docker skills is a modern day ability to type "make", without being able to actually write a Makefile or debug a Makefile.
- tokenizerrr 9y agoYour observation is incorrect.
- sigjuice 9y agoYes. Each time you start a container, you are basically saying “make clean” as well.
- notyourday 9y agoExcept that people who write software to be put in containers cannot write that Makefile to save their life so for something that should be a ten line dependency they manage to build entire Linux, entire X and all unneeded tool chains.
- noahwilde 9y agoWriting a dockerfile successfully is maybe that. But learning to make a dockerfile should take someone a day to figure out. What the entire movement is about is creating an ecosystem around a common standard for dev ops.
- krizzo 9y agoI use Makefiles for creating docker files there is an advantage to docker from fat binaries. Both tools exist for a reason, used both wisely you can save time and effort.
- Spooky23 9y agoIt pushes thinking up to the app/middleware stack and away from server instances.
- notyourday 9y agoThe 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?
- Spooky23 9y agoNo idea. I’m not advocating that position. There are enterprise use cases where docker makes sense if the app support people are less impossible to deal with than the SAs. But you don’t have that issue in cloud.
- Spivak 9y ago* Multiple machines are a larger attack surface and a larger surface area to get things wrong. * 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.
- kemitche 9y agoI can run a dozen containers on my laptop a lot more easily than I can run a dozen VMs.
- deleted 9y ago[deleted]
- 2trill2spill 9y ago> You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container. Don't group all container implementations into one category. You could certainly use FreeBSD Jails and Illumos Zones for isolating apps.
- pmoriarty 9y agoThose 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.
- 2trill2spill 9y ago> Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they? If I keep my boxes up to date I only need to worry about zero day kernel exploits. So if someone comes along and uses a zero day kernel exploit to escape my FreeBSD jail then they were going to get on the box anyway, because any attacker using a zero day is highly skilled and highly targeted. > The most secure isolation is provided with physical separation. Second best is VMs. Containers are a distant third. While I agree that physical isolation is the safest, I don't think it's so cut and dry between containers and VMs. Virtual machines have significantly more attack surface than either Jails or Zones, think of all the emulated devices.
- pmoriarty 9y ago"Virtual machines have significantly more attack surface than either Jails or Zones, think of all the emulated devices." Nothing prevents you from using jails or zones in your VM.
- 2trill2spill 9y ago> Nothing prevents you from using jails or zones in your VM. I get that but that's no longer VMs vs containers, Thats VM plus container vs container.
- rco8786 9y agoYou argument seems to be "why use Docker when you can do all of these things by hand?". It's kind of the Devops corollary of "why use Java when you could write everything in C?".
- notyourday 9y agoNo, my argument is "if you are using docker without understanding what you are doing, you are not only not solving your problem but complicating your stack" Don't get me wrong I love people doing this. It makes my skills in uncomplicating needlessly complicated systems extremely valuable.
- esteban85 9y agoclearly you never had to reengineer some crappy code whilst making the current live system operate. Docker nowadays at least for me is essential for encapsulating st