Feature understandings

[gitdeath]

I am setting up my environment to make a switch from Swarm to Overnode, but have some questions, before I pull the trigger. Apologizes upfront if the docs exist - I did look before posting, and happy to have links to docs as answers.

How would a compose file entry with the below section be entered for Overnode? Is this native support, or does it require something different? deploy: mode: replicated replicas: 3 placement: max_replicas_per_node: 1

I have a macvlan setup for a home-assistant container, such that it can interact with various broadcast devices. Does the Weavenet implementation handle this by default (ie. will it route broadcast messages received by the NICs of the devices to all containers), or allow for it somehow? I need the container on the bridge network as well, hence I'm not running it in host mode.

I've made the assumption Overnode orchestration will redeploy a container that was running on a node that has failed to a new node, similar to K3s, or Swarm - but it doesn't appear to actually say that anywhere. Is this assumption incorrect?

[avkonst]

Hi,

The overnode does not move containers. The placement is static. It is by design to make app design and troubleshooting easy. However, you still can achieve high-availability. Make sure you have got 2 or more nodes running an instance of the same service. And place haproxy or similar in front of it. HAProxy will automatically route the traffic to alive instance(s).

I think, the replicas configuration in the compose file is ignored by standalone docker-compose (ie. not in swarm mode), which is used by overnode.

I have a macvlan setup for a home-assistant container, such that it can interact with various broadcast devices. Does the Weavenet implementation handle this by default (ie. will it route broadcast messages received by the NICs of the devices to all containers), or allow for it somehow? I need the container on the bridge network as well, hence I'm not running it in host mode.

Regarding this one. I can not answer this question because I do not fully understand it. But general considerations are the following:

• each host will listen to the ports of exposed containers (you need to define in the compose file which ports to expose)
• containers within the cluster can proxy the traffic, multiplex, discard or whatever. It is up to you what containers (apps) you use and how you configure it.
• weavenet will assist with traffic going between the containers in the cluster (regardless on what nodes they are running) and will assist with traffic going in/out of the cluster via the exposed ports.

[gitdeath]

Thank you for the fast responses! Not a match for my use case unfortunately. I was really interested in the integrated prom stack.

[avkonst]

No worries. But I suggest you think again. Whatever you can do on a bare VM hosts, you can actually do in containers via overnode.

[gitdeath]

Here is my usecase and why I don't think Overnode can do what I need:

Commands run to setup the networking (macvlan) required in Swarm: docker network create --config-only --subnet 192.168.1.0/24 -o parent=eth0 --ip-range 192.168.1.XXX/30 localvlan # On each node, which allows each node to have a seperate IP range, thus ensuring no two node IPs are the same. docker network create -d macvlan --scope swarm --config-from localvlan swarmvlan # Once on a manager node assigning the name "swarmvlan" as a swarm network that uses the localvlan config from the target node.

Docker Compose File:

version: "3.7"
networks:
  internal: # This is my bridge network, which I'd not need with Overnode as weavenet is handling it instead of the swarm mesh.
    driver: overlay 
  swarmvlan: # This is the Swarm macvlan network created above
    external: true
services
  homeassistant:
    container_name: home-assistant
    image: homeassistant/raspberrypi4-homeassistant:stable
    volumes:
      - /mnt/config/homeassistant:/config
    environment:
      - TZ=America/Chicago
      - PUID=1000
      - GUID=1000
    ports:
      - 8123:8123 # Web GUI, so no matter the node (or keepalived vip) I target the web GUI will work via swarm mesh. 
    networks:
      - internal # Joins the container to the bridge network
      - swarmvlan # Joins the container to swarm macvlan network

Macvlan is a linux network driver that allows multiple mac/ip addresses for a given hardward NIC. The docker implementation uses this driver to allow a container to logically sit on a local network with those mac/ip addresses.

If I'm wrong and this can be implemented, please tell me and I will make the switch this weekend, because I love the idea of this project.

[avkonst]

1. Your usecase is very usual and can be done with overnode quite easily. Each of your nodes will have 1 haproxy container running and exposing port (eg. 8123 from your example) on a host. This haproxy container will send the traffic to your upstream web backend within the cluster network. So no matter where your backend is running, it will be accessible on each node. Here is the example for haproxy + grafana web backend: https://github.com/overnode-org/overnode/tree/master/examples/infrastructure/grafana

2. As a second option, which you probably do not realise, is that it is possible to use other networks with overnode. I believe your compose example will work with overnode too. It means you would not use the network created by overnode for your application, but you will use the overnode network to launch the containers by overnode. Not sure why you would use this option as the point 1 above is easier to implement and maintain, but you can do this too.

Hope it helps.

[gitdeath]

The first option doesn't solve the use case it is just a proxy setup for a single exposed port, in my example the web gui - this is the out of the box usage. The use case is the macvlan, which allow the container to receive broadcast packets to random and from random ports - because logically the container sits directly on the domain with an IP and MAC.

The second option actually might work, if Overnode allows me to join other networks - in this case the macvlan network, but still routes the exposed port via weavenet.

Totally worth a shot and I'll test it out - I did sort of just assume Overnode would ignore the networking portions of the compose.

[avkonst]

if Overnode allows me to join other networks - in this case the macvlan network, but still routes the exposed port via weavenet.

It would allow to join other networks. Not sure what you mean "routes the exposed port via weavenet". If your incoming traffic comes to macvlan exposed port, your service would be responsible to listen to this traffic and do something about it or proxy to other backend service containers, which would be accessible via weavenet cluster network. I frequently use socat container to wire a traffic on host to the weavenet, for example: https://github.com/overnode-org/overnode/blob/master/examples/infrastructure/loki/loki/link.yml#L13