{"id":40596,"date":"2020-02-02T10:38:43","date_gmt":"2020-02-02T07:38:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/razrabotka-prilozhenij-i-blue-green-deployment-opirayas-na-metodologiyu-the-twelve-factor-app-s-primerami-na-php-i-docker"},"modified":"2020-02-02T10:38:43","modified_gmt":"2020-02-02T07:38:43","slug":"razrabotka-prilozhenij-i-blue-green-deployment-opirayas-na-metodologiyu-the-twelve-factor-app-s-primerami-na-php-i-docker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/razrabotka-prilozhenij-i-blue-green-deployment-opirayas-na-metodologiyu-the-twelve-factor-app-s-primerami-na-php-i-docker","title":{"rendered":"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/c8f98efef30babe012d23dd82a01c13b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Per cominciare, un po' di teoria. Cos'\u00e8 <noindex><a rel=\"nofollow\" href=\"https:\/\/12factor.net\/ru\/\">The Twelve-Factor App<\/a><\/noindex>?<\/h3>\n<p>\nIn parole semplici, \u00e8 un documento progettato per semplificare lo sviluppo di applicazioni SaaS, che aiuta informando sviluppatori e ingegneri DevOps sui problemi e le pratiche pi\u00f9 comunemente riscontrati nello sviluppo di applicazioni moderne. <\/p>\n<p>Questo documento \u00e8 stato creato dagli sviluppatori della piattaforma Heroku.<\/p>\n<p>La metodologia dei dodici fattori (The Twelve-Factor App) pu\u00f2 essere applicata a applicazioni scritte in qualsiasi linguaggio di programmazione e che utilizzano qualsiasi combinazione di servizi esterni (backing services) (database, code di messaggi, cache, ecc.).<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Un breve riepilogo dei fattori su cui si basa questa metodologia:<\/h3>\n<p><\/p>\n<ol>\n<li><b>Base di codice<\/b> \u2013 Una base di codice, tracciata in un sistema di controllo versione, \u2013 molteplici distribuzioni <\/li>\n<li><b>Dipendenze<\/b> \u2013 Dichiarare esplicitamente e isolare le dipendenze<\/li>\n<li><b>Configurazione<\/b> \u2013 Conservare la configurazione nell'ambiente di esecuzione<\/li>\n<li><b>Servizi esterni (Backing Services)<\/b> \u2013 Considerare i servizi esterni (backing services) come risorse collegate<\/li>\n<li><b>Costruzione, rilascio, esecuzione<\/b> \u2013 Separare rigidamente le fasi di costruzione e esecuzione<\/li>\n<li><b>Processi<\/b> \u2013 Eseguire l'applicazione come uno o pi\u00f9 processi senza stato (stateless) <\/li>\n<li><b>Binding delle porte (Port binding)<\/b> \u2013 Esportare i servizi tramite binding delle porte <\/li>\n<li><b>Parallelismo<\/b> \u2013 Scalare l'applicazione utilizzando processi <\/li>\n<li><b>Eliminabilit\u00e0 (Disposability)<\/b> \u2013 Massimizzare l'affidabilit\u00e0 tramite avvio rapido e chiusura corretta <\/li>\n<li><b>Parit\u00e0 tra sviluppo e produzione dell'applicazione<\/b> \u2013 Mantenere gli ambienti di sviluppo, staging e produzione il pi\u00f9 simili possibile <\/li>\n<li><b>Log (Logs)<\/b> \u2013 Considerare il log come un flusso di eventi<\/li>\n<li><b>Attivit\u00e0 di amministrazione<\/b> \u2013 Eseguire attivit\u00e0 di amministrazione\/gestione tramite processi one-off <\/li>\n<\/ol>\n<p>\n<b>Ulteriori informazioni sui 12 fattori possono essere ottenute dalle seguenti risorse:<\/b><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/12factor.net\/ru\/\">Fonte ufficiale<\/a><\/noindex> \u2013 da leggere assolutamente<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/258739\/\">Articolo su habr. L'applicazione dei dodici fattori \u2013 The Twelve-Factor App<\/a><\/noindex> \u2013 traduzione ufficiale<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460363\/\">Articolo su habr. 7 fattori mancanti nell'approccio del 12 Factor App<\/a><\/noindex> \u2013 uno sguardo fresco sui 12 fattori con l'obiettivo di migliorarli.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Cos'\u00e8 il Blue-Green deployment?<\/h3>\n<p>\nIl Blue-Green deployment \u00e8 un modo per consegnare un'applicazione su <b>production<\/b> in modo che il cliente finale non veda alcuna modifica da parte sua. In altre parole, il deploy dell'applicazione avviene senza <b>downtime<\/b>.<\/p>\n<p>Schema classico di BG Deploy \u00e8 come illustrato nell'immagine sottostante. <\/p>\n<p><img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/8252356ac93ce40b248ab27982754985.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<ul>\n<li>All'inizio ci sono 2 server fisici con codice, applicazione e progetto esattamente identici, e c'\u00e8 un router (bilanciatore). <\/li>\n<li>Il router inizialmente indirizza tutte le richieste a uno dei server (<b>verde<\/b>). <\/li>\n<li>Nel momento in cui \u00e8 necessario effettuare nuovamente un rilascio, l'intero progetto viene aggiornato sull'altro server (<b>blu<\/b>), che attualmente non gestisce alcuna richiesta. <\/li>\n<li>Dopo che il codice su <b>blu<\/b> server \u00e8 completamente aggiornato, al router viene dato il comando di switchare da <b>verde<\/b> in <b>blu<\/b> il server. <\/li>\n<li>Ora tutti i clienti vedono il risultato del codice su <b>blu<\/b> Effettuano attacchi mobili. <\/li>\n<li> Per un certo periodo, <b>verde<\/b> il server funge da backup nel caso di un failed deploy su <b>blu<\/b> server e in caso di problemi, il router reindirizza il flusso degli utenti di nuovo su <b>verde<\/b> server con la versione stabile precedente, e il nuovo codice viene inviato per revisione e test.<\/li>\n<li>E alla fine del processo, anche <b>verde<\/b> il server viene aggiornato. E dopo il suo aggiornamento, il router reindirizza di nuovo il flusso delle richieste su <b>verde<\/b> il server.<\/li>\n<\/ul>\n<p>\nTutto ci\u00f2 sembra molto bene e a prima vista non dovrebbe presentare problemi.<br \/>\nMa poich\u00e9 viviamo in un mondo moderno, l'opzione di commutazione fisica come indicato nello schema classico non ci si addice. Tieni queste informazioni a mente, torneremo su di esse pi\u00f9 tardi.<\/p>\n<h3>Consigli utili e dannosi<\/h3>\n<p>\n<i>Avviso<\/i>: Negli esempi sottostanti sono indicate le utility \/ metodologie che utilizzo io, puoi usare qualsiasi alternativa con funzioni simili. <\/p>\n<p>La maggior parte degli esempi avr\u00e0 in qualche modo a che fare con lo sviluppo web (una grande sorpresa), con PHP e Docker.<\/p>\n<p>Nei punti seguenti c\u2019\u00e8 una semplice descrizione pratica dell'uso dei fattori su esempi specifici. Se desideri ulteriori teorie su questo argomento, fai riferimento ai link sopra alla fonte originale. <\/p>\n<h4>1. Base di codice<\/h4>\n<p>\nUtilizza FTP e FileZilla per caricare i file sui server uno alla volta, non conservare il codice se non sul server di produzione.<\/p>\n<p>Il progetto deve sempre avere un'unica base di codice, cio\u00e8 tutto il codice proviene da uno <b>Git<\/b> repository. I server (production, staging, test1, test2 ...) utilizzano il codice da rami di un unico repository comune. In questo modo otteniamo la coerenza del codice.<\/p>\n<h4>2. Dipendenze<\/h4>\n<p>\nScarica tutte le librerie in cartelle direttamente nella root del progetto. Gli aggiornamenti si effettuano semplicemente trasferendo il nuovo codice nella cartella con la versione attuale della libreria. Installa tutti gli strumenti necessari direttamente sul server host dove funzionano anche altre 20 servizi.<\/p>\n<p>Il progetto deve sempre avere un elenco di dipendenze chiaramente definito (con dipendenze intendo anche l'ambiente). Tutte le dipendenze devono essere esplicitamente definite e isolate. <br \/>\nPrendiamo come esempio <b>Composer<\/b> e <b>Docker<\/b>.<\/p>\n<p><b>Composer<\/b> \u2014 un gestore di pacchetti che consente di installare librerie PHP. Composer permette di specificare versioni in modo rigoroso o non rigoroso e di definirle esplicitamente. Sul server possono esserci 20 progetti diversi e ciascuno avr\u00e0 la propria lista personale di pacchetti e librerie indipendente dagli altri.<\/p>\n<p><b>Docker<\/b> \u2014 uno strumento che consente di definire e isolare l'ambiente in cui l'applicazione funzioner\u00e0. Pertanto, cos\u00ec come con composer, ma in modo pi\u00f9 sostanziale, possiamo definire con cosa l'applicazione lavora. Scegliere una versione specifica di PHP, installare solo i pacchetti necessari per il funzionamento del progetto, senza aggiungere nulla di superfluo. E soprattutto, senza sovrapporsi ai pacchetti e all'ambiente della macchina host e degli altri progetti. Quindi tutti i progetti sul server che funzionano tramite Docker possono utilizzare qualsiasi set di pacchetti e qualsiasi ambiente completamente diverso.<\/p>\n<h4>3. Configurazione<\/h4>\n<p>\nConserva le configurazioni come costanti direttamente nel codice. Costanti separate per il server di test, costanti separate per la produzione. Fai dipendere il funzionamento dell'applicazione dall'ambiente direttamente nella logica aziendale del progetto utilizzando costrutti if else.<\/p>\n<p><b>Configurazioni<\/b> \u2014 \u00e8 l'unica cosa che dovrebbe differenziare i deployment del progetto. In ideale, le configurazioni dovrebbero essere passate attraverso variabili di ambiente (env vars). <\/p>\n<p>Cio\u00e8, anche se si memorizzano pi\u00f9 file di configurazione .config.prod .config.local e si rinominano al momento del deploy in .config (il config principale da cui l'applicazione legge i dati) \u2014 questo non \u00e8 un approccio corretto, poich\u00e9 in tal caso le informazioni delle configurazioni sarebbero accessibili a tutti gli sviluppatori dell'applicazione e i dati dal server di produzione sarebbero compromessi. Tutte le configurazioni devono essere memorizzate direttamente nel sistema di deploy (CI\/CD) e generate per diversi ambienti con valori diversi necessari per ciascun ambiente proprio al momento del deploy.<\/p>\n<h4>4. Servizi di terze parti (Backing Services)<\/h4>\n<p>\nLegate rigidamente all'ambiente, utilizzate connessioni diverse per gli stessi servizi in determinati ambienti.<\/p>\n<p>In realt\u00e0, questo punto si sovrappone fortemente a quello delle configurazioni, poich\u00e9 senza questo punto non \u00e8 possibile ottenere dati di configurazione normali e, in generale, la possibilit\u00e0 di configurazione svanirebbe.<\/p>\n<p>Tutte le connessioni ai servizi esterni, come server di coda, database e servizi di caching, devono essere uniche sia per l'ambiente locale che per l'ambiente esterno \/ di produzione. In altre parole, posso in qualsiasi momento cambiare la stringa di connessione e sostituire le chiamate al database #1 con il database #2 senza modificare il codice dell'applicazione. O, per anticipare come esempio, \u00e8 come se quando si scala il servizio, non \u00e8 necessario specificare la connessione in un modo particolare per un ulteriore server di cache.<\/p>\n<h4>5. Build, rilascio, esecuzione<\/h4>\n<p>\nMantieni sul server solo la versione finale del codice, senza possibilit\u00e0 di fare rollback sul rilascio. Non riempi spazio su disco. Chi pensa di poter lanciare codice in produzione con errori \u00e8 un cattivo programmatore!<\/p>\n<p>Tutte le fasi del deploy devono essere separate tra loro.<\/p>\n<p>Assicurati di avere la possibilit\u00e0 di fare rollback. Fai rilasci mantenendo accessibili copie vecchie dell'applicazione (gi\u00e0 buildate e pronte per l'uso), in modo che nel caso di errori tu possa ripristinare una versione precedente. In altre parole, c'\u00e8 una cartella <i>releases<\/i> e una cartella <i>current<\/i>, e dopo un deploy e una build riusciti, la cartella <i>current<\/i> si collega tramite un link simbolico al nuovo rilascio che si trova all'interno <i>releases<\/i> con un nome per il numero del rilascio. <\/p>\n<p>Qui ricordiamo il Blue-Green deployment, che non solo consente di effettuare il passaggio tra il codice, ma anche di scambiare tutte le risorse e persino gli ambienti, con la possibilit\u00e0 di ripristinare tutto.<\/p>\n<h4>6. Processi<\/h4>\n<p>\nConserva i dati di stato dell'applicazione direttamente all'interno dell'app stessa. Utilizza sessioni nella memoria operativa dell'applicazione. Utilizza il maggior numero possibile di risorse condivise con i servizi esterni. Legati al fatto che l'app pu\u00f2 avere solo un processo e non permettere la scalabilit\u00e0.<\/p>\n<p>Per quanto riguarda le sessioni, conserva i dati solo nella cache controllata da servizi esterni (memcached, redis), in modo che anche se hai 20 processi dell'applicazione in esecuzione, ognuno di essi, accedendo alla cache, possa continuare a lavorare con il cliente nello stesso stato in cui l'utente si trovava interagendo con l'applicazione in un altro processo. Con questo approccio, si ottiene cos\u00ec che, indipendentemente da quante copie di servizi esterni vengono utilizzate, tutto funzioner\u00e0 regolarmente e senza problemi di accesso ai dati.<\/p>\n<h4>7. Binding delle porte<\/h4>\n<p>\nSolo il server web deve sapere come lavorare con i servizi esterni. \u00c8 meglio sollevare i servizi esterni direttamente all'interno del server web. Ad esempio come modulo PHP in Apache.<br \/>\nTutti i tuoi servizi devono essere accessibili l'uno all'altro tramite l'accesso a un indirizzo e una porta (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), cio\u00e8 da nginx posso accedere sia a php-fpm che a postgres, e da php-fpm a postgres e nginx, e fondamentalmente da ciascun servizio posso accedere a un altro servizio. In questo modo, la vitalit\u00e0 di un servizio non \u00e8 legata alla vitalit\u00e0 di un altro servizio.<\/p>\n<h4>8. Parallelismo<\/h4>\n<p>\nLavora con un solo processo, altrimenti potrebbe succedere che pi\u00f9 processi non riescano a collaborare! <\/p>\n<p>Lascia la possibilit\u00e0 di scalabilit\u00e0. Docker Swarm \u00e8 perfetto per questo. <br \/>\nDocker Swarm \u00e8 uno strumento per creare e gestire cluster di container sia tra diverse macchine che tra molti container su una singola macchina.<\/p>\n<p>Utilizzando swarm, posso determinare quanti risorse assegnare a ciascun processo e quanti processi della stessa servizio avviare. L'load balancer interno, ricevendo dati su una porta specifica, li inoltrer\u00e0 automaticamente ai processi. In questo modo, notando che il carico sul server \u00e8 aumentato, posso aggiungere pi\u00f9 processi, riducendo cos\u00ec il carico su determinati processi.<\/p>\n<h4>9. Disposabilit\u00e0<\/h4>\n<p>\nNon utilizzare code per lavorare con processi e dati. L'uccisione di un processo deve influire sul funzionamento dell'intera applicazione. Se un servizio si interrompe, cade tutto.<\/p>\n<p>Ogni processo e servizio pu\u00f2 essere spento in qualsiasi momento e questo non dovrebbe influenzare altri servizi (non si intende che un servizio diventi inaccessibile a un altro servizio, ma che un altro servizio non si spenga in seguito a questo). Tutti i processi devono terminare in modo ordinato, in modo tale che al termine non ci siano danni ai dati e alla successiva accensione il sistema funzioni correttamente. Cio\u00e8, anche in caso di arresto anomalo, i dati non devono subire danni (a tal proposito, va bene un meccanismo di transazioni; le query nel database funzionano solo in gruppi, e se almeno una query del gruppo non viene eseguita o si verifica un errore, nessun'altra query del gruppo verr\u00e0 eseguita effettivamente).<\/p>\n<h4>10. Parit\u00e0 tra sviluppo e produzione<\/h4>\n<p>\nLa versione di produzione, staging e locale dell'applicazione devono essere diverse. In produzione utilizziamo il framework Yii Lite, mentre localmente utilizziamo Yii, cos\u00ec funziona pi\u00f9 velocemente in produzione!<\/p>\n<p>In realt\u00e0, tutte le distribuzioni e il lavoro con il codice devono avvenire in ambienti quasi identici (non si parla di hardware fisico). Inoltre, chiunque faccia parte del team di sviluppo dovrebbe essere in grado di distribuire il codice in produzione se necessario, non solo un reparto devops appositamente addestrato, capace di lanciare l'applicazione in produzione solo grazie a poteri speciali.<\/p>\n<p>In questo, ci aiuta anche Docker. Seguendo tutti i punti precedenti, l'uso di Docker render\u00e0 il processo di distribuzione dell'ambiente, sia in produzione che sulla macchina locale, una questione di una o due righe di comando.<\/p>\n<h4>11. Registrazione<\/h4>\n<p>\nScriviamo i log in file e nel database! Non puliamo file e database dai log. Compreremo semplicemente un disco rigido da 9000 petabyte e va bene cos\u00ec.<\/p>\n<p>Tutti i log devono essere considerati come un flusso di eventi. L'applicazione stessa non dovrebbe occuparsi dell'elaborazione dei log. I log devono essere inviati o a stdout, oppure trasmessi tramite un protocollo come udp, in modo che il lavoro dell'applicazione con i log non crei alcun problema. In questo caso, graylog \u00e8 una buona opzione. Graylog, ricevendo tutti i log tramite udp (non \u00e8 necessario attendere una risposta per l'accettazione del pacchetto), non interferisce in alcun modo con l'applicazione e si occupa solo della strutturazione e del trattamento dei log. La logica dell'applicazione non cambia per lavorare con approcci simili.<\/p>\n<h4>12. Compiti di amministrazione<\/h4>\n<p>\nPer aggiornare dati, database e cos\u00ec via, utilizzare un endpoint appositamente creato nell'API, il cui completamento due volte di seguito porter\u00e0 a una duplicazione dei dati. Ma voi non siete fessi, non premerete due volte, e le migrazioni non ci servono.<\/p>\n<p>Tutti i compiti di amministrazione devono essere eseguiti nell'ambiente in cui si trova tutto il codice, a livello di versioni. Quindi, se dobbiamo modificare la struttura del database, non lo faremo manualmente cambiando i nomi delle colonne e aggiungendo nuove colonne tramite strumenti di gestione del database. Per queste operazioni, creiamo script separati \u2014 migrazioni, che vengono eseguiti ovunque e in tutti gli ambienti con risultati comuni e chiari. Per tutti gli altri compiti, come popolare il progetto con dati, devono essere applicate metodologie simili.<\/p>\n<h3>Esempio di implementazione in PHP, Laravel, Laradock, Docker-Compose<\/h3>\n<p>\nP.S. Tutti gli esempi sono stati fatti su MacOS. La maggior parte si adatta anche a Linux. Gli utenti Windows, scusate, ma non lavoro con Windows da molto tempo.<\/p>\n<p>Immaginiamo una situazione in cui non \u00e8 installata alcuna versione di PHP sul PC e non c'\u00e8 nulla. <br \/>\nInstalliamo l'ultima versione di docker e docker-compose. (questo pu\u00f2 essere trovato su Internet)<\/p>\n<pre><code class=\"bash\">docker -v &amp;&amp; \ndocker-compose -v\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/d9e77c47eef486befb6ebd8118403d13.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n1. Installiamo <noindex><a rel=\"nofollow\" href=\"https:\/\/laradock.io\/\">Laradock<\/a><\/noindex><\/p>\n<pre><code class=\"bash\">git clone https:\/\/github.com\/Laradock\/laradock.git &amp;&amp; \nls\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/67b3214d9a5cff4596c4914ea6e199c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer quanto riguarda Laradock, posso dire che \u00e8 una cosa davvero fantastica, che raccoglie molti container e strumenti ausiliari. Tuttavia, non raccomanderei di utilizzare Laradock senza modifiche in produzione a causa della sua eccessivit\u00e0. \u00c8 meglio creare i propri container basandosi sugli esempi di Laradock, cos\u00ec ci sar\u00e0 spazio per ottimizzazioni, poich\u00e9 non \u00e8 necessario avere tutto ci\u00f2 che offre contemporaneamente.<\/p>\n<p>2. Configuriamo Laradock per il lavoro della nostra applicazione.<\/p>\n<pre><code class=\"bash\">cd laradock &amp;&amp; \ncp env-example .env\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/df8107e1be933cc955be8ca5066f22f2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2.1. Apriamo il catalogo habr (la cartella principale in cui \u00e8 stato clonato laradock) in un qualsiasi editor. (Nel mio caso PHPStorm)<\/p>\n<p>In questa fase impostiamo solo il nome al progetto.<\/p>\n<p><img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/f6026fd04130590539e0945db30ec0dd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2.2. Avviamo l'immagine del workspace. (Nel vostro caso, le immagini impiegheranno un po' per essere costruite)<br \/>\nIl workspace \u00e8 un'immagine appositamente preparata per lavorare con il framework a nome dello sviluppatore.<\/p>\n<p>Entriamo all'interno del contenitore usando <\/p>\n<pre><code class=\"bash\">docker-compose up -d workspace &amp;&amp; \ndocker-compose exec workspace bash\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/e839a5cd055b6c06c02cdd03a5054477.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2.3. Installiamo Laravel<\/p>\n<pre><code class=\"bash\">composer create-project --prefer-dist laravel\/laravel application<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/b21b3fc30ce1bec63aee43ab5fce53e3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2.4. Dopo l'installazione, verifichiamo se \u00e8 stata creata la directory con il progetto e chiudiamo il compose.<\/p>\n<pre><code class=\"bash\">ls\nexit\ndocker-compose down\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/e812f383138637656ec96804833cfc53.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2.5. Torniamo indietro in PHPStorm e impostiamo il percorso corretto per la nostra applicazione laravel nel file .env.<\/p>\n<p><img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/abb9a5694d01163960af5375767f331b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Aggiungiamo tutto il codice in Git.<\/p>\n<p>Per fare ci\u00f2, creiamo un repository su Github (o altrove). Accediamo nel terminale alla directory habr ed eseguiamo il seguente codice.<\/p>\n<pre><code class=\"bash\">echo \"# habr-12factor\" &gt;&gt; README.md\ngit init\ngit add README.md\ngit commit -m \"first commit\"\ngit remote add origin git@github.com:nzulfigarov\/habr-12factor.git # qui sar\u00e0 il link al vostro repo\ngit push -u origin master\ngit status\n<\/code><\/pre>\n<p>\nControlliamo se va tutto bene. <\/p>\n<p><img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/cbcb770a95d91655bdaf727be79742ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer comodit\u00e0, consiglio di utilizzare un'interfaccia visiva per Git, nel mio caso si tratta di <noindex><a rel=\"nofollow\" href=\"https:\/\/www.gitkraken.com\/invite\/qXBXV9Wm\">GitKraken<\/a><\/noindex>. (qui c'\u00e8 il link di affiliazione)<\/p>\n<p>4. Avviamo!<\/p>\n<p>Prima di avviare, assicurati che non ci sia nulla in ascolto sulle porte 80 e 443.<\/p>\n<pre><code class=\"bash\">docker-compose up -d nginx php-fpm<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/f0bf0416e67b918e0966100e37c74454.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCos\u00ec, il nostro progetto \u00e8 composto da 3 servizi separati:<\/p>\n<ul>\n<li>nginx \u2014 server web<\/li>\n<li>php-fpm \u2014 php per gestire le richieste dal server web<\/li>\n<li>workspace \u2014 php per lo sviluppatore<\/li>\n<\/ul>\n<p>\nFinora siamo riusciti a creare un'applicazione corrispondente ai punti 4 su 12, nello specifico:<\/p>\n<p>1. <b>Base di codice<\/b> \u2014 tutto il codice si trova in un unico repository (piccola nota: potrebbe essere corretto inserire docker all'interno del progetto laravel, ma non \u00e8 fondamentale).<\/p>\n<p>2. <b>Dipendenze<\/b> \u2014 Tutte le nostre dipendenze sono chiaramente elencate nel application\/composer.json e in ogni Dockerfile di ciascun contenitore.<\/p>\n<p>3. <b>Servizi esterni (Backing Services)<\/b> \u2014 Ogni servizio (php-fpm, nginx, workspace) vive la sua vita e viene connesso dall'esterno e, durante il lavoro con un servizio, l'altro non verr\u00e0 toccato.<\/p>\n<p>4. <b>Processi<\/b> \u2014 ogni servizio \u00e8 un singolo processo. Ogni servizio non mantiene uno stato interno.<\/p>\n<p>5.<b> Binding delle porte (Port binding)<\/b><\/p>\n<pre><code class=\"bash\">docker ps\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/e6e3fa4a12a43d1bcd51992c424c1245.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCome vediamo, ogni servizio \u00e8 avviato sulla propria porta e accessibile a tutti gli altri servizi.<\/p>\n<p>6.<b> Parallelismo <\/b><\/p>\n<p>Docker ci consente di avviare pi\u00f9 processi per gli stessi servizi con bilanciamento automatico del carico tra di essi. <\/p>\n<p>Fermiamo i contenitori e li avviamo di nuovo tramite il flag <b>\u2014scale<\/b><\/p>\n<pre><code class=\"bash\">docker-compose down &amp;&amp; \ndocker-compose up -d --scale php-fpm=3 nginx php-fpm\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/f5d279b8a034512dd20024272c7f03b0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCome possiamo vedere, sono state create delle copie del container php-fpm. Non \u00e8 necessario apportare modifiche a questo container. Continuiamo a collegarci a lui utilizzando la porta 9000, mentre Docker gestisce il carico tra i container.<\/p>\n<p>7. <b>Eliminabilit\u00e0 (Disposability)<\/b> \u2014 ogni container pu\u00f2 essere interrotto senza danneggiare gli altri. Fermare o riavviare un container non influenzer\u00e0 il funzionamento dell'applicazione nei successivi avvii. Ogni container pu\u00f2 essere avviato in qualsiasi momento.<\/p>\n<p>8. <b>Parit\u00e0 tra sviluppo e produzione dell'applicazione<\/b> \u2014 tutti i nostri ambienti sono identici. Una volta avviata la sistemazione sul server in produzione, non sar\u00e0 necessario modificare nulla nei tuoi comandi. Tutto si baser\u00e0 esattamente su Docker.<\/p>\n<p>9. <b>Log (Logs)<\/b> \u2014 tutti i log di questi container vengono inviati in stream e sono visibili nella console di Docker. (In questo caso, con altri container personalizzati, potrebbe non essere cos\u00ec se non ci si preoccupa di questo)<\/p>\n<pre><code class=\"bash\"> docker-compose logs -f<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/67e275042b96f5270534466b426d4fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTuttavia, c'\u00e8 una limitazione in quanto i valori default in PHP e Nginx registrano anch'essi i log in un file. Per soddisfare i 12 fattori, \u00e8 necessario <b>disabilitare<\/b> registrare i log in un file nelle configurazioni di ciascun container separatamente.<\/p>\n<p>Inoltre, Docker offre la possibilit\u00e0 di indirizzare i log non solo a stdout, ma anche a strumenti come graylog di cui ho parlato sopra. E all'interno di graylog, possiamo gestire i log come vogliamo e la nostra applicazione non se ne accorger\u00e0 affatto.<\/p>\n<p>10. <b>Attivit\u00e0 di amministrazione<\/b> \u2014 tutte le operazioni di amministrazione vengono gestite da Laravel grazie allo strumento artisan esattamente come avrebbero voluto i creatori di un'applicazione a 12 fattori.<\/p>\n<p>Come esempio, mostrer\u00f2 come vengono eseguite alcune comandi.<br \/>\nEntriamo nel container.<\/p>\n<pre><code class=\"bash\"> \ndocker-compose exec workspace bash\nphp artisan list\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/3d5fb5bc40b4b8b0cb225116c0f3d625.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOra possiamo utilizzare qualsiasi comando. (Nota che non abbiamo configurato il database e la cache, quindi met\u00e0 dei comandi non verr\u00e0 eseguita correttamente, poich\u00e9 sono destinati a funzionare con la cache e il db).<\/p>\n<p><img decoding=\"async\" alt=\"Sviluppo di applicazioni e Blue-Green deployment, basandosi sulla metodologia The Twelve-Factor App con esempi in php e docker\" src=\"\/wp-content\/uploads\/2020\/02\/6f84bb2ade2ade654d2c361c585edeae.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n11. <b>Configurazioni<\/b> e 12. <b>Costruzione, rilascio, esecuzione<\/b><\/p>\n<p>Questa parte volevo dedicarla al Blue-Green Deployment, ma \u00e8 risultata troppo estesa per questo articolo. Scriver\u00f2 un articolo separato su questo tema. <\/p>\n<p>In poche parole, il concetto si basa su sistemi CI\/CD come <b>Jenkins<\/b> e <b>Gitlab CI<\/b>. In entrambi si possono definire variabili ambientali collegate a un ambiente specifico. Pertanto, in questo scenario si attuer\u00e0 il punto con <b>Le configurazioni<\/b>.<\/p>\n<p>E il punto su <b>Costruzione, rilascio, esecuzione<\/b> viene risolto dalle funzioni integrate in entrambe le utility chiamate <b>Pipeline<\/b>.<\/p>\n<p><b>Pipeline<\/b> consente di suddividere il processo di deployment in molte fasi, evidenziando le fasi di build, release e execution. Inoltre, nel Pipeline, puoi creare backup e fare praticamente qualsiasi cosa. Questo strumento ha un potenziale illimitato.<\/p>\n<p>Il codice dell'applicazione si trova su <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nzulfigarov\/habr-12factor\">Github<\/a><\/noindex>.<br \/>\nNon dimenticare di inizializzare il submodule durante il cloning di questo repository.<\/p>\n<p>P.S.: Tutti questi approcci possono essere utilizzati con qualsiasi altra utility e linguaggio di programmazione. L'importante \u00e8 che l'essenza non cambi.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/480020\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u0442\u0435\u043e\u0440\u0438\u0438. \u0427\u0442\u043e \u0442\u0430\u043a\u043e\u0435 The Twelve-Factor App? \u041f\u0440\u043e\u0441\u0442\u044b\u043c\u0438 \u0441\u043b\u043e\u0432\u0430\u043c\u0438, \u044d\u0442\u043e \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442 \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u043d\u044b\u0439 \u0443\u043f\u0440\u043e\u0441\u0442\u0438\u0442\u044c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0443 SaaS \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439, \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u0442\u0435\u043c \u0447\u0442\u043e, \u043e\u0441\u0432\u0435\u0434\u043e\u043c\u043b\u044f\u0435\u0442 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u0438 DevOps \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430\u0445 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0447\u0430\u0449\u0435 \u0432\u0441\u0435\u0433\u043e \u0432\u0441\u0442\u0440\u0435\u0447\u0430\u043b\u0438\u0441\u044c \u0432 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439. \u0414\u043e\u043a\u0443\u043c\u0435\u043d\u0442 \u0441\u0444\u043e\u0440\u043c\u0438\u0440\u043e\u0432\u0430\u043d \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430\u043c\u0438 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b Heroku. \u041c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u044f \u0434\u0432\u0435\u043d\u0430\u0434\u0446\u0430\u0442\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432(The Twelve-Factor App) \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0430 \u0434\u043b\u044f \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439, \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u043d\u044b\u0445 \u043d\u0430 \u043b\u044e\u0431\u043e\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":40597,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-40596","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/razrabotka-prilozhenij-i-blue-green-deployment-opirayas-na-metodologiyu-the-twelve-factor-app-s-primerami-na-php-i-docker\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 Blue-Green deployment, \u043e\u043f\u0438\u0440\u0430\u044f\u0441\u044c \u043d\u0430 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u044e The Twelve-Factor App \u0441 \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u043c\u0438 \u043d\u0430 php \u0438 docker | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/razrabotka-prilozhenij-i-blue-green-deployment-opirayas-na-metodologiyu-the-twelve-factor-app-s-primerami-na-php-i-docker\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-02T07:38:43+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-02T07:38:43+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Sviluppo di applicazioni e deployment Blue-Green, basato sulla metodologia The Twelve-Factor App con esempi in php e docker | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/razrabotka-prilozhenij-i-blue-green-deployment-opirayas-na-metodologiyu-the-twelve-factor-app-s-primerami-na-php-i-docker","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 Blue-Green deployment, \u043e\u043f\u0438\u0440\u0430\u044f\u0441\u044c \u043d\u0430 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u044e The Twelve-Factor App \u0441 \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u043c\u0438 \u043d\u0430 php \u0438 docker | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/razrabotka-prilozhenij-i-blue-green-deployment-opirayas-na-metodologiyu-the-twelve-factor-app-s-primerami-na-php-i-docker","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-02T07:38:43+00:00","article:modified_time":"2020-02-02T07:38:43+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"40596","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:20:45","updated":"2022-09-27 22:57:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/40596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=40596"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/40596\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/40597"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=40596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=40596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=40596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}