Docker pe Raspberry Pi

puterfixer

puterfixer

Administrator
Sugar daddy
Ză instracșăns.

1. Pregătirea Raspberry Pi:

Descarci Raspbian (Lite) și-l scrii pe un microSD folosind Balena Etcher.

Pe cardul microSD o să găsești 2 partiții, una boot și alta linux. Pe cea de boot pui în folderul rădăcină un fișier gol cu numele ssh (fără extensie) pentru ca să se activeze serviciul SSH direct, fără să trebuiască să pui monitor și tastatură. De asemenea, mai modifici fișierul config.txt adăugând la sfârșit:

Code: 
dtparam=spi=off
dtparam=audio=off
start_x=0
enable_uart=0
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt
gpu_mem=16

Cu asta dezactivezi SPI, audio, UART, bluetooth și wifi dacă intenționezi să-l folosești doar pe fir. De asemenea, eliberezi din memorie din moment ce-l vei folosi headless și atunci GPU-ul nu are nevoie să rezerve memorie pentru grafică.

Bagi cardul în RPi, îl conectezi la switch, îl pornești, afli din router sau cu un network scanner ce IP are, te conectezi prin SSH cu user pi și parola raspberry. E recomandat să schimbi parola cu passwd.

Actualizări:
Bash: 
sudo apt update
sudo apt upgrade
sudo apt -y dist-upgrade

Configurație:
Bash: 
sudo raspi-config
unde le iei pe rând ca să configurezi rețeaua, eventual și localizarea, iar la advanced dai expand filesystem pentru ca a doua partiție să umple cardul.


2. Instalarea Docker:

Asta e tot ce ai de rulat:
Bash: 
curl -sSL https://get.docker.com | sh

Docker e rulat din linie de comandă folosind, evident, comanda docker. Ca să nu tot dai sudo docker tralala fiindcă tu ești autentificat de obicei cu userul pi, cel mai bine ar fi să adaugi userul pi la grupul docker:
Bash: 
sudo gpasswd -a pi docker

După un logoff/logon sau reboot, apartenența va intra în vigoare.


3. Instalarea portainer:

Nimic mai simplu:
Bash: 
docker volume create portainer_data
docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data --restart always portainer/portainer


4: Configurarea portainer:

Te conectezi din browser la http://<ip raspberry>:9000. Primul pas e să faci un user de administrare și să-i definești parola. Dup-aia te întreabă dacă vrei să administrezi un docker local sau remote - alegi local. Da, condiția aia specificată cu roșu pe ecran a fost deja îndeplinită la punctul 2 :smile:


Unele tutoriale spun să instalezi și docker-compose, ca să fie mai ușor să controlezi dockerul (fără portainer). Ăsta se instalează ușor folosind pip, care e un utilitar python. Majoritatea tutorialelor găsite se referă la python 2, care e deprecated și urmează să fie pensionat, deci trebuie să instalezi întâi python 3 care să aducă pip, și apoi să instalezi cu pip docker-compose. Meh.


5: Primul container - pi-hole FTW!

Imaginea oficială este aici: https://hub.docker.com/r/pihole/pihole asta însemnând că e userul pihole / imaginea pihole. Userul are publicate mai multe imagini, de exemplu pihole/debian-base.

După numele imaginii mai poți specifica și un tag prin care să specifici versiunea. Poți vedea pe Docker Hub mai sus în tab-ul Tags ce versiuni există - atât versiuni de software cât și platforma.

De obicei poți folosi :latest drept tag care să indice spre ultima versiune, și detectează singur ce platformă ai.

Deci, ai putea din linia de comandă să descarci imaginea folosind
Bash: 
docker pull pihole/pihole
sau mai specific
Bash: 
docker pull pihole/pihole:latest
și dup-aia să pui configurația dată drept exemplu pe pagină la quick start într-un fișier docker-compose.yml ca fișier de „configurare” salvat în /home/pi/docker-stuff/pi-hole/ .

Dar eu sunt un puturos, de-aia mi-am pus portainer :smile:

În portainer ai putea face același lucru mergând în Images, scriind pihole/pihole:latest la numele imaginii, DockerHub la Registry, și click pe Pull the image. De fapt orice imagine descarci folosind comanda docker pull o să apară în lista de imagini descărcate local în secțiunea Images.

Dar poți să faci containerul direct, fără să descarci mai întâi imaginea. Deschizi portainer în browser, mergi la Container - Add container, scrii ce nume vrei să-i dai, pui numele imaginii ca mai sus, și apoi urmează distracția configurării necesare pentru container folosind imaginea respectivă.

Pi-hole are nevoie de câteva chestii:
  • maparea porturilor de pe host pe container, pentru ca să comunice în rețea (asta cu Network mai jos setat în mod Bridge, că se poate și Host și atunci expune tot)
  • maparea unor căi din container spre foldere de pe host (/home/pi/docker-stuff/pi-hole) unde să fie salvate fișierele persistente
  • setarea unor variabile de mediu în Env (environment) prin care să dai anumiți parametri containerului, de exemplu parola de administrare, timezone-ul și DNS-ul upstream preferat
  • setarea restart policy pe Always sau Unless Stopped, pentru ca containerul să repornească automat la boot
După asta poți face click pe Deploy the container, și aia e. După ce pornește îl poți accesa cu http://<IP de RPi>/admin/

Ghid de instalare pi-hole cu poze: https://homenetworkguy.com/how-to/install-pihole-on-raspberry-pi-with-docker-and-portainer/

Alte imagini vor avea nevoile lor privind configurația de rețea, folderele din imagine mapate spre stocarea persistentă, alte flag-uri etc. Tre' să citești.

De exemplu am dat de containrrr/watchtower care automatizează descărcarea de imagini actualizate pentru containere și repornirea containerelor cu imaginile noi. Tre' să văd ce trebuie să-i fac ca să-l rulez. https://hub.docker.com/r/containrrr/watchtower
 
Ce alte chestii ar mai merge rulate?

De asemenea, poți face dintr-un rPi deja configurat un container docker sau este mai degrabă recomandat backup settings în actualul pi-hole și apoi import în cel din container?
 
Un container nu e o mașină virtuală. Ideea unui container e să rulezi o singură aplicație per container, iar configurarea să fie externă (adică să nu fie în interiorul imaginii, să poți înlocui imaginea cu altă versiune fără să reinstalezi tot, păstrezi configurarea de la cel vechi). Aplicația trebuie setată să nu modifice pe cât posibil datele din structura de directoare care vine cu imaginea, ci să folosească pentru stocare persistentă doar path-urile pe care le montezi (în volume sau mapare de pe host -- volumele sunt în general tot un fe de mapare de pe host, dar poți face management-ul lor direct din docker). Host-ul rămâne așa cum e, poți face configurații hibride în care părți sunt în containere și părți sunt pe mașina fizică.

Idealul docker (plus orchestratoarele de deasupra) e să ai aplicația configurată atât de bine încât atunci când ai nevoie de mai multe instanțe dintr-una din aplicații (pentru că ți-au listat site-ul pe HN or whatevs) să dai 3 click-uri și ai extins numărul de instanțe de la 2 la 10 (și poa' să fie pe 5 mașini fizice diferite), și s-a reconfigurat și load balancer-ul automat ca să se lege la toate. Apoi, dacă faci un upgrade și nu-ți place, faci rollback imediat la imaginea anterioară și ai rezolvat.
 
Tu vrei deja să sari la chestii avansate, gen produs imagini pentru docker? :nuts:


Cel mai simplu e să faci backup la shittings din pi-hole actual și import. Poți face asta prin funcția încorporată din pi-hole, daaaar poți fi și șmecher un pic: imaginea docker are nevoie de 2 foldere pentru fișiere persistente (setări, logs, statistici) pe RPi-ul gazdă, care să fie conectate ca symlinks în interiorul imaginii read-only. Căile sunt definite prin mapări în setările containerului. Așa știi și unde își are salvate aceste chestii instanța existentă de pi-hole, deci ai putea bine mersi să faci copy la fișierele alea de pe RPi-ul cu pi-hole pe RPi-ul cu docker. Nu le pui în aceeași cale printre fișierele sistem, duh, le pui în home undeva, în exemplul de mai sus le-am pus în home-ul userului pi, într-un director numit docker-stuff pentru toate fișierele persistente ale tuturor containerelor, într-un director pi-hole făcut pentru acest container. Nu scapi de a seta corect variabilele de inițializare a containerului (timezone, dns1=127.0.0.1, dns2=ce vrei tu, etc.) dar măcar la prima pornire a containerului vei avea deja toate listele și statisticile de pe instanța veche.

Ce fac eu aici cu docker e cherry picking din funcțiile lui ca să-mi fie mie comodă administrarea unei singure instanțe a unui container de aplicație. Puterea lui se cunoaște însă în echipe de dezvoltare și testare, sau în producție unde faci un swarm (cluster de mașini ce rulează docker) pentru redundanță și load balancing automat. Dup-aia mai adaugi și o unealtă de orchestrare gen kubernetes, care să-ți automatizeze lanțul de deployment de la ce commit-uri de cod marțocărești tu în gitlab (că totuși lucratul în cod sursă doar local, fără versioning implementat ca lumea, e epoca de piatră a IT-ului) până la producerea imaginii și rularea ei pentru teste funcționale/de integrare și apoi producție. Mai pui niște puppet, jenkins, ansible și altele, și ai cam automatizat toaaaată "linia de producție" care, altfel, se face manual între codul sursă și aplicația rulând în producție.

De exemplu, clientul meu vrea să permită ciumpalacilor din marketing să ceară direct chestii într-un portal de servicii IT. Una dintre chestii ar fi și „tot ce e nevoie” pentru a avea un site nou pentru vreun brand sau campanie de marketing.

Ideea e ca procesul de creare a unui site să fie simplu precum:
  1. marketing dude cere site nou, tot ce știe el e numele domeniului, cine-s programatorii de la agenție și o estimare vagă a nivelului de trafic/încărcare
  2. developerii primesc de-a gata toată configurația inițială, modifică template-ul de site din GitLab și-i dau commit
  3. în câteva minute va apărea pe docker o imagine LAMP (Linux ca bază, Apache pentru server web, MySQL pentru baze de date, PHP pentru scripturi dinamice) cu configurația și fișierele site-ului găzduit, cu monitorizare a traficului și suport tehnic, cu load balancing, bla bla bla - fără să facă nimeni nimic manual între GitLab și serverul de producție.
Ce face de fapt orchestratorul:
  • în CMDB (Configuration Management DataBase), facem un Configuration Item nou pentru acest site, la care ne apucăm să adăugăm detalii dintre cele trimise de requester în formular cât și, pe rând, alte detalii tehnice pe care le obținem în pașii următori
  • în DNS, înregistrăm automat domeniul
  • în sistemul de Identity and Access Management (Active Directory), facem un cont tehnic de user pentru proiect și un grup de securitate pentru conturile programatorilor aduși de agenția de publicitate
  • în GitLab, facem un proiect nou pornind de la un template predefinit, și să dăm permisiunile corecte la userul tehnic și la grupul de securitate
  • în sistemul de stocare centralizată, obținem stocare pentru fișierele persistente ale site-ului
  • în clusterul de baze de date, obținem o bază de date pentru site, cont și parolă
  • în Splunk, configurăm un dashboard pentru afișat analytics de trafic și încărcare
  • în Docker Enterprise Environment, definim organizația și echipele și le asociem grupurile de securitate predefinite, alocăm resurse swarm la proiect pentru medii separate de dev/testing/producție, și alte câteva chestii.
Dacă requesterul vede în Splunk că site-ul merge cam șchiopătat, intră iar în portalul IT și cere mai multe resurse (cpu, noduri, whatever), care se aplică instantaneu în docker. Putem face și autoscaling în funcție de traffic load, să apară sau să dispară automat noduri/resurse. Iar o altă echipă de developeri, cei care fac mentenanța la imaginea LAMP, când publică o versiune nouă în GitLab, și aia trece complet automatizat printr-un lanț de testare și confirmare că funcționează corect, până în producție.

Na cam aici își arată docker puterea, ca părticică a unui lanț de integrare între mai multe alte unelte specializate de automatizare/orchestrare. De-aia zic că a-l folosi pe 1 RPi pentru a rula 1 instanță de pi-hole sau altceva, e cherry picking pentru capabilitatea mult mai simplă (divide et impera) de a schimba imagini de aplicații în loc de a face backups de sistem și teste într-un mediu separat înainte de a aplica o banală actualizare de componente software. Dar practic nu folosesc nici 5% din ce ar putea face docker.

Dar dacă tot ai întrebat, poți să te uiți pe Docker Hub la cele mai populare imagini și vezi dacă-ți trebuie ceva de acolo - folosește filtrele de categorii din stânga. De exemplu, poți să-ți faci foarte ușor un container de baze de date MySQL sau MariaDB pentru media gallery-ul Kodi. Dar în esență o să găsești componente care să fie asamblate în stilul de mai sus în ceva funcționalitate mai mare, mai puțin chestii de-a gata cum este pi-hole. O asemenea nevoie de a rula chestii de-a gata se pretează mai degrabă pentru „virtual appliances”, de exemplu un appliance pentru un server de mail privat cu tot ce ține de el, inclusiv anti spam și intrusion detection, dar aia e virtualizare, nu containerizare.
 
Last edited:
Neo said:
De asemenea, poți face dintr-un rPi deja configurat un container docker sau este mai degrabă recomandat backup settings în actualul pi-hole și apoi import în cel din container?
Click to expand...
Invers, faci din pihole o imagie pe care o rulezi intr-un container iar tot ce salvezi gen configuratii le tii intr-un folder ce-l mapezi in container sau intr-un "volume". Daca aplicatia moare, containerul moare cu ea, dar ce vrei sa salvezi ramane in acel folder. Deci poti inlocui imaginea dar pastrezi datele fara sa fie nevoie sa reconfigurezi totul de la zero, doar mapezi acel folder la container.

Pentru detalii:
 
  • Like
Reactions: Neo
PS: apropo de dobitocenia acelui container cu LAMP pe care-l vrea clientul - media de vârstă la client e de vreo 57 de ani. Sunt niște dinozauri în gândire și abilități de a mai învăța chestii noi. Ultima dată când le-a scintilat un pic sinapsa și au prins oarecum o idee nouă a fost conceptul de mașini virtuale, dar și pe alea le folosesc exclusiv ca infrastructura altcuiva. Cloud native, microservicii, chestii de-astea noi? Nuuuuu... Cloud e doar datacenterul altcuiva cu un nume mai fancypants, în care ne facem noi propriul datacenter virtual, cu propriile load balancere, propriile AD-uri, și propriile câteva mașini virtuale masive cu sute de procesoare pe care rulează TOT. Cum adică să ai un container care tot ce face e unul din zecile de worker nodes pentru o bază de date, în loc să ai un megaserver (virtual) cu Oracle fiindcă toți jucătorii mari din industrie folosesc Oracle și nu putem să ratăm participarea în acest circlejerk doar ca să ne putem lăuda cât cheltuim pe licențe, deși nu se potrivește cu ceea ce vrem să rulăm off-premise? Mna și uite așa cineva încă nu poate gândi dincolo de imaginea unui sistem bare metal pe care instalează LAMP, dar la care acum o să-i mai facă niște chichițe pentru ca să se poată instala ȘI într-o mașină virtuală, ȘI într-un container, da' să nu se schimbe nimic de la conceptul de big fat custom OS image, iar toți puțandreii ăștia de dooj' de ani din IT cu visele lor inovator-disruptive poa' să pupe fundurile cu doctorate ale dinozaurilor.
 
Deci in loc sa instalezi LAMP local tu instalezi Docker in care rulezi LAMP? Maxim. Tocmai scopul Docker e acela de a folosi instante separate si nu LAMP gramada. Daca ai nevoie de scaling la db practic tii resurse ocupate pentru toata magaoaia in loc sa dai doar aplicatiei care are nevoie.
 
Acuma dacă clientul plătește pentru timpul consumat cu dobitoceniile lui, cu plăcere, facem. Mănâncă și indienii o pită vreo două luni de zile minim. Da' le vine și dinozaurilor vremea... Zvonurile spun că prin sfârșit de noiembrie, așa, câteva mii de concedieri / pachete de pensie anticipată.

Alt exemplu recent de dobitocenie - competitive bidding între AWS, Azure și Google Cloud pentru cine poate oferi dedicated bare metal infrastructure in the cloud. Exact cum sună - ăia să cumpere niște rack-uri de hardware pe exact specificațiile clientului și să le dea în uz exclusiv clientului contra unei chirii lunare, și cu asta se poate bifa că s-a mutat nuș' ce aplicație din on-premise datacenter în cloud, cu factură de la unul din ăia trei drept dovadă că e la un cloud provider. Ce nu e clar?!?!
 
Last edited:
Ce-i adevarat e adevarat, dar cat timp in contabilitate arata bine inseamna ca e bine. :rotf:
Pana la urma ce e IT-ul? O combinatie de oameni non-tehnici care stiu ce vor dar nu stiu cum s-o faca si niste oameni tehnici care habar n-au ce vor dar stiu cum s-o faca. Iar din combinatia asta ies niste pornoshaguri de nu poti dormi noaptea.
 
Aia non-tehnici stiu pe dracu' ce vor. Habar-n-au. Stiu doar cum trebuie sa arate in final pe chart-urile de contabilitate si vanzari.
 
Ferească sfântu' să pui într-o ședință un inginer IT față în față cu un user, și să speri că iese ceva productiv de acolo. De-aia au apărut niște animale noi în organizații, ăia care au background de IT și lucrează în departamentul IT, da' stau mai mult cu userii, le învață procesele și limbajul și nevoile, pentru ca să devină o punte de comunicare între useri și IT. De ăștia depinde succesul unui proiect mai mult decât de programatorii care îl implementează. Problema în cazul de mai sus e că clientul meu e de fapt IT-ul companiei lor, deci degeaba aduc io aptitudini de-astea cross-functional când dau de niște ingineri de pe când era Fortranul miez, și ei au în întregime autoritatea de a lua decizii (proaste) fiindcă se mai cred și cu veleități de arhitecți.

Dar nu despre asta e vorba în acest topic. Sau poate este? O țeavă de-asta de CI/CD (continuous integration - continuous delivery) are, printre consecințe, și faptul că elimină nevoia de a mai interacționa cu niște tehnicieni operaționali :D Odată ce web dev-ul (ăla care colaborează îndeaproape cu userii) a făcut commit la cod în repo, imediat s-a și dus în instanța de test pentru ca să le arate la useri cum funcționează, iar dacă e totul ok, din câteva click-uri se duce în producție. Ce atâta tichete la IT, documentare de release, change advisory board, maintenance window și toate chestiile alea care justifică munca manuală a atâtor tehnicieni IT. Un click, frățică!
 
Da da, un click... pana cand ceva crapa si iese scandal si apar din nou release notes si change requests si restul de birocratie, ca daca is alea prezente binenteles ca nu va mai crapa nimic niciodata. :))
 
Sună a organizație în care IT-ul acceptă să-i spună business-ul cum să-și facă treaba, și în rest e doar preș de șters picioarele :)
 
Luna trecută am frecat un tichet de numa' pentru că una din mașinile docker se înțepenea cumva și nu mai comunica corect rancher-ul cu ea. Eu făceam deploy (staging), mergea tot, dădeam la client "ți-am făcut modificarea, ia vezi", ăla după câteva ore... băi, nu merge site-ul. Mda, nu merge. În rancher apărea ok mașina, dar mergea doar uneori, mai zicea și unreachable din când în când. Migrat instanțele de aplicație pe altă mașină, le pinuiesc să nu se mai miște de-acolo, deschis tichet la IT, băi nu vă merge mașina aia, ok, verificăm. Cum eu migrasem pe alta, dau la client "acum merge", răspuns după ceva timp "băi, tot nu merge". Mda, nu merge. IT-ul "rezolvase" (restart and stuff), iar apăruse mașina aia cu probleme, de data asta migrase baza de date pe mașina aia :biggrin:. Mutat și aia, pin, redeschis tichet la IT, dau la client "acum merge", răspuns după ceva timp "băi, tot nu merge". Mda, tot nu merge, FFS. Tot stack-ul meu era acum pe alte mașini decât aia inițială, FFS again. Ah, a migrat load balancer-ul global pe mașina aia, de fapt nu mai merge nimic din instanța aia de rancher :biggrin:. Între timp nenea care trebuia să aprobe modificările a intrat în concediu și de fapt o modificare minoră a durat cam o lună.
 
Aud că rancher e magnific când totul funcționează, da' și când s-a bușit ceva, mniezo cu mila. Așa e?
 
Mniezoi se aud probabil zilnic, că avem și o infrastructură super hibridă (mașini fizice on prem, mașini virtuale pe mașini fizice on prem, cloud din azure și amazon)... Ceva-ceva tot trebuie să se strice :smile:.

Cele mai mari probleme sunt pe la upgrades, că nu prea s-au chinuit să le facă ușoare.
 
Last edited:
Tare mi-e teamă că dacă lucrează numai IT-istul, iese situl ca ăla Orange sau (și mai rău) CNAIR, unde am croșetat 20 de minute până am plătit un rahat de rovinietă! :zbang:
 
You must log in or register to reply here.
Back
Top