Azure Container Registry

# Automate OS & Framework Patching with ACR Tasks

ACR Tasks provide a container centric compute primitive, focused on building and patching container workloads.

ACR Tasks are a series of steps representing execution of one or more containers, using the container as the execution environment. ACR Tasks are defined with a .yaml file, identifying the steps and the dependencies each steps has upon another.

Through ACR Tasks, developers can:

  • build containers using familiar syntax of docker build
  • push newly built images to a registry, including ACR, Docker hub and other private registries.
  • cmd to run a container as a function, enabling parameters passed to the container [ENTRYPOINT]. cmd supports run parameters including volumes and other familiar docker run parameters, enabling unit and functional testing with concurrent container execution.

# ACR Build and ACR Tasks

ACR Build (opens new window), (generally available September 2018), is the pre-cursor of ACR Tasks, focusing on a single step that builds and optionally pushes the built image.

ACR Tasks adds the ability to break up the building of an image into more composable steps. With ACR Task steps, users have more granular control over building their images, while adding testing capabilities, all within the ACR Task compute environment.

# ACR Task Common Scenarios

The most common scenarios include:

  • Building, tagging and pushing 1 or more container images; in series or in parallel.
  • Running and capturing unit test and code coverage results.
  • Running and capturing functional tests. ACR Tasks supports running multiple container,s executing a series of requests between them.
  • Task based execution, including pre/post steps of a container build.
  • Deploying 1 or more containers with your favorite deployment engine to your target environment.

ACR Tasks can be as simple as building a single image:

version: 1.0.0
steps:
  - build: -t {{.Run.Registry}}/hello-world:{{.Run.ID}} .
  - push: ["{{.Run.Registry}}/hello-world:{{.Run.ID}}"]
1
2
3
4

To more complex build, test, helm package, helm deploy scenarios:

version: 1.0.0
steps:
  - id: build-web
    build: -t {{.Run.Registry}}/hello-world:{{.Run.ID}} .
    when: ["-"]
  - id: build-tests
    build: -t {{.Run.Registry}}/hello-world-tests ./funcTests
    when: ["-"]
  - id: push
    push: ["{{.Run.Registry}}/helloworld:{{.Run.ID}}"]
    when: ["build", "build-tests"]
  - id: hello-world-web
    cmd: {{.Run.Registry}}/helloworld:{{.Run.ID}} 
  - id: funcTests
    cmd: {{.Run.Registry}}/helloworld:{{.Run.ID}} 
    env: host=helloworld:80
    when: ["hello-world-web"]
  - cmd: {{.Run.Registry}}/functions/helm package --app-version {{.Run.ID}} -d ./helm ./helm/helloworld/
    when: ["funcTests"]
  - cmd: {{.Run.Registry}}/functions/helm upgrade helloworld ./helm/helloworld/ --reuse-values --set helloworld.image={{.Run.Registry}}/helloworld:{{.Run.ID}}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# ACR Tasks Support the 3 Primary Phases of Development

ACR Tasks highlight 3 phases of container life cycle management.

  • Inner Loop Development - Before developers git-commit their code, they can test their container builds and tasks with az acr task run .
  • Team based commits - Whether a team of 1, or 100, as git commits are made, tasks can be triggered for execution. See az acr task create for establishing trigger based execution.
  • Post development, OS & Framework Patching - When developing and deploying containers, the means to patch a container involves rebuilding the image, testing and deploying the newly built and tested images. ACR Tasks support base image update triggers, enabling a task to run as the runtime or buildtime dependent images are updated.

# ACR Tasks Support Simple to Complex Workloads, Integrating with CI/CD Solutions

Many developers may find ACR Tasks meets their needs. As the complexity increases, or users which to integrate into their existing CI/CD solutions, ACR Tasks can be integrated with CI/CD pipelines getting the benefits of fast, cloud native container execution, with the robust capabilities of other CI/CD solutions.

# Scoping and Positioning ACR Tasks With Other Azure Container Primitives

As containers continue to become the common unit of custom and ISV code deployment (opens new window), Azure container hosting continues to expand. ACR Tasks are intended to fill a gap between ACI, AKS, Batch, App Services and other Azure Services. ACR Tasks are focused on short lived execution, with multi-tenant isolation capabilities. Customers building and testing their containers should have performance similar to local builds. This includes task execution queuing, scheduling, streaming of logs.

Note: performance will continue to increase as other features come online.

However, we don't know what we don't know, and we seek your feedback:

# ACR Tasks Preview Feedback

ACR Tasks evolved from the container life cycle management efforts, focusing on OS & Framework patching of containers (opens new window). For containers to evolve past the complexity of patching and testing virtual machines, ACR Build required the ability to run test containers. As we explored various options, we focused on the simplicity of running a container, passing in arguments and letting the developer choose what and how they wish to run their tests. The ability to run containers, for short lived bursts, at cloud scale is core to ACR Tasks. This primitive has exposed other possibilities and we seek your feedback.

# Next steps

To learn more about ACR Tasks, drill into the following topics:

[!div class="nextstepaction"]

← Deploy with ARM templates →