jsacapdev/azure-cli repository overview

⁠azure-cli

An image with the Azure Cli. The reasoning behind this is to have a common interface that allows Azure Cli commands to be scripted in a powershell context.

To achieve this for debian, install the cli and also use dotnet core base image which is what x-plat powershell relies on.

To achieve this for windows, just install the cli (you get powershell for free). This image is massive, but I couldnt use Nano because the azure cli installer is a msi.

Another reason for this container is to use it as a staging area (build, run, destroy). In theory your RM operations can be performed using the Azure CLI and its build system agnostic (the container has all the dependencies already installed).

⁠Build Status

⁠Build image

docker build --tag jsacapdev/azure-cli -f Dockerfile .

docker build --tag jsacapdev/azure-cli -f Windows.Dockerfile .

⁠To play

docker run -it --rm jsacapdev/azure-cli:1.0 powershell.exe

⁠Run in the context of an automated deploy (lets say):

docker run -t -v "<LOCAL_MOUNT>:<CONTAINER_MOUNT>:rw" -e <SOME_ENV>=<CONTAINER_ENV> --rm jsacapdev/azure-cli:1.0 powershell.exe / pwsh "<PATH TO A SCRIPT?>"

This command wont work if you copy and paste it, so notes on the above are:

-v -> This a volume mount so your running container can access, for example, a script that you run to build out your env

-e -> Some env variables that you want to pass from the host running the container to the container i.e. a service principal (advise: make sure your service principal isnt displayed as part of your build logs and isnt easily available in general)

<PATH TO A SCRIPT> -> Maybe a path to your script that was mounted above?

⁠Contributing

• Fork it!
• Clone it!
• Create your feature branch: git checkout -b my-new-feature
• Commit your changes: git commit -am 'Add some feature'
• Push to the branch: git push origin my-new-feature
• Submit a pull request :D