has anyone had trouble with

@pulumi/docker

frequently replacing containers even though you didn't change anything. i think the stack state is becoming unsynchronized. maybe it's because i'm using OrbStack?

It's becoming accepted that @pulumi/docker is no longer the way to go. Use @pulumi/docker-build

@little-cartoon-10569 isn't that only for building images?

What are you using @pulumi/docker for?

creating containers locally on my macOS machine, where I have orbstack installed

What did you mean by "replacing containers"? If there is no code to build the image, then what is being replaced?

Pulumi reports the logOpts, memorySwap, and networkMode as having changed, even though I'm 100% sure nothing changed on my end. To me, this is evidence that Pulumi's state drifted from what actually exists in Docker

Ah. I see. Is it possible that those are defaulted in your container resource? Or are you explicitly providing them?

it's happening on every

pulumi up

run. no refreshes in between. every

docker.Container

replaces itself, citing logOpts/memorySwap/networkMode as the culprit

Are you setting those values in your code? It may be that they're being ignored by your docker engine.

none of them are set by me ever

Then I suggest adding them. The engine / server may be doing something different to what the provider is expecting.

good suggestion. i had the same idea, but it's wee bit annoying, so i was hoping it was a known issue. but such is life as a developer 🙂

Yep. More than once in situations a bit like yours, I've had to refresh a particular resource, export the state, and add all the properties in that resource's state to my code. I gave up even caring what the offending property was, I just copied them all.

so i did as you suggested, yet the issue remains. though the culprit is different now. [diff: ~image] any idea what that means? in one case, it's being reported for a container using 'redis:7.4.2' as its image property.

Is it reporting a different image but not redeploying anything? If so, that sort of thing is caused by the image property being generated in a way that means Pulumi can't tell what the value is during the preview. Maybe an apply() with some logic in it, or something. This can be safely ignored; it may also be possible to change the logic to prevent this, but that's not always possible. If it is correctly detecting a different image, you might check the history for the image. Has the same tag been overwritten by the image publisher? It may be that the provider checks hashes and has detect a valid change in the image, and is correctly trying to redeploy.

It appears to be happening with every docker container I'm deploying. All of them have images with fixed versions.

It kinda makes sense that the memorySwap and similar values aren't being kept constant. A container isn't really a deployable or maintainable thing at all: that's what the image is. As I understand it, a container is a running (or stopped...) instance of an image. And it changes all the time: the values in its memory change, the values on its disc change, and its operating parameters, as controlled by the runtime service / engine, change. Perhaps this is just the way it works.

Seems to me that anything you can create, read, update, and destroy is valid as a Pulumi resource. I mean, the

@pulumi/docker

package has a Container resource, so that reinforces the idea that my intent is logical.

It's possible that a bug is causing this,

Absolutely, and in theory, if Pulumi is the only actor managing a resource, anything with a lifecycle can be managed by Pulumi.