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.
Red Hat existantes : emplacements activés pour l' CoreOS avec des hôtes associé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 d'associer 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 lors de la configuration d'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 de longue durée (tunneling TCP ).
Option 3 : vous pouvez créer un proxy secondaire sur un VSI au sein du même réseau que vos hôtes Satellite, qui prend en charge les connexions TCP de longue durée.
Option 4 : Vous pouvez ouvrir le pare-feu sortant 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 du tunneling d' TCP

Votre proxy doit être configuré avec la tunnellisation TCP. Les étapes suivantes décrivent la configuration générale du tunneling d' TCP; consultez la documentation de votre fournisseur pour obtenir des instructions spécifiques à celui-ci.

Configurez votre proxy HTTP pour acheminer le trafic vers les quatre points de terminaison de service public de vos sites. 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 du proxy HTTP est le même que celui de 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.

Les détails de configuration varient selon le fournisseur. Commencez par configurer votre proxy en dehors de l'environnement Satellite afin de vérifier que la configuration fonctionne correctement pour votre infrastructure, puis configurez votre proxy dans l'environnement Satellite. Pour plus d'informations sur l'installation et la configuration de votre proxy HTTP, consultez l'article de blog Proxying In Cluster Kube-APIServer Traffic in IBM Cloud Satellite.

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

Pour accéder à la liste blanche du proxy d' 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 service d'assistance a traité votre ticket, vous recevez une notification vous informant que votre localisation a été mise à jour. Si une modification est nécessaire, créez un nouveau ticket en précisant les nouveaux paramètres. Pour trouver votre LOCATIONID, exécutez 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, consultez la section Mise à jour des hôtes de plan de contrôle d' Satellite.

Choisissez un emplacement de miroir que vous souhaitez utiliser comme 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

    ```sh {: screen}
    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