Configuration d'un proxy HTTP pour vos hôtes Satellite

Vous pouvez configurer un proxy HTTP de sorte que tout le trafic sortant de vos hôtes Satellite soit acheminé via le proxy.

La configuration d'un proxy HTTP n'est disponible que pour les comptes en liste autorisée.

Quel type d'emplacement dois-je utiliser pour utiliser le proxy HTTP ?

Prenez en compte les types d'emplacements suivants.

Emplacements existants basés sur RHEL: Pour configurer un proxy, votre emplacement doit être activé pour Red Hat CoreOS (RHCOS). Si votre emplacement n'est pas activé pour RHCOS, vous ne pouvez pas configurer de proxy HTTP. Créez un emplacement compatible RHCOS, puis configurez votre proxy HTTP.
Emplacements Red Hat CoreOS existants activés avec des hôtes connectés: Pour configurer un proxy HTTP, vous devez d'abord supprimer vos hôtes de votre emplacement. Après avoir supprimé vos hôtes, voir Configuration de votre proxy HTTP. Notez que vous devez également mettre à jour les hôtes qui constituent votre plan de contrôle d'emplacement. Voir Mise à jour des hôtes du plan de contrôle d'emplacement Satellite.
Nouveaux emplacements Red Hat CoreOS activés: Avant de connecter vos hôtes à votre emplacement, configurez votre proxy HTTP.

Quel type d'hôte puis-je utiliser?

Vous pouvez utiliser des hôtes RHEL ou Red Hat CoreOS lorsque vous configurez un proxy HTTP. Vous devez modifier chaque hôte connecté à votre emplacement, y compris les hôtes qui composent le plan de contrôle. N'oubliez pas d'inclure http ou https dans votre fichier proxy.conf.

Que dois-je savoir d'autre sur le proxy HTTP ?

Pour que votre emplacement Satellite et vos clusters puissent fonctionner avec un proxy, le kubelet sur les noeuds d'infrastructure de plan de contrôle qui sont déployés sur un emplacement Satellite doit pouvoir communiquer avec le serveur d'API de noeud de plan de contrôle IBM Cloud. Pour activer cette communication, vous devez respecter l'une des exigences suivantes.

Option 1: Utilisez le script d'association de pare-feu réduit.
Option 2: le proxy actuel peut prendre en charge les connexions TCP à longue durée de vie (tunnellisation TCP).
Option 3: Vous pouvez créer un proxy secondaire sur une instance de serveur virtuel dans le même réseau que vos hôtes Satellite qui prennent en charge les connexions TCP de longue durée.
Option 4: Vous pouvez ouvrir le pare-feu en sortie pour autoriser les connexions TCP. Pour plus d'informations, voir Connectivité sortante requise pour les hôtes de toutes les régions, puis recherchez les exigences réseau sortantes spécifiques pour votre région.

Vous ne pouvez pas configurer un proxy HTTP pour les communications de noeud worker à maître ou pour la connexion aux miroirs de package.

Configuration de la tunnellisation TCP

Votre proxy doit être configuré avec la tunnellisation TCP. Bien que certaines étapes puissent varier selon votre fournisseur, suivez ces étapes générales pour configurer la tunnellisation TCP.

Configurez votre proxy HTTP pour tunnel le trafic pour les quatre noeuds finaux de service public de votre emplacement. Pour rechercher vos noeuds finaux,
```
ibmcloud sat location get --location LOCATION_NAME
```
dans la sortie, recherchez la zone URL du noeud final de service public. A partir de cette zone, vous pouvez dériver les noeuds finaux. Par exemple, si la valeur de la zone est https://c131-e.us-south.satellite.cloud.ibm.com:31726, les noeuds finaux sont https://c131-1.us-south.satellite.cloud.ibm.com:31726, https://c131-2.us-south.satellite.cloud.ibm.com:31726 et https://c131-3.us-south.satellite.cloud.ibm.com:31726.
Assurez-vous que le port d'écoute sur le proxy HTTP est le même que sur IBM Cloud.
Mettez à jour /etc/hosts sur tous vos hôtes Satellite pour inclure les noeuds finaux de service public de l'emplacement afin qu'ils acheminent le trafic vers le serveur proxy, plutôt que vers les noeuds finaux IBM Cloud.

Votre configuration peut varier d'un fournisseur à l'autre. Pensez à configurer votre proxy en dehors de l'environnement Satellite pour vous assurer que la configuration fonctionne pour votre infrastructure. Ensuite, configurez votre proxy dans l'environnement Satellite. Pour plus d'informations sur la configuration de votre proxy HTTP, voir le blogue Proxying In Cluster Kube-APIServer Traffic in IBM Cloud Satellite.

Demande d'accès à la liste autorisée

Pour accéder à la liste autorisée pour le proxy HTTP, créez un ticket auprès du support IBM.

Par exemple, utilisez la demande suivante comme modèle.

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

Une fois que le support a traité le ticket, vous recevrez une notification indiquant que votre emplacement est mis à jour. Si une modification est nécessaire, vous devez ouvrir un nouveau ticket indiquant les nouveaux paramètres. Pour rechercher votre LOCATIONID en exécutant ibmcloud sat locations.

Configuration de votre proxy HTTP

Pour configurer un proxy HTTP, vous devez modifier chacun de vos hôtes, y compris les hôtes du plan de contrôle. Si vos hôtes sont déjà connectés à un emplacement, y compris les hôtes qui composent le plan de contrôle, vous devez les supprimer de l'emplacement avant de pouvoir les modifier. Après avoir configuré le proxy, reconnectez vos hôtes à l'emplacement. Pour plus d'informations sur la mise à jour de vos hôtes de plan de contrôle, voir Mise à jour des hôtes de plan de contrôle d'emplacement Satellite.

Choisissez un emplacement miroir à utiliser pour un proxy. Cet emplacement miroir est utilisé lorsque vous définissez votre proxy.
Recherchez la valeur de NO_PROXY.
- Pour les hôtes de plan de contrôle, utilisez 172.20.0.1 pour RHCOS et NO_PROXY=172.20.0.1,$<REDHAT_PACKAGE_MIRROR_LOCATION> pour RHEL.
- Pour les hôtes Red Hat OpenShift, les hôtes NO_PROXY pour Red Hat OpenShift doivent inclure la première adresse IP du sous-réseau de service utilisé pour le cluster Red Hat OpenShift. Pour trouver cette adresse IP, exécutez la commande cluster get.
```
ibmcloud ks cluster get --cluster <ClusterID>
```
  Exemple de sortie
```
Name:                           hyp-20220306-1-d2   
ID:                             <ClusterID>  
...
Service Subnet:                 172.21.0.0/16
...
```
  A partir de cette sortie, notez que la première adresse IP est 172.21.0.1, ce qui génère la sortie complète pour les hôtes associés à ce cluster spécifique dans cet exemple NO_PROXY=172.20.0.1,172.21.0.1,$REDHAT_PACKAGE_MIRROR_LOCATION pour les hôtes RHEL et NO_PROXY=172.20.0.1,172.21.0.1,.REGION.satellite.appdomain.cloud pour les hôtes RHCOS. Par exemple, NO_PROXY=172.20.0.1,172.21.0.1,.eu-gb.satellite.appdomain.cloud est correct pour un emplacement miroir de Londres pour les hôtes RHCOS. Notez que la valeur RHCOS inclut . avant la région.
  
  Tout trafic vers les services de cluster à partir du noeud worker doit être inclus dans NO_PROXY. Par exemple, pour utiliser le service de registre d'images afin de stocker des images, ajoutez image-registry.openshift-image-registry.svc à NO_PROXY pour chaque noeud worker ; cette valeur n'a pas besoin d'être incluse pour le plan de contrôle.

Accédez à /etc/systemd/system.conf.d sur votre hôte. Si ce fichier n'existe pas, créez-le à l'aide de la commande suivante. Entrez <VALUE> pour NO_PROXY à partir de l'étape 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

Créez le fichier ibm-proxy.sh en exécutant la commande suivante. Entrez <VALUE> pour NO_PROXY à partir de l'étape 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

Redémarrez votre hôte pour inclure ce changement.
Connectez ou reconnectez votre hôte à l'emplacement.
Réaffectez l'hôte au plan de contrôle ou au service où il a été précédemment affecté.
Répétez ces étapes pour chaque hôte.

La valeur de REDHAT_PACKAGE_MIRROR_LOCATION dépend de l'emplacement des miroirs de package Red Hat. REDHAT_PACKAGE_MIRROR_LOCATION peut être un caractère générique si plusieurs miroirs sont utilisés. Pour plus d'informations, voir How to apply a system wide proxy.

Emplacements miroirs communs

La liste suivante fournit des emplacements miroirs communs.

Azure: définissant séparément : rhui-1.microsoft.com, rhui-2.microsoft.com, rhui-3.microsoft.com; /etc/yum.repos.d/rh-cloud.repo sous baseurl
Fournisseur Google Cloud: cds.rhel.updates.googlecloud.com; /etc/yum.repos.d/rh-cloud.repo sous mirrorlist
Service Web Amazon: Caractère générique : aws.ce.redhat.com; rhui3.REGION.aws.ce.redhat.com; /etc/yum.repos.d/redhat-rhui.repo sous mirrorlist
IBM Cloud: Caractère générique : service.networklayer.com; dal10: rhncapdal1001.service.networklayer.com; /etc/yum.repos.d/redhat.repo sous baseurl