Integrating docker release management in TFS with webtests

TFS express 2017 provides free and fully integrated environment for continious integration and release management for docker windows containers. Post below only focuses on release management for docker containers via TFS and webtests produced by Visual Studio Enterprise edition.

My current setup of TFS build produces following artifacts available for release management.

  • docker-stack.yml

This file presented below provides information about build version of container image and in imagetag and additional information for running environment

  • tests folder with 3 files
    • local.testsettings
      • This file provides information which server webtest have to be running against

    • webtest1.webtest
      • This file provides actual steps which is tested

  • runtest.ps1
    • This file which performs 2 functions: waits for swarm manager to bring latest version of image up and then run webtests tests on those.

Release pipeline itself contains of 3 steps for each environment. Screenshot below for staging environment.

chrome_2017-07-27_15-13-27

First step is pushing newly built image to staging docker swarm. This step is using built-in Docker command tasks in TFS and passing information about swarm location and registry connection via built in TFS properties along with docker-stack.yml file above.

chrome_2017-07-27_15-17-31

Second step is powershell script named runtest.ps1above. Variables  are passed to script to specify which server needs to be checked against as well current version of new build version of docker image

chrome_2017-07-27_15-20-09

Last step is publishing results of those tests

chrome_2017-07-27_15-21-52

Below is screenshot what failure in webtest looks like. Along with failure also attached webtestresult file which you can open in Visual Studio to inspect details of what has failed.

chrome_2017-07-27_15-25-25

Please note to enable test run you need to have mstest.exe installed on TFS agent as part of Visual Studio Enterprise 2017 installation. You can use Evaluation Version to install it. Test will fail otherwise with File extension specified .webtest is not a valid test extension.

Another thing to note is that there is currently a bug in TFS 2017 U2 which does not properly pull results form TRX file and hence additional logic was added to powershell script to put results in correct location to Publish Test Results tag can find results.

 

Advertisements

Comparing windows containers CPU perfomance vs alternatives

When presenting containers solution to wider audience question of perfomance invariably comes to place (the same sort of discussion everybody had 10 years ago during virtualization craze). I decided to do unscientific test of running Windows containers vs alternatives. Specifically windows containers are compared against running the same application on physical hardware, inside Hyper-V VM on the same hardware as well as windows containers in process and hypervisolation modes.

You can check results by yourself as image is posted at artisticcheese\iis on docker hub.

Code which is used for testing is designed to return PI number calculates to certain number which is very CPU intensive operation. In my specific run I was calculating to 8000s place with total of 100 requests in multithreaded client.

Client code is below, which is powershell code relying on runspaces via PSParallel module


#requires -Modules PSParallel
Measure-command {1..100 | Invoke-Parallel -ScriptBlock
{Invoke-WebRequest http://localhost/service.svc/pi/8000 -UseBasicParsing}}

Below are results of running this tests against 4 different environments

Test environment Hyper-V Hardware Process Isolation HyperV isolation
96.47 90.12 90.77 91.4
97.12 90.13 90.86 90.24
97.87 89.27 90.49 91.3

Conclusion may be surprising or may be not but running Windows containers introduce virtually no overhead from CPU point of view on application perfomance.

Replacing ServiceMonitor.exe with IIS error log events in windows IIS container

ServiceMonitor.exe is used as default ENTRYPOINT entry official Microsoft IIS build. It does not seem to be doing much except for checking if service W3SVC is running. There is multitude of issues with this EXE based on github (https://github.com/Microsoft/iis-docker/issues). Bearing in mind very limited functionality that this EXE provides I decided it to replace with something more useful.
Starting with IIS 8.5 it’s possible to output IIS logs not only to log files but also to ETW events. You can consume those inside eventlog name called Microsoft-Windows-IIS-Logging/Logs which shall be enabled to receive those events. Steps below will allow to provide output of all errors being logged on your webserver to docker logs instead of default ENTRYPOINT of IIS image which does not provide any valuable information.
I also decided to start my images now in servercore instead of IIS since latter only installs WindowsFeature Web-Server and creates ENTRYPOINT for ServiceMonitor.exe. Neither of which is really necessary anyway.
To accomplish this 2 things would need to be changed in base Microsoft image.

  1. Enable IIS to log to ETW (in addition or insted of file logging)
  2. Enable log called Microsoft-IIS-Logging/logs

Step number 1 is accomplished by executing following powershell

Import-module WebAdministration
$splat = @{
    pspath = "MACHINE/WEBROOT/APPHOST"
    filter = "system.applicationHost/sites/siteDefaults/logFile"
    name =  "logTargetW3C"
    value = "File,ETW"
}
Set-WebConfigurationProperty @splat

Step 2 is below

$IISOpsLog = Get-WinEvent -ListLog Microsoft-IIS-Logging/logs
$IISOpsLog.IsEnabled = "true"
$IISOpsLog.SaveChanges()

Both entries are made inside website_config.ps1 file in artifacts directory.

This setup will output ETW events to Microsoft-IIS-Logging/logs which will be repeatadly read in powershell script called entrypoint.ps1 below

$VerbosePreference = "ignore"
$sleep = 5
while ($true)
{
    $datediff = (New-TimeSpan -Seconds $sleep).TotalMilliseconds
    $filter = "*/System/TimeCreated[timediff(@SystemTime) <= $datediff] and *[EventData/Data[@Name='sc-status'] >'400']"
    Get-WinEvent -MaxEvents 10 -FilterXPath $filter -ProviderName "Microsoft-Windows-IIS-Logging" -ErrorAction SilentlyContinue | 
    Select-Object @{Name = "time"; e = {$_.Properties[2].value}}, @{Name = "VERB"; e = {$_.Properties[8].value}}, 
    @{Name = "ClientIP"; e = {$_.Properties[3].value}}, @{Name = "URI"; e = {$_.Properties[9].value}}, 
    @{Name = "Query"; e = {$_.Properties[10].value}}, @{Name = "Status"; e = {$_.Properties[11].value}}, 
    @{Name = "host"; e = {$_.Properties[21].value}} | Format-Table
    Start-Sleep $sleep
}

I restrict number of events returned by query at source based on time since last request as well as only for specific eventcodes which identifies Web Server errors (status codes > 400)

The last step is to put this script into ENTRYPOINT in DOCKERFILE

ENTRYPOINT powershell.exe C:\startup\entrypoint.ps1

Entire code base along with additional files is available on Github page (https://github.com/artisticcheese/IISadmin)
Image on dockerhub is (https://hub.docker.com/r/artisticcheese/iis-admin/)

You can test functionality below

docker run -it artisticcheese/iis-admin

Issue request to non-existent file to local container

invoke-webrequest http://172.30.163.51/asda

You will see output in stdout of container

time     VERB ClientIP     URI   Query Status host         
----     ---- --------     ---   ----- ------ ----         
18:28:08 GET  172.30.160.1 /asda -        404 172.30.163.51