Portainer.io
Replies: 7 comments 5 replies
-
|
Hi @bmwhd123, Just to confirm, you have PiHole and Unbound set up and running. Then, you upgraded and re-deployed Portainer in the exact same way, just with a version upgrade, and this caused your existing PiHole and Unbound containers to stop working? The upgrade of Portainer shouldn’t modify or change your existing containers in anyway. Since PiHole is mentioning an issue communicating with Unbound, that would be a good place to start checking. Feel free to share how your Portainer is deployed as well, for context. |
Beta Was this translation helpful? Give feedback.
-
|
Yes. It’s really strange. I followed the upgrade instructions and when the new version of portainer came up, it restarted my existing pihole and unbound containers. And they initially worked as expected. However, I could no longer edit the stack as portainer now said the “stack was created outside of portainer”?So I deleted the stack and made a new one with the exact same compose script as before (the one I posted here) and while the containers and network start, unbound is no longer replying on port 5053 as specified in the compose file as has worked previously. Tonight on a whim, I tried changing the port pihole was using to call unbound to 53 instead of 5053 and it started working again. Makes no sense as the compose script is clearly mapping 53 to 5053. Todd ***@***.*** Sep 1, 2024, at 8:28 PM, Nick Wilkinson ***@***.***> wrote:
Hi @bmwhd123,
Just to confirm, you have PiHole and Unbound set up and running. Then, you upgraded and re-deployed Portainer in the exact same way, just with a version upgrade, and this caused your existing PiHole and Unbound containers to stop working? The upgrade of Portainer shouldn’t modify or change your existing containers in anyway.
Since PiHole is mentioning an issue communicating with Unbound, that would be a good place to start checking.
Feel free to share how your Portainer is deployed as well, for context.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@bmwhd123 How did you deploy Portainer? Could you share the Docker run or Docker Compose file you used? Additionally, does Pi-hole and Unbound run on the same machine as the Portainer server? What operating system are you using, and could you also share the Docker Compose files for Pi-hole and Unbound that you used? |
Beta Was this translation helpful? Give feedback.
-
|
My environment is a network consisting of:
Ubiquiti Cloud Gateway Ultra router, 2X Ubiquiti 8 port PoE switches, and 4 Ubiquiti U6 APs.
I run two Raspberry Pi 4Bs, connected to the CGU Router directly. Both are running Docker Version:
Git commit: 3ab4256
Built: Tue Aug 27 14:15:18 2024
OS/Arch: linux/arm64
Context: default
Server: Docker Engine - Community
Engine:
Version: 27.2.0
API version: 1.47 (minimum version 1.24)
Go version: go1.21.13
Git commit: 3ab5c7d
Built: Tue Aug 27 14:15:18 2024
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.7.21
GitCommit: 472731909fa34bd7bc9c087e4c27943f9835f111
runc:
Version: 1.1.13
GitCommit: v1.1.13-0-g58aa920
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Portainer 2.21.0 was deployed on the cmd line with:
docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:2.21.0
The docker compose file used to build the stack in portainer:
# Docker Compose version
version: "3-A"networks: dns_net: driver: bridge ipam: config: - subnet:172.18.0.0/16
# Define se rvices (containers to be created)
services:
# Service name:pihole
pihole:
# Name of thecontainer instance
container_name:pihole
# Image to use forthis container# Use thespecified version of the pihole image image:pihole/pihole:2024.07.0 networks: dns_net: ipv4_address:172.18.0.7
# Expose and mapports (host:container)
ports:
-"53:53/tcp" # DNS (TCP) -"53:53/udp" # DNS (UDP) -"7300:80/tcp" # Web UI HTTP
# Environmentvariables
environment: TZ:"America/Chicago" # Time Zone; Update this to your time zone WEBPASSWORD:"<password>" # Admin password for web UI; PIHOLE_DNS_:'172.18.0.8#5053'
# Mount volumesfor persistent data
volumes: -"/data/pihole/data/pihole:/etc/pihole" # Pi-hole data -"/data/pihole/data/dnsmasq:/etc/dnsmasq.d" # dnsmasq data
# Restart policyfor the container when it exits
restart:unless-stopped
# DNS servers forthis container to use
dns: - 127.0.0.1 #Localhost for internal resolution - 1.1.1.1 #Cloudflare DNS for external resolution
unbound: container_name:unbound image: mvance/unbound-rpi:latest# remember to change this if you're not using rpi networks: dns_net: ipv4_address:172.18.0.8
volumes: -"/data/pihole/data/unbound:/etc/unbound" # unbound data
ports: -"5053:53/tcp" -"5053:53/udp"
healthcheck: test:["NONE"] restart:unless-stopped
Todd Richmond
***@***.***
On Monday, September 2, 2024 at 08:26:18 PM CDT, Nick Wilkinson ***@***.***> wrote:
@bmwhd123
Could you please share more details about your environment?
How did you deploy Portainer? Could you share the Docker run or Docker Compose file you used? Additionally, does Pi-hole and Unbound run on the same machine as the Portainer server? What operating system are you using, and could you also share the Docker Compose files for Pi-hole and Unbound that you used?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Addressing the Portainer limited stack issue. If the stack was showing up as limited when you re-deployed Portainer, is it using the same volume? When you first deployed Portainer, did you create the volume before deploying it? If you didn’t create the volume first, Docker would have created an anonymous volume. This means that when you re-deployed Portainer, it wouldn’t have used the same volume, resulting in no knowledge of the containers previously deployed via Portainer. See our docs where we mention making the named volume first - https://docs.portainer.io/start/install-ce/server/docker/linux#deployment |
Beta Was this translation helpful? Give feedback.
-
|
Ah. That makes sense. Any idea why the port mapping seems to be either broken or at least different since the upgrade?Todd ***@***.*** Sep 4, 2024, at 9:36 PM, Nick Wilkinson ***@***.***> wrote:
Addressing the Portainer limited stack issue.
If the stack was showing up as limited when you re-deployed Portainer, is it using the same volume? When you first deployed Portainer, did you create the volume before deploying it? If you didn’t create the volume first, Docker would have created an anonymous volume. This means that when you re-deployed Portainer, it wouldn’t have used the same volume, resulting in no knowledge of the containers previously deployed via Portainer.
See our docs where we mention making the named volume first - https://docs.portainer.io/start/install-ce/server/docker/linux#deployment
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Upgrading Portainer should not impact how your containers are deployed and run in anyway. What changes can you see besides the services not working? |
Beta Was this translation helpful? Give feedback.
-
|
It’s very simple. This compose file below worked before the upgrade to place pihole in a container on a user defined bridge network and an IP address of 172.18.0.7 on that network. It then created a second container with unbound and an IP of 172.18.0.8Prior to the upgrade, pihole could forward DNS requests to unbound on 172.18.0.8:5053 and now it can’t. The containers and applications are up and running. # Docker Compose versionversion: "3-A"networks: dns_net: driver: bridge ipam: config: - subnet: 172.18.0.0/16 # Define services (containers to be created)services: # Service name: pihole pihole: # Name of the container instance container_name: pihole # Image to use for this container # Use the specified version of the pihole image image: pihole/pihole:2024.07.0 networks: dns_net: ipv4_address: 172.18.0.7 # Expose and map ports (host:container) ports: - "53:53/tcp" # DNS (TCP) - "53:53/udp" # DNS (UDP) - "7300:80/tcp" # Web UI HTTP # Environment variables environment: TZ: "America/Chicago" # Time Zone; Update this to your time zone WEBPASSWORD: "428SCJconv!" # Admin password for web UI; PIHOLE_DNS_: '172.18.0.8#53' # Mount volumes for persistent data volumes: - "/data/pihole/data/pihole:/etc/pihole" # Pi-hole data - "/data/pihole/data/dnsmasq:/etc/dnsmasq.d" # dnsmasq data # Restart policy for the container when it exits restart: unless-stopped # DNS servers for this container to use dns: - 127.0.0.1 # Localhost for internal resolution - 1.1.1.1 # Cloudflare DNS for external resolution unbound: container_name: unbound image: mvance/unbound-rpi:latest # remember to change this if you're not using rpi networks: dns_net: ipv4_address: 172.18.0.8 volumes: - "/data/pihole/data/unbound:/etc/unbound" # unbound data ports: - "5053:53/tcp" - "5053:53/udp" healthcheck: test: ["NONE"] restart: unless-stoppedTodd ***@***.*** Sep 5, 2024, at 9:24 PM, Nick Wilkinson ***@***.***> wrote:
Upgrading Portainer should not impact how your containers are deployed and run in anyway. What changes can you see besides the services not working?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
You were accessing it using the IP 172.x.x.x? That’s the Docker network address for the container. The service should be accessed via the host’s IP address, followed by the port. For example, my Authentik container’s Docker IP is 172.26.0.2, but I access it on 192.168.68.113:9000. |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate your response and help with this. I am accessing Pi-hole via the host address (192.168.254.10 in my case). No problems accessing pihole that way. The problem is pihole is not able to access unbound within docker on the bridge network they both belong to. Again, the setup as deployed in the docker compose file has been working flawlessly for me and thousands of others (it’s a common deployment recommended on several YouTube docker channels). The only thing that changed was upgrading portainer. Todd ***@***.*** Sep 9, 2024, at 5:45 PM, Nick Wilkinson ***@***.***> wrote:
You were accessing it using the IP 172.x.x.x? That’s the Docker network address for the container. The service should be accessed via the host’s IP address, followed by the port.
For example, my Authentik container’s Docker IP is 172.26.0.2, but I access it on 192.168.68.113:9000.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
My understanding is if you use separate ip addresses in docker, each container is its own environment. You do not need to translate port 53. -p 53:53 should work. Translation is used when two apps that use the same ports are in the same environment. (single ip address). Then you use the ip address to talk to pi-hole and pi-hole forwards to local host (127.0.0.1:5053) to talk to unbound. |
Beta Was this translation helpful? Give feedback.
-
|
@DeanRM - All I know is that following the upgrade, the way unbound and pihole were working previously stopped working. I didn't change anything in the above docker deploy scripts, just updated portainer. They work now because I changed the original 5353 to 53. Perhaps the argument should be that it is now working correctly and the way the original developer of this deployment script had it before was due to something not working as it should in the older versions of portainer. |
Beta Was this translation helpful? Give feedback.
-
Ask a Question!
I updated to 2.21.0 on my Raspberry Pi 4s that have been happily running pihole and unbound as recursive DNS servers on my home network. Since the upgrade and re-deploy of the exact same stack and compose yaml, pihole doesn't get a reply to any query from unbound. Unbound is up and running in its container and responds to dig cnn.com @172.18.0.8 which is the IP assigned. But dig cnn.com no longer works and pihole logs show that unbound is not responding. No other changes anywhere except the portainer upgrade.
Beta Was this translation helpful? Give feedback.
All reactions