Funzionamento in una rete bloccata
L'applicazione CycleCloud e i nodi del cluster possono funzionare in ambienti con accesso Internet limitato, anche se sono presenti un numero minimo di porte TCP che devono rimanere aperte.
Installazione di Azure CycleCloud in una rete bloccata
La macchina virtuale CycleCloud deve essere in grado di connettersi a un numero di API di Azure per orchestrare le macchine virtuali del cluster e di eseguire l'autenticazione in Azure Active Directory. Poiché queste API usano HTTPS, CycleCloud richiede l'accesso HTTPS in uscita a:
- management.azure.com (Gestione ARM di Azure)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (telemetria di Azure)
- dc.applicationinsights.azure.com (applicazione Azure Insights)
- dc.applicationinsights.microsoft.com (applicazione Azure Insights)
- dc.services.visualstudio.com (applicazione Azure Insights)
- ratecard.azure-api.net (Dati prezzi di Azure)
L'API di gestione è ospitata a livello regionale e gli intervalli di indirizzi IP pubblici sono disponibili qui.
L'account di accesso di Azure AD fa parte delle API comuni di Microsoft 365 e degli intervalli di indirizzi IP per il servizio.
Gli intervalli di indirizzi IP di Azure Insights e Log Analytics sono disponibili qui.
Azure CycleCloud deve essere in grado di accedere agli account di archiviazione di Azure. Il modo consigliato per fornire l'accesso privato a questo servizio e qualsiasi altro servizio di Azure supportato è tramite Rete virtuale Endpoint servizio.
Se si usano gruppi di sicurezza di rete o il Firewall di Azure per limitare l'accesso in uscita ai domini necessari, è possibile configurare Azure Cyclecloud per instradare tutte le richieste tramite un proxy HTTPS. Vedere: Uso di un proxy Web
Configurazione di un gruppo di sicurezza di rete di Azure per la macchina virtuale CycleCloud
Un modo per limitare l'accesso Internet in uscita dalla macchina virtuale CycleCloud senza configurare la Firewall di Azure o un proxy HTTPS consiste nel configurare un gruppo di sicurezza di rete di Azure rigoroso per la subnet della macchina virtuale CycleCloud. Il modo più semplice per eseguire questa operazione consiste nell'usare i tag di servizio nella subnet o nel gruppo di sicurezza di rete a livello di macchina virtuale per consentire l'accesso di Azure in uscita richiesto.
Configurare un endpoint del servizio di archiviazione per la subnet per consentire l'accesso da CycleCloud ad Archiviazione di Azure
Aggiungere la regola NSG Outbound seguente per negare l'accesso in uscita per impostazione predefinita usando il tag del servizio di destinazione "Internet":
| Priorità | Nome | Porta | Protocollo | Source (Sorgente) | Destination | Azione |
|---|---|---|---|---|---|---|
| 4000 | BlockOutbound | Qualsiasi | Qualsiasi | Qualsiasi | Internet | Nega |
- Aggiungere le regole NSG outbound seguenti per Consentire l'accesso in uscita ai servizi di Azure necessari per tag del servizio di destinazione:
| Priorità | Nome | Porta | Protocollo | Source (Sorgente) | Destination | Azione |
|---|---|---|---|---|---|---|
| 100 | AllowAzureStorage | 443 | TCP | Qualsiasi | Archiviazione | Allow |
| 101 | AllowActiveDirectory | 443 | TCP | Qualsiasi | AzureActiveDirectory | Allow |
| 102 | AllowAzureMonitor | 443 | TCP | Qualsiasi | AzureMonitor | Allow |
| 103 | AllowAzureRM | 443 | TCP | Qualsiasi | AzureResourceManager | Allow |
Comunicazioni interne tra nodi del cluster e CycleCloud
Queste porte devono essere aperte per consentire la comunicazione tra i nodi del cluster e il server CycleCloud:
| Nome | Source (Sorgente) | Destination | Servizio | Protocollo | Intervallo di porte |
|---|---|---|---|---|---|
| amqp_5672 | Nodo cluster | CycleCloud | AMQP | TCP | 5672 |
| https_9443 | Nodo cluster | CycleCloud | HTTPS | TCP | 9443 |
Avvio di cluster Azure CycleCloud in una rete bloccata
Nota
L'esecuzione di nodi del cluster in una subnet senza accesso Internet in uscita è completamente supportata oggi, ma è un argomento avanzato che spesso richiede un'immagine personalizzata o la personalizzazione dei tipi e dei progetti del cluster CycleCloud predefinito o entrambi.
I tipi e i progetti del cluster vengono aggiornati attivamente per eliminare la maggior parte o tutte le operazioni. Tuttavia, se si verificano errori con il tipo di cluster o il progetto nell'ambiente bloccato, è consigliabile aprire una richiesta di supporto per assistenza.
L'esecuzione di macchine virtuali o cluster Cyclecloud in una rete virtuale o in una subnet con accesso a Internet in uscita richiede in genere quanto segue:
- Azure Cyclecloud deve essere raggiungibile dalle macchine virtuali del cluster per la funzionalità completa. Una delle due versioni seguenti:
- Le macchine virtuali del cluster devono essere in grado di connettersi ad Azure Cyclecloud direttamente tramite HTTPS e AMQP o
- La funzionalità ReturnProxy cyclecloud deve essere abilitata al momento della creazione del cluster e Cyclecloud stesso deve essere in grado di connettersi alla macchina virtuale ReturnProxy tramite SSH
- Tutti i pacchetti software richiesti dal cluster devono essere:
- Preinstallato in un'immagine gestita personalizzata per le macchine virtuali del cluster o
- Disponibile in un repository di pacchetti con mirroring accessibile dalle macchine virtuali o
- Copiato nella macchina virtuale da Archiviazione di Azure e installato direttamente da un progetto Cyclecloud
- Tutti i nodi del cluster devono essere in grado di accedere agli account di archiviazione di Azure. Il modo consigliato per fornire l'accesso privato a questo servizio e qualsiasi altro servizio di Azure supportato consiste nell'abilitare un endpoint di servizio Rete virtuale per Archiviazione di Azure.
Aggiornamenti di progetto da GitHub
Cyclecloud scaricherà i progetti cluster da GitHub durante la fase di orchestrazione "Staging". Questo download verrà eseguito dopo l'installazione iniziale, dopo l'aggiornamento di Cyclecloud o all'avvio di un cluster di un determinato tipo per la prima volta. In un ambiente bloccato, il traffico in uscita HTTPS verso github.com potrebbe essere bloccato. In questo caso, la creazione di nodi durante la fase delle risorse di staging avrà esito negativo.
Se l'accesso a GitHub può essere aperto temporaneamente durante la creazione del primo nodo, CycleCloud preparerà i file locali per tutti i nodi successivi. Se l'accesso temporaneo non è possibile, i file necessari possono essere scaricati da un altro computer e copiati in CycleCloud.
Determinare innanzitutto il progetto e la versione necessari per il cluster, ad esempio Slurm 2.5.0. In genere è il numero di versione più alto nel database per un determinato progetto.
/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"
Questa versione del progetto e tutte le dipendenze sono disponibili nel [tag di versione] (https://github.com/Azure/cyclecloud-slurm/releases/tag/2.5.0). Tutti gli artefatti per una versione devono essere scaricati. Scaricare prima di tutto l'artefatto del codice e creare una directory BLOB per le dipendenze aggiuntive.
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
Dopo aver eseguito il staging di questi file in locale Cyclecloud li rileverà e non proverà a scaricarli da GitHub.