• 0 Posts
  • 10 Comments
Joined 1 year ago
cake
Cake day: June 9th, 2023

help-circle
  • Not for PiHole but I was testing this recently with traefik. This has a bunch of traefik stuff in there (I’m on mobile so it’s too hard to edit it) but hopefully you see how the networks work

    # Testing macvlan setup for traefik
    # Will only work on linux because of macvlan network
    
    version: '3'
    
    services:
      traefik-whoami:
        image: traefik/whoami
        container_name: traefik_whoami
        networks:
          - bridge_network
        labels:
          - "traefik.enable=true"
          - "traefik.http.routers.whoami.rule=Host(`whoami.test`)"
          - "traefik.http.routers.whoami.entrypoints=http"
      
      traefik-reverse-proxy:
        image: traefik:v2.10
        container_name: traefik_reverse_proxy
        command:
          - "--api.insecure=true"  # Enable the API dashboard (insecure for testing)
          - "--providers.docker=true"  # Enable Docker provider
          - "--providers.docker.exposedbydefault=false"  # Disable exposing all containers by default
          - "--entrypoints.http.address=:80"  # HTTP entrypoint
          - "--entrypoints.http.forwardedheaders.insecure=true"  # Insecure forwarding (for testing)
          - "--providers.docker.network=bridge_network"  # Use bridge network for traefik discovery
        ports:
          - "1180:80"  # Expose HTTP entrypoint
          - "12345:8080"  # Expose Traefik dashboard
        networks:
          bridge_network: {}
          macvlan_network:
            ipv4_address: 192.168.1.69
        volumes:
          # TODO: Use docker.sock proxy instead of mounting directly
          # https://github.com/Tecnativa/docker-socket-proxy
          - /var/run/docker.sock:/var/run/docker.sock:ro
        labels:
          - "traefik.enable=true"
          - "traefik.http.routers.reverse-proxy.rule=Host(`traefik.test`)"
          - "traefik.http.routers.reverse-proxy.entrypoints=http"
    
    networks:
      bridge_network:
        driver: bridge
    
      macvlan_network:
        driver: macvlan
        driver_opts:
          parent: eth0
        ipam:
          config:
            - subnet: 192.168.1.0/24
              gateway: 192.168.1.1
              ip_range: 192.168.1.69/32  # Must be outside router's DHCP range
    





  • It’s not NAS specific, it’s platform independent - that’s the whole point. You have an application you want to run, and you package it all up into a docker image which contains not only the application but it’s dependencies and their dependencies all the way down to the OS. That way you don’t need to worry about installing things (because the container already has the application installed), all you have to do is allocate some resources to the container and it’s guaranteed* to work

    *nothing is ever as simple as it first appears

    One area where this is really helpful is in horizontally scaling workloads like web servers. If you get a bunch more traffic, you just spin up a bunch more containers from your server image on whatever hardware you have laying around, and route some of the traffic to the new servers. All the servers are guaranteed to be the same so it doesn’t matter which one serves the request. This is the thing kubernetes is very good at.

    Edit: see caveats below



  • So far I just hand roll my docker-compose (at home, anyway). However, docker-compose does also support overrides via yaml merging, maybe that’s worth looking into?

    My idea with that is to have a base compose that configures also my services and then to have a few override yamls with environment specific stuff (like prod, local, …)

    This is similar to Kustomize from kubernetes land which I’ve worked with in the past