GitHub OrganizationのプロフィールページにREADME.mdを設定する

最近知ったんですが、GitHubのOrganizationのプロフィールページにはREADME.mdを設定することができます。

例えばMicrosoftのOrganizationには、OpenSource Projectへの参加方法についてのリンクが主に記載されています。

github.com

公式ドキュメントは、ここになります。

https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile#adding-a-public-organization-profile-readme

.githubリポジトリprofile/README.mdを配置すると表示されるような仕組みでした。

Microsoftの場合だと、 https://github.com/microsoft/.github/blob/main/profile/README.md に対応するファイルがあります。
他のOrganizationに実際に適用してみたところ問題なく設定できたので、公式で対応してるものになりそうです。

GitHub,CircleCI-PublicやStudistでも同様の設定がされているようです。

github.com

github.com

github.com

設定する内容としては、OSSポリシーが適切そうですかね。

個人のプロフィールには設定できるのか?

個人のプロフィールページは、Organizationとは全く別のやり方です。
.githubリポジトリではなく自ユーザ名のリポジトリを作成して、ルートにREADME.mdを配置すれば良いようです。

zenn.dev

Organizationのプロフィールページを書く時に気をつけることある?

あんまりプラクティスのようなものは見つけられなかったんですが、しいて気をつけることがあるとすれば、README.mdに記載するリンクです。
例えば、.github リポジトリが以下のような構成であるとします。

.
├── images
│   └── logo.png
└── profile
    └── README.md

この時、READMEに画像を表示させるために![logo](../images/logo.png)といった書き方でリンクさせると、リポジトリやプレビューで見てる分には問題ないですが、
Organizationのプロフィールページでは表示されません。
表示させたい場合は、URLを指定して参照させます。

  • 誤 ... ![logo](.../images/logo.png)
  • 正 ... ![logo](https://github.com/corrupt952/.github/images/logo.png?raw=true)

.github-privateリポジトリというのもあるので、うまく使い分けられればポータルページのようにも使えるかもしれません。

Multi-stage buildsを使って環境別のコンテナイメージを作成する

n番煎じですが、Multi-stage buildsを使って環境別のコンテナイメージを作成する一例になります。
環境別にパッケージや挙動・設定が異なるのは望ましくないですが、
こういう書き方をする場合もあるということが誰かの参考になれば幸いです。

今回は、環境別にコンテナイメージを作成する場合のDockerfileとGitHub Actionsについて紹介します。

環境別のコンテナイメージを作成したい時とは

環境別のコンテナイメージを作成したいケースは、以下のようなケースがあります。

  • 環境別にインストールするパッケージやライブラリを変更する
  • 環境別に設定ファイルを変更する

KubernetesのConfigMapなどで外部から追加・差し替えができる場合は、イメージを環境別に作成する必要はありません。
ですが、差し替えするのが簡単ではない場合もあり、そういった場合は環境別にコンテナイメージを作成した方がメンテが楽な場合があります。 ※1

環境別にコンテナイメージを作成する

環境別にコンテナイメージを作成するために、今回達成したい要件をまとめます。

  • AlpineをベースにしてRedisを動かすイメージを作成する
  • 全てのIPv4,IPv6アドレスからの接続を許可する
  • ローカルの場合、BashVimを利用できるようにする
  • ローカルの場合、ログレベルをdebugにする
  • 本番の場合、ログレベルをwarningに変更する

これを踏まえたDockerfileは以下のようになります。

# 全ての環境で共通
FROM alpine:3.16 as base
RUN apk add --update --no-cache redis
RUN sed -i 's/bind 127.0.0.1 -::1/bind 0.0.0.0 ::/g' /etc/redis.conf
CMD ["redis-server"]

# ローカル
FROM base as dev
RUN apk add --update --no-cache bash vim
RUN sed -i 's/loglevel notice/loglevel debug/g' /etc/redis.conf

# ステージング
FROM base as staging

# 本番
FROM base as production
RUN sed -i 's/loglevel notice/loglevel warning/g' /etc/redis.conf

ローカルでdevステージを動かす

ローカルではdocker comoseを使って動かしたいので、compose.yamlを用意します。 ※2
ローカル向けでは、buildのオプションのtargetdevを指定することで、devステージのイメージが利用されます。

services:
  redis:
    build:
      target: dev
    ports:
     - 6379:6379

docker compose up を実行して起動することで動作確認ができます。
実際にBashなどが起動できるかは、docker compose exec -it redis bashで動作確認ができます。

今回はRedis用のイメージとして書いていますが、アプリケーションにも同様の仕組みが使えるので、 是非使ってみてください。

ステージングと本番向けのイメージをGitHub Actionsでビルドする

mainブランチが更新されたら、ステージング・本番向けにそれぞれイメージをビルドする仕組みを作ります。

こちらもローカル同様にtargetstagingか、productionを指定することで実現しています。

name: Build images

on:
  push:
    branches:
      - main

jobs:
  build_and_push:
    strategy:
      matrix: 
        stage: [staging, production]
    steps:
      - uses: actions/checkout@v3
      - docker/setup-qemu-action@v2
      - docker/setup-buildx-action@v2

      - name: Build and push
        uses: docker/build-push-action@v3
        with:
          context: .
          target: ${{ matrix.stage }}
          push: false

といった形で、各環境別にイメージを作成する方法について紹介しました。
実際に利用するケースはあまりないですが、どうしても利用したい場合などは、こういった書き方を検討してみてください。

※1 色々書いてますが、ローカルを含めた全ての環境で同一イメージを利用することが望ましいです

※2 動作確認の都合上、docker-composeではなくdocker composeを使っています

Hugoのextendedバージョンがaqua経由でダウンロードできるようになりました

suzuki-shunsukeさんにほんとど書いてもらったんですが、Hugoのextendedバージョンのバイナリがaquaでインストールできるようになりました。

github.com

github.com

Hugoのextendedバージョンは利用するテーマによっては必須と言ってもよいものです。
これを指定したバージョンを簡単にインストールできるようになったということは、
Hugoを使ってサイトを作っている身からすると非常にありがたいことです。

使っているサイト

Hugoを使って組んでいるサイトでコードを含めて公開可能なサイトは、zuki.devです。

zuki.dev

コードはGitHubで管理しています。

github.com

履歴は整理しましたが、元々はコンテナにHugoをインストールして管理していました。
チーム開発では基本的にコンテナでの開発・運用を勧めますが、
個人で利用するものでコンテナに押し込むメリットが少ないものは直接インストールした方が楽なケースがあります。

このリポジトリは特にその典型例でaquaでインストールできるようになり、非常に助かりました。

※ 履歴にはないですが、整理する時やCIで利用する場合などに非常に便利でした

Hugoのextendedバージョンについて

Hugoのextendedバージョンは、バージョンによって名称変更やサポートされるプラットフォームがそこそこ変更されています。

私が調べたわけではないですが、以下のコメントが非常によくまとまっており、
私自身、そこまで面倒だったのかと改めて知るきっかけになりました。

github.com

一部を抜粋しますが、

  • Since v0.103.0, replacements was changed.
  • Since v0.102.0, macOS archives have replaced with universal binaries. And linux/arm64 has been supported
  • In v0.88.0, macOS/arm64 was missing
  • Since v0.81.0, macOS/arm64 has been supported
  • extended has been supported since v0.43

といったような状態だったよううです。

それをうまくregistry.yamlに落とし込んでもらって感謝しています。

通常のHugoもaqua経由でインストールできるので、これからHugoを触ってみたい方はaquaを使ってHugoをインストールしてみたらどうでしょうか。

RTX1300にVPNに接続する

今回は、RTX1300のセットアップの続きでVPNを接続した時のメモになります。

大まかな流れ

大まかな流れですが、

  1. Web GUIのかんたん設定でVPNの接続設定を行う
  2. 足りない設定を手動で入力して補完する

といった流れになります。

弊宅ではV6プラス固定IPで外部へ接続しているため、人によっては1のみでうまく動作するケースがあるかもしれません。

Web GUIのかんたん設定でVPNの接続設定を行う

YAMAHAの公式サイトを参考にしながら、VPNの接続設定を行います。
リンク先はRTX1210ですが、ほぼ変わらないので問題ないかと思います。

network.yamaha.com

この設定だけだと、外部(モバイル回線)から接続することができなかったので、
この時点の設定ファイルを見ながら差分を補完していきます。

足りない設定を手動で入力して補完する

192.168.100.1 はデフォルトの値なので、自身の設定に応じて変更してください

私の環境では、静的IPマスカレードや Filter関連の設定がないようだったので追加で設定しました。
設定項目のほとんどはWeb GUIからも設定できるので、読み替えて設定してください。

telnetなどで接続し、administratorに切り替える

$ telnet 192.168.100.1
Username: abcdef
Password:

> administrator
#

設定を手動で入力する

静的IPマスカレードや Filter関連の設定をします。

  • nat descriptorの20000は、その環境で既にあるIDに置き換えて入力
  • 110xなどのIDは自分が管理しやすいIDに変更
  • 192.168.100.1 は自分の環境に合わせて変更
# nat descriptor address inner 20000 auto
# nat descriptor masquerade static 20000 1 192.168.100.1 esp
# nat descriptor masquerade static 20000 2 192.168.100.1 udp 500
# nat descriptor masquerade static 20000 3 192.168.100.1 udp 4500

# ip filter 1101 pass * 192.168.100.1 esp * *
# ip filter 1102 pass * 192.168.100.1 udp * 500
# ip filter 1103 pass * 192.168.100.1 udp * 4500
# ip filter 1104 pass * 192.168.100.1 udp * 1701

# tunnel select 1
tunnel1# ip tunnel secure filter in ... 1101 1102 1103 1104

これで数分待ってから無事に接続できるようになりました。

RTX1300のメトリクスをPrometheus+Grafanaで可視化する

V6プラス固定IPに変更したタイミングでRTX1300を自宅に導入しました。

簡単にいくつかのメトリクスをPrometheus+Grafanaで可視化しました。
大まかな手順とサンプルコードについては、砂場レポに放り込んであるのでこちらを参考にしてください。

github.com

手順にそって作業すれば、おおよそこういう見た目になります。

中々いい感じですね。

手順については触れませんが、作業をした時のいくつかのポイントについて書いておきます。

大まかな構成と注意点

今回は、SNMP Exporterを使ってSNMPでRTX1300のメトリクスを収集し、Grafanaで可視化するような構成にしています。

サンプルコードでは、気軽に実行できるようにdocker-copmoseにしています。

また、執筆時点(23.00.04)で取得できない項目がいくつかあったので、先にそれらの項目について書いておきます。

  • yrfRevision # reivsion
  • yrhInboxTemperature # 温度

これらの値は、SNMPで取得することは現時点だとできませんでした。

メトリクスを収集する間隔

サンプルコードでは、5秒間隔でメトリクスを収集しています。

- job_name: 'snmp.rtx1300'
  scrape_interval: 5s
  static_configs:
    - targets:
        - 192.168.100.1 # Change to IP address of RTX1300
      labels:
        name: RTX1300
        vendor: yamaha

収集しているメトリクスの1つにyrhMultiCpuUtil5secというメトリクスがあるので5秒間隔にしています。
この間隔でもCPU使用率は、特定の1コアのみ1%程度上昇するだけなので負荷は全然ないと思って良さそうです。

snmp.ymlを生成する

SNMP Exporterで利用するsnmp.ymlを生成する必要がありますが、生成する環境を作るのが面倒だったので簡単なスクリプトを作っておきました。

generator.ymlで収集したいメトリクスを変更したりした後に./generate-snmp-config.sh を実行するだけで
snmp.ymlsnmp-exporterディレクトリ下に生成されます。

内容としては、snmp_exporterのgeneratorでbuildするための環境をDockerileで定義しているぐらいです。

自宅の回線をV6プラス固定IPに変更した

表題の通り、自宅の回線をDMM光のV6プラスから、enひかりのV6プラス固定IPに変更しました。

auひかりや光クロスみたいに爆速というまではいかないものの、22:40頃でこのぐらいの速度が安定して出せているので十分。
固定IPなのでV6プラスで問題になる利用可能なポート数の制限もなく、今のところ非常に快適です。
スプラトゥーン3を含むP2P方式のオンラインゲームでも通信エラーは一切出ていないようですし、問題なさそうです。

enひかりにした強い理由は一切ないですが、V6プラス固定IPに対応しているプロパイダがほぼないというのが理由と言えば理由ですね。

注意事項

V6プラス固定IPは、対応している家庭用ルータが少ないため、対応しているかどうかは念入りに調べておいた方が良いです。
V6プラスには対応していても、V6プラス固定IPには対応していないルータの方が大部分です。

業務用ルータであれば、RTX830などのYAMAHルータなどでも対応しているので、そちらを探してみてもいいかもしれません。
弊宅は引っ越す云々の話もあり、今はRTX1300を使っています。

なぜ変更したのか

DMM光のV6プラスを契約していましたが、以前書いた記事にもあるようにオンライン通信(大体P2P通信方式)の場合に特定のユーザとプレイすることができないといった問題がありました。

khasegawa.hatenablog.com

必要な時にWireGuardを利用することで凌いでいたものの、妻がスプラトゥーン3をプレイしていて5回に1回ほど通信エラーが出るという話もあったので、
良い機会だと思い自宅の回線をV6プラス固定IPに変更しました。

今のところ通信エラーは一切出ていないという話でしたし、WireGuardをたてなくても特定の友人ともプレイできるようになってホクホクです。

auひかりなどの個別に回線をひかなかった理由ですが、宅内に引き込むことの工事を含めて許可は出ていたのですが、
集合住宅のMDFがある部屋がテナントとして貸し出されており、業務用冷蔵庫などを撤去しないと作業できないという状況で物理的に工事不可という状況だったので今回は諦めました。
次引っ越すのであれば戸建てがいいと思っていますが、あまり現実的ではなさそう。

切り替えるための大まかな流れ

実際の流れとしては以下のようになります。

  1. DMM光に問い合わせて「事業者変更承諾番号」を控える
  2. enひかりの申込みフォームで「事業者変更申込み」を選択し、「事業者変更承諾番号」を入力して申し込む
  3. 切り替えが完了するまでのPPPoEで耐えしのぐ
  4. enひかりから切り替え予定日や設定情報が入っている書類が届く
  5. 切り替え予定日の正午前後にV6プラス固定IPの設定を行って疎通確認をする

DMM光に問い合わせて「事業者変更承諾番号」を控える

公式ページにあるように電話すれば、すぐに発行してくれます。

hikari.dmm.com

また変更先がV6プラスなどの場合だと問題が起きやすいため、その電話をもってPPPoE回線に切り替わるので注意してください。

enひかりの申込みフォームで「事業者変更申込」を選択し、「事業者変更承諾番号」を入力して申し込む

enひかりの公式ページから、事業者変更申込を選んで必要な項目を入力して申し込みます。

enhikari.jp

今回は、V6プラス固定IPにしたかったので「固定IP」と「enひかりV6プラス」両方にチェックを入れておきます。

切り替えが完了するまでのPPPoEで耐えしのぐ

切り替わるまではPPPoEでの接続となるので、夜帯は非常に遅くなります。
PINGが20~150msかつ、下り速度が10~20Mbpsしか出ないと考えてください。

気休めですが、PPPoEガチャという手法があるのでその期間だけ遅いとおもったら、ガチャしてみるのもアリです。

enひかりから切り替え予定日や設定情報が入っている書類が届く

enひかりから、V6プラス固定IPの設定に必要な情報や契約書などの書類が届きます。
工事予定日なども記載されているので、認識齟齬がないか確認しておきます。

切り替え予定日の正午前後にV6プラス固定IPの設定を行って疎通確認をする

大体正午から接続できるようになっているはずなので、そのあたりからV6プラス固定IPの設定に変更して疎通確認をします。
何も問題なければ、遅くともその日のうちには接続できるはずです。

接続できない

YAMAHAのルータを使っている前提として書いているので、その他のルータは適時読みかえてください。

Failed to notify IPv6 address to the update server.

2回リトライされますが、3回とも失敗した場合は、そもそも自分の認証情報が登録されてないなどの理由や、enひかりの信号がJPNEに届いてないといった理由がありそうです。

[v6plus] Failed to notify IPv6 address to the update server. (remaining retry: 2 time(s))
[v6plus] Failed to notify IPv6 address to the update server. (remaining retry: 1 time(s))
[v6plus] Failed to notify IPv6 address to the update server.

Failed to update IPv6 address. (code=400, body=NG)

どういう状態かは分かりませんが、工事予定日の09:00~11:00ぐらいの間でチェックしていた時にこういうエラーが出ていました。
正午を過ぎれば問題ないかとは思いますが、確実とはいえません。

[v6plus] Failed to notify IPv6 address to the update server. (remaining retry: 2 time(s))
[v6plus] Notified IPv6 address to the update server.
[v6plus] Failed to update IPv6 address. (code=400, body=NG)

GitHub Actionsで特定のコマンドをリトライするだけのAction

仕事でも利用している個人で作った特定のコマンドをリトライするだけのGitHub Actionを公開しました。
似たようなActionは既にMarketplaceにあるのですが、大体がそのコマンドの出力結果を取得できないため、自前でActionを書くにいたりました。

github.com

github.com

使い方としてはシンプルでして例えばterraform planであれば、

- uses: corrupt952/retry-command@v1
  with:
    command: terraform plan -no-color
    max_attempts: 3
    retry_interval: 10

のようにすれば、リトライ間隔10秒で最大で3回実行してくれます。(リトライは2回)

実態はまだシェルスクリプトということもあり、$((RANDOM % 31)) とように書くだけで指定の範囲内でランダムにスリープしてくれます。

- uses: corrupt952/retry-command@v1
  with:
    command: terraform plan -no-color
    retry_interval: $((RANDOM % 31))

そして元々個人的に必要だったのはコマンドの実行結果で以下のように取得することができます。

- uses: corrupt952/retry-command@v1
  id: terraform_plan
  continue-on-error: true
  with:
    command: terraform plan -no-color
    max_attempts: 3
- if: steps.terraform_plan.outcome == 'failure'
  run: |
    echo "Exit code: ${{ steps.terraform_plan.outputs.exit_code }}"
    echo "Result: ${{ steps.terraform_plan.outputs.result }}

取得できるのは、現状最後に成功・失敗した時の結果になります。 もし似たようなことをしたい時は使ってみてください。