Environment
Azure ML Environments are used to define the containers where your code will run. In the simplest case you can add custom Python libraries using pip, Conda or directly via the Azure ML Python SDK. If more customization is necessary you can use custom docker images.
This page provides examples creating environments:
- From pip
requirements.txt
file - From Conda
env.yml
file - Directly via the Azure ML Python SDK
- From custom Docker image
#
Azure ML Managed Python Environments#
From pipCreate Environment from pip requirements.txt
file
#
From CondaCreate Environment from Conda env.yml
file
#
In Azure ML SDKUse the CondaDependencies
class to create a Python environment in directly with the Azure ML
Python SDK:
#
Custom docker image / dockerfileTo create an Environment
from a custom docker image:
For example Azure Container Registry addresses are of the form "<acr-name>.azurecr.io"
.
Never check in passwords. In this example we provide the password via an environment variable.
To create an Environment
from a dockerfile:
Remarks.
user_managed_dependencies = True
: You are responsible for installing all necessary Python libraries, typically in your docker image.interpreter_path
: Only used whenuser_managed_dependencies=True
and sets the Python interpreter path (e.g.which python
).
It is possible to have Azure ML manage your Python installation when providing a custom base image. For example, using pip requirements.txt
:
Note. In this case Python libraries installed in Dockerfile
will not be available.
#
Build custom docker image for Azure MLWe strongly recommend building your docker image from one of the Azure ML base images available here: AzureML-Containers GitHub Repo - like this:
These images come configured with all the requirements to run on Azure ML.
If user wants to build from scratch, here are a list of requirements and recommendations to keep in mind:
- Conda: Azure ML uses Conda to manage python environments by default. If you intend to allow Azure ML to manage the Python environment, Conda is required.
- libfuse: Required when using
Dataset
- Openmpi: Required for distributed runs
- nvidia/cuda: (Recommended) For GPU-based training build image from nvidia/cuda
- Mellanox OFED user space drivers (Recommend) For SKUs with Infiniband
We suggest users to look at the dockerfiles of Azure ML base images as references.
#
Use custom image from a private registryAzure ML can use a custom image from a private registry as long as login information are provided.
#
Environment Management#
Registered EnvironmentsRegister an environment env: Environment
to your workspace ws
to reuse/share with your team.
Registered environments can be obtained directly from the workspace handle ws
:
This dictionary contains custom environments that have been registered to the workspace as well as a collection of curated environments maintained by Azure ML.
#
Example.#
Save / Load EnvironmentsSave an environment to a local directory:
This will generate a directory with two (human-understandable and editable) files:
azureml_environment.json
: Metadata including name, version, environment variables and Python and Docker configurationconda_dependencies.yml
: Standard conda dependencies YAML (for more details see Conda docs).
Load this environment later with
#
Environment VariablesTo set environment variables use the environment_variables: Dict[str, str]
attribute. Environment variables
are set on the process where the user script is executed.
#
Hints and tipsWhen the conda dependencies are managed by Azure ML (user_managed_dependencies=False
, by default), Azure ML will check whether the same environment has already been materialized into a docker image in the Azure Container Registry associated with the Azure ML workspace. If it is a new environment, Azure ML will have a job preparation stage to build a new docker image for the new environment. You will see a image build log file in the logs and monitor the image build progress. The job won't start until the image is built and pushed to the container registry.
This image building process can take some time and delay your job start. To avoid unnecessary image building, consider:
- Register an environment that contains most packages you need and reuse when possible.
- If you only need a few extra packages on top of an existing environment,
- If the existing environment is a docker image, use a dockerfile from this docker image so you only need to add one layer to install a few extra packagers.
- Install extra python packages in your user script so the package installation happens in the script run as part of your code instead of asking Azure ML to treat them as part of a new environment. Consider using a setup script.
Due to intricacy of the python package dependencies and potential version conflict, we recommend use of custom docker image and dockerfiles (based on Azure ML base images) to manage your own python environment. This practice not only gives users full transparency of the environment, but also saves image building times at agile development stage.
#
Build docker images locally and push to Azure Container RegistryIf you have docker installed locally, you can build the docker image from Azure ML environment locally with option to push the image to workspace ACR directly. This is recommended when users are iterating on the dockerfile since local build can utilize cached layers.
#
Bootstrap ScriptIt can be useful to invoke a bootstrap.sh
script for faster development. One typical example
would be to modify the Python installation at runtime to avoid frequent image rebuilding.
This can be done quite simply with commands. First set up your bootstrap.sh
script.
To have this run ahead of your training script train.py
make use of the command:
See Running Code in the Cloud for more details on ScriptRunConfig
.
#
Distributed bootstrappingIn some cases you may wish to run certain parts of your bootstrap.sh
script
on certain ranks in a distributed setup. This can be achieved with a little care
as follows:
This script will wait for local rank 0 ($AZ_BATCHAI_TASK_INDEX
) to create its MARKER
file
before the other processes continue.
#
Use Keyvault to pass secrets#
Workspace Default KeyvaultEach Azure workspace comes with a keyvault (you can find this in the Azure Portal under the same resource group as your Workspace).
This can be used both to get and set secrets:
#
Generic Azure KeyvaultOf course you can also make use of other keyvaults you might have in Azure.
Be sure to add azure-identity
and azure-keyvault
to your projects requirements in
this case.