Docker pe Raspberry Pi

Na bun, înainte să mă apuc de experimente direct în docker-ul din Prod, mi-am tras un Raspi pe post de Dev acasă, cu raspbian buster, docker și portainer, și hai să vedem ce și cum.

Obiectiv: să rulez pe un Raspi containere care să aibă porturi ce se suprapun și pe care nu le pot modifica fiindcă altfel nu mai merge treaba. Case in point - UniFi Controller-ul care trebuie să aibă niște porturi accesibile fiindcă așa le caută echipamentele din rețea, și OpenHAB care și ăla vrea o parte din aceleași porturi fiindcă alea le caută aplicația OpenHAB de pe mobil.

Varianta 1: să adaug interfețe virtuale de rețea, cu IP-uri diferite, în ideea că fac binding la un container la un IP și la alt container la alt IP. După îndelungi căutări, am aflat că metoda găsită peste tot pe net de modificat un fișier interfaces este deprecated în Buster și va fi scoasă în viitor, deci iar e netul plin de gunoi expirat și nici măcar nu specifică „acest tutorial se aplică la X”. Am dibuit soluția folosind comanda ip, cu care pot adăuga din mers adrese IP noi la o interfață de rețea existentă, iar ca să fie persistentă treaba trebuie doar să pun comanda în scripturile de startup (de fapt cel mai simplu e în dhcpcd care caută asemenea scripturi și le execută).

Problemă - docker se pare că e tâmpit și, deși își definește 3 rețele virtuale proprii, cea intitulată „host” se conectează la TOATE adresele IP disponibile (public). Dacă încerc să definesc o anumită adresă IP la un container când îi specific porturile de rețea, face scandal cum că opțiunea nu e disponibilă pentru rețeaua host ci doar pentru custom networks.

Mbeneeeee... Sap să înțeleg custom networks, doesn't help. Alea-s un fel de rețele private pentru ca mai multe containere conectate la o rețea custom să poată comunica între ele pe bază de IP SAU hostname (că în mod normal nu face IP lookup dacă specifici hostname), da' pentru conectat o asemenea rețea la o anumită adresă IP a interfeței de rețea, ciuciu.

Deci varianta 2: rămânem la o singură adresă IP, pe care voi expune pe rețeaua host un container cu reverse proxy (probabil traefik), și care apoi să se conecteze la containerele din backend pe o rețea internă. Sucks că va face networking virtual în software de-a pixu' dar dacă altfel nu se poate, cu fericire înainte. Acuma tot ce-mi mai trebuie e un tutorial beton despre configurat traefik.

Dilema rămâne - dacă io n-am server DNS propriu-zis în rețeaua locală, de unde știe un calculator să rezolve „subdomenii” diferite pentru același nume de gazdă? Gen unifi.raspberrypi sau openhab.raspberrypi . Afaik dacă vede vreun punct acolo, întreabă DNS-ul în loc să facă lookup în rețea, și DNS-ul va zice că nu știe ce-i aia că nu e FQDN. Parcă văd acuma că trebuie să îmi rulez și propriul DNS.
 
Dilema rămâne - dacă io n-am server DNS propriu-zis în rețeaua locală, de unde știe un calculator să rezolve „subdomenii” diferite pentru același nume de gazdă? Gen unifi.raspberrypi sau openhab.raspberrypi . Afaik dacă vede vreun punct acolo, întreabă DNS-ul în loc să facă lookup în rețea, și DNS-ul va zice că nu știe ce-i aia că nu e FQDN. Parcă văd acuma că trebuie să îmi rulez și propriul DNS.
Poate mDNS/Avahi?
 
Rețelistica în docker e nasoală, toate chestiile de orchestrare bazate pe docker folosesc proxy-uri (de obicei un haproxy într-o altă instanță docker).

Păi de ce n-ai DNS în rețeaua locală? Zici că ai device-uri UniFi, n-au cum să nu suporte niște static DNS (pe lângă caching) cu whatever nume vrei tu (și să facă și reverse la nevoie).
 
Am câte un pi-hole, dar parcă e un pic dubios să-l fac să folosească și o listă statică de mapări... Right?

Oricum, dezamăgirea e exact pe partea de networking. Păi ce enterprise tool al lui pește e ăsta, dacă poate folosi eficient doar câte un singur IP per mașină cu docker? Ce facem aici, mașini virtuale în care să rulăm câte un docker și în care să avem containere?
 
Dacă ai deja pi-hole, ai și server DNS/DHCP inclus (dnsmasq). Poți să-l customizezi cum vrei, dar trebuie din fișiere de configurare, nu din web-interface (afaik). Trebuie doar să pui un fișier gen 01-myconfig.conf cu configul tău în /etc/dnsmasq.d/.
 
Da, dar mi-e un pic târșă momentan :tongue: Aș vrea să ajung și la punctul în care fișierele astea le mențin pe github și de acolo se duc peste tot, dar ăla e deja alt project.
 
Păi ce enterprise tool al lui pește e ăsta, dacă poate folosi eficient doar câte un singur IP per mașină cu docker? Ce facem aici, mașini virtuale în care să rulăm câte un docker și în care să avem containere?
Păi exact așa se folosește docker :smile:.
 
:eek: Groaznic. Ăia care-l folosesc așa n-au citit partea aia prin care scopul containerelor e să evite complet virtualizarea și overhead-ul adăugat de atâtea OS-uri?
 
Ăia care-l folosesc așa n-au citit partea aia prin care scopul containerelor e să evite complet virtualizarea și overhead-ul adăugat de atâtea OS-uri?
90% din utilizatorii 3rd party ai docker îl folosesc în cloud, adică instanțe VM pe amazon/google/azure etc. Provizionarea unui astfel de VM e relativ rapidă, iar overhead and stuff... pui mai multe mașini :smile:. Docker "singur" nu cred că folosește cineva, ai ceva deasupra pentru orchestrare, instalezi chestia aia pe mașină și ai kindof scăpat.
 
You guys are not helping :biggrin:

Deci dacă nu o scot la capăt cu traefik mă întorc la a avea 2 raspberry-uri că e mai puțină bătaie de cap?
 
Cam da. Rpi nu a fost conceput pentru chestii asa de complicate enterprise-style.
Docker e folosit in combinatie cu Kubernetes de obicei.
 
Docker ar trebui folosit atunci când ai aplicații pentru care vrei o instalare repetabilă pentru că ai nevoie de 30 de instanțe din când în când (black friday) sau pentru că vrei să poți să te muți rapid de pe un hardware pe altul în caz de ceva (ex: crapă ceva, sau vrei să migrezi de la un cloud provider la altul - dar aici e simplu doar pe hârtie). Tot ce e instalat pe mașina cu docker se consideră volatil și setup-ul imaginii trebuie făcut astfel încât să accepte asta - dacă au de stocat vor stoca pe mount-uri pe storage separat, trebuie să accepte toată configurația prin environment vars, dacă au de scris undeva trebuie să fii atent să le faci mount. Apoi ai orchestrare deasupra ca să dai 2 click-uri într-o interfață să mai ridici încă 20 de instanțe de același fel, nici nu te interesează pe ce hardware, că se face automat configurarea de load balancing. Sau să poți reveni rapid la o versiune anterioară atunci când ai făcut un upgrade și versiunea nouă e bușită (dar asta presupune că n-ai bușit partea de stocare între timp cu un upgrade care nu e backwards compatible).

Docker pe raspberry pi faci pentru că vrei să înveți docker și n-ai chef să pornești o mașină virtuală, sau pentru că vrei să folosești imagini făcute de alții (că pare simplu, dar sunt multe imagini prost făcute sau prost documentate, sau trebuie să știi destul de bine produsul din interior ca să știi cum trebuie configurat să fie sigur). Pe pi e MULT mai simplu să instalezi totul local și să faci o copie a cardului SD pentru backup. Pentru că oricum nu ai storage separat, ca să zici că tragi imaginile și gata, tot trebuie reconfigurat. Și atunci scoți cardul, faci un dd la tot și aia e. Și nu ai probleme când crapă rețelistica din docker (se întâmplă; poți să pui un watchdog să dea restart la pi), când mai dispare câte un feature din docker sau apare un bug interesant, dar tu ai făcut upgrade automat fără să știi (că tu n-ai echipă de 3 oameni care să sufle în fund docker-ului zilnic, să știe ce s-a schimbat și să testeze fiecare versiune într-un alt env).

Mie-mi place să folosesc scule enterprise acasă (ESXi pe unsupported hardware? controllere SAS cu CLI proprietar? mikrotik, cu CLI proprietar? fibră, greu de tras și fragilă? bring it on!), da' cu docker nu mă complic, chiar dacă folosesc la muncă, adică mi-ar fi ușor. Pentru că nu-i văd utilitatea. ESX-ului în văd utilitatea, că e ușor să faci VM-uri, are interfață grafică ok și nu ai nevoie de licență. Mikrotik-ului îi văd utilitatea, că upgrade-ul de la un routar la altul (complet diferit ca arhitectură, RISC->ARM), la o configurație cu TONE de customizări ia 30 de minute și e făcută cu vechiul router online (în principal să remapezi interfețele, că pot fi diferite). Dar cu docker nu știu ce să fac. Am destule aplicații instalate pe linux-uri, dar sunt deja în mașini virtuale și e simplu să fac o arhivă cu tot discul. Aș putea să zic că m-ar ajuta să fac upgrade mai des la OS-ul de dedesubt, dar până acum yum update -y a fost suficient ca să îmi țină un linux cât de cât updatat. Mutat pe alt hardware? Simplu, că-s VM-uri, fac deja asta.
 
Mai avansăm un pic la prerequisites.

Pi-hole versiunea 5 are opțiune în GUI pentru „Local DNS Records”, ceea ce puteam adăuga anterior și din linia de comandă dar meh.

Urmează configurarea traefik și testarea pe un raspi de test.

Btw luna asta a fost lansată ultima versiune de Portainer 1.x, urmând să apară 2.0 până la sfârșit de iunie. Trăiască watchtower că o să facă update automat :smile:
 
Am facut si eu update la Pi-hole ocazie cu care am constatat ca nu mai merge. Initial am suspectat ca cineva a modificat iptables, am creat o noua regula si pachetele trec dar nimeni nu raspunde la query de dns.
Totusi pentru localhost raspunde, ceea ce e ciudat.
Poate am timp sa sap diseara.
 
Eu i-am făcut update cu apt-get upgrade dar atât. Am văzut că interfața-mi spune că Pi-hole are versiuni noi dar nu-l stric :smile:
 
În docker, upgrade-ul s-ar fi făcut prin înlocuirea imaginii, iar downgrade-ul s-ar fi făcut la fel de simplu. :tongue:
 
In linie de comanda exista comanda dedicata pentru upgrade.
Dar nu cred ca upgrade in sine este problema, ultimele loguri sunt de acum vreo luna.
 
Back
Top