update.sh

[grahamwoan]

Suggest changing the order of events in this as below, to perform the pull while Pi-hole is still up. Otherwise you get DNS errors.

#!/bin/bash

echo "Downloading latest images from docker hub ... this can take a long time"
docker-compose pull

echo "Stopping containers"
docker-compose down

echo "Building images if needed"
docker-compose build

echo "Starting stack up again"
docker-compose up -d

[Schnuecks]

Hi, there's is no need to put down the stack. Just pull and up, if newer images available it's getting recreated immediately.

[Paraphraser]

That's true - for most images. The sequence:

$ cd ~/IOTstack
$ docker-compose pull
$ docker-compose up -d
$ docker system prune

will update anything that doesn't get built with a Dockerfile.

Containers built using Dockerfiles need extra work. Using NodeRed as an example, to update NodeRed you need:

$ cd ~/IOTstack
$ docker-compose build --no-cache --pull nodered
$ docker-compose up -d nodered
$ docker system prune

The --no-cache forces the rebuild of the local image (iotstack_nodered) then, when the FROM nodered/node-red in the Dockerfile is processed, the --pull forces a check to see if a later version of the base image (nodered/node-red) is available on DockerHub, pulling down an update if its available.

If you just want to rebuild the local nodered image after a change to the Dockerfile, you can get away with:

$ cd ~/IOTstack
$ docker-compose up --build -d nodered
$ docker system prune

As @Schnuecks said, there is no need to "down" the stack for any of this. All "pull" and "build" operations occur while the old containers are still running, with a new-for-old swaps performed at the last moment. There's very little downtime.

---

As to PiHole, I always use the "pull" and "up" sequence. I've never had this cause any DNS errors.

I find myself wondering whether the errors you're seeing could be explained by the large number of problems in the latest version of PiHole (5.2.1).

See:

• docker-pi-hole/issues/718 and
• docker-pi-hole/issues/720.

Basically, v5.2.1 blows away much of any configuration you entered in prior versions via the GUI. It's destructive too in that you can't just revert to version 5.2 and pick up where you left off. You also have to restore your previous ./volumes/pihole.

I struck the 5.2.1 problems with "conditional forwarding" but the underlying bug seems to affect a lot more than that.

In my case, I pinned to v5.2 in docker-compose.yml on my "live" RPi:

  pihole:
    container_name: pihole
    image: pihole/pihole:v5.2
		…

On my "test" RPi, I let it update to v5.2.1 and added extra keys to the PiHole environment file:

REV_SERVER=true
REV_SERVER_DOMAIN=mydomain.com
REV_SERVER_TARGET=192.168.132.65
REV_SERVER_CIDR=192.168.132.0/24

In words, anything in mydomain.com or in 132.168.192.in-addr.arpa gets sent to my local upstream DNS 192.168.132.65.

Environment keys definitely work so I'll probably adopt those for everything when I get around to it. Kinda makes you wonder why the configuration GUI exists...

[grahamwoan]

Thanks for replying -- I'm quite new to docker and still experimenting, but IOTstack has been invaluable for that. Good to know that pull and up is usually all that's needed. NodeRed instructions noted (though it did seem to pull things for NodeRed and rebuild when I used the reordered scripts/update.sh )

I'm running PiHole v5.2.1, and I had set conditional forwarding and changed the upstream server from the default. Neither has survived the update process so I agree it looks broken. I guess update.sh should still be modified as if will fail if PiHole is in the stack.

[theDiverDK]

Why has this script been removed from the repo? (at least i can't find it)