ko: Goによる高速なKubernetesマイクロサービス開発 ¶

公開日： 2019-04-10 、最終更新日： 2024-01-17

ko: Goによる高速なKubernetesマイクロサービス開発¶

著者： Matt Moore、Chainguard創業者/CTO

私はもともとKnative開発者を支援するために ko を書きました。コミュニティからの好意的なフィードバック、特に最近のKubecon Seattle 2018での ko に関するIBMブースでの講演により、この紹介記事を書くことにしました。私たちと同じように ko を楽しんでいただければ幸いです。 slack.knative.dev でのフィードバックをお待ちしています。

ここ数年、コンテナに関する話題が尽きません。Docker、Kubernetes、そして関連テクノロジーは、パブリッククラウドを席巻しました（しゃれではありません）。それと同時に、ソフトウェアプロジェクトがますます複雑になるにつれて、開発プロセスも複雑になっているようです。

最初は

すぐに

skaffold のようなツールは、任意の言語とDockerfileに対してこのプロセスをラップして管理を容易にし（そして高速化し）ますが、それでも 職人技の手作りDockerfile を書く必要があり、通常は、このオーケストレーション方法（例：何をどこにプッシュするか）をツールに指示するために *より多くの* yaml（またはその他）を書く必要があります。

ko は、Goのイディオムを活用して設定を排除するという異なるアプローチを採用しています。

そのようなGoのイディオムの1つは、バイナリが「インポートパス」によって参照されることです。Goバイナリをインストールする一般的な方法は

# e.g. installing ko itself
go get github.com/google/go-containerregistry/cmd/ko

# This example is based on:
# https://github.com/google/ko/blob/master/cmd/ko/test/test.yaml
              
apiVersion: v1
kind: Pod
metadata:
  name: kodata
spec:
  containers:
  - name: test
    # ko builds and publishes this Go binary, and replaces this
    # with an image name.
    image: github.com/google/go-containerregistry/cmd/ko/test
  restartPolicy: Never

ko を使い始めるのに追加の設定ファイルは必要ありません。コンテナイメージへの参照をインポートパスに置き換えるだけです。

それだけです。

ko でこれをどのように使用しますか？

ko は、ユーザーがイメージをどこに公開したいかを知る必要もあります。これは、チームの各開発者が通常独自のものを使用するため、yamlマニフェストの外部で定義されます。

export KO_DOCKER_REPO=gcr.io/mattmoor-private/ko

たとえば、Knativeで開発する場合、私は自分の .bashrc ファイルでこれを使用します。

注：DockerHubユーザー（および場合によってはその他）の場合、DockerHubはマルチレベルリポジトリ名をサポートしていないため、これは次のようになります。 docker.io/username

ko apply -f directory/ -f file.yaml

その後、コマンドラインインターフェースは kubectl をモデルにしています。

これは kubectl apply と同じ効果がありますが、yamlから参照されるGoマイクロサービスも、はるかに少ない構成でビルド、コンテナ化、および公開します。

Kubernetes yamlとコードのみを書きます。DockerfileもMakefileもありません。1つのコマンドを実行すると、最新のコードが実行されます。

~/go/src/github.com/google/go-containerregistry
$ ko apply -f cmd/ko/test/test.yaml 
Using base .. for github.com/google/go-containerregistry/cmd/ko/test
Publishing gcr.io/mattmoor-public/test-01234abcd:latest
mounted blob: sha256:deadbeef
mounted blob: sha256:baadf00d
pushed blob sha256:deadf00d
pushed blob sha256:baadbeef
pushed blob sha256:beeff00d
gcr.io/mattmoor-public/test-01234abcd:latest: digest: ... size: 915
Published gcr.io/mattmoor-public/test-01234abcd@...
pod/kodata created

~/go/src/github.com/google/go-containerregistry$ kubectl get pods
NAME     READY   STATUS      RESTARTS   AGE
kodata   0/1     Completed   0          1

上記の例に従って（幅に合わせてトリミング）

イメージのみ

ko がサポートする最も簡単なトリックは、単にイメージをコンテナ化して公開することです。ko について何も知らなくても、ほとんどのGoバイナリで動作するのが素晴らしい点です。

~/go/src/golang.org/x/tools
$ ko publish ./cmd/goimports/
Using base .. for golang.org/x/tools/cmd/goimports
Publishing gcr.io/mattmoor-public/goimports-01234:latest
mounted blob: sha256:deadbeef
mounted blob: sha256:baadf00d
mounted blob: sha256:deadf00d
pushed blob sha256:baadbeef
pushed blob sha256:beeff00d
gcr.io/mattmoor-public/goimports-01234:latest: digest: ... size: 914
Published gcr.io/mattmoor-public/goimports-01234@...

たとえば（幅に合わせてトリミング）

ko はリリースにも使えます！

# This does everything `apply` does except it pipes to
# stdout instead of kubectl
ko resolve -f config/ > release.yaml

# Later...
kubectl apply -f release.yaml

また、 ko を使用して、再配布のために次のように公開することもできます。

たとえば、これを使用してすべてのKnativeコンポーネントをリリースしています。

試してみて、ご意見をお聞かせください。

これは、 ko でできること、そして ko があなたのためにしてくれることのほんの一部です。詳細については、 README.md を参照してください。ご質問がある場合は、 slack.knative.dev の#ko、または Twitter @mattomata でご連絡ください。

よくある落とし穴

koが慣習に大きく依存しているため、注意すべき点がいくつかあります。
${GOPATH} にいる必要があります。 そうしないと、どのパッケージにいるかがわかりません。