lunedì 26 gennaio 2015

Automatizzare web creazione di hosting in Azure con PowerShell

Ecco la situazione: hai un mucchio di siti su modelli di hosting tradizionali. Contratti d'affitto condivise su macchine logiche singoli, un'infrastruttura dedicata o, peggio ancora, non proprio nessuna idea perché basta continuare a pagare quei $ 5 al mese e roba funziona. La maggior parte del tempo.

Ma avete visto la luce e si desidera spostare le cose da Azure in massa. Una piccola manciata di siti non è un dramma, c'è un po 'di lavoro di configurazione per creare le risorse Azure per ciascuno e fino a quando si segue un set predefinito di passi appena perfettamente, che stai bene. Ma come la maggior parte delle cose che richiedono operazioni manuali, è altamente soggetto a errori in termini di ottenere tutto giusto ogni volta ed è anche molto laborioso. Una volta che la manciata di siti diventa decine, inizia a sentire come un po 'di duro lavoro. Non solo, ma si sta andando a voler nuove attività in Azure in futuro e avere un modo ripetibile di farlo vicino istantaneamente sarebbe sorta di piacevole.

Ho avuto questa sfida di recente - "vogliamo la migrazione di un mucchio di siti web di Azure e faranno stare tutti in sostanza lo stesso modello" - così invece di avere persone clic sui collegamenti nel portale Azure, ho dato loro un singolo script PowerShell e li scatenato. Sto per darvi tutti i passi qui che spiegano come funziona il tutto e vi darà l'intero script PowerShell in modo che non si deve lavorare tutti i dadi e bulloni da zero. Buon divertimento!

Preparazione
Per prima cosa - avrete bisogno di un abbonamento Azure. Ok, un po 'ovvio, ma non si può semplicemente saltare in PowerShell e avviare l'esecuzione di comandi. Ho anche già avuto un sito web che significa che c'era già un piano di hosting adeguato in più ho avuto un database SQL Azure (ricordate che questo è l'offerta PaaS, non un pieno soffiato standalone SQL Server è possibile RDP), che significa che c'era già un database server e appropriate regole del firewall. Questo è il presupposto che sto facendo qui e se posso dare un suggerimento, roba che è davvero solo un setup una tantum vale la pena solo facendo nel browser piuttosto che cercare di capire i comandi per te. In realtà anche se avete intenzione di script di tutto il processo, fare un manuale e capire esattamente come volete che il vostro stato finale di essere.

Iniziare con PowerShell Azure
Ipotesi prima: Presumo che hai Azure PowerShell installato e funzionante, quindi se non è questo il caso, passano un paio di minuti sopra il Come installare e configurare Azure PowerShell tutto pagina e ottenere giocare piacevole. Assicurati si può effettivamente caricare una sessione Azure PowerShell allora continuate a leggere.

Ecco un rapido suggerimento pro: controllare l'abbonamento! In più di un'occasione ho chiedevo perché cambiamenti PowerShell che stavo facendo non apparivano nel portale web Azure e sarebbe sempre spengo che ero in un abbonamento errato. Salva te stesso il dolore se si ha accesso a più di un abbonamento e sempre eseguire prima di iniziare:

Get-AzureSubscription
Potrai vedere una lista di tutti gli abbonamenti e ognuno ha un attributo "IsCurrent". Se vedi qualcosa che non ti aspetti, flick su oltre al corretto prima di arrivare al lavoro:

Selezionare-AzureSubscription "Abbonamento di Troy"
Oh - e se avete intenzione di continuare a tornare a questo abbonamento e non è già il default, ecco quello che vi serve:

Selezionare-AzureSubscription-Default -SubscriptionName "Sottoscrizione di Troy"
Ci sono un mucchio di riferimenti sul web per i comandi che non funzionano con l'attuale generazione di API di Azure in modo che dovrebbe risparmiare qualche dolore, almeno fino a quando cambia di nuovo e questo diventa un altro riferimento non corretto! Ma sul serio, non essere consapevoli che l'API non cambia nel rompere modi e che si può anche trovare i comandi che non sono più corrette.

Con il fatto che, cominciamo creando roba!

Creazione (e rimozione) del sito web
Questo bit può essere morto facile, è solo un singolo comando:

New-AzureWebSite TroyPSTest
Ci vorrà secondi, dopo di che dovrete il seguente:

Istanze: {}
NumberOfWorkers: 1
DefaultDocuments: {Default.htm, Default.html, Default.asp, index.htm ...}
NetFrameworkVersion: v4.0
Phpversion: 5.4
RequestTracingEnabled: False
HttpLoggingEnabled: False
DetailedErrorLoggingEnabled: False
PublishingUsername: $ TroyPSTest
PublishingPassword: mZvMGi2GfDc2iCepcPm6vsEd9hLxvtk3wl5NNtHxWaMqHDjAY8Apka4fXM3W
AppSettings: {WEBSITE_NODE_DEFAULT_VERSION}
Metadati: {}
ConnectionStrings: {}
HandlerMappings: {}
Nome: TroyPSTest
Stato: Running
Nomi host: {troypstest.azurewebsites.net}
Spazio Web: AustraliaEastwebspace
SelfLink: https://waws-prod-sy3-001.api.azurewebsites.windows.net:454/subsc
                                  riptions / 62e2a1e5-4eda-4c1e-805e-44a6c8f8afbd / spazi web / Australia
                                  Eastwebspace / siti / TroyPSTest
RepositorySiteName: TroyPSTest
Cod: Gratis
UsageState: Normal
Abilitato: True
AdminEnabled: True
EnabledHostNames: {troypstest.azurewebsites.net, troypstest.scm.azurewebsites.net}
SiteProperties: Microsoft.WindowsAzure.Commands.Utilities.Websites.Services.WebEn
                                  tities.SiteProperties
AvailabilityState: Normal
HostNameSslStates: {troypstest.azurewebsites.net, troypstest.scm.azurewebsites.net}
AzureDriveTraceEnabled:
AzureDriveTraceLevel: Errore
AzureTableTraceEnabled:
AzureTableTraceLevel: Errore
AzureBlobTraceEnabled:
AzureBlobTraceLevel: Errore
ManagedPipelineMode: Integrata
WebSocketsEnabled: False
RemoteDebuggingEnabled: False
RemoteDebuggingVersion: VS2012
RoutingRules: {}
Use32BitWorkerProcess: True
AutoSwapSlotName:
SlotStickyAppSettingNames: {}
SlotStickyConnectionStringNames: {}
Avere un sfogliare che - le condizioni saranno per lo più familiare a voi se avete speso un po 'di tempo in siti web Azure, ma non siete probabilmente abituati a vederla tutti seduti lì insieme. Questo, comunque, dovrebbe essere molto familiare al stagionato Azure utente del sito:

Elenco di siti in Azure

Questo è solo il solito portale anche se con il nuovo sito ora che figura nella lista. Ricordate, PowerShell è una sola interfaccia in quello che è in ultima analisi, la stessa piattaforma di base che hai utilizzato nel browser, unico modo più veloce! C'è, però, un problema: questo sito è stato creato nel percorso "L'Australia orientale" e impostare come un omaggio. Ho molta voglia di metterlo in-occidentali e renderlo standard in modo che si siede sulla mia macchina logico esistente e non mi scongiuro più denaro. Nessun problema, facciamo solo Nuke sito:

Rimuovere-AzureWebsite -Name TroyPSTest

Otterrete una richiesta di conferma (che è possibile sostituire con il parametro "-Force") allora sì, questo è tutto, sito andato! Prendetevi un momento per bere che in - stiamo creando e rimuovendo siti web tramite la riga di comando in qualche luogo remoto lontane con la stessa facilità avremmo creiamo una cartella locale. Quando è possibile gestire le risorse in modo tale basso attrito, si può iniziare a cambiare veramente il modo di lavorare in modo molto positivo.

Creazione del sito nella giusta posizione
Passando, dobbiamo adattare tale comando originale per ottenere il sito nella giusta posizione. C'è un parametro "-La posizione" che può essere applicato sulla creazione sito web in modo che il comando originale ora cambia a questo:

New-AzureWebSite TroyPSTest -La posizione "West degli Stati Uniti"
Chiaramente posizione desiderata può essere diverso quindi fate attenzione se si sta copiando e incollando! Torna al portale nel browser e ora ci troviamo nel posto giusto:

Nuovo sito in posizione occidentale degli Stati Uniti

Ricordate - al momento non c'è ancora alcuna migrazione per mischiare automagically beni tra i data center in modo da assicurarsi che hai questo diritto prima di procedere altrimenti sei praticamente andando a ricominciare da zero. Vedrete il livello di prezzo è ancora "libero"; torneremo e ordinare che fuori a breve in quanto non è qualcosa che possiamo configurare al momento della creazione del sito.

Impostazione dei parametri del sito web
Quando ti alzi un nuovo sito web Azure, per impostazione predefinita otterrete questo:

PHP abilitato automaticamente

Ora perché sono una sicurezza abbastanza sorta cosciente della persona (e così si dovrebbe essere), davvero non voglio PHP in esecuzione sul sito. Questo non è perché c'è qualcosa intrinsecamente male su PHP, è solo che non ho bisogno di esso. Così facciamo solo disattivarlo:

Set-AzureWebsite -Name TroyPSTest -PhpVersion Off
Che è morto facile, ma c'è solo così tanto che possiamo configurare utilizzando Set-AzureWebsite. Per tutto il resto, dovremo saltare il Resource Manager Azure quindi cerchiamo di farlo ora e risolvere il livello dei prezzi.

Configurazione del livello dei prezzi
Il livello di prezzo è un po 'più complicato e non è qualcosa che possiamo impostare al momento il sito è stato creato, né utilizzando il cmdlet Set-AzureWebsite, piuttosto ci impone di modificare il sito una volta creato. Questo è bene, stiamo andando ad avere bisogno di fare un po 'di che poi comunque e sta andando a richiedere noi saltare in modalità gestore di risorse :

Switch-AzureMode AzureResourceManager
Questo vi dà una nuova serie di cmdlet che è possibile utilizzare per gestire l'ambiente che non si ottiene con i cmdlet di gestione Azure , che è quello che stavamo usando. Vedrai mi salta fuori questo modo e il modo iniziale noto come modalità di gestione dei servizi, come si richiede l'accesso a diversi set di cmdlet.

Quello che stiamo per fare ora è quello di iniziare a lavorare con i gruppi di risorse . Pensate a questi come un insieme logico di attività all'interno di un abbonamento Azure, per esempio, tutti i miei siti web sono sotto uno chiamato "Default-Web-WestUS". È possibile individuare questo nel portale Azure tramite la risorsa gruppi collegamento:

Trovare gruppi di risorse nel portale

Stiamo anche andando a bisogno della versione dell'API Azure stiamo usando così andare a prendere quello come bene e ancora una volta, di essere consapevole del fatto che potrebbe cambiare in modo rottura nel tempo. Ora possiamo recuperare il sito e assegnarlo a una variabile che chiamerò "$ r" (attenzione se si sta copiando e incollando di avere la versione corretta API):

$ R = Get-AzureResource -Name TroyPSTest -ResourceGroupName Default-Web-WestUS -ResourceType Microsoft.Web / Siti -ApiVersion 2014/04/01
Con il sito ora assegnato alla variabile, possiamo iniziare a eseguire varie azioni su di esso, tra cui messa fuori ogni attributo conosciuto semplicemente digitando $ r ed eseguire quel comando da solo. E 'un bene per la verifica a volte perché quello che stiamo andando a fare nel prossimo paio di passi renderanno modifiche al sito e non vogliamo fare inavvertitamente quelli sul sito sbagliato. Listato il valore di $ r vi darà un mucchio di JSON; un'altra cosa che possiamo fare è stampare solo un sottoinsieme delle informazioni come le proprietà dirette dell'entità:

$ R.Properties
Che ci darà una coppia di valori chiave per ogni proprietà:

Valore chiave
--- -----
nome TroyPSTest
Esecuzione Stato
nomi host {troypstest.azurewebsites.net}
spazio web westuswebspace
selfLink https: //waws-prod-bay-003.api.azurewebsites.windows.net: ...
repositorySiteName TroyPSTest
proprietario
usageState 0
abilitato Vero
adminEnabled Vero
enabledHostNames {troypstest.azurewebsites.net, troypstest.scm.azurewebsi ...
siteProperties {[metadati,], [proprietà, System.Collections.Generic.L ...
availabilityState 0
sslCertificates
CSR {}
cers
siteMode
hostNameSslStates {System.Collections.Generic.Dictionary`2 [System.String, S ...
computeMode
serverfarm Default2
webHostingPlan Default2
lastModifiedTimeUtc 22/12/2014 00:57:04
storageRecoveryDefaultState corsa
contentAvailabilityState 0
runtimeAvailabilityState 0
SiteConfig
deploymentId TroyPSTest
trafficManagerHostNames
sku gratuito
premiumAppDeployed
scmSiteAlsoStopped False
targetSwapSlot
HostingEnvironment
WebSites Microservice
cloningInfo
Quello che stiamo per fare ora è cambiare alcune proprietà che ottengono il sito nel livello dei prezzi corretta. Per impostazione predefinita, quando il sito è stato creato è andato in una nuova server farm con un nuovo piano di web hosting e, come già sappiamo, il livello dei prezzi (noto anche come SKU) è stato impostato su "Free". Quello che faremo ora è impostato gli attributi per allinearsi con i miei altri siti assegnando una serie di opportune coppie nome-valore per una nuova variabile che chiameremo $ p:

$ P = @ {"SKU" = "Standard"; "Serverfarm" = "DefaultServerFarm"; "WebHostingPlan" = "DefaultServerFarm"}
Il passo finale è ora di assegnare le proprietà di nuovo a quel nuovo sito web in questo modo:

$ R2 = Set-AzureResource -Name TroyPSTest -ResourceGroupName Default-Web-WestUS -ResourceType Microsoft.Web / Siti -ApiVersion 2014/04/01 -PropertyObject $ p
Sto in uscita il risultato di $ r2 quindi è facile per ispezionare le nuove impostazioni dopo che sono stati applicati. Solo per una sanità mentale assegno comunque, vediamo come le cose appaiono nel portale ora:

Nuovo sito web ora in "Standard" livello di prezzo

Ok, che sembra il modo migliore e solo per essere sicuri che stanno effettivamente utilizzando lo stesso piano di hosting e non mi costa di dollari in più, facciamo click attraverso il sommario:

Tutti i siti web ora nella stessa Resource Group

Questo è grande, sono tutti lì come risorse pari a tale server farm di default in modo che è quello fatto.

L'aggiunta di uno slot di distribuzione messa in scena
Una delle cose veramente pulito sul servizio web Azure è la possibilità di avere gli slot di distribuzione per la distribuzione in scena . Ciò significa che si può spingere il tuo sito web a un caso isolato in cui è possibile testare e assicurarsi che le cose bel gioco prima ancora di distribuzione al sito in diretta sul vostro dominio di produzione. Non solo, ma si può anche avviare una percentuale di routing del traffico per un altro slot con una nuova versione del sito in quello che è noto come "test in produzione". Questo renderà le teste tradizionalisti 'spin - "Prove in produzione - non si può fare questo!" - Ma fa un sacco di senso per il pronto produzione sito ad essere esposti a una piccola percentuale del tuo pubblico prima solo per essere sicuri che tutto gioca bello.

Sto andando a saltare nuovamente dentro i cmdlet di gestione Azure ora come voglio creare un nuovo servizio.

Switch-AzureMode AzureServiceManagement
Aggiunta di uno slot di distribuzione è un pezzo di torta:

New-AzureWebsite TroyPSTest -La posizione "West degli Stati Uniti" -slot "Stage"
Si noti che questo è lo stesso comando, come in precedenza, stiamo solo passando un parametro "Slot", così questa volta. Prendere attenta nota di questo - un unico "sito web" può avere molti "slot" e in seguito vedrete come comandi che non fanno riferimento esplicitamente slot fallire piuttosto male una volta che hai più di quella di default. Saltando sopra al portale, si dovrebbe ora vedere apparire sotto il sito originale, come un nuovo slot di distribuzione:

Slot Deployment ora sul sito

E 'importante notare che questo sito ha ereditato il piano e il prezzo di hosting tier abbiamo impostato in precedenza. E 'anche ereditato l'impostazione PHP che viene disattivata automaticamente per il nuovo sito.

Creazione del database SQL Azure
Ora, prima di imbarcarsi in questa nuova parte del processo, ho già avuto un DB SQL Azure e ho voluto mettere tutti gli altri sulla stessa istanza. Ciò significa che ho già avuto un name server - "snyb5o1pxk" - inoltre ho già avuto le credenziali per accedervi con "diritti Dio" e le regole del firewall appropriate per rendere le connessioni remote dal mio indirizzo IP. Come una tantum per il server, questo vale la pena di fare solo questo direttamente nel portale. Oh - e nel caso in cui si inizia a pensare di creare server separati per ogni progetto, non essere consapevoli delle Azure servizio di sottoscrizione limiti, quote e vincoli .

In termini di comando realmente disposizione il database sul server, questo è un affare molto simile a come è stato creato il sito web e sembra proprio come questo:

$ Db = New-AzureSqlDatabase "snyb5o1pxk" -servername -databasename "TroyPSTestDB" -Edizione "Basic" -MaxSizeGB 2

Non abbiamo necessariamente bisogno di assegnare il risultato alla variabile $ db, ma rende facile poi stamparlo per lo schermo in qualsiasi momento e vedere quello che abbiamo:

Nome: TroyPSTestDB
CollationName: SQL_Latin1_General_CP1_CI_AS
Edizione: di base
MaxSizeGB: 2
MaxSizeBytes: 2147483648
ServiceObjectiveName: di base
ServiceObjectiveAssignmentStateDescription: Complete
CreationDate: 22/12/2014 11:51:28
RecoveryPeriodStartDate: 22/12/2014 12:21:27
Questo è quanto di più semplice come si arriva - ora abbiamo un DB!

Tagging la risorsa
Una cosa che accade quando si inizia ad avere cumuli di risorse nel portale è che le cose si fanno disorganizzato. Etichette in Azure sono simili ai tag si ha familiarità con dire, su questo stesso blog: nullo valore funzionale, ma mantiene roba logicamente correlati raggruppati insieme.

In primo luogo, si torna alla modalità di gestione delle risorse:

Switch-AzureMode AzureResourceManager
Prima di poter applicare un tag, è necessario creare uno. Ho deciso di taggare in base al nome del progetto, si potrebbe anche tag dall'ambiente (stage, test) o qualsiasi altro tassonomia si decide di applicare. Ecco come il mio look:

New-AzureTag -Name progetto -Value TroyPSTest
Possiamo ora utilizzare questo tag in un numero di posizioni, cioè quello di individuare sia il sito e il database come appartenenti a quello gruppo logico di risorse. Vediamo ora riferimento al sito web:

$ R2 = Set-AzureResource -Name TroyPSTest -ResourceGroupName Default-Web-WestUS -ResourceType Microsoft.Web / Siti -ApiVersion 2014/04/01 -PropertyObject $ p -tag @ {Name = "progetto"; Value = "TroyPSTest"}
Si noti che la variabile proprietà abbiamo definito in precedenza viene anche passata. Mentre gli stati Doco questo come optional, ho trovato PowerShell non era reale felice quando non ha ottenuto questo (ho detto che era un po 'volubile, giusto?). Nessuna grossa delusione, è definito già così ho appena gettato di nuovo nella collezione parametri. Naturalmente la cosa più sensata da fare sarebbe quella di utilizzare un unico comando Set-AzureResource e superare sia le proprietà e le variabili in una sola volta, l'approccio di cui sopra è solo di introdurre concetti diversi uno per uno.

Diamo anche il tag DB SQL:

Set-AzureResource -Name TroyPSTestDb -ResourceGroupName server predefinito-SQL-WestUS -ParentResource / snyb5o1pxk -ResourceType Microsoft.Sql / server / database -ApiVersion 2014/04/01 -tag @ {Name = "progetto"; Value = "TroyPSTest"}
Torna sopra al portale e sia il sito web e il DB sono ora seduti uno accanto all'altro sotto il tag "TroyPSTest":

Sito web e bancadati sotto un tag

Bene, ora mi sento tutto molto organizzato!

Impostare il nome host sul sito
Ecco un po 'di pollo e uova uno per voi: si sta andando a voler un nome host sul sito web che significa che si sta andando a voler eseguire qualcosa di simile a questo:

Set-AzureWebsite -Name TroyPSTest -HostNames @ ('troypstest.troyhunt.com')
Tuttavia, che sta per darvi questo:

Set-AzureWebsite: BadRequest: un record CNAME che punta dal troypstest.troyhunt.com a troypstest.azurewebsites.net non è stato trovato. Registrare awverify.troypstest.troyhunt.com Alternativa a awverify.troypstest.azurewebsites.net non è stato trovato neanche.
Se hai mai aggiunto un nome host a un sito web attraverso il portale prima, saprete che non è possibile fino a quando hai creare un CNAME sul record dominio. Tuttavia, è necessario conoscere il nome del sito nella Azure prima di poter fare questo e mentre questo è un nome che fornisci tu stesso, deve anche essere unico e non essere utilizzato da qualsiasi sito web Azure esistenti di proprietà di nessuno . Si potrebbe andare fuori e configurare i record DNS prima di eseguire lo script sul presupposto che il nome scelto per il sito web (che va quindi nella CNAME) sarà permesso, ma se si tratta di "foo", allora si sta andando ad avere per tornare indietro e modificare DNS di nuovo in seguito.

Creazione di un account di accesso SQL e utenti
Una delle ultima cosa che dobbiamo fare è quello di assicurarsi che il sito può effettivamente connettersi al database e questo significa la creazione di un nuovo account di accesso SQL. Sì, si potrebbe avere il sito utilizza le credenziali che sono stati forniti al momento della creazione del server, ma no, non lo si fa. Se non si desidera persone anonime che vagano intorno al vostro sito web con esso quindi effettuare i collegamenti al database utilizzando un account privilegiato che può fare qualsiasi cosa che vuole. Ciò che si vuole è un conto unico per l'applicazione che si può quindi andare tutto principio del privilegio minimo su.

Quando si crea il login tramite PowerShell, non ci sono comandi nativi di fare questo in modo invece che andremo ad utilizzare SMO per eseguire i comandi SQL sul server remoto. Per fare questo, stiamo andando ad avere bisogno di importare il modulo SQLPS prima:

Import-Module SQLPS -DisableNameChecking
Ora possiamo andare avanti e connettersi al server SQL esistente e selezionare il database master in una nuova variabile $ db:

$ Conn.ConnectionString = "server = tcp: snyb5o1pxk.database.windows.net; Database = padrone, ID utente = troyhunt; Password = P @ ssw0rd;"
$ Srv = New-Object "Microsoft.SqlServer.Management.Smo.Server" $ conn
$ Db = $ srv.Databases ["master"]
Con il fatto che, creiamo un accesso SQL che chiameremo "TroyPSTestDbUser":

$ Login = New-Object -TypeName Microsoft.SqlServer.Management.Smo.Login -ArgumentList $ srv, "TroyPSTestDbLogin"
$ Login.LoginType = "SQLLogin"
$ = $ Login.PasswordPolicyEnforced falso
$ = $ Login.PasswordExpirationEnabled falso
$ Login.Create ("S0m3thingR3 @ Llyr @ nd0mTh @ ti $ ntThi $")
Next up creeremo un utente nel DB contro che login:

$ Db = $ srv.Databases ["TroyPSTestDb"]
$ DbUser = New-Object -TypeName Microsoft.SqlServer.Management.Smo.User -ArgumentList $ db, "TroyPSTestDbUser"
$ DbUser.Login = "TroyPSTestDbLogin"
$ DbUser.Create ()
E questo è tutto - lavoro fatto! Naturalmente avrete ancora bisogno di mettere l'utente in un ruolo all'interno del vostro DB dopo che si distribuisce a Azure e dare i diritti appropriati, ma ora è tutto seduto lì in attesa per voi. Non prendere atto di come viene definita la password e set, che non è particolarmente maneggevole (o sicuro) modo, se avete intenzione di essere orchestrare questa massa, ma tornerò a questo un po 'più tardi con lo script mega , c'è solo una cosa che voglio fare prima ...

Aggiungendo la stringa di connessione al sito
Ok, ultimo trucco nella configurazione: Voglio per assicurarsi che il sito è pre-configurato con la stringa di connessione del database. Sappiamo già tutti i dettagli di connessione, è ormai solo una questione di costruire la stringa e invocare i comandi PowerShell appropriati. Ecco tutti i bit:

$ ConnStr = "server = tcp: snyb5o1pxk.database.windows.net, 1433; Database = TroyPSTestDb; User Timeout = 30; "
$ ConnStrInfo = New-Object Microsoft.WindowsAzure.Commands.Utilities.Websites.Services.WebEntities.ConnStringInfo
$ ConnStrInfo.Name = TroyPSTestDb
$ ConnStrInfo.ConnectionString = $ connStr
$ ConnStrInfo.Type = "SQLAzure"
$ ConnStrSettings = ConnectionStrings (Get-AzureWebsite TroyPSTest -slot "produzione").
$ ConnStrSettings.Add ($ connStrInfo)
Set-AzureWebsite -Name TroyPSTest -slot "produzione" -ConnectionStrings $ connStrSettings
Ora c'è una cosa che qui voglio richiamare l'attenzione e questo è il parametro slot sul Get-AzureWebsite e comandi Set-AzureWebsite. Perdere questo e vi permetterà di trascorrere un lungo tempo di battere la testa contro il muro chiedendo perché si sta ricevendo le eccezioni sugli oggetti nulli quando il nome del sito è chiaramente corretto. Vedete, quando un sito ha più slot, come quello che quello di cui sopra fa la cortesia di uno "Stage" abbiamo aggiunto, non specificando esplicitamente lo slot vi lascerà a bocca asciutta in quanto restituisce una collezione che descrive gli slot. Se hai solo uno slot di default allora i comandi implicitamente applica a quello e si otterrà un sito web un'entità indietro in modo che quando si vede tutte quelle "come tos" là fuori che sembrano così dannatamente facile, ma semplicemente non lavorare per voi, che può ben essere il motivo! Ho già detto che può essere frustrante che esattamente lo stesso comando con gli stessi parametri può tornare completamente diversi tipi in base allo stato della risorsa?

Passando e indietro nel portale, ora abbiamo questo:

immagine

Quel nome stringa di connessione dovrà allinearsi con quello del vostro web.config in modo che può significare cambiare dopo la distribuzione del sito web in modo che sia applicata automaticamente al sito.

Suggerimenti Pro
Stuff andrà male e si otterrà errori. Gli errori non possono dire perché, per esempio, quando si aggiunge un tag al database:

Set-AzureResource:: Si è verificato un errore durante l'elaborazione di questa richiesta.
Alla linea: 1 char: 1
+ Set-AzureResource -Name $ dbName -ResourceGroupName $ dbResourceGroup -ParentResou ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo: CloseError: (:) [Set-AzureResource], CloudException
    + FullyQualifiedErrorId: Microsoft.Azure.Commands.Resources.SetAzureResourceCommand
Oh, "si è verificato un errore"! Quando roba inspiegabile va male, alzare il livello di dettaglio:

$ DebugPreference = "Continua"
Se non si desidera che il rumore extra una volta che roba è ordinato, acquietare indietro giù di nuovo:

$ DebugPreference = "SilentlyContinue"
Un'altra cosa che voglio pensare è convenzioni. Se avete intenzione di essere l'applicazione di questo processo per un mucchio di siti poi si vuole pensare alla tua denominazione. Sono andato con le seguenti convenzioni:

Nome Sito web = $ projectName
Nome database = $ projectName + "Db"
Login Database = $ databaseName + "Login"
Nome utente database = $ databaseName + "Utente"
Nome Tag = $ projectName
Un'ultima cosa - e non sei andando in questo modo - non sottovalutare l'importanza della stampa fine:

[Questo argomento rappresenta una documentazione non definitiva ed è soggetto a modifiche nelle versioni future.  Gli argomenti vuoti vengono inclusi come segnaposto.]

Io sono un grande sostenitore di Azure, ma sarò onesto e dire che ho avuto per ottenere i bambini a lasciare la sala prima di esprimere quello che provavo per la consistenza di PowerShell comandi che realmente funzionano . So che ho fatto presente in precedenza e ed è stato un vero e proprio dolore così basta tenere a mente che quando roba non funziona, non è sempre colpa tua, potrebbe essere stato qualcun altro è altrimenti un buon consiglio che ha lavorato per loro, allora, ma può non essere pertinenti ora.

Scripting tutto fuori
In primo luogo, attenzione - draghi avanti! Stiamo per lo script automaticamente il tutto che significa un solo click crea un sacco di roba che ti ha colpito la vostra linea di fondo. A buon mercato come i servizi Azure sono, di creare abbastanza di 'em abbastanza veloce e si può essere in una brutta sorpresa.

Un avvertimento rapido prima - questo script non è altro che i comandi di cui sopra in una sequenza logica e l'utilizzo di alcune variabili d'ambiente a persistere una serie di punture hardcoded dall'alto. Non è un elegante script di PowerShell quindi se volete un buon punto di riferimento per questo, controllare questo esempio per la creazione di un gruppo di risorse Azure.

Ecco il tutto:
# Per params progetto
$ ProjectName  =  " TroyPSTest "
$ HostName  =  " troypstest.troyhunt.com "

# Ambiente costanti
$ Location  =  " occidentale degli Stati Uniti "
$ WebResourceGroup  =  " Default-Web-WestUS "
$ WebHostingPlan  =  " DefaultServerFarm "
$ DbResourceGroup  =  " Default-SQL-WestUS "
$ DbServerName  =  " snyb5o1pxk "
$ DbServerLogin  =  " troyhunt "
$ DbServerPassword  =  " P @ ssw0rd "
$ ApiVersion  =  " 2014/04/01 "

# Computerizzata vars
$ DbName  =  $ projectName  +  " Db "
$ DbLoginName  =  $ dbName  +  " Accedi "
$ DbPassword  = [guid] :: NewGuid ()
$ Nomeutentedb  =  $ ​​dbName  +  " User "

• Assicurarsi si dà il via a modalità di gestione dei servizi
Switch-AzureMode AzureServiceManagement

# Creare il sito in posizione appropriata
New-AzureWebSite  $ projectName  - Location $ posizione

# Disattivare PHP
Set-AzureWebsite  - Nome $ projectName  - phpversion Off

# Aggiungere un nome host (solo se avete già messo il CNAME sul dominio)
# Set-AzureWebsite -Name $ projectName -HostNames @ ($ hostname)

# Passare al gestore risorse
Switch-AzureMode AzureResourceManager

# Prendi il sito e quindi modificare la SKU
$ P  = @ { " SKU "  =  " standard " ; " serverfarm "  =  $ webHostingPlan ; " webHostingPlan "  =  $ webHostingPlan }
Set-AzureResource  - Nome $ projectName  - ResourceGroupName Default-Web-WestUS  - ResourceType Microsoft.Web / siti - ApiVersion $ apiVersion  - PropertyObject $ p

# Passare al gestore risorse
Switch-AzureMode AzureServiceManagement

# Aggiungere uno slot di distribuzione per messa in scena (questo deve essere fatto dopo aver impostato la SKU, come non è possibile aggiungere gli slot di distribuzione sotto il default "libero" SKU)
New-AzureWebsite  $ projectName  - Location $ location  - Slot " Stadio "

# Creare un DB SQL
New-AzureSqlDatabase  - ServerName $ dbServerName  - DatabaseName $ dbName  - Edition " di base "  - MaxSizeGB 2

# Passare al gestore risorse
Switch-AzureMode AzureResourceManager

# Creare un tag
New-AzureTag  - Nome progetto - Valore $ projectName

# Impostare il tag sul sito web
Set-AzureResource  - Nome $ projectName  - ResourceGroupName $ webResourceGroup  - ResourceType Microsoft.Web / siti - ApiVersion $ apiVersion  - PropertyObject $ p  - Tags @ {Name =  " progetto " ; Valore =  $ projectName }

# Impostare il tag sul DB
Set-AzureResource  - Nome $ dbName  - ResourceGroupName $ dbResourceGroup  - server ParentResource / $ dbServerName  - ResourceType Microsoft.Sql / server / database - ApiVersion $ apiVersion  - Tags @ {Name =  " progetto " ; Valore =  $ projectName }

# Accendi SMO
Import-Module SQLPS - DisableNameChecking
$ Conn  =  New-Object System.Data.SqlClient.SqlConnection
$ Conn .ConnectionString =  " Server = tcp: "  +  $ dbServerName  +  " .database.windows.net; Database = padrone, User ID = "  +  $ dbServerLogin  +  " ; Password = "  +  $ dbServerPassword  +  " ; "
$ Srv  =  New-Object  " Microsoft.SqlServer.Management.Smo.Server "  $ conn
$ Db  =  $ ​​srv .databases [ " maestro " ]

# Creare il login
$ Login  =  New-Object  - TypeName Microsoft.SqlServer.Management.Smo.Login - ArgumentList $ srv , $ dbLoginName
$ Login .LoginType =  " SQLLogin "
$ Login .PasswordPolicyEnforced =  $ false
$ Login .PasswordExpirationEnabled =  $ false
$ Login .Create ( $ dbPassword )

# Aggiungere l'utente al DB
$ Db  =  $ ​​srv .databases [ $ dbName ]
$ DbUser  =  New-Object  - TypeName Microsoft.SqlServer.Management.Smo.User - ArgumentList $ db , $ nomeutentedb
$ DbUser .login =  $ dbLoginName
$ DbUser .Create ()

# Passare al gestore risorse
Switch-AzureMode AzureServiceManagement

# Aggiungere la stringa di connessione al sito
$ ConnStr  =  " Server = tcp: "  +  $ dbServerName  +  " .database.windows.net, 1433; Database = "  +  $ dbName  +  " ; utente             Timeout = 30; "
$connStrInfo  =  New-Object Microsoft.WindowsAzure.Commands.Utilities.Websites.Services.WebEntities.ConnStringInfo
$ ConnStrInfo .Name = $ dbName
$ ConnStrInfo .ConnectionString = $ connStr
$ ConnStrInfo .Type = " SQLAzure "
$ ConnStrSettings  = ( Get-AzureWebsite  $ projectName  - Slot " produzione " ) .ConnectionStrings
$ ConnStrSettings Add ( $ connStrInfo )
Set-AzureWebsite  - Nome $ projectName  - Slot " produzione "  - ConnectionStrings $ connStrSettings
# Sommario
" utente DB è: "  +  $ dbLoginName
" DB password è: "  +  $ dbPassword
visualizzare crudo CreateAzureResources.ps1 ospitato con ❤ da GitHub
Sembrano abbastanza facile? E ', e distruggendo tutto è altrettanto facile quindi ecco uno script per bombardare tutto ciò che avete appena creato in modo da poter giocare con lui poi rimuovere tutto ciò prima che colpisca la vostra linea di fondo:
# params ingresso
$ ProjectName  =  " TroyPSTest "

# Costanti
$ DbServerName  =  " snyb5o1pxk "
$ DbServerLogin  =  " troyhunt "
$ DbServerPassword  =  " P @ ssw0rd "
$ ApiVersion  =  " 2014/04/01 "

# Computerizzata vars
$ DbName  =  $ projectName  +  " Db "
$ DbLogin  =  $ dbName  +  " Accedi "

# Passare al gestore risorse
Switch-AzureMode AzureResourceManager

# Togliere il tag dal sito
$ P  =  Get-AzureResource  - Nome $ projectName  - ResourceGroupName $ webResourceGroup  - ResourceType Microsoft.Web / siti - ApiVersion $ apiVersion
Set-AzureResource  - Nome $ projectName  - ResourceGroupName $ webResourceGroup  - ResourceType Microsoft.Web / siti - ApiVersion $ apiVersion  - PropertyObject $ p .Properties - Tags @ {}

# Togliere il tag dal DB
Set-AzureResource  - Nome $ dbName  - ResourceGroupName $ dbResourceGroup  - server ParentResource / $ dbServerName  - ResourceType Microsoft.Sql / server / database - ApiVersion $ apiVersion  - Tags @ {}

# Eliminare il tag (se si tenta di eliminare solo, potrebbe essere ancora attaccato alle risorse, anche se li hai già eliminato!)
Remove-AzureTag  - Nome progetto - Valore $ projectName  - Forza

• Assicurarsi si dà il via a modalità di gestione dei servizi
Switch-AzureMode AzureServiceManagement

# Eliminare il sito web
Rimuovere-AzureWebsite  $ projectName  - Forza

# Eliminare il database
Remove-AzureSqlDatabase  - ServerName $ dbServerName  - DatabaseName $ dbName  - Forza

# Eliminare il login SQL
Import-Module SQLPS - DisableNameChecking
$ Conn  =  New-Object System.Data.SqlClient.SqlConnection
$ Conn .ConnectionString =  " Server = tcp: "  +  $ dbServerName  +  " .database.windows.net; Database = padrone, User ID = "  +  $ dbServerLogin  +  " ; Password = "  +  $ dbServerPassword  +  " ; "
$ Srv  =  New-Object  " Microsoft.SqlServer.Management.Smo.Server "  $ conn
$ SRV .Logins [ $ dbLogin ] .Drop ()
visualizzare crudo DeleteAzureResources.ps1 ospitato con ❤ da GitHub
E questo è tutto - facile giusto ?!

Nessun commento:

Posta un commento