Configuring conda in Workbench

As an administrator, it is your responsibility to maintain conda within Data Science & AI Workbench. Similar to how a user must configure conda to understand which channels to attempt to pull packages from when creating environments, Workbench requires configurations in the form of a system-level .condarc file to understand which channels Workbench users have access to when creating environments or installing packages in projects. Configuring conda at the system level overrides any user-level conda configurations.

The system-level .condarc file is populated from the conda: section of the anaconda-enterprise-anaconda-platform.yml configmap file or the values.yml helm chart override file. If no modifications are made during installation, the default Workbench .condarc file looks like this:

Default .condarc configuration

conda:
    channels:
    - defaults
    # List of channels that should be used for channel 'defaults'
    default_channels:
    - https://repo.anaconda.com/pkgs/main
    - https://repo.anaconda.com/pkgs/r
    # URL prefix to add to short channel names
    channel_alias: http://anaconda-enterprise-ap-repository/repository/conda
    # configuration for proxies with SSL inspection
    ssl_verify: /var/run/secrets/anaconda/ca-chain.pem
    # Additional configuration values not included above
    other_variables: {}

The default Workbench setup allows all users to have access to all packages from Anaconda’s main and r channels. However, with the channel_alias: set to the internal Workbench repository, conda is still able to access channels created within Workbench (whether via the UI or CLI) when the channel name is invoked in a conda command with the -c tag, or listed in a project’s anaconda-project.yml configuration file, even if they are not listed in the .condarc.

Note

Anaconda recommends removing the r channel if you are not using R language packages.

To configure conda for workbench, follow these instructions to edit the configmap’s conda: section to include the channels you need to provide to all Workbench users.

Note

Anaconda recommends listing only defaults in the channels: list, and listing only necessary channels in the default_channels: list. Place the channels you want available to all users in the default_channels: list.

Here are some example .condarc configuration variations that you can use as a template for your own .condarc settings.

Using internal Workbench repository channels only

If you want to centralize all of your channels to the internal Workbench repository, mirror the external channels and packages you want into internal Workbench channels. Make your internal channels available to all users by entering them in the default_channels: list by name, and leave the channel_alias: alone.

# Replace <CHANNEL_NAME> with the name of an internal Workbench repository channel
conda:
    channels:
    - defaults
    default_channels:
    - <CHANNEL_NAME>
    - <CHANNEL_NAME>
    ssl_verify: /var/run/secrets/anaconda/ca-chain.pem
    channel_alias: http://anaconda-enterprise-ap-repository/repository/conda

Using the internal Workbench repository with external channels

Similar to the default configurations, if you would like to be able to access the internal Workbench repository channels and still provide access to specific external repository channels, enter the full URL of the external channel location(s) in the default_channels: list and leave the channel_alias: alone.

# Replace <CHANNEL_URL> with the full URL of an external repository channel
conda:
    channels:
    - defaults
    default_channels:
    - <CHANNEL_URL>
    - <CHANNEL_URL>
    ssl_verify: /var/run/secrets/anaconda/ca-chain.pem
    channel_alias: http://anaconda-enterprise-ap-repository/repository/conda

External repository channels only

If you have a repository of channels and packages that are hosted on an external site, you can set the channel_alias: to the repository’s fully qualified domain name (FQDN). This setup enables you to invoke channel names in conda commands using the -c tag. In this example, we use anaconda.org as an external repository site:

# Replace <ORG_NAME> with your anaconda.org organization name
# Replace <ORG_CHANNEL> with the name of an anaconda.org channel
conda:
    channels:
    - defaults
    default_channels:
    - <ORG_CHANNEL>
    - <ORG_CHANNEL>
    ssl_verify: /var/run/secrets/anaconda/ca-chain.pem
    channel_alias: https://conda.anaconda.org/<ORG_NAME>/

The channels you specify can be public or private. Private channels require users to authenticate via anaconda-enterprise-cli before they can access packages from them. For more information about channel sharing, see sharing channels.

Configuring a proxy for conda

You can configure Workbench to use a proxy server for conda if your organization’s network security policy requires it.

Obtain your proxy values

You must know the address of your proxy server and what port you need to communicate over to proceed. Gather this information, and keep it somewhere you can reference quickly.

Verify proxy values

Test your proxy values by setting them as environment variables from within a Workbench project:

1. Log in to Workbench.

2. Open a session in the project you want to use to test the proxy.

   Note

   If the project already has a session open, you’ll need to stop the current session and open a new one.

3. Open a terminal window within JupyterLab.

4. Set and export your proxy variables by running the following commands:

   # Replace <PROXY_URL> with the full URL of your proxy server
   # Replace <PORT> with the port number you are using to communicate
   # Replace <PROXY_DOMAIN> with the FQDN of your proxy server
   export http_proxy=<PROXY_URL>:<PORT>
   export https_proxy=<PROXY_URL>:<PORT>
   export no_proxy=*<PROXY_DOMAIN>
   export HTTP_PROXY=<PROXY_URL>:<PORT>
   export HTTPS_PROXY=<PROXY_URL>:<PORT>
   export NO_PROXY=*<PROXY_DOMAIN>
   

5. Verify the proxy works by running the following command:

   conda create -n testenv python
   

Configure global system variables

Once you’ve confirmed your proxy works, follow instructions for setting global config variables to apply those variables to all future sessions, deployments, and scheduled jobs.

The lines you add to the global config should look something like the following, with your specific proxy address and port number substituted in:

http_proxy: http://proxy.example.com:1245/
https_proxy: https://proxy.example.com:1245/
no_proxy: *.example.com
HTTP_PROXY: http://proxy.example.com:1245/
HTTPS_PROXY: https://proxy.example.com:1245/
NO_PROXY: *.example.com