Upgrade deployment image with rancher 2.0

Is there a way, updating via rancher API v3, to keep previous configurations and only updating the docker image?

PUT <links.self of the workload> {"image": "new/image:label"}

1 Like

Thanks. Just one question yet. How I can repull image from registry, via api v3?

Hey, I tried the above but I get an error. Iā€™m a rancher newbie though so might be doing something obviously wrongā€¦ any pointers welcome :slight_smile:

curl -X PUT \
  -u "$USERNAME:$SECRET" \
  -H 'Content-Type: application/json' \
  -d "{\"image\": \"$IMAGE\"}" \
  $ENDPOINT/project/c-g98kw:project-pl4nj/workloads/deployment:my-app:my-app-api

returns

{
    "actions": {},
    "baseType": "error",
    "code": "Invalid",
    "links": {},
    "message": "Deployment.apps \"my-app-api\" is invalid: spec.template.spec.containers: Required value",
    "status": 422,
    "type": "error"
}

Which is clear enough. So I just copied a containers request from the API viewer, and that works perfectly:

curl -X PUT \
  -u "$USERNAME:$SECRET" \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d "{\"containers\":[{\"allowPrivilegeEscalation\":false,\"image\":\"$IMAGE\",\"imagePullPolicy\":\"Always\",\"initContainer\":false,\"name\":\"my-app-api\",\"privileged\":false,\"readOnly\":false,\"resources\":{\"type\":\"/v3/project/schemas/resourceRequirements\"},\"restartCount\":0,\"runAsNonRoot\":false,\"stdin\":true,\"stdinOnce\":false,\"terminationMessagePath\":\"/dev/termination-log\",\"terminationMessagePolicy\":\"File\",\"tty\":true,\"type\":\"/v3/project/schemas/container\"}]}" \
   "$ENDPOINT/project/c-g98kw:project-pl4nj/workloads/deployment:my-app:my-app-api"

The only issue though - I guess since containers is an array - is that I need to copy over the entire object over else I lose the non-default values.

So, just wanted to check if this is the correct / only way to do this. @vincent, your post above hints that maybe this can be done in a less verbose way and without affecting any other values.

Iā€™m happy to also add some info on the API approach to https://rancher.com/docs/rancher/v2.x/en/tasks/workloads/upgrade-workloads/ if Iā€™m in the right direction here.

1 Like

Did you ever figure something out here? Sending the entire array along every time doesnā€™t seem like the best of approachesā€¦

Any luck? @ gadicc what did you end up doing?

What I ended up doing to ā€œsolveā€ this, was to write a little python script that i run as the last step of my deployment with Travis CI. When the image has been pushed to Docker Hub it will fetch the container array using the API, toggle between removing and adding :latest to force a ā€œchangeā€ of the config while still getting latest and then send the container array back to Rancher.
This way i get the automatic upgrade without having to hard code the container array.

I feel dirty and gross, but i works for what i need so yeahā€¦ ĀÆ_(惄)_/ĀÆ
I hope thereā€™s a better way to do this somewhere, and i just donā€™t know about it (yet).

Oh, in my script above $IMAGE includes the sha256 of the latest image which I get form docker after building / pushing:

# Get latest iamge name, e.g. gadicc/my-app-api@sha256:12102c0....4daab8f36c
IMAGE=`docker inspect --format='{{index .RepoDigests 0}}' gadicc/my-app-api`

Yeah, Iā€™m also not happy about hard coding the arrayā€¦ also hoping thereā€™s a better way coming, would like to avoid the back-and-forth requests too.

@vincent, ping if thereā€™s a better way to do this, thanks :slight_smile:

@Kostecki yea I ended up doing something similar - an AWS Lambda function that is triggered by Docker Hub webhook, and the same logic - a GET request to get the current config (array), then just re-submit it back without any changes to force a service upgrade

1 Like

I ended up using kubectl e.g.

kubectl --namespace=project1 set image deployment/project-1-api api=image:new-version
1 Like

Can we please get an update action like in the v2 api?
We are in the middle of migrating from Rancher 1.6 to 2 and this gives me a real headache :confused:
Normaly our CI Pipeline just spits out new image:latest builds, and i simply want to update to the new latest version.
Now I have configured our Pipeline to add a timestamp like latest-2019-05-10T19-33-59 and then put the whole new containers list which in itself is way too much in my eyes.
And now my container is failing because with the put the imagePullSecrets are getting wiped and Rancher canā€™t pull the container from the repo.
This is way too much work for simply pulling the current latest version.
Regards