title | titleSuffix | services | ms.service | ms.component | author | ms.author | ms.date | ms.topic | description | keywords | manager |
---|---|---|---|---|---|---|---|---|---|---|---|
Create a Kubernetes Node.js development environment in the cloud with VS Code | Microsoft Docs |
Azure Dev Spaces |
azure-dev-spaces |
azure-dev-spaces |
azds-kubernetes |
ghogen |
ghogen |
09/26/2018 |
tutorial |
Rapid Kubernetes development with containers and microservices on Azure |
Docker, Kubernetes, Azure, AKS, Azure Kubernetes Service, containers |
douge |
In this guide, you will learn how to:
- Create a Kubernetes-based environment in Azure that is optimized for development - a dev space.
- Iteratively develop code in containers using VS Code and the command line.
- Productively develop and test your code in a team environment.
Note
If you get stuck at any time, see the Troubleshooting section, or post a comment on this page.
You're now ready to create a Kubernetes-based development environment in Azure.
Azure Dev Spaces requires minimal local machine setup. Most of your dev space's configuration gets stored in the cloud, and is shareable with other users. Your local machine can run Windows, Mac, or Linux. For Linux, the following distributions are supported: Ubuntu (18.04, 16.04, and 14.04), Debian 8 and 9, RHEL 7, Fedora 26+, CentOS 7, openSUSE 42.2, and SLES 12.
Start by downloading and running the Azure CLI.
Important
If you already have the Azure CLI installed, make sure you are using version 2.0.43 or higher.
Sign in to Azure. Type the following command in a terminal window:
az login
Note
If you don't have an Azure subscription, you can create a free account.
You can view your subscriptions by running:
az account list
Locate the subscription which has isDefault: true
in the JSON output.
If this isn't the subscription you want to use, you can change the default subscription:
az account set --subscription <subscription ID>
At the command prompt, create the resource group. Use one of the currently supported regions (EastUS, CentralUS, WestUS2, WestEurope, CanadaCentral, or CanadaEast).
az group create --name MyResourceGroup --location <region>
Create a Kubernetes cluster with the following command:
az aks create -g MyResourceGroup -n MyAKS --location <region> --kubernetes-version 1.11.2 --enable-addons http_application_routing
It takes a few minutes to create the cluster.
Enter the following Azure CLI command, using the resource group that contains your AKS cluster, and your AKS cluster name. The command configures your cluster with support for Azure Dev Spaces.
az aks use-dev-spaces -g MyResourceGroup -n MyAKS
Rich features like Kubernetes debugging are available for .NET Core and Node.js developers using VS Code.
- If you don't have it, install VS Code.
- Download and install the VS Azure Dev Spaces extension. Click Install once on the extension's Marketplace page, and again in VS Code.
In this section, you'll create a Node.js web app and get it running in a container in Kubernetes.
Download code from GitHub by navigating to https://github.com/Azure/dev-spaces and select Clone or Download to download the GitHub repository to your local environment. The code for this guide is in samples/nodejs/getting-started/webfrontend
.
So far, you have a basic web app that can run locally. You'll now containerize it by creating assets that define the app's container and how it will deploy to Kubernetes. This task is easy to do with Azure Dev Spaces:
-
Launch VS Code and open the
webfrontend
folder. (You can ignore any default prompts to add debug assets or restore the project.) -
Open the Integrated Terminal in VS Code (using the View > Integrated Terminal menu).
-
Run this command (be sure that webfrontend is your current folder):
azds prep --public
The Azure CLI's azds prep
command generates Docker and Kubernetes assets with default settings:
./Dockerfile
describes the app's container image, and how the source code is built and runs within the container.- A Helm chart under
./charts/webfrontend
describes how to deploy the container to Kubernetes.
For now, it isn't necessary to understand the full content of these files. It's worth pointing out, however, that the same Kubernetes and Docker configuration-as-code assets can be used from development through to production, thus providing better consistency across different environments.
A file named ./azds.yaml
is also generated by the prep
command, and it is the configuration file for Azure Dev Spaces. It complements the Docker and Kubernetes artifacts with additional configuration that enables an iterative development experience in Azure.
Let's run our code! In the terminal window, run this command from the root code folder, webfrontend:
azds up
Keep an eye on the command's output, you'll notice several things as it progresses:
- Source code is synced to the dev space in Azure.
- A container image is built in Azure, as specified by the Docker assets in your code folder.
- Kubernetes objects are created that utilize the container image as specified by the Helm chart in your code folder.
- Information about the container's endpoint(s) is displayed. In our case, we're expecting a public HTTP URL.
- Assuming the above stages complete successfully, you should begin to see
stdout
(andstderr
) output as the container starts up.
Note
These steps will take longer the first time the up
command is run, but subsequent runs should be quicker.
Scan the console output for information about the public URL that was created by the up
command. It will be in the form:
(pending registration) Service 'webfrontend' port 'http' will be available at <url>
Service 'webfrontend' port 80 (TCP) is available at http://localhost:<port>
Open this URL in a browser window, and you should see the web app load. As the container executes, stdout
and stderr
output is streamed to the terminal window.
Note
On first run, it can take several minutes for public DNS to be ready. If the public URL does not resolve, you can use the alternative http://localhost: URL that is displayed in the console output. If you use the localhost URL, it may seem like the container is running locally, but actually it is running in AKS. For your convenience, and to facilitate interacting with the service from your local machine, Azure Dev Spaces creates a temporary SSH tunnel to the container running in Azure. You can come back and try the public URL later when the DNS record is ready.
Azure Dev Spaces isn't just about getting code running in Kubernetes - it's about enabling you to quickly and iteratively see your code changes take effect in a Kubernetes environment in the cloud.
-
Locate the file
./public/index.html
and make an edit to the HTML. For example, change the page's background color to a shade of blue:<body style="background-color: #95B9C7; margin-left:10px; margin-right:10px;">
-
Save the file. Moments later, in the Terminal window you'll see a message saying a file in the running container was updated.
-
Go to your browser and refresh the page. You should see your color update.
What happened? Edits to content files, like HTML and CSS, don't require the Node.js process to restart, so an active azds up
command will automatically sync any modified content files directly into the running container in Azure, thereby providing a fast way to see your content edits.
Open the web app on a mobile device using the public URL for webfrontend. You may want to copy and send the URL from your desktop to your device to save you from entering the long address. When the web app loads in your mobile device, you will notice that the UI does not display properly on a small device.
To fix this issue, you'll add a viewport
meta tag:
-
Open the file
./public/index.html
-
Add a
viewport
meta tag in the existinghead
element:<head> <!-- Add this line --> <meta name="viewport" content="width=device-width, initial-scale=1"> </head>
-
Save the file.
-
Refresh your device's browser. You should now see the web app rendered correctly.
This example shows that some problems just aren't found until you test on the devices where an app is meant to be used. With Azure Dev Spaces, you can rapidly iterate on your code and validate any changes on target devices.
Updating server-side code files requires a little more work, because a Node.js app needs to restart.
-
In the terminal window, press
Ctrl+C
(to stopazds up
). -
Open the code file named
server.js
, and edit service's hello message:res.send('Hello from webfrontend running in Azure!');
-
Save the file.
-
Run
azds up
in the terminal window.
This command rebuilds the container image and redeploys the Helm chart. Reload the browser page to see your code changes take effect.
But there is an even faster method for developing code, which you'll explore in the next section.
In this section, you'll use VS Code to directly debug our container running in Azure. You'll also learn how to get a faster edit-run-test loop.
Note
If you get stuck at any time, see the Troubleshooting section, or post a comment on this page.
You first need to configure your code project so VS Code will communicate with our dev space in Azure. The VS Code extension for Azure Dev Spaces provides a helper command to set up debug configuration.
Open the Command Palette (using the View | Command Palette menu), and use auto-complete to type and select this command: Azure Dev Spaces: Prepare configuration files for Azure Dev Spaces
.
This adds debug configuration for Azure Dev Spaces under the .vscode
folder. This command is not to be confused with the azds prep
command, which configures the project for deployment.
- To open the Debug view, click on the Debug icon in the Activity Bar on the side of VS Code.
- Select Launch Program (AZDS) as the active debug configuration.
Note
If you don't see any Azure Dev Spaces commands in the Command Palette, ensure you have installed the VS Code extension for Azure Dev Spaces.
Hit F5 to debug your code in Kubernetes!
Similar to the up
command, code is synced to the development environment when you start debugging, and a container is built and deployed to Kubernetes. This time, the debugger is attached to the remote container.
Tip
The VS Code status bar will display a clickable URL.
Set a breakpoint in a server-side code file, for example within the app.get('/api'...
in server.js
. Refresh the browser page, or press the 'Say It Again' button, and you should hit the breakpoint and be able to step through code.
You have full access to debug information just like you would if the code was executing locally, such as the call stack, local variables, exception information, etc.
With the debugger active, make a code edit; for example, modify the hello message again:
app.get('/api', function (req, res) {
res.send('**** Hello from webfrontend running in Azure! ****');
});
Save the file, and in the Debug actions pane, click the Refresh button.
Instead of rebuilding and redeploying a new container image each time code edits are made, which will often take considerable time, Azure Dev Spaces will restart the Node.js process in between debug sessions to provide a faster edit/debug loop.
Refresh the web app in the browser, or press the Say It Again button. You should see your custom message appear in the UI.
Nodemon is a popular tool that Node.js developers use for rapid development. Instead of manually restarting the Node process each time a server-side code edit is made, developers will often configure their Node project to have nodemon monitor file changes and automatically restart the server process. In this style of working, the developer just refreshes their browser after making a code edit.
With Azure Dev Spaces, you can use many of the same development workflows you use when developing locally. To illustrate this point, the sample webfrontend
project was configured to use nodemon (it is configured as a dev dependency in package.json
).
Try the following steps:
- Stop the VS Code debugger.
- Click on the Debug icon in the Activity Bar on the side of VS Code.
- Select Attach (AZDS) as the active debug configuration.
- Hit F5.
In this configuration, the container is configured to start nodemon. When server code edits are made, nodemon automatically restarts the Node process, just like it does when you develop locally.
- Edit the hello message again in
server.js
, and save the file. - Refresh the browser, or click the Say It Again button, to see your changes take effect!
Now you have a method for rapidly iterating on code and debugging directly in Kubernetes! Next, you'll see how you can create and call a second container.
[!div class="nextstepaction"] Learn about team development