kubecolor を使って kubectl の実行結果を色付けしよう

kubecolor コマンドを使うと kubectl コマンドの実行結果を色付けして読みやすくできる．kubectl コマンドの実行結果は基本的に白黒なので，リソース数が多かったり，例えば -o wide オプションを使って表示項目を増やしたりすると，読みにくくなることもある．

また技術講師として研修で Kubernetes を教える機会も多く，kubectl コマンドの実行結果を説明するときに「青の〜」や「黄色の〜」という表現が使えると，特にリモート研修で注目して欲しい部分を正確に伝えられる．今回は kubecolor コマンドを紹介する．

github.com

kubecolor をインストールする

Linux と Mac なら kubecolor コマンドは brew コマンドで簡単にインストールできる．また go get コマンドで直接インストールすることもできるし，GitHub Releases からバイナリをダウンロードして使うこともできる．brew コマンドを使った場合は現時点だと v0.0.8 になる．数日前に最新版 v0.0.9 もリリースされている．詳しくは GitHub リポジトリ参照！

$ brew install dty1er/tap/kubecolor

また kubecolor コマンドは内部的に kubectl コマンドを実行するため，基本的には kubectl コマンドを置き換えて問題ないと思う．GitHub リポジトリの README.md にもそう書いてある．よって，慣れた k コマンドを kubecolor コマンドのエイリアスに設定しても良いし，タブ補完 (complete) も問題なく使える．例えば Mac だと .zshrc に以下のように設定している．

source <(kubectl completion zsh)
alias k='kubecolor'
complete -o default -F __start_kubectl kubecolor k

kubecolor を使う

サンプルとして，Deployment 経由で Pod を3個起動しておく．そして kubecolor get pods コマンドと kubecolor get pods -o wide コマンドを実行した結果を以下に載せる．従来の白黒と比較して，とても読みやすくなっていると思う．

kubecolor コマンドは get や describe など READ 関連コマンドをサポートしているため，次は kubecolor describe pods xxx コマンドを実行した結果を以下に載せる．特に describe は表示項目が多いため，少しでも色付けできると読みやすくなる．

kubecolor コマンドは YAML フォーマットもサポートしているため，最後は kubecolor get pods xxx -o yaml コマンドを実行した結果を以下に載せる．複雑な YAML フォーマットも少しは読みやすくなっていると思う．

なお，そもそも YAML フォーマットの「冗長な」情報を削除して読みやすくするなら，別記事で紹介した kubectl-neat も併用できる．kubecolor neat get pods xxx -o yaml のように kubectl-neat を「ラッパー」で実行すれば，うまく色付けできる．

kakakakakku.hatenablog.com

kubecolor で使えるオプション

kubecolor コマンドで --light-background オプションを使えば，白背景などにも対応できる．実際に iTerm2 で試したところ，逆に読みにくくなることもあった．カラースキーマとの相性もあるため組み合わせを模索すると良さそう．また --plain オプションを使えば，kubecolor コマンドを使いつつ色付けを無効化できる．

iterm2colorschemes.com

まとめ

kubecolor コマンドを使うと kubectl コマンドの実行結果に色付けをして読みやすくできる．慣れた k コマンドのエイリアスに設定できるし，タブ補完 (complete) も使える．基本的には kubectl コマンドに影響は及ぼさないため，興味があったら試してみると良いかと！

github.com

kubectl-neat を使って Kubernetes のマニフェストをスッキリ表示する

「kubectl-neat（kubectl neat コマンド）」を使うと Kubernetes のマニフェストから「冗長な」情報を削除して表示できる．知っておくと便利！GitHub リポジトリの README.md を読むと「メタデータ」や「デフォルト設定」や「Admission Controllers によって作られた情報」によって読みにくくなると書いてある．さっそく「kubectl-neat」を紹介していく．

github.com

検証環境

• Docker Desktop for Mac
• Kubernetes 1.19.3

事前確認 : kubectl get pods xxx -o yaml コマンド

「kubectl-neat」を試す前に事前確認として kubectl get pods xxx -o yaml コマンドを確認する．kubectl get pods コマンドに -o yaml オプションを追加すると，Pod の状態を YAML 形式で詳細に確認できる．まず，以下のマニフェストを作る．

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-kubectl-neat-pod
  labels:
    app: sandbox-kubectl-neat
spec:
  containers:
    - name: nginx
      image: nginx:1.19-alpine
      ports:
        - containerPort: 80

マニフェストを適用して kubectl get pods xxx -o yaml コマンドを実行すると，以下のように表示される．metadata.* も spec.* も status.* も非常に多くの情報が含まれている．全部載せると長すぎるため今回は割愛して載せる．ザッとスクロールをしてもらって OK！

$ kubectl get pods sandbox-kubectl-neat-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    （中略）
  creationTimestamp: "2021-01-01T13:00:00Z"
  labels:
    app: sandbox-kubectl-neat
  managedFields:
    （中略）
  name: sandbox-kubectl-neat-pod
  namespace: default
  （中略）
spec:
  containers:
  - image: nginx:1.19-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
    - containerPort: 80
      protocol: TCP
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-klk8p
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: docker-desktop
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: default-token-klk8p
    secret:
      defaultMode: 420
      secretName: default-token-klk8p
status:
  （中略）

「kubectl-neat」をインストールする

「kubectl-neat」は kubectl プラグインとして提供されているため，Krew を使えば簡単にインストールできる．kubectl krew install neat コマンドでインストールすれば，kubectl neat help コマンドが実行できるようになる．

$ kubectl krew install neat

Installing plugin: neat
Installed plugin: neat
\
 | Use this plugin:
 |  kubectl neat
 | Documentation:
 |  https://github.com/itaysk/kubectl-neat
/

$ kubectl neat help

なお，最初に Krew をインストールしておく必要があるため，はじめて使う場合は以下のドキュメントを参照する．

krew.sigs.k8s.io

「kubectl-neat」を試す

さっきと同じ Pod に対して「kubectl-neat」を試す．実行する方法は大きく2種類あり「kubectl get pods xxx -o yaml | kubectl neat のようにパイプをする方法」と「kubectl neat get pods xxx -o yaml のようにラッパーとして使う方法」がある．

実際に「kubectl-neat」を使うと，以下のように表示される．非常にスッキリした！個人的に使うのに便利だし，デモをするときに「意図的に」情報量を落とす場合などに使えそう．実際にデモをする場合は「kubectl-neat」を使う意図を明確に伝えておく必要がありそう．

$ kubectl get pods sandbox-kubectl-neat-pod -o yaml | kubectl neat
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: sandbox-kubectl-neat
  name: sandbox-kubectl-neat-pod
  namespace: default
spec:
  containers:
  - image: nginx:1.19-alpine
    name: nginx
    ports:
    - containerPort: 80
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  serviceAccountName: default
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300

マニフェストに ServiceAccount を指定する

GitHub リポジトリの README.md を読むと「kubectl-neat」によって削除される条件（Admission Controllers 対応表）が載っている．例えば ServiceAccount だと，以下のように default-token-* に該当するボリュームは削除されると書いてある．

Remove default-token-* volumes. Remove deprecated spec.serviceAccount

さっきと同じ Pod のマニフェストに serviceAccountName を指定して，適用しておく．

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-kubectl-neat-pod
  labels:
    app: sandbox-kubectl-neat
spec:
  serviceAccountName: sandbox-kubectl-neat-service-account
  containers:
    - name: nginx
      image: nginx:1.19-alpine
      ports:
        - containerPort: 80

もう1度 kubectl get pods sandbox-kubectl-neat-pod -o yaml | kubectl neat を実行して事前確認との差分を以下に載せる．今度はボリューム関連のマニフェストが追加されていた．これは「kubectl-neat」の仕様通り，default-token-* に該当せずに表示されている．

@@ -12,9 +12,13 @@
     name: nginx
     ports:
     - containerPort: 80
+    volumeMounts:
+    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
+      name: sandbox-kubectl-neat-service-account-token-n59lc
+      readOnly: true
   preemptionPolicy: PreemptLowerPriority
   priority: 0
-  serviceAccountName: default
+  serviceAccountName: sandbox-kubectl-neat-service-account
   tolerations:
   - effect: NoExecute
     key: node.kubernetes.io/not-ready
@@ -24,3 +28,7 @@
     key: node.kubernetes.io/unreachable
     operator: Exists
     tolerationSeconds: 300
+  volumes:
+  - name: sandbox-kubectl-neat-service-account-token-n59lc
+    secret:
+      secretName: sandbox-kubectl-neat-service-account-token-n59lc

まとめ

「kubectl-neat（kubectl neat コマンド）」を使うと Kubernetes のマニフェストから「冗長な」情報を削除して表示できる．知っておくと便利！デモをするときに「意図的に」情報量を落とす場合などに使えそう．

github.com

「あのサービスに似たサービス」を探せる AlternativeTo

「AlternativeTo」を使うと「あのサービス（ツール）に似たサービス（ツール）」を探せる．有名な Product Hunt にも Alternative products という機能があって似ているけど，「AlternativeTo」はサービスだけではなくツールも多く登録されている．個人的によく使っていることもあり，今回は「AlternativeTo」を紹介する．

alternativeto.net

Visual Studio Code (VS Code)

「AlternativeTo」で Visual Studio Code (VS Code) を調べると，Atom や IntelliJ IDEA など，他のエディタを探せる．他には Brackets など，今まで使ったことがなかった（もはや存在すら知らなかった）エディタに出会うこともできる．

alternativeto.net

Postman

次に API Client としてよく使われている Postman を調べると，Insomnia REST Client や Paw など，人気のある API Client を探せる．さらに Advanced REST client など，Chrome 拡張機能まで探せるのは「AlternativeTo」の良いところだと思う．

alternativeto.net

Trello

今度はタスク管理ツールとしてよく使われている Trello を調べると，Wrike や Taiga.io や Asana など，たくさんのタスク管理ツールに出会える．その中でも ClickUp は機能も多く，興味を持ったので，無料アカウントを作って試しているところ．

alternativeto.net

IFTTT

サービスを組み合わせて自由にワークフローを構築できる IFTTT を調べると，Zapier はとても人気がありそうだった．

alternativeto.net

他には n8n.io も載っている．実は今月に n8n.io に入門した記事を書いたのは「AlternativeTo」で発見したことに繋がっている．「AlternativeTo」を使って「ブログネタ」を探すことにも活用できる！便利！

kakakakakku.hatenablog.com

まとめ

「AlternativeTo」を使うと「あのサービス（ツール）に似たサービス（ツール）」を探せる．例えば，新しくツールを導入するときに「代替案はある？」と聞かれても困らないように事前に調べたり，使っているサービスに似たサービスを探してブログネタにしたり，いろいろと活用できる．ブックマークしておくと便利なサイトだと思う！

3年間続けた「ブログメンタリング」の振り返りと2021年の方向性

2017年12月から「ブログメンタリング」という個人活動を続けて「3年間」になった．ブログメンタリングを簡単に表現すると「技術ブログに悩んでいる人の悩みを解消する 1 on 1」と言える．ブログメンタリング内容などの詳細は，2019年6月に DevLOVE X で登壇した資料を見てもらえると今でも参考になるはず！今回の記事では，3年間のブログメンタリングを振り返りつつ，2021年の方向性をまとめる．

Stats 📝

3年間でブログメンタリング卒業生は「計58名」になった．ブログメンタリングでは最大3ヶ月として自由に卒業期間を選べる（月末に決めてもらう）仕組みにしてある．メンタリング期間の割合としては以下のようになる．55% (32名) は「3ヶ月」を選ばれた．ブログメンタリング自体に期待していたことと大きく違っていたり，急遽続けられなくなってしまった場合のみ，1ヶ月もしくは2ヶ月目途中での卒業もあった．

メリット 📝

「ブログメンタリング」という名前だけ聞くと，とても怪しく（胡散臭く）感じるだろうし，アフィリエイト生活を目指しそうな雰囲気もあるけど（笑）意図的にそういうネーミングにした．実際には「テックブログ習慣化」や「記事クオリティ向上」や「ソーシャル活用術」など，テックブログを軸に幅広く「アウトプット」を実践していく．

普段ブログ記事をレビューしてもらうという機会は少なく貴重だと思うし，ブログメンタリング開始前にヒアリングした個別の課題感にフォーカスした「最善のアドバイス」を「最善なタイミング」で提供するコミュニケーションにも価値があると思う．ブログメンタリングを「自己ブランディング向上」に活用したメンティもいれば，三日坊主にならないための「矯正ギブス」としての役割を希望されていたメンティもいた．またブログメンタリング卒業生ならわかる「卒業フィードバック」も長文でよく驚かれる．詳しくは卒業ブログを検索してみてもらえればと！

課題 1 : スケーラビリティ 📝

僕自身「メンタリング」は本気で取り組んでいるし，日々多くの時間を投資しているけど，あくまで個人活動（趣味）ではあるため，同時に受けられるメンティ数には限界がある．過去最大で「同時に9名」を受けたこともあったけど，仕事とのバランスも考慮すると「同時に4名前後」がベストだった．そして，Stats にも載せた通り，多くのメンティがメンタリング期間として「2-3ヶ月」を希望されるため，新規メンティ募集のタイミングは「1年に3,4回」となる．特に2019年からは募集人数を超える応募があり，倍率が高くなってお断りをする場面も多々あり，結果的に僕自身の「スケーラビリティ」に課題を感じていた．

課題 2 : 一時的なブースト役 📝

ブログメンタリングを卒業したら，当然ながらノルマ生活をする必要はなく，ある意味「縛り」からは解放される．またブログメンタリング卒業後に「あえて」ブログを書かないことを選んだり，更新頻度を下げたりするメンティもいる．ブログメンタリングに参加して「自信を持って継続的に書かないことに決められた」というフィードバックもあり，素晴らしいと思う．多種多様な結果があって興味深い！

課題としては，卒業後に「時間捻出」や「ネタ切れ」や「モチベーション低下」などの理由でブログの更新が止まってしまったメンティが実際にいたりして，これはブログメンタリングを通して「伝えるべきことを伝えられていなかった」という観点においては僕自身にも責任があると考えている．言い換えると，ブログメンタリングの役割が「健康ドリンク」のように「一時的なブースト役」になってしまっていた可能性がある．例えば，ライザップで食生活などを改善して痩せたとしても，すぐにリバウンドをしてしまうのと似ているように感じる．ようするに「中長期的な習慣化」に実はアプローチできていなかったのでは？という点も課題だった．

ブログメンタリング 2021 : テックブログ Tips マガジン (仮) 📝

「4年目」となるブログメンタリングでは，今までと違うスタイルに挑戦してみることにした．「テックブログ Tips マガジン」というのはあくまで仮名だし正式名称は付けないかもしれないけど，2021年は「3年間のブログメンタリングで伝えていたテックブログ Tips を整理してブログで定期的に紹介する」という企画に挑戦する．特に上記の課題2点を解決するアプローチにすることを強く意識している．逆に今までの良さでもあった「1 on 1（パーソナルメンタリング）」というメリットはなくなる．トレードオフだと思う．あくまで検証も兼ねた企画になるため，様子を見ながらやっていく．お楽しみに！

4年目も引き続き趣味として 📝

ブログメンタリング卒業生から「これで無料なのは意味不明すぎる」と褒めていただくことも多いけど，僕としてはあくまで個人活動（趣味）の範囲でやらせてもらっている．だからこそ「Amazon のほしい物リストでお返しさせてもらえませんか？」と言っていただけてもお断りしているし（ありがとうございます！），他にも「有償でテックブログを監修してもらえませんか？」という相談や「メンタープラットフォームに登録しませんか？」という紹介もいただくけど，現時点では全て断っている．まだまだ趣味として試行錯誤のフェーズだし，マネタイズできるようなクオリティではないと思う．4年目もスタイルは違えど引き続き趣味として頑張っていく！

まとめ 📝

3年間続けてきた「ブログメンタリング」を振り返りつつ，2021年の方向性をまとめた．お楽しみに！

関連記事

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

n8n.io 入門 : IFTTT のようなワークフローを構築しよう

「n8n.io」を使うと GitHub / Slack / Google Sheets など多くのサービス（ドキュメントを見ると 240 以上もインテグレーションできる！）を組み合わせて自由に「ワークフロー」を構築できる．関連サービスで言えば IFTTT のような感じ！例えば IFTTT Pro に課金せずにセルフホスティングできたりする．今回は「n8n.io 入門」を目的として Mac で Docker を使って「n8n.io」を試す．現状だと Docker と npm (npx) で試せる．なお，SaaS として使える「n8n.cloud」もある（最近まで coming soon になっていた）．

n8n.io

n8n.io 入門 : 完成形

今回は「GitHub リポジトリに対する Star⭐/ Unstar⭐をトリガーに Slack 通知とコマンド実行に条件分岐をするワークフロー」を構築して「n8n.io」に入門する．完成形を以下に載せておく．実際に Star⭐の通知を受けられる仕組みを構築できると便利そう．

1. 起動する

Quickstart に載っている通り，Docker を使ってローカル環境を起動する．1点ポイントがあり n8n start に --tunnel オプションを付ける．GitHub などの Webhook でトリガーするためにインターネット側からローカル環境に接続できるようにする必要がある．ドキュメントにも書いてある通り，--tunnel オプションは「ローカル環境」として気を付けて使う．

$ docker run -it --rm \
    --name n8n \
    -p 5678:5678 \
    -v ~/.n8n:/root/.n8n \
    n8nio/n8n \
    n8n start --tunnel

docs.n8n.io

docker run コマンドで「n8n.io」を起動してから http://localhost:5678/ にアクセスをすると，以下のようにワークフロー画面を表示できるようになる．簡単！そして UI も見やすく実装されている．

2. トリガー設定をする

さっそくトリガーを設定していく．画面右上にある + アイコンを押して，Trigger で github と検索すると GitHub Trigger を選択できるようになる．分類としては以下の通り．本当にインテグレーションが多くある．

• Regular : アクション
• Trigger : トリガー
• All : 全て

別途準備しておいた GitHub の Personal access tokens を使って Webhook の設定をする．Events には star 以外に issue や pull_request や push などを選べる．

• Authentication : Access Token
• Repository Owner : kakakakakku
• Repository Name : redash-hands-on
• Events : star

トリガー設定を完了すると，ワークフロー画面に表示される．

3. トリガー設定を確認する

この時点で動作確認をする．今回はワークフロー名を playground として保存して，画面下にある Execute Workflow ボタンを押すと待機状態になる．実際に kakakakakku/redash-hands-on リポジトリに Star⭐をすると，GitHub Trigger 上に ① と表示される．GitHub Trigger をクリックすると「レスポンスボディ」など詳細に確認できる．

4. 条件分岐を設定する

次に IF を使って条件分岐を設定する．「n8n.io」の便利な点は「レスポンスボディ」の値を使って柔軟に条件を設定できるところで，今回は GitHub Trigger のレスポンスから body.action の結果を取得して created であれば Star⭐と判断する．Unstar⭐の場合は deleted という値になる．

最終的に body.action (Equal) created という条件にする．

5. Slack 通知とコマンド実行を設定する

最後は Star⭐の場合に「Slack 通知 (Slack)」を設定する．Unstar⭐の場合に「コマンド実行 (Execute Command)」を設定する．特に意味はなく「n8n.io」を試すために設定した．詳細は割愛する．同じように画面下にある Execute Workflow ボタンを押せば動作確認できる．

まとめ

今回は簡単なワークフローを構築して「n8n.io」に入門した．便利！もっと便利に使うために以下のアクションは気になる！

• Regular : アクション
  • Twitter - Node - n8n.io
  • Google Sheets - Node - n8n.io
  • AWS Lambda - Node - n8n.io
  • HTTP Request - Node - n8n.io
• Trigger : トリガー
  • Trello - Node - n8n.io
  • Cron - Node - n8n.io

「n8n.io」の実装は GitHub リポジトリに公開されているし，デフォルト設定では SQLite にデータを格納しているし（実際に ~/.n8n/database.sqlite を確認できる），コードを読むネタとしても使えそう．引き続き「n8n.io」を試していくぞー！

github.com