Działanie w zablokowanej sieci
Aplikacja CycleCloud i węzły klastra mogą działać w środowiskach z ograniczonym dostępem do Internetu, choć istnieje minimalna liczba portów TCP, które muszą pozostać otwarte.
Instalowanie usługi Azure CycleCloud w zablokowanej sieci
Maszyna wirtualna CycleCloud musi mieć możliwość nawiązania połączenia z wieloma interfejsami API platformy Azure w celu organizowania maszyn wirtualnych klastra i uwierzytelniania w usłudze Azure Active Directory. Ponieważ te interfejsy API używają protokołu HTTPS, usługa CycleCloud wymaga wychodzącego dostępu HTTPS do:
- management.azure.com (Azure ARM Management)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (Azure Telemetry)
- dc.applicationinsights.azure.com (aplikacja systemu Azure Insights)
- dc.applicationinsights.microsoft.com (aplikacja systemu Azure Insights)
- dc.services.visualstudio.com (aplikacja systemu Azure Insights)
- ratecard.azure-api.net (dane cen platformy Azure)
Interfejs API zarządzania jest hostowany regionalnie, a zakresy publicznych adresów IP można znaleźć tutaj.
Identyfikator logowania Azure AD jest częścią typowych interfejsów API platformy Microsoft 365 i zakresów adresów IP dla usługi można znaleźć tutaj.
Zakresy adresów IP usługi Azure Insights i Log Analytics można znaleźć tutaj.
Usługa Azure CycleCloud musi mieć dostęp do kont usługi Azure Storage. Zalecanym sposobem zapewnienia prywatnego dostępu do tej usługi i innych obsługiwanych usług platformy Azure jest użycie Virtual Network punktów końcowych usługi.
Jeśli używasz sieciowych grup zabezpieczeń lub Azure Firewall w celu ograniczenia dostępu wychodzącego do wymaganych domen, można skonfigurować usługę Azure Cyclecloud do kierowania wszystkich żądań za pośrednictwem serwera proxy HTTPS. Zobacz: Korzystanie z serwera proxy sieci Web
Konfigurowanie sieciowej grupy zabezpieczeń platformy Azure dla maszyny wirtualnej CycleCloud
Jednym ze sposobów ograniczenia wychodzącego dostępu do Internetu z maszyny wirtualnej CycleCloud bez konfigurowania Azure Firewall lub serwera proxy HTTPS jest skonfigurowanie ścisłej sieciowej grupy zabezpieczeń platformy Azure dla podsieci maszyny wirtualnej CycleCloud. Najprostszym sposobem, aby to zrobić, jest użycie tagów usługi w podsieci lub sieciowej grupie zabezpieczeń na poziomie maszyny wirtualnej, aby zezwolić na wymagany dostęp wychodzący platformy Azure.
Konfigurowanie punktu końcowego usługi magazynu dla podsieci w celu zezwolenia na dostęp z usługi CycleCloud do usługi Azure Storage
Dodaj następującą regułę ruchu wychodzącego sieciowej grupy zabezpieczeń, aby domyślnie odmówić dostępu wychodzącego przy użyciu docelowego tagu usługi "Internet":
| Priorytet | Nazwa | Port | Protokół | Element źródłowy | Element docelowy | Akcja |
|---|---|---|---|---|---|---|
| 4000 | BlockOutbound | Dowolne | Dowolne | Dowolne | Internet | Zablokuj |
- Dodaj następujące reguły ruchu wychodzącego sieciowej grupy zabezpieczeń, aby zezwolić na dostęp wychodzący do wymaganych usług platformy Azure według docelowego tagu usługi:
| Priorytet | Nazwa | Port | Protokół | Element źródłowy | Element docelowy | Akcja |
|---|---|---|---|---|---|---|
| 100 | ZezwalajazureStorage | 443 | TCP | Dowolne | Storage | Zezwalaj |
| 101 | AllowActiveDirectory | 443 | TCP | Dowolne | AzureActiveDirectory | Zezwalaj |
| 102 | AllowAzureMonitor | 443 | TCP | Dowolne | AzureMonitor | Zezwalaj |
| 103 | ZezwalajazureRM | 443 | TCP | Dowolne | AzureResourceManager | Zezwalaj |
Wewnętrzna komunikacja między węzłami klastra a usługą CycleCloud
Te porty muszą być otwarte, aby umożliwić komunikację między węzłami klastra i serwerem CycleCloud:
| Nazwa | Element źródłowy | Element docelowy | Usługa | Protokół | Zakres portów |
|---|---|---|---|---|---|
| amqp_5672 | Węzeł klastra | CycleCloud | AMQP | TCP | 5672 |
| https_9443 | Węzeł klastra | CycleCloud | HTTPS | TCP | 9443 |
Uruchamianie klastrów Usługi Azure CycleCloud w zablokowanej sieci
Uwaga
Uruchamianie węzłów klastra w podsieci bez wychodzącego dostępu do Internetu jest obecnie w pełni obsługiwane, ale jest to zaawansowany temat, który często wymaga niestandardowego obrazu lub dostosowania domyślnych typów klastrów i projektów CycleCloud lub obu tych typów.
Aktywnie aktualizujemy typy klastrów i projekty, aby wyeliminować większość lub wszystkie te działania. Jeśli jednak wystąpią błędy dotyczące typu klastra lub projektu w zablokowanym środowisku, rozważ otwarcie wniosku o pomoc techniczną w celu uzyskania pomocy.
Uruchamianie maszyn wirtualnych lub klastrów Cyclecloud w sieci wirtualnej lub podsieci z wychodzącym dostępem do Internetu zwykle wymaga następujących elementów:
- Usługa Azure Cyclecloud musi być osiągalna z maszyn wirtualnych klastra w celu zapewnienia pełnej funkcjonalności. Dowolny z następujących elementów:
- Maszyny wirtualne klastra muszą mieć możliwość nawiązywania połączenia z usługą Azure Cyclecloud bezpośrednio za pośrednictwem protokołów HTTPS i AMQP lub
- Funkcja Cyclecloud ReturnProxy musi być włączona w czasie tworzenia klastra, a sama aplikacja Cyclecloud musi mieć możliwość nawiązania połączenia z maszyną wirtualną ReturnProxy za pośrednictwem protokołu SSH
- Wszystkie pakiety oprogramowania wymagane przez klaster muszą być:
- Wstępnie zainstalowane w niestandardowym obrazie zarządzanym dla maszyn wirtualnych klastra lub
- Dostępne w repozytorium pakietów dublowanego dostępnego z maszyn wirtualnych lub
- Skopiowane do maszyny wirtualnej z usługi Azure Storage i zainstalowane bezpośrednio przez projekt Cyclecloud
- Wszystkie węzły klastra muszą mieć dostęp do kont usługi Azure Storage. Zalecanym sposobem zapewnienia prywatnego dostępu do tej usługi i wszystkich innych obsługiwanych usług platformy Azure jest włączenie punktu końcowego usługi Virtual Network dla usługi Azure Storage.
Aktualizacje projektu z usługi GitHub
Usługa Cyclecloud pobierze projekty klastrów z usługi GitHub w fazie orkiestracji "Przejściowe". To pobranie nastąpi po początkowej instalacji, po uaktualnieniu narzędzia Cyclecloud lub podczas uruchamiania klastra określonego typu po raz pierwszy. W zablokowanym środowisku ruch wychodzący HTTPS do github.com może być zablokowany. W takim przypadku tworzenie węzła w fazie przejściowej zasobów zakończy się niepowodzeniem.
Jeśli podczas tworzenia pierwszego węzła można tymczasowo otworzyć dostęp do usługi GitHub, usługa CycleCloud przygotuje pliki lokalne dla wszystkich kolejnych węzłów. Jeśli dostęp tymczasowy nie jest możliwy, niezbędne pliki można pobrać z innego komputera i skopiować do aplikacji CycleCloud.
Najpierw określ, który projekt i wersja klastra będą potrzebne, np. Slurm 2.5.0. Zwykle jest to najwyższy numer wersji w bazie danych dla danego projektu.
/opt/cycle_server/cycle_server execute 'select * from cloud.project where name == "slurm"'
AdType = "Cloud.Project"
Version = "2.5.0"
ProjectType = "scheduler"
Url = "https://github.com/Azure/cyclecloud-slurm/releases/2.5.0"
AutoUpgrade = false
Name = "slurm"
Ta wersja projektu i wszystkie zależności znajdują się w tagu [release tag] (https://github.com/Azure/cyclecloud-slurm/releases/tag/2.5.0). Wszystkie artefakty dla wydania muszą zostać pobrane. Najpierw pobierz artefakt kodu i utwórz katalog obiektów blob dla dodatkowych zależności.
wget https://github.com/Azure/cyclecloud-slurm/archive/refs/tags/2.5.0.tar.gz
tar -xf 2.5.0.tar.gz
cd cyclecloud-slurm-2.5.0 && mkdir blobs
#... download all other release artifacts to the /blobs directory with wget ...
wget -P "blobs/" https://github.com/Azure/cyclecloud-slurm/releases/download/2.6.1/cyclecloud_api-8.1.0-py2.py3-none-any.whl
#... copy all the files to the Cyclecloud server
#... then on the Cyclecloud server:
cyclecloud project build
mkdir -p /opt/cycle_server/work/staging/projects/slurm/2.5.0
mkdir -p /opt/cycle_server/work/staging/projects/slurm/blobs
cp build/slurm/* /opt/cycle_server/work/staging/projects/slurm/2.5.0/
cp blobs/* /opt/cycle_server/work/staging/projects/slurm/blobs/
chown -R cycle_server:cycle_server /opt/cycle_server/work/staging
Po utworzeniu tych plików lokalnie usługa Cyclecloud wykryje je i nie spróbuje pobrać ich z usługi GitHub.