Azure Dev Spaces を使用した Windows コンテナーの操作Interact with Windows containers using Azure Dev Spaces

Azure Dev Spaces は、新規と既存の両方の Kubernetes 名前空間で有効にすることができます。You can enable Azure Dev Spaces on both new and existing Kubernetes namespaces. Azure Dev Spaces は、Linux コンテナーで実行されるサービスを実行し、インストルメント化します。Azure Dev Spaces will run and instrument services that run on Linux containers. それらのサービスは、同じ名前空間で Windows コンテナーで実行されるアプリケーションを操作することもできます。Those services can also interact with applications that run on Windows containers in the same namespace. この記事では、既存の Windows コンテナーを持つ名前空間で Dev Spaces を使用してサービスを実行する方法について説明します。This article shows you how to use Dev Spaces to run services in a namespace with existing Windows containers.

クラスターのセットアップSet up your cluster

この記事では、Linux と Windows の両方のノード プールを持つクラスターが既にあることを前提としています。This article assumes you already have a cluster with both Linux and Windows node pools. Linux と Windows のノード プールを持つクラスターを作成する必要がある場合は、こちらの手順に従ってください。If you need to create a cluster with Linux and Windows node pools, you can follow the instructions here.

Kubernetes のコマンドライン クライアントである kubectl を使ってクラスターに接続します。Connect to your cluster using kubectl, the Kubernetes command-line client. Kubernetes クラスターに接続するように kubectl を構成するには、az aks get-credentials コマンドを使用します。To configure kubectl to connect to your Kubernetes cluster, use the az aks get-credentials command. このコマンドは、資格情報をダウンロードし、それを使用するように Kubernetes CLI を構成します。This command downloads credentials and configures the Kubernetes CLI to use them.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

クラスターへの接続を確認するには、クラスター ノードの一覧を返す kubectl get コマンドを使用します。To verify the connection to your cluster, use the kubectl get command to return a list of the cluster nodes.

kubectl get nodes

次の出力例は、Windows と Linux の両方のノードを持つクラスターを示しています。The following example output shows a cluster with both a Windows and Linux node. 次に進む前に、各ノードの状態が Ready であることを確認してください。Make sure the status is Ready for each node before proceeding.

NAME                                STATUS   ROLES   AGE    VERSION
aks-nodepool1-12345678-vmssfedcba   Ready    agent   13m    v1.14.1
aksnpwin987654                      Ready    agent   108s   v1.14.1

Windows ノードに taint を適用します。Apply a taint to your Windows nodes. Windows ノードに taint があると、Dev Spaces がその Windows ノードで Linux コンテナーの実行をスケジューリングしなくなります。The taint on your Windows nodes prevents Dev Spaces from scheduling Linux containers to run on your Windows nodes. 次のコマンド例では、前の例の Windows ノード aksnpwin987654 に taint を適用しています。The following command example command applies a taint to the aksnpwin987654 Windows node from the previous example.

kubectl taint node aksnpwin987654 sku=win-node:NoSchedule

重要

ノードに taint を適用する場合、そのノードでサービスを実行するには、サービスのデプロイ テンプレートで適合する toleration を構成する必要があります。When you apply a taint to a node, you must configure a matching toleration in your service's deployment template to run your service on that node. このサンプル アプリケーションは、前のコマンドで構成した taint と適合する toleration を使用して既に構成されています。The sample application is already configured with a matching toleration to the taint you configured in the previous command.

Windows サービスの実行Run your Windows service

AKS クラスターで Windows サービスを実行し、状態が Running であることを確認します。Run your Windows service on your AKS cluster and verify it is in a Running state. この記事では、サンプル アプリケーションを使用して、クラスターで実行される Windows サービスと Linux サービスのデモンストレーションを行います。This article uses a sample application to demonstrate a Windows and Linux service running on your cluster.

このサンプル アプリケーションを GitHub から複製し、dev-spaces/samples/existingWindowsBackend/mywebapi-windows ディレクトリに移動します。Clone the sample application from GitHub and navigate into the dev-spaces/samples/existingWindowsBackend/mywebapi-windows directory:

git clone https://github.com/Azure/dev-spaces
cd dev-spaces/samples/existingWindowsBackend/mywebapi-windows

サンプル アプリケーションでは、クラスターで Windows サービスを実行するために Helm 2 が使用されます。The sample application uses Helm 2 to run the Windows service on your cluster. クラスターに Helm をインストールし、適切なアクセス許可を付与します。Install Helm on your cluster and grant it the correct permissions:

helm init --wait
kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

charts ディレクトリに移動し、Windows サービスを実行します。Navigate to the charts directory and run the Windows service:

cd charts/
helm install . --namespace dev

上のコマンドでは、Helm を使用して dev 名前空間で Windows サービスを実行しています。The above command uses Helm to run your Windows service in the dev namespace. dev という名前空間がない場合は作成されます。If you don't have a namespace named dev, it will be created.

kubectl get pods コマンドを使用して、Windows サービスがクラスターで実行されていることを確認します。Use the kubectl get pods command to verify your Windows service is running in your cluster.

$ kubectl get pods --namespace dev --watch
NAME                     READY   STATUS              RESTARTS   AGE
myapi-4b9667d123-1a2b3   0/1     ContainerCreating   0          47s
...
myapi-4b9667d123-1a2b3   1/1     Running             0          98s

Azure Dev Spaces の有効化Enable Azure Dev Spaces

Windows サービスの実行に使用した名前空間と同じ名前空間で Dev Spaces を有効にします。Enable Dev Spaces in the same namespace you used to run your Windows service. 次のコマンドを実行すると、dev 名前空間で Dev Spaces が有効になります。The following command enables Dev Spaces in the dev namespace:

az aks use-dev-spaces -g myResourceGroup -n myAKSCluster --space dev --yes

Dev Spaces 向けに Windows サービスを更新Update your Windows service for Dev Spaces

コンテナーが既に実行されている既存の名前空間で Dev Spaces を有効にすると、既定では Dev Spaces がその名前空間で実行される新しいコンテナーをすべてインストルメント化しようとします。When you enable Dev Spaces on an existing namespace with containers that are already running, by default, Dev Spaces will try and instrument any new containers that run in that namespace. また Dev Spaces は、名前空間で既に実行されているサービス用に作成された新しいコンテナーもすべてインストルメント化しようとします。Dev Spaces will also try and instrument any new containers created for service already running in the namespace. 名前空間で実行されているコンテナーが Dev Spaces によってインストルメント化されないようにするには、deployment.yamlno-proxy ヘッダーを追加します。To prevent Dev Spaces from instrumenting a container running in your namespace, add the no-proxy header to the deployment.yaml.

existingWindowsBackend/mywebapi-windows/charts/templates/deployment.yaml ファイルに azds.io/no-proxy: "true" を追加します。Add azds.io/no-proxy: "true" to the existingWindowsBackend/mywebapi-windows/charts/templates/deployment.yaml file:

apiVersion: apps/v1
kind: Deployment
metadata:
  ...
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    ...
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ include "mywebapi.name" . }}
        app.kubernetes.io/instance: {{ .Release.Name }}
        azds.io/no-proxy: "true"

helm list を使用して、Windows サービスのデプロイを一覧表示します。Use helm list to list the deployment for your Windows service:

$ helm list
NAME            REVISION    UPDATED                     STATUS      CHART           APP VERSION NAMESPACE
gilded-jackal   1           Wed Jul 24 15:45:59 2019    DEPLOYED    mywebapi-0.1.0  1.0         dev  

上の例では、デプロイの名前が gilded-jackal となっています。In the above example, the name of your deployment is gilded-jackal. helm upgrade を使用して Windows サービスを新しい構成で更新します。Update your Windows service with the new configuration using helm upgrade:

$ helm upgrade gilded-jackal . --namespace dev
Release "gilded-jackal" has been upgraded.

deployment.yaml を更新したため、Dev Spaces がサービスをインストルメント化しようとすることはありません。Since you updated your deployment.yaml, Dev Spaces will not try and instrument your service.

Azure Dev Spaces を使用した Linux アプリケーションの実行Run your Linux application with Azure Dev Spaces

webfrontend ディレクトリに移動し、コマンド azds prepazds up を使用してクラスターで Linux アプリケーションを実行します。Navigate to the webfrontend directory and use the azds prep and azds up commands to run your Linux application on your cluster.

cd ../../webfrontend-linux/
azds prep --public
azds up

azds prep --public コマンドでは、アプリケーションの Helm チャートと Dockerfile が生成されます。The azds prep --public command generates the Helm chart and Dockerfiles for your application.

ヒント

プロジェクトの Dockerfile と Helm チャートは、コードをビルドして実行するために Azure Dev Spaces によって使用されますが、プロジェクトのビルドおよび実行方法を変更する場合は、これらのファイルを変更することができます。The Dockerfile and Helm chart for your project is used by Azure Dev Spaces to build and run your code, but you can modify these files if you want to change how the project is built and ran.

azds up コマンドでは、名前空間でサービスが実行されます。The azds up command runs your service in the namespace.

$ azds up
Using dev space 'dev' with target 'myAKSCluster'
Synchronizing files...4s
Installing Helm chart...11s
Waiting for container image build...6s
Building container image...
Step 1/12 : FROM mcr.microsoft.com/dotnet/core/sdk:2.2
...
Step 12/12 : ENTRYPOINT ["/bin/bash", "/entrypoint.sh"]
Built container image in 36s
Waiting for container...2s
Service 'webfrontend' port 'http' is available at http://dev.webfrontend.abcdef0123.eus.azds.io/
Service 'webfrontend' port 80 (http) is available via port forwarding at http://localhost:57648

azds up コマンドの出力に示されているパブリック URL を開くと、サービスが実行されていることを確認できます。You can see the service running by opening the public URL, which is displayed in the output from the azds up command. この例のパブリック URL は http://dev.webfrontend.abcdef0123.eus.azds.io/ です。In this example, the public URL is http://dev.webfrontend.abcdef0123.eus.azds.io/. ブラウザーでサービスに移動し、上部の [バージョン情報] をクリックします。Navigate to the service in a browser and click on About at the top. コンテナーが使用している Windows のバージョンが記載されたメッセージが、mywebapi サービスから表示されることを確認します。Verify you see a message from the mywebapi service containing the version of Windows the container is using.

mywebapi から Windows のバージョンを通知するサンプル アプリ

次のステップNext steps

Azure Dev Spaces を使用して複数のコンテナーにまたがるより複雑なアプリケーションを開発する方法と、別の空間で別のバージョンまたは分岐を使用して作業することによって共同開発を簡略化する方法について学習します。Learn how Azure Dev Spaces helps you develop more complex applications across multiple containers, and how you can simplify collaborative development by working with different versions or branches of your code in different spaces.