Migracija legacy Perl aplikacije sa starog servera na UpCloud

U ovom projektu trebalo je prebaciti staru Perl web aplikaciju sa jednog fizičkog servera na savremeniju cloud infrastrukturu. Zadatak nije bio da se aplikacija prepiše od nule, već da se radni sistem pažljivo premesti, da se podaci razdvoje po normalnim infrastrukturnim slojevima i da se smanje operativni rizici.

Početno stanje je bilo tipično production okruženje iz 2000-ih: jedan server, Apache, Perl aplikacija, MySQL na istoj mašini i nekoliko gigabajta slika na lokalnom disku. Kod aplikacije nije bio veliki, ali se ceo sistem oslanjao na stare pretpostavke: lokalne putanje, Apache pravila, strukturu fajlova i specifičnosti stare MySQL baze.

Za novu infrastrukturu izabran je UpCloud: aplikacija je mogla da se izdvoji na poseban compute, baza u managed MySQL, a slike u object storage sa S3-kompatibilnim API-jem. Takav pristup traži više pažljive migracione pripreme nego prenos "kao što jeste" na jedan VPS, ali daje jasniji model održavanja posle pokretanja.

Pošalji brif

Zadatak

Trebalo je premestiti legacy aplikaciju na novu infrastrukturu bez gubitka podataka i bez nepotrebnog zadiranja u staru poslovnu logiku. Za to je bilo potrebno:

• razumeti staru vezu između Apache-a, Perla, MySQL-a i fajlova sa slikama;
• pripremiti ciljno okruženje na UpCloud-u;
• preneti MySQL bazu veličine oko 5 GB;
• pripremiti prenos nekoliko gigabajta slika u object storage;
• sačuvati rad starih URL-ova i pravila za isporuku fajlova;
• dogovoriti trenutak zamrzavanja podataka pre finalnog prebacivanja;
• ostaviti stari server kao fallback tokom perioda posle go-live trenutka.

Zašto ovo nije samo kopiranje fajlova

Legacy aplikacije često izgledaju male po količini koda, ali su složene po okruženju. U takvim projektima glavni posao ne počinje pisanjem novih funkcija, već razumevanjem skrivenih zavisnosti: gde se nalaze fajlovi, koja Apache pravila učestvuju u isporuci slika, kako se aplikacija povezuje na bazu, koje putanje su upisane u konfiguraciji i koje osobine stare šeme podataka su godinama bile podrazumevane.

Stari server je radio po principu "sve na jednom mestu": aplikacija, baza, web server i slike živeli su na istoj mašini. To je zgodno za početno pokretanje, ali vremenom postaje rizik: ažuriranja, backup, oporavak, bezbednost i dijagnostika zavise od jednog čvora.

Ciljna šema je razdvajala odgovornosti:

• compute: runtime za Perl aplikaciju i web server;
• managed MySQL: odvojen upravljani sloj za bazu podataka;
• object storage: odvojeno skladište za slike;
• stari server: privremeni fallback za slučaj vraćanja posle prebacivanja.

Slika 1. Migracija legacy Perl aplikacije: aplikacija, baza podataka i slike razdvajaju se između compute sloja, managed MySQL-a i object storage-a.

Migracioni plan

Za klijenta je bilo važno opisati migraciju kao kontrolisan proces, a ne kao jednokratno "prebacivanje" servera. Plan je bio zasnovan na jasnim fazama:

1. Pripremiti servise na UpCloud-u.
2. Napraviti pun backup starog sistema.
3. Podignuti okruženje za Perl aplikaciju.
4. Importovati bazu u UpCloud Managed MySQL.
5. Preneti slike u object storage.
6. Proveriti aplikaciju, URL-ove i isporuku fajlova.
7. Po potrebi uraditi finalnu sinhronizaciju.
8. Dogovoriti prebacivanje production saobraćaja.
9. Pratiti sistem posle pokretanja.
10. Sačuvati stari server dostupan kao fallback.

Posebno je definisan freeze point: posle uzimanja backup-a i početka prenosa, nove izmene na starom serveru više ne prelaze automatski u novi sistem. Za ovakve migracije to je kritičan organizacioni detalj. Ako se ne dogovori unapred, tehnički prenos može biti korektan, ali podaci mogu da se raziđu u trenutku prebacivanja.

MySQL: problem stare šeme

Najneprijatniji deo nije bio u Perl kodu, već u razlikama između pretpostavki stare baze i managed MySQL-a. U legacy bazi su postojale tabele bez primary key-a. Na starom self-hosted MySQL-u to je radilo, ali upravljani MySQL servis može biti stroži zbog zahteva za replikaciju, backup i oporavak.

Zbog toga direktan import dump-a ne prolazi uvek. Ako je u servisu uključeno obavezno postojanje primary key-a, staru šemu treba prilagoditi: dodati surrogate primary key u problematične tabele i pažljivo uskladiti dump sa novom strukturom.

Tu postoji važna tehnička zamka. Ako se doda nova kolona sa primary key-em, stari izrazi oblika INSERT INTO table VALUES (...) mogu da se pokvare: broj i redosled kolona više ne odgovaraju starom dump-u. Zato za takve tabele treba prepisati insert u formu sa eksplicitnim spiskom kolona.

INSERT INTO old_table (old_column_1, old_column_2, old_column_3)
VALUES (...);

Ovo je mali primer zašto migracija stare baze u managed servis nije samo pitanje brzine importa. Treba proveriti koje tehničke pretpostavke je stari MySQL godinama tolerisao, a novo okruženje ih više ne prihvata.

Slike i object storage

Slike su bile poseban deo posla. U starom sistemu nalazile su se na lokalnom disku i isporučivale preko Apache pravila. Pritom su pravila pristupa na starom serveru mogla da ometaju normalnu isporuku slika, pa nije bilo dovoljno proveriti samo da fajlovi postoje. Trebalo je proveriti ceo put od URL-a do odgovora web servera.

U novoj šemi slike su planirane za UpCloud Object Storage. To je S3-kompatibilno skladište, pa se za upload mogu koristiti poznati alati kao što je AWS CLI, ali sa UpCloud endpoint-om i credentials podešavanjima.

U praksi "S3-compatible" ne znači da svaki klijent sa podrazumevanim podešavanjima odmah radi savršeno sa svakim skladištem. Tokom upload-a pojavila se greška XAmzContentSHA256Mismatch na PutObject. Takve probleme treba hvatati na realnim fajlovima, jer zavise od potpisa zahteva, checksum-a, payload signing-a i osobina konkretnog S3-compatible endpoint-a.

Za projekat je to značilo da prenos slika nije mogao da se tretira kao običan rsync. Trebalo je osmisliti layout bucket-a, mapiranje starih putanja na nove URL-ove i posebno proveriti isporuku fajlova posle prenosa.

Zašto UpCloud

U ovakvim zadacima uvek postoji iskušenje da se sve prebaci na jedan novi VPS i što vernije ponovi stara arhitektura. To je brže i traži manje izmena, ali ostavlja isti operativni model: samostalno održavanje MySQL-a, backup-a, ažuriranja, bezbednosti i oporavka.

Varijanta sa UpCloud-om bila je zanimljiva upravo kao upravljivija infrastruktura: aplikacija ostaje mali compute sloj, baza prelazi u managed MySQL, a teški fajlovi odlaze u object storage. Za staru, ali i dalje korisnu aplikaciju to je često razuman kompromis između "prepisati sve" i "ostaviti kako je bilo".

Rezultat

• Razmotren je stari single-server setup sa Apache-om, Perl-om, MySQL-om i lokalnim slikama.
• Pripremljena je ciljna šema migracije na UpCloud sa razdvajanjem aplikacije, baze i fajl skladišta.
• Obrađen je prenos MySQL dump-a od oko 5 GB uz tabele bez primary key-a.
• Opisan je pristup prilagođavanju dump-a: surrogate primary keys i eksplicitni spiskovi kolona u insert izrazima.
• Razmotren je prenos slika u S3-compatible object storage i povezani edge cases.
• Za klijenta je fiksiran migration plan: backup, import, test, cutover, monitoring i fallback.
• Posebno je označen freeze point kako se pri prebacivanju ne bi izgubile izmene napravljene na starom serveru posle backup-a.

Kome odgovara ovakav format

• Projektima na Perl-u, PHP-u ili drugom legacy stack-u koji i dalje rade i donose vrednost.
• Sistemima gde je istorijski sve na jednom serveru: aplikacija, baza, fajlovi i web server.
• Vlasnicima projekata kojima treba migracija bez potpunog prepisivanja poslovne logike.
• Timovima koji žele da izmeste bazu u managed servis, a fajlove u object storage.
• Projektima gde je važno unapred isplanirati downtime, sinhronizaciju podataka i fallback.

Ako je potreban sličan rezultat: pomažem da se razume staro okruženje, pripremi plan migracije, prenesu baza i fajlovi, proveri aplikacija posle preseljenja i sačuvaju podaci u trenutku prebacivanja.

Pošalji brif