7 ms·

90% of the time Docker is used to solve the problem of "how do I upload this bucket of Python crud to a production server?" (Replace 'Python' with any other lan

90% of the time Docker is used to solve the problem of "how do I upload this bucket of Python crud to a production server?" (Replace 'Python' with any other language to taste.) A slightly smarter .tar.gz would have solved the problem just as well.

eeZah7Ux 7y ago
> A slightly smarter .tar.gz would have solved the problem just as well. It's called "OS package" ;) and can provide more strict sandboxing using a systemd unit file: unit files provide seccomp, cgroups and more.
- otabdeveloper1 7y ago
  Indeed you're right, but the problem is that your devs' machines and your production systems are running different OS's/distributions. Nix tries to solve this, but it isn't there just yet.
  - Bootvis 7y ago
    I know there is cost to this solution but it's a good one: Use the same OS and similar hardware for development and production.
    - randallsquared 7y ago
      The cost includes making development impossible without internet access, given that devs are not going to be carrying a cluster of servers around with them.
      - dijksterhuis 7y ago
        ^ This. Also means developers can work in whatever environment they want, but the result will be reproducible (almost) anywhere.
- jarfil 7y ago
  Docker containers provide seccomp, cgroups and more. Yes, systemd unit files are containers, just like Docker.
- bdavis__ 7y ago
  docker solves 2 problems. first is you have no control over your devs and allow them to install any software from anywhere. and second is you want to sell cpu time from the cloud in an efficient way (for the seller).
  - StreamBright 7y ago
    Agree with the first one but disagree with the second one. EC2 was selling CPU time long time ago before Docker existed.
  - dijksterhuis 7y ago
    Disagree with both statements. 1) is not a containerisation problem. It’s a team problem. I can jam in a load of npm and pip installs in to a shell install script. Maybe even delete /usr/ for the hell of it. Because the script isn’t isolated from the OS I can cause more damage. This problem is actually solved by doing code reviews properly and team discussions. 2) errr no. Containers != infrastructure. If you want to deploy on bare metal, you can.
manigandham 7y ago
No it wouldn't have. What's unzipping and running that code? What's monitoring it and restarting it? How do you mount volumes and env variables? How do you open ports and maintain isolation? A container is vastly more powerful for running an application than a tar file.
- archi42 7y ago
  No offense, but you're aware you make it sound as if we used to use punch cards until the arrival of docker? You can often run daemons as different users and set appropriate file permissions. You can add ENV variables to your start up scripts or configuration files. Volumes are mounted by the system (and you set appropriate access rights again). Monitoring and restarting services is managed by your init system (and probably some external monitoring, because sometimes physical hosts go nuts). Depending on your environment you can just produce debs, rpms, or some custom format for packaging/distribution. Yes, sometimes you still want docker or even a real VM, and there are good reasons for that - I totally agree. But often it is not necessary. I'm often under the impression that some people forget that the currently hyped and cool tech is not always and under every circumstance the right solution to a given type of problem. But that's not an issue with docker alone...
  - loriverkutya 7y ago
    You seems to be not aware of the problems docker solving “out-of-the-box” and that about 10-15 years ago, those problems was solved in-house developed toolset.
  - weberc2 7y ago
    The difference is that with VMs, you have to configure the things that you get for free with container runtimes. Specifically, Amazon can take care of a ton of the most mundane security and compliance burden that our org would otherwise have to own. Those differences means that developers can cost effectively be trained to do much of their own ops and I can solve more interesting problems.
  - treis 7y ago
    >You can often run daemons as different users and set appropriate file permissions. You can add ENV variables to your start up scripts or configuration files. Volumes are mounted by the system (and you set appropriate access rights again). That sounds exactly like creating a Dockerfile. The difference is that your script has to work any number of times on an endless number of system configurations. The Dockerfile has to work once on one system which is a much easier target to hit. The "any number of times on an endless number of system configurations" is a problem taken care of by the Docker team.
StreamBright 7y ago
Exactly. The said reality that solving this problem helps many developers who would otherwise not capable of deploying to servers.
- yoz-y 7y ago
  Much like accessibility, even if you are capable of doing everything by hand, it is usually nicer to have most of the gruntwork handled for you.
  - StreamBright 7y ago
    Well, not necessarily by hand. I never gave up deploying our Java application with Ansible. We could have used Docker but the team decided to use fat jars and Ansible instead. Nowadays with Java 11 you can make those fat jars even slimmer. There was no value proposition for us to change.
    - yoz-y 7y ago
      I did not work much with deployments but one thing I liked with Docker over Ansible is that testing the configurations locally is really easy and independent on the host platform.
kkapelon 7y ago
You are confusing Docker = the deployment artifact with Docker = self-contained runtime perfect for CI/CD Longer answer here https://thenewstack.io/docker-based-dynamic-tooling-a-frequently-overlooked-best-practice/ https://thenewstack.io/docker-based-dynamic-tooling-a-freque...
- otabdeveloper1 7y ago
  I'm not. My point was that Docker purports to solve the sandboxing and security problems. In reality, this is something that 90% of people who use Docker don't give a shit about. For the vast majority Docker is just a nice and easy-to-use packaging format. The sad part is that a) Docker failed at security. b) In trying to solve the security problem Docker ended up with a pretty crufty (from a technical point of view) packaging format. Maybe we need to start from scratch, listen to the devs this time and build something they actually want.
  - kkapelon 7y ago
    >My point was that Docker purports to solve the sandboxing and security problems. Says who? The article I linked to you says nothing about security. >Docker failed at security. If somebody thinks security is the strong feature of Docker he/she is misinformed. >For the vast majority Docker is just a nice and easy-to-use packaging format For the vast majority of who? Developers? Sys admins? PMs? The big advantage of docker is the self-contained environment for CI builds.

eeZah7Ux 7y ago

> A slightly smarter .tar.gz would have solved the problem just as well. It's called "OS package" ;) and can provide more strict sandboxing using a systemd unit file: unit files provide seccomp, cgroups and more.

otabdeveloper1 7y ago
Indeed you're right, but the problem is that your devs' machines and your production systems are running different OS's/distributions. Nix tries to solve this, but it isn't there just yet.
- Bootvis 7y ago
  I know there is cost to this solution but it's a good one: Use the same OS and similar hardware for development and production.
  - randallsquared 7y ago
    The cost includes making development impossible without internet access, given that devs are not going to be carrying a cluster of servers around with them.
    - dijksterhuis 7y ago
      ^ This. Also means developers can work in whatever environment they want, but the result will be reproducible (almost) anywhere.
jarfil 7y ago
Docker containers provide seccomp, cgroups and more. Yes, systemd unit files are containers, just like Docker.
bdavis__ 7y ago
docker solves 2 problems. first is you have no control over your devs and allow them to install any software from anywhere. and second is you want to sell cpu time from the cloud in an efficient way (for the seller).
- StreamBright 7y ago
  Agree with the first one but disagree with the second one. EC2 was selling CPU time long time ago before Docker existed.
- dijksterhuis 7y ago
  Disagree with both statements. 1) is not a containerisation problem. It’s a team problem. I can jam in a load of npm and pip installs in to a shell install script. Maybe even delete /usr/ for the hell of it. Because the script isn’t isolated from the OS I can cause more damage. This problem is actually solved by doing code reviews properly and team discussions. 2) errr no. Containers != infrastructure. If you want to deploy on bare metal, you can.

manigandham 7y ago

No it wouldn't have. What's unzipping and running that code? What's monitoring it and restarting it? How do you mount volumes and env variables? How do you open ports and maintain isolation? A container is vastly more powerful for running an application than a tar file.

archi42 7y ago
No offense, but you're aware you make it sound as if we used to use punch cards until the arrival of docker? You can often run daemons as different users and set appropriate file permissions. You can add ENV variables to your start up scripts or configuration files. Volumes are mounted by the system (and you set appropriate access rights again). Monitoring and restarting services is managed by your init system (and probably some external monitoring, because sometimes physical hosts go nuts). Depending on your environment you can just produce debs, rpms, or some custom format for packaging/distribution. Yes, sometimes you still want docker or even a real VM, and there are good reasons for that - I totally agree. But often it is not necessary. I'm often under the impression that some people forget that the currently hyped and cool tech is not always and under every circumstance the right solution to a given type of problem. But that's not an issue with docker alone...
- loriverkutya 7y ago
  You seems to be not aware of the problems docker solving “out-of-the-box” and that about 10-15 years ago, those problems was solved in-house developed toolset.
- weberc2 7y ago
  The difference is that with VMs, you have to configure the things that you get for free with container runtimes. Specifically, Amazon can take care of a ton of the most mundane security and compliance burden that our org would otherwise have to own. Those differences means that developers can cost effectively be trained to do much of their own ops and I can solve more interesting problems.
- treis 7y ago
  >You can often run daemons as different users and set appropriate file permissions. You can add ENV variables to your start up scripts or configuration files. Volumes are mounted by the system (and you set appropriate access rights again). That sounds exactly like creating a Dockerfile. The difference is that your script has to work any number of times on an endless number of system configurations. The Dockerfile has to work once on one system which is a much easier target to hit. The "any number of times on an endless number of system configurations" is a problem taken care of by the Docker team.

StreamBright 7y ago

Exactly. The said reality that solving this problem helps many developers who would otherwise not capable of deploying to servers.

yoz-y 7y ago
Much like accessibility, even if you are capable of doing everything by hand, it is usually nicer to have most of the gruntwork handled for you.
- StreamBright 7y ago
  Well, not necessarily by hand. I never gave up deploying our Java application with Ansible. We could have used Docker but the team decided to use fat jars and Ansible instead. Nowadays with Java 11 you can make those fat jars even slimmer. There was no value proposition for us to change.
  - yoz-y 7y ago
    I did not work much with deployments but one thing I liked with Docker over Ansible is that testing the configurations locally is really easy and independent on the host platform.

kkapelon 7y ago

You are confusing Docker = the deployment artifact with Docker = self-contained runtime perfect for CI/CD Longer answer here https://thenewstack.io/docker-based-dynamic-tooling-a-frequently-overlooked-best-practice/ https://thenewstack.io/docker-based-dynamic-tooling-a-freque...

otabdeveloper1 7y ago
I'm not. My point was that Docker purports to solve the sandboxing and security problems. In reality, this is something that 90% of people who use Docker don't give a shit about. For the vast majority Docker is just a nice and easy-to-use packaging format. The sad part is that a) Docker failed at security. b) In trying to solve the security problem Docker ended up with a pretty crufty (from a technical point of view) packaging format. Maybe we need to start from scratch, listen to the devs this time and build something they actually want.
- kkapelon 7y ago
  >My point was that Docker purports to solve the sandboxing and security problems. Says who? The article I linked to you says nothing about security. >Docker failed at security. If somebody thinks security is the strong feature of Docker he/she is misinformed. >For the vast majority Docker is just a nice and easy-to-use packaging format For the vast majority of who? Developers? Sys admins? PMs? The big advantage of docker is the self-contained environment for CI builds.