Azure ml environment

Azure ml environment DEFAULT

Environment Class

Configures a reproducible Python environment for machine learning experiments.

An Environment defines Python packages, environment variables, and Docker settings that are used in machine learning experiments, including in data preparation, training, and deployment to a web service. An Environment is managed and versioned in an Azure Machine Learning Workspace. You can update an existing environment and retrieve a version to reuse. Environments are exclusive to the workspace they are created in and can't be used across different workspaces.

For more information about environments, see Create and manage reusable environments.

Inheritance

azureml._base_sdk_common.abstract_run_config_element._AbstractRunConfigElement

Environment

Constructor

Parameters

name
string

The name of the environment.

Note

Do not start your environment name with "Microsoft" or "AzureML". The prefixes "Microsoft" and "AzureML" are reserved for curated environments. For more information about curated environments, see Create and manage reusable environments.

Azure Machine Learning provides curated environments, which are predefined environments that offer good starting points for building your own environments. Curated environments are backed by cached Docker images, providing a reduced run preparation cost. For more information about curated environments, see Create and manage reusable environments.

There are a number of ways environment are created in the Azure Machine Learning, including when you:

The following example shows how to instantiate a new environment.

You can manage an environment by registering it. Doing so allows you to track the environment's versions, and reuse them in future runs.

For more samples of working with environments, see the Jupyter Notebook Using environments.

Variables

Environment.databricks

The section configures azureml.core.databricks.DatabricksSection library dependencies.

docker
DockerSection

This section configures settings related to the final Docker image built to the specifications of the environment and whether to use Docker containers to build the environment.

inferencing_stack_version
string

This section specifies the inferencing stack version added to the image. To avoid adding an inferencing stack, do not set this value. Valid value: "latest".

environment_variables
dict

A dictionary of environment variables names and values. These environment variables are set on the process where the user script is executed.

python
PythonSection

This section specifies which Python environment and interpreter to use on the target compute.

spark
SparkSection

The section configures Spark settings. It is only used when framework is set to PySpark.

r
RSection

This section specifies which R environment to use on the target compute.

version
string

The version of the environment.

Methods

add_private_pip_wheel

Upload the private pip wheel file on disk to the Azure storage blob attached to the workspace.

Throws an exception if a private pip wheel with the same name already exists in the workspace storage blob.

build

Build a Docker image for this environment in the cloud.

build_local

Build the local Docker or conda environment.

clone

Clone the environment object.

Returns a new instance of environment object with a new name.

from_conda_specification

Create environment object from an environment specification YAML file.

To get an environment specification YAML file, see Managing environments in the conda user guide.

from_docker_image

Create environment object from a base docker image with optional python dependenies.

Python layer will be added to the environment if conda_specification or pip_requirements is specified. conda_specification and pip_requirements are mutually exclusive.

from_dockerfile

Create environment object from a dockerfile with optional python dependenies.

Python layer will be added to the environment if conda_specification or pip_requirements is specified. conda_specification and pip_requirements are mutually exclusive.

from_existing_conda_environment

Create an environment object created from a locally existing conda environment.

To get a list of existing conda environments, run . For more information, see Managing environments in the conda user guide.

from_pip_requirements

Create an environment object created from a pip requirements file.

Unpinned pip dependency will be added if pip_version is not specified.

get

Return the environment object.

If label is specified, the object previously labeled with the value will be returned. Only one of version or label parameters can be specified. If both are missed, the latest version of the Environment object will be returned.

get_image_details

Return the Image details.

label

Label environment object in your workspace with the specified values.

list

Return a dictionary containing environments in the workspace.

load_from_directory

Load an environment definition from the files in a directory.

register

Register the environment object in your workspace.

save_to_directory

Save an environment definition to a directory in an easily editable format.

add_private_pip_wheel

Upload the private pip wheel file on disk to the Azure storage blob attached to the workspace.

Throws an exception if a private pip wheel with the same name already exists in the workspace storage blob.

Parameters

workspace
Workspace

The workspace object to use to register the private pip wheel.

file_path
str

Path to the local pip wheel on disk, including the file extension.

exist_ok
bool

Indicates whether to throw an exception if the wheel already exists.

Returns

Returns the full URI to the uploaded pip wheel on Azure blob storage to use in conda dependencies.

Return type

str

build

Build a Docker image for this environment in the cloud.

Parameters

workspace
Workspace

The workspace and its associated Azure Container Registry where the image is stored.

image_build_compute
str

The compute name where the image build will take place

Returns

Returns the image build details object.

Return type

ImageBuildDetails

build_local

Build the local Docker or conda environment.

Parameters

platform
str

Platform. One of Linux, Windows or OSX. Current platform will be used by default.

kwargs
dict

Advanced keyword arguments

Returns

Streams the on-going Docker or conda built output to the console.

Return type

str

Remarks

The following examples show how to build a local environment. Please make sure workspace is instantiated as a valid azureml.core.workspace.Workspace object

Build local conda environment

Build local docker environment

Build docker image locally and optionally push it to the container registry associated with the workspace

clone

Clone the environment object.

Returns a new instance of environment object with a new name.

Parameters

new_name
str

New environment name

Returns

New environment object

Return type

Environment

from_conda_specification

Create environment object from an environment specification YAML file.

To get an environment specification YAML file, see Managing environments in the conda user guide.

Parameters

name
str

The environment name.

file_path
str

The conda environment specification YAML file path.

Returns

The environment object.

Return type

Environment

from_docker_image

Create environment object from a base docker image with optional python dependenies.

Python layer will be added to the environment if conda_specification or pip_requirements is specified. conda_specification and pip_requirements are mutually exclusive.

Parameters

name
str

The environment name.

image
str

fully qualified image name.

conda_specification
str

conda specification file.

container_registry
ContainerRegistry

private container repository details.

pip_requirements
str

pip requirements file.

Returns

The environment object.

Return type

Environment

Remarks

If base image is from private repository that requires authorization, and authorization is not set on the AzureML workspace level, container_registry is required

from_dockerfile

Create environment object from a dockerfile with optional python dependenies.

Python layer will be added to the environment if conda_specification or pip_requirements is specified. conda_specification and pip_requirements are mutually exclusive.

Parameters

name
str

The environment name.

dockerfile
str

dockerfile content or path to the file.

conda_specification
str

conda specification file.

pip_requirements
str

pip requirements file.

Returns

The environment object.

Return type

Environment

from_existing_conda_environment

Create an environment object created from a locally existing conda environment.

To get a list of existing conda environments, run . For more information, see Managing environments in the conda user guide.

Parameters

name
str

The environment name.

conda_environment_name
str

The name of a locally existing conda environment.

Returns

The environment object or None if exporting the conda specification file fails.

Return type

Environment

from_pip_requirements

Create an environment object created from a pip requirements file.

Unpinned pip dependency will be added if pip_version is not specified.

Parameters

name
str

The environment name.

file_path
str

The pip requirements file path.

pip_version
str

Pip version for conda environment.

Returns

The environment object.

Return type

Environment

get

Return the environment object.

If label is specified, the object previously labeled with the value will be returned. Only one of version or label parameters can be specified. If both are missed, the latest version of the Environment object will be returned.

Parameters

workspace
Workspace

The workspace that contains the environment.

name
str

The name of the environment to return.

version
str

The version of the environment to return.

label
str

Environment label value.

Returns

The environment object.

Return type

Environment

get_image_details

Return the Image details.

Parameters

Returns

Returns the image details as dict

Return type

DockerImageDetails

label

Label environment object in your workspace with the specified values.

Parameters

name
str

Environment name

version
str

Environment version

labels
list[str]

Values to label Environment with

list

Return a dictionary containing environments in the workspace.

Parameters

workspace
Workspace

The workspace from which to list environments.

Returns

A dictionary of environment objects.

Return type

<xref:builtin.dict>[str, Environment]

load_from_directory

Load an environment definition from the files in a directory.

Parameters

path
str

Path to the source directory.

register

Register the environment object in your workspace.

Parameters

Returns

Returns the environment object

Return type

Environment

save_to_directory

Save an environment definition to a directory in an easily editable format.

Parameters

path
str

Path to the destination directory.

overwrite
bool

If an existing directory should be overwritten. Defaults false.

Sours: https://docs.microsoft.com/en-us/python/api/azureml-core/azureml.core.environment(class)

Configure the R environment to be used for training or web service deployments. When you submit a run or deploy a model, Azure ML builds a Docker image and creates a conda environment with your specifications from your object within that Docker container.

If the parameter is not set, Azure ML will build a predefined base image (CPU or GPU depending on the flag) and install any R packages specified in the , , or parameters.

r_environment( name, version=NULL, environment_variables=NULL, r_version=NULL, rscript_path=NULL, snapshot_date=NULL, cran_packages=NULL, github_packages=NULL, custom_url_packages=NULL, bioconductor_packages=NULL, custom_docker_image=NULL, image_registry_details=NULL, use_gpu=FALSE, shm_size=NULL )

Arguments

name

A string of the name of the environment.

version

A string of the version of the environment.

environment_variables

A named list of environment variables names and values. These environment variables are set on the process where the user script is being executed.

r_version

The version of R to be installed.

rscript_path

The Rscript path to use if an environment build is not required. The path specified gets used to call the user script.

snapshot_date

Date of MRAN snapshot to use.

cran_packages

A list of objects to be installed.

github_packages

A list of objects to be installed.

custom_url_packages

A character vector of packages to be installed from local directory or custom URL.

bioconductor_packages

A character vector of packages to be installed from Bioconductor.

custom_docker_image

A string of the name of the Docker image from which the image to use for training or deployment will be built. If not set, a predefined Docker image will be used. To use an image from a private Docker repository, you will also have to specify the parameter.

image_registry_details

A object of the details of the Docker image registry for the custom Docker image.

use_gpu

Indicates whether the environment should support GPUs. If , a predefined GPU-based Docker image will be used in the environment. If , a predefined CPU-based image will be used. Predefined Docker images (CPU or GPU) will only be used if the parameter is not set.

shm_size

A string for the size of the Docker container's shared memory block. For more information, see Docker run reference If not set, a default value of is used.

Value

The object.

Details

Once built, the Docker image appears in the Azure Container Registry associated with your workspace, by default. The repository name has the form azureml/azureml_<uuid>. The unique identifier (uuid) part corresponds to a hash computed from the environment configuration. This allows the service to determine whether an image corresponding to the given environment already exists for reuse.

If you make changes to an existing environment, such as adding an R package, a new version of the environment is created when you either submit a run, deploy a model, or manually register the environment. The versioning allows you to view changes to the environment over time.

Predefined Docker images

When submitting a training job or deploying a model, Azure ML runs your training script or scoring script within a Docker container. If no custom Docker image is specified with the parameter, Azure ML will build a predefined CPU or GPU Docker image. The predefine images extend the Ubuntu 16.04 Azure ML base images and include the following dependencies:

DependenciesVersionRemarks
azuremlsdklatest(from GitHub)
R3.6.0-
Commonly used R packages-80+ of the most popular R packages for data science, including the IRKernel, dplyr, shiny, ggplot2, tidyr, caret, and nnet. For the full list of packages included, see here.
Python3.7.0-
azureml-defaultslatest contains the and packages of the Python SDK that are required for tasks such as logging metrics, uploading artifacts, and deploying models. (from pip)
rpy2latest(from conda)
CUDA (GPU image only)10.0CuDNN (version 7) is also included

See also

,

Examples

# The following example defines an environment that will build the default# base CPU image.if (FALSE) { r_env<-r_environment(name='myr_env', version='1') }

Sours: https://azure.github.io/azureml-sdk-for-r/reference/r_environment.html
  1. Anl landscapes
  2. Anderson john deere
  3. Rev x diesel

Create & use software environments in Azure Machine Learning

In this article, learn how to create and manage Azure Machine Learning environments. Use the environments to track and reproduce your projects' software dependencies as they evolve.

Software dependency management is a common task for developers. You want to ensure that builds are reproducible without extensive manual software configuration. The Azure Machine Learning class accounts for local development solutions such as pip and Conda and distributed cloud development through Docker capabilities.

The examples in this article show how to:

  • Create an environment and specify package dependencies.
  • Retrieve and update environments.
  • Use an environment for training.
  • Use an environment for web service deployment.

For a high-level overview of how environments work in Azure Machine Learning, see What are ML environments? For information about configuring development environments, see here.

Prerequisites

Create an environment

The following sections explore the multiple ways that you can create an environment for your experiments.

Instantiate an environment object

To manually create an environment, import the class from the SDK. Then use the following code to instantiate an environment object.

Use a curated environment

Curated environments contain collections of Python packages and are available in your workspace by default. These environments are backed by cached Docker images which reduces the run preparation cost. You can select one of these popular curated environments to start with:

  • The AzureML-lightgbm-3.2-ubuntu18.04-py37-cpu environment contains Scikit-learn, LightGBM, XGBoost, Dask as well as other AzureML Python SDK and additional packages.

  • The AzureML-sklearn-0.24-ubuntu18.04-py37-cpu environment contains common data science packages. These packages include Scikit-Learn, Pandas, Matplotlib, and a larger set of azureml-sdk packages.

For a list of curated environments, see the curated environments article.

Use the method to select one of the curated environments:

You can list the curated environments and their packages by using the following code:

Warning

Don't start your own environment name with the AzureML prefix. This prefix is reserved for curated environments.

To customize a curated environment, clone and rename the environment.

Use Conda dependencies or pip requirements files

You can create an environment from a Conda specification or a pip requirements file. Use the method or the method. In the method argument, include your environment name and the file path of the file that you want.

Enable Docker

Azure Machine Learning builds a Docker image and creates a Python environment within that container, given your specifications. The Docker images are cached and reused: the first run in a new environment typically takes longer as the image is build. For local runs, specify Docker within the RunConfiguration.

By default, the newly built Docker image appears in the container registry that's associated with the workspace. The repository name has the form azureml/azureml_<uuid>. The unique identifier (uuid) part of the name corresponds to a hash that's computed from the environment configuration. This correspondence allows the service to determine whether an image for the given environment already exists for reuse.

Use a prebuilt Docker image

By default, the service automatically uses one of the Ubuntu Linux-based base images, specifically the one defined by . It then installs any specified Python packages defined by the provided Azure ML environment. Other Azure ML CPU and GPU base images are available in the container repository. It is also possible to use a custom Docker base image.

Important

Azure Machine Learning only supports Docker images that provide the following software:

  • Ubuntu 18.04 or greater.
  • Conda 4.7.# or greater.
  • Python 3.6+.
  • A POSIX compliant shell available at /bin/sh is required in any container image used for training.

Use your own Dockerfile

You can also specify a custom Dockerfile. It's simplest to start from one of Azure Machine Learning base images using Docker command, and then add your own custom steps. Use this approach if you need to install non-Python packages as dependencies. Remember to set the base image to None.

Please note that Python is an implicit dependency in Azure Machine Learning so a custom dockerfile must have Python installed.

When using custom Docker images, it is recommended that you pin package versions in order to better ensure reproducibility.

Specify your own Python interpreter

In some situations, your custom base image may already contain a Python environment with packages that you want to use.

To use your own installed packages and disable Conda, set the parameter . Ensure that the base image contains a Python interpreter, and has the packages your training script needs.

For example, to run in a base Miniconda environment that has NumPy package installed, first specify a Dockerfile with a step to install the package. Then set the user-managed dependencies to .

You can also specify a path to a specific Python interpreter within the image, by setting the variable.

Warning

If you install some Python dependencies in your Docker image and forget to set , those packages will not exist in the execution environment thus causing runtime failures. By default, Azure ML will build a Conda environment with dependencies you specified, and will execute the run in that environment instead of using any Python libraries that you installed on the base image.

Retrieve image details

For a registered environment, you can retrieve image details using the following code where is an instance of DockerImageDetails (AzureML Python SDK >= 1.11) and provides all the information about the environment image such as the dockerfile, registry, and image name.

To obtain the image details from an environment autosaved from the execution of a run, use the following code:

Use existing environments

If you have an existing Conda environment on your local computer, then you can use the service to create an environment object. By using this strategy, you can reuse your local interactive environment on remote runs.

The following code creates an environment object from the existing Conda environment . It uses the method.

An environment definition can be saved to a directory in an easily editable format with the method. Once modified, a new environment can be instantiated by loading files from the directory.

Implicitly use the default environment

If you don't specify an environment in your script run configuration before you submit the run, then a default environment is created for you.

Add packages to an environment

Add packages to an environment by using Conda, pip, or private wheel files. Specify each package dependency by using the class. Add it to the environment's .

Conda and pip packages

If a package is available in a Conda package repository, then we recommend that you use the Conda installation rather than the pip installation. Conda packages typically come with prebuilt binaries that make installation more reliable.

The following example adds to the environment . It adds version 1.17.0 of . It also adds the package. The example uses the method and the method, respectively.

Important

If you use the same environment definition for another run, the Azure Machine Learning service reuses the cached image of your environment. If you create an environment with an unpinned package dependency, for example , that environment will keep using the package version installed at the time of environment creation. Also, any future environment with matching definition will keep using the old version. For more information, see Environment building, caching, and reuse.

Private Python packages

To use Python packages privately and securely without exposing them to the public internet, see the article How to use private Python packages.

Manage environments

Manage environments so that you can update, track, and reuse them across compute targets and with other users of the workspace.

Register environments

The environment is automatically registered with your workspace when you submit a run or deploy a web service. You can also manually register the environment by using the method. This operation makes the environment into an entity that's tracked and versioned in the cloud. The entity can be shared between workspace users.

The following code registers the environment to the workspace.

When you use the environment for the first time in training or deployment, it's registered with the workspace. Then it's built and deployed on the compute target. The service caches the environments. Reusing a cached environment takes much less time than using a new service or one that has been updated.

Get existing environments

The class offers methods that allow you to retrieve existing environments in your workspace. You can retrieve environments by name, as a list, or by a specific training run. This information is helpful for troubleshooting, auditing, and reproducibility.

View a list of environments

View the environments in your workspace by using the class. Then select an environment to reuse.

Get an environment by name

You can also get a specific environment by name and version. The following code uses the method to retrieve version of the environment on the workspace.

Train a run-specific environment

To get the environment that was used for a specific run after the training finishes, use the method in the class.

Update an existing environment

Say you change an existing environment, for example, by adding a Python package. This will take time to build as a new version of the environment is then created when you submit a run, deploy a model, or manually register the environment. The versioning allows you to view the environment's changes over time.

To update a Python package version in an existing environment, specify the version number for that package. If you don't use the exact version number, then Azure Machine Learning will reuse the existing environment with its original package versions.

Debug the image build

The following example uses the method to manually create an environment as a Docker image. It monitors the output logs from the image build by using . The built image then appears in the workspace's Azure Container Registry instance. This information is helpful for debugging.

It is useful to first build images locally using the method. To build a docker image, set the optional parameter . To push the resulting image into the AzureML workspace container registry, set .

Warning

Changing the order of dependencies or channels in an environment will result in a new environment and will require a new image build. In addition, calling the method for an existing image will update its dependencies if there are new versions.

Utilize adminless Azure Container Registry (ACR) with VNet

It is no longer required for users to have admin mode enabled on their workspace attached ACR in VNet scenarios. Ensure that the derived image build time on the compute is less than 1 hour to enable successful build. Once the image is pushed to the workspace ACR, this image can now only be accessed with a compute identity. For more information on set up, see How to use managed identities with Azure Machine Learning.

Use environments for training

To submit a training run, you need to combine your environment, compute target, and your training Python script into a run configuration. This configuration is a wrapper object that's used for submitting runs.

When you submit a training run, the building of a new environment can take several minutes. The duration depends on the size of the required dependencies. The environments are cached by the service. So as long as the environment definition remains unchanged, you incur the full setup time only once.

The following local script run example shows where you would use as your wrapper object.

Note

To disable the run history or run snapshots, use the setting under .

Important

Use CPU SKUs for any image build on compute.

If you don't specify the environment in your run configuration, then the service creates a default environment when you submit your run.

Use environments for web service deployment

You can use environments when you deploy your model as a web service. This capability enables a reproducible, connected workflow. In this workflow, you can train, test, and deploy your model by using the same libraries in both your training compute and your inference compute.

If you are defining your own environment for web service deployment, you must list with version >= 1.0.45 as a pip dependency. This package contains the functionality that's needed to host the model as a web service.

To deploy a web service, combine the environment, inference compute, scoring script, and registered model in your deployment object, . For more information, see How and where to deploy models.

In this example, assume that you've completed a training run. Now you want to deploy that model to Azure Container Instances. When you build the web service, the model and scoring files are mounted on the image, and the Azure Machine Learning inference stack is added to the image.

Notebooks

Code examples in this article are also included in the using environments notebook.

To install a Conda environment as a kernel in a notebook, see add a new Jupyter kernel.

Deploy a model using a custom Docker base image demonstrates how to deploy a model using a custom Docker base image.

This example notebook demonstrates how to deploy a Spark model as a web service.

Create and manage environments with the Azure CLI

Important

The Azure CLI commands in this article require the , or 1.0, extension for Azure Machine Learning. The enhanced 2.0 CLI (preview) using the extension is now available and recommended. The extensions are incompatible, so 2.0 CLI commands will not work for the steps in this article. However, machine learning workspaces and all underlying resources can be interacted with from either, meaning one user can create a workspace with the 1.0 CLI and another can submit jobs to the same workspace with the 2.0 CLI.

To find which extensions you have installed, use . If the list of Extensions contains , you have the correct extension for the steps in this article.

For more information on installing and using the different extensions, see the following articles:

The Azure Machine Learning CLI mirrors most of the functionality of the Python SDK. You can use it to create and manage environments. The commands that we discuss in this section demonstrate fundamental functionality.

The following command scaffolds the files for a default environment definition in the specified directory. These files are JSON files. They work like the corresponding class in the SDK. You can use the files to create new environments that have custom settings.

Run the following command to register an environment from a specified directory.

Run the following command to list all registered environments.

Download a registered environment by using the following command.

Create and manage environments with Visual Studio Code

Using the Azure Machine Learning extension, you can create and manage environments in Visual Studio Code. For more information, see manage Azure Machine Learning resources with the VS Code extension.

Next steps

Sours: https://docs.microsoft.com/en-us/azure/machine-learning/how-to-use-environments
Deploying your First Machine Learning Model with Azure ML

Improved Environments Experience in Azure Machine Learning for Training and Inference

This article is contributed. See the original author and article here.

Tracking your project’s software dependencies is an integral part of the machine learning lifecycle. But managing these entities and ensuring reproducibility can be a challenging process leading to delays in the training and deployment of models. Azure Machine Learning Environments capture the Python packages and Docker settings for that are used in machine learning experiments, including in data preparation, training, and deployment to a web service. And we are excited to announce the following feature releases: 


 


Environments UI in Azure Machine Learning studio 


 


The new Environments UI in Azure Machine Learning studio is now in public preview. 



  • Create and edit environments through the Azure Machine Learning studio.  

  • Browse custom and curated environments in your workspace. 

  • View details around properties, dependencies (Docker and Conda layers), and image build logs.  

  • Edit tag and description along with the ability to rebuild existing environments.   


Screenshot 2021-07-07 130422.jpg


 


Screenshot 2021-07-07 130535.jpg


 


 


Curated Environments 


 


Curated environments are provided by Azure Machine Learning and are available in your workspace by default. They are backed by cached Docker images that use the latest version of the Azure Machine Learning SDK and support popular machine learning frameworks and packages, reducing the run preparation cost and allowing for faster deployment time. Environment details as well as their Dockerfiles can be viewed through the Environments UI in the studio. Use these environments to quickly get started with PyTorch, Tensorflow, Sci-kit learn, and more.  


 


Inference Prebuilt Docker Images 


 


At Microsoft Build 2021 we announced Public Preview of Prebuilt docker images and curated environments for Inferencing workloads. These docker images come with popular machine learning frameworks and Python packages. These are optimized for inferencing only and provided for CPU and GPU based scenarios. They are published to Microsoft Container Registry (MCR). Customers can pull our images directly from MCR or use Azure Machine Learning curated environments. The complete list of inference images is documented here: List of Prebuilt images and curated environments. 


 


The difference between current base images and inference prebuilt docker images: 



  1. The prebuilt docker images run as non-root. 

  2. The inference images are smaller in size than compared to current base images. Hence, improving the model deployment latency. 

  3. If users want to add extra Python dependencies on top of our prebuilt images, they can do so without triggering an image build during model deployment. Our Python package extensibility solution provides two ways for customers to install these packages: 

    • Dynamic Installation: This method is recommended for rapid prototyping. In this solution, we dynamically install extra python packages during container boot time. 

      1.  Create a requirements.txt file alongside your score.py script. 

      2.  Add all your required packages to the requirements.txt file. 

      3.  Set the AZUREML_EXTRA_REQUIREMENTS_TXT environment variable in your Azure Machine Learning environment to the location of requirements.txt file. 



    • Pre-installed Python packages: This method is recommended for production deployments. In this solution, we mount the directory containing the packages. 

      1.  Set AZUREML_EXTRA_PYTHON_LIB_PATH environment variable, and point it to the correct site packages directory.   






https://channel9.msdn.com/Shows/Docs-AI/Prebuilt-Docker-Images-for-Inference/player


Dynamic installation: 
https://docs.microsoft.com/en-us/azure/machine-learning/how-to-prebuilt-docker-images-inference-python-extensibility#dynamic-installation  


 


Summary 


 


Use the environments to track and reproduce your projects’ software dependencies as they evolve. 


Like this:

LikeLoading...

Related

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

Sours: https://www.drware.com/improved-environments-experience-in-azure-machine-learning-for-training-and-inference/

Ml environment azure

What are Azure Machine Learning environments?

Azure Machine Learning environments are an encapsulation of the environment where your machine learning training happens. They specify the Python packages, environment variables, and software settings around your training and scoring scripts. They also specify run times (Python, Spark, or Docker). The environments are managed and versioned entities within your Machine Learning workspace that enable reproducible, auditable, and portable machine learning workflows across a variety of compute targets.

You can use an object on your local compute to:

  • Develop your training script.
  • Reuse the same environment on Azure Machine Learning Compute for model training at scale.
  • Deploy your model with that same environment.
  • Revisit the environment in which an existing model was trained.

The following diagram illustrates how you can use a single object in both your run configuration (for training) and your inference and deployment configuration (for web service deployments).

Diagram of an environment in machine learning workflow

The environment, compute target and training script together form the run configuration: the full specification of a training run.

Types of environments

Environments can broadly be divided into three categories: curated, user-managed, and system-managed.

Curated environments are provided by Azure Machine Learning and are available in your workspace by default. Intended to be used as is, they contain collections of Python packages and settings to help you get started with various machine learning frameworks. These pre-created environments also allow for faster deployment time. For a full list, see the curated environments article.

In user-managed environments, you're responsible for setting up your environment and installing every package that your training script needs on the compute target. Conda doesn't check your environment or install anything for you. If you're defining your own environment, you must list with version as a pip dependency. This package contains the functionality that's needed to host the model as a web service.

You use system-managed environments when you want Conda to manage the Python environment and the script dependencies for you. A new conda environment is built based on the conda dependencies object. The Azure Machine Learning service assumes this type of environment by default, because of its usefulness on remote compute targets that aren't manually configurable.

Create and manage environments

You can create environments by:

  • Defining new objects, either by using a curated environment or by defining your own dependencies.
  • Using existing objects from your workspace. This approach allows for consistency and reproducibility with your dependencies.
  • Importing from an existing Anaconda environment definition.
  • Using the Azure Machine Learning CLI
  • Using the VS Code extension

For specific code samples, see the "Create an environment" section of How to use environments. Environments are also easily managed through your workspace. They include the following functionality:

  • Environments are automatically registered to your workspace when you submit an experiment. They can also be manually registered.
  • You can fetch environments from your workspace to use for training or deployment, or to make edits to the environment definition.
  • With versioning, you can see changes to your environments over time, which ensures reproducibility.
  • You can build Docker images automatically from your environments.

For code samples, see the "Manage environments" section of How to use environments.

Environment building, caching, and reuse

The Azure Machine Learning service builds environment definitions into Docker images and conda environments. It also caches the environments so they can be reused in subsequent training runs and service endpoint deployments. Running a training script remotely requires the creation of a Docker image whereas, a local run can use a Conda environment directly.

Submitting a run using an environment

When you first submit a remote run using an environment, the Azure Machine Learning service invokes an ACR Build Task on the Azure Container Registry (ACR) associated with the Workspace. The built Docker image is then cached on the Workspace ACR. Curated environments are backed by Docker images that are cached in Global ACR. At the start of the run execution, the image is retrieved by the compute target from the relevant ACR.

For local runs, a Docker or Conda environment is created based on the environment definition. The scripts are then executed on the target compute - a local runtime environment or local Docker engine.

Building environments as Docker images

If the environment definition doesn't already exist in the workspace ACR, a new image will be built. The image build consists of two steps:

  1. Downloading a base image, and executing any Docker steps
  2. Building a conda environment according to conda dependencies specified in the environment definition.

The second step is omitted if you specify user-managed dependencies. In this case you're responsible for installing any Python packages, by including them in your base image, or specifying custom Docker steps within the first step. You're also responsible for specifying the correct location for the Python executable. It is also possible to use a custom Docker base image.

Image caching and reuse

If you use the same environment definition for another run, the Azure Machine Learning service reuses the cached image from the Workspace ACR.

To view the details of a cached image, use Environment.get_image_details method.

To determine whether to reuse a cached image or build a new one, the service computes a hash value from the environment definition and compares it to the hashes of existing environments. The hash is based on:

  • Base image property value
  • Custom docker steps property value
  • List of Python packages in Conda definition
  • List of packages in Spark definition

The hash doesn't depend on environment name or version - if you rename your environment or create a new environment with the exact properties and packages of an existing one, then the hash value remains the same. However, environment definition changes, such as adding or removing a Python package or changing the package version, cause the hash value to change. Changing the order of dependencies or channels in an environment will result in a new environment and thus require a new image build. It is important to note that any change to a curated environment will invalidate the hash and result in a new "non-curated" environment.

The computed hash value is compared to those in the Workspace and Global ACR (or on the compute target for local runs). If there is a match then the cached image is pulled, otherwise an image build is triggered. The duration to pull a cached image includes the download time whereas the duration to pull a newly built image includes both the build time and the download time.

The following diagram shows three environment definitions. Two of them have different names and versions, but identical base image and Python packages. But they have the same hash and thus correspond to the same cached image. The third environment has different Python packages and versions, and therefore corresponds to a different cached image.

Diagram of environment caching as Docker images

Important

  • If you create an environment with an unpinned package dependency, for example, , the environment uses the package version that was installed when the environment was created. Also, any future environment that uses a matching definition will use the original version.

    To update the package, specify a version number to force image rebuild, for example, . New dependencies, including nested ones, will be installed, and they might break a previously working scenario.

  • Using an unpinned base image like in your environment definition results in rebuilding the environment every time the latest tag is updated. It's assumed that you want to keep up to date with the latest version for various reasons, like for vulnerabilities, system updates, and patches.

Warning

The Environment.build method will rebuild the cached image, with possible side-effect of updating unpinned packages and breaking reproducibility for all environment definitions corresponding to that cached image.

Next steps

Sours: https://docs.microsoft.com/en-us/azure/machine-learning/concept-environments
Deploying your First Machine Learning Model with Azure ML

Reproducible Environments by Azure Machine Learning

A few years ago, Docker started gaining popularity. Everyone claimed that this tool was saving them incredible amounts of time. The only thing that you needed for solving the messy process of building, deploying, and managing apps was Docker. It was like heaven.

But… such a wonderful thing could be real? Well, it turnsout that everything was true. A little part of paradise might mistakenly have fallen on earth?. Might be, or might be not but, because of that, nowadays if you are forced to choose the star player for replicable environments your answer will definitively start with a “D” and ends with “ocker”.

Besides, as you already might know, reproducibility is a must in any professional machine learning project. The problem is that achieving this isn’t always something easy to accomplish.

Data scientists love working on their local machines, and learning Docker, might distract them from their principal task: pip installing everything.

If you are one of those, I’m not here just to criticize you. I’m coming with a solution. The people that developed Azure Machine Learning knew that making replicable Python environments was a goldmine for capturing data scientists. They came with a solution to handle environments just inside your Jupyter notebooks.

So, in case you know nothing about Azure Machine Learning, let me briefly explain it to you. Azure ML is a place that aims to bring together every step related to the machine learning lifecycle in one place: secure workspace, storage, model management, compute, model reproducibility, and more.

On the left sidebar, you can see the variety of options provided. But this is not an overview of Azure ML, so I will go straight to the point that brings us here: manageable environments.

At a high level, after you launch your Azure Machine Learning workspace, you can create an Environment object. You can configure your environment with different options. Still, the most commons enable Docker, assign the Conda dependencies, and your favorites PyPi packages.

As you can see in the figure below, you can create a managed Docker environment within your workspace with your package requirements.

As the standard services provided by Azure Machine Learning, you can register them. This gives us the possibility to version our environments without a bunch of files inside of a folder that nobody will understand.

There are three types of environments available:

  1. Curated Environments: these ones are lists of preinstalled packages. They are backed by cached Docker images, reducing the run preparation and enabling faster deployments.
  2. System-managed Environments: is the default environment assumed by Azure. Here you can let Conda to handle your dependencies. The best option if you want personalized packages and you prefer to avoid manage the environment by yourself.
  3. User-managed Environments: here, you own the responsibility for installing the packages needed for your code to run. The only Azure requirement here is that you must list azureml-defaults package between your pip dependencies.

But enough of concepts, a little hands-on won’t hurt you.

We will see examples of the first two environments types because they are much easier for you to work without much knowledge.

To work today, you can create an instance in the “Compute” option inside your Azure ML workspace or just set up your local environment. In case you choose the first one, and you don’t know how to do it, I’ve recently made a tutorial in the following link:

Let’s try a curated environment first. You can inspect the options given by Azure using the following code.

Note: if you are using this in your local, ensure having the JSON config file.

After running the code, you will see many environment possibilities, every one with its own packages and dependencies. So, you can choose whichever that fulfills your requirements.

Let’s say that you liked the environment AzureML-Scikit-learn-0.20.3. Here are the code and a part of the output displayed, just for you to check the packages.

As you can see, the environment is ready for you, just calling it by its name! You can use this even without knowing anything about pip and Conda.

Let’s say that you didn’t find your special package in any of the last lists. Or your packages were there, but the combination that you need to use wasn’t available.

That’s a perfect scenario for system-managed environments. Here you can specify exactly which Conda and pip dependencies you want.

First, you should assign a name to your environment. Then, you can set the python user-managed dependencies to False, and finally, enable Docker to create your reusable cacheable image.

Suppose that we need the scikit-learn 0.23.2 version for our project. So, where do I specify my requirements? Well, the CondaDepdencies imported in the last gist wasn’t just for fun. There you can define the exact version of your package, and decide whether to Conda or pip install them.

Another functionality is that you can store environment variables. If you use them right, it will save you a couple of headaches.

With your environment all set, you can register it to your workspace, which we’ve done in the last code line. Registering environments will give us the chance to retrieve any version that we want. Imagine now that you forgot to list the Boruta package. Well, that’s no problem. You can just update your pip_packages list and register the environment again.

Awesome! But let’s say that your code went into production last week, without the Boruta package, and you need to know how the environment was configured. Again! Easy-peasy. As you will see in the output caption, your first version is precisely the same that you registered.

Incredible! Now everyone in your team can enjoy the benefits obtained by Docker without knowing any command!

As you could have seen, we didn’t actually USE the environments that we just created. Why? Well, because to understand how to train our models, I need to explain what estimators are first. And that’s complex enough to create another article explaining estimators.

Don’t worry if you want to train your model right now, the next post is coming soon, and there you will understand how estimators work.

I really hope that you enjoyed or found this article somehow useful! If you like this content let me know! We can review in further detail other components of the Azure Machine Learning Service.

About the author: I’m passionate about data science, cloud infrastructure, business problems, and writing. I recently obtained the DP-100 Azure data scientist associate certification, and I love to share all the knowledge as soon as I get it.

If you liked it, follow me on Medium and Linkedin. If you want to write to me, I’m recently on Twitter. I will gladly talk with you!

In case you feel like reading a little more, check out some of my recent posts:

Sours: https://towardsdatascience.com/reproducible-environments-by-azure-machine-learning-34a74772c38b

You will also like:

Defining an Environment

When we run a Python script as an experiment in Azure machine learning, a core environment is created to define execution context for the script. Azure machine learning provides a default environment that includes many common packages, including the Azure ML defaults package, that contains the libraries necessary for working with an experiment run, as well as popular packages like Pandas and NumPy.

You can also define your own environment and outer packages by using Conda or PIP, to ensure your experiment has access to all the libraries it requires.

The following code creates an environment for the diabetes experiment. And we import the necessary classes, environment and Conda dependencies. We create a Python environment for the experiment. So, by setting user-managed dependencies to false, what it does is it lets Azure ML manage dependencies. We also have docker enabled, so, we can use a docker container.

We then create a set of package dependencies, Conda or PIP, as required, and then we add the dependencies to the environment. So now, we can use the environment for the experiment by sending it to an estimator, or we can assign it to run config. So, here the code assigns environment we've created with generic estimator, and submits an experiment.

As the experiment runs, we can observe the run details in the widgets, and we can also, have a look at the output logs, and see the Conda environment being built.

So, for our estimator, we import estimator, I experiment and run details classes. We then set up our script parameters. We get the training dataset, and then we create a generic estimator. Notes, the parameters, so, source directory, inputs by passing our diabetes dataset, our script params, our compute is local, environment the definition, our diabetes environment we set up, and our entry script is a diabetes training script.

We then create our experiment, run experiments, and set it up to show the run details while it is running. So, the experiment successfully used the environment, which included all the packages it required. So, now what we can do is then register our environment in the workspace. And that's accomplished by looking the register function in our diabetes environment, and as specified in the workspace, we want it registered in.

Sours: https://cloudacademy.com/course/using-the-azure-machine-learning-sdk-1087/defining-an-environment/


550 551 552 553 554