WebSphere-alkalmazások migrálása Azure-beli virtuális gépekre

  • Cikk

Ez az útmutató azt ismerteti, hogy mire érdemes figyelnie, amikor egy meglévő, hagyományos WebSphere Application Server (WAS) alkalmazást szeretne migrálni az Azure-beli virtuális gépeken való futtatáshoz. Az Azure Marketplace-en elérhető WAS hagyományos megoldások áttekintéséért tekintse meg az IBM WebSphere termékcsalád Azure-beli futtatásának megoldásait.

A migrálás előtt

A sikeres migrálás biztosításához a kezdés előtt végezze el az alábbi szakaszokban leírt értékelési és leltározási lépéseket.

Határozza meg, hogy mit takar a befejezett migrálás

Ez az útmutató és a kapcsolódó Azure Marketplace-ajánlatok kiindulópontként szolgálnak a WAS hagyományos számítási feladatainak Azure-ba való migrálásának felgyorsításához. Fontos definiálni a migrálási folyamat hatókörét. Például szigorúan csak átemelést („lift and shift”) alkalmaz meglévő infrastruktúrájából az Azure Virtual Machines szolgáltatásba? Ha igen, megpróbálhatja a „lift and improve” módszert is.

Azonban célszerű leginkább az átemeléses módszer mellett maradni, és figyelembe venni az útmutatóban ismertetett változásokat. Határozza meg, hogy mit takar a „befejezett migrálás”, így tudni fogja, hogy mikor érte el ezt a mérföldkövet. Amikor elérte a "migrálás befejeződött", pillanatképet készíthet a virtuális gépekről a virtuális merevlemez pillanatképének létrehozása című szakaszban leírtak szerint. Miután ellenőrizte, hogy sikeresen visszaállítható-e a pillanatképből, anélkül végezheti el a fejlesztéseket, hogy ne kelljen tartania az eddig elért migrálási folyamat elvesztésétől.

Győződjön meg arról, hogy a cél a megfelelő cél a migrálási munkához

A WAS-alkalmazások Azure-ba történő sikeres migrálásának első lépése a legmegfelelőbb migrálási cél kiválasztása.

A WAS hagyományosan jól működik az Azure-beli virtuális gépeken. A virtuális gép (VM) cél a legegyszerűbb választás, mivel a leginkább hasonlít egy helyszíni üzembe helyezésre. A virtuális gépek felügyeleti és üzembe helyezési élménye a helyszíni környezethez hasonló.

Egy másik lehetőség a tárolókba való migrálás a WAS hagyományos számítási feladatainak alkalmazástárolókká alakításával. A tárolócélt az Azure Kubernetes Service (AKS) és az Azure Red Hat OpenShift szolgáltatásban futtathatja. Ennek a könnyű kezelésnek a kompromisszumoje a gazdasági költség.

Általánosságban elmondható, hogy a virtuálisgép-alapú megoldások percenkénti költsége magasabb a tárolókhoz képest. Bár egy tárolóalapú megoldás futtatása kevesebbe kerül, korlátoznia kell az alkalmazást, hogy megfeleljen a tárolóvezénylési platform követelményeinek.

Ha a módosítás minimalizálása a migrálási munka legfontosabb tényezője, fontolja meg a virtuális gépalapú migrálást. Ebben az esetben lásd : WebSphere-alkalmazások migrálása azure-beli virtuális gépekre.

Ha el tudja viselni, hogy az alkalmazást tárolókon belüli futtatásra konvertálja a futtatókörnyezet költségeinek csökkentése érdekében, fontolja meg az AKS-alapú vagy az Azure Red Hat OpenShift-alapú migrálást.

Az AKS-alapú migráláshoz használhatja az ingyenes szintet. Ingyenes fürtkezelést kérhet, és csak a felhasznált virtuális gépekért, a társított tárterületért és a hálózati erőforrásokért kell fizetnie. Ebben az esetben lásd : WebSphere-alkalmazások migrálása az Azure Kubernetes Service-be.

Az Azure Red Hat OpenShift-alapú migrálás esetén az alkalmazáscsomópontok a számítási és infrastrukturális költségek mellett az OpenShift-licenc összetevőjének egy másik költségével is rendelkeznek. Ez a költség az alkalmazáscsomópontok száma és a példány típusa alapján kerül számlázásra. Igény szerinti díjszabást vagy fenntartott példányokat használhat, amelyik a legjobban megfelel a számítási feladat és az üzlet igényeinek. Ebben az esetben lásd : WebSphere-alkalmazások migrálása az Azure Red Hat OpenShiftbe.

Az Azure Red Hat OpenShift dokumentációjának útmutatói a migrálás szempontjából releváns szempontokat ismertetik. Az útmutatók teljes listáját az Azure Red Hat OpenShift dokumentációjában találja.

Annak meghatározása, hogy az előre összeállított Azure Marketplace-ajánlatok jó kiindulópontok-e

Az IBM és a Microsoft együttműködött, hogy azure-megoldássablonokat hozzon létre az Azure Marketplace-re, hogy biztos kiindulópontot biztosítson az Azure-ba való migráláshoz. Az ajánlatok listájáért tekintse meg a WebSphere termékcsalád és a Microsoft Azure-beli Liberty futtatása című témakört, majd válassza ki azt, amelyik a leginkább megfelel a meglévő üzembe helyezésnek. Az ajánlatok listáját az áttekintési cikkben találja: Mik azok a megoldások, amelyek az IBM WebSphere termékcsaládot futtatják az Azure-ban?

Ha egyik meglévő ajánlat sem jó kiindulópont, akkor kézzel kell reprodukálnia az üzembe helyezést az Azure Virtual Machine-erőforrások használatával. A részletes útmutatót a következő oktatóanyagban találja: Az IBM WebSphere Application Server hálózati üzembe helyezésének manuális telepítése hagyományosan az Azure-beli virtuális gépeken. További információ: Mi az IaaS?

Annak meghatározása, hogy a WAS hagyományos verziója kompatibilis-e

A meglévő WAS hagyományos verziójának kompatibilisnek kell lennie az IaaS-ajánlatokban szereplő verzióval. A verzióinformációkat az AZURE-beli virtuális gépeken futó IBM WebSphere Application Server Single Instance és az Azure-beli virtuális gépeken futó IBM WebSphere Application Server-fürt áttekintési oldalán találja. Ha a meglévő WAS hagyományos verziója nem kompatibilis ezzel a verzióval, manuálisan kell reprodukálnia az üzembe helyezést az Azure IaaS-erőforrások használatával. További információ: Mi az IaaS?

A leltárkiszolgáló kapacitása

Dokumentálja a jelenlegi éles kiszolgálók hardverét (memória, CPU, lemez), valamint az átlagos és a kiugró kérésszámokat, illetve az erőforrás-használatot. Ezek az adatok határozzák meg a virtuális gép méretét. További információ: A Cloud Services méretei.

Az összes titkos kód leltározása

A szolgáltatásként nyújtott konfigurációs technológiák (például az Azure Key Vault) elterjedése előtt a titkos kódok fogalma kissé homályos volt. Ehelyett olyan eltérő konfigurációs beállítások közül választhatott, amelyek tulajdonképpen a mai titkos kódoknak feleltek meg. Az olyan alkalmazáskiszolgálók esetében, mint a WAS, ezek a titkos kódok számos különböző konfigurációs fájlban és konfigurációs tárolóban találhatók. Ellenőrizze az éles kiszolgáló(k) minden tulajdonságát és konfigurációs fájlját titkos kódokhoz és jelszavakhoz. Az alkalmazásban jelszavakat vagy hitelesítő adatokat tartalmazó konfigurációs fájlok is szerepelhetnek. A WAS több dokumentumban tárolja a konfigurációs adatokat a címtárak kaszkádolt hierarchiájában. A legtöbb konfigurációs dokumentum XML-tartalommal rendelkezik. További információkért tekintse meg a konfigurációs dokumentumokat és az Azure Key Vault alapfogalmait.

Az összes tanúsítvány leltározása

Dokumentáljon minden, nyilvános SSL-végponthoz használt tanúsítványt. A következő parancs futtatásával megtekintheti az éles kiszolgáló(ko)n található összes tanúsítványt:

keytool -list -v -keystore <path to keystore>

További információ: IBM-dokumentumtanúsítvány-kezelés SSL-ben

Annak ellenőrzése, hogy a támogatott Java-verzió megfelelően működik-e

A WAS azure-beli virtuális gépeken való használatához a Java egy adott verziója szükséges, ezért ellenőriznie kell, hogy az alkalmazás megfelelően fut-e a támogatott verzióval.

Az IBM Java 8 a WAS9 disztribúcióval rendelkezik. Az IBM által biztosított Java JRE használatát javasoljuk. További információ: Java Standard kiadás 8 a hagyományos V9-ben futó WebSphere Application Serverben.

Ha másik Java SDK-ra szeretne váltani, kövesse az IBM-dokumentumot : A Java SDK váltása a WebSphere Alkalmazáskiszolgálón.

JNDI-erőforrások leltározása

Leltározzon minden JNDI-erőforrást. Előfordulhat például, hogy az adatforrások (például az adatbázisok) olyan JNDI-névvel rendelkeznek, amely lehetővé teszi, hogy a JPA helyesen kössön EntityManager-példányokat egy adott adatbázishoz. További információ a JNDI-erőforrásokról és -adatbázisokról: WebSphere Data Sources in the IBM documentation. Egyéb JNDI-erőforrások (például a JMS-üzenetközvetítők) migrálást vagy újrakonfigurálást igényelhetnek. A JMS-konfigurációval kapcsolatos további információkért lásd : JMS-erőforrások használata.

Profilkonfiguráció vizsgálata

A WAS fő konfigurációs egysége a profil. Ezért a resources.xml fájl számos konfigurációt tartalmaz, amelyeket alaposan meg kell fontolnia a migráláshoz. A fájl további, alkönyvtárakban tárolt XML-fájlokra mutató hivatkozásokat tartalmaz. Az IBM azt javasolja, hogy a WAS kezelhető objektumainak és szolgáltatásainak konfigurálásához az IBM-konzolt használja, és engedélyezze a WAS számára a profilok/profilnév mappa karbantartását. További információ: Profilok kezelése elosztott és IBM i operációs rendszereken.

Az alkalmazáson belül

Vizsgálja meg a deployment.xml fájlt és/vagy a WEB-INF/web.xml fájlt.

Annak meghatározása, hogy az alkalmazás munkamenet-replikációt használ-e

Ha az alkalmazás munkamenet-replikációra támaszkodik, a következő lehetőségek közül választhat:

  • HTTP-munkamenetek esetén a munkamenet-kezelés szintjének megfelelően memória vagy adatbázis használatával gyűjthet munkamenetadatokat.
  • Elosztott munkamenetek esetén adatbázis-munkamenetek megőrzésével mentheti a munkameneteket az adatbázisban.
  • Dinamikus gyorsítótár esetén kezelheti a munkamenet-adatokat a memória–memória replikációban vagy egy adatbázisban.
  • Bontsa újra az alkalmazást munkamenet-kezeléshez szükséges adatbázis használatához.
  • Bontsa újra az alkalmazást az Azure Redis Service-ben való külső elérhetővé tételéhez. További információ: Azure Cache for Redis.

Mindezekhez a lehetőségekhez érdemes elsajátítani a WAS http-munkamenetállapot-replikációjának módját. További információ: Rendszergazda munkamenet-bab regisztrálása az IBM dokumentációjában.

Dokumentum-adatforrások

Ha az alkalmazása adatbázisokat használ, Önnek rögzítenie kell az alábbi adatokat:

  • Mi az adatforrás neve?
  • Milyen a kapcsolatkészlet konfigurációja?
  • Hol található a JDBC-illesztőprogram JAR-fájlja?

A WAS JDBC-illesztőprogramjaival kapcsolatos további információkért lásd : JDBC-illesztőprogramok használata a WebSphere Alkalmazáskiszolgálóval.

Annak meghatározása, hogy a WAS testre lett-e szabva

Határozza meg, hogy a következő testreszabások közül melyik lett végrehajtva, és rögzítse, mi történt.

  • Módosultak az indítási szkriptek? Ilyen szkriptek például a wsadmin, Rendszergazda Control, Rendszergazda Config, Rendszergazda App és Rendszergazda Task.
  • Küld adott paramétereket a JVM-nek az alkalmazás?
  • Tartalmaz JAR-fájlokat a kiszolgáló osztályútvonala?
  • Használták-e az operációsrendszer-szintű létesítményeket, például systemd arra, hogy a WAS-összetevők automatikusan elinduljanak a kiszolgáló újraindítása után?

A migrálással kapcsolatos szempontokat figyelembe kell vennie a kérdésekre adott válaszoktól függően.

Annak megállapítása, hogy szükséges-e helyszíni kapcsolat

Ha az alkalmazásnak hozzá kell férnie helyszíni szolgáltatásokhoz, ki kel építenie egy Azure-beli kapcsolati szolgáltatást. További információ: Megoldás választása a helyszíni hálózat Azure-hoz való csatlakoztatásához. Másik megoldásként újrabonthatja az alkalmazást, hogy az nyilvánosan elérhető, a helyszíni erőforrások által közzétett API-kat használjon.

Állapítsa meg, hogy használ-e Java Message Service- (JMS-) üzenetsorokat és -témákat

Ha az alkalmazás JMS-üzenetsorokat vagy témaköröket használ, át kell telepítenie őket egy külsőleg üzemeltetett JMS-kiszolgálóra. A JMS-t használó felhasználók egyik stratégiája az Azure Service Bus és az Advanced Message Queuing Protocol használata. További információkért lásd: A JMS használata az Azure Service Busszal és az AMQP 1.0-val.

Ha konfigurálta a JMS állandó tárolóit, rögzítenie kell a konfigurációjukat, és alkalmaznia kell azt az áttelepítés után.

Ha IBM MQ-t használ, migrálhatja ezt a szoftvert az Azure Virtual Machinesbe, és használhatja is.

A Microsoft megoldást kínál az IBM MQ és a Logic Apps integrálására. További információ: Csatlakozás egy IBM MQ-kiszolgálóra az Azure Logic Apps munkafolyamatából.

Annak meghatározása, hogy saját, egyénileg létrehozott megosztott Java EE-könyvtárakat használ-e

Ha a megosztott Java EE-könyvtár funkciót használja, két lehetősége van:

  • Bontsa újra az alkalmazás kódját a könyvtárak minden függőségének eltávolításához, majd foglalja közvetlenül az alkalmazásba a funkciókat.
  • Adja hozzá a könyvtárakat a kiszolgáló osztályútvonalához.

Annak meghatározása, hogy a kiszolgáló OSGi-csomagokat használ-e

Ha a WAS-hoz hozzáadott OSGi-csomagokat használta, az egyenértékű JAR-fájlokat közvetlenül a webalkalmazáshoz kell hozzáadnia.

Annak meghatározása, hogy az alkalmazás tartalmaz-e az operációs rendszerre vonatkozó kódot

Ha az alkalmazás tartalmaz a gazdagép operációs rendszeréhez tartozó függőségekkel rendelkező kódot, azt Önnek újra kell bontania a függőségek eltávolításához. Előfordulhat például, hogy a File.Separator vagy Paths.get fájlrendszerbeli útvonalakkal rendelkező /- vagy \-előfordulásokat cserélnie kell.

Annak meghatározása, hogy az IBM Integration Bus használatban van-e

Ha az alkalmazás IBM Integration Bust használ, rögzítenie kell az IBM Integration Bus konfigurálását. További információkért lásd az IBM Integration Bus dokumentációját.

Annak meghatározása, hogy az alkalmazás több WAR-fájlból áll-e

Ha az alkalmazása több WAR-fájlból áll, ezeket különálló alkalmazásként kell kezelnie, és az útmutató lépéseit egyenként elvégeznie mindegyikhez.

Annak megállapítása, hogy az alkalmazás EAR-ként van-e csomagolva

Ha az alkalmazás EAR-fájlként van csomagolva, mindenképpen vizsgálja meg a application.xml, az ibm-application-bnd.xmi és az ibm-application-ext.xmi fájlokat, és rögzítse a konfigurációikat. További információ: A vállalati archívum (EAR) csomag létrehozása a WebSphere-en.

Az éles kiszolgálókon futó összes külső folyamat és démon azonosítása

Ha rendelkezik az alkalmazáskiszolgálón kívül futó folyamatokkal, például figyelési démonokkal, ezeket el kell távolítania, vagy máshová kell migrálnia.

Határozza meg, használják-e a fájlrendszert, és ha igen, hogyan

A virtuális gépek fájlrendszerei az adatmegőrzés, indítás és leállítás szempontjából ugyanúgy működnek, mint a helyszíni fájlrendszerek. Éppen ezért fontos tisztában lennie a fájlrendszer igényeivel, és gondoskodnia kell arról, hogy a virtuális gépek megfelelő tárhellyel és teljesítménnyel rendelkeznek.

Csak olvasható statikus tartalom

Ha az alkalmazás jelenleg statikus tartalmat szolgáltat, szüksége lesz egy másik helyre hozzá. A statikus tartalmat célszerű az Azure Blob Storage-ba helyezni és az Azure CDN hozzáadásával biztosítani a villámgyors globális letöltést. További információ: Statikus webhely üzemeltetése az Azure Storage-ban és rövid útmutató: Azure Storage-fiók integrálása az Azure CDN-nel. A statikus tartalmat közvetlenül is üzembe helyezheti egy alkalmazáson az Azure Spring Apps Enterprise-csomagban. További információ: Webes statikus fájlok üzembe helyezése.

Dinamikusan közzétett statikus tartalom

Ha az alkalmazás engedélyezi az alkalmazás által feltöltött/előállított statikus tartalmakat, azonban a létrehozás után nem módosítható, az Azure Blob Storage és az Azure CDN fent ismertetett módon történő, egy Azure-függvénnyel közös használatával kezelheti a feltöltéseket és a CDN-frissítést. A Statikus tartalom feltöltése és CDN-előtöltése az Azure Functions szolgáltatással című témakörben megadtunk egy szabadon használható mintaimplementációt. A statikus tartalmat közvetlenül is üzembe helyezheti egy alkalmazáson az Azure Spring Apps Enterprise-csomagban. További információ: Webes statikus fájlok üzembe helyezése.

A hálózati topológia meghatározása

Az Azure Marketplace-ajánlatok jelenlegi készlete a migrálás kiindulópontja. Ha az ajánlat nem fedi le az áttelepítendő architektúra aspektusait, rögzítenie kell a meglévő üzembe helyezés hálózati topológiáját. Ezután reprodukálnia kell ezt a hálózati topológiát az Azure-ban, még akkor is, ha az alapajánlatot az egyik megoldássablonnal kiállta.

A hálózati topológia széles körű témakör, de az alábbi hivatkozások segíthetnek a migrálási erőfeszítésekben:

JCA-adapterek és erőforrás-adapterek használatának fiókja

Ha a meglévő alkalmazás JCA-adaptereket vagy más erőforrás-adaptereket használ más vállalati rendszerekhez való csatlakozáshoz, győződjön meg arról, hogy az összetevők konfigurációját az Azure-beli virtuális gépeken futó WAS-ra alkalmazza. További információ: Relációs erőforrás-adapterek és JCA az IBM dokumentációjában.

Fiók hitelesítéshez és engedélyezéshez

A legtöbb alkalmazás rendelkezik valamilyen hitelesítést és engedélyezést. Ha openID-t használ a hitelesítéshez, konfigurálhatja az OpenID connect-hitelesítést a Microsoft Entra-azonosítóval. További információ: OpenID Csatlakozás hitelesítés a Microsoft Entra-azonosítóval.

Annak meghatározása, hogy a WAS-fürtözést használja-e a rendszer

Valószínűleg több WAS-kiszolgálón is üzembe helyezte az alkalmazást a magas rendelkezésre állás érdekében. Ezeket a fürtöket közvetlenül a helyszíni telepítésből migrálhatja az Azure-beli virtuális gépeken futó WAS-ba. További információ: WebSphere Application Server Network Deployment in the IBM documentation.

Terheléselosztási követelmények figyelembe vétele

A terheléselosztás a WAS-fürt Azure-ba való migrálásának alapvető része. A legegyszerűbb megoldás az IBM WebSphere alkalmazáskiszolgálófürthöz készült Azure Marketplace-ajánlatban szereplő Azure-alkalmazás átjáró vagy IBM HTTP-kiszolgáló beépített támogatása.

A Azure-alkalmazás Gateway más Azure-beli terheléselosztási megoldásokkal összehasonlított képességeinek összegzéséhez tekintse meg a terheléselosztási lehetőségeket.

Annak meghatározása, hogy az alkalmazás használja-e a Java EE Application Client funkciót

Ha az alkalmazása a Java EE Application Client funkciót használja, akkor az Azure Virtual Machines szolgáltatásba való migrálás után változatlanul kell tovább működnie. További információ: A Java EE ügyfélalkalmazás-moduljainak használata.

Migrálás

Hagyományos WAS kiválasztása az Azure Virtual Machines-ajánlatban

Az alábbi ajánlatok érhetők el a WAS-hoz az Azure-beli virtuális gépeken.

Az ajánlat üzembe helyezése során a rendszer arra kéri, hogy válassza ki a WAS-csomópontok virtuálisgép-méretét. A virtuális gép méretének kiválasztásakor fontos a méretezés minden aspektusát figyelembe venni. További információt a Cloud Services méreteinek (klasszikus) című témakörben talál.

Az ajánlat kiépítése

Miután kiválasztotta, hogy melyik ajánlattal kezdjen, vegye ki ezt az ajánlatot a WebSphere Application Server (hagyományos) fürt üzembe helyezése azure-beli virtuális gépeken című témakörben leírtak szerint.

A profilok migrálása

Az ajánlat kiépítése után megvizsgálhatja a profilkonfigurációt. További információ: Profilfogalmak az IBM dokumentációjában.

Adatbázisok összekapcsolása

Miután migrálta a profilokat, csatlakoztathatja az adatbázisokat a WebSphere Alkalmazáskiszolgáló adatforrásának konfigurálásával kapcsolatos utasításokat követve az IBM dokumentációjában.

A kulcstárak számba vétele

Számolnia kell az alkalmazás által használt SSL-kulcstárak migrálásával is. További információkért tekintse meg az SSL keystore-konfigurációit az IBM dokumentációjában.

A JMS-erőforrások összekötése

Miután csatlakoztatta az adatbázisokat, konfigurálhatja a JMS-t az IBM-dokumentáció JMS beállítása az IBM WebSphere Alkalmazáskiszolgálón című témakörben leírtak szerint.

Fiók hitelesítéshez és engedélyezéshez

A legtöbb alkalmazás rendelkezik valamilyen hitelesítést és engedélyezést. Ha openID-t használ a hitelesítéshez, konfigurálhatja az OpenID connect-hitelesítést a Microsoft Entra-azonosítóval. További információ: OpenID Csatlakozás hitelesítés a Microsoft Entra-azonosítóval.

A naplózás számba vétele

Az Elastic Stack konfigurálásához kövesse a WebSphere Alkalmazáskiszolgáló naplóinak Elemzés az Elastic Stackdel című témakör utasításait az IBM dokumentációjában. Az Azure támogatja az Elastic szolgáltatást. További információ: Mi az Azure rugalmas integrációja? Az ebben a két erőforrásban található tudást kombinálva azure-ra optimalizált naplózási megoldást érhet el a WAS-hoz virtuális gépeken.

Alkalmazások migrálása

Az alkalmazások fejlesztési fázisból teszteléshez, előkészítéshez és éles kiszolgálókhoz való üzembe helyezés technikái minden esetben nagyban eltérhetnek egymástól. Bizonyos esetekben egy fejlett CI/CD-platform is létezik, amely az alkalmazásokat a WebSphere alkalmazáskiszolgálón helyezi üzembe. Más esetekben a folyamat inkább manuális. A WAS hagyományos alkalmazások felhőbe való migrálásának egyik előnye, hogy a meglévő folyamatok továbbra is működnek.

Konfigurálnia kell azt a hálózati biztonsági csoportot, amelyet az ajánlat a CI/CD-folyamatból vagy a manuális üzembehelyezési rendszerből való hozzáférés engedélyezésére biztosít. További információ: Hálózati biztonsági csoportok.

Tesztelés

Konfigurálnia kell a tárolón belüli teszteket az alkalmazásokon, hogy hozzáférjenek az Azure-ban futó új kiszolgálókhoz. A CI/CD-vel kapcsolatos aggodalmakhoz hasonlóan gondoskodnia kell arról, hogy a szükséges hálózati biztonsági szabályok lehetővé tegyék a tesztek számára az Azure-ban üzembe helyezett alkalmazások elérését. További információ: Hálózati biztonsági csoportok.

A migrálás után

A migrálást megelőző folyamatok lépésben meghatározott célok elérése után teljes körű elfogadási tesztelést végezhet, hogy ellenőrizze, hogy minden a várt módon működik. A migrálást követő néhány lehetséges fejlesztéssel kapcsolatos útmutatásért tekintse meg az alábbi ajánlásokat: