I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio 1 2
evil80
evil80
il 7 febbraio 2019 alle 18:32
234 messaggi dal 08 marzo 2012
Ciao a tutti,

sto utilizzando Microsoft.AspNetCore.SignalR.Hub all'interno di un'applicazione web Asp.NET CORE
Puntualmente accade che non riesco a ripubblicare un aggiornamento su Azure (tramite FTP) perchè i file risultano essere i uso.
Sono quindi costretto a stoppare l'app service, fare l'aggiornamento e poi riavviarlo.

Sapreste indicarmi in quale modo evitare questo comportamento? Come posso effettivamente stoppare un servizio di tipo Microsoft.AspNetCore.SignalR.Hub?

Grazie!
RispondiQuoting
BrightSoul
BrightSoul
l'8 febbraio 2019 alle 07:58
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao, è normale ma non dipende da SignalR.
L'applicazione ASP.NET Core deve essere necessariamente arrestata prima che possa essere aggiornata.
Anziché copiare i file a mano via FTP, usa questa modalità di pubblicazione da Visual Studio (se usi Visual Studio) che ridurrà il downtime al minimo.

https://docs.microsoft.com/it-it/aspnet/core/tutorials/publish-to-azure-webapp-using-vs?view=aspnetcore-2.2

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
evil80
evil80
il 10 febbraio 2019 alle 10:44
234 messaggi dal 08 marzo 2012
Quindi succede con qualsiasi applicazione web .net core? Perché è più su questa che usa signalr che sperimento dei problemi (per questo pensavo fosse legato al componente).

Ne approfitto per farti un'altra domanda. Come gestisci ambiente di test, quality e produzione con gli app service e sql azure?
Ne crei di diversi in resource group diversi oppure usi i deployment slot?
Ma con ul db server (io uso SQL AZURE) come ti comporti invece?
Ne fai una copia e la tieni allineata?

Grazie!
RispondiQuoting
evil80
evil80
il 4 marzo 2019 alle 10:57
234 messaggi dal 08 marzo 2012
BrightSoul ha scritto:
Ciao, è normale ma non dipende da SignalR.

https://docs.microsoft.com/it-it/aspnet/core/tutorials/publish-to-azure-webapp-using-vs?view=aspnetcore-2.2

Ciao,

sto usando la modalità indicata ma comunque riscontro sempre problemi. Non esiste una procedura per capire cosa è in uso?
L'unico modo che ho di pubblicare è quello di stoppare/avviare il servizio dalla management console di Azure.

Grazie!
Modificato da evil80 il 04 marzo 2019 23:09 -
RispondiQuoting
BrightSoul
BrightSoul
il 4 marzo 2019 alle 23:25
11.886 messaggi dal 09 febbraio 2002
Contributi
Sì, puoi usare i deployment slots e configurare una connection string sticky sullo slot, in modo che nell'ambiente di test ti colleghi sempre al db test.
https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#configuration-for-deployment-slots
I db li puoi tenere aggiornati con le migration, ma io non ho molta esperienza con Azure. Sentiamo che dice Andrea che è MVP per Azure.
Modificato da BrightSoul il 04 marzo 2019 23:33 -
Enjoy learning and just keep making
RispondiQuoting
andrea.tosato86
andrea.tosato86
il 5 marzo 2019 alle 08:36
244 messaggi dal 22 gennaio 2017
Contributi
Ciao evil80, la procedura corretta per il deployment sarebbe quella di passare attraverso lo slot. In questa maniera si evita il down del servizio.
Nello script che ti riporto, spiego il perchè della prassi.
https://www.windowsazureitalia.com/script/136/Bluegreen-Deployment-Azure-Web-App-DevOps.aspx

Ad ogni modo, il recycle del pool dell'applicazione è buona norma e questo ovviamente introduce il tuo problema. Lavorando con gli slot, il traffico viene indirizzato verso l'istanza che ha in "running" già la nuova versione.


Per quanto riguarda il database, ci sono varie strade, dipendenti anche dal costo del servizio.
Si possono usare degli slot, correttamente creati per fare test, con degli app settings che puntano a DB di ambienti diversi.
Slot DEV, db DEV
Slot Test, db Test
Slot QA, db QA
e così via.

In altre occasioni, è possibile creare App Service e applicazioni completamente isolate e magari con pricing ridotti, in cui fare i test e gli UAT.

Per il Database SQL, mi trovo bene con l'utilizzo delle migrazioni automatiche, utilizzo SSDT che è incluso in Visual Studio e Azure DevOps.
Tu procedi alla migrazione, script per script?
RispondiQuoting
evil80
evil80
il 6 marzo 2019 alle 14:17
234 messaggi dal 08 marzo 2012
Attualmente utilizzo una soluzione che mi piace poco.
Ho due sottoscrizioni, una di test ed una di prod, completamente separate.

Su ognuna mi creo app service, database ed i vari servizi che adopero dopo di che una volta conclusa una fase di test passo le modifiche in produzione.
Per i database stessa cosa e passo le modifiche tramite script.

Ma non mi piace molto, vorrei provare il meccanismo degli slot: domanda gli slot gestiscono anche i database?

Con la mia attuale impostazione posso dare ai dev solo accesso alla sottoscrizione di TEST mentre in prod non ci possono entrare per ovvie ragioni. Potrei riuscire a segmentare in modo simile anche con gli slot, ovvero fargli vedere solo quelli di test?

grazie!
RispondiQuoting
andrea.tosato86
andrea.tosato86
il 6 marzo 2019 alle 14:24
244 messaggi dal 22 gennaio 2017
Contributi
Le due sottoscrizioni separate non sono un problema. Semmai ti consiglierei di implementare una pipeline DevOps e di portare il codice verso la produzione in maniera automatica.
Anche gli script, prevederei una soluzione con SSDT (https://www.gatevnotes.com/continuous-deployment-sql-server-data-tools-project-template/)

domanda gli slot gestiscono anche i database?

Gli slot non gestiscono i database visto che sono concetti della WebApp. Semmai puoi puntare a una connection string diversa per ogni slot.
A fine test, fai lo swap e quindi 0 downtown.

Potrei riuscire a segmentare in modo simile anche con gli slot, ovvero fargli vedere solo quelli di test?

NO
RispondiQuoting
1 2

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.