Roll the daemon with backend deploys in the Swarm stack #40

Merged
admin_emi merged 1 commit from fix/stack-daemon-roll into dev 2026-07-24 18:59:48 +00:00

View file

@ -166,13 +166,19 @@ else
echo "==> Rolling web + worker + lake to $BACKEND_IMAGE" echo "==> Rolling web + worker + lake to $BACKEND_IMAGE"
docker service update --with-registry-auth --detach=false --image "$BACKEND_IMAGE" "${STACK_NAME}_web" docker service update --with-registry-auth --detach=false --image "$BACKEND_IMAGE" "${STACK_NAME}_web"
docker service update --with-registry-auth --detach=false --image "$BACKEND_IMAGE" "${STACK_NAME}_worker" docker service update --with-registry-auth --detach=false --image "$BACKEND_IMAGE" "${STACK_NAME}_worker"
# lake ships in the same image; a stack file predating it has no service # lake and daemon ship in the same image; a stack file predating either
# yet — the next SERVICE=all stack deploy creates it, so don't fail here. # has no service yet — the next SERVICE=all stack deploy creates it, so
if docker service inspect "${STACK_NAME}_lake" >/dev/null 2>&1; then # don't fail here. The daemon especially must roll with web: they share
docker service update --with-registry-auth --detach=false --image "$BACKEND_IMAGE" "${STACK_NAME}_lake" # the /internal/* contract, and a version skew between them is exactly
# what pinning one BACKEND_IMAGE_TAG exists to prevent (seen live: the
# first post-creation backend roll left the daemon a release behind).
for extra in lake daemon; do
if docker service inspect "${STACK_NAME}_${extra}" >/dev/null 2>&1; then
docker service update --with-registry-auth --detach=false --image "$BACKEND_IMAGE" "${STACK_NAME}_${extra}"
else else
echo " (no ${STACK_NAME}_lake service yet; created on the next full stack deploy)" echo " (no ${STACK_NAME}_${extra} service yet; created on the next full stack deploy)"
fi fi
done
;; ;;
frontend) frontend)
echo "==> Rolling frontend to $FRONTEND_IMAGE" echo "==> Rolling frontend to $FRONTEND_IMAGE"