

Amazon non CodeCatalyst è più aperta a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta [Come migrare da CodeCatalyst](migration.md).

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Richiesta di una versione del pacchetto con repository upstream
<a name="packages-upstream-repositories-request"></a>

L'esempio seguente mostra i possibili scenari in cui un gestore di pacchetti richiede un pacchetto da un CodeCatalyst repository di pacchetti che dispone di repository upstream.

Per questo esempio, un gestore di pacchetti, ad esempio`npm`, richiede una versione del pacchetto da un archivio di pacchetti denominato `downstream` che ha più repository upstream. Quando viene richiesto il pacchetto, può verificarsi quanto segue:
+  Se `downstream` contiene la versione del pacchetto richiesta, viene restituita al client. 
+  Se `downstream` non contiene la versione del pacchetto richiesta, la CodeCatalyst cerca nei `downstream` repository upstream, nell'ordine di ricerca configurato. Se viene trovata la versione del pacchetto, viene copiato un riferimento ad essa e la versione del pacchetto viene restituita al `downstream` client. 
+  Se nessuno dei `downstream` suoi repository upstream contiene la versione del pacchetto, al client viene restituita una `Not Found` risposta HTTP 404.

 Il numero massimo di repository diretti upstream consentito per un repository è 10. Il numero massimo di CodeCatalyst ricerche nei repository quando viene richiesta una versione del pacchetto è 25. 

## Package retention dai repository upstream
<a name="package-retention-upstream-repos"></a>

Se una versione del pacchetto richiesta viene trovata in un repository upstream, viene mantenuto un riferimento ad essa ed è sempre disponibile nell'archivio che l'ha richiesta. Ciò garantisce l'accesso ai pacchetti in caso di interruzione imprevista dell'archivio upstream. La versione del pacchetto mantenuta non è influenzata da nessuno dei seguenti fattori: 
+  Eliminazione del repository upstream. 
+  Disconnessione del repository upstream dal repository downstream. 
+  Eliminazione della versione del pacchetto dal repository upstream. 
+  Modifica della versione del pacchetto nell'archivio upstream (ad esempio, aggiungendovi una nuova risorsa). 

## Recupero dei pacchetti tramite una relazione a monte
<a name="fetching-packages-through-an-upstream-relationship"></a>

CodeCatalyst può recuperare pacchetti tramite più repository collegati chiamati repository upstream. Se un repository di CodeCatalyst pacchetti ha una connessione upstream a un altro repository di CodeCatalyst pacchetti che ha una connessione upstream a un repository gateway, le richieste di pacchetti non presenti nell'archivio upstream vengono copiate dal repository esterno. Ad esempio, considerate la seguente configurazione: un repository denominato `repo-A` ha una connessione upstream al repository del gateway,. `npm-public-registry-gateway` `npm-public-registry-gateway`ha una connessione upstream al repository pubblico dei pacchetti,. [https://npmjs.com](https://npmjs.com)

![Semplice diagramma del repository upstream che mostra tre repository concatenati tra loro.](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/upstream-with-external.png)


Se `npm` è configurato per utilizzare il `repo-A` repository, l'esecuzione `npm install` avvia la copia dei pacchetti da dentro. [https://npmjs.com](https://npmjs.com)`npm-public-registry-gateway` Vengono inoltre inserite le versioni installate. `repo-A` L'esempio seguente installa`lodash`.

```
$ npm config get registry
https://packages.{{region}}.codecatalyst.aws/npm/{{space-name}}/{{proj-name}}/{{repo-name}}/
$ npm install lodash
+ lodash@4.17.20
added 1 package from 2 contributors in 6.933s
```

Dopo l'esecuzione`npm install`, `repo-A` contiene solo la versione più recente (`lodash 4.17.20`) perché è la versione che è stata recuperata da`npm`. `repo-A`

 Perché `npm-public-registry-gateway` dispone di una connessione upstream esterna a [https://npmjs.com](https://npmjs.com), tutte le versioni del pacchetto da cui vengono importate [https://npmjs.com](https://npmjs.com)vengono archiviate in. `npm-public-registry-gateway` Queste versioni del pacchetto avrebbero potuto essere recuperate da qualsiasi repository downstream con una connessione upstream che porta a. `npm-public-registry-gateway` 

Il contenuto di `npm-public-registry-gateway` fornisce un modo per visualizzare tutti i pacchetti e le versioni dei pacchetti importati nel tempo. [https://npmjs.com](https://npmjs.com)

## Conservazione dei pacchetti in repository intermedi
<a name="package-retention-intermediate-repositories"></a>

 CodeCatalyst consente di concatenare repository upstream. Ad esempio, `repo-A` può avere `repo-B` come repository upstream e `repo-B` può avere `repo-C` come repository upstream. Questa configurazione rende le versioni del pacchetto in `repo-B` e disponibili da. `repo-C` `repo-A` 

![Semplice diagramma del repository upstream che mostra tre repository concatenati tra loro.](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/upstream-chaining.png)


 Quando un gestore di pacchetti si connette al repository `repo-A` e recupera una versione del pacchetto dal repository`repo-C`, la versione del pacchetto non viene conservata nell'archivio. `repo-B` La versione del pacchetto viene conservata solo nell'archivio a valle più lontano, che in questo esempio è. `repo-A` Non viene conservata in nessun archivio intermedio. Questo vale anche per le catene più lunghe; ad esempio, se ci fossero quattro repository:`repo-A`,, e `repo-B` `repo-C``repo-D`, e un gestore di pacchetti collegato al quale è stata `repo-A` recuperata una versione del pacchetto`repo-D`, la versione del pacchetto verrebbe conservata in ma non in o. `repo-A` `repo-B` `repo-C` 

Il comportamento di conservazione dei pacchetti è simile quando si estrae una versione del pacchetto da un archivio pubblico di pacchetti, tranne per il fatto che la versione del pacchetto viene sempre conservata nell'archivio del gateway che ha la connessione diretta a monte all'archivio pubblico. Ad esempio, ha come repository upstream`repo-A`. `repo-B` `repo-B`ha `npm-public-registry-gateway` come repository upstream, che ha una connessione upstream al repository pubblico, **npmjs.com**; vedi lo schema seguente.

![Diagramma del repository upstream che mostra tre repository concatenati tra loro con una connessione upstream esterna a npmjs.com.](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/packages/upstream-chaining-external.png)


 **Se un gestore di pacchetti connesso `repo-A` richiede una versione specifica del pacchetto, ad esempio *lodash 4.17.20*, e la versione del pacchetto non è presente in nessuno dei tre repository, verrà recuperata da npmjs.com.** **Quando *lodash 4.17.20* viene recuperato, viene mantenuto in `repo-A` quanto si tratta del repository a valle più lontano e poiché dispone della connessione a monte al repository esterno pubblico, npmjs.com. `npm-public-registry-gateway`** *lodash* 4.17.20 `repo-B` non viene mantenuto perché si tratta di un repository intermedio. 