Parallele Dockerinstallation

[Ben1983]

@haselchen aber wie soll es denn durch verschieden Hostnamen gehen?
weil der dann irgendwie die ip:port kombi vom bridged netzwerk nutzt?
Woher weiss das aber das gegenüber? der sieht doch nur die host:post kombi.

Genau deswegen dachte ich ja, muss man macVLAN nehmen.
weil man sonst unterschiedliche ports für produktiv und testsystem braucht

[haselchen]

@ben1983

Deswegen sage ich ja, bei MCVLAN müssen andere ran.
Der Port 8081 bleibt ja, die IP davor muss sich ja unterscheiden.
Du kannst doch auf der Syno über den VM Manager auch ne VM installieren und ne Iobroker Container Installation haben.

[Ben1983]

@haselchen das habe ich einmal versucht, danach ging netzwerktecnisch gar nichts mehr und ich kam nicht mehl an den iobroker

[OliverIO]

@ben1983 sagte in Parallele Dockerinstallation:

Aber die stackconfig oben sollte so passen, oder?

sieht gut aus, hier noch detailoptimierung
ich habe dem netzwerk einen namen gegeben ich verwende das mit default so ncith.
aber wenn es funktioniert

version: '2'

services:
 iobroker_testsystem:
   image: buanet/iobroker:v10.0.0
   restart: always

   volumes:
     - /volume1/docker/iobroker_testsystem:/opt/iobroker
   networks:
     default:
       ipv4_address: 192.168.2.92

networks:
 default:
   name: mymacvlan
   external: true

hier ist meins
ich habe mittlerweile docker und diesen container ipv6 fähig gemacht

version: '3'

services:
  iobrokerdev:
    image: buanet/iobroker:latest
    restart: always
    environment:
      DEBUG: "false"
      AVAHI: "true"
    ports:
      - "8081:8081"
      - "3000:3000"
    volumes:
      - /home/iobroker/docker/volume/iobroker/dev/iobroker:/opt/iobroker
    networks:
      macvlanipv6:
        ipv4_address: 192.168.1.81
networks:
  macvlanipv6:
    external: true

[OliverIO]

@ben1983 sagte in Parallele Dockerinstallation:

aber wie soll es denn durch verschieden Hostnamen gehen?
weil der dann irgendwie die ip:port kombi vom bridged netzwerk nutzt?

gar nicht.
host oder bridged heißt ja, das der container unter der host ip erreichbar ist und alle ports auf den host bereich gemapped werden.
wenn man eine 2.iob installation haben möchte, müssen alle ports des 2. containers auf freie ports des hosts gemapped werden
das geht dann auch nur im bridged, da portmapping im hostmode nicht berücksichtigt wird

vorteil von macvland sind auch die broadcasts. wenn man services einsetzt, die auf broadcasts horchen muss ich entweder hostmode einsetzen oder macvlan.
im bridged werden die broadcasts nicht durchgereicht.

[Ben1983]

@oliverio OK. Mir ging es ja darum eine Testumgebung zu haben, die die gleichen Ports nutzt,
da der kommunizierende Service ja nicht doppelt vorhanden ist.

[Codierknecht]

@ben1983 sagte in Parallele Dockerinstallation:

eine Testumgebung zu haben, die die gleichen Ports nutzt,

Wie soll das z.B. bei MQTT funktionieren?
Dann müsstest Du ja am sendenden Gerät eine andere IP einstellen.
Gleiche IP und gleicher Port geht jedenfalls nicht.

Du kannst höchstens 2 Stacks erzeugen, die beide Bridge, die gleichen Ports usw. verwenden und den jeweils nicht benötigten Stack stoppen.

[Ben1983]

@codierknecht einen ioBroker auf dem Host (Mein Produktiv) und ein im MacVLAN.
mit ner anderen IP. Können doch beider clients sein. geht doch, oder?

[OliverIO]

@ben1983
Theoretisch ja
Würde ich und habe ich nicht

Ich habe einen produktions Container
Und einen Test Container mit festen ip

Den Test kann ich jederzeit neu aufsetzen ist aber meistens auf latest

Gelegentlich setze ich dann noch einen bridged Container auf mit alten js Controller Versionen um rückwärts Kompatibilität zu testen. Aber die leben nur sehr kurz

[Ben1983]

@oliverio OK.
So ganz kann ich dir nicht folgen... hast kein MacVLAN, aber container mit fester ip?
Oder meinst Du damit im bridged Netzwerk?

[Codierknecht]

@ben1983 sagte in Parallele Dockerinstallation:

einen ioBroker auf dem Host (Mein Produktiv) und ein im MacVLAN.
mit ner anderen IP. Können doch beider clients sein. geht doch, oder?

Wie @OliverIO schon schreibt: Theoretisch ja.
Ich hatte das Vorhaben so verstanden, dass da 2 Container laufen sollen, die prinzipiell die gleichen Aufgaben ausführen. Nur einer eben um mögliche Fehler auf dem anderen auszuschließen.

nur was ist bspw. mit bspw. eine mqtt port 1883 den ich nutze.
Diesen nutzt ja jetzt das Livesystem schon.
den kann ich jetzt nicht mehr ins testsystem rein bekommen, oder?

Wenn das Livesystem mit seiner IP über Port 1883 erreicht wird, kann ja nicht gleichzeitig ein anderes System auf der gleichen IP den gleichen Port verwenden.
Mit 2 unterschiedlichen IP's geht das natürlich. Aber dann muss ja auf dem MQTT-Gerät eine andere IP eingetragen werden.
Oder halt 2 Container auf der Synology, die MQTT (und alles andere auch) über unterschiedliche Ports anbieten. Dann muss eben im MQTT-Gerät der Port geändert werden.

Mein Produktivsystem läuft als LXC unter Proxmox.
Testsystem nativ unter Debian auf 'nem NUC.
Dazu noch je 1x ioBroker auf Unraid, unter Windows, als Docker-Container auf dem NUC und als Docker-Container auf 'ner Synology-VM unter Proxmox. Das sind eher Spielsysteme, um andere Basissysteme testen zu können.

[OliverIO]

@ben1983

Doch, beide macvlan container
Haben eine feste up

Im testcontainer teste ich immer meine
Adapter gegen latest und möglichst echten Bedingungen. Der dev-Server macht manche Dinge dann doch nochmal anders
Außerdem teste ich dort Dinge zu Themen aus dem Forum und discord

Den zusatzcontainer auf bridge mache ich
Dann wenn ich kein volume mapping auf Festplatte brauche.
Leider habe ich mein macvlan etwas zu kleinbgeplant so das ch da nicht soviel ip Adressen habe. Daher spare ich mir für die sehr kurzlebigen Tests auch die ip Adresse und Mappe die Ports auf den Host.
Wie schon gesagt läuft bei mir auf dem Host nur Docker. Alles andere habe ich in Container verlegt

Ich habe da sogar ein linux mit grafischer Oberfläche laufen. Zugriff läuft über den Browser mittels vnc. Fühlt sich aber leider ein wenig sluggish an. Aber dafür reichts
https://hub.docker.com/r/jlesage/baseimage-gui

[Ben1983]

@oliverio na vielleicht teste ich doch mal ein Testsystem auf einem MacVLAN Container.
Eventuell sollte / kann man ja später mal das Produktivsystem umziehen.