3 ms·

But you are not addressing what I am saying at all. I am saying that this is convenient for developers, but for us sysadmins, who have to implement Docker apps

• matthewmacleod 12y ago
  Sysadmins are expected to cheer in the same happy way, but in my opinion, many of us already knew how to build the kick ass systems /without/ containerization that the new developers ("devops"... yuch) are so cheery about. I don't think this is the case. My goal as a developer is to be able to deploy applications quickly and easily, to be able to scale them, and to avoid worrying about dependencies. That's all good practice. I still need a sysadmin to handle that infrastructure, so Docker et. al. are not a tool to replace sysadmins. That being the case, why do you think there is pressure from developers to adopt these tools? If sysadmins are generally capable of building 'kick ass systems' that offer the same features but without using Docker, then why aren't developers happy with the situation? Docker is a tool that allows sysadmins to provide these useful features without having to arse about building them by hand. It's a tool for sysadmins, and dismissing it out-of-hand in the way you do is totally stupid.
  • vacri 12y ago
    I'm a sysadmin in a place that's bringing docker on-board, and I'm finding that I'm having to write more stuff for docker than docker is solving, from an ops point of view. Developers don't care about where logs go or whether they persist. Or about managing SSL certificates (don't want those in the repo). Or starting/stopping things programmatically. Or a number of other things that the guys who have to make this stuff work in production have to care about. Docker is lovely for devs who can coddle their containers personally, but it's an entire new ecosystem with its own can of worms for ops people. An example: I can't easily rename containers, so if I want to install a new container with a set name for programmatic use, I have to destroy the old container, so there's no quick rollback. Instead I have to have a tag system for the docker images, and track those instead, keeping aware of which current unique name is 'old prod'. Another example: docker doesn't really support having one repo support two clients with their own config, not without a lot of faffing about. You get one dockerfile, it is always at the root of its tree, and it only builds one artifact. Another example: until you set up your own base images and repos, you're taking an app that used to be a few megabytes, and turning it into an image that is hundreds of megabytes in size. We have an nginx image that uses a stock docker base, and it's over 400MB! For nginx! That takes a non-trivial amount of time to download on a base image update, a new dev machine, a newly provisioned machine... if the docker hub happens to be up and not slow (we had a couple of issues there recently). And if you do have your own base images, you now have an extra operating system image that you need to keep up-to-date with security patches. Docker is nice and will 'get there' eventually, but in its current state it benefits devs at the cost of sysadmins. I would counter that dismissing sysadmin concerns out-of-hand in the way you are doing is totally stupid.
    • voidz 12y ago
      Thank you for making my point. English is not my first language, but this is exactly what I meant, and your examples are spot on, too. One other thing that is annoying is networking. IPv6 is once again being ignored, and for the rest they offer either a simple NAT bridge (and who wants to NAT anyway?), or you're on your own for the stuff you cannot proxy with for example nginx. I'm hoping that this will really improve because tools do exist already. Openvswitch is one of them. (It's also ironic to witness in this discussion how matthewmacleod even helps prove my point - developers are usually not really aware of what sysadmins do, although the other way around, we know what devs are doing, that's for sure.)