Skip to content

Latest commit

 

History

History
109 lines (87 loc) · 6.55 KB

how-dev-spaces-works-prep.md

File metadata and controls

109 lines (87 loc) · 6.55 KB
title services ms.date ms.topic description keywords
How preparing a project for Azure Dev Spaces works
azure-dev-spaces
03/24/2020
conceptual
Describes how preparing your project with Azure Dev Spaces works
azds.yaml, Azure Dev Spaces, Dev Spaces, Docker, Kubernetes, Azure, AKS, Azure Kubernetes Service, containers

How preparing a project for Azure Dev Spaces works

Azure Dev Spaces provides you with multiple ways to rapidly iterate and debug Kubernetes applications and collaborate with your team on an Azure Kubernetes Service (AKS) cluster. Dev Spaces can generate Dockerfiles and Helm charts for your project. Dev Spaces also creates and uses a configuration file for deploying, running, and debugging your Kubernetes applications in AKS. All of these files reside with your application's code and can be added to your version control system.

This article describes what happens you prepare your project for running in AKS with Dev Spaces.

Prepare your code

In order to run your application in a dev space, it needs to be containerized, and you need to define how it should be deployed to Kubernetes. To containerize your application, you need a Dockerfile. To define how your application is deployed to Kubernetes, you need a Helm chart. To assist in creating both the Dockerfile and Helm chart for your application, the client-side tools provide the prep command:

azds prep --enable-ingress

The prep command will look at the files in your project and try to create the Dockerfile and Helm chart for running your application in Kubernetes. Currently, the prep command will generate a Dockerfile and Helm chart with the following languages:

  • Java
  • Node.js
  • .NET Core

You must run the prep command from a directory that contains source code. Running the prep command from the correct directory allows the client-side tooling to identify the language and create an appropriate Dockerfile to containerize your application. You can also run the prep command from a directory that contains a pom.xml file for Java projects.

If you run the prep command from directory that does not contain source code, the client-side tooling will not generate a Dockerfile. It will also display an error saying: Dockerfile could not be generated due to unsupported language. This error also occurs if the client-side tooling does not recognize the project type.

When you run the prep command, you have the option of specifying the --enable-ingress flag. This flag tells the controller to create an internet-accessible endpoint for this service. If you do not specify this flag, the service is only accessible from within the cluster or using the localhost tunnel created by the client-side tooling. You can enable or disable this behavior after running the prep command by updating the generated Helm chart.

The prep command will not replace any existing Dockerfiles or Helm charts you have in your project. If an existing Dockerfile or Helm chart uses the same naming convention as the files generated by the prep command, the prep command will skip generating those files. Otherwise, the prep command will generate its own Dockerfile or Helm chart along side the existing files.

Important

Azure Dev Spaces uses the Dockerfile and Helm chart for your project to build and run your code, but you can modify these files if you want to change how the project is built and run.

The prep command will also generate an azds.yaml file at the root of your project. Azure Dev Spaces uses this file to build, install, configure, and run your application. This configuration file lists the location of your Dockerfile and Helm chart and also provides additional configuration on top of those artifacts.

Here is an example azds.yaml file created using .NET Core sample application:

kind: helm-release
apiVersion: 1.1
build:
  context: .
  dockerfile: Dockerfile
install:
  chart: charts/webfrontend
  values:
  - values.dev.yaml?
  - secrets.dev.yaml?
  set:
    replicaCount: 1
    image:
      repository: webfrontend
      tag: $(tag)
      pullPolicy: Never
    ingress:
      annotations:
        kubernetes.io/ingress.class: traefik-azds
      hosts:
        # This expands to [space.s.][rootSpace.]webfrontend.<random suffix>.<region>.azds.io
        # Customize the public URL by changing the 'webfrontend' text between the $(rootSpacePrefix) and $(hostSuffix) tokens
        # For more information see https://aka.ms/devspaces/routing
        - $(spacePrefix)$(rootSpacePrefix)webfrontend$(hostSuffix)
configurations:
  develop:
    build:
      dockerfile: Dockerfile.develop
      useGitIgnore: true
      args:
        BUILD_CONFIGURATION: ${BUILD_CONFIGURATION:-Debug}
    container:
      sync:
      - "**/Pages/**"
      - "**/Views/**"
      - "**/wwwroot/**"
      - "!**/*.{sln,csproj}"
      command: [dotnet, run, --no-restore, --no-build, --no-launch-profile, -c, "${BUILD_CONFIGURATION:-Debug}"]
      iterate:
        processesToKill: [dotnet, vsdbg]
        buildCommands:
        - [dotnet, build, --no-restore, -c, "${BUILD_CONFIGURATION:-Debug}"]

The azds.yaml file generated by the prep command is intended to work for simple, single project development scenario. If your specific project has increased complexity, you may need to update this file after running the prep command. For example, your project may require some changes to your build or launch process based on your development or debugging needs. You also might have multiple applications in your project, which require multiple build processes or a different build content.

Next steps

To learn more about running your code in your dev space, see How running your code with Azure Dev Spaces works.

To get started using Azure Dev Spaces to prepare your project for Azure Dev Space, see the following quickstarts: