DEV Community: Stafford Williams

Building a React Native pipeline for Android and iOS

Stafford Williams — Wed, 01 Apr 2020 04:17:00 +0000

Liquid syntax error: Unknown tag 'endraw'

An Azure Pipeline for Visual Studio Marketplace

Stafford Williams — Tue, 05 Nov 2019 08:50:49 +0000

In a previous post I built a custom Azure Pipeline release task and manually uploaded it to the Visual Studio Marketplace. In this post I’ll add new features and have DEV and PROD versions of the extension automatically deploy to the Marketplace on commit.

The source for this project is here and the diff for changes mentioned in this post is here.

Development and Release Versions

Initially I followed a colleague’s post on setting up a pipeline and this devblog from Microsoft in an attempt to have a dev (and prod) version of the release task. However, I later determined that there’s a difference between the extension that is defined and published by vss-extension.json and the (one or more) tasks that are packaged with the extension and defined by taskName/task.json. I could successfully push a unique-id extension to my existing publisher, but the deployment would then fail due to the marketplace already having an existing version of the task.

As such, the approach was to name and key both vss-extension.json (now renamed manifest-*.json) and task.json specifically for dev/prod. The core changes to achieve this result in a structure like this:

azure-pipelines-dev.yml # dev pipeline
azure-pipelines-release.yml # release pipeline
manifest-dev.json # dev extension definition
manifest-release.json # release extension definition
cloudflarePurge
  |-- task.json # dev & release task definition

NB: Actually manifest-dev.json and manifest-release.json could be merged and token-replaced similar to task.json.

The result is two extensions and their associated tasks:

Purge Cache for Cloudflare and;
Purge Cache for Cloudflare (Development)

The first is the existing, already published version, and the second is a brand new instance specifically for development and testing and with public: false set. The production instance continues to reflect and is now triggered from the master branch, and the new development instance is triggered from the dev branch.

Token Replacement

An immediate issue with my proposed pipeline was the difference in how vss-extension.json and task.json deal with version and how JSON variable substitution works within the standard File Transform task.

vss-extension.json

"version": "1.2.3"

task.json

"version": {
    "Major": 1,
    "Minor": 2,
    "Patch": 3
}

The solution proposed by microsoft was to split the two variable transforms across jobs. I’ll give this approach a go in the future, however for now I’ve just used a single job and token replacement.

This same token replacement is used for setting the name and id of the extension and task.

Build and deploy

Outside token-replacement the only steps in both dev/prod pipelines are;

Install node
Install dependencies
Compile typescript
Deploy to marketplace

We’ll use npm to install the dependencies and use npx to compile with typescript & deploy with tfx-cli. For the latter we’ll need a PAT from our Azure Devops tenant, instructions can be found here.

Note that before installing npm dependencies, it’s important to set the working directory to the task directory. Doing so installs dependencies adjacent to the task and ensures they are shipped with tfx-cli extension publish. Originally I had not done this, such that the extension was building and shipping without the dependencies, meaning users of the extension needed to npm install themself - my thanks to Patrycjusz Jaskurzyński who reported, and helped me diagnose, this issue.

Further differences

An issue with the previous version of the extension was that the provided icon was only visibile on the marketplace, but once installed into an Azure DevOps tenant, a default icon rather than the one supplied was visible when adding the task to a release pipeline.

Where vss-manifest.json defines an icons property, task.json does not, and instead by convention checks for icon.png in the same directory. Additionally some documentation indicates an icon size of 32x32 is required - this will however result in a lower quality image once installed as the icon will be scaled up in size. To resolve this supply the icon at 128x128.

Conclusion

The last thing I needed to do was actually install the new Development version of the extension. This is an entirely different extension as far as Visual Studio Marketplace is concerned, but I can have both of them installed on my single Azure Devops tenant. The dev version’s public: false property in the extension definition and --share-with myUserName in the pipeline defintion means only my Azure Devops tenant can see the development version. While developing and testing, I commit directly to the dev branch and the development version of the extension is deployed to the Visual Studio Marketplace and updated on my Azure Devops tenant. Once i’m satisfied, I merge dev into master, which triggers the production build & deploy.

As for the extension itself, now you can specify individual URLs instead of purging everything:

Monitoring the Web with Azure for Free

Stafford Williams — Wed, 25 Sep 2019 14:00:00 +0000

With the deprecation of Multi-step Web Testing in Visual Studio and Azure, what approach can we now use to monitoring web properties, especially if we don’t own them? In this post, I’ll propose and demonstrate the leveraging of Azure to provide us a solution to this problem at no-to-little cost.

Multi-step Web Test Deprecation

Announced here, this deprecation means that Visual Studio 2019 Enterprise will be the last version of Visual Studio to support Multi-step Web Test projects, and no replacement is currently being worked on. This enterprise-only feature was not overly enviable anyways considering these tests are HTTP-based only (no Javascript) and the pricing was pretty out there, for example West US 2 / AUD pricing is shown below.

Feature	Free units included	Price
Multi-step web tests	None	$13.73 per test per month
Ping web tests	Unlimited	Free

A Better Solution

I’m looking for a more modern solution with a feature set greater than what’s possible with Multi-step Web Tests. We’ll use Azure to host it, and if we go with the bare minimum then this solution can be entirely free. For a few cents a month we can add additional features that compliement the idea of monitoring web properties that might not be our own.

This solution is entirely opensource and available for free on GitHub. If you have ideas on how this solution could be improved, please let me know!

Browser Automation

To solve the core requirement of monitoring availability, request times and whether our single page applications are executing javascript correctly, we’ll use Selenium. We’ll control it with .net core, using plain old mstest which we (or more likely our automation) can run easily with dotnet test.

There’s plenty of guidance on writing tests with Selenium, and it’s good practice to use a Page Object Model approach when using Selenium. An example I’ve written loads up , navigates to the pricing page, and tests some assertions on what it finds using Shoudly.

I’m using ChromeDriver with Selenium, which we can pass further arguments to for example, to avoid tracking integrations like google analytics and to run headless so we can run it on linux vms without a graphical environment.

Running It In The Cloud

I need something to periodically run the above test project, and Azure DevOps is the free answer, with 1,800 free hosted build minutes per month. I can implement a build pipeline that will run the tests and email me the results. There’s even a dashboard widget to show how my tests have performed over the last 20 runs, including how long the run took and whether any tests failed.

The build pipeline configuration is pretty trivial. Whenever a build is triggered, a hosted linux agent will run the following steps;

Install dotnet core 2.2
Restore nuget packages
Build the project
Run the tests
Publish the result

Scheduling the build is also quite trivial, especially now that Azure Pipelines supports scheduling with cron syntax. Triggering every hour is as simple as the snippet below. Remember to set always: true so the build is triggered regardless of no change being committed to source.

schedules:
- cron: '0 * * * *'
  displayName: Hourly build
  branches:
    include:
    - master
  always: true

Cron schedules are fairly new to Azure Pipelines and were broken on my initial implementation. While the fix was coming through I instead used Logic Apps to schedule the build. Logic Apps already includes an Azure DevOps connector and a two step app was all that was required - a periodic recurrence and a build trigger. Now that Cron schedules are fixed however, the Logic Apps approach is no longer required.

Additionally, Cron schedules are only reliable if your Azure Devops tenant is in constant use. The docs explain that the tenant goes dormant after everyone has logged out - if this occurs to you, a Logic Apps approach will ensure your builds get triggered.

Storing the data

A great way for us to both store and query the data we’ll be collecting is to use Application Insights. Normally we’d use the Application Insights SDK to automagicially track our own website’s data - however as we’re monitoring other websites out on the internet, we’ll just include the Base API and use TelemetryClient directly.

I’ve written ApplicationInsights.cs as a wrapper around TelemetryClient, and it shows we’re sending Availability and Exception telemtry to Application Insights. Integrating this with our Selenium tests and configuring the Instrumentation Key results in our data being available for querying in the Azure Portal.

We can review up to 90 days of data in the portal, using Kusto to query and create charts. We can also query the data externally by using the Application Insights REST API and we’ll do so below to generate reports that will snapshot our prior to reaching the data rentention limit.

Notifications and Alarms

There’s two key events we want to be notified of:

Test failures and;
When the whole system is down and not monitoring.

Test failures are already being emailed by Azure DevOps, but the content of the email could be a lot better than this. We can extend the existing test project to build a summary of failures once all tests are complete. Even better, we can use Selenium to grab screenshots of the browser at the point of failure and include these images in the email.

We can detect that the whole system is down if our Application Insights instance has not received any new data in x minutes/hours. Originally I had used Azure Scheduler for this task, but it is deprecated and to be retired by the end of the year. As such, Logic Apps is our friend which we can use to query the same Application Insights REST API mentioned above and send an email should we detect no data.

Reporting

Periodically I’d like a summary of how these web properties have been performing, which would basically be a snapshot of the charts we already have generated above using Application Insights. However, Application Insights does not currently offer a way to periodically email these results, so we’ll write our own.

To do this, we’ll grab our raw telemetry data using the Application Insights REST API and we’ll ressurect Microsoft.Chart.Controls - a WinForms charting control for .NET Framework - to generate charts that look very similar to results we’ve seen in the portal. We’ll export these charts to .png, reference them in an HTML file we’ll build, and then attach them to a MailMessage for emailing. The result is an HTML formatted email delivered right to our email client.

Emailing

Throughout the above I’ve mentioned emails that we’re generating, but we’ll need something to actually send them, for example our good friend SMTP. To deliver this functionality for the cool price of free, we’ll use SendGrid which lets us send 100 emails/day at no cost - much more than we’ll need.

Conclusion

And that about wraps it up - we’ve seen that we can use a range of Azure services and integrations for free or very low cost to implement a fairly robust monitoring system. However, with the techniques described, we could expand or (totally) change this solution to meet close to any requirements we might have for running workloads in the cloud. I hope this overview has given you some ideas or helped you discover something new - if you can think of an improved way to implement the above or notice any errors please reach out!

Auto-scaling Azure SignalR Service with Logic Apps

Stafford Williams — Fri, 12 Jul 2019 14:00:00 +0000

Azure SignalR Service does not have auto-scale functionality out of the box. In this post I’ll implement my own auto-scaling using Azure Logic Apps.

Scaling Azure SignalR Service

Microsoft promotes Azure SignalR Service as a simple way to scale SignalR implementations, but how does the service itself scale? The answer is Units: for every Unit the Standard_S1 sku accepts another 1,000 concurrent connections. To scale, bump the Unit count to a maximum of 100 (100k concurrent connections) using the Azure Portal, CLI, Azure Powershell or REST API.

Some caveats here are that the service actually only accepts Unit counts of 1, 2, 5, 10, 20, 50, 100. You can’t set a Unit count of, say, 3 or 60. Additionally, pricing includes a per unit, per day factor, and this day includes part-thereof, such that if you set a unit count of 100 you’ll be charged 100 x $AUD2.21 for that day, even if you immediatly roll back to 1 unit. Pricing here is not consumption based.

Will it auto-scale?

I don’t want to scale it myself in the Portal, or by making remote calls, rather I’d like the service to auto-scale based on concurrent connection count, but the service does not offer this capability out of the box.

It doesn’t currently autoscale. Is it a blocker for you?

— Anthony Chu (@nthonyChu) July 6, 2019

As such, the driving forces of laziness and curiosity within me has led to the creation of a Logic App that will auto-scale SignalR Service for me, even if it’s not a great idea to do so.

Automate Azure with Logic Apps

The source and usage is here, but let’s take a look at what this Logic App is doing.

Logic Apps doesn’t have a connector available for SignalR Service, so instead we’ll use the Azure REST API to query and modify it. There’s three REST end points we’re interested in;

GET monitor/metrics/list to query how many concurrent connections there are
GET signalr/get to query the current Unit setting and;
PUT signalr/createorupdate to update the unit count.

Everything else in the Logic App are then steps to determine whether we need to call the PUT above and what Unit count we’ll set if we do.

How many connections until we scale?

The formula I’m using to determine the number of units we need is as follows:

(CurrentConnections + BaseConnections + Buffer) / ConnectionsPerUnit

where:

CurrentConnections is the maximum connections connected at any time since the last run
BaseConnections reflects that we’ll always need at least 1 unit regardless of connection count
Buffer is how close to the maximum connections per unit we’ll get before scaling. I set this to 100 initially so, for example, reaching 900 connections would add another unit. After testing showed that limits are soft and counts would go up to 10% over, so probably this could be closer to, or just 0.
ConnectionsPerUnit = 1000

The formula produces an ideal Unit count, however Azure SignalR Service allows us only Unit counts of 1, 2, 5, 10, 20, 50 or 100, so we’ll choose one that’s greater or equal to our ideal count. As a side note, I also found during testing that 0 is a valid unit count, however doing so blocks both clients and servers from connecting to the service.

Scaling up and down

Once we’ve determined what unit count we need, we’ll compare it to what the current SignalR Service unit count is. If they are equal, then there’s nothing more to do. If they’re different, we’ll call the createorupdate endpoint with our new unit count, at which time the service will reload, disconnecting all current connections with the following HubException:

Connection terminated with error: Microsoft.AspNetCore.SignalR.HubException: The server closed the connection with the following error: ServiceReload

Whilst disconnection sounds alarming, this happens often enough in practice that client applications should already have re-conection implementations built in.

Parameterising for ARM template deployment

Editing Logic Apps in the Designer is frustrating to say the least, so converting variables first to Workflow Definition Language Parameters and then into ARM template parameters is time consuming but lets us pass parameters and update the Logic App from the commandline. Embedding ARM parameters directly into Logic App definitions is not a great idea.

We can then call deploy the Logic App via CLI and have it run and auto-scale every 30 minutes like so:

az group deployment create \
    --resource-group yourResourceGroup \
    --template-file template.json \
    --parameters @parameters.json \
    --parameters scaleInterval=30

Would I do it again?

Now that it exists, I can auto-scale SignalR Service pretty effortlessly but the lack of granular control over unit count and no consumption pricing makes scaling up costly and scaling down before the end of a given day pointless.

Building this in Logic Apps was a learning experience, but the Designer and Workflow Definition Language had some short-comings that made progress slow and frustrating. This included whacky workarounds for converting floats to integers and WDL not having floor or round functions. I found myself constantly fighting the Designer when it failed to display dynamic variables, inserted superfluous foreach steps, blocked renaming of steps once they are referenced by another, and had no editing of parameters. These problems meant I more often than not needed to directly edit the underlying JSON.

It’d be interseting to see how the same functionality could be achieved using Az PowerShell modules inside an Azure Function.

Load testing ASP.NET Core SignalR

Stafford Williams — Mon, 10 Jun 2019 12:50:17 +0000

Last time around I messed with SignalR I touched briefly on load testing. This time around I'll deep dive into SignalR load testing, specifically to test the tool supplied in source, Crankier, and build my own load testing tools to investigate the limits of SignalR applications.

Why?

I have a SignalR-based application I'm building that I intend to gradually test with increasing-sized audiences of people. Prior to these real-human tests I'd like to have confidence and an understanding of what the connection limits and latency expectations are for the application. An application demo falling over due to load that could have been investigated with robots 🤖 instead of people 🤦‍♀ is an experience I want to skip.

I started load testing SignalR three months ago and it took me down a crazy rabbit hole of learning - this post will summarise both the journey and the findings.

Crankier

Crankier is an ASP.NET Core SignalR port of Crank, which was a load testing tool shipped with ASP.NET SignalR. At the moment the only thing Crankier does is attempt to hold open concurrent connections to a SignalR hub. There's also a BenchmarkServer which we can use to host a SignalR hub for our load testing purposes.

At the very least, we can clone the aspnetcore repo and run both of these apps as a local test:

git clone https://github.com/aspnet/AspNetCore
cd aspnetcore/src/SignalR/perf/benchmarkapps

Start the server:

cd BenchmarkServer
dotnet run

Start crankier:

cd Crankier
dotnet run -- local --target-url http://localhost:5000/echo --workers 10

I put the server on an Azure App Service and pointed Crankier at it too. Here's the results;

Server	Max connections
Local	8113
B1 App Service	350
S1 App Service	768
P1V1 App Service	768

These results look alarming, but there's reasoning behind them. 8113 turns out to be the maximum http connections my local machine can make, even within itself. But if that's the case why can't I get that number with the App Services? The limit on B1 is stated on Azure subscription service limits but the same page notes Unlimited for Web sockets per instance for S1 and P1V1. Turns out (via Azure Support) that 768 is the (undocumented) connection limit per client. I'll need more clients!

Hosting Crankier inside a container

I want to spawn multiple clients to test connection limits, so containers seem like a great idea to do this. Sticking Crankier inside a container is pretty easy, here's the Dockerfile I built to do this. I've pushed this to docker hub, so we can skip building it and run it directly. The run command above now becomes:

docker run staff0rd/crankier --target-url http://myPath/echo --workers 10

Using this approach I can push the App Services above 768 concurrent connections, but I still need one client per 768 connections. I want to chase higher numbers, so I'll swap the App Services out for Virtual Machines, which I'll directly run the Benchmark server on.

Hosting BenchmarkServer inside a container

Now that I have multiple clients it no longer clear how many concurrent connections I've reached. I'll extend the benchmark server to echo some important information every second:

Total time we've been running
Current connection count
Peak connection count
New connections in last second
New disconnections in the last second

I've forked aspnetcore here to implement the above functionality.

Additionally, I'll put it inside a container so I don't have to install any of its dependencies on the VM, like the dotnet sdk. Here's the Dockerfile, but as usual it's on docker hub, so we can now start the server like so:

docker run -d -p 80:80 crankier staff0rd/crankier-server

Container client results

Now we can raise 10-20 (or more!) containers at a time asynchronously with the following command, where XX is incremented each time:

az container create -g crankier --image staff0rd/crankier --cpu 1 --memory 1 \
    --command-line "--target-url http://myPath/echo --workers 10 --connections 20000" \
    --no-wait --name myContainerXX

Over many tests I found that Operating System didn't seem to make much of a difference, so I stuck to Linux as it's cheaper. I didn't detect any difference between running the server inside a container with docker vs running it directly via dotnet installed on the VM, so future tests stick to running the server inside docker only.

Here's the results:

VmSize	Max connections	Time	Os
B2s	64200	15m	Windows Datacenter 2019
B2s	64957	18m	Windows Datacenter 2019
B2s	57436	> 5m	Ubuntu 16.04
B2ms	107944	7m	Ubuntu 16.04 (50+ containers)

Overall these results are a bit lower than I was expecting, and two problems still existed.

By default Crankier only holds connections open for 5 minutes before dropping them. Any tests running over 5 minutes were dropping their connections and;
Some containers were maxing out 500 concurrent connections only. If I raised 10 containers, only 1 or 2 of them would crank past 500.

The first one is easily solve by passing --send-duration 10000 to hold connections open for 10000 seconds, but the second item would require a move to VMs as clients.

Crankier running on VMs

I found that VMs were much more reliable in bringing up many connections, but my problem was that they weren't as easily automated like containers. So, I built the automation myself with these scripts:

clientVM.json
- An ARM template that specifies the structure of the VM to bring up per client.
startUpScript.sh
- Install docker on the VM once it's initialised and docker pull staff0rd/crankier in preparation.
Up.ps1
- Asynchronously raise count VMs on size vmSize
RunCommand.ps1
- Running commands on VMs is not quick, so this script enables faster command running using ssh & powershell jobs. We can use this to send commands to all the VMs and get the result back.

Using the scripts above I quickly found that Azure places a limit of 20 cores per region by default. As a workaround, I raise ten 2-core VMs per region. Here's an example of raising 30 VMs:

.\Up.ps1 -count 10 -location australiaeast
.\Up.ps1 -count 10 -offset 10 -location westus
.\Up.ps1 -count 10 -offset 20 -location eastus

I can monitor the progress of bringing the VMs up with Get-Job and Get-Job | Receive-Job. Once the jobs are completed I can clear them with Get-Job | Remove-Job. Because the VMs are all brought up asynchronously it takes about 5 minutes total to bring them all up. After they're up, we can send commands to them:

.\RunCommand.ps1 -command "docker run --name crankier -d staff0rd/crankier --send-duration 10000 --target-url http://mypath/echo --connections 10000 --workers 20"

If we've set the client's target-url correctly, we should now see the server echoing the incoming connections:

[00:00:00] Current: 178, peak: 178, connected: 160, disconnected: 0, rate: 160/s
[00:00:02] Current: 432, peak: 432, connected: 254, disconnected: 0, rate: 254/s
[00:00:02] Current: 801, peak: 801, connected: 369, disconnected: 0, rate: 369/s
[00:00:03] Current: 1171, peak: 1171, connected: 370, disconnected: 0, rate: 370/s
[00:00:05] Current: 1645, peak: 1645, connected: 474, disconnected: 0, rate: 474/s
[00:00:05] Current: 2207, peak: 2207, connected: 562, disconnected: 0, rate: 562/s
[00:00:06] Current: 2674, peak: 2674, connected: 467, disconnected: 0, rate: 467/s
[00:00:08] Current: 3145, peak: 3145, connected: 471, disconnected: 0, rate: 471/s
[00:00:08] Current: 3747, peak: 3747, connected: 602, disconnected: 0, rate: 602/s
[00:00:10] Current: 4450, peak: 4450, connected: 703, disconnected: 0, rate: 703/s

Monitoring client VM connections

RunCommand.ps lets us send any command we like to every VM, so we can use docker logs to get the last line logged from every VM to monitor their status:

.\RunCommand.ps1 -command "docker logs --tail 1 crankier"

Output:

{"ConnectingCount":10,"ConnectedCount":8038,"DisconnectedCount":230,"ReconnectingCount":0,"FaultedCount":34,"TargetConnectionCount":10000,"PeakConnections":8038}

{"ConnectingCount":10,"ConnectedCount":8026,"DisconnectedCount":211,"ReconnectingCount":0,"FaultedCount":34,"TargetConnectionCount":10000,"PeakConnections":8026}

{"ConnectingCount":10,"ConnectedCount":7984,"DisconnectedCount":187,"ReconnectingCount":0,"FaultedCount":32,"TargetConnectionCount":10000,"PeakConnections":7986}
...

Here's an example of killing the containers:

.\RunCommand.ps1 -command "docker rm -f crankier"

Results

Over the last three months I've raised ~980 VMs, slowly enhancing how I test and capture data. The lines below represent some of those tests, the later ones also include the full log of the test.

Standard_D2s_v3 server

Time from start	Peak connections	Logs
15:35	93,100
07:38	100,669
24:16	91,541
24:04	92,506	https://pastebin.com/QPLgDeZt
07:54	100,730	https://pastebin.com/FB9skzJE
13:31	91,541	https://pastebin.com/sDLdm0bh

Average 80% CPU/RAM

Standard_D8s_v3 server

Time from start	Peak connections	Logs
02:34	107,564
05:55	111,665
03:43	132,175
25:33	210,746
13:03	214,025	https://pastebin.com/wkttPAaS

Average 40% CPU/RAM

Standard_D32s_v3 server

Time from start	Peak connections	Logs
11:05	236,906	https://pastebin.com/mm3RZM1y
10:28	245,217	https://pastebin.com/6kAPJB9R

Average 20% CPU/RAM

The logs tell an interesting story, including the limits on new connections per second, and how long it takes before Kestrel starts slowing down with:

Heartbeat took longer than "00:00:01" at "05/21/2019 09:37:19 +00:00"

and the time until SignalR starts throwing the following exception (GitHub issue - possible fix),

Failed writing message. Aborting connection.

System.InvalidOperationException: Writing is not allowed after writer was completed

Findings

My original target was guided by this tweet from April 2018, which suggests 236k concurrent connections at 9.5GB. From the tests above it doesn't look like ASP.NET Core SignalR is currently (dotnet 3.0.100-preview6-011744) capable of such a number at such low memory. B2ms which has 8GB peaked at 107k with D2s_v3 similar. However, with D8s_v3 and D32s_v3 peaking at 214k and 245k respectively, it's clear that CPU and memory are not currently the limiting factor. With the tools I've created to automate both the deployment of server and clients, once .NET Core 3 reaches RTM it will be relatively trivial to re-test at a later date.

Taking it further

I've sunk quite a bit of time into this load testing project. It's resulted in three new containers and a few merges to aspnet/aspnetcore. Even so, there's still things to do.

The functionality from the forked benchmarkserver should instead be moved in to Crankier itself. The server logs are missing important metrics: total cpu & memory usage, however there doesn't seem to be a nice way to grab these in current .NET Core (currently I monitor top in another ssh session to the server). Finally, one could leverage Application Insights, and, along with echoing to std out, also push telemetry to App Insights via TelemetryClient - this would result in pleasant graphs and log querying over pastebin log dumps.

A final note

Having become acquainted with Crankier I can appreciate its own limits. The current implementation only tests concurrent connections and not messaging between client and server which without does not reflect "real" load on a SignalR application. To test your own application, not only should messaging be tested, but specifically the messaging that your Hub implementations expect. Instead of extending Crankier to test your own Hub methods, it's much easier to use Microsoft.AspNetCore.SignalR.Client to write your own class that will use HubConnection to call your application's Hub methods directly, acting as an automated user specific to your application.

Chasing concurrent connection counts in this manner has been fun, but doesn't reflect what production should look like. Ramping VM size to achieve higher connection counts ignores that one VM is one single point of failure for your application. In production, using something like Azure SignalR Service would be a better approach to scaling concurrent connections.

Docker containers aren't just for long running tasks

Stafford Williams — Mon, 27 May 2019 12:03:59 +0000

Docker makes it easy to run long-running services like sql server or nzbget, but did you know that docker is also an excellent option for executing shorter workloads? This could be compiling a dotnet core program without installing the sdk, or building your jekyll blog without installing ruby.

To demonstrate both a short task use-case and the ease of creating your own docker containers, in this post I'll build a container that lets you, and me, push log files or any other text content at pastebin.com via the commandline.

Publishing logs from any VM

Pastebin lets you quickly post and share text files online. They offer an API so you can automate this process and have examples of using it written in PHP. In my use-case, I need to publish logs created on transient VMs in Azure, but I don't want to install PHP or its dependencies, nor the scripts required to post the logs. These VMs already have docker available, so my intention is to package Pastebin's PHP code into a container and push the container to docker hub.

This approach will let me use docker run staff0rd/pastebin on any VM, and the downloading and executing of the container will be taken care of automagically.

Try it now

Now that I've built and published this container, you also have access to this functionality without having to go through any of the following effort. If you've got docker installed, you can try this right now:

docker run -it staff0rd/pastebin -k <yourDevApiKey> "post this content to pastebin"

You can extend, modify, and use the source to create your own if you wish, or, open a PR and collaborate on this one. The image is on dockerhub and the source is on github.

Creating the Dockerfile

The Dockerfile represents the image we're going to docker build, and is a great example of how trivial it is to create your own containers leveraging the hard work others have already done for you. If I want to host or run a PHP script, I'm going to base my Dockerfile on the official php image. In this case, and as we'll see below, I ended up pulling in a php dependency manager, so I'll base my image on that image, which in turn is based on the php image.

FROM composer:1.8
COPY ./src /app
WORKDIR /app
RUN composer install
ENTRYPOINT [ "php", "./pastebin.php" ]

In the five lines above, I've set the base image for my container, copied my script and set the working directory, executed the install command for the dependency manager, and told the container to run the script when it starts. I can run the following command and the container is ready to be used on the machine I built it.

docker build -t staff0rd/pastebin .

Then I can run this command, and the container can be pulled or run from any machine on the internet:

docker push staff0rd/pastebin

Building the script

The larger part of this exercise is building the script that gets copied inside the container. For the actual execution I'll just use the code exampled by pastebin, but because this script will be encapsulated within the container, the parameters it needs are not obvious outside the container. To solve this, I'll use commando to build a nice CLI helper. As a dependency, commando can be installed via Composer, a php dependency manager, and hence I based the Dockerfile on Composer rather than php directly.

At the very least, commando gives me a nice --help output, so the options implemented by the script within container are no longer a secret:

λ docker run -it staff0rd/pastebin --help

Examples:

docker run -it staff0rd/pastebin -k <devKey> "paste this text to pastebin!"
    Paste the given text to pastebin

cat myfile.log | docker run -i staff0rd/pastebin -k <devKey>
    Paste the contents of myfile.log to pastebin

docker run -it staff0rd/pastebin -k <devKey> -u <userName> --password <password>
    Retrieve a userKey to use associate pastes with your user

arg 0
     Content to to paste

-k/--devkey <argument>
     Required. Your api developer key

--help
     Show the help page for this command.

-j/--userkey <argument>
     Your user key

-n/--name <argument>
     Name or title of your paste

-p/--public
     Make this paste public.  Default is unlisted.

--password <argument>
     Your pastebin password

-u/--username <argument>
     Your pastebin user name

Wrapping it up

I've pushed the image to docker hub and enabled automatic builds, so any updates to the git repo will result in a new image being built on docker hub.

Otherwise, I can (and so can you, because docker) send any file to pastebin on any docker-enabled host with the following:

cat sendThisFile.txt | docker run -i staff0rd/pastebin -k thisIsMyDevKey

I hope this post has illustrated both how easy it is to create your own docker containers, and, how docker is also a great tool for both executing and distributing/deploying short-running tasks.

Publishing a custom Azure Pipelines release task

Stafford Williams — Sat, 18 May 2019 14:00:00 +0000

I wanted to clear my Cloudflare cache during an Azure Pipeline deployment. Cloudflare offers a REST API to do this, but rather than poke around with scripts I decided to see how I could instead write a custom task to do this and publish it on the Visual Studio market place.

Get the extension

The extension is free on Visual Studio Marketplace and it’s open source on github. Here’s a screenshot of how it looks in a Azure DevOps:

How I built it

I followed a great walk-through on docs.microsoft. I like that the instructions promote typescript and testing, though I’m not going to write tests for such a small task.

Another netizen already pointed out that I would need to query first the Cloudflare REST API to translate a zone name into a zone id, and then request the purge. I turned those instructions into typescript, compiled to javascript, and bundled this javascript as a vsix extensiion using tfx-cli.

Over all the code is very simple. The structure is as follows:

/vss-extension.json
- Extension manifest, defines basic information about what the extenion does. Reference docs.
/images/extension-icon.png
- Icon representing the extension
/cloudflarePurge/index.ts
- The code that the task will execute. I haven’t written TypeScript since before v2 so I suspect the error handling could be more elegantly written with async or similar.
/cloudflarePurge/task.json
- Defines how the task’s configuration options will be rendered and which scripts will execute at build time. Reference docs

If we were just using javascript with no dependencies, that would be it. However we’re using typescript so we also have;

/cloudflarePurge/index.js
- tsc output (generated)
/cloudflarePurge/package.json
- nodejs dependencies
/cloudflarePurge/tsconfig.json
- typescript config

Once this is in place I packaged the extension with:

npx tfx-cli extension create --rev-version --manifest-globs vss-extension.json

Publishing

Publishing was a little odd - to publish publicly your Visual Studio Marketplace account needs to be approved as a publisher by someone at Microsoft. This was accomplished by entering some details about who I was and clicking a Request Approval (or similar) button. I got an approval and a you’re now approved email from someone at Microsoft about two days later.

Prior to being approved, the marketplace will block the uploading of any extension that has public:true set. Post-approval the uploader pointed out I need to include an overview.md on a public extension. However, you can point content/details in your vss-extension.json at, say, README.md to resolve this issue:

"content": {
    "details": {
        "path": "README.md"
    } 
},

That’s it!

Overall it was pretty simple to execute custom code within an Azure Pipeline release and package it into an extension. From here I’d like to look into how such a task can be called by an Azure Pipeline yaml build, and, to auto-deploy updates to this task to the marketplace on commit - a colleague of mine has a post on this.