Cloud Penguins

Flying penguins in the cloud.

KnativeでBuildpackを使ったデプロイを試す

knative PaaS

Knative試してみた話2回目。

前回: jaco.udcp.info

前回は、既に存在するDocker imageを使ってアプリのデプロイを行いました。今回は、ソースコードからアプリのデプロイを試してみます。

Buildpackの話

Buildpackは、PaaSであるherokuやCloud Foundryで利用されている、アプリケーションのビルドやコンフィグレーションを行うための仕組みです。

buildpackの仕組みについては、以下のスライドでも解説しています(42ページ〜)

www.slideshare.net

herokuであればgitへのpush、Cloud Foundryでれば cf push コマンドでソースコードをデプロイすることで、あとは自動でインターネットに公開するところまで終わってしまうわけですが、その裏にはこのBuildpackの存在があります。

Buildpackを使ってKnativeにアプリのデプロイをやる

Knativeは、Buildpackを使ってのアプリやファンクションのコンテナイメージ作成をサポートしています。

ということで、今回はこちらのサンプルアプリを利用して、デプロイを試してみます。

利用するのはこちらのYAML。これを sample.yamlとして保存しておきましょう

apiVersion: serving.knative.dev/v1alpha1
kind: Configuration
metadata:
  name: buildpack-sample-app
  namespace: default
spec:
  build:
    source:
      git:
        url: https://github.com/cloudfoundry-samples/dotnet-core-hello-world
        revision: master
    template:
      name: buildpack
      arguments:
      - name: IMAGE
        value: &image DOCKER_REPO_OVERRIDE/buildpack-sample-app

  revisionTemplate:
    metadata:
      labels:
        knative.dev/type: app
    spec:
      container:
        image: *image
---
apiVersion: serving.knative.dev/v1alpha1
kind: Route
metadata:
  name: buildpack-sample-app
  namespace: default
spec:
  traffic:
  - configurationName: buildpack-sample-app
    percent: 100

このYAML、よーく読むと分かるのですが、コンテナイメージへのパスがどこにも記されていません。その代わり、こちらのリポジトリが指定されています。

github.com

これはKnativeではなくCloud Foundryのデモのために公開されている.NET Coreのアプリケーションです。リポジトリのほうには、コンテナのコの字もなく、単にソースコードが置いてあるだけです。

まずは以下のコマンドで、Buildpackを使ったデプロイを有効にします。

kubectl apply -f https://raw.githubusercontent.com/knative/build-templates/master/buildpack/buildpack.yaml

次に、以下のコマンドを使ってsample.yamlの中身を書き換えます。

REPOには、Google Container Registryのパスが入る形になります。

export REPO="gcr.io/<ここをGCPのProject名に書き換え>"

perl -pi -e "s@DOCKER_REPO_OVERRIDE@$REPO@g" sample.yaml

書き換えが終わったらデプロイしてみましょう

kubectl apply -f sample.yaml

buildpackでコンテナイメージの作成まで行っているので、全てが立ち上がるまで数分かかります。 kubectl get all で全てがRUNNINGになっていることを確認したら、以下のコマンドでアプリのホスト名とknative-ingressgatewayのIPを環境変数に格納しておきます。

export SERVICE_HOST=`kubectl get route buildpack-sample-app -o jsonpath="{.status.domain}"`
export SERVICE_IP=`kubectl get svc knative-ingressgateway -n istio-system -o jsonpath="{.status.loadBalancer.ingress[*].ip}"`

それでは、curlでホストヘッダを指定してアプリにアクセスしてみましょう。Hello worldが表示されているでしょうか？

curl --header "Host: $SERVICE_HOST" http://${SERVICE_IP}/

Hello World!

前回の記事で利用したkanative-ingressgatewayと、今回利用しているものを比較してみてください。実は同じものを叩いていることが分かるでしょう。

kubectl get svc knative-ingressgateway -n istio-system

つまり、kanative-ingressgatewayがホストヘッダを見て、紐付いているserviceにルーティングを行ってくれているわけですね。

作成したイメージをみてみる

それでは、GCRのほうをみてみましょう。

f:id:jaco-m:20180726022248p:plain

生成されたコンテナイメージが保存されていることが分かるでしょう

さて、次はBuildpackを使ったFunctionのデプロイも試してみましょうかね。