Giter VIP home page Giter VIP logo

acr's Introduction

Azure Container Registry

This repo contains issues, samples, troubleshooting tips, and a collection of links for Azure Container Registry.

Blog posts

Links

A set of short links for presentations & social media.

General ACR Links

Title Link
ACR service https://aka.ms/acr
Tiers https://aka.ms/acr/tiers
Pricing https://aka.ms/acr/pricing
Docs https://aka.ms/acr/docs
CLI docs https://aka.ms/acr/docs/cli
REST docs https://aka.ms/acr/docs/rest
Roadmap https://aka.ms/acr/roadmap

General ACR Capabilities

Title Link
Cross region replication https://aka.ms/acr/geo-replication
In-zone redundancy https://aka.ms/acr/az
Helm support https://aka.ms/acr/helm
Supply chain artifact support https://aka.ms/acr/acr/supply-chain-artifacts
Importing artifacts https://aka.ms/acr/import
Tag locking https://aka.ms/acr/tag-locking
Webhook notifications https://aka.ms/acr/webhooks
Auto-purge https://aka.ms/acr/auto-purge
OCI artifacts https://aka.ms/acr/artifacts
Artifact streaming https://aka.ms/acr/artifact-streaming

Diagnostic & Troubleshooting Links

Title Link
Audit logs https://aka.ms/acr/audit-logs
Health check CLI https://aka.ms/acr/health-check

Security Links

Title Link
Authentication https://aka.ms/acr/authentication
Authorization roles https://aka.ms/acr/authentication/roles
Repository permissions https://aka.ms/acr/repo-permissions
Azure policies https://aka.ms/acr/azurepolicy
VNet & firewall rules https://aka.ms/acr/vnet
Azure private link https://aka.ms/acr/privatelink
Dedicated data endpoints http://aka.ms/acr/dedicated-data-endpoints
Customer-managed keys https://aka.ms/acr/cmk
Content trust / signing https://aka.ms/acr/content-trust
Quarantine pattern https://aka.ms/acr/quarantine
Custom domains (Preview) https://aka.ms/acr/custom-domains

ACR Tasks

Title Link
Tasks https://aka.ms/acr/tasks
Tasks - Gated Import of Public Content https://aka.ms/acr/tasks/gated-import
Task Scheduling https://aka.ms/acr/tasks/scheduling
Task Timer Cron Expressions https://aka.ms/acr/tasks/cron
Task Dedicated Agent Pool https://aka.ms/acr/tasks/agentpool

Social Media, Content & ACR Jobs at Microsoft

Title Link
Links https://aka.ms/acr/links
FAQ https://aka.ms/acr/faq
Presentations https://aka.ms/acr/presentations
Jobs https://aka.ms/acr/jobs
X #AzureContainerRegistry https://twitter.com/search?q=%23AzureContainerRegistry

Providing feedback

Title Link
Stack Overflow for community support https://aka.ms/acr/stack-overflow
Azure Feedback for feature requests https://aka.ms/acr/uservoice
GitHub for logging issues https://aka.ms/acr/issues
Create a ticket for general support https://aka.ms/acr/support/create-ticket

API and SDK reference

acr's People

Contributors

adewaleo avatar ankurkhemani avatar avtakkar avatar bangbingsyb avatar davidobando avatar dependabot[bot] avatar djyou avatar dlepow avatar ehotinger avatar huanwu avatar inorthtyphoon avatar jaysterp avatar mangalorereshmi avatar mmacy avatar mnltejaswini avatar msyihchen avatar northtyphoon avatar sajayantony avatar savaradh avatar shahzzzam avatar shizhmsft avatar silviomessi avatar sivagms avatar srinibanala avatar stevelas avatar stevelasker avatar terencet-dev avatar toddysm avatar yugangw-msft avatar yuwamsft2 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

acr's Issues

Cleanup functionality - e.g. keep "latest" and things newer than <n> days

Is a functionality on the roadmap which is able to automatically purge images via some criteria (to be discussed)?

We are quickly approaching some hard limits (500 GB in our case) and need to find a way to clean things up.

Our requirement in the first iteration would be something like: "Keep any manifest marked latest, and additionally anything newer than n days."

We are considering scripting this (somehow, e.g. in Python or node), but wouldn't bother if you say it's just around the corner. Or, even better, do you know of anybody who has already done something similar?

The data is readily available over the API, as it seems; e.g. az acr repository show-manifests -n <name> --repository <repo> returns exactly the kind of data which would be needed to implement such a functionality - each manifest has a list of tags, and additionally a timestamp.

Azure Container Registry integration with Azure Active Directory - doc in progress

Azure Container Registry integration with Azure Active Directory

The Azure Container Registry allows users to manage a private Docker registry on the cloud. Our service enables customers to store and manage container images across all types of Azure deployments, keep container images near deployments to reduce latency and costs, maintain Windows and Linux container images in a single Docker registry, use familiar, open-source Docker command line interface (CLI) tools, and simplify registry access management with Azure Active Directory.

The integration of Azure Container Registry with Azure Active Directory is crucial in order to enable transparent authentication and authorization of users and headless services using AAD credentials. In this scenario, a user will only have to use their AAD credentials to log-in to their private registry, and the Azure Container Service will take care of the authorization validation of each operation using the provided credentials.

Under the hood Azure Container Service utilizes the oauth2 authorization protocol, as described by the Docker Registry v2 authentication via central service documentation as well as the Docker Registry v2 Bearer token specification. The JWT tokens generated by the Azure Container Registry are easy to observe in jwt.io.

Authenticating to a registry with Azure CLI

The process to log in to the registry, from the user's perspective, is simple. The user will use the Microsoft Azure CLI 2.0:

az acr login -n contosoregistry

Internally, the CLI will follow these steps:

  1. Calls to Azure Resource Manager to resolve the login server for the specified registry.
  2. Obtains refresh credentials from the profile in use. For a headless call, this will give you the registered SPN, for a regular user this will give you a refresh token.
  3. Makes an HTTPS GET call to the registry server's /v2 endpoint, without credentials. A bearer token authentication challenge is expected, specifying realm and service values. The realm contains the authentication server's URL.
  4. Makes an HTTPS POST call to the authentication server's /oauth2/exchange endpoint, with a body indicating the grant type, the service, the tenant, and the credentials.
  5. From the server's response, we extract an Azure Container Registry refresh token.
  6. Pass the refresh token as the password to the Docker CLI, using a null GUID as the username and calling docker login. From here on, the docker CLI takes care of the authorization cycle using oauth2.

At the end Docker will store the refresh token and go through the oauth2 flow on each operation it does against the Azure Container Registry.

Listing a repository with Azure CLI

The Microsoft Azure CLI 2.0 allows users to also list the repositories registries, and list tags for a repository in a registry. Here's how users can achieve listing the repositories in a registry:

az acr repository list -n contosoregistry

Internally, the CLI will follow these steps:

  1. Calls to Azure Resource Manager to resolve the login server for the specified registry.
  2. Obtains refresh credentials from the profile in use. For a headless call, this will give you the registered SPN, for a regular user this will give you a refresh token.
  3. Makes an HTTPS GET call to the registry server's /v2 endpoint, without credentials. A bearer token authentication challenge is expected, specifying realm and service values. The realm contains the authentication server's URL.
  4. Makes an HTTPS POST call to the authentication server's /oauth2/exchange endpoint, with a body indicating the grant type, the service, the tenant, and the credentials.
  5. From the server's response we extract an Azure Container Registry refresh token.
  6. Makes an HTTPS POST call to the authentication server's /oauth2/token endpoint, with a body indicating the grant type, the service, the scope, and the Azure Container Registry refresh token.
  7. From the server's response we extract an Azure Container Registry access token.
  8. Makes an HTTPS GET call to the registry server's /v2/_catalog endpoint using the access token as the bearer token.
  9. Obtains the data from the service and displays it.

When listing the tags of a repository, every step above is the same except for the call to the endpoint that gives the tags which is /v2/contosoregistry/tags/list instead of /v2/_catalog.

Azure Container Registry refresh tokens and access tokens

Let's follow an example call to list a repository:

az acr repository list -n contosoregistry

This will produce a JWT refresh token with the following payload:

{
  "jti": "365e3b5b-844e-4a21-a38c-4d8aebdd6a06",
  "sub": "[email protected]"
  "nbf": 1497988712,
  "exp": 1497990801,
  "iat": 1497988712,
  "iss": "Azure Container Registry",
  "aud": "contosoregistry.azurecr.io",
  "version": "1.0",
  "grant_type": "access_token_refresh_token",
  "tenant": "409520d4-8100-4d1d-ad47-72432ddcc120",
  "credential": "AQA...iAA"
  "permissions": {
    "actions": [
      "*"
    ],
    "notActions": []
  }
}

Followed by an access token with the following payload:

{
  "jti": "ec425c1e-7eda-4f70-adb5-19f927e34a41",
  "sub": "[email protected]"
  "nbf": 1497988907,
  "exp": 1497993407,
  "iat": 1497988907,
  "iss": "Azure Container Registry",
  "aud": "contosoregistry.azurecr.io",
  "access": [
    {
      "type": "registry",
      "name": "catalog",
      "actions": [
        "*"
      ]
    }
  ]
}

Getting credentials programatically

In order to sign in to a container you'll need to exchange AAD credentials for ACR credentials. The accepted form of credential exchange are:

  • AAD access token
  • AAD refresh token
  • AAD access token and refresh token

Ideally you'll present both the AAD access token and the AAD refresh token. The AAD access token is used to talk to the Azure Resource Manager and query for the set of permissions that the user has for the container registry resource. The AAD refresh token is used in two ways:

  1. If no AAD access token was presented, the AAD refresh token is used to obtain an AAD access token.
  2. The AAD refresh token is sent back to the user so they can initiate a token refresh cycle against AAD. If no AAD refresh token is sent, then the client won't have this credential at hand to initiate a credential refresh.

The cycle to get credentials looks as follows:

  1. Call /oauth2/exchange presenting the AAD refresh token and the AAD access token. The service will return you an ACR refresh token.
  2. Call /oauth2/token presenting the ACR refresh token. The service will return you an ACR access token which you can use to call the Azure Container Registry's APIs.

Calling /oauth2/exchange to get an ACR refresh token

Assume you have the following:

  1. A valid container registry, which here we'll call contosoregistry.azurecr.io
  2. The AAD tenant identifier associated to the credentials, which here we'll take to be 409520d4-8100-4d1d-ad47-72432ddcc120.
  3. Valid AAD access token and AAD refresh token credentials with access to the aforementioned container registry.

Here's how such a call looks when done via curl:

export registry="contosoregistry.azurecr.io"
export tenant="409520d4-8100-4d1d-ad47-72432ddcc120"
export aad_refresh_token="AQA...iAA"
export aad_access_token="eyJ...H-g"
curl -v -X POST -H "Content-Type: application/x-www-form-urlencoded" -d \
"grant_type=access_token_refresh_token&service=$registry&tenant=$tenant&refresh_token=$aad_refresh_token&access_token=$aad_access_token" \
https://$registry/oauth2/exchange

The body of the POST message is a querystring-like text that specifies the following values:

  • grant_type, which can take a value of access_token_refresh_token, or access_token, or refresh_token.
  • service, which must indicate the name of your Azure container registry.
  • tenant, which is the AAD tenant associated to the AAD credentials.
  • refresh_token, the AAD refresh token, mandatory when grant_type is access_token_refresh_token or refresh_token.
  • access_token, the AAD access token, mandatory when grant_type is access_token_refresh_token or access_token.

The outcome of this operation will be a response with status 200 OK and a body with the following JSON payload:

{"refresh_token":"eyJ...L7a"}

This response is the ACR refresh token which you can inspect with jwt.io. You can now use it to obtain an ACR access token programmatically or simply send it to the docker login command to get docker talking to the Azure Container Registry.

Authenticating docker with an ACR refresh token

Once you have obtained an ACR refresh token, you can use the docker CLI to sign in to your registry like this:

export registry="contosoregistry.azurecr.io"
export acr_username="00000000-0000-0000-0000-000000000000"
export acr_refresh_token="eyJ...L7a"
docker login -u "$acr_username" -p "$acr_refresh_token" $registry

The null GUID tells the container registry that this is an ACR refresh token during the login flow.

Calling /oauth2/token to get an ACR access token

Assume you have the following:

  1. A valid container registry, which here we'll call contosoregistry.azurecr.io.
  2. A valid ACR refresh token.
  3. The desired scope for the operation, as specified here and here; in this example we'll ask for the "registry:catalog:*" scope that will allow us to call the /v2/_catalog API.

Here's how such a call looks when done via curl:

export registry="contosoregistry.azurecr.io"
export acr_refresh_token="eyJ...L7a"
export scope="registry:catalog:*"
curl -v -X POST -H "Content-Type: application/x-www-form-urlencoded" -d \
"grant_type=refresh_token&service=$registry&scope=$scope&refresh_token=$acr_refresh_token" \
https://$registry/oauth2/token

The body of the POST message is a querystring-like text that specifies the following values:

  • grant_type which is expected to be refresh_token.
  • service, which must indicate the name of your Azure container registry.
  • scope, which is expected to be a valid scope, and can be specified more than once for multiple scope requests.
  • refresh_token, which must be a valid ACR refresh token, as obtained by calling /oauth2/exchange.

The outcome of this operation will be a response with status 200 OK and a body with the following JSON payload:

{"access_token":"eyJ...xcg"}

This response is the ACR access token which you can inspect with jwt.io. You can now use it to call APIs exposed by the Azure Container Registry

Calling an Azure Container Registry API

Assume you have the following:

  1. A valid container registry, which here we'll call contosoregistry.azurecr.io.
  2. A correctly crafted ACR access token

Here's how a call to an Azure Container Registry API would look like when done via curl:

export registry="contosoregistry.azurecr.io"
export acr_access_token="eyJ...xcg"
curl -v -H "Authorization: Bearer $acr_access_token" https://$registry/v2/_catalog

This should result in a status 200 OK, and a body with a JSON payload listing the repositories held in this registry:

{"repositories":["alpine","hello-world","contoso-marketing"]}

Allows Access Control to enable access to ACR

We currently use the admin user to be able to push/pull images from ACR. We would rather authorize with the AAD, so you could do something like this:

docker login myacs.azurecr.io -u [email protected] -p /o=w0SV+tL+f0GiiF=xd+UPQDINYeNPX

Via IAM this user is assigned contributor access, so it can push/pull images from the repository.

Failing to pull image using a service principal

I am trying to pull an image from ACR within a CI/CD process on Ubuntu 16.04. The output from az --version shows:

azure-cli (2.0.23-1)
acr (2.0.17)

I login using an AAD Service Principal. The service principal login is successful and I can enumerate the list of Azure subscriptions to which it has access. I proceed to loging to ACR using:

sh az acr login --name zapic --resource-group zapic-test-acr

It appears to succeed (exits with a code of 0); however, it prints the following:

WARNING: Unable to get AAD authorization tokens with message: Access to registry 'zapic.azurecr.io' was denied. Response code: 504.

It then fails to pull our Docker image:

docker pull "zapic.azurecr.io/image/name:tag"
Error response from daemon: Get https://zapic.azurecr.io/v2/image/name/manifests/tag: Get https://zapic.azurecr.io/oauth2/token?account=zapic&scope=repository%3Aimage%2Fname%3Apull&service=zapic.azurecr.io: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

Has anyone encountered this before? This was all working yesterday, and there have been no changes to our CI/CD process. I'm a little lost on how to begin to troubleshoot this issue. Any thoughts or guidance are appreciated.

Change to repository description

Please consider changing repository description (text that appears at top and in repo listings) to "Samples, Troubleshooting tips, and a collection of links for Azure Container Registry" instead of just "Azure container registry".

Create an option for deleting "ALL" untagged images (manifests)

If pushing with same tag, the older one's get untagged.

  {
    "digest": "sha256:<your-some-sha-hash>",
    "tags": [],
    "timestamp": "2017-12-26T11:02:03Z"
  },

and which means you can't delete with tag option cause it doesn't have tags.

az acr repository delete -n <CR_NAME> --repository <REPO_NAME> --tag  --manifest
#az acr repository delete: error: argument --tag: expected one argument

az acr repository delete -n <CR_NAME> --repository <REPO_NAME> --tag '' --manifest
# Please specify either a tag name with --tag or a manifest digest with --manifest.

az acr repository delete -n <CR_NAME> --repository <REPO_NAME> --tag [] --manifest
# 404 page not found
# (404? what the hell)

The only option to delete this untagged images is just deleting the repo.

Is there is any way to delete these untagged repos?

build-task create should run after creation

In most cases, creating a build task is not very useful unless it's run.
Without the default run stage, I would either need to manually run it, or make a fake git-commit
we also need run to parse the base image dependencies

Linking Github check-ins to auto generate ACR images

Can I link my github check-ins to automatically generate docker images in the azure container registry? This functionality is provided by Google Cloud Platform so I was wondering if Azure provides it as well.

Improve error message for not found

When az acr repository list --name myreg is run when myreg is not in the current subscription, the following error is returned:

No resource with type Microsoft.ContainerRegistry/registries can be found with name: myreg

It would be more helpful if the error also mentioned the Subscription in question. For example:

No resource with type Microsoft.ContainerRegistry/registries can be found with name: myreg from Subscription: MySubscription.

This will help users much more quickly understand the source of the problem in cases where this is caused by an incorrect default subscription, a scenario mention on the troubleshooting guide.

running az acr build-task create doesn't fail when -n already exists

Running this script multiple times simply updates the build-task. Somewhat interesting, but shouldn't this fail as I wouldn't want to override an existing build task

az acr build-task create \
  -n demo42quotesapi \
  --context https://github.com/demo42/quotes -t demo42/quotes-api:{{.Build.ID}} \
  -f ./src/QuoteService/Dockerfile \
  --git-access-token <redacted> \
  --build-arg NAME=VALUE \
  --registry jengademos 

AAD doc fixes

The commands given in the doc requires some updates.
Would recommend more details in in how to use the token end to end.

Failing pulls from an ACS Kubernetes Cluster

Since a couple of days, we have had sporadical pull failures from our Azure Container Registry (classic) hosted in Europe West from our Kubernetes 1.8.2 cluster we created with acs-engine tooling.

When running a kubectl describe pod, we just see that the cluster is pulling the image, but that it's apparently very slow. Our pipelines cancel the rollout after ten minutes, if the container is not yet up then, as pulling one of our images usually doesn't take more than 1-2 minutes (maximum).

Our container registry has around 180-190 GB of images, and it's been around a while, so it's obviously still a "classic" unmanaged registry. Are you aware of any kind of rate limiting which might kick in? Is there something we can do about it, and/or debug/error trace to see why this happens?

I just triggered an upgrade to a "managed registry", where we'd obviously be willing to pay the "Premium" tier (which is very fairly priced at around 50โ‚ฌ a month, good work!), and hope it gets better with this. How good are chances it will help?

builds listed out of order in build-task list-builds table output

When viewing the list of builds with az acr build-task list-builds [...] -o table, builds that are running aren't listed at the top of the list. This makes it more difficult to notice which build is latest, and which (if any) are currently running.

Example output below. Notice that the currently running build, aa8, is listed after the previous build, aa7.

BUILD ID    TASK             PLATFORM    STATUS     TRIGGER       STARTED               DURATION
----------  ---------------  ----------  ---------  ------------  --------------------  ----------
aa7                                      Succeeded  Manual        2018-04-30T17:59:12Z  00:00:35
aa8         buildhelloworld  Linux       Running    Image Update  2018-04-30T17:59:38Z
aa6         buildhelloworld  Linux       Succeeded  Manual        2018-04-30T17:49:41Z  00:00:55
aa5                                      Succeeded  Manual        2018-04-30T17:46:41Z  00:00:55
aa4         buildhelloworld  Linux       Succeeded  Git Commit    2018-04-30T17:45:05Z  00:00:35
aa3         buildhelloworld  Linux       Succeeded  Manual        2018-04-30T17:42:38Z  00:00:45
aa2         buildhelloworld  Linux       Succeeded  Manual        2018-04-30T17:39:36Z  00:00:40
aa1                                      Succeeded  Manual        2018-04-30T17:26:28Z  00:00:45

acr-build to support Date as a build-arg

Would like to use various date formats in build args, or for image tags

az acr build-task create \
  -n myBuildTask \
  --context https://github.com/demo42/deploy \
  -t baseimages/microsoft/dotnet-sdk:linux-2.1 \
  --build-arg IMAGE_BUILD_DATE=`date +%Y%m%d-%H%M%S` 

Creating container registry in UK South

I get this error

"properties": {
    "statusCode": "BadRequest",
    "serviceRequestId": null,
    "statusMessage": "{\"error\":{\"code\":\"NoRegisteredProviderFound\",\"message\":\"No registered resource provider found for location 'uksouth' and API version '2016-06-27-preview' for type 'registries'. The supported api-versions are '2016-06-27-preview, 2017-03-01, 2017-10-01, 2017-06-01-preview'. The supported locations are 'westus, eastus, southcentralus, westeurope, northeurope, uksouth, ukwest, australiaeast, australiasoutheast, centralindia, eastasia, japaneast, japanwest, southeastasia, southindia, brazilsouth, canadaeast, canadacentral, centralus, eastus2, northcentralus, westcentralus, westus2'.\"}}"
},

VSTS Docker push to ACR / ##[error]unknown

Getting an error on a push from VSTS docker push. I have been building and pushing images without issue for weeks. I also tried deleting many older images but problem still remains.

2018-04-13T20:17:29.0558873Z ##[section]Starting: Push an image
2018-04-13T20:17:29.0645315Z ==============================================================================
2018-04-13T20:17:29.0661341Z Task         : Docker
2018-04-13T20:17:29.0678077Z Description  : Build, tag, push, or run Docker images, or run a Docker command. Task can be used with Docker or Azure Container registry.
2018-04-13T20:17:29.0695225Z Version      : 0.3.11
2018-04-13T20:17:29.0715157Z Author       : Microsoft Corporation
2018-04-13T20:17:29.0731887Z Help         : [More Information](https://go.microsoft.com/fwlink/?linkid=848006)
2018-04-13T20:17:29.0748537Z ==============================================================================
2018-04-13T20:17:29.6747408Z [command]/usr/local/bin/docker push registryremoved/image:119
2018-04-13T20:17:29.8941932Z The push refers to a repository registryremoved/image
2018-04-13T20:17:30.1058378Z 833c64751768: Preparing
2018-04-13T20:17:30.1077986Z c3b1c273e512: Preparing
2018-04-13T20:17:30.1093498Z 5a776eda9f77: Preparing
2018-04-13T20:17:30.1107987Z 9d540b2ec721: Preparing
2018-04-13T20:17:30.1123550Z 77fb8e00cfad: Preparing
2018-04-13T20:17:30.1139074Z f8b21fcb37cf: Preparing
2018-04-13T20:17:30.1158992Z e0736ad33d81: Preparing
2018-04-13T20:17:30.1174122Z c02db22f8b53: Preparing
2018-04-13T20:17:30.1188473Z 3b5e4260d400: Preparing
2018-04-13T20:17:30.1204016Z 0706f78fa8ac: Preparing
2018-04-13T20:17:30.1218770Z 445960985331: Preparing
2018-04-13T20:17:30.1234785Z 602c24687a98: Preparing
2018-04-13T20:17:30.1250190Z 3358360aedad: Preparing
2018-04-13T20:17:30.1269536Z f8b21fcb37cf: Waiting
2018-04-13T20:17:30.1286212Z e0736ad33d81: Waiting
2018-04-13T20:17:30.1302848Z 0706f78fa8ac: Waiting
2018-04-13T20:17:30.1317760Z c02db22f8b53: Waiting
2018-04-13T20:17:30.1332879Z 445960985331: Waiting
2018-04-13T20:17:30.1347395Z 602c24687a98: Waiting
2018-04-13T20:17:30.1366172Z 3358360aedad: Waiting
2018-04-13T20:17:30.1381203Z 3b5e4260d400: Waiting
2018-04-13T20:17:31.4335791Z 77fb8e00cfad: Retrying in 5 seconds
2018-04-13T20:17:31.4356579Z 833c64751768: Retrying in 5 seconds
2018-04-13T20:17:31.4416368Z 5a776eda9f77: Retrying in 5 seconds
2018-04-13T20:17:31.4458866Z 9d540b2ec721: Retrying in 5 seconds
2018-04-13T20:17:31.4485140Z c3b1c273e512: Retrying in 5 seconds
2018-04-13T20:17:32.4336459Z 77fb8e00cfad: Retrying in 4 seconds
2018-04-13T20:17:32.4358497Z 833c64751768: Retrying in 4 seconds
2018-04-13T20:17:32.4417850Z 5a776eda9f77: Retrying in 4 seconds
2018-04-13T20:17:32.4459404Z 9d540b2ec721: Retrying in 4 seconds
2018-04-13T20:17:32.4483305Z c3b1c273e512: Retrying in 4 seconds
2018-04-13T20:17:33.4336640Z 77fb8e00cfad: Retrying in 3 seconds
2018-04-13T20:17:33.4358299Z 833c64751768: Retrying in 3 seconds
2018-04-13T20:17:33.4417077Z 5a776eda9f77: Retrying in 3 seconds
2018-04-13T20:17:33.4460248Z 9d540b2ec721: Retrying in 3 seconds
2018-04-13T20:17:33.4482952Z c3b1c273e512: Retrying in 3 seconds
2018-04-13T20:17:34.4336472Z 77fb8e00cfad: Retrying in 2 seconds
2018-04-13T20:17:34.4357637Z 833c64751768: Retrying in 2 seconds
2018-04-13T20:17:34.4418851Z 5a776eda9f77: Retrying in 2 seconds
2018-04-13T20:17:34.4470852Z 9d540b2ec721: Retrying in 2 seconds
2018-04-13T20:17:34.4489372Z c3b1c273e512: Retrying in 2 seconds
2018-04-13T20:17:35.4338054Z 77fb8e00cfad: Retrying in 1 second
2018-04-13T20:17:35.4358710Z 833c64751768: Retrying in 1 second
2018-04-13T20:17:35.4418261Z 5a776eda9f77: Retrying in 1 second
2018-04-13T20:17:35.4480214Z 9d540b2ec721: Retrying in 1 second
2018-04-13T20:17:35.4496007Z c3b1c273e512: Retrying in 1 second
2018-04-13T20:17:36.6160151Z 833c64751768: Retrying in 10 seconds
2018-04-13T20:17:36.6176849Z 77fb8e00cfad: Retrying in 10 seconds
2018-04-13T20:17:36.6230130Z 5a776eda9f77: Retrying in 10 seconds
2018-04-13T20:17:36.6304161Z c3b1c273e512: Retrying in 10 seconds
2018-04-13T20:17:36.6382957Z 9d540b2ec721: Retrying in 10 seconds
2018-04-13T20:17:37.6163444Z 833c64751768: Retrying in 9 seconds
2018-04-13T20:17:37.6178381Z 77fb8e00cfad: Retrying in 9 seconds
2018-04-13T20:17:37.6233189Z 5a776eda9f77: Retrying in 9 seconds
2018-04-13T20:17:37.6304012Z c3b1c273e512: Retrying in 9 seconds
2018-04-13T20:17:37.6384664Z 9d540b2ec721: Retrying in 9 seconds
2018-04-13T20:17:38.6163268Z 833c64751768: Retrying in 8 seconds
2018-04-13T20:17:38.6182160Z 77fb8e00cfad: Retrying in 8 seconds
2018-04-13T20:17:38.6232086Z 5a776eda9f77: Retrying in 8 seconds
2018-04-13T20:17:38.6303694Z c3b1c273e512: Retrying in 8 seconds
2018-04-13T20:17:38.6385066Z 9d540b2ec721: Retrying in 8 seconds
2018-04-13T20:17:39.6161784Z 833c64751768: Retrying in 7 seconds
2018-04-13T20:17:39.6177183Z 77fb8e00cfad: Retrying in 7 seconds
2018-04-13T20:17:39.6234473Z 5a776eda9f77: Retrying in 7 seconds
2018-04-13T20:17:39.6304211Z c3b1c273e512: Retrying in 7 seconds
2018-04-13T20:17:39.6402358Z 9d540b2ec721: Retrying in 7 seconds
2018-04-13T20:17:40.6170764Z 833c64751768: Retrying in 6 seconds
2018-04-13T20:17:40.6186358Z 77fb8e00cfad: Retrying in 6 seconds
2018-04-13T20:17:40.6234610Z 5a776eda9f77: Retrying in 6 seconds
2018-04-13T20:17:40.6303694Z c3b1c273e512: Retrying in 6 seconds
2018-04-13T20:17:40.6383707Z 9d540b2ec721: Retrying in 6 seconds
2018-04-13T20:17:41.6166105Z 833c64751768: Retrying in 5 seconds
2018-04-13T20:17:41.6190931Z 77fb8e00cfad: Retrying in 5 seconds
2018-04-13T20:17:41.6233883Z 5a776eda9f77: Retrying in 5 seconds
2018-04-13T20:17:41.6303416Z c3b1c273e512: Retrying in 5 seconds
2018-04-13T20:17:41.6385137Z 9d540b2ec721: Retrying in 5 seconds
2018-04-13T20:17:42.6162849Z 833c64751768: Retrying in 4 seconds
2018-04-13T20:17:42.6182311Z 77fb8e00cfad: Retrying in 4 seconds
2018-04-13T20:17:42.6235762Z 5a776eda9f77: Retrying in 4 seconds
2018-04-13T20:17:42.6303663Z c3b1c273e512: Retrying in 4 seconds
2018-04-13T20:17:42.6384339Z 9d540b2ec721: Retrying in 4 seconds
2018-04-13T20:17:43.6165832Z 833c64751768: Retrying in 3 seconds
2018-04-13T20:17:43.6182222Z 77fb8e00cfad: Retrying in 3 seconds
2018-04-13T20:17:43.6231684Z 5a776eda9f77: Retrying in 3 seconds
2018-04-13T20:17:43.6307233Z c3b1c273e512: Retrying in 3 seconds
2018-04-13T20:17:43.6385111Z 9d540b2ec721: Retrying in 3 seconds
2018-04-13T20:17:44.6163269Z 833c64751768: Retrying in 2 seconds
2018-04-13T20:17:44.6178015Z 77fb8e00cfad: Retrying in 2 seconds
2018-04-13T20:17:44.6232556Z 5a776eda9f77: Retrying in 2 seconds
2018-04-13T20:17:44.6304286Z c3b1c273e512: Retrying in 2 seconds
2018-04-13T20:17:44.6385233Z 9d540b2ec721: Retrying in 2 seconds
2018-04-13T20:17:45.6163265Z 833c64751768: Retrying in 1 second
2018-04-13T20:17:45.6179012Z 77fb8e00cfad: Retrying in 1 second
2018-04-13T20:17:45.6231091Z 5a776eda9f77: Retrying in 1 second
2018-04-13T20:17:45.6305065Z c3b1c273e512: Retrying in 1 second
2018-04-13T20:17:45.6384431Z 9d540b2ec721: Retrying in 1 second
2018-04-13T20:17:46.8144859Z 833c64751768: Retrying in 15 seconds
2018-04-13T20:17:46.8160355Z c3b1c273e512: Retrying in 15 seconds
2018-04-13T20:17:46.8175150Z 77fb8e00cfad: Retrying in 15 seconds
2018-04-13T20:17:46.8217048Z 9d540b2ec721: Retrying in 15 seconds
2018-04-13T20:17:46.8240494Z 5a776eda9f77: Retrying in 15 seconds
2018-04-13T20:17:47.8140054Z 833c64751768: Retrying in 14 seconds
2018-04-13T20:17:47.8156818Z c3b1c273e512: Retrying in 14 seconds
2018-04-13T20:17:47.8174132Z 77fb8e00cfad: Retrying in 14 seconds
2018-04-13T20:17:47.8217668Z 9d540b2ec721: Retrying in 14 seconds
2018-04-13T20:17:47.8241913Z 5a776eda9f77: Retrying in 14 seconds
2018-04-13T20:17:48.8144436Z 833c64751768: Retrying in 13 seconds
2018-04-13T20:17:48.8160303Z c3b1c273e512: Retrying in 13 seconds
2018-04-13T20:17:48.8177877Z 77fb8e00cfad: Retrying in 13 seconds
2018-04-13T20:17:48.8217783Z 9d540b2ec721: Retrying in 13 seconds
2018-04-13T20:17:48.8240388Z 5a776eda9f77: Retrying in 13 seconds
2018-04-13T20:17:49.8147617Z 833c64751768: Retrying in 12 seconds
2018-04-13T20:17:49.8164578Z c3b1c273e512: Retrying in 12 seconds
2018-04-13T20:17:49.8180099Z 77fb8e00cfad: Retrying in 12 seconds
2018-04-13T20:17:49.8217706Z 9d540b2ec721: Retrying in 12 seconds
2018-04-13T20:17:49.8240657Z 5a776eda9f77: Retrying in 12 seconds
2018-04-13T20:17:50.8148973Z 833c64751768: Retrying in 11 seconds
2018-04-13T20:17:50.8165420Z c3b1c273e512: Retrying in 11 seconds
2018-04-13T20:17:50.8184079Z 77fb8e00cfad: Retrying in 11 seconds
2018-04-13T20:17:50.8216511Z 9d540b2ec721: Retrying in 11 seconds
2018-04-13T20:17:50.8240935Z 5a776eda9f77: Retrying in 11 seconds
2018-04-13T20:17:51.8144597Z 833c64751768: Retrying in 10 seconds
2018-04-13T20:17:51.8164404Z c3b1c273e512: Retrying in 10 seconds
2018-04-13T20:17:51.8178867Z 77fb8e00cfad: Retrying in 10 seconds
2018-04-13T20:17:51.8217250Z 9d540b2ec721: Retrying in 10 seconds
2018-04-13T20:17:51.8241425Z 5a776eda9f77: Retrying in 10 seconds
2018-04-13T20:17:52.8142727Z 833c64751768: Retrying in 9 seconds
2018-04-13T20:17:52.8160244Z c3b1c273e512: Retrying in 9 seconds
2018-04-13T20:17:52.8181246Z 77fb8e00cfad: Retrying in 9 seconds
2018-04-13T20:17:52.8217576Z 9d540b2ec721: Retrying in 9 seconds
2018-04-13T20:17:52.8244442Z 5a776eda9f77: Retrying in 9 seconds
2018-04-13T20:17:53.8140036Z 833c64751768: Retrying in 8 seconds
2018-04-13T20:17:53.8156884Z c3b1c273e512: Retrying in 8 seconds
2018-04-13T20:17:53.8172059Z 77fb8e00cfad: Retrying in 8 seconds
2018-04-13T20:17:53.8216394Z 9d540b2ec721: Retrying in 8 seconds
2018-04-13T20:17:53.8257834Z 5a776eda9f77: Retrying in 8 seconds
2018-04-13T20:17:54.8140831Z 833c64751768: Retrying in 7 seconds
2018-04-13T20:17:54.8157142Z c3b1c273e512: Retrying in 7 seconds
2018-04-13T20:17:54.8173198Z 77fb8e00cfad: Retrying in 7 seconds
2018-04-13T20:17:54.8217153Z 9d540b2ec721: Retrying in 7 seconds
2018-04-13T20:17:54.8248374Z 5a776eda9f77: Retrying in 7 seconds
2018-04-13T20:17:55.8165142Z 833c64751768: Retrying in 6 seconds
2018-04-13T20:17:55.8190698Z 77fb8e00cfad: Retrying in 6 seconds
2018-04-13T20:17:55.8205921Z c3b1c273e512: Retrying in 6 seconds
2018-04-13T20:17:55.8222588Z 9d540b2ec721: Retrying in 6 seconds
2018-04-13T20:17:55.8240339Z 5a776eda9f77: Retrying in 6 seconds
2018-04-13T20:17:56.8140428Z 833c64751768: Retrying in 5 seconds
2018-04-13T20:17:56.8160062Z c3b1c273e512: Retrying in 5 seconds
2018-04-13T20:17:56.8175301Z 77fb8e00cfad: Retrying in 5 seconds
2018-04-13T20:17:56.8217174Z 9d540b2ec721: Retrying in 5 seconds
2018-04-13T20:17:56.8241446Z 5a776eda9f77: Retrying in 5 seconds
2018-04-13T20:17:57.8141983Z 833c64751768: Retrying in 4 seconds
2018-04-13T20:17:57.8158525Z c3b1c273e512: Retrying in 4 seconds
2018-04-13T20:17:57.8175216Z 77fb8e00cfad: Retrying in 4 seconds
2018-04-13T20:17:57.8217362Z 9d540b2ec721: Retrying in 4 seconds
2018-04-13T20:17:57.8241692Z 5a776eda9f77: Retrying in 4 seconds
2018-04-13T20:17:58.8139121Z 833c64751768: Retrying in 3 seconds
2018-04-13T20:17:58.8157763Z c3b1c273e512: Retrying in 3 seconds
2018-04-13T20:17:58.8174243Z 77fb8e00cfad: Retrying in 3 seconds
2018-04-13T20:17:58.8216161Z 9d540b2ec721: Retrying in 3 seconds
2018-04-13T20:17:58.8241351Z 5a776eda9f77: Retrying in 3 seconds
2018-04-13T20:17:59.8141388Z 833c64751768: Retrying in 2 seconds
2018-04-13T20:17:59.8159363Z c3b1c273e512: Retrying in 2 seconds
2018-04-13T20:17:59.8179557Z 77fb8e00cfad: Retrying in 2 seconds
2018-04-13T20:17:59.8217542Z 9d540b2ec721: Retrying in 2 seconds
2018-04-13T20:17:59.8241097Z 5a776eda9f77: Retrying in 2 seconds
2018-04-13T20:18:00.8142947Z 833c64751768: Retrying in 1 second
2018-04-13T20:18:00.8211963Z c3b1c273e512: Retrying in 1 second
2018-04-13T20:18:00.8253865Z 77fb8e00cfad: Retrying in 1 second
2018-04-13T20:18:00.8269657Z 9d540b2ec721: Retrying in 1 second
2018-04-13T20:18:00.8285455Z 5a776eda9f77: Retrying in 1 second
2018-04-13T20:18:02.0374306Z 5a776eda9f77: Retrying in 20 seconds
2018-04-13T20:18:02.0401309Z 833c64751768: Retrying in 20 seconds
2018-04-13T20:18:02.0423615Z 9d540b2ec721: Retrying in 20 seconds
2018-04-13T20:18:02.0440269Z c3b1c273e512: Retrying in 20 seconds
2018-04-13T20:18:02.0456478Z 77fb8e00cfad: Retrying in 20 seconds
2018-04-13T20:18:03.0391167Z 5a776eda9f77: Retrying in 19 seconds
2018-04-13T20:18:03.0408570Z 833c64751768: Retrying in 19 seconds
2018-04-13T20:18:03.0425180Z 9d540b2ec721: Retrying in 19 seconds
2018-04-13T20:18:03.0442735Z c3b1c273e512: Retrying in 19 seconds
2018-04-13T20:18:03.0460532Z 77fb8e00cfad: Retrying in 19 seconds
2018-04-13T20:18:04.0369294Z 5a776eda9f77: Retrying in 18 seconds
2018-04-13T20:18:04.0390329Z 833c64751768: Retrying in 18 seconds
2018-04-13T20:18:04.0406372Z 9d540b2ec721: Retrying in 18 seconds
2018-04-13T20:18:04.0424007Z c3b1c273e512: Retrying in 18 seconds
2018-04-13T20:18:04.0439901Z 77fb8e00cfad: Retrying in 18 seconds
2018-04-13T20:18:05.0371163Z 5a776eda9f77: Retrying in 17 seconds
2018-04-13T20:18:05.0388968Z 833c64751768: Retrying in 17 seconds
2018-04-13T20:18:05.0405724Z 9d540b2ec721: Retrying in 17 seconds
2018-04-13T20:18:05.0426694Z c3b1c273e512: Retrying in 17 seconds
2018-04-13T20:18:05.0443588Z 77fb8e00cfad: Retrying in 17 seconds
2018-04-13T20:18:06.0369464Z 5a776eda9f77: Retrying in 16 seconds
2018-04-13T20:18:06.0386826Z 833c64751768: Retrying in 16 seconds
2018-04-13T20:18:06.0404291Z 9d540b2ec721: Retrying in 16 seconds
2018-04-13T20:18:06.0420455Z c3b1c273e512: Retrying in 16 seconds
2018-04-13T20:18:06.0436741Z 77fb8e00cfad: Retrying in 16 seconds
2018-04-13T20:18:07.0370666Z 5a776eda9f77: Retrying in 15 seconds
2018-04-13T20:18:07.0395167Z 833c64751768: Retrying in 15 seconds
2018-04-13T20:18:07.0410815Z 9d540b2ec721: Retrying in 15 seconds
2018-04-13T20:18:07.0429510Z c3b1c273e512: Retrying in 15 seconds
2018-04-13T20:18:07.0446516Z 77fb8e00cfad: Retrying in 15 seconds
2018-04-13T20:18:08.0369661Z 5a776eda9f77: Retrying in 14 seconds
2018-04-13T20:18:08.0397082Z 9d540b2ec721: Retrying in 14 seconds
2018-04-13T20:18:08.0415597Z 77fb8e00cfad: Retrying in 14 seconds
2018-04-13T20:18:08.0433488Z c3b1c273e512: Retrying in 14 seconds
2018-04-13T20:18:08.0449263Z 833c64751768: Retrying in 14 seconds
2018-04-13T20:18:09.0370407Z 5a776eda9f77: Retrying in 13 seconds
2018-04-13T20:18:09.0460624Z 9d540b2ec721: Retrying in 13 seconds
2018-04-13T20:18:09.0476685Z 833c64751768: Retrying in 13 seconds
2018-04-13T20:18:09.0492671Z c3b1c273e512: Retrying in 13 seconds
2018-04-13T20:18:09.0508226Z 77fb8e00cfad: Retrying in 13 seconds
2018-04-13T20:18:10.0378245Z 5a776eda9f77: Retrying in 12 seconds
2018-04-13T20:18:10.0397900Z 833c64751768: Retrying in 12 seconds
2018-04-13T20:18:10.0417792Z 9d540b2ec721: Retrying in 12 seconds
2018-04-13T20:18:10.0434606Z c3b1c273e512: Retrying in 12 seconds
2018-04-13T20:18:10.0451768Z 77fb8e00cfad: Retrying in 12 seconds
2018-04-13T20:18:11.0369440Z 5a776eda9f77: Retrying in 11 seconds
2018-04-13T20:18:11.0385625Z 833c64751768: Retrying in 11 seconds
2018-04-13T20:18:11.0399729Z 9d540b2ec721: Retrying in 11 seconds
2018-04-13T20:18:11.0413221Z c3b1c273e512: Retrying in 11 seconds
2018-04-13T20:18:11.0428012Z 77fb8e00cfad: Retrying in 11 seconds
2018-04-13T20:18:12.0369163Z 5a776eda9f77: Retrying in 10 seconds
2018-04-13T20:18:12.0387037Z c3b1c273e512: Retrying in 10 seconds
2018-04-13T20:18:12.0404109Z 833c64751768: Retrying in 10 seconds
2018-04-13T20:18:12.0418815Z 9d540b2ec721: Retrying in 10 seconds
2018-04-13T20:18:12.0438543Z 77fb8e00cfad: Retrying in 10 seconds
2018-04-13T20:18:13.0385114Z 5a776eda9f77: Retrying in 9 seconds
2018-04-13T20:18:13.0406350Z 833c64751768: Retrying in 9 seconds
2018-04-13T20:18:13.0424001Z 9d540b2ec721: Retrying in 9 seconds
2018-04-13T20:18:13.0440796Z c3b1c273e512: Retrying in 9 seconds
2018-04-13T20:18:13.0457336Z 77fb8e00cfad: Retrying in 9 seconds
2018-04-13T20:18:14.0371852Z 5a776eda9f77: Retrying in 8 seconds
2018-04-13T20:18:14.0388137Z 833c64751768: Retrying in 8 seconds
2018-04-13T20:18:14.0404021Z 9d540b2ec721: Retrying in 8 seconds
2018-04-13T20:18:14.0420853Z c3b1c273e512: Retrying in 8 seconds
2018-04-13T20:18:14.0436337Z 77fb8e00cfad: Retrying in 8 seconds
2018-04-13T20:18:15.0371990Z 5a776eda9f77: Retrying in 7 seconds
2018-04-13T20:18:15.0390472Z 833c64751768: Retrying in 7 seconds
2018-04-13T20:18:15.0405805Z 9d540b2ec721: Retrying in 7 seconds
2018-04-13T20:18:15.0422526Z c3b1c273e512: Retrying in 7 seconds
2018-04-13T20:18:15.0437663Z 77fb8e00cfad: Retrying in 7 seconds
2018-04-13T20:18:16.0374699Z 5a776eda9f77: Retrying in 6 seconds
2018-04-13T20:18:16.0394897Z 833c64751768: Retrying in 6 seconds
2018-04-13T20:18:16.0411388Z 9d540b2ec721: Retrying in 6 seconds
2018-04-13T20:18:16.0428571Z c3b1c273e512: Retrying in 6 seconds
2018-04-13T20:18:16.0447128Z 77fb8e00cfad: Retrying in 6 seconds
2018-04-13T20:18:17.0370994Z 5a776eda9f77: Retrying in 5 seconds
2018-04-13T20:18:17.0391463Z 833c64751768: Retrying in 5 seconds
2018-04-13T20:18:17.0409543Z 9d540b2ec721: Retrying in 5 seconds
2018-04-13T20:18:17.0425734Z c3b1c273e512: Retrying in 5 seconds
2018-04-13T20:18:17.0441722Z 77fb8e00cfad: Retrying in 5 seconds
2018-04-13T20:18:18.0368625Z 5a776eda9f77: Retrying in 4 seconds
2018-04-13T20:18:18.0385501Z 833c64751768: Retrying in 4 seconds
2018-04-13T20:18:18.0401327Z 9d540b2ec721: Retrying in 4 seconds
2018-04-13T20:18:18.0417216Z c3b1c273e512: Retrying in 4 seconds
2018-04-13T20:18:18.0434369Z 77fb8e00cfad: Retrying in 4 seconds
2018-04-13T20:18:19.0369275Z 5a776eda9f77: Retrying in 3 seconds
2018-04-13T20:18:19.0385904Z c3b1c273e512: Retrying in 3 seconds
2018-04-13T20:18:19.0405626Z 833c64751768: Retrying in 3 seconds
2018-04-13T20:18:19.0425538Z 77fb8e00cfad: Retrying in 3 seconds
2018-04-13T20:18:19.0442431Z 9d540b2ec721: Retrying in 3 seconds
2018-04-13T20:18:20.0369745Z 5a776eda9f77: Retrying in 2 seconds
2018-04-13T20:18:20.0389175Z 833c64751768: Retrying in 2 seconds
2018-04-13T20:18:20.0405674Z 9d540b2ec721: Retrying in 2 seconds
2018-04-13T20:18:20.0422167Z c3b1c273e512: Retrying in 2 seconds
2018-04-13T20:18:20.0438235Z 77fb8e00cfad: Retrying in 2 seconds
2018-04-13T20:18:21.0370378Z 5a776eda9f77: Retrying in 1 second
2018-04-13T20:18:21.0393690Z 77fb8e00cfad: Retrying in 1 second
2018-04-13T20:18:21.0413295Z 833c64751768: Retrying in 1 second
2018-04-13T20:18:21.0427552Z 9d540b2ec721: Retrying in 1 second
2018-04-13T20:18:21.0443063Z c3b1c273e512: Retrying in 1 second
2018-04-13T20:18:22.2360036Z unknown: The operation is disallowed.
2018-04-13T20:18:22.2543047Z ##[error]unknown: The operation is disallowed.
2018-04-13T20:18:22.2626543Z ##[error]/usr/local/bin/docker failed with return code: 1
2018-04-13T20:18:22.3480874Z ##[section]Finishing: Push an image

Webhook - Play it again...

When troubleshooting build/release issues, it would be great to run the same webhook again.

reasoning

A release is likely based on the image:tag combination. So, you can't just trigger a release without the information it needs.
In the idempotent, unlreiable microservice world, it would be great to right-click on a specific webhook execution, and say, 'play again'
This would save me from having to docker pull, docker push the same tag again.

Provisioning VM for custom domains hangs during script start

I used the scripts and template in the custom-domain to set up a VM in Azure to forward traffic to ACR to have our own customer domain.

The running of the deployment template just seems to hang in this loop in deploy-nginx-docker.sh:

## Docker installation extension installs docker in the background
## So we cannot make assumption about its completion time
until docker-compose up
do
    sleep 10
done

I verified that by logging in to the VM and looking at running commands.

Everything else seems to be set up correctly.
After killing the stuck task I just ran docker-compose up -d and everything seems to run smoothly

docker pull failed by "unauthorized"

Though I could log in and push an image to ACR repository, I failed to pull the same image.

$ sudo docker push example.azurecr.io/nginx:latest
The push refers to a repository [example.azurecr.io/nginx]
af5bd3938f60: Pushed 
29f11c413898: Pushed 
eb78099fbf7f: Pushed 
latest: digest: sha256:788fa27763db6d69ad3444e8ba72f947df9e7e163bad7c1f5614f8fd27a311c3 size: 948

$ sudo docker pull example.azurecr.io/nginx:latest
Trying to pull repository example.azurecr.io/nginx ... 
unauthorized: authentication required

I wonder my docker version is 1.12, which is the stable latest version at Fedora 25.

$ sudo docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-common-1.12.6-7.gitae7d637.fc25.x86_64
 Go version:      go1.7.6
 Git commit:      ae7d637/1.12.6
 Built:           Tue Jul 18 16:18:12 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-common-1.12.6-7.gitae7d637.fc25.x86_64
 Go version:      go1.7.6
 Git commit:      ae7d637/1.12.6
 Built:           Tue Jul 18 16:18:12 2017
 OS/Arch:         linux/amd64

Is there any limitation of docker version?

ACR does not support logging in with an application identifier_uri

Summary:
ACR does not support logging in with an application identifier_uri (aka, a non-GUID client_id).

Observation:

$ docker login --username http://colemick-acs-kube-sp --password '[redacted]' testperma1registry-microsoft.azurecr.io
Error response from daemon: login attempt to https://testperma1registry-microsoft.azurecr.io/v2/ failed with status: 401 Unauthorized

$ docker login --username '4e814388-d2e5-4045-9c54-0afb2e8a5e65' --password '[redacted]' testperma1registry-microsoft.azurecr.io
Login Succeeded

Problem:
Those are both valid client_ids for the same application. ACR should allow me to login with both identifiers.

Creating ACR registry: throws error Error creating ACR. Please try again later. Response from az was not json: b''.

I am trying to create aml environment using DSVM. and when I run aml env setup I get the following error....

Subscription set to Azure Pass
Continue with this subscription (Y/n)? y
Resource group devmlrg already exists, skipping creation.
Registering is still on-going. You can monitor using 'az provider show -n Microsoft.Storage'
Creating storage account devmlstor.
Registering is still on-going. You can monitor using 'az provider show -n Microsoft.ContainerRegistry'
Creating ACR registry: devmlacr (please be patient, this can take several minutes)
Error creating ACR. Please try again later. Response from az was not json: b''.

Any suggestions that would help to resolve the issue??

Thanks

az acr repository delete --tag ... not working as expected

Probably more a question than an issue... when trying to delete some old tags within az acr repository client, doesn't work and I don't get any response from az acr client.

The command I'm using:

az acr repository delete -n myacr --resource-group=myrg --repository myrepo --tag mytag --manifest -y

If I don't pass the --manifest param the tag gets deleted but I don't get free space... when passing --manifest as param some times it deletes the image (and I get free space) and sometimes it gets 'freeze', don't get any response, the tag isn't deleted and my script fails... Happens to me with many tags... i'm missing something or it's an acr bug?

I don't find any suitable doc that can help me to understand what happens with this tags, if anyone here can help..

PowerShell commandlets for ACR

It seems that ACR can only be managed via AZ CLI 2.0, but almost all other services also have Powershell cmdlets. We have completely standardized on PowerShell, but we need to install AZ CLI 2.0 to deal with ACR.

When Admin user is not enabled Repositories are not searchable.

We setup a registry and configured service principals to push and pull images, but we cannot find a way to list what images are in the repository.

When attempting to view repositories in the azure portal we see this message:
Admin user is not enabled. Enable admin user in Access keys blade to view repositories.

We tried from the docker CLI like this.
docker login reg.azurecr.io
docker search reg.azurecr.io

and we always receive this message:
Error response from daemon: Unexpected status code 404

Your blog post on ACR user accounts indicates that the Admin User is a temporary approach that will go away in the future. Are we correct in assuming that enabling the Admin User is currently the only way to view what images are in the registry?

Call ACR APIs using empty GUID and refresh token via basic auth

I just acquired an ACR refresh token programmatically, and I can do docker login and docker pull with empty GUID and this refresh token. However, when I try to call ACR APIs using these credentials, such as https://${registryUrl}/v2/_catalog, I still encounter "401 unauthorized" error. Does ACR support calling APIs using empty GUID and refresh token via basic auth? Or did I miss something?

Using IIS ARR Proxy (instead of nginx/docker/vm) fails on pull with 502.3 "The server returned an invalid or unrecognized response"

Hi, I'm trying to use IIS ARR proxy for ACR (locally for now, the plan was to deploy on Azure App Service). I can login fine, do a 'GET http://localhost/v2' but docker pull fails and so does 'GET http://localhost/v2/sitecore/blobs/sha256:74999096977bb95e29d7368cb1b84070895c0e35f64515959a70b7b9db21688d'.

My web.config looks like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.webServer>
        <httpErrors errorMode="Detailed" />
        <rewrite>
            <rules>
                <rule name="Proxy" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="https://someregistry.azurecr.io/{R:1}" />
                    <serverVariables>
                        <set name="HTTP_ACCEPT_ENCODING" value="" />
                        <set name="HTTP_HOST" value="someregistry.azurecr.io" />
                        <set name="HTTP_X_REAL_IP" value="{REMOTE_ADDR}" />
                        <set name="HTTP_X_FORWARDED_FOR" value="{REMOTE_ADDR}" />
                        <set name="HTTP_X_FORWARDED_PROTO" value="https" />                        
                    </serverVariables>
                </rule>
            </rules>
            <allowedServerVariables>
                <add name="HTTP_HOST" />
                <add name="HTTP_ACCEPT_ENCODING" />
                <add name="HTTP_X_REAL_IP" />
                <add name="HTTP_X_FORWARDED_FOR" />
                <add name="HTTP_X_FORWARDED_PROTO" />
            </allowedServerVariables>
        </rewrite>
    </system.webServer>
</configuration>

Is this even possible to do with IIS ARR?

Docker login is not working on windows to my container registry

When I try a docker login I get this error on my windows 10 machine:

Error response from daemon: Get https://.azurecr.io/v2/: net/http: request canceled while waiting for a connection (Client.Timeout exceeded while awaiting headers)

Doing the same docker login command on ubuntu works seamlessly.

Any idea? Docker version of Windows

Docker version 17.12.0-ce, build c97c6d6

az acr repository show-manifests very, very slow

For larger repositories in an ACR, the Azure CLI command az acr repository show-manifests is extremely slow. While show-tags is fairly quick (under 30 seconds), show-manifests sometimes takes several minutes to finish. In some cases, I had to cancel the request after almost 30 minutes.

Granted, those repositories have never been cleaned up (see issue #82), and that's what I am currently trying to do. Some repositories have several hundred tags, and as such also an amount of manifests in the same order of magnitude.

Still, this seems to be too slow. Is this a known issue, is there something one can do about it?

Addendum: It seems as if it's really the call to GET //v2/_acr/<repository>/manifests/list?n=20 which is really slow for certain of the larger repositories. This means I currently can't really clean things up efficiently. For the smaller repos, it works, but there seems to be some kind of O(n^2) thing in here (or even worse) which makes it too slow for repos having lots of manifests.

build-task --build-arg and --secret-build-arg should support Azure Keyvault

Rather than having to pass in static values to build-task create, i'd like to pass in a reference to a keyvault secret.

az acr build-task create \
  -n demo42quotesapi \
  --context https://github.com/demo42/quotes \
  -t demo42/quotes-api:{{.Build.ID}} \
  -f ./src/QuoteService/Dockerfile \
  --git-access-token '{{ .Source=AzureKeyVault \
                        .Vault.Name=$AKV_NAME \
                        .Vault.Secret=$GIT_TOKEN_NAME }}' \
  --build-arg REGISTRY_NAME=$REGISTRY_NAME \
  --secret-build-arg A_CONNECTIONSTRING={{ .Source=AzureKeyVault \
                        .Vault.Name=$AKV_NAME \
                        .Vault.Secret=demo42-quotes-sql-connectionstring-eastus }} \
  --registry $ACR_NAME 

Enable obtaining authorization tokens for ACR

ACR login currently does a handshake with the ACR oauth2 provider. The token is then used to login on the machine which runs the command. In cases when this credential has to be handed off as a secret into another VM or K8s cluster, we want to be able to generate this token without actually doing a docker login.

az acr credential get-authorization-token

Optionally pass in the scope or an an existing access token which can be used to obtain a token based on the access token passed in. For e.g. using MSI.
We also need to consider extending this command to support generating tokens for SAS kind of scenarios.

/cc @DavidObando @shhsu

Prepare documentation for ACR and AAD integration

Azure Container Registry integration with Azure Active Directory

The Azure Container Registry allows users to manage a private Docker registry on the cloud. Our service enables customers to store and manage container images across all types of Azure deployments, keep container images near deployments to reduce latency and costs, maintain Windows and Linux container images in a single Docker registry, use familiar, open-source Docker command line interface (CLI) tools, and simplify registry access management with Azure Active Directory.

The integration of Azure Container Registry with Azure Active Directory is crucial in order to enable transparent authentication and authorization of users and headless services using AAD credentials. In this scenario, a user will only have to use their AAD credentials to log-in to their private registry, and the Azure Container Service will take care of the authorization validation of each operation using the provided credentials.

Under the hood Azure Container Service utilizes the oauth2 authorization protocol, as described by the Docker Registry v2 authentication via central service documentation as well as the Docker Registry v2 Bearer token specification. The JWT tokens generated by the Azure Container Registry are easy to observe in jwt.io.

Logging into a registry

The process to log in to the registry, from the user's perspective, is simple. The user will use the Microsoft Azure CLI 2.0:

az acr login -n contosoregistry

Internally, the CLI will follow these steps:

  1. Calls to Azure Resource Manager to resolve the login server for the specified registry.
  2. Obtains refresh credentials from the profile in use. For a headless call, this will give you the registered SPN, for a regular user this will give you a refresh token.
  3. Makes an HTTPS GET call to the registry server's /v2 endpoint, without credentials. A bearer token authentication challenge is expected, specifying realm and service values. The realm contains the authentication server's URL.
  4. Makes an HTTPS POST call to the authentication server's /oauth2/exchange endpoint, with a body indicating the grant type, the service, the tenant, and the credentials.
  5. From the server's response, we extract an Azure Container Registry refresh token.
  6. Pass the refresh token as the password to the Docker CLI, using a null GUID as the username and calling docker login. From here on, the docker CLI takes care of the authorization cycle using oauth2.

At the end Docker will store the refresh token and go through the oauth2 flow on each operation it does against the Azure Container Registry.

Listing a repository

The Microsoft Azure CLI 2.0 allows users to also list the repositories registries, and list tags for a repository in a registry. Here's how users can achieve listing the repositories in a registry:

az acr repository list -n contosoregistry

Internally, the CLI will follow these steps:

  1. Calls to Azure Resource Manager to resolve the login server for the specified registry.
  2. Obtains refresh credentials from the profile in use. For a headless call, this will give you the registered SPN, for a regular user this will give you a refresh token.
  3. Makes an HTTPS GET call to the registry server's /v2 endpoint, without credentials. A bearer token authentication challenge is expected, specifying realm and service values. The realm contains the authentication server's URL.
  4. Makes an HTTPS POST call to the authentication server's /oauth2/exchange endpoint, with a body indicating the grant type, the service, the tenant, and the credentials.
  5. From the server's response we extract an Azure Container Registry refresh token.
  6. Makes an HTTPS POST call to the authentication server's /oauth2/token endpoint, with a body indicating the grant type, the service, the scope, and the Azure Container Registry refresh token.
  7. From the server's response we extract an Azure Container Registry access token.
  8. Makes an HTTPS GET call to the registry server's /v2/_catalog endpoint using the access token as the bearer token.
  9. Obtains the data from the service and displays it.

When listing the tags of a repository, every step above is the same except for the call to the endpoint that gives the tags which is /v2/contosoregistry/tags/list instead of /v2/_catalog.

Azure Container Registry Refresh Token and Access Token

Let's follow an example call to list a repository:

az acr repository list -n contosoregistry

This will produce a JWT refresh token with the following payload:

{
  "jti": "365e3b5b-844e-4a21-a38c-4d8aebdd6a06",
  "nbf": 1488413863,
  "exp": 1488417456,
  "iat": 1488413863,
  "iss": "Azure Container Registry",
  "aud": "contosoregistry-contoso.azurecr.io",
  "version": "1.0",
  "grant_type": "refresh_token",
  "tenant": "f686d426-8d16-42db-81b7-ab578e110ccd",
  "credential": "AQA...iAA"
}

Followed by an access token with the following payload:

{
  "jti": "ec425c1e-7eda-4f70-adb5-19f927e34a41",
  "nbf": 1488413866,
  "exp": 1488417464,
  "iat": 1488413866,
  "iss": "Azure Container Registry",
  "aud": "contosoregistry-contoso.azurecr.io",
  "access": [
    {
      "type": "registry",
      "name": "catalog",
      "actions": [
        "*"
      ]
    }
  ]
}

Storage account not found error

when we try to create ACR using a given storage account, the operation fails with "BadRequest":

"message": "Storage account xxxx was not found in subscription xxxx."

However the storage account is there already, both ACR and storage account are created under ARM.

Is this a known issue?

Warning: failed to get default registry endpoint from daemon

I have created a new Container Registry and, using the Cloud Shell, am unable to connect to it using az acr login --name .
I get the following message:
"Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?). Using system default: https://index.docker.io/v1/
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"

Migration from Classic to Basic/Standard/Premium takes a long time and/or fails

We've been working to transition from Classic Azure Container Registries, which use a storage account in the customers subscription, to a fully managed Azure Container Registry.
For more info on the different SKUs and why you'd want to migrate to the managed Basic, Standard and Premium SKUs, please see http://aka.ms/acr/skus

We've found customers with large or older registries are either taking a long time, 24+ hours, or they fail.
We've identified throttling and bugs related to the blob copying of storage accounts between a customer's subscription and the managed ACR storage accounts.

We're working with the storage team to resolve 2 underlying bugs. Unfortunately, since Storage is a core service of Azure, rolling out a change takes time to adhere to safe deployment practices.

While SKU migration is available in the az CLI, we have not yet enabled migration in the Azure Portal. Once we have more customer validations and confidence, we'll enable the portal.

The bugs impact the speed and reliability of the copy, but do not impact the source storage account. While migration is running, docker push is blocked. However, all docker login and pull operations continue to function. Since migration is a copy of the Classic storage account, there is no risk of data loss. If the migration fails, your classic registry will be fully intact.

If you wish to take advantage of the managed registry features, and your registry has fewer than 500 image/tags, you can initiate
az acr update --name standard. Once in the managed registry, you can easily move between basic, standard and classic.

If migration takes longer than 3 hours, it's likely the migration will not succeed. Please contact support and request cancelling the migration. Please provide the login url: yourregistry.azurecr.io

We realize the critical importance of providing a scalable, reliable container registry and we're working hard to provide the best possible experience. We apologize for any inconvenience and appreciate our patient, early adopter customers that have been impacted.

We'll provide further updates as we have the fix rolled out.
Steve

build-task dependencies output to include git-commit id

acr-build task currently outputs the build dependencies

ACR Builder discovered the following dependencies:
- image:
    registry: jengademos.azurecr.io
    repository: helloworld
    tag: aa80
    digest: sha256:f257b21ed4d1a1932d43f3957xxxxxxxxxxxxxx
  runtime-dependency:
    registry: jengademos.azurecr.io
    repository: baseimages/node
    tag: "9"
    digest: sha256:429e5c0d83f228xxxxxxxxxxxxxx
  git:
    git-head-revision: aad96c38ee0a02ed8730b9856d65f132abc652b7

Can we add git-commit id?

  git:
    git-head-revision: aad96c38ee0a02ed8730b9856d65f132abc652b7
    git-commit skdkddk

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.