4 ms·
In theory yes. In practice, no. While immutable assets (I imagine you mean container or VM images) are easy to audit, they don't solve all problems. How do you
by acatton 5y ago
In theory yes. In practice, no.
While immutable assets (I imagine you mean container or VM images) are easy to audit, they don't solve all problems. How do you spin up a database and add database-users over time? Do you just just rebuild your container-VM from scratch and loose your data? With Ansible, I can just enforce a new database user as I run a new service against this database.
Also, how do you spin up the host which runs your static VM and container images?
There are tons of problems which can't be solved by immutable artifacts. Yes, immutable containers/VMs for application code. But it doesn't work well when dealing with databases, caching systems and object storages. People deploying Postgres, Redis and/or Minio on k8s or openshift are facing a totally different set of problems which are already solved by mutable state.
- cnity 5y agoIn every environment I've worked in, the content of a DB is not considered a build artifact. The container that actually runs e.g. PostgreSQL is, but it will use volume mounts. I think what OP is referring to is the fact that the container itself is stateless. If you (to continue the PostgreSQL example) needed to upgrade the version of a dependency in the container, you'd publish a new artifact and use the same volume mount, performing a data migration as you go. Rather than performing upgrades to an already running instance. ("containers are cattle, not pets").
- heleninboodler 5y agoI think the point of GP is that you really can't completely take the position that "mutable state is an anti-pattern" since that volume you've mounted is itself mutable state.
- acatton 5y agoGP here, exactly. Also how does one manages these mutable states? And these volumes? Most of these hosts are managed with Ansible, which the Top-Poster was criticising so heavily as "an anti-pattern".
- cnity 5y agoI was referring to your comment about having to recreate build images every time you want to insert data (users) into the DB. I don't see how _any_ deployment solution could be stateless, if you want a database. I might be misinterpreting you though.
- acatton 5y ago> If you (to continue the PostgreSQL example) needed to upgrade the version of a dependency in the container, you'd publish a new artifact and use the same volume mount, performing a data migration as you go. You're just proving the point I made: "People deploying Postgres, Redis and/or Minio on k8s or openshift are facing a totally different set of problems which are already solved by mutable state." When one does what you describe, they now have to deal with downtime, etc...
- cnity 5y agoI think we're talking past each other because containerization solutions aren't designed to solve the problem you're talking about. It's just not the target problem domain. That isn't a shortcoming of containerization. If you need zero downtime, there are ways to make that work using additional tooling. I think we may actually agree on that point.