| title | services | ms.date | ms.topic | description | keywords |
|---|---|---|---|---|---|
Frequently asked questions about Azure Dev Spaces |
azure-dev-spaces |
01/28/2020 |
conceptual |
Find answers to some of the common questions about Azure Dev Spaces |
Docker, Kubernetes, Azure, AKS, Azure Kubernetes Service, containers, Helm, service mesh, service mesh routing, kubectl, k8s |
This addresses frequently asked questions about Azure Dev Spaces.
Azure Dev Spaces supports all currently supported general availability (GA) versions of Kubernetes in AKS.
See supported regions for a complete list of available regions.
Yes, if you want to move your AKS cluster with Azure Dev Spaces to another supported region, we recommend that you create a new cluster in the other region then install and configure Azure Dev Spaces and deploy your resources and applications to your new cluster. For more information on migrating AKS, see Migrate to Azure Kubernetes Service (AKS).
Yes, if your project already has a Dockerfile or a Helm chart, you can use those files with Azure Dev Spaces. When you run azds prep, use the --chart parameter and specify the location of the chart. Azure Dev Spaces will still generate an azds.yaml and Dockerfile.develop file, but it will not replace or modify an existing Dockerfile or a Helm chart. You may need to modify the azds.yaml and Dockerfile.develop files in order for everything to work correctly with your existing application when running azds up.
When using your own Dockerfile or Helm chart, there are the following limitations:
- If using only one Dockerfile, it must include everything you need to enable development scenarios, such as the language SDK not just the runtime. If using a separate Dockerfile for Azure Dev Spaces, such as a Dockerfile.develop, everything you need to enable development scenarios must be included in that Dockerfile.
- Your Helm chart must support passing part of or the entire image tag as a value from values.yaml.
- If you are modifying anything with ingress, you can also update your Helm chart to use the ingress solution provided by Azure Dev Spaces.
- If you want to use the routing capabilities provided by Azure Dev Spaces, all services for an individual project must fit within a single Kubernetes namespace and must be deployed with simple naming, for example service-a. In standard Helm charts, this naming update can be done by specifying a value for the fullnameOverride property.
To compare your own Dockerfile or Helm chart to an existing version that works with Azure Dev Spaces, review the files generated in the quickstart.
Yes, you can modify the azds.yaml file, Dockerfile, and Helm chart generated by Azure Dev Spaces when preparing your project. Modifying these files changes how the project is built and run.
No, you can't provision Azure Dev Spaces on an AKS Cluster without a public IP. A public IP is needed by Azure Dev Spaces for routing.
Yes, you can configure your own ingress along side the ingress Azure Dev Spaces creates. For example, you can use traefik or NGINX.
Yes, you can configure your own ingress with HTTPS using traefik or NGINX.
Yes, you can use Azure Dev Spaces on an AKS cluster that uses CNI for networking. For example, you can use Azure Dev Spaces on an AKS cluster with existing Windows containers, which uses CNI for networking. More information on using CNI for networking with Azure Dev Spaces is available here.
Currently, Azure Dev Spaces is intended to run on Linux pods and nodes only, but you can run Azure Dev Spaces on an AKS cluster with existing Windows containers.
Yes, you can use Azure Dev Spaces on AKS clusters with API server authorized IP address ranges enabled. More information on using an AKS clusters with API server authorized IP address ranges enabled with Azure Dev Spaces is available here.
Yes, you can use Azure Dev Spaces on AKS clusters with restricted egress traffic for cluster nodes enabled once the correct FQDNs have been allowed. More information on using an AKS clusters with restricted egress traffic for cluster nodes enabled with Azure Dev Spaces is available here.
Yes, you can use Azure Dev Spaces on AKS clusters with or without RBAC enabled.
When using Visual Studio to prepare your project, you have the option of enabling ingress for your service. Enabling ingress creates a public endpoint to access your service when running on your AKS cluster, which is optional. If you do not enable ingress, your service is only accessible from within your AKS cluster.
Yes, you can use pod managed identities on AKS clusters with Azure Dev Spaces enabled, but there are additional configuration steps after you enable Azure Dev Spaces on your cluster with pod managed identities. If you have pod managed identities installed and would like to uninstall it, you can find more details in the uninstall notes.
Yes, you can use Azure Dev Spaces in an application with multiple microservices, but you must prepare and run the individual microservices at their root. The Azure Dev Spaces CLI, Azure Dev Spaces VS Code extension, and Visual Studio Azure Development workload expect the azds.yaml file to be at the root of the microservice in order to run and debug. See the Bike Sharing sample application for an example of multiple microservices in a single application.
In Visual Studio Code, it is possible to open separate projects in a single workspace and debug them separately through Azure Dev Spaces. Each of the projects must be self-contained and prepared for Azure Dev Spaces.
In Visual Studio, it is possible to configure .NET Core solutions for debugging through Azure Dev Spaces.
At this time, you can't use Azure Dev Spaces with service meshes such as Istio or Linkerd. You can run Azure Dev Spaces and a service mesh on the same AKS cluster, but you can't have both Azure Dev Spaces and a service mesh enabled in the same namespace.