Missing how to re-run your Acornfile?
I don't know if I've missed it in the docs, but I can't figure this out.
Let's say that I've deployed an app, it's using MySQL with a volume, and all is well.
Then I want to add Memcached to my app. So I add the required sections in my Acornfile, and I attempt to run:
$ acorn run -n fc-dotcom-dev .
I would expect this to update the running app, with the new container included, binding the DNS and everything. However, what happens when I try is:
...
=> => pushing layers 0.0s
=> => pushing manifest for 127.0.0.1:5000/acorn/acorn:latest@sha256:4eed5129181b3bf4ea8d566fbebdeee1f84c1a655eb603a619e7c5434136a759 0.0s
Error: appinstances.internal.acorn.io "fc-dotcom-dev" already exists
I got around this just by doing acorn rm fc-dotcom-dev and re-running it, but that doesn't feel like the right solution and when running in production, I can't just remove my production database and deploy from scratch.
I understand you can update the running image of an app (although the example given doesn't specify which container(s) it should update) using https://docs.acorn.io/running/upgrades but that page doesn't seem to cover the case I'm looking at.
Would appreciate any help.
As a side/secondary question but highly related to this. Assuming it's a case of "Jeffries! You're being dim, the command is X and documented at Y", how in that case can I stop a secret from having it's value overwritten after I've created it the first time. E.g. create the first time with a template value, replace in cluster with the real secret value, then when I re-apply my Acornfile I don't want to go back to the template value. A use case is to think of an external API key I guess (or the Rails 7 credentials decryption key, which is my actual thing).
although the example given doesn't specify which container(s) it should update
It will update the ENTIRE acorn app. Think of your acornfile as the "desired state" in this case. Whatever containers are in the acornfile at the time of running update is what acorn will make reality in the cluster. So, to your original question, I think you want acorn update ...
To your second question, I am not sure I entirely follow. Can you describe (prefereably with commands) how you are replacing the template value with a the real secret value in cluster? When you say template value, do you mean acorn term for secret templates (https://docs.acorn.io/authoring/secrets#consuming-secrets-in-templates), or do you mean something else?
Ok, so if I wanted to add a container to a running app, I would do “acorn update -n appname newcontainer memcached:1.2.3” and it will also update everything, not just set the image for that container.
that’s what I’m not following, if I update the acornfile, how do I re apply it? Just “acorn update -n appname” with no container?
regarding secret, I was just going to edit it directly between runs. My acornfile is check in to source control, but I don’t want to check in my (for example) stripe api keys. So I wanted to create them with one value, manually edit in the correct values on the cluster directly, but then be able to re-apply the acornfile in the future without losing those values.
Sorry for delayed response!
You want:
acorn update --image memcached:1.2.3 appname
(where the --image flag specifies the new acorn image)
regarding secret, I was just going to edit it directly between runs. My acornfile is check in to source control, but I don’t want to check in my (for example) stripe api keys. So I wanted to create them with one value, manually edit in the correct values on the cluster directly, but then be able to re-apply the acornfile in the future without losing those values.
Yeah, so you want to "bind" the secret. This bit of the docs explains it: https://docs.acorn.io/running/args-and-secrets#binding-secrets
If you bind a secret like that, when it comes time to upgrade, you can just do
acorn update --image memcached:1.2.3 appname
and the secret you created will stay bound to app. You don't need to rebind it on the upgrade.
Sorry for delayed response!
You want:
acorn update --image memcached:1.2.3 appname(where the --image flag specifies the new acorn image)
Ohhhh it’s specifying the Acorn image, not the container’s image… gotcha…
👍 let me know if we're good to close this issue or not
Good for me, thanks for the answers.
Sorry @cjellick , I'm back and this isn't working for me still. I've anonymised some stuff below and trimmed some output in the build, but nothing to do with responses or errors (no errors anyway).
$ acorn build -p linux/amd64 -t foundercatalyst/myimage:3 .
...
=> => pushing layers 0.0s
=> => pushing manifest for 127.0.0.1:5000/acorn/acorn:latest@sha256:20b140626013fbc351a78...6efb 0.0s
f7218b0f6adae8fe8d...a4b1e
$ acorn push docker.io/foundercatalyst/myimage:3
[859756362/859756362] ███████████████████████████████████████████████ 100% | 0s
$ acorn update --image docker.io/foundercatalyst/myimage:3 white-dust
white-dust
$ acorn apps
NAME IMAGE HEALTHY UP-TO-DATE CREATED ENDPOINTS MESSAGE
white-dust foundercatalyst/myimage:1 3 3 20m ago http://web.white-dust.00000.alpha.on-acorn.io => web:3000 [jobs: rails-migrate: failed []]
$
Why does "white-dust" never get upgraded to myimage:3?
Can you do acorn images and show me the output? Specifically, I want to see myimage:1 and myimage:3
$ acorn images
REPOSITORY TAG IMAGE-ID
foundercatalyst/myimage 1 f7218b0f6ada
foundercatalyst/myimage 2 f7218b0f6ada
foundercatalyst/myimage 3 f7218b0f6ada
OK, so, because all the image tags actaully point to the same image-id, it isn't changing anything. I'd say this is bug, but a relatelively low priority one because in all practical usecases, if you are trying to update the image, it isn't going to be the same image ID that you are currently on.
Closing due to age. Please reopen if there's more to discuss here.