6. Windows + Linux azpiegitura hibridoa¶

Ingurune erreal askotan, Windows Server eta Linux elkarrekin bizi dira: batek erabiltzaileak eta politikak zentralizatzen ditu, eta besteak web aplikazioak ostatatzen ditu. Atal honetan, moduluaren erronkan erabiliko duzun antzeko eszenatoki hibrido bat diseinatuko dugu.

6.1. Laborategi hibridoaren arkitektura¶

6.1.1. Osagai nagusiak¶

Laborategian gutxienez hiru "pieza" izango ditugu:

Windows Server domeinu-kontrolatzailea (DC)
Active Directory Domain Services (AD DS) rola.
Domeinuan integratutako DNS zerbitzua.
Ekipo eta erabiltzaileei aplikatutako GPO posibleak.
Linux zerbitzaria (LAMP)
Linux sistema eragilea (adibidez, Ubuntu Server, Rocky, Debian…).
LAMP pila edo antzekoa:
- Web zerbitzaria (Apache/Nginx).
- PHP (Laravelerako).
- Datu-basea (MySQL/MariaDB/PostgreSQL).
Laravel + Vue.js + Tailwind bidez garatutako web aplikazioa.
Backup gunea
Hau izan daiteke:
- Bigarren disko/partizio bat Linux zerbitzarian.
- Backup-zerbitzari dedikatu bat (ingurune errealetan ideia ona).
Helburua: Windows eta Linuxen kopiak puntu komun batean zentralizatzea.

Ikuspegi logiko (sinplifikatua) adibide gisa:

Laborategiko barne-sarea.
DC1 (Windows Server): dc1.enpresa.local → AD + DNS.
WEB1 (Linux): web1.enpresa.local → LAMP + Laravel aplikazioa.
BACKUP (bigarren diskoa duen WEB1 bera izan daiteke, edo hirugarren zerbitzari bat): kopiak gordetzen ditu.

6.1.2. Lan-fluxu oinarrizkoa¶

Erabiltzaileak Active Directoryn existitzen dira.
Ikasle eta irakasleen kontuak.
Talde espezifikoak (adibidez, WEBDEV, ERABILTZAILEAK_APP, eta abar).
Windows ekipoak domeinuan autentikatzen dira DCren aurka, aurreko kapituluetan ikusi duzun bezala.
Linux zerbitzaria domeinuan integratzen da, honako hauek ahalbidetzeko:
ADko erabiltzaile/talde jakin batzuek SSH bidez sartzea.
Web aplikazioaren direktorioetan baimenak ematea ADko erabiltzaile/taldeen bidez.
Backupak politika komun batekin (RPO/RTO) antolatzen dira, baina tresna desberdinekin:
Windows Server-ek Windows Server Backup erabiltzen du.
Linuxek rsync/tar/Borg/Restic bezalako tresnak erabiltzen ditu.
Kopien helmuga zentralizatzen da (normalean Linuxen edo backup-zerbitzari dedikatuan).

Laborategiko praktikan, arkitektura hau makina birtual lokaletan edo AWS Academyn (EC2 Windows + EC2 Linux) muntatu daiteke.

6.2. Identitate-kudeaketa Active Directory-rekin¶

Ideia nagusia da Active Directory izatea identitateen iturri bakarra (erabiltzaile eta taldeak), bai Windowsentzat bai, neurri handi batean, Linuxentzat ere.

6.2.1. AD erabiltzaile eta taldeen "egia" gisa¶

Aurreko kapituluetan ikusi duzu nola:

Erabiltzaileak eta taldeak sortu ADn.
Kontuak OU-etan antolatu.
GPOak aplikatu OU, talde eta abarren arabera.

Ingurune hibridoan helburu bat gehiago gehitzen dugu: erabiltzaile/talde horiek Linuxen sarbidea kontrolatzeko ere balio dezatela (SSH, aplikazioaren baimenak, etab.).

Ikuspegi honen abantailak:

Kontuak sortu, aldatu edo desaktibatzeko leku bakarra.
Sistema desberdinen artean "bikoiztutako erabiltzaile" gutxiago.
Politika koherenteak: ADn erabiltzaile bat baja ematean, Linux zerbitzarira sartzeko aukera ere galduko du.

6.2.2. Linux domeinura integratzeko baldintzak¶

Kontzeptu-mailan, Linuxek honakoak behar ditu:

Domeinuko izenak ebaztea (DCren DNSa erabiliz).
Domeinuaren realm-a eta Kerberos/LDAP konfigurazioa ezagutzea (adibidez, ENPRESA.LOCAL).
ADrekin "zubi" lanak egingo duen Linuxeko zerbitzua:
sssd + realmd (distro moderno askotan), edo
winbind (Samba paketeak).

Orokorrean jarraitzen diren pauso tipikoak (komando zehatzen xehetasunik gabe oraindik):

Linuxen DNS ebazpena konfiguratzea DCren DNSa erabiltzeko (dc1.enpresa.local).
Konektibitatea egiaztatzea:
ping dc1.enpresa.local
dig enpresa.local edo antzeko tresnak.
Domeinura batzeko behar diren paketeak instalatzea (distroaren arabera: realmd, sssd, adcli, etab.).
Linux zerbitzaria domeinura batzea, honelako komando batekin:
realm join ENPRESA.LOCAL -U Administratzailea (adibide orokorra).
Orain ADko erabiltzaile eta taldeak Linuxetik ikus daitezkeela egiaztatzea (adib. id erabiltzailea@ENPRESA.LOCAL).

6.2.3. Laborategiko erabilera praktikoa¶

Behin domeinura batuta, erabaki dezakezu zer rol izango duen ADk Linuxen:

SSH sarbidea ADko talde baten bidez kontrolatzea
Talde bat definitu ADn (adibidez, GRP_WEBDEV).
Linux konfiguratzea talde horretako kideek bakarrik sartu ahal izateko SSH bidez.
Laravel aplikazioaren baimenak
Irakurketa/idazketa baimenak ematea /var/www/enpresa-app direktorioan ADko talde bati.
Aplikazioa desplegatzeko prozesua (git pull, artisan, etab.) zerbitzu-kontu batek edo GRP_WEBDEV taldeko kideek exekutatzea.

Kapituluaren gainerakoan (6.3 eta hurrengoak) ikusiko duzu identitate-kudeaketa hau nola lotzen den aplikazioaren despleguekin eta backup estrategiarekin.

6.3. LAMP zerbitzaria web aplikaziorako¶

Linux zerbitzarian Laravel + Vue.js + Tailwind oinarritutako web aplikazioa desplegatuko da, LAMP (edo Nginx erabiltzen bada LEMP) motako pila erabiliz.

6.3.1. Pila osagaiak¶

Web zerbitzaria: Apache edo Nginx.
PHP: Laravel bertsioarekin bateragarria den bertsioa.
Datu-basea: MySQL/MariaDB/PostgreSQL.
Node.js + npm/yarn: Vue.js + Tailwind-eko asset-ak konpilatzeko.

Laborategian ez gara osagai bakoitzaren instalazio-zehaztasun guztietan sakonduko, baina garrantzitsua da argi izatea zer non dagoen, gero kopiak eta berreskurapenak ondo planifikatzeko.

6.3.2. Aplikazioaren bide kritikoak¶

Laravel desplegu tipiko batek Linuxen honako egitura izan dezake:

Aplikazioaren kodea: /var/www/enpresa-app.
Laravel-en PHP kodea, Vue osagaiak, konfigurazio fitxategiak, etab. biltzen ditu.
Aplikazioaren datu-direktorioak:
storage/ → log-ak, aplikazioak sortutako fitxategiak, cache-ak, etab.
public/ → baliabide publikoak (konpilatutako CSS/JS, irudi publikoak…).
Erabiltzaileek igotako fitxategiak:
Normalean storage/app barruan edo konfiguratutako beste bide batzuetan gordetzen dira.
.env fitxategia:
Konfigurazio sentikorra dauka (DB konexioa, gakoak, etab.).

Gainera, aplikazioaren datu-basea (adibidez, enpresa_db) konfiguratutako DB motorean egongo da. Kopietarako, erosoagoa izaten da dump logikoak (SQL) egitea, datu-fitxategiak zuzenean kopiatzea baino.

6.3.3. Backup eta berreskurapenerako ondorioak¶

Backup ikuspegitik, garrantzitsuena da identifikatzea:

Aplikazioa berreraikitzeko gorde behar dituzun karpeta eta fitxategiak:
Kodea + .env + storage/ + igotako fitxategiak.
Nola gordeko duzun datu-basea:
mysqldump/pg_dump erabiltzen duten script-ak .sql edo .sql.gz fitxategiak sortzeko.
Nola egingo duzun berreskurapen proba:
VM/klon bat sortu eta kodea + DB dump-ak berreskuratzea.

Erronka finalean, LAMP zerbitzaria eta Windows domeinua batera ibiliko dira: erabiltzaileak ADn, aplikazioa Linuxen eta backupak 6.4 atalean definitutako politikaren arabera koordinatuta.

6.4. Backup estrategia ingurune hibridoan¶

6.4.1. Kopiak Windows Serverretik¶

5. kapituluko (Backups) atalean jada ikusi duzu:

Kontzeptu orokorrak: RPO/RTO, kopia motak, 3-2-1 araua (5.1).
Nola egin kopiak Windows Server-en Windows Server Backup erabiliz (5.2).
Nola egin kopiak Linuxen rsync, tar, Borg/Restic, etab. erabiliz (5.3).

6.4 atalean ez dugu teoria osoa errepikatuko; baizik eta 6.1ean definitutako eszenatoki hibridoan aplikatuko dugu.

6.4.1. Kopiak Windows Serverretik¶

Kopien iturburu nagusiak:
System State edo sistemaren egoera: AD, GPO, erregistroa, konfigurazio kritikoa.
DCren mende dauden partekatutako karpetak eta profilak.
Tresna: Windows Server Backup, 5.2 atalean ikusi bezala.
Ingernu hibrido baterako gomendatutako helmuga:
Sareko karpeta bat Linux zerbitzarian edo backup-zerbitzari dedikatuan.
Adibidea: \\backup-linux\\wsb edo antzeko bidea.

6.4.2. Kopiak Linuxetik¶

Kopien iturburu nagusiak:
Laravel + Vue aplikazioaren kodea (/var/www/enpresa-app).
storage direktorioak eta erabiltzaileek igotako fitxategiak.
Datu-basea (dump periodikoak mysqldump/pg_dump erabiliz, etab.).
Erabili daitezkeen tresnak (5.3 atalean ikusitakoak):
rsync → /mnt/backup/host1/ edo antzeko karpetara sinkronizatzeko.
tar → kopia osoak paketatu eta konprimatzeko.
Borg/Restic → errepositorio deduplikatua nahi bada.
Gomendatutako helmuga:
Windows-ek erabiltzen duen backup-zerbitzari bera (adibidez, Linuxen disko dedikatu bat).

6.4.3. RPO/RTO politika bateratua¶

5.1 atalean emandako adibideetan oinarrituta, laborategirako honelako zerbait defini daiteke:

RPO: gehienez lanegun bateko datu-galera onartzen dugu.
RTO: ordu batzuetan berriro martxan egotea onargarria da.

Windows + Linux aplikatuta:

Astean behingo kopia osoak: Windows (System State + datuak) eta Linux (kodea + DB + datuak).
Eguneroko inkrementalak (edo rsync-ekin eguneroko sinkronizazioak) bi sistemetan.
Gutxienez kopia bat ekoizpeneko euskarritik desberdinean gordea (bigarren diskoa, backup-zerbitzaria, etab.).

AWS Academynko inplementazioan, helburu berberak EBS snapshot-etan, AMI-etan eta, erabiltzen bada, AWS Backup-en bidez gauzatuko dira.

6.5. Eszenatokia AWS Academy-ra eramatea¶

AWS Academyn eszenatoki hibrido bera berreraiki ahal izango duzu AWSren baliabideak erabiliz. Goi-mailan, honako mapaketa hau izango litzateke:

On‑prem DC Windows → EC2 Windows Server instantzia
Sistema-diskoa EBS-en.
EBS snapshot-ak bloke mailako kopietarako.
AMI sortzeko aukera, instantziaren irudi osoak edukitzeko.
On‑prem LAMP zerbitzaria → EC2 Linux instantzia
Laravel + Vue + Tailwind kodea desplegatuta /var/www/enpresa-app bidean.
Datu-basea → RDS (aukera moduan) edo EC2 barruko DB zerbitzaria.
EBS snapshot-ak bolumenetarako.
Backup zerbitzaria / NAS → aukera desberdinak AWSn:
Disko handia duen EC2 Linux, bertan Borg/Restic/rsync erabiliz kopiak kontsolidatzeko.
S3 biltegi gisa (fitxategi kopiak eta dump-ak gordetzeko).
AWS Backup erabiliz EBS, RDS eta abar automatikoki babesteko (laborategian bertsio sinpleago batekin lan egin daiteke).

Helburua ez da AWSren produktu guztiak sakon ikastea, baizik eta ikustea nola itzultzen diren on‑prem kontzeptu berak (DC + LAMP + backups) hodeiko azpiegitura batera.