Per il connettore S3A di Hadoop 3.4.2 tramite un proxy HTTP, unite queste voci alla configurazione Hadoop dell'operazione, in genere il core-site.xml pertinente:

<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>

Per un test autorizzato in modo indipendente verso un endpoint S3 raggiungibile pubblicamente senza credenziali del proxy, il elenco di proxy HTTP fornisce valori candidati per il nome host e la porta esplicita. fs.s3a.proxy.ssl.enabled=false seleziona una connessione HTTP semplice a questo proxy; non disattiva TLS da S3A a S3. Usate il valore corrispondente al listener reale del proxy.

Controllate entrambi i consumatori. Il client che invia può elencare S3 correttamente mentre i container delle attività map di DistCp non riescono a raggiungere il proxy né a caricare la stessa configurazione del filesystem. Sono quelle attività a eseguire i trasferimenti.

Per un'attività non riuscita, conservate host di esecuzione, configurazione effettiva ed endpoint scelto insieme all'errore. L'ambiente della shell di invio non è una prova sufficiente per un worker.

Queste impostazioni governano s3a://. Le vecchie ricette del connettore Jets3t configurano un'altra implementazione e non sostituiscono le opzioni S3A usate da questo lavoro.

Articoli correlati