kakakakakku blog

Weekly Tech Blog: Keep on Learning!

「Slack Orb」を使って CircleCI から Slack に通知する

CircleCI のジョブ結果を Slack に通知する場合,今までは CircleCI の Webhook と Slack の Incoming WebHooks を組み合わせて実現していた.最近読んでいる「CircleCI 実践入門」「Slack Orb」を使う方法が載っていたので,プライベートで使っている GitHub リポジトリの通知を移行することにした.実際に「Slack Orb」で試した内容を整理しておきたいと思う.なお「CircleCI 実践入門」の書評記事は別途書く.

「Slack Orb」を試す

まず,CircleCI の Project SettingsSlack Integration を選択して,Webhook URL を登録しておく.

f:id:kakku22:20200925233119p:plain

次に .circleci/config.yml「Slack Orb」の設定を追加する.ポイントは version2.1 にしておくことと,orbs の設定をしておくこと.そして今回は「Slack Orb」slack/status コマンドを使う.今回は以下のように exit をするサンプルを用意した.

version: 2.1

orbs:
  slack: circleci/slack@3.4.2

jobs:
  hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run: exit 0
      - slack/status

workflows:
  version: 2
  ci:
    jobs:
      - hello

exit 0exit 1 を使って実行すると,以下のように「成功」「失敗」も Slack に通知できるようになった.簡単!

f:id:kakku22:20200925233135p:plain

fail_only パラメータを追加する

実運用を考えると,ジョブが「失敗」したときに通知できれば十分だと思う.その場合は slack/status コマンドに fail_only パラメータを追加する.true を設定すると「失敗」したときに通知できるようになる.ドキュメントを読むと,他にもパラメータは多くある.

(中略)

jobs:
  hello:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run: exit 1
      - slack/status
          fail_only: true

(中略)

「Slack Orb」コマンド slack/notify

ドキュメントを読むと「Slack Orb」には slack/status 以外にもコマンドが用意されている.特に任意の値を通知できる slack/notify コマンドは使える場面が多くあると思う.

  • slack/approval
  • slack/notify
  • slack/notify-on-failure
  • slack/status

以下のサンプルのように slack/notify コマンドを使える.今回はパラメータとして titlemessagementions を設定した.他にも colorimage_url など,パラメータは多くある.

(中略)

jobs:
  htmllint:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run: exit 0
      - slack/notify:
          title: 🚨
          message: アプリケーションエラー⚡
          mentions: kakakakakku

(中略)

実行すると,以下のように任意の値を通知できるようになった.簡単!

f:id:kakku22:20200925233239p:plain

疑問 1 : Alpine

Alpine で作った Docker イメージを CircleCI のジョブで使う場合,slack/status コマンドを実行するときに Bashcurl がなく,エラーになってしまう.ワークアラウンドとして .circleci/config.yml の中で run: apk add bash curl を追加して,一時的に Bashcurl をインストールすることにより,問題なく使えるようになった.Alpine を使う場面は多いと思うし,覚えておくと良さそう.

#!/bin/sh -eo pipefail
if [ ! -x /bin/bash ]; then
  echo Bash not installed.
  exit 1
fi

疑問 2 : when パラメータ

「CircleCI 実践入門」slack/notify コマンドと when パラメータを組み合わせた例が紹介されていた.実際に試したところ Build Error になってしまった.確かに CircleCI の設定に when パラメータは存在するけど,slack/notify コマンドと組み合わせられる?

steps:
  - slack/notify:
      message: デプロイ失敗
      when: on_fail

まとめ

「Slack Orb」を使って,CircleCI のジョブ結果を Slack に通知できるようにした.今後もどんどん使っていこうと思う.Alpine で作った Docker イメージを CircleCI のジョブで使っている場合はワークアラウンドも必要になる.「CircleCI 実践入門」は本当に良書だと思う.書評記事は今週公開する予定!

2年間も積読していた「スタンフォード式 最高の睡眠」を読んだら朝スッキリと起きられるようになった

8月に「スタンフォード式 最高の睡眠」を読んだ.今さら?と思われるかもしれないし,僕が「睡眠」に興味を持っていることに驚かれるかもしれない.本書は「2017年2月」に出版されていて,友人に「読んでみたら?」と薦められたこともあり「2018年8月」に購入していた.しかし,読む必要性を感じられないまま「2年間」も積読して,やっと読むことができた.読んだ.睡眠の「質 (Quality)」を高める基本的なプラクティスを学べたら良いなぁーという期待をしていたけど,本書を読んでから朝スッキリと起きられるようになったし,今までよりもスッと入眠できるようになった.なぜ2年間も積読していたんだろう!

スタンフォード式 最高の睡眠

スタンフォード式 最高の睡眠

  • 作者:西野精治
  • 発売日: 2017/02/27
  • メディア: 単行本(ソフトカバー)

前提 💤

書評を書く前の前提として,僕自身は「満足した睡眠」を取れていないと思う.自分自身の欲求の中でもプライオリティは低いし,規則正しい生活をするのが苦手という性格もある.活動時間を長く確保することを重要視しているため,トレードオフの対象になっている.良し悪しは価値観によって違うと思う.

  • 基本的に朝に弱く,完全に夜型
  • とは言え,仕事の関係もあり,1週間に3日程度は「朝6~7時」に起きる
  • アメリカ時間で働くこともあり「夜23時~24時」に起きて昼夜逆転の生活をすることもある
  • 娘たちを寝かすときに一緒に寝落ちしてしまうこともある
  • 早朝に起きた娘たちに馬乗りにされて強制的に起こされてしまうこともある
  • あまり週末に予定を入れず,寝溜めをしている
  • Trello で管理している週タスクを終わらせるために徹夜をすることもある(完徹ではなくパワーナップを取る)
  • 体質的に「ショートスリーパー」ではない
  • どんなに寝不足だったとしても仕事中に眠くなることはほとんどない
  • 寝具に興味がなくどこでも寝れる(ただし首と腰はいつも痛い)

90分の黄金法則 💤

まず,本書の序盤に載っている「90分の黄金法則」は1番インパクトがあった.睡眠に対して「量の確保」ではなく「質の確保」を重要視し,それは「眠り始めの90分で決まる」と書いてあった.本書を読んでから「眠り始めの90分を深くすること」を強く意識をして,後述する「眠りのスイッチ」と組み合わせるのが効果的だった.

週末の寝溜め 💤

読まずともわかっていたけど,バッサリと書かれていた.週末の寝だめは「睡眠負債」を増やしているらしい.

週末の寝だめごときで、睡眠負債は解決しない。

ううう...

睡眠負債は、脳にも体にもダメージを与える。

起床のウィンドウ 💤

「90分間の倍数で寝る」というプラクティスは数年ほど実践しているけど,正直言って,スッキリ起きられるときもあれば,全く起きられないときもあった.本書を読んだら「覚醒戦略①」として「起床のウィンドウ」が紹介されていた.具体的には「スリープサイクルには個人差がある」ため,アラームを「20分間隔ぐらいで」でセットする.例えば「7時」に起きる場合は「6時40分」「7時20分」にセットする.

個人的には非常に効果があり,今までは「目覚まし3個(スマホ / 大音量 目覚まし時計 / Amazon Echo Show)」を組み合わせて,オーケストラのように数分間隔で音を鳴らしてギリギリ起きていたけど,今は「目覚まし1個(スマホ)」で起きている.何という変化!

パワーナップ 💤

前提にも書いた通り,もともと「パワーナップ(仮眠)」を取る習慣がある.取る時間はバラバラだけど,1番多いのは「21~24時(3時間)」あたり.娘たちを寝かせるときに寝落ちしながらパワーナップにしてしまうこともある.本書にも同じようなことが書かれていた.当然ながら「パワーナップ」を取れば OK という意味ではなく,どうしても作業をしなければいけないときに徹夜をするのではなく,パワーナップを取るべきという文脈で書かれている.自己流で実践していたことが解説されていて参考になった.

私がおすすめするのは、眠気があるならまず寝てしまい、黄金の90分が終了した最初のレム睡眠のタイミングに起きて、資料作りにとりかかるという作戦だ。最初のレム睡眠も入れてわずか100分ほどしか寝ていないとはいえ、深く眠れていれば質は確保される。

眠りのスイッチ 💤

本書には体温調節を重要視するプラクティスが載っていて,例えば「寝る90分前にお風呂に入る」と書いてある.現状だと,娘たちとシャワーに入ることも多く,時間的な自由はなく無理だった.足湯をするプラクティスも載っていて,実際に2回試したけど,とにかく面倒だし,足湯を準備する時間があったら他の作業に時間を使いたく,価値観が合わなかった.

本書を読むまでは,基本的にベットに入ってからスマホでネットサーフィンをしたり,YouTube を観たりしながら,劇的な睡魔を待ちながら「寝落ち」をする生活をしていたけど,面白くて寝れなかったりすることも多かった.脳に刺激を与えないという「当たり前」のことが本書には書かれていて,今はベットにスマホを持ち込まないように我慢している.もう1点は「コーヒー」で,今までは24時間気にせずにガブガブと飲み続けていた.今は18時以降になると「デカフェ」を飲むようにしている.当たり前すら実践できていないことに気付けて良かった.

まとめ 💤

8月に「スタンフォード式 最高の睡眠」を読んだ.不規則な生活ではあるけど,本書で学んだプラクティスを少し取り入れることにより,朝スッキリと起きられるようになった.特に「90分の黄金法則」「眠りのスイッチ」の組み合わせが効果的だった.また今まで自己流で実践していた「パワーナップ」も最低限の効果があることも学べて良かった.さーて,この記事を書いてる今はもう夜中の2時半!おやすみなさい!

Brewfile で Homebrew のライブラリを管理しよう!

Homebrew で Mac の環境構築をする機会は多いと思う.ライブラリをインストールするときに brew install xxx と実行すればすぐに使える.ただし,Mac を移行したり,再インストールするときに brew install を再実行するのは面倒で,今回は Homebrew Bundle (Brewfile) を紹介する.同僚に Brewfile を紹介する機会があり,今後もサッと紹介できるようにブログにまとめておくことにした.

github.com

Homebrew Bundle (Brewfile) とは?

Homebrew Bundle を使うと Homebrew でインストールするライブラリを Brewfile というファイルで管理できる.プログラミング言語だと Gemfilepackage.jsonpom.xml のような感じ.さらに Brewfile を GitHub の dotfiles リポジトリに置いておけば,プルリクエストを使って個人設定をうまく管理することもできる.以下に Brewfile のサンプルを載せておく.

brew "ghq"
brew "git"
brew "kubernetes-cli"
brew "peco"
brew "vim"

インストールするときは brew bundle コマンドを実行すれば OK!便利!僕は「80個」も管理している...!

$ brew bundle
Installing ghq
Installing git
Installing kubernetes-cli
Installing peco
Installing vim

Homebrew Bundle complete! 80 Brewfile dependencies now installed.

Brewfile 構文 🍺

よく使う Brewfile 構文を「4種類」紹介する.基本的には brew コマンドに対応している.

1. brew

brew 構文を使うと,Homebrew に正式に登録されたライブラリをインストールできる.brew install コマンドと同じくライブラリ名を引数に記述する.

brew "ghq"
brew "git"
brew "kubernetes-cli"
brew "peco"
brew "vim"

2. tap

tap 構文を使うと,Homebrew に正式に登録されていないライブラリをインストールできる.brew tap コマンドに対応している.以下のサンプルは mkrmobeksctl など,よく使うライブラリをインストールするように記述している.

tap "mackerelio/mackerel-agent"
tap "remotemobprogramming/brew"
tap "weaveworks/tap"

brew "mackerelio/mackerel-agent/mkr"
brew "remotemobprogramming/brew/mob"
brew "weaveworks/tap/eksctl"

なお,brew tap は指定した GitHub リポジトリを Homebrew に登録する仕組みとなり,${userName}/homebrew-${repositoryName}${organizationName}/homebrew-${repositoryName} という命名規則でリポジトリがある.サンプルとして載せたライブラリのリポジトリもある.このあたりを調べていくと Homebrew に詳しくなれるはず!

3. cask

cask 構文を使うと,Google Chrome など,Mac アプリをインストールできる.brew cask install コマンドに対応している.個人的には直接 .dmg でインストールすることも多く,あまり活用できていないけど,例えば BlackHoleKeycastr OpenInTerminal など,最近ブログで紹介したライブラリなどは Brewfile に記述している.

tap "homebrew/cask"

cask "blackhole"
cask "keycastr"
cask "openineditor-lite"
cask "openinterminal-lite"

4. mas

mas 構文を使うと,App Store から Mac アプリをインストールできる.mas コマンドに対応している.個人的に必須な CotEditorTomato OneMagnet などを Brewfile に記述している.

brew "mas"

mas "CotEditor", id: 1024640650
mas "Tomato One", id: 907364780
mas "Magnet", id: 441258766

今から Brewfile に移行できる?

今まで個別に brew install コマンドを実行していて,今後 Brewfile に移行したい人もいると思う.実は brew bundle dump コマンドを実行すると,自動的に現在の環境から Brewfile を生成できるようになっている.生成された Brewfiletapbrewcaskmas の順番でキレイに並んでいるし,ライブラリ名もアルファベット順に並んでいるので,非常に見やすいと思う.

$ brew bundle dump

また Brewfile をよく見ると「これ何だっけ?」というライブラリが入っていると思う(僕だけ?).ライブラリをアンインストールするときに brew uninstall コマンドを実行する必要はなく,Brewfile からエントリーを削除して brew bundle cleanup コマンドを実行すればアンインストールできる.たまにアンインストールされないこともあり,その場合は brew uninstall コマンドを実行している.

$ brew bundle cleanup

フォント管理も Brewfile で!

最後に Brewfile でフォント管理をする Tips を紹介する.フォントをインストールする機会は多くないけど,Keynote を作るときに使う「MigMix フォント」など,Mac を移行するときに毎回サイトからダウンロードするのは面倒だと思う.既に紹介した tap 構文と cask 構文を組み合わせて,以下のように Brewfile に設定できる.

tap "homebrew/cask-fonts"

cask "font-migu-1p"

フォントは多くあり,brew search コマンドを使えば検索できる.例えば Noto Sans CJK JP など.

$ brew search font-

$ brew search font-noto-sans-cjk
==> Casks
font-noto-sans-cjk
font-noto-sans-cjk-jp
font-noto-sans-cjk-kr
font-noto-sans-cjk-sc
font-noto-sans-cjk-tc

まとめ

同僚に Homebrew Bundle (Brewfile) を紹介する機会があり,ブログにまとめておくことにした.Brewfile ファイル管理して brew bundle コマンドを実行すれば,ライブラリを簡単にインストールできる.tap / brew / cask / mas など,Homebrew の機能もサポートしている.もし今後 Brewfile に移行するなら brew bundle dump コマンドも使える.便利!

github.com

Flux と kustomize を組み合わせた GitOps 入門チュートリアル「Using Flux with Kustomize」を試した

昨日の記事では GitOps に入門できる Flux のチュートリアル「Get started with Flux」を紹介した.次は Fluxkustomize を組み合わせて,ベースマニフェストに対して環境ごとに異なる設定値を適用する流れを学んでいく.

kakakakakku.hatenablog.com

チュートリアル「How to bootstrap Flux using Kustomize」

Flux のドキュメントに載っているチュートリアル「How to bootstrap Flux using Kustomize」は,名前の通り「kustomize を使って Flux 自体をブートストラップする」内容だった.具体的には Flux を Kubernetes の Namespace flux ではなく,任意の Namespace に起動するだけだった.実際に試したけど,個人的には試さなくて良いと思う.

https://docs.fluxcd.io/en/1.20.2/tutorials/get-started-kustomize/docs.fluxcd.io

チュートリアル「Using Flux with Kustomize」

次に GitHub に公開されているチュートリアル「Using Flux with Kustomize」を試した.これは期待していた通り,Flux を使って kustomize build をして環境ごとに異なる設定値を適用する流れを学べる.今回はこのチュートリアルを紹介する.

github.com

1. 事前準備

今回も Docker Desktop for Mac "Edge" を使って,以下の Kubernetes 環境で試す.昨日の記事と同じく fluxctl コマンドも使う.

$ kubectl version --short
Client Version: v1.18.6
Server Version: v1.18.6

$ fluxctl version
1.20.2

そして,チュートリアルで使う GitHub リポジトリ fluxcd/flux-kustomize-example をフォークしておく.ディレクトリ構成は以下となり,kustomize で使うディレクトリ (base / staging / production) と Flux の設定ファイル .flux.yaml がある.もしかしたら kustomizeOverlay は?と気になるかもしれない.記事の最後に書いておいた.

$ tree -La 2 .
.
├── .flux.yaml
├── base
│   ├── demo-ns.yaml
│   ├── kustomization.yaml
│   ├── podinfo-dep.yaml
│   ├── podinfo-hpa.yaml
│   └── podinfo-svc.yaml
├── production
│   ├── flux-patch.yaml
│   ├── kustomization.yaml
│   └── replicas-patch.yaml
└── staging
    ├── flux-patch.yaml
    ├── kustomization.yaml
    └── replicas-patch.yaml

2. セットアップ

Namespace flux を作り,fluxctl install コマンドと kubectl apply コマンドを組み合わせて Flux 環境を構築する.

$ kubectl create namespace flux

$ export GHUSER=kakakakakku

$ fluxctl install \
--git-user=${GHUSER} \
--git-email=${GHUSER}@users.noreply.github.com \
--git-url=git@github.com:${GHUSER}/flux-kustomize-example \
--git-path=staging \
--namespace=flux \
--manifest-generation | kubectl apply -f -

serviceaccount/flux created
clusterrole.rbac.authorization.k8s.io/flux unchanged
clusterrolebinding.rbac.authorization.k8s.io/flux configured
deployment.apps/flux created
secret/flux-git-deploy created
deployment.apps/memcached created
service/memcached created

$ kubectl rollout status deployment/flux -n flux
deployment "flux" successfully rolled out

なお,昨日の記事で紹介したチュートリアル「Get started with Flux」とは異なるオプションがあり,以下に載せておく.

  • --git-path
    • リポジトリにあるディレクトリ名を指定する
    • kustomize で使う staging or production を指定できる
    • 今回は staging を指定する
  • --manifest-generation
    • マニフェストの自動生成を有効化する
    • デフォルトは false

特に --manifest-generation は今回重要な設定となり,リポジトリ直下に置いてある .flux.yaml ファイルを使ってマニフェストを自動生成する.今回リポジトリに用意されていた .flux.yaml は以下となり,やっと kustomize build コマンドとの関係を確認できる.ここで実行していたんだ!

version: 1
patchUpdated:
  generators:
    - command: kustomize build .
  patchFile: flux-patch.yaml

なお .flux.yaml に関しては,以下のドキュメントに詳しく載っている.

https://docs.fluxcd.io/en/1.20.2/references/fluxyaml-config-files/docs.fluxcd.io

3. アクセス権限の設定

昨日の記事と同じように GitHub リポジトリの Deploy keys に公開鍵を追加する.Allow write access にもチェックを入れておく.

$ fluxctl identity --k8s-fwd-ns flux
ssh-rsa xxx

4. 動作確認

少し待てば Flux によって Namespece demo にアプリケーションが起動される.ポートフォワードをすれば http://localhost:9898 にアクセスできるようになり,実際に curl をすると JSON が返ってくる.

$ kubectl -n demo get pods
NAME                       READY   STATUS    RESTARTS   AGE
podinfo-649f78fc4b-m8n78   1/1     Running   0          105s
podinfo-649f78fc4b-w5l75   1/1     Running   0          47m

$ kubectl -n demo port-forward deployment/podinfo 9898:9898

$ curl http://localhost:9898
{
  "hostname": "podinfo-649f78fc4b-m8n78",
  "version": "1.4.4",
  "revision": "1c3bf10",
  "color": "green",
  "message": "greetings from podinfo v1.4.4",
  "goos": "linux",
  "goarch": "amd64",
  "runtime": "go1.11.6",
  "num_goroutine": "8",
  "num_cpu": "2"
}

チュートリアル手順では動作確認もなく,今回は Horizontal Pod Autoscaler リソースの minReplicasmaxReplicas を確認することにする.GitHub リポジトリの構成を見る限り,staging 環境には Horizontal Pod Autoscaler の設定はなく,base の設定をそのまま使う.実際に kubectl で値を確認しても minReplicas: 1maxReplicas: 2 になっている.

Key base staging production
minReplicas 1 - 2
maxReplicas 2 - 4
$ kubectl -n demo get horizontalpodautoscalers.autoscaling
NAME      REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
podinfo   Deployment/podinfo   <unknown>/99%   1         2         2          100m

5. マニフェストの修正

さっそく staging/replicas-patch.yaml を以下の YAML で新しく作る.staging 環境用に Horizontal Pod Autoscaler リソースの minReplicasmaxReplicas を設定している.

---
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: podinfo
  namespace: demo
spec:
  minReplicas: 2
  maxReplicas: 10

また staging/kustomization.yaml にも patchesStrategicMerge の設定を追加しておく.やっと kustomize build をする準備が整ったため,最後に git commitgit push をする.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../base/
patchesStrategicMerge:
- replicas-patch.yaml

なお,kustomize の入門記事も前に書いているため,合わせて読んでもらえると良さそう.

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

6. 適用確認

少し待てば,Flux によって適用される.kubectl の結果は以下のようになり,staging 環境の設定が minReplicas: 2maxReplicas: 10 になっている.うまく動いた!

Key base staging production
minReplicas 1 2💡 2
maxReplicas 2 10💡 4
$ kubectl -n demo get horizontalpodautoscalers.autoscaling
NAME      REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
podinfo   Deployment/podinfo   <unknown>/99%   2         10        2          100m

7. リソース削除

チュートリアル手順には載っていなかったけど,最後にリソースを削除しておく.以下のコマンドを使えば良いと思う.

$ export GHUSER=kakakakakku

$ fluxctl install \
--git-user=${GHUSER} \
--git-email=${GHUSER}@users.noreply.github.com \
--git-url=git@github.com:${GHUSER}/flux-kustomize-example \
--git-path=staging \
--namespace=flux \
--manifest-generation | kubectl delete -f -

$ kubectl delete namespace flux

$ kubectl delete deployments podinfo -n demo

$ kubectl delete horizontalpodautoscalers.autoscaling/podinfo -n demo

$ kubectl delete service/podinfo -n demo

まとめ

引き続き Flux に入門するために今回は Fluxkustomize を組み合わせたチュートリアル「Using Flux with Kustomize」を試した.Flux「Manifest generation 機能」を使えば fluxdkustomize build を実行させることができる.流れを把握できて良かった.1点注意点としては,kustomizeOverlay には対応していなさそうだった.Roadmap を確認したところ「Flux v2」の Goals には「Kustomize overlays」に対する言及があり,サポートされる可能性がありそう.

次は Argo CD を試していくぞー!

toolkit.fluxcd.io

Flux を使った GitOps 入門チュートリアル「Get started with Flux」を試した

最近よく聞くようになった「GitOps」というデリバリ戦略があり,Single Source of Truth として Git を採用し,Kubernetes リソースなどを継続的にデリバリーしていく.GitOps では,直接 kubectl などを実行せず,例えば GitOps Operator などを使って,Operator からマニフェストを適用する.なお,Git への push をトリガーして CI サービスからデプロイする従来の戦略は比較として「CIOps」と表現される.詳しくは以下の記事に載っている.

また,GitOps を実現するツールも多くある.最近だと「Argo CD」の話題をよく見る.他にも「Flux」「Jenkins X」などもある.また Intuit と Weaveworks のパートナーシップにより「Argo CD」「Flux」を組み合わせた「GitOps Engine」というソリューションもある.詳しくは以下の記事に載っている.

チュートリアル「Get started with Flux」

今回は GitOps に入門するために Flux のチュートリアル「Get started with Flux」を試す.

https://docs.fluxcd.io/en/1.20.2/tutorials/get-started/docs.fluxcd.io

1. 事前準備

今回は Docker Desktop for Mac "Edge" を使って,以下の Kubernetes 環境で試す.

$ kubectl version --short
Client Version: v1.18.6
Server Version: v1.18.6

次に fluxctl コマンドを使えるようにする.今回は brew でインストールしておく.

$ brew install fluxctl
$ fluxctl version
1.20.2

最後にチュートリアルで使う GitHub リポジトリをフォークしておく.

github.com

2. セットアップ

まず,Flux で使う Namespace flux を作っておく.

$ kubectl create namespace flux

次に,Flux 関連の Kubernetes リソースをセットアップする.環境変数 GHUSER に GitHub の個人アカウントを設定して,以下の fluxctl install コマンドを実行すると,マニフェストが自動生成されるため,直接 kubectl apply で適用する.

$ export GHUSER=kakakakakku

$ fluxctl install \
--git-user=${GHUSER} \
--git-email=${GHUSER}@users.noreply.github.com \
--git-url=git@github.com:${GHUSER}/flux-get-started \
--git-path=namespaces,workloads \
--namespace=flux | kubectl apply -f -

serviceaccount/flux created
clusterrole.rbac.authorization.k8s.io/flux unchanged
clusterrolebinding.rbac.authorization.k8s.io/flux unchanged
deployment.apps/flux created
secret/flux-git-deploy created
deployment.apps/memcached created
service/memcached created

$ kubectl rollout status deployment/flux -n flux
deployment "flux" successfully rolled out

$ kubectl get deployments -n flux
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
flux        1/1     1            1           50s
memcached   1/1     1            1           50s

実行結果に載っている通り,Flux / Memcached / RBAC 関連のリソースを起動している.なお,GitOps の全体像や Memcached の利用箇所などは,Flux のドキュメントにも載っている.

GitHub - fluxcd/flux: Successor: https://github.com/fluxcd/flux2 — The GitOps Kubernetes operator より引用

3. アクセス権限の設定

Flux は起動時に SSH キーを生成する仕組みになっている.生成された「公開鍵」をコピーして,GitHub リポジトリに設定することにより,Kubernetes クラスターと GitHub リポジトリを同期できるようになる.そこで fluxctl identity コマンドを実行すれば「公開鍵」を確認できる.今回はそのままコピーして,GitHub リポジトリの Deploy keys に追加する.なお Allow write access にもチェックを入れておく.

$ fluxctl identity --k8s-fwd-ns flux
ssh-rsa xxx

4. 動作確認

チュートリアル手順では,次に GitHub UI でマニフェストを修正していたけど,その前に動作確認をしておくと理解しやすい.既に Flux によって Namespece demo にアプリケーションが起動されているため,以下のように Deployment に対してポートフォワードをする.すると http://localhost:9898 にアクセスできるようになる.curl で JSON を取得し,具体的な値として message を確認すると greetings from podinfo v3.1.5 になっている.

$ kubectl -n demo port-forward deployment/podinfo 9898:9898

$ curl -s http://localhost:9898 | jq '.message'
"greetings from podinfo v3.1.5"

なお,ブラウザから http://localhost:9898 にアクセスすると,以下のようなアプリケーション画面になる.紫イカ?の下にも同じく greetings from podinfo v3.1.5 と表示されている.

アプリケーション画面 - Before

5. アプリケーションの修正

事前準備でフォークした GitHub リポジトリ flux-get-started の中にある Deployment マニフェスト flux-get-started/workloads/podinfo-dep.yaml を修正する.podinfod コンテナの command--ui-message オプションを追加すると,任意の文字列をメッセージとして表示できる仕組みになっているようだった.以下のマニフェストのように --ui-messageWelcome to Flux を追加する.コミットまでしておく.

command:
  - ./podinfo
  - --port=9898
  - --port-metrics=9797
  - --grpc-port=9999
  - --grpc-service-name=podinfo
  - --level=info
  - --random-delay=false
  - --random-error=false
  - --ui-message='Welcome to Flux'

6. Flux による自動適用

約5分程度(インターバル設定による)待つと Flux によって,GitHub にコミットしたマニフェストの修正が自動的に適用される.今回はすぐに確認するため fluxctl sync コマンドを使って即時適用をする.適用後に Pod を確認すると,新しく作られていた.これこそ Flux を使った GitOps の基本と言える.

$ fluxctl sync --k8s-fwd-ns flux

Synchronizing with ssh://git@github.com/kakakakakku/flux-get-started
Revision of master to apply is xxxxxxx
Waiting for xxxxxxx to be applied ...
Done.

$ kubectl get pods -n demo
NAME                       READY   STATUS    RESTARTS   AGE
podinfo-695dc4ffdb-4v9lg   1/1     Running   0          100s
podinfo-695dc4ffdb-qj5bf   1/1     Running   0          100s

同じく Deployment に対してポートフォワードをして動作確認をする.curl で JSON を取得すると,messageWelcome to Flux に変更されている.

$ kubectl -n demo port-forward deployment/podinfo 9898:9898

$ curl -s http://localhost:9898 | jq '.message'
"Welcome to Flux"

アプリケーション画面も紫イカ?の下に Welcome to Flux と表示されている.

アプリケーション画面 - After

7. リソース削除

チュートリアル手順には載っていなかったけど,最後にリソースを削除しておく.以下のコマンドを使えば良いと思う.

$ export GHUSER=kakakakakku

$ fluxctl install \
--git-user=${GHUSER} \
--git-email=${GHUSER}@users.noreply.github.com \
--git-url=git@github.com:${GHUSER}/flux-get-started \
--git-path=namespaces,workloads \
--namespace=flux | kubectl delete -f -

deployment.apps "flux" deleted
secret "flux-git-deploy" deleted
deployment.apps "memcached" deleted
service "memcached" deleted
serviceaccount "flux" deleted
clusterrole.rbac.authorization.k8s.io "flux" deleted
clusterrolebinding.rbac.authorization.k8s.io "flux" deleted

$ kubectl delete namespace flux

$ kubectl delete deployments podinfo -n demo

$ kubectl delete horizontalpodautoscalers.autoscaling/podinfo -n demo

$ kubectl delete service/podinfo -n demo

まとめ

最近よく聞く「GitOps」に入門するために Flux のチュートリアル「Get started with Flux」を試した.試すだけなら,1時間もかからず簡単に楽しめる.また他にも Helm と組み合わせたチュートリアルもある.Flux に限らず Argo CD も含めて,引き続き試していくぞ!

https://docs.fluxcd.io/en/1.20.2/tutorials/get-started/docs.fluxcd.io