Knative初体験:Build Hello World

著者|阿里雲知能事業群技術専門家冬島
BuildモジュールはPipelineメカニズムを提供しています.Pipelineの各ステップは、ソースコードをバイナリにコンパイルしたり、ミラーをコンパイルしたり、他のことをしたりする動作を実行することができます.Knative Buildがコンパイルを実行するときは、コンパイル環境を事前に準備する必要はありません.これらはすべてPodで直接実行されます.タスクを実行する必要がある場合、Buildモジュールは自動的にPodを作成して対応する処理を行います.だからこの一連の動作はすべてKubernetes原生のものです.

Knative Buildのいくつかの重要な特性

完全なBuildは複数のBuilderからなるPipelineであり、各Builderは1つ以上の動作

を実行することができる.

Builderは実行時にcontainerであり、コンテナのミラーリングはBuilderを宣言する際にユーザ自身が指定するので、containerでは任意の命令

を実行することができる.

KanikoによるBuilderでのミラーのコンパイルやミラーウェアハウスへのプッシュなどの動作

.

BuildTemplateは、再利用可能なテンプレート

を提供する.

Buildプロシージャはgitウェアハウスcloneコードからミラーウェアハウスpushにミラーリングすることができる.これらの動作で使用されるすべての認証情報は、serviceAccountによって関連付けることができる.Kubernetesオリジナルの能力を直接使用すれば

を実現できます.

Buildの例

Hello Worldである以上、具体的な例から話しましょう.

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: example-build-name
spec:
  serviceAccountName: build-auth-example
  source:
    git:
      url: https://github.com/example/build-example.git
      revision: master
  steps:
    - name: ubuntu-example
      image: ubuntu
      args: ["ubuntu-build-example", "SECRETS-example.md"]
    - image: gcr.io/example-builders/build-example
      args: ["echo", "hello-example", "build"]
    - name: dockerfile-pushexample
      image: gcr.io/example-builders/push-example
      args: ["push", "${IMAGE}"]
      volumeMounts:
        - name: docker-socket-example
          mountPath: /var/run/docker.sock
  volumes:
    - name: example-volume
      emptyDir: {}

キーフィールドの説明:

steps

Stepフィールドとtemplateフィールドは反発します.templateが指定されていない場合はstepsフィールドを設定する必要があります.このフィールドはPipelineの手順を指定するために使用します.StepsをBuildTemplateに定義することもでき、テンプレートでPipelineの能力を多重化することができます.
各stepはミラーを作成し、実際に実行するときにコンテナを起動して現在のstepの動作をします.

Template

stepsが設定されていない場合は、このフィールドを指定する必要があります.このフィールドはBuildTemplateを参照してstepsを設定します.

Source

よく使われるSourceはgit repoで、このフィールドで参照するgit repoを指定し、repoのライセンス情報は関連するServiceAccountで設定されます.

ServiceAccount

git repeからコードをクローンしたり、ミラーウェアハウスpushにミラーしたりするには、認証情報が必要です.これらの認証情報は、KubernetesのServiceAccountによって関連付けることができる.

Volumes

複数のstep間でデータを共有するには、volumeをマウントする形でsecretまたはemptyDirをマウントできます.

Timeout

Buildプロシージャ全体のデフォルトタイムアウト時間は10分です.つまり、stepが10分以内に完了していない場合はタイムアウトします.ただし、タイムアウト時間はTimeoutフィールドでカスタマイズできます.
次に、各キーフィールドをそれぞれ詳細に解読します.

steps

次はstepsを設定する例で、この例には3つのstepがあります.各stepは、1つのミラーによってコンテナを実行して独自の動作を完了します.

spec:
  steps:
    - name: ubuntu-example
      image: ubuntu
      args: ["ubuntu-build-example", "SECRETS-example.md"]
    - image: gcr.io/example-builders/build-example
      args: ["echo", "hello-example", "build"]
    - name: dockerfile-pushexample
      image: gcr.io/example-builders/push-example
      args: ["push", "${IMAGE}"]
      volumeMounts:
        - name: docker-socket-example
          mountPath: /var/run/docker.sock

Template

再利用可能なstepsはBuildTemplateによって定義され、主にstepsの多重化である.BuildTemplate自体はKubernetesのCRDです.CRDの利点は,同じKubernetesクラスタ内で互いに共有できる限り,ユーザ間で共有できることであり,より効率的である.
BuildTemplateはstepsを定義する以外にparametersを指定することができ、ユーザーはBuildTemplateを使用するときにparametersに基づいてstepsをカスタマイズすることができます.BuildTemplateの作成者はparametersで変数を共有することもできます.

spec:
  parameters:
    # This has no default, and is therefore required.
    - name: IMAGE
      description: Where to publish the resulting image.

    # These may be overridden, but provide sensible defaults.
    - name: DIRECTORY
      description: The directory containing the build context.
      default: /workspace
    - name: DOCKERFILE_NAME
      description: The name of the Dockerfile
      default: Dockerfile

  steps:
    - name: dockerfile-build
      image: gcr.io/cloud-builders/docker
      workingDir: "${DIRECTORY}"
      args:
        [
          "build",
          "--no-cache",
          "--tag",
          "${IMAGE}",
          "--file",
          "${DOCKERFILE_NAME}",
          ".",
        ]
      volumeMounts:
        - name: docker-socket
          mountPath: /var/run/docker.sock

    - name: dockerfile-push
      image: gcr.io/cloud-builders/docker
      args: ["push", "${IMAGE}"]
      volumeMounts:
        - name: docker-socket
          mountPath: /var/run/docker.sock

  # As an implementation detail, this template mounts the host's daemon socket.
  volumes:
    - name: docker-socket
      hostPath:
        path: /var/run/docker.sock
        type: Socket

Source

一般的なsourceとは、git repoまたはemptyDir共有データを指定することです.次に、この2つのシーンについて説明します.

git repoの例

次の例の意味はhttps://github.com/knative/build.gitcloneコード、stepがcat READMEであることを指定する.md

spec:
  source:
    git:
      url: https://github.com/knative/build.git
      revision: master
  steps:
    - image: ubuntu
      args: ["cat", "README.md"]

volume共有データ

次の例は2つのstepで、最初のstepはファイルをダウンロードして/var/my-volumeに保存し、2番目のstepは/var/my-volumeを使用する内容です.

spec:
  steps:
    - image: ubuntu
      entrypoint: ["bash"]
      args: ["-c", "curl https://foo.com > /var/my-volume"]
      volumeMounts:
        - name: my-volume
          mountPath: /var/my-volume

    - image: ubuntu
      args: ["cat", "/etc/my-volume"]
      volumeMounts:
        - name: my-volume
          mountPath: /etc/my-volume

  volumes:
    - name: my-volume
      emptyDir: {}

ServiceAccount

次の例はtest-build-robot-git-sshというServiceAccountを使用してcloneコードに必要なgit ssh認証情報を関連付けます.ServiceAccountとsecretで認証情報を保存することで、複数のユーザ間で同じデータを共有することができ、またRBACで異なるリソースの可視範囲を制御することができ、比較的柔軟である.

Buildは、以下のように構成する

.

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: test-build-with-serviceaccount-git-ssh
  labels:
    expect: succeeded
spec:
  serviceAccountName: test-build-robot-git-ssh
  source:
    git:
      url: [email protected]:knative/build.git
      revision: master

  steps:
    - name: config
      image: ubuntu
      command: ["/bin/bash"]
      args: ["-c", "cat README.md"]

test-build-robot-git-ssh ServiceAccount構成は次の

です.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-build-robot-git-ssh
secrets:
  - name: test-git-ssh

ServiceAccountに関連付けられたsecretは、次の

です.

apiVersion: v1
kind: Secret
metadata:
  name: test-git-ssh
  annotations:
    build.knative.dev/git-0: github.com
type: kubernetes.io/ssh-auth
data:
  # Generated by:
  # cat id_rsa | base64 -w 0
  ssh-privatekey: LS0tLS1CRUdJTiBSU0EgUFJJVk.....[example]
  # Generated by:
  # ssh-keyscan github.com | base64 -w 0
  known_hosts: Z2l0aHViLmNvbSBzc2g.....[example]

Timeout

以下に、カスタムBuildタイムアウト時間の例を示します.

spec:
  timeout: 20m
  source:
    git:
      url: https://github.com/knative/build.git
      revision: master
  steps:
    - image: ubuntu
      args: ["cat", "README.md"]