2024-11-03

M75q-TinyへのProxmoxのセットアップメモ

KVMホストとして動作させていたが、仮想ネットワーク周りでvnicが作られているのに仮想マシンに割り当てられなかったりする現象が発生して、どうにも修正ができなくなったので、Proxmoxに乗り換えることにした話の続きで、Proxmoxインストールについてメモを残す。

使用する機器

Lenovo M75q-Tiny
- CPU：AMD Ryzen 5 PRO 3400GE
- メモリ：32GB
- ディスク：
  - 128GB（標準ディスク）
  - 250GB（追加ディスク）

構成の検討

128GBの標準SSD(NVME)にはWindows10が入っているが、この領域を削除して、Proxmoxをインストールする
250GBの追加SSD(SATA)があるので、こちらに仮想マシンの仮想ディスク用の領域を作成する
ネットワークは、普段使っている主系の高速回線、加えて低速回線という2本のネットワークが家の中にある
- Proxmoxの仮想マシンからは、高速回線側には出て行けないようFWを構成して、低速回線を仮想マシンの通信用として割り当てる
- 高速回線側からは、NATを設定して仮想サーバにsshなどアクセスをする想定にする
- なので、Proxmoxの仮想ネットワークの構成は、以下の3本構成とする
  - 高速回線側にブリッジした仮想ネットワーク
  - 低速回線側にブリッジした仮想ネットワーク
  - 仮想マシン間でのみ通信が可能な仮想ネットワーク（＝インターネットには抜けられないNW）

初期インストール

Rufusなどを使って、USBディスクにProxmoxのインストールイメージを書き込み、ブートしてインストールしていく
ただし、LenovoのM75q-Tinyは、バッファローのUSBメモリとの相性が悪いので、それ以外のメーカーのUSBメモリを使ってブートUSBを作成する
M75q-Tinyの電源を入れ、F1でBIOSメニューに入る
- Boot orderでUSBメモリを選択
インストール自体は、ウィザードに従っていけば良いので他の方のエントリを参照してほしい

初期セットアップ

データ領域の拡張

SSD(NVME)にProxmoxがインストールされたが、NVMEディスクにデータ領域も作られてしまってる。なので、250GBのSATAディスクにはKVM領域が残っていものを消して仮想マシンのデータストアとして使う

root@pve:~# lsblk
NAME               MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                  8:0    0 232.9G  0 disk 
└─sda1               8:1    0 232.9G  0 part 
nvme0n1            259:0    0 119.2G  0 disk 
├─nvme0n1p1        259:1    0  1007K  0 part 
├─nvme0n1p2        259:2    0     1G  0 part /boot/efi
└─nvme0n1p3        259:3    0 118.2G  0 part 
    ├─pve-swap       252:0    0     8G  0 lvm  SWAP
    ├─pve-root       252:1    0  39.6G  0 lvm  /
    ├─pve-data_tmeta 252:2    0     1G  0 lvm  
    │ └─pve-data     252:4    0  53.9G  0 lvm  
    └─pve-data_tdata 252:3    0  53.9G  0 lvm  
        └─pve-data     252:4    0  53.9G  0 lvm  
root@pve:~#

管理GUIから、data領域を削除する

GUIでのディスク追加

次に領域を削除したディスクをデータストアとして設定していく
管理GUIから、ノード→Disks→対象ディスクを選んでInitialize Disk with GPTをクリック
LVM-Thinを開いて、Create: Thinpoolをクリックして新しいディスクを選択して作成する
- ここで指定した名前は、VG名とLV名に使われる

ネットワークの作成

仮想マシンで使用する仮想ネットワークを作成していく
ノードを選択してSystem→Networkから開くと、Proxmoxホストのネットワーク設定が行える。新しいブリッジを作ったり、ボンディング、VLAN設定などが行える
デフォルトで作成されているブリッジネットワークvmbr0に仮想マシンのNICを割り当てることもできるが、仮想マシン用の仮想ネットワークを作成する
Datacenter → SDNと辿っていく。作成する順番としては、Zoneを作成して、次にVNetの作成、最後にSubnetを作る
- Zoneは、複数のVNetを含むまとまり
- VNetが、仮想マシンのNICに割り当てるLANになる
- Subnetは作らなくても別に大丈夫
  - DHCPでIPアドレスを割り当てたい、そのVNetで使うIPアドレスを制限したいなどのときにSubnetを作るらしい（たぶん）

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
3: ens34: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
5: vnet01: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000

VMを作ったあとには、いろいろインターフェイスが出来ている

$ ip a
10: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr101i0 state UNKNOWN group default qlen 1000
        link/ether ca:4f:38:02:d5:0c brd ff:ff:ff:ff:ff:ff
11: fwbr101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
        link/ether 02:cc:3c:f9:33:80 brd ff:ff:ff:ff:ff:ff
12: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vnet01 state UP group default qlen 1000
        link/ether 0a:ba:b9:cd:52:e0 brd ff:ff:ff:ff:ff:ff
13: fwln101i0@fwpr101p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr101i0 state UP group default qlen 1000
        link/ether 02:cc:3c:f9:33:80 brd ff:ff:ff:ff:ff:ff

次回、テンプレートVMからTerraformを使って、ProxmoxにVMを作成するメモを残す予定。

2024-10-26

http.Handleとhttp.HandleFuncの整理

Golangの標準ライブラリであるnet/httpを使っていると、http.Handleとhttp.HandleFunc、Handler、HandlerFuncとがあって、ごっちゃになってしまうので、自分なりに整理をした。

net/httpライブラリを使ってサーバを起動する（http.ListenAndServe）と、デフォルトのマルチプレクサー;mux（ルーター）が生成される
このmuxに対してURLパスとHTTPハンドラを登録することで、リクエストを受けたりレスポンスを返したり出来る。登録する仕組みとしては、
- http.Handle(pattern string, handler Handler)
- http.HandleFunc(pattern string, handler func(ResponseWriter, *Request))
の2つが用意されている
この2つの違いは、引数にHandlerインターフェイスを受け取るか、HandlerFunc型を受け取るかの違いでしかない
まず、Handlerインターフェイスの定義は、以下の通りServeHTTPメソッドだけが定義されている

type Handler interface {
    ServeHTTP(http.ResponseWrite, *http.Request)
}

次にHandlerFunc型は関数型であり、以下のように定義されている。
type HandlerFunc func(ResponseWriter, *Request)
そして、HandlerFunc型にはServeHTTPメソッドが定義されている。
- このServeHTTPは、レシーバで受け取ったHandlerFunc型を返すだけのメソッドとなっている。

func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
  f(w, r)
}

したがって、HandlerFunc型と同じシグネチャを持つ任意の関数MyFuncをhttp.HandlerFunc(MyFunc)のようにキャストすると、MyFuncに対してHandlerFuncが持つメソッドServeHTTP()が実装される。
- func MyFunc(w http.ResponseWriter, r *http.Request) {// do something }
- MyHandler := http.HandlerFunc(MyFunc)
結果、暗黙的にHandlerインターフェイスを実装する（満たす）ことになる。よって、myFuncは、Handlerインターフェイス型として扱えるので、http.Handleの第2引数として渡せる。
- http.Handle("/myfunc", MyHandler)
じゃあ、この二つの使い分け方はどうするのか？という点だけど、力尽きてしまったのでChatGPTに聞いてみると次のような簡潔な回答を得られた。

使い分け方
- シンプルなハンドラーが必要な場合、または匿名関数で簡潔に処理を記述したい場合は、http.HandleFuncを使用します。
- 状態を持つハンドラーや、複数のメソッドやロジックを持たせたカスタムハンドラーが必要な場合には、http.Handleを使い、構造体やカスタム型を渡すことで柔軟に実装します。
まとめ
- http.HandleFunc: 関数を簡単にハンドラーにしたいときに便利。
- http.Handle: http.Handlerインターフェースを満たす型をハンドラーとして登録し、より複雑な処理を行いたいときに使います。

2024-10-19

素のKVMからProxmox VEへ乗り換えた

雑記

M75q-TinyにRHEL 9をインストールして、KVMホストとして動作させていたが、仮想ネットワーク周りでトラブルがあり、これを解決するよりもProxmoxに乗り換えた方が楽なのでは？と思い、破壊的衝動に駆られ、Proxmoxに乗り換えた
- なぜか分からないが、仮想マシンが起動して、vnicが作られているのに仮想マシンに割り当てられておらず、手動で割り当てようにも接続先の選択肢として表示されず、どうにもならない状態になってしまった
- 仮想ネットワーク周りが壊れるよりも前に、WebコンソールのCockpitダッシュボードが壊れて表示できなくなっていたので、そういうのも乗り換えの一因にある
Proxmox VEを触った感じ、個人用途で仮想環境が欲しいなら、Proxmox VEが簡単で十分だなと思った
- インストールは簡単で、初期設定（VLAN設定、データストア設定）や仮想マシンの管理も全部ブラウザから出来て、便利
- それに、無料版のESXiも無くなったので、もう仮想環境を作る選択肢として、素のKVMかProxmox VEの2択しかない気がする。であれば、Proxmoxの一択かなと
- vSphereに慣れていると、はじめProxmoxの仕組みになれず、奇妙なやっちゃなーって思ったりはしたが、分かってしまえば非常に使いやすい。それに、仕組みが分かってしまえば、素のKVMを触るより100倍くらい楽だなと思った

2024-10-15

『つくって、壊して、直して学ぶ Kubernetes入門』読んだ

読書

www.shoeisha.co.jp

「壊して、学ぶ」というのは非常に面白いテーマだと思ったので、興味引かれて買ってみた
Kubernetes(k8s)という言葉は知ってるけど、どういうもなのか分からないという人が読むと良さそうな入門書
k8sのアーキテクチャについては、全体像が載っているくらいで、あまり解説はされていないので、アーキテクチャを含めて理解したいという場合は、本書では足りないと思う
k8sを少しでも触ったことのある人にとっては、壊す部分が物足りない気がした
- 個人的には物足りなかった
初心者だとk8sが壊れたときに、どう対処したら良いか分からないって場合があると思うし、この本では対処の”型”がハンズオン形式で学べる
- k8sの解説書は数多くあるとは思うけど、障害時の対応について特化した本は無いようにも思うので、そういう意味では非常に有用な本かもしれない
本書を読んだ後、より詳しく知りたい人のための読書紹介や学習ロードマップもあるので、入門書としては丁寧な作りになってると思う

2024-10-14

REALFORCE RC1は結構良さそう

雑記

pc.watch.impress.co.jp

REALFORCE RC1は、個人的には結構理想型のキーボードな感じがする
打ち心地が良いREALFORCEキーのコンパクトキーボードであり、アローキーがある。そして、本体重量が0.6kg
- ケーブルがL字コネクタになってるのは分かってる感があって良い
コンパクトキーボードの有名どころとしてHHKBがあるけど、HHKBの場合は日本語配列にはアローキーがあるのに、US配列には存在しないので、厳しい
- HHKB studioの打鍵感は非常に良かった分、アローキーがないので使っていて不便だった
ただ、REALFORCE RC1のマイナスポイントとして、電源がリチウムイオンバッテリーという点がある
- ポータビリティ性を高めたかったんだろうけど、キーの寿命よりも短いであろうバッテリーを本体に内蔵するというのは如何なものなのだろう
- 同じことを懸念して、結局乾電池を使うようにしたというHHKB studioの開発者インタビューがあった気がするので、余計に気になってしまう
- まあ持ち運んで使うって言うケースは、ぼくは殆ど無いので、ずっとケーブルに接続した状態で使うから、バッテリーがどうとかはどうでもいいポイントかもしれない
とはいえ、KeychronキーボードのK3シリーズがかなり個人的に気に入ってるので、REALFORCE RC1が3万5千円という値段もあり、今回は即購入にはならず

2024-10-11

『APIを作りながら進むGo中級者への道』読んだ

読書 Go

techbookfest.org

同人誌だと1000円くらいのイメージだから、2500円もするので、初見ではちょっとびっくりする。とはいえ、本書は500ページを超える大作だし、内容も素晴らしいので、おすすめできる
- 試し読みもあるので、どういう内容か雰囲気をつかめるし
- Go言語の基礎文法を抑えた後に、簡単なWebアプリケーションを作ってみた後に、次はどうすれば良いのか悩んでる場合に非常におすすめ
本書は、ブログサイトのWebアプリケーションを作っていく
- まずナイーブな実装を行い、それがなぜ駄目なのか、どうリファクタリングしていくかを丁寧に説明してくれているので、初心者にとって非常にありがたい
- 紙媒体で出版される場合だと、誌面の都合上で言葉を削り、説明をある程度簡略化する必要があるので、ちょっとニュアンスが掴みづらくなるとは思うが、本書は存分に、余すこと無く丁寧に説明してくれている
- 機能を拡張してリファクタリングしつつ、最終的には、変更に強いデザインパターンの一つであるクリーンアーキテクチャに従ったコードベースを作り上げていく
  - ただし、本書ではクリーンアーキテクチャについては、詳しく説明はされていないので、もっとクリーンアーキテクチャについて知りたいとなったら、『ちょうぜつソフトウェア』を参照すると良いと思う
他の本書レビューを見ると、本書で使っているgorilla/muxがアーカイブ化されているという記述があり、その時はアーカイブ化されているならgo-chi/chiを使えばいいやと思って特に調べていなかった
- しかし、最近だとメンテナーが見つかってアーカイブ化解除されているような雰囲気がする（あまり調べていない）
- とはいえ、gorilla/muxとgo-chi/chiのどちらも標準ライブラリのnet/httpとの互換性があるので、別にどっちを使っても変わらないのがいい
去年の同じ頃、クリーンアーキテクチャに関して、言葉は知ってるという程度で『詳解Go言語Webアプリケーション開発』を読んで、実際よく理解できず、その次にもう少し理解しようと『ちょうぜつソフトウェア』を読んだり、Udemyの動画も見て勉強してきたが、やっぱり十分に理解したという感覚は得られなかったものの、今回再び本書でクリーンアーキテクチャに従ったコードを書いて、ようやく理解できたように思う
- Goの文法は分かったし、ライブラリを使って、ちょっとしたプログラミングは出来るものの、何かが足りない気がする、というタイミングで本書を読んで、どう書けばより良いコードになるかの設計の考え方が分かったので、そういう意味でタイトル通りの良書だなという感想を抱いた
- 次はWebAPIの設計について勉強してこうかなーって思っている

2024-09-07

全ステ野良カンスト達成！

雑記

9/1(日)のドンブラコシフトで野良カンストを達成して、ようやく全ステージで”でんせつ999”となった
2022年12月から野良カンストを目指してサーモンランだけをやり続けていたのにも関わらず、2年近くもかかってしまった。正直、こんなに時間がかかるとは夢にも思っていなかった
- 現時点でスプラトゥーン3の総プレイ時間は1340時間。2022年12月までに450時間プレイしていたので、900時間近くサーモンランだけをやっていたことになる
- それを考えるとだいぶサーモンランのセンスないねって感じはするけど、これだけやっても全然飽きが来なかったのは、サーモンランというゲームがそれだけ魅力的だったということ。しらんけど
今回のドンブラコ編成は、プロモデラーMG、シャープマーカー、モップリン、リッター4Kという編成
- シューターが2枚に加えて、雑魚シャケに無類の強さを誇るモップリン、そして使い方が難しいﾘｯﾀｰ4k。個人的には、ﾘｯﾀｰ4kがRペンだったら理想的かなーって思った
  - ﾘｯﾀｰ4kは、射程が長いものの、チャージ長い＆1発のみだけなので、使い方がなかなか難しい。なので、割と動きやすそうな編成だったけど、野良カンストいけるか不安はあった
  - もし、ﾘｯﾀｰ4kではなくRペンなら、1回フルチャージで1発240ダメを5発撃てるので使い勝手が良く、HP500のオオモノを処理して、さらに2発残ってるので1回のフルチャで2匹のオオモノを倒すこともできる。さらに、意外にも射程が長いので、それなりに遠くから処理を行えるのがよかった。
  - ただ、対雑魚シャケが圧倒的に弱いため、他に雑魚シャケ処理が強いブキが編成にいるとRペンも動きやすくなる。今回の編成で言えば、モップリンがまさにそれだった
全ステ野良カンストをしてぼくのサーモンランも一区切りがつき、そしてビッグランも9/7(土)を最後にもう開催され無さそうなので、少し寂しい

'sqr'atch-note

ちりはつもれど　ちりぬるを