mdtoc: .mdファイルに目次を挿入するためのツール

takaishi/mdtocという、マークダウン ファイルに目次を挿入するためのCLIツールを作成した。

なぜ作ったかというと、そのまんまで目次の作成を楽にしたかったから。半年くらい定期的に追記したり見返すマークダウン ファイルがあるのだけど、結構長くて目的の見だしを探すのが大変だったりする。GitHub上で表示するので、見だし名を使った内部リンクを作成できるのだけど、見だし数がそこそこ多いので面倒。じゃあツール作って挿入できるようにしよう、と思って作った。

使い方はリポジトリのREADMEを参照してほしい。MacならHomebrewでインストールできるようになっている。go getでもインストールできると思う。なお、Homebrew fomulaの更新はGoReleaserを使って自動化した。GoReleaser、かなり便利なので別途紹介したい。

CustomControllerでinformerを使ってリソースの追加や更新といったイベント毎に処理を行う

Hello Custom Controller!ではカスタムリソースの取得を素朴にループで実装している。しかし、code-generatorにはinformer-genというコマンドがあり、これを使うとリソースの追加や更新、削除といったイベントに対応して任意の処理を実行することが出来る。コードの見通しもよくなるので、informerを使った形に書き換えてみよう。

準備

kubernetes v1.12.3を使う。minikubeで環境を作成:

  • go: v1.11.2

informer用のコードを生成する

code-generatorのinformer-genを使う。

コントローラーの実装

informerを素朴に使った実装は以下の通り。リソースの追加、更新、削除に対応して任意の処理を実行できる。

後はビルドしてデプロイするだけ。注意点として、使用するサービスアカウントがリソースをwatchできる必要があるのでRoleの更新が必要。

カスタムリソースを追加するとaddFunc関数が呼び出されることが確認できる。

informerを使えばイベントに応じて任意の処理を書くことが出来る、ということを確認出来た。code-generatorでコードを生成できるので、基本的にはinformerを使っていくのがよさそうだなあ。

Hello Custom Controller!

2019年はカスタムコントローラーや!ということで2018年末頃から少しづつ調べている。まずは非常に簡単なものを動かしてみる。

Custom Controller is…

CRDについてのメモにも書いたが、CRD自体はただのデータなので、それだけでは何も起こらない。Kubernetesのdeclarative APIを活用するためにはコントローラーの作成が必要。なお、本記事は以下のページを参考にしています。

作っていく

カスタムコントローラーを作っていくわけだが、いきなり複雑なものを作るのは難しい。そこで、まずはカスタムリソースを読み込み、ログに出力するだけのコントローラーを作る。カスタムコントローラー用のSDKやBuilderがいろいろあるようだがこれも使わず、KubernetesのAPI用コードを出力するだめの code-generator を用いて素朴に作ってみる。code-generatorはいくつかの機能を持っている。

  • deepcopy-gen – 各型についてDeepCopy用のメソッドを生成
  • client-gen – カスタムリソースを扱うためのクライアントセットを生成
  • informer-gen – カスタムリソースの変更に対応するためのイベントベースインターフェースを生成
  • lister-gen – GetとListについて、読み取り用キャッシュレイヤを扱うコードを生成

本格的にカスタムリソースを扱うためにはinformer-genやlister-genが必要になるが、今回はdeepcopy-genとclient-genのみ。deepcopy-genも不要な気がするが、これなしでうまく動かす方法がちと分からなかった。

生成元のコードを用意する

まずは apis/foo/v1alpha/doc.go

次にapis/foo/v1alpha/register.go

最後にapis/foo/v1alpha/types.go

コード生成

これらのファイルを用意したら、code-generatorでコードを生成する。なお、code-generatorのバージョンは kubernetes-1.12.3を使用。

カスタムコントローラーを実装

これで、GoからFooリソースを扱うことが出来る。カスタムコントローラー用のコードを書いていく:

コントローラー用のマニフェスト。defaultアカウントがオブジェクトを取得できるようにRBACの設定も行っている:

デプロイして動作確認する

カスタムコントローラーのビルドからKubernetesへのデプロイまで行うためのMakefile:

デプロイする:

カスタムコントローラーのログを見ると、Fooリソースを取得してログに出力していることが確認できた:

非常にシンプル、というかとくに何もしていないが、カスタムコントローラーができたといっていいだろう。理屈ではログ出力の部分をロジックに置き換えればいいはず。実際にはinformerを用いてイベントベースで処理を行うようなコードになるのだと思う。次はログ出力だけではなく別リソースを扱うようにしていきたい。

ソースコードなどはtakaishi/hello2019にあります。

CRDについてのメモ

Kubernetesのカスタムリソースについてのメモ。基本的には公式ドキュメントの Custom Resources にいろいろと説明が書かれているのでここを読めばよい。カスタムリソース自体は構造化されたデータをKubernetes上に保存・取得できる機能といえる。これにカスタムコントローラを組み合わせることで、Deploymentのようなビルトインリソースと同じような宣言的APIを用いた状態管理を実現できるようになる。データ保存だけなら必ずしもカスタムコントローラーは必要ではないというのが最初分かっていなかった。

軽く試す。使用バージョンは以下の通り:

  • Kubernetes v1.12.3
  • minikube v0.32.0

検証用環境はminikubeで起動:

kubernetes/sample-controller を参考にしつつ、CRD用のマニフェストを作成する。グループやバージョンがリソースへアクセスする際のAPIとなる(/apis/<group>/<version>)。リソースのkindや単数形、複数形なども定義できる。

このマニフェストを適用すると、以下のようにcrdリソースとして見えるようになる:

Fooリソースを作ってみる。以下のようなマニフェストを用意し、 kubectl applyする:

Fooリソースが作成されていることがわかる:

リソースの詳細を見ると、マニフェストで指定したspecが確認できる:

リソース毎にspecが異なることも確認できる:

CRDでバリデーションを行うこともできる(OpenAPIv3.0を使うようだ)。kubernetes/sample-controller を見つつ、replicasのバリデーションを設定してみる:

これで、replicasの最小値と最大値が設定される。replicasが10より大きいマニフェストを用意して適用してみる:

バリデーションに引っかかり、作成に失敗することが確認できた。

API Aggregationというものもあるようだが、そちらはまた今度。

参考:

JapanContainerDays v12.18

12月4日、12月5日に JapanContainerDays v12.18 が開催されたので参加してきた。

12月4日

CNCFのChrisさんの発表でVirtualKubeletや(CNCFのSandbox入りした。気になるぞ〜)、CNFs(Cloud Native Network Functions)という新しいプロダクトを知って何それ!となった。VirtualKubeletは名前の通りKubeletのように振る舞う何かで、例えばFargateプロバイダがあったりする。まだこのプロダクトが見せる未来というのが掴めていないけど、ベアメタルor仮想マシンだったノードがさらに抽象化されて、今後どうなるのか楽しみだ。そして、2019年は4月にCloudNativeDays福岡、7月にCloudNativeDays東京がある!さらにKubernetesDays@Tokyoも開催される!盛り上がっている一方、かなりやっていかないと開催頻度に追いつけないな、と感じるところ。

メルカリ、LINE、デンソーのKeynoteもよかった。なぜKubernetesを使うか?というテーマや、PrivateCloudでKubernetesをどう使ってるか。デンソーでKubernetesを使っているということを知らなかったので驚きであった。

Keynoteの後は市原さんのKubernetesネットワークセッション。一通りカバーしていて、わかりやすい。最終的にはiptablesやこれまでのネットワークに繋がっていくのだなあ(そりゃそうだ)。

午後は自分のセッションがあって、「Ansible、Terraform、Packerで作るSelf-Hosted Kubernetes」という話をしてきた。

どうなるか心配だったけど、Twitterを見る限り刺さった人はいるようでうれしい限り。やはり、自分で手を動かして得たことが誰かに伝わるような行動をとっていかねばなあと思う。

12月6日

2日目!CloudNativeMeetupTokyoのコミュニティセッションで話すことになったのでそれをしたり、CloudNativeDeepDiveのスペースでわいわい話をしたりした。

 

DeepDiveは過去開催のタイミングではあまり触っていなかったりしたので不参加だったのだけど、今回はある程度触ったりして分かってきたので覗いてきた。めっちゃ楽しい。

コンテナランタイムデベロッパーの@udzuraさんの発表を聞いて、その後コンテナランタイム座談会を聞いたり。

 

“Container”DaysといいつつやはりKubernetes関係の発表が多く、コンテナ・オーケストレーションをやっていくならこれだなあと再認識した。また、Kubernetesに取り組み初めてから、「Kubernetesの次はどうなるか、もしくはKubernetesに代わるものがでてきたらどうなるか」ということを考えることがあったのだけど、「Linuxのように標準的な存在になっていくのではないか」という話を聞いて、腑に落ちた。Linuxも今ではシュッとインストールして気軽に使っているけど、少し昔はそうでもなかったわけで、Kubernetesもそのような存在になっていく、というのはなるほどなと思う。

Kubernetesを使う難しさ、というのもHelmのようなパッケージシステムやKnativeのようなKubernetes上に作るプラットフォームなどが登場してきており、数年すれば素のKubernetesを使わない状態になる可能性もある。Railsアプリの開発であればnginxやmysqlはHelmでインストールして、Rails部分は素のyaml/kustomize/もしくはRails特化のツールのようなもので楽に動かす、ということも起こりえるだろう。そして、Kubernetes上で何かをやる、となるとそれを実装しきる力が必要になるのは間違いなく、これまで以上に研鑽が必要だなあと思いを新たにした。

何はともあれ、2018年最後の大きなイベントが終わって一安心。疲れたが、スタッフとスピーカーを兼ねている人が何人もいたりして、自分の疲労なんてたいしたことないだろうな…と思ったりする。来年もいろいろイベントがあるので、いろんな形で関わっていけるといいな。