17 ms·
In 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 us
by cnity 5y ago
In 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.