3 ms·

Hmm, a SCP shell script on my laptop, prompting my SSH key's password and deploying the site to the target machine? Or a constantly-updating behemoth, running

Hmm, a SCP shell script on my laptop, prompting my SSH key's password and deploying the site to the target machine? Or a constantly-updating behemoth, running as root, installing packages from yet another unauditable repository chain?

hyperhopper 5y ago
The first option is something custom that you had to write yourself and remember how to use years later, or explain how to use to others The second option is standardized and usually the same 1 or 2 commands to run anywhere
somenewaccount1 5y ago
You forgot the step where you had to provision that server to run the software and maintain all the systems security updates on the live running server, and that server requires all the same maintenance, with or without docker. And if you fuck it up, better call the wife and cancell Sunday plans because you forgot how it all gets installed and ......yeah, just use docker :p
- danuker 5y ago
  Debian offers unattended upgrades: https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades And security updates, as you said, are needed regardless of whether you run Docker on top. I think Docker is a needless complexity and security risk.
  - throwanem 5y ago
    And you're welcome to think so, but if you intend to make a case for removing Docker as optimization, you still have yet to start.
    - danuker 5y ago
      I am arguing against Docker for maintainability reasons, not CPU cycles. Relying on hidden complexity makes for a hard path ahead. You become bound by Docker's decisions to change in the future. For example, SSLPing's reliance on a lot of complex software (among which NodeJS and Docker) got it to close, and it got on the front page of HN recently. https://sslping.com/ https://sslping.com/ https://news.ycombinator.com/item?id=30985514 https://news.ycombinator.com/item?id=30985514 Keeping dependencies to a minimum will extend the useful lifespan of your software.
      - throwanem 5y ago
        Docker Swarm isn't Docker; it's an orchestration service on top of Docker, that happens to have originated with the same organization that Docker does - hence the name. A few years ago Swarm looked like it might be competitive in the container orchestration space, but then Kubernetes got easy to use even for the small deployments Swarm also targeted, and Swarm has withered since. It wouldn't be impossible or probably even all that difficult to switch over to k8s if that were the only blocker, but as the sunset post notes and you here ignore, that wasn't the only or the worst problem facing SSLping - as, again, the sunset post notes to your apparent disinterest, it's been losing money for quite a while before it fell apart. (Has it occurred to you that it losing money for a while might have contributed to its eventual unmaintainability, as the dev opted sensibly to work on more sustainably remunerative projects? If so, why ignore it? If not, why not?) Similarly for the Node aspect - that's very much a corner use case related to this specific application (normally SSLv3 support is something you actively don't want!), and not something that can fairly be generalized into an indictment of Node overall. Not that it's a surprise to see anyone unjustly indict Node on the basis of an unsupportable generalization from a corner case! But that it's unsurprising constitutes no excuse. Other than that you seem here to rely on truisms, with no apparent effort to demonstrate how they apply in the context of the argument at which you gesture. And even the truisms are misapplied! Avoiding dependencies for the sake of avoiding dependencies produces unmaintainable software because you and your team are responsible for every aspect of everything, and that can work for a team of Adderall-chomping geniuses, but also only works for a team of Adderall-chomping geniuses. Good for you if you can arrange that, but it's quite absurd to imagine that generalizes or scales.
  - lolinder 5y ago
    Security updates are only needed on the OS level if you're running Docker on bare metal or a VPS. If you're running Docker in a managed container or managed Kubernetes service such as ECS/EKS, you only need to update the Docker image itself, which is as simple as updating your pip/npm/maven/cargo/gem/whatever dependencies. I see two main places where Docker provides a lot of value: in a large corp where you have massive numbers of developers running diverse services on shared infrastructure, and in a tiny org where you don't have anyone who is responsible for maintaining your infrastructure full time. The former benefits from a standardized deployment unit that works easily with any language/stack. The latter benefits from being able to piggy-back off a cloud provider that handles the physical and OS infrastructure for you.

hyperhopper 5y ago

The first option is something custom that you had to write yourself and remember how to use years later, or explain how to use to others The second option is standardized and usually the same 1 or 2 commands to run anywhere

somenewaccount1 5y ago

You forgot the step where you had to provision that server to run the software and maintain all the systems security updates on the live running server, and that server requires all the same maintenance, with or without docker. And if you fuck it up, better call the wife and cancell Sunday plans because you forgot how it all gets installed and ......yeah, just use docker :p

danuker 5y ago
Debian offers unattended upgrades: https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades And security updates, as you said, are needed regardless of whether you run Docker on top. I think Docker is a needless complexity and security risk.
- throwanem 5y ago
  And you're welcome to think so, but if you intend to make a case for removing Docker as optimization, you still have yet to start.
  - danuker 5y ago
    I am arguing against Docker for maintainability reasons, not CPU cycles. Relying on hidden complexity makes for a hard path ahead. You become bound by Docker's decisions to change in the future. For example, SSLPing's reliance on a lot of complex software (among which NodeJS and Docker) got it to close, and it got on the front page of HN recently. https://sslping.com/ https://sslping.com/ https://news.ycombinator.com/item?id=30985514 https://news.ycombinator.com/item?id=30985514 Keeping dependencies to a minimum will extend the useful lifespan of your software.
    - throwanem 5y ago
      Docker Swarm isn't Docker; it's an orchestration service on top of Docker, that happens to have originated with the same organization that Docker does - hence the name. A few years ago Swarm looked like it might be competitive in the container orchestration space, but then Kubernetes got easy to use even for the small deployments Swarm also targeted, and Swarm has withered since. It wouldn't be impossible or probably even all that difficult to switch over to k8s if that were the only blocker, but as the sunset post notes and you here ignore, that wasn't the only or the worst problem facing SSLping - as, again, the sunset post notes to your apparent disinterest, it's been losing money for quite a while before it fell apart. (Has it occurred to you that it losing money for a while might have contributed to its eventual unmaintainability, as the dev opted sensibly to work on more sustainably remunerative projects? If so, why ignore it? If not, why not?) Similarly for the Node aspect - that's very much a corner use case related to this specific application (normally SSLv3 support is something you actively don't want!), and not something that can fairly be generalized into an indictment of Node overall. Not that it's a surprise to see anyone unjustly indict Node on the basis of an unsupportable generalization from a corner case! But that it's unsurprising constitutes no excuse. Other than that you seem here to rely on truisms, with no apparent effort to demonstrate how they apply in the context of the argument at which you gesture. And even the truisms are misapplied! Avoiding dependencies for the sake of avoiding dependencies produces unmaintainable software because you and your team are responsible for every aspect of everything, and that can work for a team of Adderall-chomping geniuses, but also only works for a team of Adderall-chomping geniuses. Good for you if you can arrange that, but it's quite absurd to imagine that generalizes or scales.
- lolinder 5y ago
  Security updates are only needed on the OS level if you're running Docker on bare metal or a VPS. If you're running Docker in a managed container or managed Kubernetes service such as ECS/EKS, you only need to update the Docker image itself, which is as simple as updating your pip/npm/maven/cargo/gem/whatever dependencies. I see two main places where Docker provides a lot of value: in a large corp where you have massive numbers of developers running diverse services on shared infrastructure, and in a tiny org where you don't have anyone who is responsible for maintaining your infrastructure full time. The former benefits from a standardized deployment unit that works easily with any language/stack. The latter benefits from being able to piggy-back off a cloud provider that handles the physical and OS infrastructure for you.