parent
c524927bb1
commit
429a1d685d
|
@ -90,12 +90,13 @@ The standard pi-hole customization abilities apply to this docker, but with dock
|
|||
|
||||
**If you try to use `pi-hole -up` it will fail.** For those unfamilar, the docker way to ugprade is:
|
||||
|
||||
* Throw away your container: `docker rm -f pihole`
|
||||
1. Download the latest version of the image: `docker pull diginc/pi-hole`
|
||||
2. Throw away your container: `docker rm -f pihole`
|
||||
* **Warning** When removing your pihole container you may be stuck without DNS until step 3 - **docker pull** before you **docker rm -f** to avoid DNS inturruption or always have a fallback DNS server configured in DHCP configured to avoid this problem all together.
|
||||
* If you care about your data (logs/customizations), make sure you have it volume mapped or it will be deleted in this step
|
||||
* Download the latest version of the image: `docker pull diginc/pi-hole`
|
||||
* Start your container with the newer base image: `docker run ... diginc/pi-hole` (whatever your original run command was)
|
||||
3. Start your container with the newer base image: `docker run ... diginc/pi-hole` (whatever your original run command was)
|
||||
|
||||
Why is this style of upgrading good? A couple reasons: Everyone is starting from the same base image which has been tested to know it works. No worrying about upgrading from A to B, B to C, or A to C is required when rolling out updates, reducing complexity.
|
||||
Why is this style of upgrading good? A couple reasons: Everyone is starting from the same base image which has been tested to know it works. No worrying about upgrading from A to B, B to C, or A to C is required when rolling out updates, it reducing complexity, and simply allows a 'fresh start' every time while preserving customizations with volumes.
|
||||
|
||||
### Volumes customizations
|
||||
|
||||
|
|
Loading…
Reference in New Issue