git pull --pruneしてマージ済みのローカルブランチを削除するgitのサブコマンドを作った
TerraformのKubernetes ProviderでK8sのリソース管理にトライ
- はじめに
- 環境構成
- 手順
- 下準備
- terraformerによるimport→失敗
- HCLを書いてterraform import
- HCLを編集してリソースを更新してみる
- リソースの名前を変えて、再作成してみる
- 所感
- 参考記事
はじめに
昨日の記事↓で、Kubernetesのリソース設定をTerraformで管理できそうな件について触れた。
TerraformにはKubernetesのProviderもあるので、できるというわけだ。
ググると先行者がいるので、できること自体はわかっているが、オブジェクトの削除や再作成時の動きなど気になるので、自分でも試しておくことにした。
環境構成
さっきこのブログに記事を上げたけど、昨日UbuntuデスクトップにMicrok8sを入れたので、この環境を使う。
- Ubuntu 18.04 LTS
- microk8s v1.18.2
- terraformer v0.8.7
- terraform v0.12.24
- terraform-provider-kubernetes v1.11.2
いつもterraformのHCLを書くのにはIntelliJ IDEAを使っていたのだけど、最近Visual Studio Codeの拡張機能もTerraform v0.12に対応したので、今回はVS Codeを使ってみた。*1
参考: VSCodeでTerraformを書くときの設定(2019/11/07追記: HCL2対応) - Qiita
手順
続きを読むUbuntuでKubernetesのテスト環境としてMicrok8sをセットアップした
- はじめに
- セットアップ手順
- Install
- Join the group
- Check the status
- Access Kubernetes
- Deploy an app
- Use add-ons
- Starting and Stopping MicroK8s
- 所感
- 参考記事
はじめに
Ubuntu 18.04デスクトップ環境で、4/29に昔入れていたminikubeをアンインストールしてしまった(*1)のだが、また手元でさくっと試せるKubernetes環境が欲しくなった。
またMinikubeを入れてもいいのだけど、CanonicalがMicrok8sというのを出しており、これが使えそうだ。
公式ドキュメントや試してみた系の記事を軽く見てみたところ、snapパッケージで簡単にインストール可能できそうだったので、こちらを入れてみることにした。
セットアップ手順
Quick start | MicroK8s に従ってセットアップしていく。
Install
続きを読むKubernetesのマニフェストをリポジトリ管理しつつ、リソースの削除も反映したい件
- はじめに
- 問題
- 方法
- ①labelsでバージョン管理する
- ②kubectl apply --pruneを使う
- ③Argo CDのAutomatic Pruningを使う
- ④Terraformで管理する
- 終わりに
- 余談
- マニフェストをexportして管理する
- 脚注
はじめに
最近、Kubenetesの運用管理に携わるようになりました。
マニフェスト(*1)はYAMLで管理して、Gitリポジトリに入れています。
複数の環境を持つシステムにおいては、Kustomizeを使って、マニフェストをDRYに保つように努力しています。
そんなある日のこと、あるワークロードからExternalNameで参照しているServiceオブジェクトの定義を変えることになりました。
下のような変更です:
apiVersion: v1 kind: Service metadata: - name: my-api1 + name: my-api2 namespace: myapp spec: type: ExternalName - externalName: my-api1.example.com + externalName: my-api2.example.com
問題
……で、このYAMLを kubectl apply
で適用するわけですが、次の事実に気づきました:
- 上のYAMLを
kubectl apply
で適用すると、新しくmy-api2 Serviceが作られるが、 my-api1 Serviceは消えない
metadata.name
を変えなければそうはならないのでしょうが、名前が実体を表していないのは気持ちが悪いので、なるべくなら変えたいところです。
そうでなくとも、並行稼働期間にmy-api2 Serviceを追加し、後からmy-api1 Serviceを削除したいと思った場合も、同じ問題が発生します。*2
つまり、マニフェストから削除しても、単に kubectl apply
するだけでは削除が反映されない、ということです。
この場合の解決策は簡単で、 kubectl delete service my-api1
を叩けば話は終わりです。
実際、このときはそうしました。
しかし、例えばマニフェストをkustomizeで適用する自動化のパイプラインを組んだとき、差分に応じてこういうアドホックな処理を入れるのはつらそうだなと思いました。(まだそこまで自動化できてはいませんが。)
こういった問題の対処については、本などにもあまり載ってなさそうで、どうするのが良いのかと疑問に思いました。
そこで、自分でも少し調べつつ、とあるKubernetesのコミュニティで識者に聞いてみました。
本稿では、その回答も含めて、現在私が把握している方法を紹介します。
※公開コミュニティでの質疑内容ではありますが、どなたの回答かというのは本稿では伏せておきます。
*1:「A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest」 cf. https://kubernetes.io/ja/docs/reference/glossary/#term-manifest
*2:今回はどちらかといえばこれに該当していました。
今更だけどNeoBundleからdein.vimに乗り換えて、プラグインを6つ追加した
はじめに
本当に今更である。
NeoBundleやdein.vimは、Vimのプラグインマネージャーである。
他に有名なものでは、Vundleやvim-plugといったものがある。*1
NeoBundleはもう4年以上前に開発が停止し、dein.vimへの移行が促されている。*2
作業環境
dein.vimのインストール
https://github.com/Shougo/dein.vim#quick-start に従う。
インストール先は ~/.vim/dein
とした。
curl https://raw.githubusercontent.com/Shougo/dein.vim/master/bin/installer.sh > installer.sh
sh ./installer.sh ~/.vim/dein
自分はいつものVim環境を新しいPCやサーバでさっとセットアップしたいことがそこそこあるので、セットアップ用のシェルスクリプトを用意している。
今、そのスクリプトはこんな感じになっている。
vimrcの移行
NeoBundle用の記述をdein.vim用に書き直す。
dein.vimではインストールするプラグインのリストや、それに付随する設定をTOML形式の別ファイルで管理することができるので、その方式を使うことにした。
具体的には、このコミットで対応した。
移行後、 'Align'
プラグインで警告が出ていることにしばらく気づかず、挙動が少しおかしくなっていたが、 'vim-scripts/Align'
に修正したら問題が解消した。
追加したプラグイン
*1:参考: Vim におけるプラグイン管理についてまとめてみた - Qiita
*2:Clarified statement development stopping · Shougo/neobundle.vim@c196111
UbuntuにHomebrewを入れてHomebrew Bundleでパッケージ管理することにした
動作環境
はじめに
tfutils/tfenvを入れようと思ったんだけど、aptやsnapでのパッケージ提供がないようなので、Linuxにも対応しているHomebrewを使うことにした。
本記事では、その実施ログを記す。
Homebrewのインストール
https://docs.brew.sh/Homebrew-on-Linux のガイドに従ってインストール。
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
デフォルトで /home/linuxbrew/.linuxbrew
にインストールされるようだ。
自分しか使ってないマシンだし、特にこだわらないのでこのままで。
インストールログ
% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" [sudo] パスワード: ==> This script will install: /home/linuxbrew/.linuxbrew/bin/brew /home/linuxbrew/.linuxbrew/share/doc/homebrew /home/linuxbrew/.linuxbrew/share/man/man1/brew.1 /home/linuxbrew/.linuxbrew/share/zsh/site-functions/_brew /home/linuxbrew/.linuxbrew/etc/bash_completion.d/brew /home/linuxbrew/.linuxbrew/Homebrew ==> The following new directories will be created: /home/linuxbrew/.linuxbrew/bin /home/linuxbrew/.linuxbrew/etc /home/linuxbrew/.linuxbrew/include /home/linuxbrew/.linuxbrew/lib /home/linuxbrew/.linuxbrew/sbin /home/linuxbrew/.linuxbrew/share /home/linuxbrew/.linuxbrew/var /home/linuxbrew/.linuxbrew/opt /home/linuxbrew/.linuxbrew/share/zsh /home/linuxbrew/.linuxbrew/share/zsh/site-functions /home/linuxbrew/.linuxbrew/var/homebrew /home/linuxbrew/.linuxbrew/var/homebrew/linked /home/linuxbrew/.linuxbrew/Cellar /home/linuxbrew/.linuxbrew/Caskroom /home/linuxbrew/.linuxbrew/Homebrew /home/linuxbrew/.linuxbrew/Frameworks Press RETURN to continue or any other key to abort : (略 : Warning: /home/linuxbrew/.linuxbrew/bin is not in your PATH. ==> Installation successful! ==> Homebrew has enabled anonymous aggregate formulae and cask analytics. Read the analytics documentation (and how to opt-out) here: https://docs.brew.sh/Analytics No analytics data has been sent yet (or will be during this `install` run). ==> Homebrew is run entirely by unpaid volunteers. Please consider donating: https://github.com/Homebrew/brew#donations ==> Next steps: - Run `brew help` to get started - Further documentation: https://docs.brew.sh - Install the Homebrew dependencies if you have sudo access: Debian, Ubuntu, etc. sudo apt-get install build-essential Fedora, Red Hat, CentOS, etc. sudo yum groupinstall 'Development Tools' See https://docs.brew.sh/linux for more information. - Configure Homebrew in your /home/progrhyme/.zprofile by running echo 'eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv)' >> /home/progrhyme/.zprofile - Add Homebrew to your PATH eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv) - We recommend that you install GCC by running: brew install gcc
上のログ末尾のガイドに従い、 ~/.zshrc
に eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv)
を足した。
Homebrew BundleでHomebrewのパッケージ管理
https://github.com/Homebrew/homebrew-bundle
Homebrewのパッケージ管理ツールはいくつかあるっぽいが、公式のこれがLinuxにも対応していたので、これを使う。
brew bundle
を初回実行するとインストールされる。
Brewfileは環境に1つでいいので、 ~/.Brewfile
に作って、 brew bundle
コマンドを --global
オプション付きで実行することにした。
tfenvをbrew bundleでインストール
~/.Brewfile
に下の行を足す。
brew "tfenv"
brew bundle --global
を実行し、インストールできた。
むすびに
UbuntuにHomebrewをインストールし、Homebrew Bundleを使ってパッケージをインストールするまでの流れを記した。
Brewfileやdotfiles類は(今のところ)GitHubで公開しているが、今回の対応の差分はだいたいこちらのものになる。(※一部関係ない差分がある)
参考
技術メモを旧GoogleサイトからHugo + Docsyに移行している話
- TL;DR
- はじめに
- 移行先システムの選定
- Docsyについて
- 他に検討したツールとNG理由
- Hugoテーマ「LEARN」
- GitBook
- Docsyによるサイト構築
- Docsyのセットアップ
- hugoの拡張版をインストール
- デモサイトのソースを雛形としてクローン
- コンテンツ作成の準備
- 不要コンテンツの整理とコンフィグ調整
- 見た目の調整
- layoutsのカスタマイズとdocsのパス変更
- Docsyのセットアップ
- GitHub Actionsによるデプロイ自動化
- まとめ
TL;DR
できたサイトはこちら: https://progrhy.me/tech-notes/
コンテンツは2020-04-26現在、全く移行できていません。
はじめに
4年以上前から、雑なメモを公開しつつストックするサイトとして、Googleサイトを使ってきました。*1
技術メモサイトのURLは https://sites.google.com/site/progrhymetechwiki/ です。
GoogleサイトのWYSIWYGエディタは特に好きではありませんが、Markdown Hereというブラウザ拡張を使うとMarkdownで書けるので、問題ありませんでした*2。
Googleサイトの良い点として、ブラウザだけで作業ができるので環境構築が不要である点や、ビルド・公開といった手間が不要という点が挙げられます。
一方で、問題点がないわけではありません。
- 旧Googleサイトは来年末に終了が予定されている。
- 各ページをMarkdownファイルで管理しているわけではないので、他のMarkdownベースの文書管理システムに移行しづらい。
特に、前者がクリティカルです。
「新しいGoogleサイトに移行すればいいんじゃないの?」と思う人もいるかもしれませんが、変換ツールは上手く動かず、新GoogleサイトでMarkdown Hereを試したところ、上手く動きませんでした。
そこで、旧Googleサイトの終了がアナウンスされた頃から「移行しなければならない」と思っており、今回、ようやく実施に漕ぎつけました。
移行先システムの選定
移行前の技術メモサイトを見て頂ければわかると思いますが、結構ジャンルが多岐に渡っており、ページ数が多いです。*3
それも踏まえて、私が移行先システムに求める要求は以下の通り:
- 3以上のレベルでページを階層構造にできる
- ページツリーをサイドバーなどで俯瞰できる
- 記事の目次を表示できる
- 記事の全文検索が可能
- Markdownファイルで記事を管理できる
- Markdownで以下の拡張記法がサポートされている
- テーブル、シンタックスハイライト
- ページ数が多くなっても、待てる時間内でビルドが終わる
数年前だとなかなかいいツールが見つからなかったのですが、最近はだいぶ選択肢が増えているように思います。
HugoやJekyllなどの静的サイトジェネレーターなら、上の要求の大半は満たされます。
ただし、「3以上のレベルでページを階層構造」にして「ページツリーをサイドバーなどで俯瞰できる」ようなテーマは限られているかと思います。
Hugoは高速なので、ビルド時間に関してアドバンテージがあるでしょう。
結論としては、タイトルに書いたようにHugoのDocsyというテーマを使うことにしました。
Docsyについて
DocsyはGoogleが去年の7月頃に公開した(*4)HugoのThemeで、特定の製品に関する技術文書の作成に向いています。
Kubeflow, Knative, Apache Airflowなどのドキュメンテーションに使われています。
以下のような機能があって、だいぶリッチなツールです。
*1:雑なメモをいくつか Google サイトに移してみた - weblog of key_amb
*2:Googleサイト上の個人WikiでMarkdown Hereを使うことにした - weblog of key_amb
*3:2020-04-26時点で553ページありました。
*4:Google、技術文書を公開するようなWebに向けたテンプレート集「Docsy」を公開 | OSDN Magazine