Sprawdź poprawność hosta i portu adresu URL na potrzeby dostępu do chmury

W środowisku chmury należy wziąć pod uwagę wiele czynników przy uzyskiwaniu dostępu do adresów URL z poziomu aplikacji.

1. Czy jest konieczna zmiana nazwy hosta lub adresu IP?
• Jeśli usługa docelowa została przeniesiona z aplikacją, wówczas nazwa hosta lub adres IP wymaga zmiany.
2. Czy dostęp do hosta można uzyskać z poziomu środowiska chmury?
• Jeśli host docelowy nie znajduje się w publicznym Internecie, należy skonfigurować bezpieczne połączenie przy użyciu tunelu VPN. Więcej informacji na ten temat zawiera sekcja Tworzenie bezpiecznego połączenia.
3. Czy dostęp do portu można uzyskać z poziomu środowiska chmury?
• Jeśli host docelowy znajduje się w chmurze publicznej, może być konieczne otwarcie portu w przypadku korzystania z portów innych niż domyślne. Więcej informacji na ten temat zawiera sekcja Otwieranie portu.
4. Czy można dynamicznie zmienić nazwę hosta lub adres IP w środowisku chmury po wdrożeniu?
• W środowisku chmury usługi lub węzły sieci mogą być przemieszczane lub ponownie generowane, co powoduje przesunięcie ich do nowych nazw hostów i adresów IP. Po takim przesunięciu wywołania aplikacji skierowane do konkretnych nazw hostów lub adresów IP mogą zostać przerwane.
• Zamiast korzystać z nazw hostów lub adresów IP należy skontaktować się z zewnętrznym rejestrem usług w celu rozwiązania punktów końcowych usług lub delegować całą funkcję routingu na magistralę usług lub system równoważenia obciążenia przy użyciu nazwy wirtualnej.
5. Jeśli nazwa hosta to localhost, to czy usługa docelowa została przeniesiona z aplikacją?
• Jeśli nie została przeniesiona, należy skonfigurować bezpieczne połączenie przy użyciu tunelu VPN. Więcej informacji na ten temat zawiera sekcja Tworzenie bezpiecznego połączenia.

Ta reguła powoduje oznaczenie flagą odwołań do następujących literałów łańcuchowych języka Java i wartości właściwości w plikach .properties:

• corbaloc:<protokół>:<host>:<port>/ (protokół i port są opcjonalne)
• corbaname:<protokół>:<host>:<port>/ (protokół i port są opcjonalne)
• http://
• https://
• iiop://
• imap://
• jdbc:<typ bazy danych>://
• ldap://
• ldaps://
• pop2://
• smtp://
• ssl://
• tcp://

Jeśli docelowym środowiskiem wykonawczym chmury jest IBM Cloud lub model PaaS innej firmy, następujące protokoły nie zostaną oznaczone flagą przez tę regułę, ponieważ są one oznaczone flagą przez regułę Nie używaj starszych lub niestandardowych protokołów.

• corbaloc
• iiop
• ssl
• tcp

Ta reguła powoduje również oznaczenie odwołań do "http://" lub "https: //" w atrybucie < code> location < /code> w elemencie < span class= "XmlDefinition"> < address> < /span> w plikach WSDL.

Uwaga: odwołania do adresów "http://www.w3.org/" i "http://schemas.xmlsoap.org/" nie są oznaczane flagą, ponieważ identyfikują one zdefiniowane przez przestrzenie nazw w specyfikacji mechanizmu adresowania usług WWW (WS-Addressing).

Sposób rozwiązania

Jeśli aplikacja jest w stanie uzyskać bezpośredni dostęp do punktu końcowego usługi lub węzła sieci, nie jest wymagane żadne działanie. W przeciwnym razie istnieją dwa potencjalne rozwiązania:

Tworzenie bezpiecznego połączenia

Korzystając z tunelu VPN, na przykład IBM Secure Gateway na potrzeby platformy IBM Cloud, można utworzyć bezpieczne połączenie z punktem końcowym usługi lub węzłem sieci. Więcej informacji o konfigurowaniu bezpiecznego połączenia zawiera sekcja Konfigurowanie sieci VPN. Po skonfigurowaniu bramy należy połączyć aplikację z nowym miejscem docelowym, korzystając z hosta chmury i numeru portu, który jest udostępniany podczas tworzenia miejsca docelowego.

Otwieranie portu

W środowisku chmury domyślnie są otwierane tylko niektóre porty. Informacje na temat otwierania dodatkowych portów można znaleźć w sekcji Porty firewalla w sekcji Dostęp do systemu WebSphere Application Server w systemie IBM Cloud.

Więcej informacji na ten temat zawiera sekcja 9 najważniejszych reguł dla aplikacji w chmurze.