Configurando um proxy HTTP para seus hosts do Satellite

É possível configurar um proxy HTTP para que todo o tráfego de saída de seus hosts do Satellite seja roteado por meio do proxy.

A configuração de um proxy HTTP está disponível somente para contas incluídas na lista de permissões.

Qual tipo de local eu preciso para usar proxy HTTP?

Considere os tipos de locais a seguir.

Locais existentes baseados no RHEL
Para configurar um proxy, seu local deve estar ativado para o Red Hat CoreOS (RHCOS). Se o seu local existente não for ativado para RHCOS, não será possível configurar um proxy HTTP. Crie um local ativado para o RHCOS, em seguida, configure seu proxy HTTP.
Locais existentes habilitados para o Red Hat CoreOS com hosts associados
Para configurar um proxy HTTP, deve-se primeiro remover os hosts do local. Depois de remover os hosts, consulte Configurando seu proxy HTTP. Note que deve-se também atualizar os hosts que compõem o plano de controle de local. Consulte Atualizando hosts do plano de controle de local do Satellite.
Novos locais ativados pelo Red Hat CoreOS
Antes de associar seus hosts ao seu local, configure o proxy do HTTP.

Que tipo de hosts posso usar?

Você pode usar hosts RHEL ou Red Hat CoreOS ao configurar um proxy HTTP. Deve-se editar cada host anexado ao seu local, incluindo os hosts que compõem o plano de controle. Lembre-se de incluir http ou https no arquivo proxy.conf.

O que mais eu preciso saber sobre proxy HTTP?

Para o seu local e clusters Satellite para trabalhar com um proxy, o kubelet nos nós de infraestrutura de plano de controle que são implementados em um local Satellite deve ser capaz de se comunicar ao servidor de API do avião de controle do IBM Cloud. Para ativar essa comunicação, você deve atender a um dos requisitos a seguir.

  • Opção 1: Use o script de conexão de firewall reduzido..

  • Opção 2: O proxy atual é compatível com conexões de longa duração do tipo “ TCP ” (tunelamento TCP ).

  • Opção 3: Você pode criar um proxy secundário em um VSI na mesma rede que seus hosts do Satellite, que suporte conexões de longa duração TCP.

  • Opção 4: Você pode abrir o firewall para tráfego de saída a fim de permitir as conexões TCP. Para obter mais informações, consulte A conectividade de saída necessária para hosts em todas as regiões e, em seguida, encontre os requisitos específicos de rede de saída para sua região.

Não é possível configurar um proxy HTTP para as comunicações entre o trabalhador e o mestre ou para a conexão com os espelhos do pacote.

Configurando o tunelament TCP

Seu proxy deve ser configurado com o tunelamento TCP. As etapas a seguir descrevem a configuração geral do tunelament TCP; consulte a documentação do seu provedor para obter instruções específicas para ele.

  1. Configure seu proxy HTTP para encaminhar o tráfego para todos os quatro endpoints de serviço público das suas localidades. Para localizar seus terminais,

    ibmcloud sat location get --location LOCATION_NAME

    Na saída, localize o campo URL de terminal de serviço público. Nesse campo, é possível derivar os terminais. Por exemplo, se o valor do campo for https://c131-e.us-south.satellite.cloud.ibm.com:31726, os terminais serão https://c131-1.us-south.satellite.cloud.ibm.com:31726, https://c131-2.us-south.satellite.cloud.ibm.com:31726 e https://c131-3.us-south.satellite.cloud.ibm.com:31726.

  2. Certifique-se de que a porta de escuta no proxy HTTP seja a mesma que a do site IBM Cloud.

  3. Atualize o /etc/hosts em todos os seus hosts do Satellite para incluir os terminais de serviço público de local para encaminhar o tráfego ao proxy, em vez de aos terminais da IBM Cloud.

Os detalhes da configuração variam de acordo com o provedor. Configure primeiro seu proxy fora do ambiente Satellite para verificar se a configuração funciona na sua infraestrutura e, em seguida, configure seu proxy no ambiente Satellite. Para obter mais informações sobre como instalar e configurar seu proxy do HTTP, consulte o blog Proxying In Cluster Kube-APIServer Traffic in IBM Cloud Satellite.

Como solicitar acesso à permitida

Para obter acesso à lista de permissões de um proxy d HTTP, crie um ticket no Suporte do IBM.

Por exemplo, use o seguinte pedido como modelo.

Title: Request for addition of HTTP_PROXY config to
       location <LOCATION_ID>
Request Body:
We are requesting the following HTTP_PROXY info be added to
the location_ID listed in the title of this ticket.
Use the following HTTP_PROXY info
BE SURE to include the protocol (http:// or https://)
AND the port (`:PORT_NUMBER`) in the endpoint.
HTTP_PROXY: https://my-proxy-endpoint.com:PORT_NUMBER
HTTPS_PROXY: https://my-proxy-endpoint.com:PORT_NUMBER

Depois que a equipe de suporte processar o ticket, você receberá uma notificação informando que sua localização foi atualizada. Caso seja necessária uma alteração, abra um novo ticket indicando os novos parâmetros. Para encontrar seu LOCATIONID, acesse ibmcloud sat locations.

Configurando seu proxy HTTP

Para configurar um proxy HTTP, deve-se editar cada um de seus hosts, incluindo os hosts no plano de controle. Se hosts já estão anexados a um local, incluindo os hosts que compõem o plano de controle, deve-se removê-los do local antes de poder editá-los. Depois de configurar o proxy, reanexe seus hosts ao local. Para obter mais informações sobre como atualizar seus hosts do plano de controle, consulte “ Atualização dos hosts do plano de controle de um Satellite ”.

  1. Escolha um local de espelho que você deseja usar como proxy. Esse local de espelho é usado quando você configura o seu proxy.

  2. Localize o valor para NO_PROXY.

    • Para hosts do plano de controle, use 172.20.0.1 para RHCOS e NO_PROXY=172.20.0.1,$<REDHAT_PACKAGE_MIRROR_LOCATION> para RHEL.
    • Para hosts Red Hat OpenShift, o NO_PROXY para hosts Red Hat OpenShift deve incluir o primeiro IP da sub-rede de serviço usada para o cluster Red Hat OpenShift. Para localizar esse IP, execute o comando cluster get.
        ibmcloud ks cluster get --cluster <ClusterID>
    ```
    Saída de exemplo

    ```sh {: screen}
    Name:                           hyp-20220306-1-d2   
    ID:                             <ClusterID>  
    ...
    Service Subnet:                 172.21.0.0/16
    ...
    ```
    A partir desta saída, observe que o primeiro IP é `172.21.0.1`, que faz a saída completa para hosts que estão associados com este cluster específico neste exemplo `NO_PROXY=172.20.0.1,172.21.0.1,$REDHAT_PACKAGE_MIRROR_LOCATION` para hosts RHEL e `NO_PROXY=172.20.0.1,172.21.0.1,.REGION.satellite.appdomain.cloud` para hosts RHCOS Por exemplo, `NO_PROXY=172.20.0.1,172.21.0.1,.eu-gb.satellite.appdomain.cloud` é correto para um local de espelho de Londres para hosts RHCOS. Observe que o valor RHCOS inclui `.` antes da região.

    Qualquer tráfego para serviços de cluster do nó do trabalhador deve ser incluído no `NO_PROXY`. Por exemplo, para usar o serviço de registro de imagens para armazenar imagens, adicio `image-registry.openshift-image-registry.svc` a `NO_PROXY` para cada nó do trabalhador; este valor não precisa ser incluído para o plano de controle.

  3. Navegue até /etc/systemd/system.conf.d em seu host. Se esse arquivo não existir, crie-o com o comando a seguir. Insira o <VALUE> para NO_PROXY da etapa 2.

    mkdir -p /etc/systemd/system.conf.d
cat >"/etc/systemd/system.conf.d/proxy.conf" <<EOF
[Manager]
DefaultEnvironment="HTTP_PROXY=https://my-proxy-endpoint.com:PORT_NUMBER" "HTTPS_PROXY=https://my-proxy-endpoint.com:PORT_NUMBER" "NO_PROXY=<VALUE>"
EOF
chmod 0644 /etc/systemd/system.conf.d/proxy.conf

  4. Crie o arquivo ibm-proxy.sh executando o comando a seguir. Insira o <VALUE> para NO_PROXY da etapa 2.

    mkdir -p /etc/profile.d
cat >"/etc/profile.d/ibm-proxy.sh" <<EOF
#!/usr/bin/env bash
HTTP_PROXY="https://my-proxy-endpoint.com:PORT_NUMBER"
HTTPS_PROXY="https://my-proxy-endpoint.com:PORT_NUMBER"
NO_PROXY="<VALUE>"
export HTTP_PROXY
export HTTPS_PROXY
export NO_PROXY
EOF
chmod 0755 /etc/profile.d/ibm-proxy.sh

  5. Reinicialize seu host para captar essa mudança.

  6. Anexe ou reanexe seu host ao local.

  7. Atribua o host de volta para o plano de controle ou para o serviço onde ele foi previamente designado.

  8. Repita essas etapas para cada host.

O valor para REDHAT_PACKAGE_MIRROR_LOCATION depende do local dos espelhos do pacote Red Hat. O REDHAT_PACKAGE_MIRROR_LOCATION poderá ser um curinga se vários espelhos forem usados. Para obter mais informações, consulte Como aplicar um proxy wide system.

Locais de espelho comuns

A lista a seguir fornece alguns locais de espelho comuns.

Azure
definindo separadamente: rhui-1.microsoft.com, rhui-2.microsoft.com, rhui-3.microsoft.com
/etc/yum.repos.d/rh-cloud.repo em baseurl
Google Cloud Provider
cds.rhel.updates.googlecloud.com
/etc/yum.repos.d/rh-cloud.repo em mirrorlist
Serviço da web Amazon
curinga: aws.ce.redhat.com
rhui3.REGION.aws.ce.redhat.com
/etc/yum.repos.d/redhat-rhui.repo em mirrorlist
IBM Cloud
curinga: service.networklayer.com
dal10: rhncapdal1001.service.networklayer.com
/etc/yum.repos.d/redhat.repo em baseurl