compose-spec VS docker-pi-hole

Specification: https://compose-spec.io

https://github.com/compose-spec/compose-spec/blob/master/spe...

There are a number of incorrect statements in this post.

1) One should neither be using the "latest" nor just the "version" tag as the version can still vary depending on when it is pulled.

Instead, one should use a combination of version + hash, say alpine:3.18.2@sha256:82d1e9d7ed48a7523bdebc18cf6290bdb97b82302a8a9c27d4fe885949ea94d1 for reproducibility reasons. This provides for human readable versions as well as the specific hash.

2) Next, afaik, Compose has removed the need for version tags. All of the compose.yml files that I now use do not specify versions.

See https://github.com/compose-spec/compose-spec/blob/master/04-...

Docker Compose v2 specifications provide a useful Secrets feature which may also be used for standalone Compose Application Stacks and not just in Docker Swarm mode. With Docker Secrets the environment variables that contain credentials for other subsystems are mounted into the Telegraf Container as files. These secret files are read through the Docker Secret Store plugin and passed to the respective plugins in a relatively safe manner. By using the Docker Secret Store Plugin, one can also avoid credentials that were previously visible via environment variables, to be now hidden behind runtime secret files within the container. Standard Method with Environment Variables As an example, it is possible to pass the credentials to a plugin via the environment variable placeholder in a telegraf configuration file where the credentials for a plugin exist in a .env file (e.g. MQTT input Plugin)

also the docker-compose.yml file is very picky about what you have in it and where. Please read this so you know how to format it https://github.com/compose-spec/compose-spec/blob/master/spec.md

As part my quadlet helper tool, podlet, I'm adding functionality to convert compose files into k8s yaml to use with quadlet as an alternative to creating a bunch of separate quadlet files, which I've also added functionality for. So I would like to be able to transform the options on compose volumes into k8s yaml. For example, using the volume.podman.io/driver annotation to change the volume driver for a specific volume if possible.

If you find this helpful feature, please leave your feedback and suggestions here.

The compose spec will give what you need. https://github.com/compose-spec/compose-spec/blob/master/spec.md

Indeed, as per the compose-spec a lot of what was version specific is going away

Hello everyone, I just made a tool to visualize compose files, and all the parsing rules follow the [compose-spec](https://github.com/compose-spec/compose-spec/blob/master/spec.md). I hope this tool will help you :D

Yesterday I deployed the official pi hole docker container on my raspberry pi 3 and set a custom DNS address on my phone addressing to the pi.

#pihole   pihole:     container_name: pihole     image: pihole/pihole:latest     ports:       - target: 53         published: 53         protocol: tcp         mode: host       - target: 53         published: 53         protocol: udp         mode: host       - "67:67/udp"       - "8070:80/tcp"       - "8073:443/tcp"     environment:       TZ: 'America/Indianapolis'       WEBPASSWORD: #'TEMP_PASSWORD' #'set a secure password here or it will be random'       WEBPASSWORD_FILE: '/etc/pihole/adminpw.txt'     # Volumes store your data between container upgrades     volumes:       - '~/pihole/etc-pihole:/etc/pihole'       - '~/pihole/etc-dnsmasq.d:/etc/dnsmasq.d'     #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities     cap_add:       - NET_ADMIN # Recommended but not required (DHCP needs NET_ADMIN)     #network_mode: host     restart: unless-stopped     #UPTIME KUMA   uptime_kuma:     image: louislam/uptime-kuma:1     container_name: uptime-kuma     volumes:      - uptime-kuma:/app/data     ports:      - 8060:3001     restart: always

version: "3" # More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/ networks: dns_net: driver: bridge ipam: config: - subnet: 10.2.0.0/24 services: pihole: depends_on: [unbound] container_name: pihole image: pihole/pihole:latest hostname: pihole networks: dns_net: ipv4_address: 10.2.0.100 ports: - "5335:53/tcp" - "5335:53/udp" - "7000:80/tcp" environment: TZ: ${TZ} WEBPASSWORD: ${PWD} FTLCONF_LOCAL_IPV4: ${HOST_IP} # Set to server's LAN IP, used by web block modes. PIHOLE_DNS_: 10.2.0.200 # Upstream DNS server(s) for Pi-hole to forward queries to, separated by a semicolon DNSMASQ_LISTENING: all # "Listen on all interfaces, permit all origins" # Volumes store your data between container upgrades volumes: - /var/lib/docker/volumes/pihole/etc-pihole:/etc/pihole - /var/lib/docker/volumes/pihole/etc-dnsmasq.d:/etc/dnsmasq.d healthcheck: disable: true restart: unless-stopped unbound: # https://github.com/MatthewVance/unbound-docker container_name: unbound image: mvance/unbound:latest hostname: unbound networks: dns_net: ipv4_address: 10.2.0.200 ports: - "${HOST_IP}:53:53/udp" - "${HOST_IP}:53:53/tcp" healthcheck: disable: true restart: unless-stopped

services: pihole: container_name: pihole image: pihole/pihole:latest hostname: pihole # Container hostname (optional) domainname: mynetwork.local # Container domain (optional) mac_address: f7:55:63:b0:68:83 # Random MAC address (optional) networks: virtualnet: # Name of macvlan ipv4_address: 192.168.100.249 # Desired IP for pihole dns: - 127.0.0.1 - 1.1.1.1 ports: - "53:53/tcp" - "53:53/udp" - "67:67/udp" - "80:80/tcp" - "443:443/tcp" volumes: - ./pihole-configs/:/etc/pihole/ - ./dnsmasq.d-configs/:/etc/dnsmasq.d/ # DNSMASQ_USER # https://github.com/pi-hole/docker-pi-hole/issues/963 # https://github.com/pi-hole/docker-pi-hole/blob/master/README.md#upgrade-notes environment: FTLCONF_LOCAL_IPV4: 10.59.0.6 # Desired IP for pihole VIRTUAL_HOST: pihole.mynetwork.local DNSMASQ_USER: root PIHOLE_DNS_: 1.1.1.1;1.0.0.1;2606:4700:4700::1111;2606:4700:4700::1001 restart: unless-stopped # Set container to always restart

You could have a look at docker and try to run a more recent Ubuntu image on the Nano https://github.com/pi-hole/docker-pi-hole

My advice would be either use the docker-pi-hole documentation/quick start, or contact the content creator.