Clever Geek Handbook

TFSを使用してKubernetesで継続的デリバリーを設定する方法

冗長性に基づいた継続的デリバリー（CD）と高可用性（HA）への取り組みを続けています。 前のシリーズでは、モバイルアプリケーションのAPIを.NET Coreに移動しました 。 CDを実現する次の論理ステップは、Dockerコンテナーでビルドを構成することです。







今日は、Dockerイメージのアセンブリの構成と、.NET開発者向けのTFSでのKubernetesでの展開に関する入門ガイドを共有します。







（この時点で、ASP.NETアプリケーションは既にASP.NET Coreに移行済みであると想定されています。移行されていない場合は、 前回の記事をお読みください）。













Dockerと連携するためのASP.NETアプリケーションのセットアップ



  1. Visual Studio 2017では、Webプロジェクトを右クリック->追加-> Dockerサポート;
  2. VS2015の場合、 拡張機能をインストールする必要があります。
  3. Dockerfileファイルがプロジェクトフォルダーに追加されます-これは、アプリケーションのイメージを作成するための構成です。
  4. Dockerの詳細については、こちらをご覧ください。
  5. 新しいdocker-composeプロジェクトが追加されます。
  6. Docker-compose自体は、マルチコンテナアプリケーションを管理するためのユーティリティです。 たとえば、アプリケーションとDBMSを起動します。
  7. プロジェクト内のファイル：

    a。 docker-compose.yml-サービス/依存関係の説明。

    SQL Serverと組み合わせたASP.NETアプリケーションの例を次に示します。 


version: '3' services: agentrequests.webapp: image: agentrequests.webapp build: context: . dockerfile: AgentRequests.WebApp/Dockerfile depends_on: - agentrequests-db agentrequests-db: image: microsoft/mssql-server-linux environment: SA_PASSWORD: "<YourStrong!Passw0rd>1" ACCEPT_EULA: "Y" ports: - "1401:1433" volumes: - agent-requests-db-data:/var/opt/mssql volumes: agent-requests-db-data:


サービス名（サンプルデータベースのagentrequests-db）は、サーバーサイドサービス検出などのアプリケーションで直接使用できます。







たとえば、ベースへの接続文字列は「Server = agentrequests-db; Database = AgentRequests; User = sa; Password = <YourStrong！Passw0rd> 1;」です。







b。 docker-compose.override.yml-このファイルは開発中に使用されます。 Visual Studioは、F5キーを押すとこれらのファイルをマージします。







ヒント：docker-compose.ymlが変更されるたびに、アプリケーションには新しいローカルポートが割り当てられ、デバッグ時にすぐに気になります。 したがって、docker-compose.override.ymlでは、アプリケーションのポートを修正すると便利です。 







 version: '3' services: agentrequests.webapp: environment: - ASPNETCORE_ENVIRONMENT=Development ports: - "40005:80"


c。 docker-compose.ci.build.yml-この構成を使用すると、CIでアプリケーションをビルドでき、結果はローカルビルドに似たものになります。 このファイルは、IISなどで既製のファイルを展開する場合にのみ必要です。 既製のdocker-imagesを提供し、Dockerfileを直接使用します。







一番下の行：docker-composeプロジェクトを最初のプロジェクトにし、F5キーを押して喜びます。

注：ドッカーはSQL / ASP.Net Coreイメージをダウンロードする必要があるため、最初の起動は長い場合があります。







また、デバッグ時には、Visual Studioはアプリケーションコードが変更されるたびに新しいdockerイメージを作成しません。実際、Dockerfileからコンテナーが1つだけ作成され、そこにホストマシン上のソースのあるフォルダーがマウントされます。 したがって、たとえばjsファイルのすべての変更は、実行中のコンテナにも即座に反映されます。







TFSでDockerイメージを構築してデプロイする



CIは、開発者に関係なく自動ビルドを実行するビルドマシンがあることを前提としています。 開発者が変更をバージョン管理システムにアップロードすると、ビルドマシンが最新の変更を取得してプロジェクトを再構築します。 したがって、ビルドマシンには、プロジェクトのビルドに必要なすべてのツールが必要です。 私たちの場合、Dockerイメージを収集するには、彼女はDockerにアクセスできる必要があります。







いくつかのオプションがあります：







  1. ビルドマシンにDockerを直接配置するか、Dockerクライアントを介して別のマシンのDockerにリモート接続できます。 最初は、Windows上で標準の.Net開発が行われていたため、すべてのビルドマシンは1つ以上のビルドエージェントを備えたWindows仮想マシンでした。 DockerがWindowsマシンでLinuxコンテナーを構築できるように、DockerはLinux仮想マシンをインストールします。 複数の仮想マシンが相互に組み込まれていることがわかります。 しかし、何かが庭をフェンスで囲み始めたくないので、Docker はそのような体制を公式にサポートしていません 。







  2. 別のマシンのDockerに接続するには、 リモートアクセスを設定する必要があります。デフォルトではオフになっています。 TLS証明書を保護することもお勧めします。 Microsoftのマニュアルもあります 。このマニュアルには、LibreSSLがプリインストールされたWindowsコンテナを使用した簡単な構成オプションがあります。







  3. 最も簡単な方法：Dockerコンテナーでビルドエージェントを直接実行できます。ビルドエージェントは、実行しているDockerにアクセスできます。 microsoft / vsts-agentリポジトリから必要なコンテナを選択するだけです。









ビルドエージェントのセットアップ



  1. ビルドエージェントをダウンロードします。
  2. ここで、イメージのバージョンとパラメータの違いについて読むことができます 。
  3. ボード上のドッカーを備えたバージョンが必要です、例えば：

    docker pull microsoft / vsts-agent：ubuntu-16.04-tfs-2017-u1-docker-17.12.0-ce
  4. TFSの[セキュリティ]ページで個人用アクセストークン（PAT）を生成します。



  5. Dockerビルド用の新しいエージェントプールを追加できます。 これはここで行われます：



  6. コンテナを起動します。 

     docker run \ -e TFS_URL=<YOUR_TFS_URL> \ -e VSTS_TOKEN=<PAT> \ -e VSTS_POOL=<POOL> \ -e VSTS_AGENT=$(hostname)-agent \ -v /var/run/docker.sock:/var/run/docker.sock \ --restart=always \ -it microsoft/vsts-agent:ubuntu-16.04-tfs-2017-u1-docker-17.12.0-ce


CIセットアップ



  1. TFSのプロジェクトで、テンプレートを使用して新しいビルド定義を追加します-コンテナ（PREVIEW）
  2. タスクビルドイメージ：



    a。 コンテナレジストリタイプ-コンテナレジストリ。

    b。 Dockerレジストリ接続-ここで、画像のレジストリへのパスを設定します。 Docker Hubを使用できますが、当社ではNexusレジストリを使用しています。

    c。 Dockerファイル-Dockerファイルへのパス。 マスクなしでパスを明示的に指定することをお勧めします。

    d。 デフォルトのビルドコンテキストを使用-チェックを外します。

    e。 ビルドコンテキスト-.slnファイルがあるフォルダーへのパス。

    f。 イメージ名-明示的に指定する方が適切です。すべての文字は小文字です。 例：groups / agent-requests：$（Build.BuildId）;

    g。 最新のタグを含めることができます-レジストリ内の最新のタグが更新されます。
  3. タスクはイメージをプッシュします-2番目のポイントに似ています。 主なことは、イメージ名を変更することを忘れないことです。
  4. ビルドビルドアーティファクトテンプレートを使用してタスクを追加します。 kubernetesにデプロイする予定なので、アーティファクトはkubectlの構成になります。



    a。 パブリッシュするパス-kubernetes configを使用したyamlファイルへのパス。 いくつかの設定がある場合、フォルダーを指定できます。

    b。 アーティファクト名-あなたの好みに合わせて。 たとえば、kubernetes;

    c。 アーティファクトタイプ-サーバー。


CDおよびKubernetesを構成する



最初は小さな余談。 大まかに言って、docker-compose（swarm）はkubernetesのライバルです。 しかし、VSにはkubernetesでのビルドとデバッグの便利なチューニングがないため、開発中に作成する、戦闘中のkubernetesの両方のオプションを使用します。







良いニュースは、 Komposeユーティリティがあることです。Kubernetesの構成をdocker -compose.yamlファイルとの間で変換できます。







ただし、開発者がdocker / composeを完全に使用する必要はありません-旧式の方法ですべてを構成し、URL / configを手動で変更するか、さまざまな環境用に10個のweb.configを保存できます。







Service.yamlの例 
 apiVersion: v1 kind: Service metadata: name: webapp spec: type: LoadBalancer selector: app: webapp ports: - port: 80  deployment.yaml: apiVersion: extensions/v1beta1 kind: Deployment metadata: name: webapp spec: replicas: 1 template: metadata: labels: app: webapp spec: imagePullSecrets: - name: <   Docker Registry> containers: - image: webapp name: webapp env: - name: DB_USER valueFrom: secretKeyRef: name: database-secret key: username - name: DB_PASSWORD valueFrom: secretKeyRef: name: database-secret key: password - name: SQLCONNSTR_<  > # SQLCONNSTR_DefaultConnection value: "Server=< SQL >;Initial Catalog=< >;Persist Security Info=False;User ID=$(DB_USER);Password=$(DB_PASSWORD);" ports: - containerPort: 80


CDを構成するために、TFSサーバーにKubernetes拡張機能を使用しました。これは、TFSのバージョンでは標準のDeploy to Kubernetesタスクが動作しないことが判明したためです。







  1. DockerレジストリにKubernetes接続設定を追加する 









     kubectl create secret docker-registry\ <   Docker Registry>\ --docker-server=< >\ --docker-username=<>\ --docker-password=<>\ --docker-email=<>


  2. データベースに接続するためのログインとパスワードを追加します 







     kubectl create secret generic database-secret\ --from-literal=username=<>\ --from-literal=password=<>


    注：ステップ1および2は、TFSを介して自動化することもできます。







  3. KubernetesエンドポイントをTFSに追加します。











  4. 新しいリリース定義を作成します。



    a。 プロジェクトとビルド定義を選択してください

    b。 継続的な展開を確認す​​る







  5. タスクバーkubernetesダウンローダーを追加します。



    a。 [kubernetesエンドポイント]フィールドで、kubernetesエンドポイントを選択します

    b。 「kubectl download version」フィールドで、必要なバージョンを指定するか、フィールドを空のままにします。この場合、クライアントの最新バージョンがインストールされます。









  6. kubectl execタスクを追加します。



    a。 「サブコマンド」フィールドに書き込み：適用

    b。 「引数」フィールドに次のように記述します。-f $（System.DefaultWorkingDirectory）/ <configフォルダーのパス> /deployment.yaml









  7. kubectl execタスクを追加します。



    a。 「サブコマンド」フィールドに書き込み：適用

    b。 「引数」フィールドに次のように記述します。image -f $（System.DefaultWorkingDirectory）/ <configフォルダーへのパス> /service.yaml







  8. kubectl execタスクを追加します。



    a。 「サブコマンド」フィールドに書き込み：設定

    b。 「引数」フィールドに次のように記述します。image -f $（System.DefaultWorkingDirectory）/ <構成フォルダーへのパス> /deployment.yaml webapp = webapp：$（Build.BuildID）









まとめ



シムのためにすべて。 Dockerを使用して展開を自動化し、金曜日の夜でも休暇前でも簡単にリリースできます。







最後に、非常に便利であることがわかったいくつかのリンク




More articles:


All Articles