7 ms·

There are some things that have to be made clear to the team when moving to containers (don't use joerandom/alpine as a baseimage, build via digest instead of t

There are some things that have to be made clear to the team when moving to containers (don't use joerandom/alpine as a baseimage, build via digest instead of tag etc) but the speed at which you can onboard people is amazing. I couldn't imagine deploying a Python application without Docker nowadays.

baq 7y ago
i've been doing python for 15+ years now and docker is one of the best things to happen to it, possibly it's saving grace in server side software. deployment and dev env setup used to be brutal.
jwbwater 7y ago
How is this better than ansible, salt, chef, puppet, etc.? Once it's automated it's automated, no?
- 0x138d5 7y ago
  I wouldn't use the term "better" - I still rely heavily on puppet and ansible. But the containerization aspect gives the option to pull up and destroy services without worrying about polluting the host you're in.
  - u801e 7y ago
    But couldn't you get the same thing using the virtual environment provided by python? Unless you're using a lot of modules with C extensions, you wouldn't need to install anything outside the virtual environment.
    - m_mueller 7y ago
      > Unless you're using a lot of modules with C extensions in my experience only the simplemost applications actually don't need anything outside of vanilla python pip. suddenly the client wants PDF reports and you're setting up e.g. some tex-based printing system with a bunch of host packages needed. only containers give you the peace-of-mind that all dependencies, current and future, can be described as part of the codebase.
      - u801e 7y ago
        > only containers give you the peace-of-mind that all dependencies, current and future, can be described as part of the codebase. Couldn't the same thing be done via the package manager and a RPM spec or deb file where all the necessary dependencies are listed and installed as part of the package? It could be done on a VM or could be done on a machine by keeping track of what dependencies are installed when installing the application and handling uninstallation by removing all newly installed dependencies along with the application.
        ahnick 7y ago
        My understanding is yes and I believe you are describing NixOs (https://nixos.org/ https://nixos.org/)
        m_mueller 7y ago
        but why polute host or go back to VM overhead per application if we have already a solution that is easier to handle? even just in terms of build & launch time it's quite a bit more performant to use containers vs. VMs.
        u801e 7y ago
        > but why polute host The package manager can handle removing pretty much any file it installs when uninstalling, so the host really doesn't get "polluted". > or go back to VM overhead per application In a development environment hosted on a VM, several applications can be installed on the VM (rather than having one per VM) to reduce overhead. Then testing and making code changes could be done by running a pip -e (editable) install and modifying code in the working directory, or making the change, repackaging and re-installing, and restarting the daemon. With a container, at least in my experience, you need to re-build it each time you make a change to the code, which actually takes longer than modifying an editable install or re-building the wheel/RPM and reinstalling it.
        m_mueller 7y ago

baq 7y ago

i've been doing python for 15+ years now and docker is one of the best things to happen to it, possibly it's saving grace in server side software. deployment and dev env setup used to be brutal.

jwbwater 7y ago

How is this better than ansible, salt, chef, puppet, etc.? Once it's automated it's automated, no?

0x138d5 7y ago
I wouldn't use the term "better" - I still rely heavily on puppet and ansible. But the containerization aspect gives the option to pull up and destroy services without worrying about polluting the host you're in.
- u801e 7y ago
  But couldn't you get the same thing using the virtual environment provided by python? Unless you're using a lot of modules with C extensions, you wouldn't need to install anything outside the virtual environment.
  - m_mueller 7y ago
    > Unless you're using a lot of modules with C extensions in my experience only the simplemost applications actually don't need anything outside of vanilla python pip. suddenly the client wants PDF reports and you're setting up e.g. some tex-based printing system with a bunch of host packages needed. only containers give you the peace-of-mind that all dependencies, current and future, can be described as part of the codebase.
    - u801e 7y ago
      > only containers give you the peace-of-mind that all dependencies, current and future, can be described as part of the codebase. Couldn't the same thing be done via the package manager and a RPM spec or deb file where all the necessary dependencies are listed and installed as part of the package? It could be done on a VM or could be done on a machine by keeping track of what dependencies are installed when installing the application and handling uninstallation by removing all newly installed dependencies along with the application.
      - ahnick 7y ago
        My understanding is yes and I believe you are describing NixOs (https://nixos.org/ https://nixos.org/)
      - m_mueller 7y ago
        but why polute host or go back to VM overhead per application if we have already a solution that is easier to handle? even just in terms of build & launch time it's quite a bit more performant to use containers vs. VMs.
        u801e 7y ago
        > but why polute host The package manager can handle removing pretty much any file it installs when uninstalling, so the host really doesn't get "polluted". > or go back to VM overhead per application In a development environment hosted on a VM, several applications can be installed on the VM (rather than having one per VM) to reduce overhead. Then testing and making code changes could be done by running a pip -e (editable) install and modifying code in the working directory, or making the change, repackaging and re-installing, and restarting the daemon. With a container, at least in my experience, you need to re-build it each time you make a change to the code, which actually takes longer than modifying an editable install or re-building the wheel/RPM and reinstalling it.
        m_mueller 7y ago