Stack-ul NameOcean: Python, Django, Redis și Proxmox

Pe scurt: NameOcean este o aplicație Python și Django. PostgreSQL stochează datele, Redis servește drept cache, iar sarcinile din fundal rulează pe două sisteme de cozi: RQ pe Redis pentru joburile scurte și Dramatiq pe RabbitMQ pentru fluxurile mai grele. Găzduirea clienților rulează în containere LXC pe Proxmox, pe propriile noastre servere. Puteți gestiona totul din browser, dintr-un instrument în linie de comandă scris în Go sau prin asistentul dumneavoastră AI, cu ajutorul MCP. În acest articol trecem prin fiecare nivel și explicăm de ce l-am ales.

Stack-ul dintr-o privire

• Limbaj și framework: Python cu Django, servit de Gunicorn în spatele Nginx.
• Bază de date: PostgreSQL, cu backupuri point-in-time recovery pe un server de backup separat.
• Cache: Redis, folosit prin django-redis și django-cacheops.
• Cozi: RQ (django-rq) pe Redis, plus Dramatiq pe RabbitMQ.
• Găzduire: servere Proxmox VE care rulează fiecare server de client ca un container LXC.
• DNS: propriile noastre servere PowerDNS, de la ns1 la ns4.
• Stocare de obiecte: un sistem self-hosted, compatibil S3, pentru fișiere, backupuri și imaginile de pe blog.
• Instrumente pentru clienți: CLI-ul nameocean (Go) și serverul nostru MCP la distanță pentru clienții AI, ambele construite peste același API public.
• Deployuri: git push plus o singură comandă Fabric. Nimeni nu modifică codul direct pe un server.

Vreți să vedeți cum este construit orice alt site? Website Technology Checker, instrumentul nostru gratuit, arată furnizorul de găzduire, CMS-ul, limbajul de programare și framework-ul oricărui domeniu. Încercați-l pe nameocean.net.

De ce Python și Django

Văzut din afară, un registrar de domenii pare simplu: căutați un nume, plătiți, gestionați DNS-ul. Dedesubt însă se află multă logică de business: API-uri de registrar, transferuri cu propriile mașini de stări, reînnoiri, facturi în mai multe monede, emiterea certificatelor SSL, zone DNS, căsuțe de e-mail și servere de găzduire, toate în 21 de limbi. Ne-am dorit un stack care să păstreze această logică lizibilă și să permită unei echipe mici să livreze în siguranță. Django ne oferă exact asta.

„Batteries included”, cu adevărat

Django vine din start cu componentele de care orice registrar are nevoie din prima zi:

• ORM și migrații. Modelele noastre (domenii, zone, transferuri, facturi, servere) se schimbă în fiecare săptămână. Migrațiile Django transformă fiecare modificare de schemă într-un fișier revizuit în git, care rulează identic local, în teste și în producție.
• Interfața de administrare. Munca de suport și de operațiuni se face în Django admin, așa că nu a fost nevoie să construim un back office intern. O personalizăm acolo unde contează, de exemplu pentru ștergerile sigure și acțiunile de facturare.
• Autentificare și securitate. Sesiunile, protecția CSRF, hashing-ul parolelor și un model de utilizator personalizat, bazat pe adresa de e-mail, sunt incluse. Peste acestea am adăugat autentificarea în doi pași.
• Internaționalizare. Site-ul este tradus în 21 de limbi cu ajutorul instrumentelor gettext din Django și al URL-urilor cu prefix de limbă. Engleza nu are prefix, celelalte limbi primesc /tr/, /de/ și așa mai departe.
• Sitemap-uri, cache, șabloane. Toate standard, toate bine documentate.

Un singur limbaj, de la site până la servere

Python nu înseamnă doar aplicația web. Același limbaj rulează workerii cozilor, comenzile de management din spatele joburilor cron, scripturile care comunică cu Proxmox, instrumentele DNS (dnspython) și scripturile de deploy (Fabric). Un inginer care poate citi view-ul de checkout poate citi și codul care creează un container de găzduire sau reînnoiește un certificat. Pentru o echipă mică, acest lucru contează mai mult decât viteza brută.

Excepțiile sunt instrumentele care rulează pe calculatorul dumneavoastră. A cere fiecărui utilizator să instaleze Python și un set de pachete ar fi o primă experiență proastă, așa că CLI-ul este scris în Go (detalii mai jos). Aceste instrumente nu conțin logică de business proprie: totul trece prin același API Django.

Un ecosistem matur

Aproape tot ce integrăm are o bibliotecă Python solidă: Stripe pentru plăți, Django REST framework pentru API-ul nostru public, clienți S3 în stilul boto, API-ul Proxmox, raportare de erori compatibilă cu Sentry. Serverul nostru MCP la distanță, care le permite asistenților AI să gestioneze domeniile și DNS-ul în numele unui client, face și el parte din aplicația Django.

La ce renunțăm și cum compensăm

Python nu este cel mai rapid limbaj, iar o cerere Django sincronă nu ar trebui să aștepte după un API de registrar lent. Rezolvăm asta în trei moduri: munca grea sau lentă merge într-o coadă, citirile frecvente vin din Redis, iar baza de date este optimizată și indexată pentru tiparele noastre de interogare. În practică, blocajul este aproape întotdeauna un API extern, nu Python.

PostgreSQL: sursa unică de adevăr

Fiecare domeniu, zonă, factură și server se află în PostgreSQL. L-am ales pentru tranzacțiile stricte (banii și dreptul de proprietate asupra domeniilor nu trebuie niciodată scrise pe jumătate), pentru tipurile de date bogate, precum câmpurile JSON și adresele de rețea, și pentru o strategie de backup de încredere. Backupurile sunt continue: write-ahead log-ul este trimis către un server de backup separat, astfel încât putem restaura baza de date în orice moment din timp, nu doar la dump-ul de azi-noapte. Un server web de rezervă, pregătit să preia (warm standby), folosește aceeași bază de date și poate prelua activitatea dacă serverul web principal cade.

Redis: cache-ul pe primul loc

Redis este cache-ul nostru. Verificările de disponibilitate și de preț ale domeniilor, fragmentele de pagină randate și limitele de rată stau toate în Redis, astfel încât o cerere repetată nu ajunge niciodată la API-ul registrarului sau la baza de date. Fiecare cheie de cache include limba, deoarece aceeași pagină diferă între / și /tr/. Folosim și django-cacheops pentru a pune în cache querysets ORM și a le invalida automat atunci când un rând se modifică.

Redis a fost o alegere ușoară: este rapid, simplu de operat și are un suport excelent în Django. Și, pentru că oricum îl avem, susține și coada noastră de joburi ușoare.

Cozi: RQ pe Redis și Dramatiq pe RabbitMQ

Multe dintre acțiunile pornite de un client nu ar trebui să blocheze pagina pe care o vede. Înregistrarea unui domeniu la registry, emiterea unui certificat SSL, crearea unei adrese de e-mail sau pornirea unui container de găzduire durează secunde sau minute. Aceste joburi intră într-o coadă, de unde sunt preluate de workeri. Rulăm două sisteme de cozi, fiecare pentru tipul de muncă la care se pricepe cel mai bine.

RQ (django-rq) pe Redis

RQ este cea mai simplă coadă din lumea Python: un job este o funcție Python împreună cu argumentele ei, stocate în Redis. Îl folosim pentru joburile de zi cu zi ale site-ului:

• crearea contului clientului la registrar după înregistrare,
• emiterea și reînnoirea certificatelor SSL,
• sincronizarea stării domeniilor și a zonelor DNS,
• adăugarea adreselor de e-mail și a regulilor de redirecționare,
• pornirea și oprirea containerelor de găzduire, deschiderea porturilor și configurarea Nginx pentru serverul unui client,
• generarea facturilor și trimiterea memento-urilor de reînnoire.

Un proces de planificare rulează joburile periodice, iar dashboard-ul django-rq afișează joburile din coadă, cele în execuție și cele eșuate direct în admin. În mediul de dezvoltare, coada rulează sincron, așa că un job se execută pe loc, iar erorile apar imediat.

Dramatiq pe RabbitMQ

Pentru fluxurile mai grele și mai lungi folosim Dramatiq, cu RabbitMQ ca broker. RabbitMQ este un broker de mesaje dedicat: mesajele sunt confirmate abia după ce un worker le finalizează, așa că un job nu se pierde dacă un worker se oprește brusc la jumătatea drumului. Dramatiq adaugă peste acestea reîncercări automate cu backoff exponențial, limite de timp, priorități și middleware. Se potrivește sarcinilor cu mulți pași, volumelor mari sau serviciilor externe care mai cad din când în când.

De ce două cozi?

RQ păstrează simple joburile simple: niciun serviciu suplimentar, depanare ușoară, iar Redis rulează deja. RabbitMQ și Dramatiq oferă garanții de livrare mai puternice și un throughput mai bun atunci când un job chiar are nevoie de ele. Alegând în funcție de tipul de sarcină, nu plătim costul operațional al unui broker de mesaje complet pentru un job de cinci secunde și nici nu încredințăm un flux critic celui mai simplu instrument.

Găzduire: Proxmox și containere LXC

Planurile noastre de găzduire și vibe hosting rulează pe propriile servere Proxmox VE. Fiecare server de client este un container LXC, nu o mașină virtuală completă.

• Containerele partajează kernelul gazdei, așa că pornesc în câteva secunde și folosesc mult mai puțină memorie decât mașinile virtuale. O parte mai mare din hardware ajunge la aplicația clientului, în loc să susțină un al doilea sistem de operare.
• Fiecare container este izolat, cu propriul sistem de fișiere, propriile procese, propria rețea și limite de resurse pentru CPU, memorie și disc.
• Totul este automatizat prin API-ul Proxmox. Când comandați un server, Django trimite un job în coadă, iar un worker creează containerul dintr-un șablon, îi setează limitele, atașează rețeaua, deschide porturile și configurează reverse proxy-ul și SSL-ul pentru domeniul dumneavoastră.
• Redimensionarea, backupurile și restaurările sunt butoane în dashboard care apelează același API. Containerele pot fi mutate și între serverele Proxmox atunci când reechilibrăm încărcarea.

Faptul că rulăm pe propriul hardware înseamnă prețuri previzibile și control total asupra rețelei, a backupurilor și a locului în care sunt stocate datele.

DNS, e-mail și stocare

• DNS: zonele sunt servite de propriile noastre servere PowerDNS (de la ns1 la ns4). Modificările pe care le faceți în panoul DNS sunt scrise pe serverul primar și transmise automat către cele secundare. Serverul primar are backup în fiecare noapte.
• E-mail: găzduirea de e-mail și redirecționarea gratuită a e-mailurilor rulează pe propriile noastre servere de e-mail, cu SPF, DKIM și DMARC configurate pentru domeniul dumneavoastră.
• Stocare de obiecte: un sistem self-hosted, compatibil S3, păstrează fișierele încărcate, backupurile și imaginile.

CLI-ul nameocean și serverul MCP

Dashboard-ul web nu este singura cale de acces. Tot ce face acesta trece prin API-ul nostru REST public și prin serverul nostru MCP la distanță de la https://nameocean.net/mcp, iar CLI-ul nameocean este construit peste ele.

CLI-ul nameocean

nameocean este un singur binar static scris în Go, compilat pentru macOS, Linux și Windows, atât pe amd64, cât și pe arm64. Am ales Go aici din motivul opus celui pentru care am ales Python pe server: un CLI trebuie să se instaleze în câteva secunde și să ruleze oriunde fără niciun runtime, iar Go se compilează într-un singur fișier care face exact asta.

• Vă autentificați o singură dată. nameocean login deschide browserul și vă autentifică prin OAuth 2.1 cu PKCE. Tokenurile sunt stocate în keychain-ul sistemului de operare (macOS Keychain, Windows Credential Manager sau libsecret pe Linux) și sunt reîmprospătate automat. Pe servere și în CI puteți folosi în schimb o cheie API din dashboard.
• Servere și porturi. nameocean servers ls, servers info pentru detaliile SSH și git, precum și ports open / ports close pentru a expune un port al containerului.
• Domenii pe servere. nameocean bind example.com <server> configurează DNS-ul, SSL-ul și load balancer-ul cu o singură comandă.
• DNS și SSL. dns ls, dns add și dns rm pentru înregistrări A, CNAME, MX, TXT și altele, plus ssl status și ssl issue --wait.
• Domenii. domains ls și domains check pentru disponibilitate și preț. CLI-ul nu cheltuiește niciodată bani: înregistrările și reînnoirile rămân în dashboard.
• Gândit pentru scripturi și agenți AI. Fiecare comandă acceptă --json și afișează JSON-ul API-ului nemodificat, astfel încât rezultatul poate fi trimis direct către jq, scripturi shell sau un agent.
• O singură comandă pentru clienții AI. nameocean mcp install găsește Claude Code, Cursor și OpenCode pe calculatorul dumneavoastră și adaugă serverul MCP NameOcean în fiecare dintre ele.

nameocean login
nameocean dns add example.com A @ 203.0.113.10 --ttl 5m
nameocean bind example.com 3f9a1c2e
nameocean servers ls --json | jq '.servers[].default_domain'

Îl puteți instala cu Homebrew (brew install nameocean/tap/nameocean) sau puteți descărca o arhivă pentru platforma dumneavoastră.

Serverul MCP la distanță

Pentru vibe hosting, asistentul dumneavoastră AI comunică direct cu NameOcean. O singură comandă conectează Claude Code: claude mcp add --transport http nameocean https://nameocean.net/mcp. Vă autentificați o singură dată în browser, iar de acolo înainte îi puteți cere să facă deploy, să deschidă un port sau să îndrepte un domeniu către serverul dumneavoastră, fără să atingeți vreun fișier de configurare. Cursor, Claude Desktop, claude.ai și alți clienți MCP se conectează la același URL; documentația MCP arată cum. Nimic nu rulează pe calculatorul dumneavoastră, deci nu aveți nimic de instalat sau de actualizat.

Înainte ofeream pentru acest lucru o aplicație desktop. Aceasta pornea un server MCP local și se autentifica cu parolă, lucru incompatibil cu autentificarea în doi pași, iar serverul la distanță face același lucru fără nicio instalare, așa că am retras-o în noiembrie 2026.

De ce amândouă?

Oamenii lucrează în locuri diferite. CLI-ul este pentru dezvoltatorii care trăiesc în terminal și vor comenzi scriptabile și repetabile. Serverul MCP este pentru cei care preferă să descrie ce vor și să-l lase pe asistentul AI să se ocupe de rest. Pentru că ambele sunt straturi subțiri peste același API, o funcționalitate adăugată în aplicația Django ajunge simultan în dashboard-ul web, în CLI și în fiecare client MCP.

Monitorizare și deployuri

Fiecare eroare din producție este raportată unui sistem de urmărire a erorilor self-hosted, compatibil cu Sentry. Verificările de uptime monitorizează fiecare server web, iar metricile ajung într-o bază de date de serii temporale. Deployurile sunt plictisitoare în mod intenționat: facem push în git, rulăm o singură comandă Fabric, iar aceasta actualizează fiecare server web, instalează dependențele, rulează migrațiile, colectează fișierele statice, compilează traducerile și repornește aplicația. Dacă un server are cod învechit, soluția este un nou deploy, niciodată o modificare manuală.

Rezumat

• Python și Django pentru o logică de business lizibilă, interfața de administrare, i18n și un singur limbaj peste tot.
• PostgreSQL ca sursă unică de adevăr, cu point-in-time recovery.
• Redis drept cache și ca backend pentru coada de joburi RQ.
• RQ pentru joburile simple din fundal, Dramatiq pe RabbitMQ pentru fluxurile grele, în care nimic nu are voie să se piardă.
• Containere LXC pe Proxmox pentru o găzduire rapidă, izolată și accesibilă.
• CLI-ul nameocean (Go) și serverul MCP la distanță ca straturi subțiri peste același API.

Sunteți curios ce stă în spatele unui alt site? Verificați-l cu Website Technology Checker. Sunteți gata să vă construiți propriul site? Găsiți un domeniu și găzduiți-l pe NameOcean hosting.