David Gardiner - Docker

Running Speedtest on a Synology NAS

2022-01-03T13:00:00.000+10:30

Yesterday I noticed that our home Internet speed seemed a bit sluggish. Logging into the modem showed that instead of the usual 48-50Mbps, we were only getting around 25 (and sometimes much worse). Restarting the modem did not improve the speed, so I resorted to calling our ISP (Internode). They tried a reset from their end (on the NBN 'Node' I believe) but still no improvement. They've logged a call with the NBN who are scheduled to investigate the problem tomorrow. Interestingly the Internode support person said I was the third person she'd dealt with in the last few hours with a speed problem in my area.

Anyway this got me thinking. It would be nice to have some kind of regular scheduled speed test running to be able to monitor (and possibly even be notified of changes) to our Internet speed.

Doing a search for "synology speed test" came up with How to Install Speedtest Tracker on Your Synology NAS, which I started to follow when I realised that actually I think this could be done through the Synology Docker UI, rather than using a scheduled task. Here's what I did:

Installing Speedtest Tracker

In the Synology UI, open the Docker application.
Go to the Registry page, and enter speedtest-tracker
Select henrywhitaker3/speedtest-tracker, then click Download
At the Choose Tag prompt, select latest and click Select
Go to the Image page and wait for the image to finish downloading
Select the henrywhitaker3/speedtest-tracker:latest image and click on Launch
In Container Name enter Speedtest
Click on Advanced Settings
Under Advanced Settings tab, check Enable auto-restart
Under Volume tab, click Add Folder
Select docker folder and click on Create Folder
Enter speedtest and click OK
Click Select
In the Mount Path field, enter /config
Under Port Settings tab, select the 443 row and click on the - button to delete the row.
Select the 80 row and in the Local Port field, enter 8788
Under the Environment tab, click the + button to add the following environment variables. Refer to Marius's tip on getting the values for PUID and PGID, and unless you also live in Adelaide you'll need to change the TZ value to something from this list.

variable value

PUID 1026

PGID 100

TZ Australia/Adelaide

OOKLA_EULA_GDPR true
Click Apply
Click Next
Review the summary to confirm the details are correct then click on Apply
Switch to the Container page and confirm that the container is running.
Now browse to http://your-synology:8788 (Change your-synology to the IP address or name of your Synology). Either click the button to start the test, or just wait a minute or so (as it started automatically for me).

variable	value
`PUID`	1026
`PGID`	100
`TZ`	Australia/Adelaide
`OOKLA_EULA_GDPR`	true

So now Speedtest Tracker application is running a test every hour. Over time, this should become a useful reference to map our average Internet speed (and be able to identify outages or degradations). Hopefully tomorrow it might also track the restoration of our speed if NBN can fix the problem.

UniFi Controller on a Synology

2021-07-26T09:00:00.000+09:30

I've been using Ubiquiti's UniFi wireless access points for a few years around home. Until now I've only used the UniFi Controller application on an as-need basis (when setting the configuration or installing updates). But having the Synology DS1621xs on hand gives me an opportunity to try out its Docker support and in particular being able to run UniFi Controller continuously in a Docker container on the Synology.

I say 'UniFi Controller' but I gather that as of version 6.2 they've renamed it to 'UniFi Network Application'. Same software, just an updated name.

Installing Docker on the Synology

Open the Package Center
Select All Packages and scroll down to the Third-party section
In the 'Docker' package click Install
When installation has completed, the button changes to Open. Click on it to open the Docker UI.
The first time you open Docker a welcome screen message is displayed. Select Don't show this again and close the message.
Docker is now running on your Synology

Installing UniFi Controller

Select the Registry page.
In the search bar enter unifi and click Search.
Double-click on the jacobalberty/unifi image.
You now need to select a tag. Review the options to understand what the different tag values mean. (Choose latest to go with the latest stable version).
The image is now being downloaded.
Go to the Image page.
When the download has completed, the Launch button will be enabled. Click on Launch.
If desired, you can customise the Container Name.
Select Enable resource limitation.
Click on Advanced Settings.
Select Enable auto-restart.
Select Volume tab and click Add Folder.
Select the docker folder and then click on Create Folder.
Enter unifi and click OK.
Click Select.
In the Mount path column, enter /unifi. (See Volumes for volumes used by this image).
Select Network tab and select use the same network as Docker Host.
It is recommended to not run this image as root. Go to the Environment tab.
Change the value of RUNAS_UID0 to false.
As we will be binding to a port > 1024, we can also set the value of BIND_PRIV to false.
Click Apply.
Click Next.
Review the Summary details, then if they look correct click Apply.
Select the Container page.
You can see the UniFi image is now running in a container.

If you have the Synology Firewall enabled, you will need to allow access to the application, the port needs to be opened in the Synology Firewall. In my case because I hadn't exposed the Synology directly to the Internet, the firewall was disabled. I figured it was probably a good idea to enable the firewall.

From the Ports documentation there are a number of TCP and UDP ports to select.

Go to the Synology main menu and select Control Panel.
Select Advanced Mode and click on Security.
In the Firewall tab, select the custom profile and click Edit Rules.
Click Create and under Ports select Custom and then click on Custom.
Ensure Protocol is set to TCP.
In the Ports field enter 8080,8443,8843,8880,6789.
Click OK, and OK
Click Create and under Ports select Custom and then click on Custom.
In Protocol select UDP.
In the Ports field enter 3478.
Click OK, and OK
Click OK to save the firewall profile changes.
If it is highlighted, click Apply to save firewall changes.

Accessing UniFi Controller

Navigate to https://your-synology-box:8443/ (replacing your-synology-box with the DNS name of your Synology).
As the UniFi Controller comes with a self-signed TLS certificate you'll need to tell your browser to trust the certificate.
After this you should see the UniFi start-up wizard. If this is the first time you've used the software, proceed through the wizard following the steps. Alternatively (like me) if you're migrating from another installation you can click the or restore setup from backup to upload a back from the old system.

And with that you should be good to go!

Final thoughts

The ability to run Docker containers on a Synology is a great advantage. The UI is easy to use but flexible enough to allow you to run useful Docker images. Do check out my review of the DS1621xs, and check it out on amazon.com or amazon.com.au

Acknowledgements

There are quite a few different Docker images for running UniFi. Thanks to Simon Waight for the suggestion of https://github.com/jacobalberty/unifi-docker.
Ruud's instructions which formed the basis of the steps I followed here.

Docker performance on Azure Pipelines agents

2020-05-23T17:30:00.000+09:30

I've noticed some interesting variations in build times on Azure Pipelines related to using Docker to build and/or run containers. I tracked down the issue to excessive time downloading docker images, so I started investigating whether there's ways to cache or optimise the docker pull steps.

So what to do?

Self-hosted agents

First off, if you can run your own build agent you're probably not going to see these problems. Having a dedicated agent means that Docker caches all images locally and can reuse them for subsequent build jobs. That's issue with Microsoft-hosted agents - you get a brand new agent for each job - there's no possibility to persist any changes, so the value of Docker's image caching is reduced.

Cache Task

First off I did some research into whether the Cache Task could be used as a way to more efficiently restore the Docker image cache. I think the answer is probably 'no'. I've started using this task for another build involving NuGet packages, and in that case it makes the dotnet restore step much faster, but I think the problem with Docker is the files are stored in various places, so trying to cache C:\ProgramData\Docker\image\windowsfilter\layerdb\sha256 and/or C:\ProgramData\Docker\windowsfilter didn't seem to have any effect.

Docker Save/Load

There's a GitHub issue with some discussion about using docker save/load and I can confirm the comments on the issue that this did not make things faster (in fact it made things slower).

Here's an example - a pipeline that's saving 4.8-windowsservercore-ltsc2019 in the cache.

pool:
  vmImage: 'windows-latest'

variables:
  dockerCache: $(Build.ArtifactStagingDirectory)\.dockercache

steps:

- script: docker images --digests
  displayName: Docker images

- task: Cache@2
  inputs:
    key: 'nuget | "$(Agent.OS)" | azure-pipelines-docker-cache.yml'
    path: '$(dockerCache)'
    cacheHitVar: DOCKER_CACHE_HIT
  displayName: 1. Cache Task

- script: |
    if exist $(dockerCache)\4.8-windowsservercore-ltsc2019.tar docker load -i $(dockerCache)/4.8-windowsservercore-ltsc2019.tar
  displayName: 2. Docker Load

- script: docker pull mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
  displayName: 3. Docker Pull

- script: |
    if not exist $(dockerCache) mkdir $(dockerCache)
    docker image save -o $(dockerCache)/4.8-windowsservercore-ltsc2019.tar mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
  condition: ne(variables['DOCKER_CACHE_HIT'], 'true')
  displayName: 4. Docker Save

Build	1. Cache Task	2. Docker Load	3. Docker Pull	4. Docker Save	5. Cache Save	Job time (total)
Build 1 (cache miss)	00:00:03	00:00:01	00:08:04	00:17:06	00:06:09	00:31:50
Build 2 (cache hit)	00:05:45	00:10:56	00:00:03	00:00:01	00:00:03	00:17:15

So yes, the second build was faster, but both of these are way slower than a build that had no caching at all (cf just the first docker pull at 00:08:04). So that's no help.

Buildctl

The issue also mentions using buildctl, which is part of BuildKit. The trouble is I'm working with Windows Containers and BuildKit currently supported with those. If you're working with Linux containers, this does sound promising.

Existing images on the agent

It occurred to me that shouldn't Docker be making use of some existing images that are shipped on the hosted agent. The software and tools pre-installed on each agent is documented. For example, the Windows 2019 agent. This is not a static list, the agents will be updated over time as patches and updates are issued for both the OS and applications.

You can see the list of pre-installed images listed, or just to confirm, you can run docker images --digests in a pipeline step to confirm. Here's the output I got which matches the documentation.

REPOSITORY                                   TAG                              DIGEST                                                                    IMAGE ID            CREATED             SIZE
mcr.microsoft.com/dotnet/framework/aspnet    4.8-windowsservercore-ltsc2019   sha256:dbf97206264133cdef6b49b06fa5d4028482845547c2858a086b5ce5c4513f00   8280f73a9be1        9 days ago          6.87GB
mcr.microsoft.com/dotnet/framework/runtime   4.8-windowsservercore-ltsc2019   sha256:bf47599181ae3877ec680428a99f76d43ffb26251155a6f0b0b76f4e70304c26   bcd511658148        9 days ago          6.51GB
mcr.microsoft.com/windows/servercore         ltsc2019                         sha256:2629881183feda906459163cb58fbdbc001bea76a92b2dc4695c8e5b14f747ae   561b89eac394        2 weeks ago         3.7GB
mcr.microsoft.com/windows/nanoserver         1809                             sha256:8e6807c213b52405fec8a861e0b766055ba9d4f941267adf49ee67526755b63a   9e7d556b2b51        2 weeks ago         251MB
microsoft/aspnetcore-build                   1.0-2.0                          sha256:9ecc7c5a8a7a11dca5f08c860165646cb30d084606360a3a72b9cbe447241c0c   5d8be0910d37        21 months ago       3.99GB

Out of curiosity, I added a docker pull mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019 step to the pipeline. Now that should be super-quick as you can see that image is already cached. But it wasn't! It too almost 8 minutes.

docker pull mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
========================== Starting Command Output ===========================
"C:\windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\d190c5d8-262b-4a70-9c04-216b9ac2b165.cmd""
4.8-windowsservercore-ltsc2019: Pulling from dotnet/framework/aspnet
4612f6d0b889: Already exists
eed17b4baac2: Pulling fs layer
565c587c68c2: Pulling fs layer
c732b140f2ad: Pulling fs layer
84ae672f9921: Pulling fs layer
cd04865d4563: Pulling fs layer
7c75100d3a4d: Pulling fs layer
bea74093ac0e: Pulling fs layer
6353217bf85b: Pulling fs layer
ca397bdd5ee0: Pulling fs layer
ef8702482a58: Pulling fs layer
84ae672f9921: Waiting
cd04865d4563: Waiting
7c75100d3a4d: Waiting
bea74093ac0e: Waiting
6353217bf85b: Waiting
ca397bdd5ee0: Waiting
ef8702482a58: Waiting
c732b140f2ad: Verifying Checksum
c732b140f2ad: Download complete
565c587c68c2: Verifying Checksum
565c587c68c2: Download complete
eed17b4baac2: Verifying Checksum
eed17b4baac2: Download complete
cd04865d4563: Verifying Checksum
cd04865d4563: Download complete
7c75100d3a4d: Verifying Checksum
7c75100d3a4d: Download complete
6353217bf85b: Verifying Checksum
6353217bf85b: Download complete
ca397bdd5ee0: Verifying Checksum
ca397bdd5ee0: Download complete
84ae672f9921: Verifying Checksum
84ae672f9921: Download complete
ef8702482a58: Verifying Checksum
ef8702482a58: Download complete
bea74093ac0e: Verifying Checksum
bea74093ac0e: Download complete
eed17b4baac2: Pull complete
565c587c68c2: Pull complete
c732b140f2ad: Pull complete
84ae672f9921: Pull complete
cd04865d4563: Pull complete
7c75100d3a4d: Pull complete
bea74093ac0e: Pull complete
6353217bf85b: Pull complete
ca397bdd5ee0: Pull complete
ef8702482a58: Pull complete
Digest: sha256:3579480a92f0795c37d6e551139b431eb7cafe798d257c7ce279e10adbd0cb6d
Status: Downloaded newer image for mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019

Why is it pulling all those layers? When does mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019 != mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019?

I then took a look at the Docker Hub page for ASP.NET. It lists the same tag, though interestingly the 'last modified' date was 19th of May (4 days ago). Compare that with the docker images list above - it says '9 days ago' - and on closer examination the sha256 values are different too!

So I'm pretty sure that's the problem - there's a lag between when a new image is published on Docker Hub and when that image will be included in the current hosted agent VM.

Image architecture

One other thing to watch out for. Notice that the one of the images listed on the agent is mcr.microsoft.com/windows/servercore:ltsc2019? There's different 'architecture' options for container images. For Windows Containers, these are usually either 'multiarch' or 'amd64'. For example see both listed for Windows Server Core. The trap is that these are two different images. If you specify the ltsc2019-amd64 tag, that won't match the image on the agent.

Possible solutions

So that seems like a reasonable hypothesis. Because we're either explicitly doing a docker pull or we're depending on images that were built with a different version of the base image, we're experiencing a cache miss and paying the penalty by needing to download an entirely new image.

I think the problem can be managed by ensuring that images are built against the current base images on the agent. If you're building images in different pipelines and then storing those in a private registry (Azure Container Registry for example), then you're probably going to need to refresh those as soon as the agent images are updated.

Following the releases in the GitHub Actions virtual-environments repo appears to be the easiest way to know when the agent software is changing. Yes, GitHub Actions and Azure Pipelines share the same agent configurations.

If you really need to fix on a version, don't just rely on the tags - you're best bet then is to reference the sha256. That way there's no ambiguity. But be aware you'll more than likely end up referring to an image that isn't cached. In that case if build time matters, then using a self-hosted agent is probably the best strategy.

JSON to Environment Converter

2020-05-11T08:00:00.000+09:30

I made a thing!

I needed to translate some JSON configuration (like the appsettings.json file used by ASP.NET Core) into equivalent environment variables (so that they could be set in a Dockerfile). Rather than try and figure it out, I created a simple web tool to do the conversion for me.

Paste your JSON into the first text field
Select the formatting options
1. Dockerfile-style or Yaml (suitable for docker-compose.yml or azure-pipelines.yml)
2. Whether to include entries with a key but no value
3. Use colons or underscores as separators
Press Convert
Review and/or copy the text that appears in the second text field.

You can find it at https://jsontoenvironmentconverter.azurewebsites.net/, and the source code is at https://github.com/flcdrg/JsonToEnvironmentConverter

Trying Docker for Windows and Linux

2019-11-16T14:45:00.000+10:30

I've been spending a bit of time trying out Docker over the past few days, with the goal of making builds more reliable and repeatable.

Docker Desktop for Windows has the ability to run in Windows mode and Linux mode. Usually that means you can only run containers of one OS at at a time.

However, if you run configure Docker to enable 'Experimental' mode, then you can actually run both platforms simultaneously.

Interestingly, when you're in this mode and you set 'Windows' as the default container platform, you don't see an extra virtual machine listed in HyperV.

Here's Docker running with Linux containers:

And here's Docker with Windows containers: Notice the VM may be there, but it is not running, even when I'm actually building a Linux container when that screenshot was taken.

So with experimental mode on, how can Docker be also running Linux containers in Windows mode?

Currently it uses something called LCOW - Linux Containers on Windows.

I know Docker also has preview support for WSL2. I think the plan is that once that ships (presumably with Windows 10 20H1) then Docker will be able to leverage that for Linux execution.

So in theory, if you need to spin up Linux and Windows containers, then this is the technology that will make that happen.

There's still a few rough edges - probably why it's all behind 'preview' or 'experimental' flags.

I hit one issue where trying to spin up a Node Linux container which has a step to run yarn resulted in some weird internal error:

Step 14/22 : RUN yarn
---> Running in eb14f055a9aa
container eb14f055a9aaa23db5f35493feec9009b775c6688e3c488b26c6880517bdd9f1 encountered an error during CreateProcess: failure in a Windows system call: Unspecified error (0x80004005)
[Event Detail: failed to run runc create/exec call for container eb14f055a9aaa23db5f35493feec9009b775c6688e3c488b26c6880517bdd9f1: exit status 1 Stack Trace:
github.com/Microsoft/opengcs/service/gcs/runtime/runc.(*container).startProcess
/go/src/github.com/Microsoft/opengcs/service/gcs/runtime/runc/runc.go:580
github.com/Microsoft/opengcs/service/gcs/runtime/runc.(*runcRuntime).runCreateCommand
/go/src/github.com/Microsoft/opengcs/service/gcs/runtime/runc/runc.go:471
github.com/Microsoft/opengcs/service/gcs/runtime/runc.(*runcRuntime).CreateContainer

No idea what's going on there other than maybe I've managed to hit some issue where some API isn't implemented?

It's strange, as a different container (based on a different Linux distribution) didn't have that problem.

So it has potential, but it's obviously a work in progress.