Az csak remote szerverben tud syncronizálni, nem? 2 konténert nem szeretnék futtatni emiatt.

Egyik HDDn van Munka mappa, másik HDDn meg Backup mappa, ezeket kéne 1 eszközön szinkronizálni. Ezt ahogy most rákerestem megint, továbbra se tudja syncthing.

[ Szerkesztve ]

Értem.
Valóban eszközszinkronizálásra való a Syncthing.

Mappaszinkronizálásra futtathatsz cronból rsyncet.

Meg CP parancsot is, tudom, viszont annál picit komolyabb dolgot szeretnék, fájlverzió követés stb.

Létrehoztam a portainert a compose fájlban, viszont, a webes felületen a stacks fülön limited control-t mutat. Ez normális?

Igen, ha a többi stacket is kézzel hoztad létre, nem magából portainerből. Ott írja is elvileg

Sziasztok!

Ti a docker konténerek indítását boot után, hogy oldjátok meg?
Nekem jelenleg egy-egy konténer egy-egy systemd service-ként fut.
Valahogy így.
(Rutorrent, Sonarr, Radarr, Jackett, Plex, Ombi, Heimdall)

Docker-compose fájlban restart: always esetén a docker service indulásakor indul a stack is

Miért kell systemd servicebe csomagolni?
Restart always flag támogatott sima és compose módban is.

Ez így szimpatikus nagyon!
Több docker-compose stack-nél kell valamivel bűvészkedni? (1 torrent, 1 nextcloud, 1 tvheadend)
Konkrét leírást nem találtam neten, csak annyit, hogy a docker-compose parancsban megadható a yml fájl is.

Systemd-ben azért volt kényelmes, mert a compose-hoz nem értek és 3 éve nem találkoztam a restart paraméterrel. Így az upgrade is csak félig volt macera.

Nem kell bűvészkedni semmivel.
Sőt, ha docker-compose.yml a fájlod neve és minden stacked külön könyvtárban van akkor még a fájlnevet sem kell megadnod, hanem az adott könyvtárból docker-compose up és már megy is.

És ezt tudom valahogy elegánsan automatizálni boot után?

Egyszer elindítod és utána automatikusan elindul bootkor.

Composet első alkalommal -d flaggel indítod akkor automatikusan a háttérbe küldi magát.

Restart: always pedig elindítja amikor a Docker daemon indul bootkor.

Ez nagyon jól hangzik! Köszönöm!
Sokat fogok még ide visszajárni!

Nem, semmi. Annyi, hogy minden service-hez fel kell sorolni amit futtatni szeretnél. Van egyébként unless stopped is, nem tudom pontosan hogy van keress rá. Akkor még jobban .service -re hasonlít, mert ha leállítod kézzel ("disable") akkor nem indul újra amíg el nem indítod kézzel.

Meg ugye el lehetne ezt az egészet vinni kubernetes irányába is, de szerintem otthonra (jobban mondva amíg nem load-balance / high availability a cél) addig felesleges és szvsz. a kubernetes konfigja egy hányadék a compose-hoz képest

Kapcsolók közül még a --force-recreate talán érdemes megjegyezni

[ Szerkesztve ]

Persze, mi a gond konkrétan?

Akkor meg is van mi a gond. Első körben, hogy a 172.19.0.2 az a konténer ip címe és lokál (ezért is látod a virtualizált eth0 interfészt), ahogyan a 192 -es is. Public ip -d kéne felvenni a dinamikus dns -hez.
Ezen felül a docker0, lan és wan interfészeid össze kellen forwardolni, ip forwardingot engedélyezni kernelben

Mondjuk ennek nagy részét a Docker alapból megcsinálja, ha nem vagy mazohista és nem kapcsoltad ki az iptables nyulkapiszkát és csinálod manuálisan
De servernek tuti a wan címed kell nem a konténer-lan

Nálam pl. azt adom meg, hogy rowra.org, a lan 10.0.0.0/24, a docker meg 10.10.0.0/16
Ezen felül érdemes NET_ADMIN jogot adni a stacknek.

Teszt erejére kipróbálhatod, hogy
privileged: true
network_mode: host
Módban futtatod, csak majd (szerintem) ne hagyd úgy, mert így nem nagyon érvényesül a virtualizációban rejlő "védelem", ráül a hosztra teljesen

Itt az én konfigom, hátha segít ez is [link]

[ Szerkesztve ]

A pubilc IP van a ddns-ben beállítva. (Nem is tudom, lehet-e mást).

A többit megnézem.

version: "2"
services:
  openvpn-as:
    image: linuxserver/openvpn-as
    container_name: openvpn-as
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Budapest
    volumes:
      - openvpn:/config
    ports:
      - 943:943
      - 9443:9443
      - 1194:1194/udp
    restart: unless-stopped

[ Szerkesztve ]