Installation og vedligehold

Transkript

1 Installation og vedligehold Praktikportal projektet, oktober 2014 Version 1.0 Systemdokumentation - Praktikportal, side 1 af 51

2 Revisionshistorie Version Dato Ansvarlig Beskrivelse Phillip Lemonakis Dokument oprettet Lars Christensen Tilføjet detaljer om WebService API Jon Odgaard Tilføjet ACS delen fra separat dokument WAYF delen fra systemdokumentation Systemdokumentation - Praktikportal, side 2 af 51

3 Indhold Revisionshistorie... 2 Indledning... 5 Systemkrav... 6 Krav til løsningen... 6 Hardware krav... 6 Installation... 7 Deploy 7 Deploy af WebService API...11 Autoscale regel i Azure...11 ReCaptcha nøgler...12 Krav til indeksering af metadata og fremsøgning Om VM erne...12 Installation af Elastic Search...14 IIS Rewrites på Test, Demo og Undervisning...15 Elastic Search indexes...17 Disk alerts på Azure VM er...17 Andre alerts...19 Krav til Storage Accounts Azure Konfiguration...21 Navngivning...22 Krav til SQL server Hardware krav...22 Sql Logins...23 SQL brugeropsætning på Azure SQL...23 Krav til Bagrundsservices og PDFService Om Services...24 Azure Cloud Service Deploy How to...25 IP begrænsning...29 Systemdokumentation - Praktikportal, side 3 af 51

4 Praktikportal ACS...31 Kendte IDPer Ditmer...31 VIA...31 UCN...31 Miljøer 31 Tilkobling af ny IDP Start ACS Oprettelse af IDP Opret transform rule group Konfigurer relying pary WAYF...37 WAYF metadata og certifikater WAYF konfigurationsdel i web.config WAYF konfiguration i portalen Backup og restore...39 Azure SQL Restore How to Backup til Amazon S3 (Database og Storage) Database og blobstores...46 Elasticsearch indexfiler Storage backup/restore på Azure WebService API på Azure: Domæne URL registrering: Publicering af løsningens dele...48 Database WebSites WebService (API) Cloud Services (Worker) PDF Generator Cloud Service (Worker) Systemdokumentation - Praktikportal, side 4 af 51

5 Indledning I dette dokument er det beskrevet hvordan man installerer og drifter Praktikportalen. Det er en god idé at have læst Systemdokumentation som er et separat dokument samt at have set de til hørende Visio diagrammer som kan findes i roden af en given kodebranch under /Documents. Systemdokumentation - Praktikportal, side 5 af 51

6 Systemkrav Dette afsnit beskrives de software pakker der er nødvendige for at PRAKTIKPORTAL applikationen kan køre. Afsnittet er delt op i: Website Baggrundservices(som hvert udfører et servicejob) PDFService Indeksering og fremsøgning af metadata Storage accounts SQL-del WebService API Webserveren kører webdelen som brugerne interagerer med. Baggrundservices er opgaver der kører fast skeduleret logik og ex afvikler brugerimport oa. nødvendige dataintegrationer. PDFService er en service som kan levere PDF dokumenter af udvalgt data fra Praktikportalen, til download. Indeksering af metadata og fremsøgning er gennem en dedikeret Elastic Search server på en virtuel maskine, som bruges både af webdelen og af alle services til ex. logning af opgaver udført af baggrundservices, brugeradfærd i websitet mm. WebService API er et REST API, som udstiller data og funktioner til brug for eksterne systemer. Storage accounts er en Microsoft Azure term som er hvor vi læser/gemmer alt binært data der bruges af website eller services, og kan sidestilles med diskplads. Sqldelen kører databasen som er hvor alt data/metadata som website og services skal persistere (minus binært indhold som skrives til ovennævnte Storage accounts). Der er ved udvikling, test og deploy af PRAKTIKPORTAL version 1.0 truffet et valg om at hoste løsningen i Microsoft Azure som er en cloud baseret hosting provider. Visse systemkrav og termer relateret hertil bruger de ord og begreber som de hedder når man er logget på Azure som bruger i deres Admin GUI. Krav til løsningen Hardware krav Sitet skal køre min. på en Windows Server 2012 Server, skulle man installere det fysisk. I Azure styrer vi ikke det underliggende OS og blogs indikerer at man får det nyeste kompatible og ergo ikke skal bekymre sig om værtens OS(som jo er en af fordelene ved Cloud hosting) Sitet i Azure har Web hosting Plan mode: Standard(ses under Website, Scale menupkt) Det skal kunne autoscale således at i takt med at load øges gennem flere samtidige brugere, flere websites automatisk startes op for at svare på et brugerrequest* Systemdokumentation - Praktikportal, side 6 af 51

7 Sitet er konfigureret til at bruge (i Azure ses alt på Configure siden).net Framework: min. version 4.5 Managed Pipeline Mode: Integrated Platform: 64bit. Der er installeret gyldigt SSL certifikat: *.ucpraktikportal.dk for Test/Demo/Undervisning og ucpraktikportal.dk for Drift Sitet er bundet til den ønskede DNS. * Måden Azure løser scaling på er gennem Autoscale regler. Læs mere herom i afnittet Autoscale i Azure. Installation Et website i Praktikportalen kan skabes gennem Azure Quick create som beskrevet her: Man kan også lade Visual Studio oprette det første gang til et nyt miljø men skal huske at konfigurere det som beskrevet ovenfor i Krav til Websitet. Deploy Forudsætning Det er en forudsætning at man har udlæst seneste kode fra den kodebranch man ønsker at deployere, via Visual Studio og ser at al kode kan kompilere lokalt først. I skrivende er den seneste branch: delleverance1. Dette skal verificeres før man påbegynder en deploy således at det er den seneste stabile kode og ikke udviklingskoden der sættes i produktion. Måder at deployere Der er 2 måder at deployere selve koden fra WebUI projektet til et givent miljø i Azure. Deploy via Publish Profiles i Visual Studio Deploy via en lokal.bat fil i roden af kildekoden. Inden Deploy handlingen kan man enten gå gennem en manuel procedure hvor man opretter de sites de skal deployeres og dernæst deployerer første gang eller lade Visual Studio wizard udføre handlingerne og oprette sitet i én og samme process. Der skal stadig udføres en konfiguration som beskrevet ovenfor for at overholde kravene til websitet. Deploy via Publish Profiles i Visual Studio 1. Åbn Visual Studio og Vælg WebUI projektet: Systemdokumentation - Praktikportal, side 7 af 51

8 2. I vinduespanelet Web Publish Activity vælger du den ønskede Publish Profil som ved navnekonvention er døbt: AzurePraktikportal<miljøNavn>.pubxml. Herunder er der vist at man har valgt Drift som det miljø man ønsker at deployere til: 3. Klik på Publish Web ikonet for at udføre deploy: Systemdokumentation - Praktikportal, side 8 af 51

9 4. Følg resten af denne deploy guide: Deploy via en lokal.bat fil Når du har fundet roden af den lokale kildekode struktur som i dette ex viser den kodebranch som hedder Trunk: Systemdokumentation - Praktikportal, side 9 af 51

10 Skal du i en kommando prompt afvikle den fil der svarer til det miljø du vil have deployeret til i Azure. 1. Åbn en cmd i roden ved at skrive cmd i adresselinien i Windows Stifinder Systemdokumentation - Praktikportal, side 10 af 51

11 2. Skriv navnet på det miljø du ønsker at deployere til. Som i dette ex. er det Drift som er valgt: 3. Tryk Enter og se at der ikke udskrives noget i rød tekst som indikerer at der skete fejl og at website ergo ikke er deployeret. Deploy af WebService API WebService API deployes på samme måde som beskrevet for WebSitet med bat filer. Batfilerne ligger samme sted, som batfilerne for WebSitet. De hedder: DeployDemoWebService.bat DeployDriftWebService.bat DeployTestWebService.bat og DeployUndervisningWebService.bat Autoscale regel i Azure Der er lavet autoscale regler i Azure som har en Scale up rule metrik og en Scale down rule metrik på websites som bruger Autoscale (som er alle i Praktikportalen). Dvs. man har sat den Scale up metrik som over en defineret periode måler på hvordan load har været og skyder det antal websites i luften som man maksimalt ønsker, for at kunne håndtere nuværende brugerload. Tilsvarende køler Scale down metrikken websites ned til det minimumsantal websites som der er konfigureret, når cooldown reglen er indfriet. Bemærk at disse regler skal konfigureres gennem den nyeste Azure Preview Portal: Der kan kun laves simple regler og metrikker for Autoscale på instanser af website(hvor mange min og max) og den metrik som Azure måler på over tid som er % CPU brugt over tid i den gamle Azure portal: så brug nyeste Azure Preview Portal til dette formål. Som ex. som Scale up rule bruger Driften bruger mellem min 2 og max 4 websites, med en target CPU på max 80% i min. seneste 5 min, som efter målinger/anbefalinger menes at kunne håndtere et realistisk højt antal brugere som defineret i udbuddet og løsningsbeskrivelsen af Praktikportalen. Scale down rule metrikken er sat til det modsatte i CPU forbrug med en max på 60%, som så ergo er nedadgående dog over noget længere tid dvs. 120 min(for ikke at have sites til at stå og skalere op og ned ved blandet load som i sig er forbundet med et vist overhead i Azure). Systemdokumentation - Praktikportal, side 11 af 51

12 Praktikportal websites, Demo, Test og Undervisning sites er konfigureret med andre regler som er hurtigere til at skalere men hvor der ikke forventes samme load og derfor kun har mellem 1 og 3 sites til skalering. ReCaptcha nøgler Til validering af human input ved oprettelse af nye Praktikinstutionsforespørgsler på forsiden, bruges der en CAPTCHA validering fra Google kaldt recaptcha. Læs mere om funktionen her Kort fortalt så skal brugeren skrive den visuelle nøgle som man ser, som tekst for at formvalideringen bliver en succes. Der er oprettet Google konti med login og passwords specifikt hertil som an ses i Ditmer Password Manager XP som Ditmer administrator under Ditmer Google account, eller kan udleveres efter forlangende og bevis på behørig adgang til oplysningerne. Når man logger ind med Praktikportalens Ditmer Google account kan man se de nøgler som websitet er konfigureret med til et givent miljø og svarer til disse to keys i web.config: recaptchaprivatekey recaptchapublickey Krav til indeksering af metadata og fremsøgning Om VM erne For at kunne facilitere en hurtig fulltext søgning på udvalgt metadata fra Praktikportalen samt alle typer logging incl. Fra Baggrundsservices, er der sat en Elastic Search Server op på en Azure Virtuel Maskine. Den virtuelle maskine giver Websitet og alle Baggrundsservices adgang til skrive og læse loggingdetaljer fra de index som er sat op i Elastis Search. De Azdure VHD diske som er tilgængelige ses herunder, prefixet med VM navnet: En VHD disk tilhører en bestemt Storage Account og bor fysisk i Blob storage container. Her ses den første disk markeret med blåt på billedet og har denne sti: Hvis du skal forbinde til VM en, for administration af serveren etc, gør du det gennem RDP (Remote Desktop), ved at markere VM et og klikke på Connect: Systemdokumentation - Praktikportal, side 12 af 51

13 Der er konfigureret en bruger ved navn ditmeradmin, pw kan du finde i PW manager Begge VM er er sat op ens op som flg. herunder. Azure Settings for Demo/Test/Undervisnings-miljø Systemdokumentation - Praktikportal, side 13 af 51

14 Azure Settings for Driftsmiljø Installation af Elastic Search I skrivende stund skal der min installeres og konfigureres en elasticsearch server. Selve konfigurationen handler om at der skal være porte åbne på serveren til administration og til datakommunikation. Drift bruger en default konfig under E:\WindowsServices\elasticsearch-1.3.1\config, hvor der findes to.yml filer som skal være der. YML er det filformat som Elastic Search gemmer sine konfigurationer i. Elastic Search hentes herfra og efter endt installation skal services køre som services som denne guide viser Fordi vi har tre instanser af Elastic Search på VM praktik-test server skal, IIS en konfigureres med URL Rewrites som beskrevet i IIS Rewrites på Test, Demo og Undervisning. Systemdokumentation - Praktikportal, side 14 af 51

15 IIS Rewrites på Test, Demo og Undervisning Der er lavet custom http URL Rewrites på Azure VM praktik-test således at man kan have en url for hver Elastics Search instans der peger på en custom porte og dermed have flere på samme server og undgå portnummeret i url en. I IIS en skal der være disse tre som modsvarer det portnummer som den konkrete Elastic Search instans lytter på; konfiguret i instansens Elastic Search config fil E:\WindowsServices\elasticsearch \config\elasticsearch.yml Her ses de 3 regler oprettet i IIS: Systemdokumentation - Praktikportal, side 15 af 51

16 Og her er en af reglerne, som i dette tilfælde er den som peger på Test Elastic Search instansen: Som det fremgår er der angivet det den regex der matcher alle url som starter med <hostnavn>/test og en rewrite til det portnummer som Elastic Search instansen lytter på. Hver Elastic Search instans på test VM har sit eget cluster.name da de befinder sig på fælles vlan og broadcaster her. Drift er på sit eget vlan(via egen Azure Subscription). Systemdokumentation - Praktikportal, side 16 af 51

17 Elastic Search indexes I skrivende stund arbejder vi med disse index som skabes af websitet og baggrundsservices: Koden sørger for oprettelse af dem og man skal ikke konfigurere noget vedr index i Elastic Search konfig filer. Disk alerts på Azure VM er Der er sat en custom diskforbrugs-alert op på vore VM: praktik-test og ditmer002 Der er lavet en user defined performance counter kaldt DiskUsage, en Scheduled Task kaldt 'Send disk alert' og et powershell script kaldt 'SendDiskAlertMail.ps1', som kan sende beskeder med event data ved overløb af forbrugsgrænsen på diske på vores VM'er. Forbrugsgrænsen er i skrivende defineret som 'mindre end 10 gb' og vil sende en mail hvis denne er overskredet på OS og Data disken. PS scriptet er lavet således at det sender en mail med event data fra "Microsoft-Windows-Diagnosis- PLA/Operational" event loggen. Der er konkrete SendGrid smtp server / accounts/pw som skal rettes til. Se kommentarer i scriptet som Ligger i roden af Documents på VM'et for ditmeradmin brugeren. Herunder er de Windows Performance Counter, Scheduled Task og PS script templates som kan indlæses og SKAL rettes til hvis man ønsker at bruge dem på andre VM'er for fremtiden. Performance Counter XML, som kan importeres, import dialogen tager selv højde for forskelle i maskin navne osv.: <?xml version="1.0" encoding="utf- 16"?><DataCollectorSet><Status>1</Status><Duration>0</Duration><Description> </Description><DescriptionUnresolved> </DescriptionUnresolved><DisplayName> </DisplayName><DisplayNameUnresolved> </DisplayNameUnresolved><SchedulesEnabled>- 1</SchedulesEnabled><LatestOutputLocation>C:\PerfLogs\Admin\DiskUsage\PRAKTIK-TEST_ </LatestOutputLocation><Name>DiskUsage</Name><OutputLocation>C:\PerfLogs\Admin\DiskUsage\PRAKT IK-TEST_ Systemdokumentation - Praktikportal, side 17 af 51

18 000015</OutputLocation><RootPath>%systemdrive%\PerfLogs\Admin\DiskUsage</RootPath><Segment>0</Segmen t><segmentmaxduration>0</segmentmaxduration><segmentmaxsize>0</segmentmaxsize><serialnumber>15</seri alnumber><server> </Server><Subdirectory> </Subdirectory><SubdirectoryFormat>3</SubdirectoryFormat><SubdirectoryFormatPattern>yyyyMMdd\- NNNNNN</SubdirectoryFormatPattern><Task> </Task><TaskRunAsSelf>0</TaskRunAsSelf><TaskArguments> </TaskArguments><TaskUserTextArguments> </TaskUserTextArguments><UserAccount>SYSTEM</UserAccount><Security>O:BAG:S D:AI(A;;FA;;;SY)(A;;FA;;;BA)(A;;FR;;;LU)(A;;0x1301ff;;;S )(A;;FR;;;SY)(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200ab;;;LU)(A;ID;FR;;;AU)(A;ID;FR;;;LS)(A ;ID;FR;;;NS)</Security><StopOnCompletion>0</StopOnCompletion><AlertDataCollector><DataCollectorType> 3</DataCollectorType><Name>DataCollector01</Name><Alert>\LogicalDisk(E:)\Free Megabytes<10000</Alert><Alert>\LogicalDisk(C:)\Free Megabytes<10000</Alert><AlertDisplayName>\LogicalDisk(E:)\Free Megabytes<10000</AlertDisplayName><AlertDisplayName>\LogicalDisk(C:)\Free Megabytes<10000</AlertDisplayName><EventLog>-1</EventLog><SampleInterval>3600</SampleInterval><Task> </Task><TaskRunAsSelf>0</TaskRunAsSelf><TaskArguments> </TaskArguments><TaskUserTextArguments> </TaskUserTextArguments><TriggerDataCollectorSet> </TriggerDataCollectorSet></AlertDataCollector><DataManager><Enabled>0</Enabled><CheckBeforeRunning> 0</CheckBeforeRunning><MinFreeDisk>0</MinFreeDisk><MaxSize>0</MaxSize><MaxFolderCount>0</MaxFolderCo unt><resourcepolicy>0</resourcepolicy><reportfilename>report.html</reportfilename><ruletargetfilenam e>report.xml</ruletargetfilename><eventsfilename> </EventsFileName></DataManager></DataCollectorSet> Scheduled Task definition der trigger på den Performance Counter oven for: <?xml version="1.0" encoding="utf-16"?><task xmlns=" ver- sion="1.2"><registrationinfo><date> t19:39: </date><author>praktik- TEST\ditmeradmin</Author></RegistrationInfo><Triggers><EventTrigger><Enabled>true</Enabled><Subscrip tion><querylist><query Id="0" Path="Microsoft-Windows-Diagnosis-PLA/Operational"><Select Diagnosis-PLA'] and EventID=2031]]</Select></Query></QueryList></Subscription></EventTrigger></Triggers><Principals><Princip al id="author"><userid>praktik- TEST\ditmeradmin</UserId><LogonType>InteractiveToken</LogonType><RunLevel>LeastPrivilege</RunLevel>< /Principal></Principals><Settings><MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy><Disal lowstartifonbatteries>true</disallowstartifonbatteries><stopifgoingonbatteries>true</stopifgoingonbatteries><allowhard Terminate>true</AllowHardTerminate><StartWhenAvailable>false</StartWhenAvailable><RunOnlyIfNetworkAvailab le>false</runonlyifnetworkavailable><idlesettings><stoponidleend>true</stoponidleend><restartonidle> false</restartonidle></idlesettings><allowstartondemand>true</allowstartondemand><enabled>true</enab led><hidden>false</hidden><runonlyifidle>false</runonlyifidle><waketorun>false</waketorun><execution TimeLimit>P3D</ExecutionTimeLimit><Priority>7</Priority></Settings><Actions Context="Author"><Exec><Command>C:\Users\ditmeradmin\Documents\SendDiskAlertMail.ps1</Command><Argument s>-windowstyle hidden</arguments></exec></actions></task> Send Mail PowerShell script som skal til rettes som anvist i de kommentarer skrevet i scriptet: #REQUIRES -Version 2.0 <#.SYNOPSIS Bruges til at sende admin alert s med, primært disk usage i scriptet er der konfigureret variabler med en mailserver, en modtager, en afsender, og et password der skal rettes til. Body text fra event loggen Systemdokumentation - Praktikportal, side 18 af 51

19 .EXAMPLE #> # variabler $subject = "praktik-test VM Disk Alert! - < 10gb" $from = 'azure_9cf5c8f5a396920b4f31e7d57e732b10@azure.com' $mailusername = 'azure_9cf5c8f5a396920b4f31e7d57e732b10@azure.com' $to = 'support-praktikportal.test@ditmer.dk' $smtp = 'smtp.sendgrid.net' $secpasswd = ConvertTo-SecureString '<indsæt_password_her>' -AsPlainText -Force #Grab latest event from specific log with diskusage event id: 2031 $eventdata = Get-WinEvent -LogName "Microsoft-Windows-Diagnosis-PLA/Operational" -Maxevents 1 Where {$_.id -eq '2031'} Format-List Out-String #Default body text if the latest event with id 2031 is not found as expected $body = 'Der var ikke noget i event loggen som forventet med event ID 2031 på denne liste: Microsoft-Windows-Diagnosis-PLA/Operational' if($eventdata){ } $body = $eventdata $mycreds = New-Object System.Management.Automation.PSCredential ($mailusername, $secpasswd) Send-MailMessage -To $to -From $from -Subject $subject -Body $body -Credential $mycreds -SmtpServer $smtp -port 587 -DeliveryNotificationOption Never BodyAsHtml Andre alerts Vedr. website trafik på Drift er der lavet en alert ved mere end 1000 requests de sidste 5 min. Se her: Auto Scaling af websites Systemdokumentation - Praktikportal, side 19 af 51

20 Krav til Storage Accounts Disse Azure Storage Accounts er steder hvor et VM, en service eller websitet gemmer data som binært indhold. I Praktikportalen bruges en storage account når vi gemmer billeder/dokumenter oa. metadata og tilgås igennem navn og en krypteret nøgle som skal være den primære nøgle der ses i Azure Management portalen når man ser egenskaber for den pågældende. Som ex fra en Storage account: I Websites WebUi web<miljø>.config for det pågældende miljø finder du de specifikke referencer. Også Bagrundsservices har disse accounts og nøgler konfigureret for kunne ex. synkronisere brugerbilleder oa. binært indhold i Azure. Her findes ref til dem i ServiceConfiguration.AzurePraktikportal<Miljønavn>.cscfg For Drift eksisterer der i skrivende stund disse storage accounts. Systemdokumentation - Praktikportal, side 20 af 51

21 Azure Konfiguration Fælles for alle Storage accounts som er døbt ucpraktikportal<miljønavn> og som bør have en binarystore container(der hvor PraktikPortalen gemmer data), er at de er sat op som flg. hvad angår tilgængelighed, Locally Redundant, Systemdokumentation - Praktikportal, side 21 af 51

22 og logging: Logging har en cirkulationslogik på 7 dage. Dette er gjort for at eliminere tvivl om handlinger udført både på Blobs såvel som selve containeren. Der er ikke logging på diske som bruges af VM erne ex ditmer002 og praktik-test. Navngivning Der er tilsvarende diske/binære containere sat op for Undervisning, Test og Demo som også følger navngivningssyntaksen: ucpraktikportal<miljønavn> Bemærk at den storage account der bruges til Undervisning er trunkeret og hedder ucpraktikportalundervisn pga. en max længde restriktion i Azure. Gælder ligeledes for ppworkerstorageundervis(bruges af en baggrundsservice). Krav til SQL server Hardware krav Da løsningen kører I Azure hvor man har taget udgangspunkt i forventet load/skalerbarhed/størrelse og prissætning er der truffet valg om en Standard Sql server database med Performance level Standard S1. Læs evt mere om Azure SQL server udgaver/performance og prissætning her som har influeret valget: Rent teknisk er der en db grænse på 250 gb, Point-In-Time-Restore mulighed 14 dage tilbage. Den tekniske formåen eller performancemåling er noget soim Microsoft kalder Database Throughput Units, disse er metrikker på CPU, Requests og Memory. Læs mere her om Azure SQl Database Levels og performance: Systemdokumentation - Praktikportal, side 22 af 51

23 Sql Logins Bruger konti til de 2 Azure sql servere: Test: cbhcp4rxye.database.windows.net og Drift: xa96megzqg.database.windows.net er oprettet i Ditmer Password Manager. Tjek under folderen Praktikportal/Azure hvor alt SQL login relateret skal ligge. Hvis man ikke er ansat hos Ditmer kan man få udleveret disse oplysninger mod forlangende og tjek af behørig adgang. SQL brugeropsætning på Azure SQL Der er lavet individuelle login for alle miljøer som matcher vores connectionstrenge i Praktikportal løsningen (config filer for hvert projekt i VS) Herunder er der 2 scripts som der skal bruges ved oprettelse og test af en ny bruger og dennes rettigheder VIGTIGT!!: husk at læse kommentarer i sql scripts for hvordan du forbinder korrekt til Azure SQL databasen ellers virker oprettelsen ikke som tiltænkt. Via scriptet 'Test_User_Kan_Insert_Delete_på_DB.sql' i kan du tjekke at der er permission til at indsætte data(læs også kommentarer heri for tilgang til den rigtige db, så test data også bliver slette igen). Ny_pp_bruger_sql_LÆS_KOMMENTARER.sql --Step 1: log på som ditmer_admin -- i Sql studio hvor connection option er sat til databasen; vigtigt! --svarer til dette men kræver en ny sql connection -- USE [master] /****** Object: User [ditmer_admin] Script Date: 09/29/ :35:07 ******/ -- hvis du er på test er der CREATE LOGIN [pp_drift] WITH password='' -- skriv pw fra pw manager GO --Step 2 - log på i Sql studio hvor connection option er sat til databasen du ønsker; vigtigt! --svarer til dette men kræver en ny sql connection -- man kan ikke bare bruge USE [ucpraktikportal-drift] CREATE USER [pp_drift] FOR LOGIN [pp_drift] GO -- Step:3 permissions EXEC sp_addrolemember 'db_owner', [pp_drift] --step4: evt hvis der skal andre roller på login og permissions, dette har vi ikke gjort på nogle endnu, ikke nødvendigt for brugeren --EXEC sp_addrolemember 'db_datareader', 'pp_drift'; --EXEC sp_addrolemember 'db_datawriter', 'pp_drift'; 'Test_User_Kan_Insert_Delete_på_DB.sql' Systemdokumentation - Praktikportal, side 23 af 51

24 -- ret db herunder til din ønskede eg. [ucpraktikportal-test] INSERT INTO [ucpraktikportal-undervisning].[dbo].[saerligekrav] ([FeltNavnGuid]) VALUES ('8689EC03-27C DB-88E02DD165B9') GO -- fjern db test data igen Delete from [ucpraktikportal-undervisning].[dbo].[saerligekrav] where FeltNavnGuid = '8689EC03-27C DB-88E02DD165B9' Krav til Bagrundsservices og PDFService Om Services Der er lavet 2 projekter i Visual Studio som er som er Azure Cloud Services: PraktikPortal.PDFServiceWorkerRole, som er den service Praktikportalens website kalder for at samle dokumenter til en PDF og PraktikportalAzureWorkerRole, som er alle vores baggrundservices. Disse er Azure Cloud Services Worker roles som kan sidestilles med en Azure Virtuel maskine som ikke har en webserver installeret. Man skal i skrivende stund deployere service fra Visual Studio 2013 når man ønsker at publicere koden til Praktikportalen. Alle Cloud Service projekter skal deployeres i hånden, inde fra Visual Studio. Alle miljø definitioner har hver deres Publish Profil (Azure kalder dem TargetProfiler) og deres service definition navngivet efter miljø eg. ServiceConfiguration.AzurePraktikportal<MiljøNavn>.cscfg og ligger i Azure projekt typen. Herunder ses PdfService projektets konfiguration med tilhørende Worker Role: og Baggrundsservices: Systemdokumentation - Praktikportal, side 24 af 51

25 Settings definitioner fælles for hver deploy profile/servicekonfiguration er generet via Properties som her: Azure Cloud Service Deploy How to Herunder er en generisk måde at tjekke det rigtige kommer ud i selve Publish dialogen gennem Visual Studio. Sign In, Vælg din Subscription - den bruger som kun kan rette i Praktikportal Drift eller Test/Demo/Undervisning eg: <initialer>@infoditmer.onmicrosoft.com Systemdokumentation - Praktikportal, side 25 af 51

26 Tjek Common Settings er som de bør være - her er det den konkrete Cloud Service der hører til hvert miljø: Systemdokumentation - Praktikportal, side 26 af 51

27 Tjek at Advanced Settings er som de bør være - her inkluderer det den storage account der hører til hvert miljø: Systemdokumentation - Praktikportal, side 27 af 51

28 Tjek på den sidste side i Publish dialogen at der er ikke er røde krydser eller noget der ikke hedder drift som indikerer det ikke er korrekt. Publicer og se at det resulterer i Succes - ellers er der oftest fine fejlbeskeder som kan hjælpe dig videre ved at expandere Publish resultatet på trekant til venstre for Publish handlingen: Systemdokumentation - Praktikportal, side 28 af 51

29 IP begrænsning Baggrund Der er lavet 4 Cloud Services som er vores Bagrundssservices som skal bindes på en statisk IP for at få lov til at trække data fra UC FMD(UC data integration, I skrivende stund er disse de aktive IP er i Azure som tillades at kontakte UC FMD: ReservedIPName: PP_DriftWorkerServiceIP Address: Id: d d34-a699-eef9ed Label: PP_DriftWorkerServiceIP bruges til Drift baggrundservices Location: North Europe ReservedIPName: PP_DemoWorkerServiceIP Address: Id: 2eb6d862-66d7-460a-a43c-337f c Label: PP_DemoWorkerServiceIP bruges til Demo baggrundservices Location: North Europe ReservedIPName: PP_TestWorkerServiceIP Address: Id: 9f0c4ecc a93c-85254d503b44 Label: PP_TestWorkerServiceIP bruges til Test baggrundservices Location: North Europe ReservedIPName: PP_UndervisningWorkerServiceIP Address: Id: dd973c21-93b8-44f0-ac2b-8bc7061b3db7 Label: PP_UndervisningWorkerServiceIP bruges til Undervisning baggrundservices Location: North Europe 3 af disse, demo, test og undervisning tilhører den ene Azure Subscription som hedder "Ditmer - Professionshøjskolerne - Praktikportal TestDemoUndervis". Drift er bundet op på denne subscription, "Ditmer - Professionshøjskolerne - Praktikportal". Det er vigtigt at de reserverede IP'er(se afsnit om Opret og vedligehold) er lavet til den ønskede subscription ellers kan man ikke deployere og binde IP in den VM som en Cloud Service kører under. Opret og vedligehold Administration af reserverede IP sker gennem Azure Powershell/se dette for syntax: og der er en gotcha/noget man skal være opmærksom på ved oprettelse: For at have adgang til dit miljø/din subscriptions skal du importere en settings fil i Azure PS, se denne vejledning: Systemdokumentation - Praktikportal, side 29 af 51

30 og følg 'To download and import publish settings and subscription information'. Tjek at der nu ikke er flere subscriptions end dem du rent faktisk ønsker i: "C:\Users\<dit windows brugernavn>\appdata\roaming\windows Azure Powershell\AzureProfile.json" her gemmes alle subscriptions som der importeres under en session og hver gang du laver en settings import! Sæt den ønskede subscription (hvis ikke du kun har én i din profil, se ovenfor) eg: Select-AzureSubscription -SubscriptionName "Ditmer - Professionshøjskolerne - Praktikportal" Vigtigt: her er det det SubscriptionName miljø strengen som er den key man skal vælge sin aktive subscription med. Lav et tjek for at være sikker på at du har valgt den ønskede subscription i din PS session: Get-AzureSubscription Der skal stå IsCurrent: true ud for den ønskede subscription, så er du sikker på at der bindes IP til denne. Reserver en ny IP: New-AzureReservedIP ReservedIPName "<SpecificNameKey>" Label "<forklarings_tekst>" Location "North Europe" <SpecificNameKey> er den nøgle du skal indsætte i ServiceConfiguration senere ved Publish. Tjek at du kan se den med: Get-AzureReservedIP - kan du ikke se en IP du mener at have oprettet tilhører den en anden subscription og du skal slette IP'en og starte på denne opskrift igen. Selve binding mellem din Cloud Service og IP'en sker kun ved nye services og kan ikke laves efter en CS er blevet skabt. Heldigvis kan alt ske gennem Publish i Visual Studio. En Cloud Service skal indeholde denne section i sin ServiceConfiguration for at bruge den IP du ønsker, så før Publish sikr dig at dette eksisterer: <NetworkConfiguration> <AddressAssignments> <ReservedIPs> <ReservedIP name="<specificnamekey>"/> </ReservedIPs> </AddressAssignments> </NetworkConfiguration> Udfør Publish og lav evt din storage account direkte i dialogen hvis denne ikke eksisterer(der hvor VM/Service filer gemmes for den pågældende Cloud Service). Systemdokumentation - Praktikportal, side 30 af 51

31 Publicer og se at det går godt; dobbelttjek med at se din Cloud Service har den ønskede IP på Dashboard siden i Azure portalen. Praktikportal ACS Kendte IDPer Her er listen med de pt. kendte IDPers metadata endpoints og test brugere Ditmer Metadata: Bemærk: Vi har, viser det sig, åbentbart ikke åbnet så man udefra er i stand til at få fat i metadata (hvilket ikke giver nogen som helst mening). Derfor download metadata lokalt og upload metadata filen. VIA Metadata: Test brugere: Teststud5@via.dk Teststud6@via.dk Teststud7@via.dk Password: Abc12345 UCN Metadata: Test bruger: Username: praktikportaltest Password: Qwerty1! Miljøer Her er listen med site URLs og metadata endpoints for de fire Praktikportal miljøer Miljø URL Federation metadata Demo l.dk/ onmetadata/ /federationmetadata.xml Undervisning ikportal.dk/ ederationmetadata/ /federationmetadata.xml Test dk ationmetadata/ /federationmetadata.xml Drift tadata/ /federationmetadata.xml Systemdokumentation - Praktikportal, side 31 af 51

32 Tilkobling af ny IDP I det følgende beskrives hvordan en ny IDP tilkobles til praktikportalens ACS server Start ACS Første skridt er at starte ACS management portalen. Det gøres lettest fra Azure management portalen ved at navigere til Active Directory fanen og derefter vælge fanen Access Control Namespaces Under fanen vælg det miljø du ønsker at administrere Tryk på Manage knappen i bunden af interfacet: Der bliver nu åbnet en ny fane med ACS management portalen for det miljø du valgte. Oprettelse af IDP Vælg menu punktet Identity providers i venstre side: Systemdokumentation - Praktikportal, side 32 af 51

33 Vælg Add for at påbegynde oprettelse af IDP: Vælg WS-Federation identity provider... og tryk på Next : Systemdokumentation - Praktikportal, side 33 af 51

34 Udfyld skemaet for den nye IDP. Eksempel: Display name er blot en itern beskrive af denne IDP. Vises ikke til slutbruger. WS-Federation metadata bør pege på URL hvor IDP udstiller sine metadata. Denne URL skaffes ved at kontakte den enkelte IDP. Til nød kan man uploade metadata filen modtaget fra IDP hvis dette endpoint ikke er udstillet. Dette er en dårlig måde at gøre det på, da det betyder at ændringer foretaget i IDP ens metadata manuelt skal distribueres til alle relying parties (dvs. bla. Praktikportalen) som så manuelt skal uploade dokumentet igen for hvert miljø der anvender IDPen. Login link text er teksten der vises til brugeren når listen med IDPer vises for brugeren. Image URL bør pege på URL hos IDP som giver et passende logo for denne IDP. Det er en god ide at have dette, da det er hurtigere at spotte et logo man kender. domain names bør efterlades tomt Relying party applications skal have flueben i det miljø som du er ved at konfigurere. Der er forhåbentligt kun et miljø da der skal være et namespace for hvert miljø. Systemdokumentation - Praktikportal, side 34 af 51

35 Opret transform rule group En transform rule group et et sæt instruktioner der beskriver hvordan claims modtaget fra IDPen skal oversættes til de claims som ACSen udsteder. Vælg Rule groups i venstre menu Vælg Add for at lave ny rule group Giv rule group et passende navn som inkluderer navnet på den IDP du er ved at tilkoble og tryk save Tryk på Generate for at påbegynde automatisk oprettelse af regelgrupper: Systemdokumentation - Praktikportal, side 35 af 51

36 Sæt hak ud for den IDP du oprettede i forrige trin og tryk Generate Der bliver nu oprettet en rule group der lader alle claims fra IDPen passere direkte igennem uden transformation. Konfigurer relying pary Nu mangler du bare at vælge at relying party (praktikportal miljøet) kan modtage claims fra IDPen Vælg Relying party applications fra menu i venstre side: Systemdokumentation - Praktikportal, side 36 af 51

37 Vælg den relying party der svarer til miljøet. Der bør kun være en relying party. Sæt flueben i regel gruppen du netop har oprettet og verificer der er flueben ud for den IDP du oprettede i starten. Nu skulle den nye IDP fungere WAYF Praktikportal er integreret med WAYF Til integration med WAYF bruger vi OIOSAML.NET som udvikles i under digitaliseringsstyrelsen og er af WAYF direktoratet den anbefalede måde at integrere fra.net til WAYF. Se: WAYF metadata og certifikater WAYF integrationen bruger et signing certifikat til at signere sinon requests til WAYF. Det er egentligt OIO- SAML der står for at foretage authentication og den kræver at signe requests, selv om WAYF egentligt ikke kræver det. Certifikaterne kan findes i web projektet under Wayf folderen. Der er et certifikat for hvert miljø. Metadata.xml filen i hvert miljøes mappe beskriver det endpoint hos WAYF som man skal forwarde signon requests til. Både metadata filen og certifikatet skal deployes sammen med løsningen. Da løsnigen kører i på Azure hvor man ikke umiddelbart har adgang til at installere egne certifikater i certificate store så er det nødvendigt at kunne hente certifikatet som en fil. Systemdokumentation - Praktikportal, side 37 af 51

38 Password til åbning af af pfx filen findes i readme.txt filen i hvert wayf miljøs mappe. WAYF konfigurationsdel i web.config Sektionerne <Federation> og <SAML20Federation> indeholder deklarative indstillinger for hvordan WAYF skal fungere. Nogle af indstillingerne er afhængige af hvilket miljø der er tale om: <SigningCertificate> har en attribut (findvalue) der beskriver thumbprint for det certifikat der anvendes til at signe authentication requests til WAYF. Thumbprint kan findes ved at inspicere signing certifikatet i WAYF folderen. <Audience> skal være absolut URL til det miljø der skal modtage en assertion fra WAYF. Svarer lidt til homerealm i WS-Trust scenarie. <ServiceProvider> har to attributter: 1) (id) som er det ID dette website (service provider) har når WAYF skal finde ud af hvilken SP der forsøger at authenticate mod dem. IDet skal svare til det ID man oprettede forbindelsen med i JANUS. 2) 2) (server) skal være URL til dette site (samme værdi som i <audience> attributten <IDPEndPoints> har attributten (metadata) som skal være den relative sti til folderen hvor metadatafilen for WAYF signon endpointet befinder sig. <IDPEndPoints>/<add> har attributten (id) som skal være URLen til WAYFs signon endpoint WAYF konfiguration i portalen Hvert UC har to indstillinger der kontrollerer hvordan integrationen til WAYF fungerer. WAYF identifier er en identifier som en authenticated bruger får med tilbage i assertion fra WAYF når vedkommende er authenticated. I overnstående er en bruger authenticated i orphanage som er en test IDP i WAYFs QA og drift miljø. WAYF IDP EntitytID bruges til at prævælge en IDP hos WAYF så bruger ikke først skal vælge blandt en meget lang liste hvilken IDP de ønsker at authenticate hos. Listen med entity ID er og WAYF identifier (schachomeorganization) kan hentes hos WAYF fra denne URL: Systemdokumentation - Praktikportal, side 38 af 51

39 Backup og restore Der skal foretages backup af både databaser og storage accounts. Der skal foretages daglig backup af databaser på SQL server. I Azure gøres det i faste i intervaller af sig selv når man har en SQL DB i sit miljø. Versionen af SQL databasen skal være basic, Standard, and Premium service for at understøtte Point in Time Restore. Læs mere herom: Der foretages fuld database backup en gang om ugen, differentiel database backups en gang om dagen, og transaction log backups hvert 5 minut. Den fulde og differentielle backup er replikeret på tværs af regioner for at sikre tilgængelighed af de forskellige backupsæt i tilfælde af en uoprettelig fejl i Sql databasen der kræver en restore. Læs mere her om Rentention Policy i Azure dvs. hvor langt tilbage i tid man kan restore en DB fra: Azure SQL Restore How to Der er lettest at restore via Azure Management portalen hvor der er en dialog til det. Det kan dog også gøres via Powershell men er noget mere involveret og gør brug af Azure Powershell cmdlets hertil. Læs mere om restore gennem Powershell her: Systemdokumentation - Praktikportal, side 39 af 51

40 Denne guide viser Restore gennem Azure Management portalen: Klik på Restore for den ønskede database. Systemdokumentation - Praktikportal, side 40 af 51

41 Næste dialog præsenterer dig for de restore valg i tid der er muligt: Systemdokumentation - Praktikportal, side 41 af 51

42 Vælg et restore point enten via slideren eller ved at vælge specifik dato og tid (husk der kan vælges helt ned til 5 min intervaller): Ex herpå: Databasen restores til en ny db med det navn der modsvarer den valgte dato tilbage i tid. Her i ex. får du en database der hedder ucpraktikportal-undervisning_ t11-00z på samme databaseserver som ucpraktikportal-undervisning. Systemdokumentation - Praktikportal, side 42 af 51

43 Når den er genetableret ser du den i portalen som ex. herunder, den viste db er fra et andet restore job og hedder derfor noget andet end det foregående ex men har samme navngivningssyntaks: NB!: Det er en god tommelfingerregel at tjekke den db du har genetableret ved at ad kigge/query på data du mener skal være der. Dette gør du gennem Sql Management Studio eller Azure Management portalen. For at gøre brug af denne database, skal vi have omdøbt den originale og den nye der er genetableret. Dette gøres gennem en forbindelse til SQL databasen enten Azure Management portalen eller Sql Management Studio med et brugerlogon som har ret til at fortage ændringer i master tabellen og dermed omdøbe. Pt. har ditmer_admin kun det. Ex herunder viser de kommandoer der skal bruges: Start med at stoppe website og services der gør brug af databasen for ikke at fremprovokere sql connection fejl. Systemdokumentation - Praktikportal, side 43 af 51

44 Omdøb den originale db som ikke længere er ok i produktionsøjemed. Udfør flg. i Sql Management Studio forbundet til master db som ditmer_admin@<servernavn>(denne rolle kan udføre database ændringer): Systemdokumentation - Praktikportal, side 44 af 51

45 Når du er forbundet kan du udføre dette ex. med den originale db fra produktion så vi kan restore til samme navn bagefter fra backup: ALTER DATABASE [ucpraktikportal-undervisning] MODIFY NAME = [ucpraktikportalundervisning_tobedeleted_ ] Nu vil du gerne omdøbe den genetablerede database til det originale db navn så den kan bruges i produktion: ALTER DATABASE [ucpraktikportal-undervisning_ t11-00z] MODIFY NAME = [ucpraktikportalundervisning] Her efter skal du nu have genstartet website og services du havde stoppet før du gik i gang med genetableringen. Nu skal du logge på Praktikportalen, i dette ex. er det undervisning.ucprakrikportal.dk, og se at alt virker som forventet. Systemdokumentation - Praktikportal, side 45 af 51

46 Backup til Amazon S3 (Database og Storage) Database og blobstores Vi anvender redgate cloud service til at tage backup af database og blobstores. Backupen bliver placeret i en Amazon S3 bucket. Redgate servicen kan desuden bruges til at restore database og blobstores igen. Servicen kan tilgås på URL en: Der er sat to jobs op, der henholdsvis tager backup af database og blobstores til hver deres S3 bucket: Amazon web servicen S3 kan tilgås på følgende URL: vælg Sign in to the console for at få adgang til alle AWS services, heriblandt S3: Brugernavn og password til de forskellige accounts kan findes i password manager under Praktikportal folderen. Elasticsearch indexfiler Til backup afelasticsearchs indexfiler anvendes en Microsoft agent som taler med Azures Recovery Services: Backup agenten kan hentes fra recovery services dashboardet: Systemdokumentation - Praktikportal, side 46 af 51

47 Agenten installeres på den maskine man ønsker at tage backup af. Agenten er naturligvis installeret på den maskine hvor elasticsearch er installeret og tager backup af index folderen. På desktoppen ligger shortcut til agenten: Storage backup/restore på Azure Storage bliver udenlukkende kopieret over til Amazon S3. Vi bruger ikke Azure egne metoder til storage backup. Der er dog undersøgt muligheder for storage backup på Azure. Læs i øvrigt om backup/restore af storage indenfor Azure: You can copy a snapshot over its base blob. By promoting a snapshot to the position of the base blob, you can restore an earlier version of a blob. WebService API på Azure: Der er oprettet 4 separate WebSites til API et. Alle websites er sat op til SLL og DNS for subdomænerne er registreret hos DanDomain. Systemdokumentation - Praktikportal, side 47 af 51

48 Domæne URL registrering: ucpraktikportal.dk er registreret hos DanDomain.dk LAC og SLO har login til dandomain. Publicering af løsningens dele Afhængigt af hvilke(n) dele af systemet man har ændret, er der forskellige trin i at publicere ændringerne. Her følger en beskrivelse af, hvordan løsningens dele publiceres: Database Til brug for publicering af database ændringer bruges konfigurationsfiler, se figur 9. Efter ændringer er foretaget i en eller flere af sql filerne i database projektet, dobbeltklikker man på konfigurationsfilen for det miljø, som man vil publicere til. Herfra er det blot at trykke Publish det kræver selvfølgelig de nødvendige rettigheder. Ved denne publicering bliver både tabeller og indexes oprettet. Efter oprettelse af tabeller kører post-deployment scripts, som ses i figur 10. Disse post-scripts lægger initielle opstartsdata ind i nogle af tabellerne. Figur 1 - Publiceringskonfigurationer Systemdokumentation - Praktikportal, side 48 af 51

49 Figur 2 Tabel og postscript sql Systemdokumentation - Praktikportal, side 49 af 51

50 WebSites For at publicere websites, skal man køre den bat fil, som hører til det miljø, hvor man gerne vil publicere til. Se mulighederne her i figuren: Figur 3 Bat filer til publicering af websites WebService (API) For at publicere webservice API, skal man køre den bat fil, som hører til det miljø, hvor man gerne vil publicere til. Se mulighederne her i figuren: Cloud Services (Worker) For at publicere den worker, som afvikler cloud servicene, skal man højreklikke på Praktikportal.Jobs.Hosting.AzureWorkerRole i Solution Explorer. I dialogen der fremkommer, vælges det miljø, hvortil man ønsker at publicere. Se figuren her:

51 Figur 4 Publicering af Cloud Services workeren PDF Generator Cloud Service (Worker) For at publicere den worker som afvikler PDF Generator servicen, skal man højreklikke på PDF_CloudService og vælge publish. I dialogen der fremkommer, vælges det miljø, hvortil man ønsker at publicere. Se figuren her: Figur 5 Publicering af PDF Generator Cloud Service workeren Systemdokumentation - Praktikportal, side 51 af 51