Hadoop DistCp : configurer le proxy S3A sur les tâches des workers

Pour le connecteur S3A de Hadoop 3.4.2 via un proxy HTTP, fusionnez ces entrées dans la configuration Hadoop de l'opération, généralement le core-site.xml approprié :

<property>
  <name>fs.s3a.proxy.host</name>
  <value>gateway.example</value>
</property>
<property>
  <name>fs.s3a.proxy.port</name>
  <value>8080</value>
</property>
<property>
  <name>fs.s3a.proxy.ssl.enabled</name>
  <value>false</value>
</property>

Pour un test autorisé de manière indépendante contre un point de terminaison S3 accessible publiquement sans identifiants de proxy configurés, la liste de proxys HTTP fournit des valeurs candidates pour le nom d'hôte et le port explicite. fs.s3a.proxy.ssl.enabled=false sélectionne une connexion HTTP simple vers ce proxy ; il ne désactive pas TLS entre S3A et S3. Utilisez la valeur correspondant à l'écouteur réel du proxy.

Vérifiez les deux consommateurs. Le client qui soumet peut lister S3 avec succès alors que les conteneurs des tâches map de DistCp ne peuvent pas joindre le proxy ni charger la même configuration de système de fichiers. Ce sont ces tâches qui effectuent les transferts.

Pour une tâche en échec, conservez l'hôte d'exécution, la configuration effective et le point de terminaison choisi avec l'erreur. L'environnement du shell de soumission ne constitue pas une preuve suffisante pour un worker.

Ces paramètres régissent s3a://. Les anciennes recettes du connecteur Jets3t configurent une autre implémentation et ne remplacent pas les options S3A utilisées par cette tâche.