Operando em uma rede bloqueada
O aplicativo CycleCloud e os nós de cluster podem operar em ambientes com acesso limitado à Internet, embora haja um número mínimo de portas TCP que devem permanecer abertas.
Instalando o Azure CycleCloud em uma rede bloqueada
A VM do CycleCloud deve ser capaz de se conectar a várias APIs do Azure para orquestrar VMs de cluster e autenticar-se no Azure Active Directory. Como essas APIs usam HTTPS, o CycleCloud requer acesso HTTPS de saída para:
- management.azure.com (Gerenciamento do ARM do Azure)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (Telemetria do Azure)
- dc.applicationinsights.azure.com (Aplicativo Azure Insights)
- dc.applicationinsights.microsoft.com (Aplicativo Azure Insights)
- dc.services.visualstudio.com (Aplicativo Azure Insights)
- ratecard.azure-api.net (dados de preço do Azure)
A API de gerenciamento é hospedada regionalmente e os intervalos de endereços IP públicos podem ser encontrados aqui.
O logon Azure AD faz parte das APIs comuns do Microsoft 365 e intervalos de endereços IP para o serviço podem ser encontrados aqui.
Os intervalos de endereços IP do Azure Insights e do Log Analytics podem ser encontrados aqui.
O Azure CycleCloud deve ser capaz de acessar contas de Armazenamento do Azure. A maneira recomendada de fornecer acesso privado a esse serviço e a qualquer outro serviço do Azure com suporte é por meio de pontos de extremidade de serviço Rede Virtual.
Se o uso de Grupos de Segurança de Rede ou o Firewall do Azure para limitar o acesso de saída aos domínios necessários, é possível configurar o Azure Cyclecloud para rotear todas as solicitações por meio de um proxy HTTPS. Veja: Usando um proxy Web
Configurando um grupo de segurança de rede do Azure para a VM do CycleCloud
Uma maneira de limitar o acesso à Internet de saída da VM do CycleCloud sem configurar o Firewall do Azure ou um proxy HTTPS é configurar um grupo estrito de segurança de rede do Azure para a sub-rede da VM do CycleCloud. A maneira mais simples de fazer isso é usar Marcas de Serviço na sub-rede ou grupo de segurança de rede no nível da VM para permitir o acesso necessário ao Azure de saída.
Configurar um ponto de extremidade do serviço de armazenamento para a sub-rede para permitir o acesso do CycleCloud ao Armazenamento do Azure
Adicione a seguinte regra de saída do NSG para negar o acesso de saída por padrão usando a Marca de Serviço de Destino "Internet":
| Prioridade | Nome | Porta | Protocolo | Fonte | Destino | Ação |
|---|---|---|---|---|---|---|
| 4000 | BlockOutbound | Qualquer | Qualquer | Qualquer | Internet | Negar |
- Adicione as seguintes regras de saída do NSG para permitir o acesso de saída aos serviços do Azure necessários por marca de serviço de destino:
| Prioridade | Nome | Porta | Protocolo | Fonte | Destino | Ação |
|---|---|---|---|---|---|---|
| 100 | AllowAzureStorage | 443 | TCP | Qualquer | Armazenamento | Allow |
| 101 | AllowActiveDirectory | 443 | TCP | Qualquer | AzureActiveDirectory | Allow |
| 102 | AllowAzureMonitor | 443 | TCP | Qualquer | AzureMonitor | Allow |
| 103 | AllowAzureRM | 443 | TCP | Qualquer | AzureResourceManager | Allow |
Comunicações internas entre nós de cluster e CycleCloud
Essas portas precisam estar abertas para permitir a comunicação entre os nós de cluster e o servidor CycleCloud:
| Nome | Fonte | Destino | Serviço | Protocolo | Intervalo de portas |
|---|---|---|---|---|---|
| amqp_5672 | Nó de Cluster | CycleCloud | AMQP | TCP | 5672 |
| https_9443 | Nó de Cluster | CycleCloud | HTTPS | TCP | 9443 |
Iniciando clusters do Azure CycleCloud em uma rede bloqueada
Observação
A execução de nós de cluster em uma sub-rede sem acesso à Internet de saída é totalmente compatível hoje, mas é um tópico avançado que geralmente requer uma imagem personalizada ou personalização dos tipos e projetos de cluster do CycleCloud padrão ou ambos.
Estamos atualizando ativamente os tipos de cluster e projetos para eliminar a maioria ou todo esse trabalho. No entanto, se você encontrar falhas com seu tipo de cluster ou projeto em seu ambiente bloqueado, considere abrir uma solicitação de suporte para assistência.
A execução de VMs ou clusters cyclecloud em uma rede virtual ou sub-rede com acesso à Internet de saída geralmente requer o seguinte:
- O Azure Cyclecloud deve ser acessível nas VMs do cluster para obter a funcionalidade completa. Ou:
- As VMs de cluster devem ser capazes de se conectar diretamente ao Azure Cyclecloud por meio de HTTPS e AMQP ou
- O recurso ReturnProxy do Cyclecloud deve ser habilitado no momento da criação do cluster e o próprio Cyclecloud deve ser capaz de se conectar à VM ReturnProxy via SSH
- Todos os pacotes de software exigidos pelo cluster devem ser:
- Pré-instalado em uma imagem gerenciada personalizada para as VMs do cluster ou
- Disponível em um espelho de repositório de pacotes acessível por meio das VMs ou
- Copiado para a VM do Armazenamento do Azure e instalado diretamente por um projeto do Cyclecloud
- Todos os nós de cluster devem ser capazes de acessar contas de Armazenamento do Azure. A maneira recomendada de fornecer acesso privado a esse serviço e a qualquer outro serviço do Azure com suporte é habilitar um ponto de extremidade de serviço Rede Virtual para o Armazenamento do Azure.
Project Atualizações do GitHub
O Cyclecloud baixará projetos de cluster do GitHub durante a fase de orquestração "Preparo". Esse download ocorrerá após a instalação inicial, após a atualização do Cyclecloud ou ao iniciar um cluster de um determinado tipo pela primeira vez. Em um ambiente bloqueado, o tráfego de saída HTTPS para github.com pode ser bloqueado. Nesse caso, a criação de nó durante a fase de recursos de preparo falhará.
Se o acesso ao GitHub puder ser aberto temporariamente durante a criação do primeiro nó, o CycleCloud preparará os arquivos locais para todos os nós subsequentes. Se o acesso temporário não for possível, os arquivos necessários poderão ser baixados de outro computador e copiados para o CycleCloud.
Primeiro determine qual projeto e versão seu cluster precisará, por exemplo, Slurm 2.5.0. Normalmente, é o número de versão mais alto no banco de dados para um determinado projeto.
/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"
Esta versão do projeto e todas as dependências são encontradas na [marca de versão] (https://github.com/Azure/cyclecloud-slurm/releases/tag/2.5.0). Todos os artefatos de uma versão devem ser baixados. Primeiro baixe o artefato de código e crie um diretório de blobs para as dependências adicionais.
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
Depois que esses arquivos forem preparados localmente, o Cyclecloud os detectará e não tentará baixá-los do GitHub.