はてなブックマーク

これまで Macbook Pro を開発環境としていたんだけど、価格は高いし Docker for Mac は重いしでいいことないなということで Linux の開発環境に移ることにした。前職の最初の数年はすべて VM（当初は jail）にログインして開発していたのでその頃に戻った感じ。ただ GUI は macOS が何かと楽なので Intel NUC を購入して自宅に置いてリモートでログインして使っている。Core i7、メモリ 64GB で10万ちょいと安いのにめちゃくちゃ快適でさいこう。 ここからは備忘録としてリモートを開発環境とするうえで実施した作業を残す。あと作ったものもあるので宣伝。 外部からログインしたい自宅以外からも使うだろうということで（最近京都からリモートで働くこともあり）、VPN サービスとして Tailscale を導入した。 Best VPN Service for

ブログエントリの OGP 画像は、これまでエントリ中に画像を使っていればそれを指定して、特に指定できる画像がなければアバタの画像を出すようにしていたのだけど、アバダは何も表せてないので何かいいものはないかなあと思っていた。 第一候補は @ladicle の tcardgen でこのツールを使うと次の感じでエントリのタイトルやタグを入れて OGP 画像を生成できる。 これもすっごいよいのだけど、なんか他にないかなあと思っていたところ、エントリのスクリーンショットがそのまま出ていればどんなページなのか分かってよい感じなのでは？と思い、やってみた。結果としては次のような感じで個人的には気に入っている。 ブログエントリの ogp イメージにスクショを設定するようにしてみた。スクショは pageres-cli で生成してる。どうだろうか。 https://t.co/rOe8awTNow — すぱぶら

tmuxずっと tmux に移行しようかなという気持ちを持っていたので、重い腰を上げて移行してみた。プレフィックスを C-j にすれば大体 GNU screen と同じ感じで使えることがわかったので、すんなり使えている。ただ画面の分割が GNU screen では新しい window が作られるところ、tmux では pane が作れられるのでそこに少し戸惑った。 https://github.com/superbrothers/dotfiles/blob/master/tmux.conftmux プラグインでは tmux-thumbs が気に入っていて、vimperator 的な感じで画面内のそれっぽい文字列をハイライトしてくれて、ハイライトに出ているヒントのキーを押すとバッファにコピーしてくれる。コピーコードやトラックパッドを使うよりも高速に操作できるのでさいこう。 https://g

Pod に複数のコンテナが含まれる場合に、kubectl logs コマンドを実行すると次のように1つのコンテナを選択するようにとエラーになります。 $ kubectl logs nginx error: a container name must be specified for pod nginx, choose one of: [app sidecar] kubectl logs コマンドで対象のコンテナを指定するには --container (-c) フラグを使用します。 $ kubectl logs nginx --container app しかしながら、メインのコンテナとサイドカーコンテナという構成の場合、おそらく多くの場合で確認したいログは、メインのコンテナのものです。これをいちいち毎回指定しないといけないというのも面倒です。 Kubernetes 1.18 の kubec

2021/04/15: GitHub Actions のワークフローで GITHUB_TOKEN を使って ghcr.io で認証できるようになりました。個々のコンテナイメージ毎に特定のリポジトリのワークフローで READ/WRITE のどちらを許可するのか選択できます。詳しくは Packages: Container registry now supports GITHUB_TOKEN - GitHub Changelog を参照ください。 はじめにDocker Hub の Rate Limit の件もあり、新しくイメージをホストするコンテナレジストリとして GitHub Container Registry（GHCR）を使ってみようとしましたが、ロボットアカウントから使用するのにいくつかハマりポイントがあったので残します。 なぜロボットアカウントを使うのかロボットアカウントとは、ここで

asdf がそれっぽいツールですね。私はこれで kubectl を管理してます。 — すぱぶら (Kazuki Suda) (@superbrothers) May 13, 2020kubectl などの CLI ツールを複数のバージョンを切り替えながら使いたいことがあります。例えば本番のクラスタのバージョンは 1.16 だけど検証で 1.18 のクラスタを使うといったケースです。毎回どこからインストールするのかドキュメントを探したり、コマンドのヒストリを検索してみたり、kubectl118 のような別名で管理したりと何かと面倒です。 asdf-vm は、Node.js や Ruby、Python、Go といった言語で複数のバージョンを管理できる anyenv に似たツールで、言語に留まらず kubectl や istioctl といった CLI ツールもいい感じにインストールからバージョ

はじめにPID 1 問題というのは、コンテナを実行した際にアプリケーションのプロセスが PID 1（プロセス番号が1番）で実行されることで、コンテナに対して SIGTERM などのシグナルを送信してもコンテナ内のプロセスが正常に終了しないというものです。ここでは2020年3月現在でこの PID 1 問題を回避する方法を Docker と Kubernetes のそれぞれで紹介します。 TL;DRアプリケーションが「明示的にシグナルをハンドリングするようにする」、または「PID 1 で実行されないようにする」の2つの回避策があるアプリケーションプロセスが PID 1 で実行されないようにする場合、Docker では Tini のような軽量 init を使う、もしくは Docker 1.13 以上の場合は docker run の --init オプションを使うで問題を回避できるKuberne

対象のフィールドの値を null としてパッチすることでフィールドそのものを削除できます。 kustomize version {Version:3.5.4 GitCommit:3af514fa9f85430f0c1557c4a0291e62112ab026 BuildDate:2020-01-17T14:23:25+00:00 GoOs:darwin GoArch:amd64} 例えば次のような Pod マニフェストがあるとします。 apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: k8s.gcr.io/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: LOG_LEVEL

TL;DRKubernetes API は、Categories と呼ばれるリソースが紐づくエイリアスグループがあるall は、デフォルトで定義された1つのエイリアスグループであるCustomResourceDefinition では、spec.names.categories []string でカスタムリソースに任意のカテゴリを設定できるつまり好きなカテゴリを好きに作れるし、任意のカスタムリソースを all カテゴリに追加することもできるはじめに前回のエントリでは、kubectl get all は全リソースの情報を表示しないことと、真に全リソースの情報を表示するワンライナの紹介と kubectl プラグインを使って便利に使う方法を紹介しました。 ここでは、その続きとして kubectl get コマンドの all の対象となるリソースリストがどこからやってくるのかを解説します。この情

TL;DRkubectl get all は、v1.14.3 時点で次のリソースの情報のみを表示し、全リソースが対象ではないpods.v1replicationcontrollers.v1services.v1cronjobs.batchdaemonsets.appsdeployments.appshorizontalpodautoscalers.autoscalingjobs.batchreplicasets.appsstatefulsets.apps本当に全リソースの情報を表示するには、次のワンライナが利用できるkubectl get "$(kubectl api-resources --namespaced=true --verbs=list -o name | tr "\n" "," | sed -e 's/,$//')" ワンライナを kubectl プラグインとしておくと便利は