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 no Azure Ative Directory. Como essas APIs usam HTTPS, o CycleCloud requer acesso HTTPS de saída para:
- management.azure.com (Azure ARM Management)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (Telemetria do Azure)
- dc.applicationinsights.azure.com (Azure Application Insights)
- dc.applicationinsights.microsoft.com (Azure Application Insights)
- dc.services.visualstudio.com (Azure Application Insights)
- ratecard.azure-api.net (Dados de Preços do Azure)
A API de gerenciamento é hospedada regionalmente e os intervalos de endereços IP públicos podem ser encontrados aqui.
O logon do Azure AD faz parte das APIs comuns do Microsoft 365 e os 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 este serviço e a qualquer outro serviço do Azure com suporte é por meio Pontos de Extremidade do Serviço de Rede Virtual.
Se estiver usando os Grupos de Segurança de Rede ou o Firewall do Azure para limitar o acesso de saída aos domínios necessários, será possível configurar o Azure Cyclecloud para rotear todas as solicitações por meio de um proxy HTTPS. Consulte: Usando um de proxy da Web
Configurando um Grupo de Segurança de Rede do Azure para a VM do CycleCloud
Uma maneira de limitar o acesso de saída à Internet da VM do CycleCloud sem configurar o Firewall do Azure ou um proxy HTTPS é configurar um Grupo de Segurança de Rede do Azure estrito para a sub-rede da VM do CycleCloud. A maneira mais simples de fazer isso é usar Etiquetas de Serviço no nível de sub-rede ou VM Grupo de Segurança de Rede para permitir o acesso de saída necessário do Azure.
Configurar um de Ponto de Extremidade do Serviço de Armazenamento de
para a Sub-rede permitir o acesso do CycleCloud ao Armazenamento do Azure Adicione a seguinte regra de saída NSG a Negar acesso de saída por padrão usando a etiqueta de serviço de destino "Internet":
| Prioridade | Designação | Porto | Protocolo | Fonte | Destino | Ação |
|---|---|---|---|---|---|---|
| 4000 | BlockOutbound | Qualquer | Qualquer | Qualquer | Internet | Negar |
- Adicione as seguintes regras de saída do NSG ao Permitir acesso de saída aos serviços necessários do Azure por marca de serviço de destino:
| Prioridade | Designação | Porto | Protocolo | Fonte | Destino | Ação |
|---|---|---|---|---|---|---|
| 100 | AllowAzureStorage | 443 | TCP | Qualquer | Armazenamento | Permitir |
| 101 | AllowActiveDirectory | 443 | TCP | Qualquer | AzureActiveDirectory | Permitir |
| 102 | AllowAzureMonitor | 443 | TCP | Qualquer | AzureMonitor | Permitir |
| 103 | AllowAzureRM | 443 | TCP | Qualquer | AzureResourceManager | Permitir |
Comunicações internas entre nós de cluster e o CycleCloud
Essas portas precisam estar abertas para permitir a comunicação entre os nós do cluster e o servidor CycleCloud:
| Designação | Fonte | Destino | Serviço | Protocolo | Intervalo de portas |
|---|---|---|---|---|---|
| amqp_5672 | Nó do cluster | CycleCloud | AMQP | TCP | 5672 |
| https_9443 | Nó do 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 de saída à Internet é totalmente suportada atualmente, mas é um tópico avançado que geralmente requer uma imagem personalizada ou personalização dos tipos e projetos de cluster padrão do CycleCloud ou ambos.
Estamos atualizando ativamente os tipos de cluster e projetos para eliminar a maior parte ou todo esse trabalho. Mas, 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 de saída à Internet geralmente requer o seguinte:
- O Azure Cyclecloud deve estar acessível a partir das VMs de cluster para obter funcionalidade completa. Quer:
- As VMs de cluster devem ser capazes de se conectar ao Azure Cyclecloud diretamente via HTTPS e AMQP, ou
- O recurso Cyclecloud ReturnProxy 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 a partir das VMs, ou
- Copiado para a VM do Armazenamento do Azure e instalado diretamente por um projeto 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 este serviço e a qualquer outro serviço do Azure com suporte é habilitar um de Ponto de Extremidade do Serviço de Rede Virtual para o Armazenamento do Azure.
Atualizações de projeto do GitHub
O Cyclecloud baixará projetos de cluster do GitHub durante a fase de orquestração "Preparação". 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 do 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 podem ser baixados de outra máquina e copiados para o CycleCloud.
Primeiro, determine qual projeto e versão seu cluster precisará, por exemplo, Slurm 3.0.8. Normalmente, é o número de versão mais alto no banco de dados para um determinado projeto. Você pode determinar a versão mais recente visitando a página do projeto github ou consultando o CycleCloud para obter a versão mais recente.
Para consultar o CycleCloud (observe que muitas vezes haverá várias versões listadas):
/opt/cycle_server/cycle_server execute 'select Name, Version, Url from cloud.project where name == "slurm" order by Version'
Name = "slurm"
Version = "3.0.8"
Url = "https://github.com/Azure/cyclecloud-slurm/releases/3.0.8"
Esta versão do projeto e todas as dependências são encontradas na tag [release] (https://github.com/Azure/cyclecloud-slurm/releases/tag/3.0.8).
Você pode baixar todos os artefatos de liberação manualmente, mas a CLI do CycleCloud fornece um auxiliar para essa operação.
Primeiro, use a CLI do CycleCloud para buscar e preparar o repositório do github (esta é a mesma operação que o CycleCloud executa durante a fase "Recursos de preparo"):
RELEASE_URL="https://github.com/Azure/cyclecloud-slurm/releases/3.0.8"
RELEASE_VERSION="3.0.8"
mkdir "${RELEASE_VERSION}"
cd "${RELEASE_VERSION}"
# Download release artifacts from githug (on a machine with github access)
cyclecloud project fetch "${RELEASE_URL}" .
# Create a tarbal with the project files pre-staged
cyclecloud project build
mv ./build/slurm "./${RELEASE_VERSION}"
tar czf "slurm-${RELEASE_VERSION}.tgz" ./blobs "./${RELEASE_VERSION}"
Em seguida, copie o tarball do projeto empacotado para o servidor CycleCloud e extraia:
#... copy the "slurm-${RELEASE_VERSION}.tgz" file to the Cyclecloud server in /tmp
sudo -i
mkdir -p /opt/cycle_server/work/staging/projects/slurm
cd /opt/cycle_server/work/staging/projects/slurm
tar xzf "/tmp/slurm-${RELEASE_VERSION}.tgz"
chown -R cycle_server:cycle_server /opt/cycle_server/work/staging
Uma vez que esses arquivos tenham sido preparados localmente, o Cyclecloud os detetará e não tentará baixá-los do GitHub.