3 ms·

I agree with this statement that Dockerizing creates more dependencies that you need to track. But... A setup script on the host OS would install some packages

by gitgud 8y ago

I agree with this statement that Dockerizing creates more dependencies that you need to track. But... A setup script on the host OS would install some packages that the host OS will keep up to date. This is simply not as easy as you make it out to be. Installing dozens of services from the OS, is inherently creating a nest of dependencies which is hard to explicitly reproduce on other systems. Whereas Docker provides explicit isolated environments for each service so it's far easier to reproduce on other systems. This appeals to me for cloud environments but Docker on the desktop might be a bit too far for me...

lostapathy 8y ago
Yes, isolation is a big win. It means I can update the “os” each service resides on independently of each other, so I don’t have to tackle 10 upgrades at once. It also removes attack vectors and weirdness that happens when a package sees optional dependencies on the system. I.e,, if I need ldap for one thing, I don't have services in other containers trying to work with ldap.
- TicklishTiger 8y ago
  Now every time a package in Alpine gets an update you have to update all 10 containers. Because you will have no way of knowing if that package impacts the security of the service running in that container. Yes, most docker enthusiasts don't do this. They run a bunch of containers full of security holes. I expect this to become a hot topic as soon as we will start witnessing data breaches that have outdated containers as their source.
  - lostapathy 8y ago
    Right, we do daily builds on the CI/CD server at work for just this reason, but I agree, most don't.
  - geezerjay 8y ago
    > Now every time a package in Alpine gets an update you have to update all 10 containers. Because you will have no way of knowing if that package impacts the security of the service running in that container. That's pretty much the baseline when dealing with any software system, whether it's a bare metal install of a distro, a distro running on a VM, or software running in a container. > Now every time a package in Alpine gets an update you have to update all 10 containers. All it takes is inheriting the latest version of an image and running docker build prior to redeploying. I mean, this stuff is handled automatically by any CI/CD pipeline. If you don't carr about running reproducible containers you can also sh into a container and upgrade it yourself. Do you also complain about package managers such as deb or rpm because most debian and redhat users run a bunch of software full of security holes? Software updates is not a container issue. It is a software deployment issue. I mean, when you complain about keeping packages updated you are in fact complaining about the OS running on the base image.
    - TicklishTiger 8y ago
      That's pretty much the baseline when dealing with any software system Exactly. And now instead of one system, he has 11. All it takes is inheriting the latest version of an image He is not using "an image". From the article: "After the Alpine Linux 3.9.1 release I noticed the official Docker images had not been updated so I built my own." I mean, this stuff is handled automatically by any CI/CD pipeline. He has not describe any CI/CD pipeline involved in his infrastructure. Yet another aspect he has to build. you can also sh into a container and upgrade it yourself Into all 10 containers.
      - iKevinShah 8y ago
        I am not adding to the discussion but this was a real fun read. Great points from both sides.
TicklishTiger 8y ago
nest of dependencies which is hard to explicitly reproduce on other systems Not if the other system is using the same OS. A good way is to call your setup script "setup_debian_9.sh" for example, so it is clear which OS it was tested on.

by gitgud 8y ago

lostapathy 8y ago

Yes, isolation is a big win. It means I can update the “os” each service resides on independently of each other, so I don’t have to tackle 10 upgrades at once. It also removes attack vectors and weirdness that happens when a package sees optional dependencies on the system. I.e,, if I need ldap for one thing, I don't have services in other containers trying to work with ldap.

TicklishTiger 8y ago
Now every time a package in Alpine gets an update you have to update all 10 containers. Because you will have no way of knowing if that package impacts the security of the service running in that container. Yes, most docker enthusiasts don't do this. They run a bunch of containers full of security holes. I expect this to become a hot topic as soon as we will start witnessing data breaches that have outdated containers as their source.
- lostapathy 8y ago
  Right, we do daily builds on the CI/CD server at work for just this reason, but I agree, most don't.
- geezerjay 8y ago
  > Now every time a package in Alpine gets an update you have to update all 10 containers. Because you will have no way of knowing if that package impacts the security of the service running in that container. That's pretty much the baseline when dealing with any software system, whether it's a bare metal install of a distro, a distro running on a VM, or software running in a container. > Now every time a package in Alpine gets an update you have to update all 10 containers. All it takes is inheriting the latest version of an image and running docker build prior to redeploying. I mean, this stuff is handled automatically by any CI/CD pipeline. If you don't carr about running reproducible containers you can also sh into a container and upgrade it yourself. Do you also complain about package managers such as deb or rpm because most debian and redhat users run a bunch of software full of security holes? Software updates is not a container issue. It is a software deployment issue. I mean, when you complain about keeping packages updated you are in fact complaining about the OS running on the base image.
  - TicklishTiger 8y ago
    That's pretty much the baseline when dealing with any software system Exactly. And now instead of one system, he has 11. All it takes is inheriting the latest version of an image He is not using "an image". From the article: "After the Alpine Linux 3.9.1 release I noticed the official Docker images had not been updated so I built my own." I mean, this stuff is handled automatically by any CI/CD pipeline. He has not describe any CI/CD pipeline involved in his infrastructure. Yet another aspect he has to build. you can also sh into a container and upgrade it yourself Into all 10 containers.
    - iKevinShah 8y ago
      I am not adding to the discussion but this was a real fun read. Great points from both sides.

TicklishTiger 8y ago

nest of dependencies which is hard to explicitly reproduce on other systems Not if the other system is using the same OS. A good way is to call your setup script "setup_debian_9.sh" for example, so it is clear which OS it was tested on.