Build Docker Image

[John0x]

Hi, using AWS CDK (the aws equivalent to bicep) you can actually build a docker image from a local dockerfile when defining a resource.

image: ecs.ContainerImage.fromAsset("../")

Is that possible with bicep as well?
Usecase:
I want to run a cronjob in the azure cloud using my Dockerfile. I could build that image in a different step, but I really like that CDK solves that problem.

[kevball2]

Closest you would get in would be using a Deployment script in your Bicep file (https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-script-bicep) I would suggest that the building of your docket image would be better suited as a separate step during a CI/CD pipeline.

[John0x]

Yep, the production version will use CI, but for now I would like to recreate my AWS setup, since I would like to switch to azure as soon as possible.
ACR Tasks seem to be something similar: https://docs.microsoft.com/en-us/azure/container-registry/container-registry-quickstart-task-cli
Can I use that from within bicep?

I found the "Microsoft.ContainerRegistry/registries/tasks" resource but I can't find any option to recreate the multi step yaml files.
(build docker file -> then execute in azure)

Like the following but with bicep:
https://github.com/Azure-Samples/acr-tasks/blob/master/build-run-hello-world.yaml

[kevball2]

You could

param utcValue string = utcNow()

resource acrDeploy 'Microsoft.Resources/deploymentScripts@2020-10-01' = {
  name: 'acrDeploy'
  location: resourceGroup().location
  kind: 'AzureCLI'
  properties: {
    forceUpdateTag: utcValue
    azCliVersion: '2.28.0'
    timeout: 'PT30M'
    scriptContent: 'az acr build --image sample/hello-world:v1 --registry myContainerRegistry008 --file Dockerfile .'
    cleanupPreference: 'OnSuccess'
    retentionInterval: 'P1D'
  }
}

I am not 100% if that command would wait for your docker image to build before it deployed though. Check out the DeploymentScriptsAPI for more properties you may need as well. The previous article I listed has some samples for AZ CLI and powershell too.

[abossard]

Why is this an accepted answer? I doubt it would work; from where would the execution have access to the files?

This does work though:
https://github.com/Azure/bicep-registry-modules/blob/main/modules/deployment-scripts/build-acr/README.md

[John0x]

Thanks @kevball2
But shouldn't it be possible to recreate something like:
https://docs.microsoft.com/en-us/azure/container-registry/container-registry-tasks-multi-step
https://github.com/Azure-Samples/acr-tasks/blob/master/build-run-hello-world.yaml

With bicep?

[kevball2]

Any of the AZ cli commands that they have in the quick start should work in the deployment script (Though there may be limitations I haven't run into)

Another option would be looking at the Container Registry API scheme, there are Build Tasks that could be used to do everything in Bicep. I think using the AZ CLI with the deployment script would be the quickest option to add it to a Bicep deployment

[alex-frankel]

@John0x - from what I can tell, the az cli command that @kevball2 suggested is functionally equivalent to the github action you are referencing. I don't believe there is a way to consume the literal yaml in code in the same way that you can in a pipeline -- is that what you are looking for?

[John0x]

I really prefer the way that aws solved this. Just having a flag/property that sets the path for the Dockerfile, which will then automatically be built during deployment.

[alex-frankel]

cc @rynowak who has been experimenting with how Bicep could be used as a build tool. Definitely just in the proposal stage right now, but interesting to think more about.

As of now, Bicep doesn't do any complex client-side operations like building a docker image. It only "transpiles" from Bicep code to ARM JSON code, so this would be a major expansion of functionality for bicep if we were to implement it. I'm going to convert this to an issue so it has more visibility.

[John0x]

I'd definitely recommend supporting it. From a user perspective, I can say, that it's pretty handy.
Pulumi supports it as well

[rynowak]

This is an idea that I spent a while playing with for Bicep about 9 months ago - I even got to the point of building a prototype for it.

The concept was that there's a special type of annotation that's processed by the client. The transformation turns the annotation into a variable during build/compile, and that variable is scoped to the resource.

@build('dotnet', '../myproject.csproj')
resource container 'some awesome resource type' = {
  properties: {
    image: build.output.image
  }
}

There are some problems with this that I hadn't really solved:

• How does this play with modules? A feature like this is best used where "actions" happen during deployment not compilation, however local paths are going to be common.
• Passing complex config into one of this is going to be annoying