C# 初心者が Casio のキーボードと BLE 接続するために C# を使った話
アドベントカレンダー初めて使います。 11日目です。皆さんが素晴らしい内容しか書いていないので、私はネタ要員として投稿させてもらいます。箸休め程度にご覧ください。
C# を使うことは久しくなかったのですが、久々に C# を使ってプログラムを書いてみようと思い立ち、 Casio キーボードと Windows PC が接続するためのツールを書きました。このプログラムを書いたのはもう数か月前なのですが、せっかくなら記事にしてみようと思い立ち、記事を書きました。良かったら見ていってください。ちなみにコードを整理していないので全体のコードの公開は年末ごろになる予定です。（望んでいる人がいるとはおもいませんが）
はじめに
先日、 CASIO のキーボード CDP-S300 を購入しました。
CDP-S300 には、同梱で WU-BT10 と呼ばれる Bluetooth 接続用のデバイスが付属しています。この BLE デバイスに Windows 標準機能で接続しようとすると以下のように接続できません。
また、Casio の公式は、このデバイスを Windows PC に接続するためのアプリケーションを用意していません。 Microsot App Store には、それっぽいアプリケーションが販売されていますが、これで接続できなかった時の悲しさは考えるに堪えません。。。
そこで、ないなら自分で作ってしまおう！ということで、久々に C# を触るのもいいなと思いたち、 C# でプログラムを書きました。 ただ、いちから、 BLE 接続するプログラムを書くのは骨が折れます。そんなとき、以下のリポジトリを見つけました。
このプログラムは、 Winrt の Bluetooth デバイスの接続処理を DLL にラップしてくれています。また、ライセンスは WTFPL です。つまりは自由に使えます。
※ すでにお気づきの方がいるかもしれませんが、後になってから、 Winrt API で BLE の API があることを知り、 C# からより簡単に扱えることを知りましたが、今回は、いったん、上記の BleWinrtDll を利用して実装しました。（Microsoft のページにはサンプルコードのリンクまで載っていて、とても素晴らしいですね！）
本編
さて、作ろうと思ったものの、 BLE の処理も知らない、 BLE-MIDI の規格も知らない状態で作業を始めることになりました。こんな時、皆さんはどうしているのでしょう？最近だと、AI に聞くのが早いですよね。私も多分に漏れず、まずは AI に聞きました。そこで、どうやら BleWinrtDll というものがあるらしいということがわかり、このプログラムをベースに WU-BT10 と Windows マシンとの接続用のコードを書き始めました。
BLE との接続については、 BleWinrtDll にも付属していたサンプルコードをもとに実装を始めました。そう。 BleWinrtDll の作者が C# から BleWinrtDll.dll の関数を呼べるようにするための Marshal まわりの処理を全部書いてくれていたのです。C# からの Native コードの呼び出しについて、自分の知識の再確認のためにもここで一度おさらいをしておきます。（詳しい方は間違いがあれば、ツッコミ入れていただけると嬉しいです。）
C# からの Native コードの呼び出し
.NET アプリケーション（例えば C#） から Native のアプリケーションの関数を呼び出したいことはそれなりにあると思います。この時に、覚えておかないといけない概念がマーシャリングです。
.NET 9 とか 10 とかのキラキラした新しい機能だとどう書くのかは知りませんが、 例えば以下のコードがマーシャリングしているコードです。（BleWinrtDll のコードから一部抜粋）
public class BLE
{
// dll calls
class Impl
{
public enum ScanStatus { PROCESSING, AVAILABLE, FINISHED };
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct DeviceUpdate
{
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 100)]
public string id;
[MarshalAs(UnmanagedType.I1)]
public bool isConnectable;
[MarshalAs(UnmanagedType.I1)]
public bool isConnectableUpdated;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 50)]
public string name;
[MarshalAs(UnmanagedType.I1)]
public bool nameUpdated;
}
[DllImport("BleWinrtDll.dll", EntryPoint = "StartDeviceScan")]
public static extern void StartDeviceScan();
[DllImport("BleWinrtDll.dll", EntryPoint = "PollDevice")]
public static extern ScanStatus PollDevice(out DeviceUpdate device, bool block);
[DllImport("BleWinrtDll.dll", EntryPoint = "StopDeviceScan")]
public static extern void StopDeviceScan();
ここでは、 Native の BleWinrtDll.dll がエクスポートしている関数の呼び出しを定義しています。 例えば、 PollDevice の例だと、引数が DeviceUpdate と bool の ScanStatus という列挙型を返す関数です。ここで見るべきは、例えば、以下の構造体の定義です。
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct DeviceUpdate
{
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 100)]
public string id;
[MarshalAs(UnmanagedType.I1)]
public bool isConnectable;
[MarshalAs(UnmanagedType.I1)]
public bool isConnectableUpdated;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 50)]
public string name;
[MarshalAs(UnmanagedType.I1)]
public bool nameUpdated;
}
この構造体の定義は、 Native 側の実装では、以下のように定義されています。
struct DeviceUpdate { wchar_t id[100]; bool isConnectable = false; bool isConnectableUpdated = false; wchar_t name[50]; bool nameUpdated = false; };
C# では、 wchar_t id[100] の文字列データを表すために CharSet.Unicode で Unicode であることや ByValTStr で固定長の文字列であることなどを指定してあげる必要があるわけです。これらの機能は、 C# から Win32 API を呼びたいときも使用します。よく覚えておきましょう。
デバイスのスキャンと取得
BleWinrtDll では、サンプルコードに BLE デバイスのスキャンおよびデバイスとの接続処理の実装例が書かれていました。これは、流用するほかありませんね。 BleWinrtDll をラップした ScanDevices 関数を流用することで、 WU-BT10 MIDI のデバイスを見つけ出すことができます。この時、 BleWinrtDll のコードを流用したのですが、以下の C# の記法が興味深かったです。
public class BLEScan
{
public delegate void FoundDel(string deviceId, string deviceName);
public delegate void FinishedDel();
public FoundDel Found;
public FinishedDel Finished;
internal bool cancelled = false;
public void Cancel()
{
cancelled = true;
Impl.StopDeviceScan();
}
}
BLE.BLEScan scan = BLE.ScanDevices();
scan.Found = (_deviceId, deviceName) =>
{
Console.WriteLine("found device with name: " + deviceName + ", " + _deviceId);
if (deviceId == null && deviceName == "WU-BT10 MIDI")
deviceId = _deviceId;
};
scan.Finished = () =>
{
Console.WriteLine("scan finished");
if (deviceId == null)
deviceId = "-1";
};
アセンブリを直接書き込んで実行するときにデリゲートを設定して実行するテクニックは知っていたのですが、こうやって、ラムダ式のようなものを関数ポインタに書き込むことで呼び出すようにするような記述ができるんですね。というか、これがデリゲートの本来の使い方なんですかね？一つ勉強になりました。
BLE デバイスの接続
さて、 BLE デバイスとの接続を行う場合、 Service UUID と Characteristic UUID の値が必要になります。これらの値は、 Bluetooth の仕様により定められており、指定した値で接続することで接続したデバイスの情報を取得したり書き込んだりすることができます。
例えば、今回は BLE-MIDI の接続を行いたいので、 Service UUID を {03B80E5A-EDE8-4B33-A751-6CE34EC4C700} 、 Charasterristic UUID を {7772E5DB-3868-4112-A1A9-F2669D106BF3} で指定して接続することになります。これらの UUID は、上記の Bluetooth の仕様に定められた値ではなく、 Apple が定めた BLE-MIDI の仕様 に基づいて定められた値です。この Apple が定めた仕様が、 BLE から送られてくるデータのパースにも必要になってきます。
BLE デバイスとの接続時は、このようにデバイスが用意しているサービスなどを特定して、接続する必要があります。 WU-BT10 はその点行儀のよいデバイスのようで、上記の UUID で接続することができました。
今見ると、 {5052494d-2dab-0341-6972-6f6861424c45} というサービスも提供しているようですね。こちらも調べてみると面白そうです。
BLE データの取得とデータのパース
ここまでくれば、あとは、 BLE-MIDI のデータのパーサーを書けばよいだけです。賞味ここが一番面倒でした。実際のところ、すべてを実装できたと思っていませんが、以下のように実装しました。
詳細な説明を書くのは面倒くさいので、いくつか C# の機能で気に入ったところを挙げるなら、以下でした。
書いていて面倒くさかったのは、実際の Apple が出している仕様とは少し異なるデータ形式で返ってきているように見えるデータがあることでした。 BLE-MIDI 完全に理解した。
仕上げ（アプリケーションから MIDI 出力する）
これで、 BLE-MIDI でデータを取得することはできました。ただ、 Windows でこの MIDI データを再生するには、このプログラムから仮想 MIDI ポートに接続する必要があります。そこで、 NAudio パッケージを利用して、仮想 MIDI ポートへの接続処理を書きました。
MIDI 周りに詳しい人はわかるかもしれませんが、もちろん、 それだけでは Windows で音を再生するようなことはできません。 loopMIDI をインストールし、この loopMIDI に 仮想 MIDI ポートを作成し、その仮想 MIDI ポートに接続します。
BleMidiContext context = new BleMidiContext();
try
{
while (running)
{
var data = BLE.ReadPackage();
if (data != null && data.Length > 3)
{
ushort timestamp = (ushort)(((data[0] & 0x3F) << 7) | (data[1] & 0x7F));
foreach (var evt in BleMidiDecoder.Decode(data, context))
{
midiOut.SendBuffer(evt.Data);
}
}
Console.WriteLine(BLE.GetError());
}
}
finally
{
ble.Close();
midiOut?.Dispose();
}
以上のようなコードで仮想 MIDI ポート（midiOut）にデータを送ることで MIDI 仮想ポートにデータを送り込むことができました。
あとは、 Splice INSTRUMENT や Domino などと接続して遊ぶだけです！ここまで記事を粘り強く読んでくださりありがとうございます。
オチ
やったね！ピアノとPCを優先ケーブルでつなげなくても Windows で音が鳴るね！と思ったんですが、 BLE-MIDI の遅延 0.1 秒ほどと明らかに遅延がありすぎて Windows で鳴らした音をベースにはまともに演奏できないというありさまで、使い物になりませんでしたとさ。 おそらくだけど、譜面起こしで Domino と連携させて使うくらいだったらできるかもしれません。
あれ？これって本当に C# の記事だったのか？読者諸賢の皆様のことですので、このような自己満記事でもお許しいただけると信じて末筆とさせていただきます。
RKE2 + Windows ノードで Calico の blockSize を変更して Pod を 61 個以上動かす方法
みなさん。 k8s 使ってますか？
わたしは CKA の勉強をすると決めて 6か月くらい経ちました。
はやく受験しろって感じですけど、ちょっと実験したことがあったので記事にします。
ちなみにこの記事を読んでも CKA には何の関係もありません。
RKE2 の Windows ワーカーノードでは、Calico のデフォルト設定だと /26（64 IP） が割り当てられます。
ただし Windows ノードでは各ブロックで 4 IP が予約されるため、実際に使えるのは 60 IP しかありません。
そのため、Pod を 61 個以上動かそうとすると IP が枯渇してしまいます。
この記事では、blockSize を拡張して 61 個以上の Pod を収容できるようにした手順を備忘録として残します。
Windows Server を購入できるほどのお金はないので、今回の検証では評価版の Windows Server を利用しました。
RKE2 では、2025年9月現在 Windows Server 2022 までをサポートしているようです。
さて、以下から記事本文です。
検証環境
- RKE2
- Calico (VXLAN)
- Windows Server 2022 評価版（ワーカーノード）
Ubuntu Desktop を Rancher 実行環境として、 master ノードに Ubuntu Server 、 worker ノードに Windows Server 2022 という構成です。 検証には、 VMware Workstation Pro を利用しました。 VMware Workstation Pro が無償になってくれてありがたいですね。
ポイント
- /25 にすると 128 - 4 = 124 IP
- /24 にすると 256 - 4 = 252 IP
- HelmChartConfig (rke2-calico) を編集するのが正規の方法
手順
以下の手順で対応できます。
- HelmChartConfig を編集する
- 既存ブロックの対応
以下は詳細な手順です。
HelmChartConfig を編集する
以下の HelmChartConfig は、作成したクラスタの More Resources の Helm にあります。
この設定を以下の設定に変更します。
spec:
failurePolicy: reinstall
valuesContent: |-
global:
cattle:
clusterId: c-m-2xbcc2vw
installation:
calicoNetwork:
ipPools:
- cidr: 10.42.0.0/16
encapsulation: VXLAN
natOutgoing: Enabled
nodeSelector: all()
blockSize: 25 # ★ここを25や24に設定
RKE2 では Calico が Helm チャートとして組み込まれており、
HelmChartConfig (rke2-calico) に設定を書けば、デフォルト値を上書きできます。
つまり「自分で設定を書かない限り、勝手に変な変更が起きることはない」ので安心して使えます。
以下は、今回設定した項目に関する詳細です。
| キー | RKE2 デフォルト値 | 今回の変更 |
|---|---|---|
calicoNetwork.ipPools[0].cidr |
10.42.0.0/16 |
変更なし |
calicoNetwork.ipPools[0].encapsulation |
VXLAN |
変更なし |
calicoNetwork.ipPools[0].natOutgoing |
Enabled |
変更なし |
calicoNetwork.ipPools[0].blockSize |
/26（=64 IP, Windows では実効 60 IP） |
/24 に拡張（=252 IP 利用可能） |
詳細を知りたい方は、Calico Installation API リファレンス や RKE2 Networking (公式ドキュメント) をご参照ください。
既存ブロックの対応
公式が推奨している方法がありますが、今回は新規でクラスタを作成したので、以下に示す方法2 で対応することにしました。
- 方法1: 一時的に別の IPPool を作って Pod を移行し、旧 Pool を削除する（Calico 公式推奨）。
方法2: 今回は簡易的に以下で対応。
結果
- /24 に変更したことで、1ノードあたり実効 252 IP が利用可能に。
- Pod を 61 個以上起動しても IP 枯渇せずに動作。
まとめ
- RKE2 の Windows ノードはデフォルトだと 60 Pod で IP が尽きる。
- HelmChartConfig (
rke2-calico) でblockSizeを拡張することで解決できる。
ChatGPTを使ってアメリカ経済が大暴落する可能性についてレポートを作成してみた
ChatGPT に現在の経済動向について調べてもらって、その結果をレポートという形でまとめてもらいました。
投資を始めるなら大暴落した後のほうがいいよね！ってことで、大暴落の可能性についてというテーマで調べてみてもらいました。私個人としては、来年の初めくらいまではアメリカ経済は持ちこたえるんじゃないかなと思っていますが、実際のところどうなるんでしょうねぇ。（消費者信用残高は、-156.28億USDとなっていて過去最低だったり、非農業部門雇用者数が多くなっているのにも関わらず平均時給は伸びていなかったり、不安な点はいろいろありますけども）
以下は、 ChatGPT が生成した記事です。なんかそれっぽくないですか？う～ん、結構リスク高めと評価してますね。今は円安が続いていますが、強いアメリカ経済が終わって円高に向かってほしいものです。（希望）
米国経済の大暴落の可能性を検討するため、過去の市場動向と現在の市場状況を比較し、各リスク要因にスコアを割り当て、全体的なリスクスコアを計算しました。以下は、リスクスコアの計算と大暴落の可能性の再評価に基づくレポートの要約です。
米国経済の大暴落の可能性の再評価
1. 米国不動産市場:
- 過去の市場: 2008年の金融危機では、不動産市場の崩壊が経済の大暴落を引き起こしました。
- 現在の市場: 利息率の上昇と消費者信用残高の減少が不動産市場に悪影響を与えています。
- リスクスコア: 8/10
2. 供給チェーンの問題:
- 過去の市場: 過去の市場動向と比較して、現在の供給チェーンの問題は新しいものであり、これが経済にどのような影響を与えるかは未だ明確ではありません。
- 現在の市場: 半導体不足や他の物資の不足が生産と配送に影響を与えています。
- リスクスコア: 8/10
3. グローバルな経済状況:
- 過去の市場: 過去の経済危機はしばしばグローバルな影響を持っていました。
- 現在の市場: 世界経済の減速と中国の経済的ストレスが米国経済に影響を与える可能性があります。
- リスクスコア: 7/10
4. 中国の経済動向:
- 過去の市場: 中国の経済は、過去数十年間で急速に成長し、グローバルな経済の重要なプレイヤーになっています。
- 現在の市場: 中国の経済減速と不動産市場の問題が、世界経済に影響を与える可能性があります。
- リスクスコア: 7/10
5. 他のグローバルな経済動向:
- 過去の市場: 過去の市場動向は、技術革新や環境変化が経済に影響を与える可能性を示しています。
- 現在の市場: 環境変化、技術革新、金融市場の規制が経済に影響を与える可能性があります。
- リスクスコア: 6/10
総評:
過去の市場動向と現在の市場状況を比較すると、米国経済の大暴落のリスクは高まっている可能性があります。特に、不動産市場と供給チェーンの問題は、経済のリスクを高める主要な要因となっています。しかし、これらのリスクは、連邦準備制度理事会（Fed）の政策、政府の介入、およびグローバルな経済協力によって緩和される可能性があります。米国経済の大暴落のリスクを完全に理解するには、これらの要因がどのように相互に影響し合っているかをさらに分析することが重要です。
このレポートは、過去の市場動向と現在の市場状況を比較し、米国経済の大暴落の可能性を再評価する基盤を提供しています。さらなる分析とモニタリングが、今後の経済動向とリスク評価にとって重要です。
by ChatGPT
パスワードのわからないラズパイをハックしよう！ ～ラズパイで運用しているUbuntu20.04のパスワードを忘れたとき～
この記事は、ラズパイで運用しているUbuntu20.04のパスワードを忘れてしまった時のための備忘録です。
やったこと
- Win32 Disk Imager を使ってラズパイのデータをバックアップ
- Error 5 のときは、開きっぱなしのファイルがないか確認して閉じよう
- Error 32 のときは、一度SDカードを取り外して再接続しよう
- kpartx と mount を使ってラズパイのイメージをマウント
- (メモ) file コマンドでバックアップされたファイルを見ると圧縮されていなかったので、zcatコマンドは不要だった
- /etc/shadow のパスワードを書き換えて、SDカードに書き込み
試してダメだったこと
rw init=/bin/shを cmdline.txt に追記して起動- splashがないというエラーメッセージが表示されてしまう
参考文献
最後に
わかりづらいと思うので時間があるときに整理したい
ブレードランナー2049を観てみた
アマゾンプライムでブレードランナー 2049が見れるようになっていました。 タイトルだけは聞いたことがあったので観てみました。
※ ブレードランナー2049は、1982年に公開された映画の続編にあたる作品とのことでしたが、1982年に公開された映画のほうのブレードランナーは観たことがないです。
私は記憶力が悪いほうなので覚えている範囲で感想を書こうと思います。
SF作品ということで、AI技術やロボット技術が進化した世界を扱った作品で私の好きなジャンルでした。 主人公は、ヒューマノイドの初期型(レプリカント)を取り締まる新型ヒューマノイド(ブレードランナー)として登場し、レプリカントに対して情は少なく、殺してしまうほどの悪役でした。 しかし、ある事件をきっかけに自分の正体に疑念を抱き、それを捜査する過程で、人間的な情を持ち始め、ヒューマノイドの未来について考え始めるといったストーリーでした。
似たようなストーリーをどこかで見たことがあるような気がしたのですが、 Detroit: Become Human でしょうか。
もし、ヒューマノイドが知性を持ち、世の中で活躍するような世の中になったとき、われわれ人間はヒューマノイドに対してどのような感情を持つのだろうか。 こんなことを考えさせられる作品でした。
感想文を書くのは苦手です。 長い文章を書ける人は一体どういった脳みそをもってるんでしょうか。。。
Wikipedia のダンプデータから知識のグラフ構造を取得したい
前置き
前置き長いので、読み飛ばしてもらって構いません。
何かの知識を得たいと思った時、その知識には前提がある。
その前提が何かを知るには、本を読んだり人に聞いたりする。
個人で勉強するときには、前提がわからないとその壁にぶつかってしまう。
僕は、その壁を取っ払うために何かいい手立てはないかと日々考えている。
完全な独学環境の整備
それが僕の一つの夢だ。
小恥ずかしいことを書いたが、いたって真剣だ。
私が知っている限りの研究としての取り組みでは妻鳥貴彦先生や、三好康夫先生のシラバスの可視化プロジェクトや学際マップという取り組みがあるというのを以前調べた。
Learning Path Finder の使い方 - Tokushima Univ.
あと海外の誰かが作成したこの Web 関係に関するスキルマップもとても面白い。
また、様々な方々が学問マップという形で一学問のマップを考えて作ってくれている例もある。
以下は、物理学などを教える YouTuber ヨビノリさんの動画でとても参考になる。
どの取り組みもそれぞれの知識をグラフ構造に落とし込むことによって知識と知識の連関を理解し、次の知識習得に結び付けようとしている。
これらの素晴らしい取り組みは、最近だとコグニカルというサービスに受け継がれているように見える。
自分も似たようなサービスを空想していただけに先を越された感と応援したい気持ちでいっぱいになった。
学問や学問内のスキルの依存関係を図示したいんだけど、その依存関係についてだれか調べた人とかいないのかなあ... あまり文献が見つからない... というか、探し方が悪いだけかもしれないが...
— cive@-13.6eV (@to4sh) 2020年1月3日
今回はそんな夢を実現するためのデータセットづくりとして、一つやってみたことがあったので記事にしてみた。
Wikipedia のダンプデータから、知識のグラフ構造を作成してみることをやってみたやりたかった。
という失敗談に近いかもしれない。 (正確には、今もデータを入れ続けているが、無限に終わらなさそう)
概要
概要としては、 Wikipedia のダンプデータから、リンクされた記事を取ってきて neo4j にデータを突っ込んでみるというだけである。
結果として、それらの知識同士のつながりあい度合いを可視化できると面白そうと思ってやってみた。
実施手順
実施した内容は簡単でこれだけである。
1. Wikipedia のダンプデータを取得し、 WikiExtractor を使用してリンクが取得できるように展開
2. 展開したデータから Wikipedia 内のリンクだけを取得し、それらのリンクを neo4j に投入
しかし、記事の数が膨大すぎて neo4j にすべてのデータを投入するには莫大な時間がかかりそうということがわかった。
以下は、ラズパイ上で実行中のログである。ちょっとずつ想定完了時間が伸びてきていて一年で完了するのかもわからない状態だ。
結果
簡単な結果だけだが、以下のようにそれぞれの記事同士のつながりを見てみる。
まず、私が、気になったのは数学や物理の知識がどのようにつながるかである。
当初の私の予想としては、数学の簡単な知識から難しい知識に至るまでのマップが形成されると予想していた。
だが、予想を裏切られた。
なぜか、日付や数学にまつわる人物の情報ばかりが出てきてしまった。
悔しいので、微分幾何学で検索してみた。
やはり、先ほどと同様の結果に近い。
なぜ、予想に反しているかといえば、図からもわかるようにまだ投入できていない記事の数が多いからだろうと思われる。
結果を受けて
現在検討中なのは、 neo4j に投入するデータを絞ることで、方法としては何となく思いついているのでちょっとやってみようと思っている。
To be continued?
私にとっての docker-compose と k8s
すごい前の書きかけに下記が残ってたので、供養
概要
複数の OSS をそれぞれコンテナとして立てて、それらの api を使用するようなサーバーを構築したいという状況が最近多かった。
そのようなときに、 docker-compose と k8s を使ってみて、どういうところがうれしかったか? という点についてまとめてみた。
あらかじめ断っておくが、私はどちらについてもヘビーユーザーではないので、間違った意見の可能性もある。
そのあたりは、指摘していただけると、とても助かります。
docker-compose
docker-compose は、コンテナをまとめて記載するとき、とても素直な書き方ができる。
なので、学習コストが極めて低い。と思う。
それに、 yaml ファイルにビルド設定を書くこともできるので、開発中に、コンテナの詳細な外部設定に目を向ける必要がないため、目的に集中することができた。
小さなものを作りたいときには、使用するコンテナを yaml につっこんでおけばよいので、脳死の状態でも書ける。
ただ、長期間、動かしたいなどの用途だと、コンテナがよからぬ原因で死んでしまった場合などを考慮し始めると、つらいかもしれない。
運用には適していないのかもしれない。
k8s
k8s の学習コストが高そうな話を聞いていたが、、、
k8s 自体は、 docker-compose のコンテナの設定とか、環境変数の設定、マウントする volume とかを別々のファイルに分けて、詳細に設定できるようにしただけで、そこまで難しくはなかった。
( 手元で適当に走らせる分には )
k8s の yaml ファイルの書き方については、以下の postgresql サーバーを立てるページがとても参考になった。
上記のページの yaml を写経しつつ、調べつつしていると、以下のことについての理解がすすんだ。
1. configMap とかいう、 docker なら .env に設定するようなことを設定できることとか
2. PersistentVolume という、 docker の volume に相当するような概念とか
