Getting a List of Tags from the Microsoft Container Registry–#SQLNewBlogger

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

I needed to write this post because I keep forgetting this. I’m hoping this will help me remember.

I easily remember that the container registry is at This isn’t helpful. On Firefox, I get a redirect.

2020-07-07 15_22_22-Azure Container Registry _ Microsoft Azure

In Chrome, I get less help

2020-07-07 15_22_05-Window

I know that the image path is under /mssql/server, but again, on Firefox, I get to to product home page. On Chrome, I get the same thing.

2020-07-07 15_24_32-Window

On StackOverflow, someone suggested a /v2 in front of the image path, and adding a /tags/list to the end. I did that and got redirected to this long URL:

2020-07-07 15_29_26-Mozilla Firefox

That works since it apparently gets me the Docker API with the v2.

The main problem for me was that I wanted to get the latest 2019 image, without using latest. I tried this:

docker pull

However, that doesn’t work. Apparently, since there are now two versions for Ubuntu, I need to add a – with that. Either a 16.04 or an 18.04.

Maybe I’ll remember that.


Containers are going to be important at some point and knowing how to work with them will be a desired skill. As I try different things, taking 10 minutes to document some knowledge is good. In this case, I give an interviewer a good reason to ask me if I actually remember this.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Blog and tagged , , . Bookmark the permalink.

2 Responses to Getting a List of Tags from the Microsoft Container Registry–#SQLNewBlogger

  1. Dave Wentzel says:

    Here’s why it works this way (and it drives me nuts too). A container registry accomplishes 2 things: a place to _store_ the images and a place to _catalog_ the images. mcr is merely the former and NOT the latter. The latter is handled via Docker Hub. Now the why…it’s not a good idea to have your bits stored under the purview of another entity. It’s much better to store your own bits how you want to store them and then merely use the public registry for cataloging and searching. If you are unsure why this is smart just look at recent controversies over package managers (pip, npm, etc). IMO every package manager is broken. Package managers serve dual purposes just like a registry, however, many of the package manager maintainers will bundle the dependencies _they_ want to include vs what the author of the software intended and tested. Example: if you want to install google chrome on ubuntu via a deb file (how google develops and tests it) you are FORCED to use the snap which canonical (ubuntu’s owner) makes (but google doesn’t tes) and can therefore do whatever they want to it, in the future. Including nefarious stuff.

    Anyway, all microsoft containers, not just sql, work this way. So you _discover_ the container you need via docker hub, which points you to mcr which is where you _pull_ it. This is the right way to do this. Admittedly, microsoft should make mcr discoverable via public api’s as well. More info:


  2. way0utwest says:

    Thanks for the note. It’s a bit maddening when I want to find something to go to Docker Hub and I thought that it was deprecated, but I guess I’ll also use that in the future.


Comments are closed.