Updating Big Bear Docker Images for Pi-hole V6: When Simple Upgrades Aren't So Simple

BigBearBlog
1

Hey everyone,

I wanted to share a recent experience that reminded me how even seemingly straightforward software updates can turn into interesting technical challenges. It all started with a friendly ping from a BigBearCommunity member letting me know that Pi-hole V6 had been released and it was time to update our big-bear-docker-images for Pi-hole and Unbound.

The Initial Attempt: Just Change the Version Number, Right?

My first thought was “Great! This should be simple.” Like many maintainers, I have a routine for these updates:

  1. Bump the version number
  2. Let the CI pipeline do its thing
  3. Merge and release

So I made the version change and pushed it to the CI pipeline, expecting a smooth build. Instead, I was greeted with failure messages. Something had changed significantly in Pi-hole V6, and my existing Dockerfile wasn’t going to cut it anymore.

Diving Into the Changes

After investigating, I discovered two major changes in the official Pi-hole image:

  1. They’ve moved away from Debian Linux as the base image
  2. They’ve removed the s6-overlay that was previously used for service management

These changes weren’t just minor tweaks - they represented a fundamental shift in how the Pi-hole container was structured. My existing Dockerfile, which had worked fine for previous versions, was now completely incompatible.

Rethinking the Approach

This meant I needed to rethink my entire Docker image strategy. The big-bear-docker-images project aims to provide optimized containers for the community, and now I had some decisions to make:

  • Should I follow Pi-hole’s lead and move away from Debian? (Of course)
  • What service management solution should I use if not s6-overlay?
  • How could I maintain compatibility for users upgrading from previous versions?

The Rebuild Process

After considering the options, I decided to:

  1. Study the new official Pi-hole image to understand their design decisions
  2. Redesign our Dockerfile to align with the upstream changes while maintaining our specific optimizations
  3. Test extensively to ensure the Unbound DNS integration still worked flawlessly
  4. Document the changes for our users to ensure smooth transitions

Lessons Learned

This experience reinforced some important lessons in maintaining community software:

  1. Never assume updates will be simple - Even minor version bumps can include architectural changes
  2. Keep an eye on upstream projects - Understanding their roadmap can help you prepare for changes
  3. Build flexible CI/CD pipelines - They should not just test but also provide meaningful feedback when things fail
  4. Value community communication - That ping from a community member gave me a heads-up that saved our users from potential issues

What’s Next

The updated images for Pi-hole V6 with Unbound are now available in our repository. If you’re using our Docker images, you can pull the latest version and enjoy the benefits of Pi-hole V6.

I’d love to hear your experiences with the update. Have you encountered any issues or noticed any improvements? Let me know in the comments!

P.S. Huge thanks to the BigBearCommunity member who alerted me to this update. Community collaboration makes projects like this possible!

Avaliable on BigBearCasaOS today:

https://hub.docker.com/r/bigbeartechworld/big-bear-pihole-unbound

2 Likes
2

Looks like this documentation needs also an update

3

This has been updated. Thank you for letting me know.