Creating Docker Hosts in Azure w/Docker-Machine 0.7.0



unread writer


I've never read a book by my favorite writer.  Joss Whedon created the TV shows Buffy the Vampire Slayer, Angel, and Firefly.  Now, he's created the movie Serenity.  Orson Scott Card (also not bad in the writing department) says Serenity is the best sci fi movie he's seen.  I thought it was incredible, but for me, my Mom's reaction was the most surprising.

My Mom is no breathless sci fi fan. I wasn't sure she would like it at all. She said it reminded her of seeing the original Star Wars.  She doesn't think it was like Star Wars. Instead it was remembering the feeling of not knowing what to expect and finding something new and great in a movie. 

Shai and I didn't get to experience it that way.  We've watched the Firefly series on TV, then the entire series on DVD.  The characters, and the writing were familar to us, but the result was still great.  If you haven't heard of Firefly go see this movie.  If you have, convince someone you wouldn't expect to be a fan to go see it with you.


Use the symbol server


Below you see the sad state of affairs that comes from not using the public symbol server:

No Symbol Server

This is not the callstack you want to see.  With only exports loaded for ntdll.dll you are missing the whole show.  What you need is the public symbol server! (Don't bother clicking on this link, use this URL in Symbol settings dialog in VS, not internet Explorer: "https://msdl.microsoft.com/download/symbols").

Symbol Settings

If you add the public symbol server, be sure to cache those symbols locally. If you don't use a cache devenv will hit the network on each module load.  Below you can see the improved callstack, and the heading in the modules window that shows the public symbols are 'stripped' of source information.

With Symbol Server everything is better

From other tools that support symbol server you will need a slightly more verbose syntax as the cache and the server are specified on one line:"srv*c:\symcache*https://msdl.microsoft.com/download/symbols;"


Using Note flags in Onenote


How I expected to use note flags was very ambitious.  How I actually use them is much simpler.

 

I like the ability to flag TODO items more than the ability to browse by bug, email alias, etc.  I use check box style flags and keep the summary set to show only unchecked items, while keeping the search scope at the current folder.

 

Then I made 3 categories.  Habit, is specific advice that I found so valuable I want to remember and make it a habit over time.  Non-urgent, is for the times I hope I am doing all day.  Urgent, is for anything that is on a tight deadline.  If you've read the 7 habits Urgent and Non-urgent correspond to quadrant I and II (important/urgent, and important/non-urgent).  I don't bother making todo items for unimportant things.

 

Finally I decided I need to keep all items visible in the note flags summary.  This means for example, if I need to make a new non-urgent item and I have no room, I am forced to make a 'tough call' and admit I won't do something.  I've been using this for two weeks.  It may require a few more tweaks, but I like it so far.


XSLT debugging in Visual Studio


Visual Studio is a big tool.  It's easy to miss some useful features.  Hopefully the XSLT debugger won't get missed.   If you want to learn how to use XSLT debugging take a look at Neetu Rajpal's msdn article Introducing Xml tools in VS 2005.  Below you can see the debugger in action as an xslt transform is being applied to some XML.

 

(Please excuse the nonsense XSLT I use in the example.  I haven't had a chance to play around with XSLT for quite some time.)

XSLTdebugging 

XSLT debugging is interesting to me because much of it is the managed debugger.  XSLT is compiled to msil, and the managed debugger is used to provide things like breakpoints and stepping. You can see this by opening the modules window.  You'll see in the last column that the process is a managed process called the Microsoft.XSLDebugProxy.exe, and there will be some modules loaded with names like System.Xml.Xsl.CompiledQuery.1.   All of the debugger windows work as expected: callstack, locals, immediate, threads, modules.  You can see below the callstack for my nonsense example:

 

XSLTcallstackwithJMC 

However! Go to the callstack window and right click to get the context menu. There will be an item called Show External Code. Pick that and you get to see much in the callstack window that was hidden before. The grey colored frames are because there is no debug info (pdb file) for that assembly, which is why those frames were marked as 'External Code' before. The CompiledQuery frames were hidden because the XSLT compiler placed an attribute on them to tell the debugger they were not of interest. With the expanded view you can now see the compiled query and the code that dispatched it.

XSLTCallstackWithoutJMC

However, while that is interesting it is unlikely to help you get at a bug in your XSLT. The Locals window however appears to be one of the more useful windows, that can help you see what is happening as the transforms are applied.

LocalsWindowXSLTdebugging


ACR Build (Preview) Now Supported In All Public Regions


ACR Build, a native container build capability of the Azure Container Registry is now available in all regions ACR is available. That's 23 regions worldwide as of July 23rd 2018.

ACR Build enables network close builds, alongside your container registry. While docker has an efficient image layering scheme, image layers can grow in size. Reducing the network distance your image pull and push operations must travel is key to improving reliability, speed and reducing network egress costs.

Wherever you run your Azure Container Registry, you can now build Linux, Windows and ARM right alongside.

OS & Framework Patching of Containers


ACR Build is primarily focused on the container lifecycle management challenge. ACR Build supports:

ACR Build is currently in preview, incorporating feedback. Based on feedback, we've recently enabled:

  • remote context, such as an existing git repository with nested folders
    az acr build \ -t hello-acr:{{.Build.ID}} \ https://github.com/Azure-Samples/acr-helloworld.git
    and nested folders
    az acr build \ -t hello-world-of-windows:{{.Build.ID}} \ https://github.com/AzureCR/acr-builder-os-tests.git#master:Windows/Servercore
  • multi-tagging support -t image1:{{.Build.ID}} -t image1:latest
  • ARM support
  • Windows support
  • {{.Build.Date}} is coming soon

Watch more on Azure Friday with Lara Rubbelke

Give it a try. Tell us what you need.

For more information

Any other feedback, feel free to leave larger comments here, user voice, twitter (@SteveLasker)

Thanks,
Steve and the great members of the ACR team


ACR Build OS & Framework Patching Now Supports Docker Hub


In May we announced the public preview of ACR Build, enabling OS & Framework patching. When we announced the preview, only Azure Container Registries were supported for base image update notifications.

With DockerCon starting this week, it's only appropriate we add support for base in Docker Hub.

  • Docker build a locally scoped directory in Azure, with a tag based on the build id:

git pull https://github.com/demo42/helloworld az acr build -t helloworld:{{.Build.ID}} .

  • Create a build-task that automatically builds, based on git commits, or base image updates

az acr build-task create \ -n helloworld \ -c https://github.com/demo42/helloworld \ -t helloworld:{{.Build.ID}} \ --git-access-token $PAT

When az acr build completes, the base images dependencies are dynamically discovered. We believe dynamic discovery is key, so your build task and dependencies are kept in sync with your code:

 ACR Builder discovered the following dependencies:  - image:    registry: demo42.azurecr.io    repository: helloworld    tag: aanc    digest: sha256:581a6215cae409690a4106fb06f8a1f7b9cd4790b956cb197b22eb4cae9b3977   runtime-dependency:    registry: registry.hub.docker.io    repository: baseimages/node    tag: 9-alpine    digest: sha256:1c3d74a201d4169a2dff0d49e831510384063df7546ee89bb806febfe29eaadb   git:    git-head-revision: e578d0e125be1599fb125bdd07c05f16d45ff1c1

Build Latency

To meet the scale of builds that we expect over time, ACR build has a built in randomness to the delay by which a base image update will be notified. This is currently between 10 and 60 minutes.

Using az acr build-task list-builds, you can see the build change from a Git Commit to Image Update

 BUILD ID  TASK        PLATFORM  STATUS  TRIGGER   STARTED       DURATION  ---------- ------------------ ---------- --------- ------------ -------------------- ---------  aanc    helloworld     Linux   Succeeded Image Update 2018-06-11T18:34:55Z 00:00:45  aanb    helloworld     Linux   Succeeded Git Commit  2018-06-11T18:31:13Z 00:00:45

We believe automated OS & Framework patching is a key element of container life cycle management. We also know that running ahead means we may not always have the the experience just right. We encourage your thoughts and feedback:

You can always reach me directly at Steve.Lasker at microsoft dot com or twitter: @SteveLasker

Steve


Azure Container Registry Build Supports All Windows Versions (Preview of Preview)


ACR Build, a cloud-native container build capability of the Azure Container Registry now supports all supported versions of Windows Containers.

In May of 2018, Azure announced ACR Build (Preview), a component of Azure's OS & Framework Container Life-cycle Management Today, we wanted to give customers early access to Windows Builds, in addition to the Linux and ARM builds customers could do since last May.

ACR Build Enables All Supported Versions of Windows Containers

The most significant element of Windows support is the support for all supported version of Windows, including ltsc2016, 1709 and 1803. In addition to Windows Server Core, Nano Server is also supported by ACR Build.

A suite of tests for Windows containers are available here: https://github.com/AzureCR/acr-builder-os-tests/tree/master/Windows

What is (Preview of Preview)

Updates to the az cli will not be publicly available until July 31. There are two ways to get ACR Build for Windows Container support today (July 16th, 2018)

  1. Create a build task with the public az cli
    build-task already supports the --os parameter, so you're good to go if you just want build-tasks
  2. To use az acr build; the equivalent of docker build, use a preview build of the az cli, which can be
    1. installed directly: https://github.com/Azure/azure-cli#edge-builds
    2. or with a docker image: https://github.com/Azure/azure-cli#docker docker run -v ${HOME}:/root -it azuresdk/azure-cli-python:dev

A quick test

We'll use the most consistent way, a docker container of the dev builds of the az cli

  • On Windows, or Mac, instance a docker container, running the latest dev build, including updates to az acr build docker run -v ${HOME}:/root -it azuresdk/azure-cli-python:dev
  • Note: ACR Build is currently supported:
    • East US
    • West Europe
    • Central US
    • South Central US
      More regions are coming on weekly, with full global coverage coming "soon"
  • Build a Windows Server Core image, with a .NET Framework app
    az acr build \ -t helloworld-windowsservercore:multi-arch-{{.Build.ID}} \ -f helloworld-windowsservercore/multi-arch.Dockerfile \ --os windows \ https://github.com/AzureCR/acr-builder-os-tests.git#master:Windows/Servercore

How this works:

  • az acr build is the functional equivalent of docker build. Rather than having to install the docker client, az acr build sends the context to an ACR Build server in Azure
  • -t uses the standard docker tag, with the added ability to get a unique build id.
  • -f uses the standard dockerfile syntax to reference a Dockerfile that isn't in the root of the context
  • --os tells ACR Build to use a Windows host. As many FX and platform tags are multi-arch, this parameter is required to specify which OS you require for docker build
  • https://github... is a remote context for the build. While . is supported for a local directory, acr build and build-task can also specify remote git repos, avoiding the necessity of first git clone

Since this references the multi-arch tag for Windows and the .NET Framework, this will produce an 1803 version of Windows Server Core. To get a specific windows version, use the following:

  • Windows Server 1709, using the 1709.Dockerfile az acr build \ -t helloworld-windowsservercore:1709-{{.Build.ID}} \ -f helloworld-windowsservercore/1709.Dockerfile \ --os windows \ https://github.com/AzureCR/acr-builder-os-tests.git#master:Windows/Servercore
  • Windows Nano Server 1709, using the 1709.Dockerfile for Nano Server and .NET Core
    az acr build \ -t helloworld-nanoserver:1709-{{.Build.ID}} \ -f helloworld-nanoserver/1709.Dockerfile \ --os windows \ https://github.com/AzureCR/acr-builder-os-tests.git#master:Windows/Nanoserver

Automated Build Tasks, based on Git Commits, or Based Image Updates

The primary scenario for ACR Build revolves around Container OS & Framework patching. Just as your builds kick off, based on git-commit changes, as base images are patched, your builds can also be triggered.

See Overview of ACR Build, targeting OS & Framework Patching for more details.

Creating automated builds

Note: this can be done directly with the publicly released az cli, however, we'll use the az cli docker image for consistency.

  • Fork the https://github.com/AzureCR/acr-builder-os-tests repo
  • Create a Personal Access Token.
    For more info, see the ACR Build Docs for creating a build task.
  • Set the PAT to an environment variable
    PAT=[pastePAT]
  • Create an acr build-task
    az acr build-task create \ -n HelloworldWinServercoreLtsc2016 \ -t helloworld-windowsservercore:ltsc2016-{{.Build.ID}} \ -f helloworld-windowsservercore/ltsc2016.Dockerfile \ -c https://github.com/AzureCR/acr-builder-os-tests.git#master:Windows/Servercore \ --os windows \ --git-access-token $PAT
  • Trigger a build manually
    az acr build-task run HelloworldWinServercoreLtsc2016

For more information

Any other feedback, feel free to leave larger comments here, user voice, twitter (@SteveLasker)

Thanks,
Steve and the great members of the ACR team