5 ms·

How many scenarios do you typically need to spin up your environment in? I achieve the same (defining the environment) by pinning Python dependencies via requi

How many scenarios do you typically need to spin up your environment in? I achieve the same (defining the environment) by pinning Python dependencies via requirements.txt and virtual environments. And I have an installation script, like a Dockerfile but just an executable bash script, that installs PostgreSQL etc, pulls the code from GitHub and starts up the server. I can upload this to a clean Debian installation to set up the server, with a well-defined stack, in minutes. > Have other apps you want to host on the same set of machines I don't. I just use one $5 per month Linode for each SaaS. (Or bigger Linodes as the projects get more users. My biggest single box currently serves ~100,000 users.)

piaste 6y ago
> I don't. I just use one $5 per month Linode for each SaaS Well then you're basically using VMs as your containerization mechanism, with install scripts replacing Dockerfiles. So from your perspective, don't think of Docker as a really fat binary. Think of it as a stripped-down VM that doesn't cost a minimum of $5 per instance, and comes in a standardized format with a standardized ecosystem around it (package registries, monitoring dashboards, etc.)
- mherrmann 6y ago
  It's a really fat binary that adds unnecessary layers in both dev and prod. In dev, it's faster to run tests and easier to debug without Docker. And in prod, why use a vm inside a vm?
  - sofixa 6y ago
    > In dev, it's easier to debug without Docker. And in prod, why use a vm inside a vm? On the contrary, it's easier to debug with Docker - it eliminates dangling system level libraries / old dependencies / cache, and everything is self-contained. If you have the problem in dev, you'll have it in prod as well. Docker is not a VM, it's basically a big wrapper around chroot and cgroups, the performance hit is minimal. The advantage is that, again, it's self-contained, so there's little risk some OS / dangling library muddies the waters ( especially in Python that's a great risk -OS level python library installations are a thing, and many a Python library depend on C libraries on the system level, which you can't manage through Python tooling). It's also idempotent ( thus making rollbacks easier) and declarative.
    - mherrmann 6y ago
      I've never encountered this "dangling libraries" problem you describe in the past 7 years of developing web apps. I suspect you are working in different, maybe more specialised, environments than me. For me, it usually is really just pretty standard libraries and dependencies.
    - antidocker 6y ago
      This is wrong. Docker is a VM on Windows at least.
      - sofixa 6y ago
        Nobody is talking about Docker on Windows or Mac for production use.
        antidocker 6y ago
        Don't you think Mac are not used in Prod?
  - treekogreen 6y ago
    Containerisation software adds so much more than just a binary with layers of indirection. Easy fine grain control of individual application memory, namespace isolation (container to container communication on a need to know basis), A-B testing, ease of on-boarding, multi-os development, CD pipelines, ease of container restarting etc.
- antidocker 6y ago
  I use Ansible instead Docker. It make no sense to use Docker at all. Ansible take care of all.

piaste 6y ago

> I don't. I just use one $5 per month Linode for each SaaS Well then you're basically using VMs as your containerization mechanism, with install scripts replacing Dockerfiles. So from your perspective, don't think of Docker as a really fat binary. Think of it as a stripped-down VM that doesn't cost a minimum of $5 per instance, and comes in a standardized format with a standardized ecosystem around it (package registries, monitoring dashboards, etc.)

mherrmann 6y ago
It's a really fat binary that adds unnecessary layers in both dev and prod. In dev, it's faster to run tests and easier to debug without Docker. And in prod, why use a vm inside a vm?
- sofixa 6y ago
  > In dev, it's easier to debug without Docker. And in prod, why use a vm inside a vm? On the contrary, it's easier to debug with Docker - it eliminates dangling system level libraries / old dependencies / cache, and everything is self-contained. If you have the problem in dev, you'll have it in prod as well. Docker is not a VM, it's basically a big wrapper around chroot and cgroups, the performance hit is minimal. The advantage is that, again, it's self-contained, so there's little risk some OS / dangling library muddies the waters ( especially in Python that's a great risk -OS level python library installations are a thing, and many a Python library depend on C libraries on the system level, which you can't manage through Python tooling). It's also idempotent ( thus making rollbacks easier) and declarative.
  - mherrmann 6y ago
    I've never encountered this "dangling libraries" problem you describe in the past 7 years of developing web apps. I suspect you are working in different, maybe more specialised, environments than me. For me, it usually is really just pretty standard libraries and dependencies.
  - antidocker 6y ago
    This is wrong. Docker is a VM on Windows at least.
    - sofixa 6y ago
      Nobody is talking about Docker on Windows or Mac for production use.
      - antidocker 6y ago
        Don't you think Mac are not used in Prod?
- treekogreen 6y ago
  Containerisation software adds so much more than just a binary with layers of indirection. Easy fine grain control of individual application memory, namespace isolation (container to container communication on a need to know basis), A-B testing, ease of on-boarding, multi-os development, CD pipelines, ease of container restarting etc.
antidocker 6y ago
I use Ansible instead Docker. It make no sense to use Docker at all. Ansible take care of all.