RSS

Oracle Lift and Shift for Java EE

Liczba odsłon: 171

We wto­rek mia­łem okaz­ję uczest­ni­czyć w zor­ga­ni­zo­wa­nych w biu­rach Oracle Polska w Warszawie war­szta­tach Lift and Shift for Java EE and WLS. Ich te­ma­ty­ką by­ło mig­ro­wa­nie ist­nie­ją­cych apli­kac­ji Java EE dzia­ła­ją­cych w śro­do­wis­ku kon­te­ne­ra WebLogic Server z ma­szyn fi­zycz­nych do śro­do­wis­ka zwir­tuali­zo­wa­ne­go skon­fi­gu­ro­wa­ne­go w chmu­rze Oracle IaaS. Warsztaty pro­wa­dzi­li Mark Mundy oraz Stefan Dodel.

Jednym z prob­le­mów, przed któ­rym sto­ją oso­by od­po­wie­dzial­ne za in­fra­struk­tu­rę IT w przed­się­bior­stwach wy­ko­rzy­stu­ją­cych spe­cja­li­zo­wa­ne opro­gra­mo­wa­nie, jest utrzy­ma­nie w ru­chu sta­rych sys­te­mów in­for­ma­tycz­nych. Progra­my pi­sa­ne „pod klucz” i do­sko­na­le speł­nia­ją­ce swo­je za­da­nia nie są ak­tyw­nie roz­wi­ja­ne, a oso­by zna­ją­ce ich bu­do­wę i spe­cy­fi­kę opusz­cza­ją swo­je miej­sca pra­cy. W pew­nym mo­men­cie oka­zu­je się, że pro­gram jest uwią­za­ny do kon­kret­nej wer­sji sys­te­mu opera­cyj­ne­go i bi­blio­tek lub dzia­ła tyl­ko w pew­nej kon­fi­gu­rac­ji sie­ci. Również sprzęt słu­żą­cy do uru­cha­mia­nia kom­po­nen­tów ser­we­ro­wych mo­że być zbyt dro­gi w utrzy­ma­niu lub znaj­do­wać się w sta­nie tech­nicz­nym nie gwa­ran­tu­ją­cym dal­szej po­praw­nej pra­cy.

Jednym z roz­wią­zań jest prze­nie­sie­nie apli­kac­ji w „chmu­rę”. Ponie­waż jed­nak ce­lem jest mi­ni­ma­li­za­cja kosz­tów, nie mo­że­my za­kła­dać moż­li­woś­ci wpro­wa­dza­nia zmian do ko­du lub od­twa­rza­nia funkcjo­nal­noś­ci w no­wym śro­do­wis­ku. Jedyną op­cją jest plat­for­ma IaaS, w któ­rej do­staw­ca prze­ka­zu­je ser­wer wir­tu­al­ny wi­docz­ny w Inter­ne­cie, na któ­rym za­in­sta­lo­wa­ne jest od­po­wia­da­ją­ce nam opro­gra­mo­wa­nie ser­we­ro­we, zgod­ne z prze­no­szo­ną apli­kac­ją.

W ra­mach war­szta­tów za­pre­zen­to­wa­ny zo­stał właś­nie ta­ki sce­na­riusz. Migrowanym pro­gra­mem był BigRez — hi­po­te­tycz­ny sys­tem do re­zer­wo­wa­nia apar­ta­men­tów. Działał on na czte­rech ser­we­rach fi­zycz­nych, z któ­rych je­den rów­no­wa­żył ob­cią­że­nie (bram­ka Apache), dwa rea­li­zo­wa­ły właś­ci­wą funkcjo­nal­ność apli­kac­ji (Oracle WebLogic Server) a je­den prze­cho­wy­wał da­ne (Oracle Database 11g). Wszystkie ser­we­ry dzia­ła­ły pod kon­tro­lą Oracle Linux i by­ły po­łą­czo­ne w trzech od­ręb­nych pod­sie­ciach IP.

Architektura przenoszonego systemu
Architek­tu­ra prze­no­szo­ne­go sys­te­mu
Źródło: ma­teria­ły Oracle

Prowadzą­cy przed­sta­wi­li spo­sób na pra­wie bez­ob­słu­go­we prze­nie­sie­nie apli­kac­ji w „chmu­rę”. Pierwszym kro­kiem jest do­ko­na­nie in­tro­spek­cji, czy­li ana­li­zy wy­ma­gań sta­wia­nych przez apli­ka­cję śro­do­wis­ku, w któ­rym ma dzia­łać. Wyma­ga­nia te trze­ba od­two­rzyć al­bo za­pew­nia­jąc go­to­we śro­do­wis­ko wir­tu­al­ne, al­bo prze­no­sząc kon­fi­gu­rac­ję wraz z apli­kac­ją i da­ny­mi. Ten krok zo­stał wy­ko­na­ny już przed warsz­ta­ta­mi, a nam przed­sta­wio­ne zo­sta­ły je­go wy­ni­ki. Następ­nie po­szcze­gól­ne usłu­gi zo­sta­ły za­trzy­ma­ne oraz zar­chi­wi­zo­wa­ne do po­je­dyn­czych pli­ków .tgz za­wie­ra­ją­cych kod apli­kac­ji, pli­ki kon­fi­gu­ra­cyj­ne oraz da­ne. Za po­mo­cą przy­go­to­wa­nych wcześ­niej skryp­tów pli­ki te zo­sta­ły prze­nie­sio­ne do ob­sza­ru skła­do­wa­nia da­nych w „chmu­rze”.

Mając już ma­teriał po­trzeb­ny do od­two­rze­nia funkcjo­nal­noś­ci, mo­gliś­my przy­stą­pić do utwo­rze­nia ma­szyn wir­tu­al­nych re­pre­zen­tu­ją­cych do­tych­cza­so­we ser­we­ry fi­zycz­ne. W tym ce­lu stwo­rzo­na zo­sta­ła pod­sta­wo­wa ma­szy­na, słu­żą­ca do za­rzą­dza­nia wszyst­ki­mi po­zo­sta­ły­mi oraz prze­te­sto­wa­nia do­stęp­noś­ci da­nych. Do tej ma­szy­ny do­łą­czo­ny zo­stał współ­dzie­lo­ny ob­szar skła­do­wa­nia da­nych, za­wie­ra­ją­cy zgro­ma­dzo­ne in­for­mac­je.

Teraz moż­na by­ło już przy­stą­pić do uru­cho­mie­nia ma­szyn wir­tu­al­nych. Przygo­to­wa­ny wcześ­niej skrypt, uru­cho­mio­ny na wspom­nia­nej ma­szy­nie za­rzą­dza­ją­cej, za po­mo­cą od­po­wied­nich od­wo­łań REST auto­ma­tycz­nie utwo­rzył czte­ry no­we ma­szy­ny wir­tu­al­ne dzia­ła­ją­ce w „chmu­rze”. Dla każ­dej zo­sta­ła wska­za­na właś­ci­wa kon­fi­gu­rac­ja sprzę­to­wa oraz ob­raz sys­te­mu opera­cyj­ne­go, każ­da też otrzy­ma­ła od­po­wied­nią wstęp­ną kon­fi­gu­rac­ję sie­cio­wą (od­po­wia­da­ją­cą wcześ­niej sto­so­wa­nej adre­sa­cji fi­zycz­nej). Z każ­dą no­wą ma­szy­ną zo­sta­ły też po­wią­za­ne li­sty kon­tro­li do­stę­pu, umoż­li­wia­ją­ce okreś­le­nie za­kre­su do­pusz­cza­ne­go ru­chu sie­cio­we­go na pod­sta­wie źród­ła ru­chu oraz do­ce­lo­wej apli­kac­ji (por­tu). Wszystkie czte­ry ma­szy­ny sta­ły się do­stęp­ne w cią­gu kil­ku mi­nut i od ra­zu moż­na by­ło za­lo­go­wać się zdal­nie na każ­dą z nich za po­mo­cą usłu­gi SSH.

Ostatni krok po­le­gał na roz­pa­ko­wa­niu właś­ci­wych ar­chi­wów na po­szcze­gól­nych ma­szy­nach wir­tu­al­nych. Jedynie w przy­pad­ku ma­szy­ny peł­nią­cej ro­lę ba­zy da­nych po­trzeb­ne by­ło jesz­cze za­in­sta­lo­wa­nie bi­blio­te­ki współ­dzie­lo­nej wy­ma­ga­nej przez opro­gra­mo­wa­nie Oracle Database, a nie­dos­tęp­nej stan­dar­do­wo na now­szej wer­sji sys­te­mu Oracle Linux uru­cha­mia­nej z pre­de­fi­nio­wa­nych obra­zów.

W tym mo­men­cie moż­na by­ło przy­stą­pić już do za­re­jes­tro­wa­nia usług w sys­te­mie, by uru­cha­mia­ły się auto­ma­tycz­nie, oraz do włą­cze­nia ich. I fak­tycz­nie, mi­mo cał­ko­wi­te­go zmie­nie­nia śro­do­wis­ka pra­cy apli­kac­ji, ca­łość za­dzia­ła­ła od pierw­sze­go ra­zu: ser­wer Apache ode­brał po­łą­cze­nie i zrów­no­wa­żył ob­cią­że­nie, ser­we­ry apli­ka­cyj­ne ob­słu­ży­ły żą­da­nia, a ser­wer ba­zy da­nych udo­stęp­nił stan obo­wią­zu­ją­cy w mo­men­cie wy­łą­cze­nia sta­rych ser­we­rów fi­zycz­nych.


Jeszcze jed­nym ele­men­tem po­ka­zy­wa­nym w ra­mach war­szta­tów był me­cha­nizm uwie­rzy­tel­nia­nia Oracle Identi­fi­ca­tion Cloud Services (IDCS). Pozwala on na uzu­peł­nie­nie stan­dar­do­wych me­cha­niz­mów JAAS o ob­słu­gę me­cha­niz­mu jed­no­krot­ne­go uwie­rzy­tel­nia­nia zgod­ne­go mię­dzy in­ny­mi z OAuth. Pozwala to na zlik­wi­do­wa­nie we­wnętrz­nej ba­zy da­nych użyt­kow­ni­ków oraz reali­zo­wa­nie uwie­rzy­tel­nia­nia za po­mo­cą wie­lu róż­nych zew­nętrz­nych usług.

Urucho­mie­nie IDCS po­le­ga wy­łącz­nie na za­in­sta­lo­wa­niu w kon­te­ne­rze apli­kac­ji Java EE od­po­wied­nie­go mo­du­łu roz­sze­rza­ją­ce­go. W przy­pad­ku kon­te­ne­ra Oracle WebLogic 11g, któ­ry sta­no­wił pod­sta­wę apli­kac­ji BigRez, in­sta­lac­ja wy­ma­ga­ła wie­lu ręcz­nie wy­ko­ny­wa­nych kro­ków, gdyż wer­sja ta nie jest jesz­cze ofi­cjal­nie ob­słu­gi­wa­na. Nowsze wer­sje ob­słu­gu­ją IDCS stan­dar­do­wo. Również od­po­wied­nie mo­du­ły roz­sze­rza­ją­ce do­sto­so­wa­ne do star­szych wer­sji zo­sta­ną po­dob­no nie­dłu­go udos­tęp­nio­ne.


Warsztaty po­ka­za­ły, że moż­li­we jest – w cza­sie li­czo­nym w go­dzi­na­ch, a nie dniach lub mie­sią­cach – zlik­wi­do­wa­nie czte­rech spra­wia­ją­cych prob­le­my ser­we­rów fi­zycz­nych i prze­nie­sie­nie ca­ło­ści funkcjo­nal­noś­ci w chmu­rę. Takie roz­wią­za­nie, je­że­li po­li­czy się kosz­ty ener­gii elek­trycz­nej, ob­słu­gi sprzę­tu, chło­dze­nia ser­we­row­ni oraz two­rze­nia za­pa­so­wych kopii da­nych, mo­że oka­zać się co naj­mniej kon­ku­ren­cyj­ne ce­no­wo, a da­je znacz­nie wyż­szy po­ziom bez­pie­czeń­stwa i do­stęp­noś­ci.

Jednocześ­nie na­le­ży za­uwa­żyć, że plat­for­my IaaS to roz­wią­za­nia ma­ło wy­ra­fi­no­wa­ne, ma­ją­ce cha­rak­ter przej­ścio­wy. Charakte­ry­zu­ją się one du­żym sto­pniem mar­no­wa­nia za­so­bów, gdyż za­miast ko­rzy­stać ze wspól­nych usług, po­wie­la się opro­gra­mo­wa­nie sys­te­mo­we i apli­ka­cyj­ne. Stworzone w ra­mach war­szta­tów roz­wią­za­nie wy­ma­ga­ło kil­ku­dzie­się­ciu gi­ga­baj­tów prze­strze­ni dys­ko­wej oraz kil­ku­na­stu gi­ga­baj­tów pa­mię­ci opera­cyj­nej — a uru­cha­mia­ną apli­kac­ją był pros­ty sys­tem re­zer­wa­cji apar­ta­men­tów.

Szukając roz­wią­za­nia prob­le­mu prze­nie­sie­nia apli­kac­ji ty­pu le­ga­cy w śro­do­wis­ko chmu­ro­we po­win­no się za­tem spoj­rzeć na ofer­tę fir­my Oracle. Warto jed­nak jed­no­cześ­nie pa­mię­tać, że je­że­li sys­tem ma dzia­łać dłu­go­fa­lo­wo i pod­le­gać zmia­nom lub roz­sze­rze­niom, i tak mo­że­my zo­stać zmu­sze­ni do prze­bu­do­wa­nia go lub wręcz od­two­rze­nia od no­wa. W ta­kim przy­pad­ku war­to oprzeć się na roz­wią­za­niach ty­pu PaaS , w któ­rych od­po­wie­dzial­ność za kon­fi­gu­rac­ję i dzia­ła­nie opro­gra­mo­wa­nia ba­zo­we­go (sys­te­my opera­cyj­ne, kon­te­ne­ry apli­kac­ji, ba­zy da­nych) oraz za do­stęp­ność i bez­pie­czeń­stwo da­nych (ko­pie za­pa­so­we) zrzu­ca­my na do­staw­cę plat­for­my, a sa­mi sku­pia­my się tyl­ko na wdro­że­niu jak naj­lep­szej apli­kac­ji.

Dla osób chcą­cych sto­so­wać roz­wią­za­nia chmu­ro­we war­szta­ty ta­kie, jak zor­ga­ni­zo­wa­ne przez Oracle Polska oraz Arrow są bar­dzo cen­ne. Warto pod­kre­ślić tu wy­so­ki po­ziom or­ga­ni­za­cji szko­le­nia. Prelegenci by­li świet­nie przy­go­to­wa­ni, uczest­ni­cy do­sta­li bar­dzo szcze­gó­ło­we in­struk­cje wy­ko­ny­wa­nia ćwi­czeń, a dzię­ki wcześ­niej­sze­mu spraw­dze­niu ich po­praw­noś­ci nie by­ło żad­nych prob­le­mów z reali­zac­ją po­szcze­gól­nych ćwi­czeń. Bardzo na­pię­ta agen­da spot­ka­nia nie sta­no­wi­ła żad­ne­go prob­le­mu, a róż­ni­ce w go­dzi­na­ch roz­po­czę­cia i za­koń­cze­nia po­szcze­gól­nych częś­ci za­my­ka­ły się w gra­ni­cy 10 mi­nut.