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à. # App **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). Un'*app OpsWorks * Stacks rappresenta il codice che desideri eseguire su un server di applicazioni. Il codice stesso risiede in un repository come un archivio Amazon S3; l'app contiene le informazioni necessarie per distribuire il codice nelle istanze dell'application server appropriate. Quando distribuisci un'applicazione, OpsWorks Stacks attiva un evento Deploy, che esegue le ricette Deploy di ogni livello. OpsWorks Stacks installa anche [gli attributi di configurazione e distribuzione dello stack](workingcookbook-json.md) che contengono tutte le informazioni necessarie per distribuire l'app, come l'archivio dell'app e i dati di connessione al database. Devi implementare ricette personalizzate che recuperano i dati di distribuzione dell'app dagli attributi di configurazione e distribuzione dello stack e gestiscono le attività di distribuzione. **Topics** + [Aggiunta di app](workingapps-creating.md) + [Distribuzione di app](workingapps-deploying.md) + [Modifica delle app](workingapps-editing.md) + [Connessione di un'applicazione a un server di database](workingapps-connectdb.md) + [Utilizzo delle variabili di ambiente](apps-environment-vars.md) + [Passaggio di dati alle applicazioni](apps-data.md) + [Utilizzo di chiavi SSH di repository Git](workingapps-deploykeys.md) + [Utilizzo di domini personalizzati](workingapps-domains.md) + [Uso di SSL](workingsecurity-ssl.md) # Aggiunta di app **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). La prima fase del processo di distribuzione di un'applicazione nei server di applicazioni prevede l'aggiunta di un'app allo stack. L'app rappresenta l'applicazione e contiene una serie di metadati, ad esempio il nome e il tipo dell'applicazione, nonché le informazioni necessarie per distribuire l'applicazione sulle istanze del server, ad esempio l'URL dell'archivio. Devi disporre delle autorizzazioni Manage (Gestione) per aggiungere un'app a uno stack. Per ulteriori informazioni, consulta [Gestione delle autorizzazioni utente](opsworks-security-users.md). **Nota** La procedura in questa sezione è valida per stack Chef 12 e stack di versioni più recenti. Per ulteriori informazioni su come aggiungere app ai livelli negli stack Chef 11, consulta [Fase 2.4: Creazione e distribuzione di un'app - Chef 11](gettingstarted-simple-app.md). **Per aggiungere un'app a uno stack.** 1. Inserisci il codice nel tuo repository preferito: un archivio Amazon S3, un repository Git, un repository Subversion o un archivio HTTP. Per ulteriori informazioni, consulta [Origine dell'applicazione](#workingapps-creating-source). 1. Fare clic su **Apps (App)** nel riquadro di navigazione. Nella pagina **Apps (App)** fare clic su **Add an app (Aggiungi un'app)** per la prima app. Per le app successive, fare clic su **\$1App**. 1. Utilizzare la pagina **App New (Nuova app)** per configurare l'app, come descritto nella sezione seguente. ## Configurazione di un'app La pagina **Add App (Aggiungi app)** è composta dalle seguenti sezioni: **Settings (Impostazioni)**, **Application source (Origine applicazione)**, **Data Sources (Origini dati)**, **Environment Variables (Variabili di ambiente)**, **Add Domains (Aggiungi domini)** e **SSL Settings (Impostazioni SSL)**. **Topics** + [Settings](#workingapps-creating-settings) + [Origine dell'applicazione](#workingapps-creating-source) + [Origini dati](#workingapps-creating-data) + [Variabili di ambiente](#workingapps-creating-environment) + [Impostazioni relative a SSL e dominio](#workingapps-creating-domain-ssl) ### Settings **Name** Il nome dell'app, utilizzato per rappresentare l'app nell'interfaccia utente. OpsWorks Stacks utilizza questo nome anche per generare un nome breve per l'app che viene utilizzato internamente e per identificare l'app negli attributi di [configurazione e distribuzione dello stack](workingcookbook-json.md). Dopo aver aggiunto l'app allo stack, per visualizzare il nome breve fare clic su **Apps (App)** nel riquadro di navigazione e quindi scegliere il nome dell'app per aprire la pagina dei dettagli. ****Document root (Radice documento)**** OpsWorks Stacks assegna l'impostazione **root del documento** all'[`[:document_root]`](attributes-json-deploy.md#attributes-json-deploy-app-root)attributo negli attributi dell'app. `deploy` Il valore predefinito è `null`. Le ricette di distribuzione possono recuperare tale valore dagli attributi `deploy` tramite la sintassi di nodo Chef standard e quindi distribuire il codice specificato nella posizione appropriata sul server. Per ulteriori informazioni su come distribuire le app, consulta [Ricette di ditribuzione](create-custom-deploy.md). ### Origine dell'applicazione Puoi distribuire app dai seguenti tipi di repository: Git, pacchetto Amazon S3, pacchetto HTTP e Altro. Tutti i tipi di archivio richiedono di specificare il tipo e l'URL dell'archivio. I singoli tipi di archivio hanno requisiti propri, come descritto di seguito. **Nota** OpsWorks Stacks distribuisce automaticamente le applicazioni dai repository standard ai livelli server integrati. Se utilizzi il tipo di repository Altro, che è l'unica opzione per gli stack di Windows, OpsWorks Stacks inserisce le informazioni del repository negli [`deploy`attributi](workingcookbook-json.md#workingcookbook-json-deploy) dell'app, ma devi implementare ricette personalizzate per gestire le attività di distribuzione. **Topics** + [Archivio HTTP](#w2ab1c14c57c13c11b8b8) + [Archivio Amazon S3](#w2ab1c14c57c13c11b8c10) + [Archivio Git](#w2ab1c14c57c13c11b8c12) + [Altri archivi](#w2ab1c14c57c13c11b8c14) #### Archivio HTTP Per usare come archivio un server HTTP accessibile pubblicamente: 1. Crea un archivio compresso (zip, gzip, bzip2, Java WAR o tarball) della cartella che contiene il codice dell'app e gli eventuali file associati. **Nota** OpsWorks Stacks non supporta archivi tar non compressi. 1. Caricare il file di archivio sul server. 1. Per specificare l'archivio nella console, selezionare HTTP Archive (Archivio HTTP) come tipo di repository e immettere l'URL. Se l'archivio è protetto da password, in **Application** Source, specifica le credenziali di accesso. #### Archivio Amazon S3 Per utilizzare un bucket Amazon Simple Storage Service come repository: 1. Crea un bucket Amazon S3 pubblico o privato. Per ulteriori informazioni, consulta la [documentazione di Amazon S3](https://aws.amazon.com/documentation/s3/). 1. OpsWorks Affinché Stacks possa accedere ai bucket privati, devi essere un utente con almeno diritti di sola lettura sul bucket Amazon S3 e avrai bisogno dell'ID della chiave di accesso e della chiave di accesso segreta. Per ulteriori informazioni, consulta la [documentazione di AWS Identity and Access Management](https://docs.aws.amazon.com/iam/). 1. Inserire il codice e i file associati in una cartella e archiviare la cartella in un archivio compresso (zip, gzip, bzip2, Java WAR o tarball). **Nota** OpsWorks Stacks non supporta archivi tar non compressi. 1. Carica il file di archivio nel bucket Amazon S3 e registra l'URL. 1. Per specificare il repository nella console OpsWorks Stacks, imposta il **tipo di repository** su **S3 Archive e inserisci l'URL dell'archivio**. Per un archivio privato, è necessario fornire anche l'ID di una chiave di accesso AWS e la chiave di accesso segreta la cui policy concede le autorizzazioni per accedere al bucket. Lasciare vuote queste impostazioni per gli archivi pubblici. #### Archivio Git Un repository [Git](http://git-scm.com/) fornisce il controllo del codice sorgente e il controllo delle versioni. OpsWorks Stacks supporta siti di repository ospitati pubblicamente come [GitHub](https://github.com/)[Bitbucket](https://bitbucket.org) e server Git ospitati privatamente. Sia per le app che per i moduli Git secondari, il formato utilizzato per specificare l'URL dell'archivio in **Application Source (Origine applicazione)** dipende se l'archivio è pubblico o privato: **Archivio pubblico**: utilizza i protocolli di sola lettura HTTPS o Git. Ad esempio, [Nozioni di base sugli stack Linux Chef 11](gettingstarted.md) utilizza un GitHub archivio pubblico a cui è possibile accedere tramite uno dei seguenti formati di URL: + Protocollo Git di sola lettura: **git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git** + HTTPS: **https://github.com/amazonwebservices/opsworks-demo-php-simple-app.git** **Archivio privato**: utilizza il read/write formato SSH mostrato in questi esempi: + Archivi Github: **git@github.com:*project*/*repository***. + Archivi in un server Git: ***user*@*server*:*project*/*repository*** Se selezioni **Git** in **Source Control (Controllo origine)** vengono visualizzate altre due impostazioni opzionali: **Repository SSH key (Chiave SSH archivio)** Devi specificare una chiave SSH di distribuzione per accedere agli archivi Git privati. Questo campo richiede la chiave privata; la chiave pubblica è assegnata al repository Git. Per i moduli secondari Git, la chiave specificata deve avere accesso a tali moduli secondari. Per ulteriori informazioni, consulta [Utilizzo di chiavi SSH di repository Git](workingapps-deploykeys.md). La chiave SSH di deployment non può richiedere una password; OpsWorks Stacks non ha modo di passarla. **Branch/Revision (Ramo/Versione)** Se il repository ha più rami, OpsWorks Stacks scarica il ramo principale per impostazione predefinita. Per specificare un ramo particolare, inserisci il nome del ramo, l' SHA1 hash o il nome del tag. Per specificare un determinato commit, immetti l'identificatore di commit completo a 40 cifre esadecimali. #### Altri archivi Se gli archivi standard non soddisfano i requisiti, puoi usare altri archivi, ad esempio [Bazaar](http://bazaar.canonical.com/en/). Tuttavia, OpsWorks Stacks non distribuisce automaticamente le app da tali repository. Devi implementare le ricette personalizzati per gestire il processo di distribuzione e assegnarle agli eventi Deploy (Distribuzione) dei livelli appropriati. Per un esempio di come implementare le ricette di ditribuzione (Distribuzione), consulta [Ricette di ditribuzione](create-custom-deploy.md). ### Origini dati Questa sezione collega un database all'app. Sono disponibili le seguenti opzioni: + **RDS**: collega uno dei livelli di servizio [Amazon RDS](workinglayers-db-rds.md) dello stack. + **Nessuno**: non collegare un server di database. Se selezioni **RDS**, devi specificare le seguenti informazioni. **Istanza di database** L'elenco include tutti i livelli di servizio Amazon RDS. Puoi anche selezionare una delle seguenti opzioni: (Obbligatorio) Specificare il server di database da collegare all'app. Il contenuto dell'elenco dipende dall'origine dati. + **RDS**: un elenco dei livelli di servizio Amazon RDS dello stack. **Nome del database** (Opzionale) Specificare un nome di database. + Livello Amazon RDS: inserisci il nome del database che hai specificato per l'istanza Amazon RDS. Puoi ottenere il nome del database dalla [console Amazon RDS](https://console.aws.amazon.com/rds/). [Quando distribuisci un'app con un database collegato, OpsWorks Stacks aggiunge la connessione dell'istanza di database agli attributi dell'app. `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) Puoi scrivere una ricetta personalizzata per recuperare le informazioni dagli attributi `deploy` e inserirle in un file a cui l'applicazione può accedere. Questo è l'unico modo per fornire informazioni sulla connessione al database all'applicazione di tipo Other (Altro). Per ulteriori informazioni su come gestire le connessioni al database, consulta [Connessione a un database](workingapps-connectdb.md). Per scollegare un server di database da un'app, [modifica la configurazione dell'app](workingapps-editing.md) per specificare un server di database diverso oppure nessun server. ### Variabili di ambiente Per ogni app puoi specificare un set di variabili di ambiente specifiche per l'app. Ad esempio, se disponi di due applicazioni, le variabili di ambiente definite per la prima app non sono disponibili nella seconda app e viceversa. Puoi inoltre definire la stessa variabile di ambiente per più app e assegnarle un valore diverso per ogni applicazione. **Nota** Non c'è un limite specifico al numero di variabili di ambiente. Tuttavia, la dimensione della struttura dati associata, che include i nomi, i valori e i valori dei flag protetti delle variabili, non può superare i 20 KB. Questo limite deve essere tale da poter far fronte la maggior parte, se non tutti i casi d'uso. Il superamento di tale limite potrebbe generare un errore del servizio (console) o un'eccezione (API) accompagnata dal messaggio "Environment: is too large (maximum is 20KB)" ("Variabile di ambiente troppo grande (massimo: 10 KB)"). OpsWorks [Stacks memorizza le variabili come attributi negli attributi dell'app. `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) Puoi impostare le ricette personalizzati in modo che recuperino tali valori utilizzando la sintassi di nodo standard di Chef. Per esempi di come accedere alle variabili di ambiente di un'app, consulta [Utilizzo delle variabili di ambiente](apps-environment-vars.md). **Chiave** Nome della variabile. Può contenere fino a 64 lettere maiuscole e minuscole, numeri e caratteri di sottolineatura (\$1), ma deve iniziare con una lettera o un carattere di sottolineatura. **Valore** Valore della variabile. Può contenere fino a 256 caratteri, che devono essere tutti stampabili. **Protected value (Valore protetto)** Indica se il valore è protetto. Questa impostazione consente di nascondere le informazioni sensibili, ad esempio le password. Se imposti **Protected value (Valore protetto)** per una variabile, dopo aver creato l'app: + Nella pagina dei dettagli dell'app viene visualizzato solo il nome della variabile e non il valore. + Se disponi dell'autorizzazione per modificare l'app, puoi fare clic su **Update value (Aggiorna valore)** per specificare un nuovo valore, ma non puoi visualizzare o modificare il valore precedente. **Nota** I log di distribuzione Chef talvolta possono includere variabili di ambiente. Questo significa che nella console possono essere visualizzate variabili protette. Per evitare che le variabili protette vengano visualizzate nella console, ti consigliamo di utilizzare i bucket Amazon S3 come storage per le variabili protette che non desideri vengano visualizzate nella console. Un esempio di come utilizzare un bucket S3 a questo scopo è disponibile in [Utilizzo di un bucket Amazon S3](gettingstarted.walkthrough.photoapp.md) in questa guida. ### Impostazioni relative a SSL e dominio Per il tipo di app Altro, OpsWorks Stacks aggiunge le impostazioni agli attributi dell'app. `deploy` La ricette possono recuperare i dati da questi attributi e configurare il server in base alle esigenze. **Impostazioni relative al dominio** Questa sezione include un campo opzionale **Add Domains (Aggiungi domini)** per specificare i domini. Per ulteriori informazioni, consulta [Utilizzo di domini personalizzati](workingapps-domains.md). **Impostazioni SSL** Questa sezione include un pulsante di alternanza **SSL Support (Supporto SSL)** che puoi utilizzare per abilitare o disabilitare il protocollo SSL. Se fai clic su **Yes (Sì)**, dovrai fornire le informazioni sul certificato SSL. Per ulteriori informazioni, consulta [Uso di SSL](workingsecurity-ssl.md). # Distribuzione di app **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). Lo scopo principale della distribuzione è distribuire il codice dell'applicazione e i file correlati in istanze del server applicazioni. L'operazione di distribuzione viene gestita dalle ricette di distribuzione di ogni istanza, determinate dal livello dell'istanza. Quando avvii un'istanza, una volta completate le ricette di installazione, OpsWorks Stacks esegue automaticamente le ricette Deploy dell'istanza. Tuttavia, quando aggiungi o modifichi un'app, devi distribuirla manualmente in qualsiasi istanza online. Per distribuire un'app, devi avere autorizzazioni di gestione o distribuzione. Per ulteriori informazioni, consulta [Gestione delle autorizzazioni utente](opsworks-security-users.md). **Per distribuire un'app** 1. Nella pagina **Apps (App)** fare clic sull'operazione **deploy (distribuzione)** dell'app. ![\[Apps page showing SimplePHP app with deploy, edit, and delete action options.\]](http://docs.aws.amazon.com/it_it/opsworks/latest/userguide/images/apps_with_content.png) **Nota** È possibile distribuire un'app anche facendo clic su **Deployments (Distribuzioni) **nel riquadro di navigazione. Nella pagina **Deployments & Commands (Distribuzioni e comandi)** fare clic su **Deploy an app (Distribuisci un'app)**. A questo punto, è possibile scegliere anche l'app da distribuire. 1. Specificare le impostazioni seguenti: + Obbligatorio: impostare **Command (Comando)** su **deploy (distribuzione)**, se non è già selezionato. + Facoltativo: includere un commento. 1. Fate clic su **Avanzato >>** per specificare un codice JSON personalizzato. OpsWorks Stacks aggiunge un set di [attributi di configurazione e distribuzione dello stack all'oggetto](workingcookbook-json.md) nodo. Gli attributi `deploy` contengono i dettagli della distribuzione e possono essere utilizzati da ricette di distribuzione per gestire l'installazione e la configurazione. Negli stack Linux, puoi utilizzare il campo JSON personalizzato per [sovrascrivere le impostazioni OpsWorks Stacks predefinite o passare impostazioni personalizzate alle](workingcookbook-json-override.md) tue ricette personalizzate. Per ulteriori informazioni su come utilizzare codice JSON personalizzato, consulta [Utilizzo di un JSON personalizzato](workingstacks-json.md). **Nota** Se specifichi qui codice JSON personalizzato, questo viene aggiunto agli attributi di configurazione e distribuzione dello stack solo per questa distribuzione. Se vuoi aggiungere codice JSON personalizzato in modo permanente, devi [aggiungerlo allo stack](workingstacks-json.md). Il codice JSON personalizzato è limitato a 120 KB. Se hai bisogno di maggiore capacità, ti consigliamo di archiviare alcuni dati su Amazon S3. Le ricette personalizzate possono quindi utilizzare l'interfaccia a riga di comando di AWS oppure l'[SDK AWS per Ruby](https://aws.amazon.com/documentation/sdk-for-ruby/) per scaricare i dati dal bucket all'istanza. Per vedere un esempio, consulta [Utilizzo dell'SDK for Ruby](cookbooks-101-opsworks-s3.md). 1. In **Instances (Istanze)** fare clic su **Advanced >> (Avanzate >>)** e specificare le istanze in cui eseguire il comando di distribuzione. Il comando di distribuzione attiva un evento Deploy (Distribuzione), che esegue le ricette di distribuzione nelle istanze selezionate. Le ricette di distribuzione per il server applicazioni associato scaricano il codice e i file correlati dal repository e li installano nell'istanza e di conseguenza è normalmente possibile selezionare tutte le istanze del server applicazioni associate. Tuttavia, poiché altri tipi di istanza potrebbe richiedere alcune modifiche di configurazione per supportare la nuova app, è spesso utile eseguire le ricette di distribuzione anche in queste istanze. Le ricette aggiornano la configurazione nel modo appropriato, ma non installano i file dell'app. Per ulteriori informazioni sulle ricette, consulta [Libri di ricette e ricette](workingcookbook.md). 1. Fare clic su **Deploy (Distribuisci)** per eseguire le ricette di distribuzione nelle istanze specificate. Viene visualizzata la pagina Deployment (Distribuzione). Una volta completato il processo, OpsWorks Stacks contrassegna l'app con un segno di spunta verde per indicare la corretta implementazione. Se la distribuzione non riesce, OpsWorks Stacks contrassegna l'app con una X rossa. In tal caso, puoi andare alla pagina **Distribuzioni ed esaminare il registro** di distribuzione per ulteriori informazioni. ![\[Deployment status page showing successful deployment of PHPTestApp with details.\]](http://docs.aws.amazon.com/it_it/opsworks/latest/userguide/images/deployed_app.png) **Nota** Quando distribuisci un aggiornamento per un'app JSP, Tomcat potrebbe non riconoscere l'aggiornamento e continuare invece a eseguire la versione esistente dell'app. Questo può verificarsi, ad esempio, se distribuisci l'app come file ZIP contenente solo una pagina JSP. Per assicurarti che Tomcat esegua la versione distribuita più recente, la directory root del progetto deve includere una directory WEB-INF contenente un file `web.xml`. Un file `web.xml` può includere vari tipi di contenuto, ma quello riportato di seguito è sufficiente a garantire che Tomcat riconosca gli aggiornamenti ed esegua la versione dell'app attualmente distribuita. Non devi modificare la versione per ogni aggiornamento. Tomcat riconoscerà l'aggiornamento anche se la versione non è cambiata. ``` appVersion 0.1 ``` ## Altri comandi di distribuzione La pagina **Deploy app (Distribuisci app)** include diversi altri comandi per la gestione delle app e i server associati. Tra i comandi seguenti, solo **Undeploy (Annulla distribuzione)** è disponibile per app in stack Chef 12. **Undeploy (Annulla distribuzione)** Attiva un [evento del ciclo di vita](workingcookbook-events.md) Undeploy (Annullamento distribuzione), che esegue ricette di annullamento della distribuzione per rimuovere tutte le versioni dell'app dalle istanze specificate. **Rollback** Ripristina la versione dell'app distribuita in precedenza. Ad esempio, se hai distribuito l'app tre volte e quindi esegui **Rollback**, il server renderà disponibile l'app della seconda distribuzione. Se esegui di nuovo **Rollback**, il server renderà disponibile l'app della prima distribuzione. Per impostazione predefinita, OpsWorks Stacks archivia le cinque distribuzioni più recenti, il che consente di ripristinare fino a quattro versioni. Se superi il numero di versioni memorizzate, il comando non riesce e lascia la versione meno recente. Questo comando non è disponibile in stack Chef 12. **Start Web Server (Avvia server Web)** Esegue ricette che avviano il server applicazioni nelle istanze specificate. Questo comando non è disponibile in stack Chef 12. **Stop Web Server (Arresta server Web)** Esegue ricette che arrestano il server applicazioni nelle istanze specificate. Questo comando non è disponibile in stack Chef 12. **Restart Web Server (Riavvia server Web)** Esegue ricette che riavviano il server applicazioni nelle istanze specificate. Questo comando non è disponibile in stack Chef 12. **Importante** **Start Web Server (Avvia server Web)**, **Stop Web Server (Arresta server Web)**, **Restart Web Server (Riavvia server Web)** e **Rollback** sono essenzialmente versioni personalizzate del [comando dello stack Execute Recipes (Esegui ricette)](workingstacks-commands.md). Questi comandi eseguono un set di ricette che svolgono l'attività nelle istanze specificate. Poiché questi comandi non attivano un evento del ciclo di vita, non puoi impostarli per l'esecuzione di codice personalizzato. Questi comandi possono essere utilizzati solo per i [livelli del server applicazioni](workinglayers-servers.md) predefiniti. In particolare, non hanno effetto sui livelli personalizzati, anche se supportano un server applicazioni. Per avviare, arrestare o riavviare server in un livello personalizzato, devi implementare ricette personalizzate per l'esecuzione di queste attività e utilizzare il [comando dello stack Execute Recipes (Esegui ricette)](workingstacks-commands.md) per eseguirle. Per ulteriori informazioni su come implementare e installare ricette personalizzate, consulta [Libri di ricette e ricette](workingcookbook.md). # Modifica delle app **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). Puoi modificare la configurazione di un'app mediante la modifica dell'app. Ad esempio, se sei pronto per distribuire una nuova versione, puoi modificare le impostazioni OpsWorks Stacks dell'app per utilizzare il nuovo ramo del repository. Devi disporre delle autorizzazioni di gestione o distribuzione per poter modificare la configurazione di un'app. Per ulteriori informazioni, consulta [Gestione delle autorizzazioni utente](opsworks-security-users.md). **Per modificare un'app** 1. Nella pagina **Apps (App)**, fare clic sul nome dell'app per aprire la relativa pagina dei dettagli. 1. Fare clic su **Edit (Modifica)** per modificare la configurazione dell'app. + Se modifichi il nome dell'app, OpsWorks Stacks utilizza il nuovo nome per identificare l'app nella console. La modifica del nome non comporta la modifica del nome breve associato. Il nome breve è impostato quando si aggiunge l'app allo stack e non può essere modificato in un secondo temo. + Se si specifica una variabile di ambiente protetta, non è possibile visualizzare o modificare il valore. Tuttavia, è possibile specificare un nuovo valore facendo clic su **Update value (Aggiorna valore)**. 1. Fare clic su **Save (Salva)** per salvare la nuova configurazione e quindi su **Deploy App (Distribuisci app)** per distribuire l'applicazione. La modifica di un'app modifica le impostazioni con OpsWorks Stacks, ma non influisce sulle istanze dello stack. Quando [distribuisci un'app](workingapps-deploying.md) per la prima volta, le ricette di ditribuzione (Distribuzione) scaricano il codice e i file correlati nelle istanze del server di applicazioni, che quindi eseguiranno la copia locale. Se modifichi l'app nel repository o modifichi altre impostazioni, devi distribuire l'app per installare gli aggiornamenti sulle istanze del tuo app server, come segue. OpsWorks Stacks distribuisce automaticamente la versione corrente dell'app su nuove istanze al momento dell'avvio. Per le istanze esistenti, tuttavia, la situazione è diversa: + OpsWorks Stacks distribuisce automaticamente la versione corrente dell'app su nuove istanze al momento dell'avvio. + OpsWorks Stacks distribuisce automaticamente la versione più recente dell'app sulle istanze offline, comprese le istanze [basate sul caricamento e quelle basate sul](workinginstances-autoscaling.md) tempo, al riavvio. + Devi distribuire manualmente l'app aggiornata alle istanze online. Per ulteriori informazioni su come distribuire le app, consulta [Distribuzione di app](workingapps-deploying.md). # Connessione di un'applicazione a un server di database **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). Puoi associare un server di database Amazon RDS a un'app al momento [della creazione dell'app](workingapps-creating.md) o successivamente [modificandola](workingapps-editing.md). L'applicazione può quindi utilizzare le informazioni di connessione al database: nome utente, password,... —per connettersi al server del database. Quando [distribuisci un'app](workingapps-deploying.md), OpsWorks Stacks fornisce queste informazioni alle applicazioni in due modi: + Per Linux stack, OpsWorks Stacks crea un file su ciascuna delle istanze di server di applicazioni integrate che contengono dati di connessione che l'applicazione può utilizzare per connettersi al server di database. + OpsWorks Stacks include le informazioni di connessione negli [attributi di configurazione e distribuzione dello stack](workingcookbook-json.md) installati su ciascuna istanza. È possibile implementare una ricetta personalizzata per estrarre le informazioni di connessione da questi attributi e metterla in un file nel formato desiderato. Per ulteriori informazioni, consulta [Passaggio di dati alle applicazioni](apps-data.md). **Importante** Per gli stack Linux, se desideri associare un livello di servizio Amazon RDS alla tua app, devi aggiungere il pacchetto driver appropriato al livello di app server associato, come segue: Fare clic su **Layers (Livelli)** nel riquadro di navigazione e aprire la scheda **Recipes (Ricette)** del server dell'applicazione. Fare clic su **Edit (Modifica)** e aggiungere il pacchetto driver adeguato a **OS Packages (Pacchetti OS)**. Ad esempio, è necessario specificare `mysql` se il livello contiene le istanze di Amazon Linux e `mysql-client` se il livello contiene istanze Ubuntu. Salvare le modifiche e ridistribuire l'applicazione. ## Utilizzo di una ricetta personalizzata È possibile implementare una ricetta personalizzata che estrae i dati di connessione dagli [`deploy` attributi](workingcookbook-json.md#workingcookbook-json-deploy) dell'applicazione e li salva in un formato che l'applicazione è in grado di leggere, ad esempio come file YAML. Si collega un server di database a un'applicazione quando si [crea l'app](workingapps-creating.md) o in seguito [modifica l'app](workingapps-editing.md). Quando distribuisci l'app, OpsWorks Stacks installa una [configurazione dello stack e degli attributi di distribuzione](workingcookbook-json.md) su ogni istanza che includono le informazioni di connessione al database. L'applicazione può quindi recuperare gli attributi appropriati. I dettagli variano a seconda se si utilizza uno stack Linux o Windows. ### Connessione a un server di database per un Linux Stack Per gli stack Linux, lo spazio dei nomi di [configurazione stack e attributi di distribuzione](workingcookbook-json.md) `deploy` includono un attributo per ogni applicazione distribuita, denominata con il nome breve dell'applicazione. Quando colleghi un server di database a un'app, OpsWorks Stacks popola l'`[:database]`attributo dell'app con le informazioni di connessione e lo installa sulle istanze dello stack per ogni distribuzione successiva. I valori degli attributi vengono forniti dall'utente o generati da OpsWorks Stacks. **Nota** OpsWorks Stacks consente di collegare un server di database a più app, ma ogni app può avere un solo server di database collegato. Se si desidera connettere un'applicazione a più di un server di database, collegare uno dei server all'applicazione e utilizzare le informazioni negli attributi `deploy` dell'app per connettersi al server. Utilizzare JSON personalizzato per inoltrare le informazioni di connessione per gli altri server di database all'applicazione. Per ulteriori informazioni, consulta [Passaggio di dati alle applicazioni](apps-data.md). Un'applicazione può utilizzare le informazioni di connessione dagli attributi `deploy` dell'istanza per connettersi a un database. Tuttavia, le applicazioni non possono accedere direttamente a tali informazioni: solo le ricette possono accedere agli attributi. `deploy` È possibile affrontare questo problema implementando una ricetta personalizzata che estrae le informazioni di connessione dagli attributi `deploy` e le inserisce in un file che può essere letto dall'applicazione. # Utilizzo delle variabili di ambiente **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). **Nota** I suggerimenti riportati in questo argomento si applicano a Chef 11.10 e versioni precedenti di Chef. Per ottenere le variabili di ambiente in Chef 12 e nelle versioni più recenti, devi utilizzare il contenitore di dati dell'app. Per ulteriori informazioni, consulta [AWS OpsWorks Data Bag Reference](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bags.html) e [App Data Bag (aws\$1opsworks\$1app](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bag-json-app.html)). [Quando [specifichi le variabili di ambiente per un'app](workingapps-creating.md#workingapps-creating-environment), OpsWorks Stacks aggiunge le definizioni delle variabili agli attributi dell'app. `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) I livelli personalizzati possono utilizzare una ricetta per recuperare il valore di una variabile utilizzando la sintassi standard di nodo e archiviarlo in un formato accessibile alle app del livello. Devi implementare una ricetta personalizzata in grado di recuperare i valori delle variabili di ambiente dagli attributi `deploy` dell'istanza. La ricetta può quindi archiviare i dati nell'istanza in un formato accessibile dall'applicazione, ad esempio un file YAML. Le definizioni delle variabili di ambiente di un'app vengono archiviate negli attributi `deploy`, all'interno della variabile `environment_variables` dell'app. L'esempio seguente mostra il percorso di questi attributi per un'app denominata `simplephpapp`, utilizzando dati JSON per rappresentare la struttura degli attributi. ``` { ... "ssh_users": { }, "deploy": { "simplephpapp": { "application": "simplephpapp", "application_type": "php", "environment_variables": { "USER_ID": "168424", "USER_KEY": "somepassword" }, ... } } ``` Una ricetta può recuperare i valori delle variabili utilizzando una sintassi standard di nodo. L'esempio seguente mostra come recuperare il valore `USER_ID` dal precedente dato JSON e inserirlo nel log di Chef. ``` Chef::Log.info("USER_ID: #{node[:deploy]['simplephpapp'][:environment_variables][:USER_ID]}") ``` Per una descrizione più dettagliata di come recuperare informazioni dai dati JSON di configurazione e distribuzione dello stack e archiviarle nell'istanza, consulta [Passaggio di dati alle applicazioni](apps-data.md). # Passaggio di dati alle applicazioni **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). Spesso risulta utile passare dati quali, ad esempio, coppie chiave-valore a un'applicazione nel server. A tale scopo, devi utilizzare [dati JSON personalizzati](workingstacks-json.md) per aggiungere i dati allo stack. OpsWorks Stacks aggiunge i dati all'oggetto nodo di ogni istanza per ogni evento del ciclo di vita. Si noti, tuttavia, che anche se le ricette possono recuperare i dati JSON personalizzati dall'oggetto nodo tramite gli attributi di Chef, le applicazioni non sono in grado di eseguire questa operazione. Un approccio che consenta di passare i dati JSON personalizzati a una o più applicazioni è implementare una ricetta personalizzata in grado di estrarre i dati dall'oggetto `node` e quindi di scriverli in un file che l'applicazione è in grado di leggere. L'esempio utilizzato in questo argomento illustra come scrivere i dati a un file YAML. Puoi tuttavia utilizzare lo stesso approccio di base per altri formati, ad esempio JSON o XML. Per passare i dati chiave-valore alle istanze dello stack, allo stack devi aggiungere dati JSON personalizzati, come quelli riportati di seguito. Per ulteriori informazioni su come aggiungere dati JSON personalizzati allo stack, consulta [Utilizzo di un JSON personalizzato](workingstacks-json.md). ``` { "my_app_data": { "app1": { "key1": "value1", "key2": "value2", "key3": "value3" }, "app2": { "key1": "value1", "key2": "value2", "key3": "value3" } } } ``` L'esempio presuppone la presenza di due app i cui nomi brevi sono `app1` e `app2`, ciascuna delle quali include tre valori di dati. La ricetta corrispondente presuppone l'utilizzo dei nomi brevi delle app per identificare i dati associati; gli altri nomi sono arbitrari. Per ulteriori informazioni sui nomi brevi delle app, consulta [Settings](workingapps-creating.md#workingapps-creating-settings). La ricetta nell'esempio seguente mostra come estrarre i dati per ogni app dagli attributi `deploy` e come inserirli in un file `.yml`. La ricetta presuppone che i dati JSON personalizzati contengano dati per ogni applicazione. ``` node[:deploy].each do |app, deploy| file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do content YAML.dump(node[:my_app_data][app].to_hash) end end ``` Gli attributi `deploy` includono un attributo per ogni app, denominato utilizzando il nome breve dell'app. Ogni attributo dell'app contiene un set di attributi che rappresentano una serie di informazioni relative all'app. In questo esempio viene utilizzata la directory di distribuzione dell'app, che è rappresentata dall'attributo `[:deploy][:app_short_name][:deploy_to]`. Per ulteriori informazioni su `[:deploy]`, consulta [Attributi deploy](attributes-json-deploy.md). Per ogni app in `deploy`, la ricetta esegue le seguenti operazioni: 1. Crea un file denominato `app_data.yml` nella sottodirectory `shared/config` della directory `[:deploy_to]`dell'applicazione. Per ulteriori informazioni su come OpsWorks Stacks installa le app, consulta. [Ricette di ditribuzione](create-custom-deploy.md) 1. Converte i valori JSON personalizzati dell'app nel formato YAML e scrive i dati formattati in `app_data.yml`. **Per passare i dati a un'app** 1. Aggiungere un'app allo stack e annotare il relativo nome breve. Per ulteriori informazioni, consulta [Aggiunta di app](workingapps-creating.md). 1. Aggiungere dati JSON personalizzati contenenti i dati dell'app agli attributi `deploy`, come descritto in precedenza. Per ulteriori informazioni su come aggiungere dati JSON personalizzati allo stack, consulta [Utilizzo di un JSON personalizzato](workingstacks-json.md). 1. Creare un libro di ricette e aggiungervi una ricetta contenente il codice riportato nell'esempio precedente, modificato in base alle esigenze relativamente ai nomi di attributo utilizzati nei dati JSON personalizzati. Per ulteriori informazioni su come creare libri di ricette e ricette, consulta [Libri di ricette e ricette](workingcookbook.md). Se per questo stack sono già disponibili libri di ricette personalizzati, è possibile anche aggiungere la ricetta a un libro di ricette esistente oppure aggiungere il codice a una ricetta Deploy (Distribuzione) esistente. 1. Installare il libro di ricette sullo stack. Per ulteriori informazioni, consulta [Installazione di libri di ricette personalizzati](workingcookbook-installingcustom-enable.md). 1. Assegna la ricetta all'evento Deploy lifecycle del livello del server dell'app. OpsWorks Stacks eseguirà quindi la ricetta su ogni nuova istanza, dopo l'avvio. Per ulteriori informazioni, consulta [Esecuzione di ricette](workingcookbook-executing.md). 1. Distribuire l'app. Questa operazione installa anche gli attributi di configurazione e distribuzione dello stack, che ora contengono i dati. **Nota** Se i file di dati devono essere disponibili prima della distribuzione dell'app, è anche possibile assegnare la ricetta all'evento Setup (Configurazione) del ciclo di vita del livello. Questo evento si verifica una volta, al completamento dell'avvio dell'istanza. Tuttavia, OpsWorks Stacks non avrà ancora creato le directory di distribuzione, quindi la ricetta dovrebbe creare le directory richieste in modo esplicito prima di creare il file di dati. L'esempio seguente crea in modo esplicito la directory `/shared/config` dell'app, quindi crea un file di dati in tale directory. ``` node[:deploy].each do |app, deploy| directory "#{deploy[:deploy_to]}/shared/config" do owner "deploy" group "www-data" mode 0774 recursive true action :create end file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do content YAML.dump(node[:my_app_data][app].to_hash) end end ``` Per caricare i dati, puoi utilizzare il seguente codice [Sinatra](http://www.sinatrarb.com/): ``` #!/usr/bin/env ruby # encoding: UTF-8 require 'sinatra' require 'yaml' get '/' do YAML.load(File.read(File.join('..', '..', 'shared', 'config', 'app_data.yml'))) End ``` Puoi aggiornare i valori dei dati dell'app in qualsiasi momento mediante l'aggiornamento dei dati JSON personalizzati, come descritto di seguito. **Per aggiornare i dati dell'applicazione** 1. Modificare i dati JSON personalizzati per aggiornare i valori dei dati. 1. Distribuisci nuovamente l'app, che indica a OpsWorks Stacks di eseguire le ricette Deploy sulle istanze dello stack. Le ricette utilizzerà gli attributi derivati dagli attributi di configurazione e distribuzione aggiornati dello stack. Pertanto la ricetta personalizzata aggiornerà i file di dati con i valori correnti. # Utilizzo di chiavi SSH di repository Git **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). La chiave SSH di un repository Git, chiamata talvolta chiave SSH di distribuzione, è una chiave SSH senza password che consente di accedere a un repository Git privato. Idealmente, non appartiene ad alcuno sviluppatore specifico. Il suo scopo è consentire a OpsWorks Stacks di distribuire in modo asincrono app o libri di cucina da un repository Git senza richiedere ulteriori input da parte dell'utente. Di seguito viene descritta la procedura di base per la creazione della chiave SSH di un repository. Per ulteriori informazioni, consulta la documentazione relativa al repository. Ad esempio, [Managing deploy keys](https://help.github.com/articles/managing-deploy-keys) descrive come creare una chiave SSH di repository per un repository, mentre [Deployment Keys on Bitbucket descrive come creare una chiave SSH di GitHub repository per un repository Bitbucket](http://blog.bitbucket.org/2012/06/20/deployment-keys/). Un documento descrive la creazione di una chiave su un server. Per OpsWorks Stacks, basta sostituire «server» con «workstation» nelle istruzioni. **Per creare una chiave SSH di repository** 1. Creare una coppia di chiavi SSH di distribuzione per il repository Git sulla workstation utilizzando un programma, ad esempio `ssh-keygen`. **Importante** OpsWorks Stacks non supporta le passphrase delle chiavi SSH. 1. Assegnare la chiave pubblica al repository e archiviare la chiave privata sulla workstation. 1. Immettere la chiave privata nella casella **Repository SSH Key (Chiave SSH repository)** quando si aggiunge un'app o si specifica il repository di un libro di ricette. Per ulteriori informazioni, consulta [Aggiunta di app](workingapps-creating.md). OpsWorks Stacks passa la chiave SSH del repository a ciascuna istanza e le ricette integrate utilizzano quindi la chiave per connettersi al repository e scaricare il codice. La chiave viene memorizzata negli attributi [`deploy`](workingcookbook-json.md) come [`node[:deploy]['appshortname'][:scm][:ssh_key]`](attributes-json-deploy.md#attributes-json-deploy-app-scm-key) ed è accessibile solo all'utente root. # Utilizzo di domini personalizzati **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). Se ospiti il nome di un dominio di una parte terza, puoi mappare quel nome di dominio per un'app. La seguente è la procedura di base: 1. Crea un sottodominio con il registar DNS e mappalo sull'indirizzo IP elastico del tuo sistema di bilanciamento del carico, oppure sull'indirizzo IP pubblico del server dell'app. 1. Aggiorna la configurazione dell'app per scegliere il sottodominio e ridistribuire l'app. **Nota** Assicurati di inoltrare il tuo nome di dominio non qualificato (ad esempio myapp1.example.com) a un nome di dominio qualificato (ad esempio www.myapp1.example.com), affinché entrambi mappino la tua app. Quando configuri un dominio per un'app, viene elencato come un alias del server nel file di configurazione del server. Se stai utilizzando un sistema di bilanciamento del carico, questo controlla il nome di dominio nell'URL quando arrivano richieste e reindirizza il traffico in base al dominio. **Per mappare un sottodominio a un indirizzo IP** 1. Se stai utilizzando un sistema di bilanciamento del carico, nella pagina **Instances (Istanze)**, fai clic sull'istanza del sistema di bilanciamento del carico per aprire la pagina dei suoi dettagli e per ottenere l'indirizzo **Elastic IP (IP elastico)** dell'istanza. In caso contrario, ottieni l'indirizzo IP pubblico dalla pagina dei dettagli dell'istanza del server dell'applicazione. 1. Segui le istruzioni fornite dal registrar DNS per creare e mappare il tuo sottodominio per l'indirizzo IP dalla Fase 1. **Nota** Se l'istanza del sistema di bilanciamento del carico a un certo punto viene terminata, ti verrà assegnato un nuovo indirizzo IP elastico. È necessario aggiornare le impostazioni del tuo registar DNS per mappare il nuovo indirizzo IP elastico. OpsWorks [Stacks aggiunge semplicemente le impostazioni del dominio agli attributi dell'app. `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) È necessario implementare una ricetta personalizzata per recuperare le informazioni dall'oggetto nodo e configurare il server in modo appropriato. Per ulteriori informazioni, consulta [Libri di ricette e ricette](workingcookbook.md). # Esecuzione di più applicazioni sullo stesso server dell'applicazione **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disattivato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). **Nota** Le informazioni incluse in questo argomento non sono valide per le app Node.js. Se disponi di più applicazioni dello stesso tipo, talvolta è più conveniente eseguirle sulle stesse istanze del server dell'applicazione. **Per eseguire più applicazioni sullo stesso server** 1. Aggiungi un'app allo stack di ogni applicazione. 1. Ottieni un sottodominio separato per ogni app e mappa i sottodomini per i server dell'applicazione o l'indirizzo IP di un sistema di bilanciamento del carico. 1. Modifica la configurazione di ogni app per specificare il sottodominio appropriato. Per ulteriori informazioni su come eseguire queste attività, consulta [Utilizzo di domini personalizzati](workingapps-domains.md). **Nota** Se i server delle applicazioni eseguono più applicazioni HTTP, puoi utilizzare Elastic Load Balancing per il bilanciamento del carico. Per più applicazioni HTTPS, devi terminare la connessione SSL al sistema di bilanciamento del carico o creare uno stack separato per ogni applicazione. Le richieste HTTPS sono crittografate, il che significa che se interrompi la connessione SSL al server, il sistema di bilanciamento del carico non è in grado di verificare il nome di dominio per determinare quale applicazione deve gestire la richiesta. # Uso di SSL **Importante** Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support). Per utilizzare SSL con l'applicazione, è necessario prima ottenere un certificato server digitale da una Certificate Authority (CA). Per semplicità, questa procedura guidata crea un certificato poi lo autofirma. I certificati autofirmati sono utili per scopi di formazione ed esecuzione di test, ma è necessario utilizzare sempre un certificato firmato da una CA per gli stack di produzione. In questa procedura guidata, si eseguiranno le operazioni seguenti: 1. Installare e configurare OpenSSL 1. Crea una chiave privata. 1. Creare una richiesta di firma del certificato. 1. Generare un certificato autofirmato. 1. Modificare l'applicazione con le informazioni del certificato. **Importante** [Se la tua applicazione utilizza SSL, ti consigliamo di disabilitarlo SSLv3, se possibile, nei livelli del server delle applicazioni per risolvere le vulnerabilità descritte in CVE-2014-3566.](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-3566) Se lo stack include un livello Ganglia, è necessario disabilitare SSL v3 anche per quel livello. I dettagli dipendono dal livello specifico; per ulteriori informazioni, consulta quanto segue. [Java App Server OpsWorks Stacks Layer](layers-java.md) [Node.js App Server OpsWorks Stacks Layer](workinglayers-node.md) [PHP App Server OpsWorks Stacks Layer](workinglayers-php.md) [Rails OpsWorks App Server Stacks Layer](workinglayers-rails.md) [Static Web Server OpsWorks Stacks Layer](workinglayers-static.md) [Ganglia Layer](workinglayers-ganglia.md) **Topics** + [Passaggio 1: installare e configurare OpenSSL](#w2ab1c14c57c29c15) + [Passaggio 2: creare una chiave privata](#w2ab1c14c57c29c17) + [Passaggio 3: creare una richiesta di firma del certificato](#w2ab1c14c57c29c19) + [Passaggio 4: inviare il CSR alla Certificate Authority](#w2ab1c14c57c29c21) + [Passaggio 5: modificare la app](#w2ab1c14c57c29c23) ## Passaggio 1: installare e configurare OpenSSL La creazione e il caricamento dei certificati server richiede uno strumento che supporta i protocolli SSL e TLS. OpenSSL è uno strumento open-source che fornisce le funzioni di crittografia di base necessarie per creare un token RSA e firmarlo con la chiave privata. La procedura seguente presuppone che il computer non disponga già di OpenSSL installato. **Per installare OpenSSL su Linux e Unix** 1. Andare su [OpenSSL: Source, Tarballs (OpenSSL: origine, tarball)](https://www.openssl.org/source/). 1. Scaricare l'origine più recente. 1. Creare il pacchetto. **Per installare OpenSSL in ambiente Windows** 1. [Se il Microsoft Visual C\$1\$1 2008 Redistributable Package non è già installato sul sistema, scarica il pacchetto.](https://www.microsoft.com/en-us/download/details.aspx?id=11895) 1. Eseguire il programma di installazione e seguire le istruzioni fornite da Microsoft Visual C\$1\$1 2008 Redistributable Setup Wizard per installare il ridistribuibile. 1. Andare su [OpenSSL: Binary Distributions (OpenSSL: distribuzione binaria)](https://www.openssl.org/community/binaries.html), fare clic sulla versione appropriata dei file binari OpenSSL per l'ambiente e salvare il programma di installazione in locale. 1. Eseguire il programma di installazione e seguire le istruzioni in **OpenSSL Setup Wizard (Procedura guidata di installazione OpenSSL)** per installare il file binari. Creare una variabile di ambiente che punti al punto di installazione OpenSSL attraverso l'apertura di un terminale o di una finestra di comando e l'utilizzo delle seguenti righe di comando. + Su Linux e Unix ``` export OpenSSL_HOME=path_to_your_OpenSSL_installation ``` + Su Windows ``` set OpenSSL_HOME=path_to_your_OpenSSL_installation ``` Aggiungere la variabile di percorso dei file binari OpenSSL sul computer tramite l'apertura di un terminale o di una finestra di comando e l'utilizzo delle seguenti righe di comando. + Su Linux e Unix ``` export PATH=$PATH:$OpenSSL_HOME/bin ``` + Su Windows ``` set Path=OpenSSL_HOME\bin;%Path% ``` **Nota** Eventuali modifiche apportate alle variabili di ambiente tramite l'utilizzo di queste righe di comando sono valide solo per la sessione della riga di comando attuale. ## Passaggio 2: creare una chiave privata È necessaria una chiave privata univoca per creare la richiesta di firma del certificato (CSR). Crea la chiave utilizzando la seguente riga di comando: ``` openssl genrsa 2048 > privatekey.pem ``` ## Passaggio 3: creare una richiesta di firma del certificato Una richiesta di firma del certificato (CSR) è un file inviato a una Certificate Authority (CA) per richiedere un certificato server digitale. Creare la CSR utilizzando la seguente riga di comando. ``` openssl req -new -key privatekey.pem -out csr.pem ``` L'output del comando risulterà simile al seguente: ``` You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ``` La tabella seguente aiuta a creare la richiesta di certificato. **Dati di richiesta di certificato** | Nome | Descrizione | Esempio | | --- | --- | --- | | Nome paese | L'abbreviazione ISO di due lettere per il tuo paese. | US = Stati Uniti | | Lo stato o la provincia | Il nome dello stato o della provincia in cui si trova la tua organizzazione. Questo nome non può essere abbreviato. | Washington | | Locality Name (Nome località) | Il nome della città in cui si trova la tua organizzazione. | Seattle | | Nome organizzazione | La denominazione legale completa della tua organizzazione. Non abbreviare il nome dell'organizzazione. | CorporationX | | Unità organizzativa | (Opzionale) Per informazioni aggiuntive sull'organizzazione. | Marketing | | Common Name (Nome comune) | Il nome di dominio pienamente qualificato per il CNAME. Si riceverà un avviso di controllo del nome di certificato se non è una corrispondenza esatta. | www.example.com | | Indirizzo e-mail | L'indirizzo e-mail dell'amministratore del server | someone@example.com | **Nota** Il campo Nome comune è spesso frainteso e viene completato in modo non corretto. Il nome comune è in genere l'host più il nome di dominio. Comparirà come "www.example.com" o "example.com". È necessario creare una CSR utilizzando il proprio nome comune corretto. ## Passaggio 4: inviare il CSR alla Certificate Authority Per l'utilizzo di produzione, è possibile ottenere un certificato server inviando il CSR a una Certificate Authority (CA) che potrebbe richiedere altre credenziali o prove di identità. Se la richiesta va a buon fine, la CA restituisce il certificato di identità con la firma digitale e possibilmente un file della catena del certificato. AWS non consiglia una CA specifica. Per un elenco parziale dei prodotti disponibili CAs, consulta [Certificate Authority - Providers](https://en.wikipedia.org/wiki/Certificate_authority#Providers) su Wikipedia. È inoltre possibile generare un certificato autofirmato che può essere utilizzato solo a scopo di test. Per questo esempio, utilizzare la seguente riga di comando per generare un certificato autofirmato. ``` openssl x509 -req -days 365 -in csr.pem -signkey privatekey.pem -out server.crt ``` L'output risulterà simile al seguente: ``` Loading 'screen' into random state - done Signature ok subject=/C=us/ST=washington/L=seattle/O=corporationx/OU=marketing/CN=example.com/emailAddress=someone@example.com Getting Private key ``` ## Passaggio 5: modificare la app Dopo aver generato il certificato e averlo firmato, aggiornare la app per attivare SSL e fornire le informazioni di certificato. Nella pagina **App** scegliere un’app per aprire la pagina dei dettagli e fare clic su **Edit App (Modifica app)**. Per attivare il supporto SSL, impostare **Enable SSL (Abilita SSL)** su **Sì** per visualizzare le seguenti opzioni di configurazione. **Certificato SSL** Copiare i contenuti del file di certificato della chiave pubblica (.crt) nella casella. Il certificato deve avere un aspetto simile al seguente: ``` -----BEGIN CERTIFICATE----- MIICuTCCAiICCQCtqFKItVQJpzANBgkqhkiG9w0BAQUFADCBoDELMAkGA1UEBhMC dXMxEzARBgNVBAgMCndhc2hpbmd0b24xEDAOBgNVBAcMB3NlYXR0bGUxDzANBgNV BAoMBmFtYXpvbjEWMBQGA1UECwwNRGV2IGFuZCBUb29sczEdMBsGA1UEAwwUc3Rl cGhhbmllYXBpZXJjZS5jb20xIjAgBgkqhkiG9w0BCQEWE3NhcGllcmNlQGFtYXpv ... -----END CERTIFICATE----- ``` Se si sta utilizzando Nginx e si dispone di un file della catena del certificato, è necessario aggiungere i contenuti al file di certificato della chiave pubblica. Se si sta aggiornando un certificato esistente, eseguire le operazioni seguenti: + Scegliere **Update SSL certificate (Aggiorna certificato SSL)** per aggiornare il certificato. + Se il nuovo certificato non corrisponde alla chiave privata esistente, scegliere **Update SSL certificate key (Aggiorna chiave certificato SSL)**. + Se il nuovo certificato non corrisponde alla catena di certificati esistente, scegliere **Update SSL certificates (Aggiorna certificato SSL)**. **SSL Certificate Key (Chiave del certificato SSL)** Copiare i contenuti del file della chiave privata (file .pem) nella casella. Deve avere un aspetto simile al seguente: ``` ----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQC0CYklJY5r4vV2NHQYEpwtsLuMMBhylMrgBShKq+HHVLYQQCL6 +wGIiRq5qXqZlRXje3GM5Jvcm6q0R71MfRIl1FuzKyqDtneZaAIEYniZibHiUnmO /UNqpFDosw/6hY3ONk0fSBlU4ivD0Gjpf6J80jL3DJ4R23Ed0sdL4pRT3QIDAQAB AoGBAKmMfWrNRqYVtGKgnWB6Tji9QrKQLMXjmHeGg95mppdJELiXHhpMvrHtpIyK ... -----END RSA PRIVATE KEY----- ``` **SSL certificates of Certification Authorities (Certificati SSL delle Certification Authority)** Se si dispone di un file della catena del certificato, incollare il contenuto nella casella. Se si sta usando Nginx, è necessario lasciare la casella vuota. Se si dispone di un file della catena del certificato, aggiungerla al file del certificato della chiave pubblica in **SSL Certificate (Certificato SSL)**. ![\[SSL Settings interface with options for SSL Supporto, Certificate, Key, and Certification Authorities.\]](http://docs.aws.amazon.com/it_it/opsworks/latest/userguide/images/app_ssl_settings.png) Dopo aver fatto clic su **Save (Salva)**, [ridistribuire l'applicazione](workingapps-deploying.md) per aggiornare le proprie istanze online. Per i [livelli di application server integrati](workingcookbook-json.md#workingcookbook-json-deploy), OpsWorks Stacks aggiorna automaticamente la configurazione del server. Al termine della distribuzione, è possibile verificare che l'installazione OpenSSL è andata a buon fine, come segue. **Per verificare un'installazione OpenSSL** 1. Andare alla pagina **Instances (Istanze)**. 1. Eseguire l'app facendo clic sull'indirizzo IP delle istanze del server di applicazione o, se si sta utilizzando un sistema di bilanciamento del carico, l'indirizzo IP del sistema di bilanciamento del carico. 1. Modificare il prefisso dell'indirizzo IP da **http://** a **https://** e aggiornare il browser per verificare che la pagina venga caricata correttamente con SSL. Gli utenti che hanno configurato le app per l'esecuzione in Mozilla Firefox talvolta ottengono il seguente errore di certificato: `SEC_ERROR_UNKNOWN_ISSUER`. Questo errore può essere causato dalla funzionalità di sostituzione dei certificati nei programmi antivirus e antimalware dell'organizzazione, da alcuni tipi di software di monitoraggio e filtro del traffico di rete o da malware. Per ulteriori informazioni su come risolvere questo errore, consulta [Come interpretare i codici di errore e risolvere i problemi di sicurezza per i siti web sicuri](https://support.mozilla.org/en-US/kb/error-codes-secure-websites?redirectlocale=en-US&redirectslug=troubleshoot-SEC_ERROR_UNKNOWN_ISSUER#w_monitoringfiltering-in-corporate-networks) sul sito Web di supporto di Mozilla Firefox. Per tutti gli altri livelli, inclusi i livelli personalizzati, OpsWorks Stacks aggiunge semplicemente le impostazioni SSL agli attributi [`deploy` dell'app](workingcookbook-json.md#workingcookbook-json-deploy). È necessario implementare una ricetta personalizzata per recuperare le informazioni dall'oggetto nodo e configurare il server in modo appropriato.