Rancher Academy に入学した
Rancher Academy て何？
特徴
原文はこちらの記事をご覧ください。
Rancher Academy は Rancher Lab 社が用意した、無料のトレーニングポータルです。
最初のコースは Certified Rancher Operator です。レベル1では、Rancher のデプロイ方法や、Kubernetes クラスタのデプロイと管理に Rancher を使用する方法を正確に学ぶことができます。週に3〜5時間勉強して5週間分の内容になっています。
わからないことがあればslackで聞いてくれよって感じみたいです。
レベル2以降の情報が見当たらないので、きっと作成中なんだと思います。
コースの内容は以下のようになっています。
- Week 1: Rancher と RKE の紹介
- Week 2: Rancher をインストールして管理する
- Week 3: Rancher を使って Kubernetes をデプロイする
- Week 4: Rancher を使って Kubernetes を管理する
- Week 5: Kubernetes Workloads を動かす
個人的に Rancher や kubernetes は完全に趣味で業務で触ったことはないんですが、実践的に手を動かすことで身につくかなと思って入学します。
卒業して50問のテストに合格すると、 「Rancher Certification」という認定をもらえるみたいです。
全部英語っぽいけど、なんとかなるでしょう！
注意
前提として、Docker や Kubernetes に関する基礎的な知識が必要です。
「Docker？Kubernetes？なにそれ美味しいの」な人向けではありません。
逆に Rancher に関する知識は不要です。
また、少なくとも2コア、それぞれ8GBのRAMを搭載した複数の物理マシンまたは仮想マシンをデプロイできる環境へのアクセスが必要です。
これらのシステムは、コースのラボで使用されます。
いざ入学
ポータルサイトに行き「Enroll Now」を押してメアドや名前を登録するだけです。もちろん無料です。
登録したメアドにValdationメールが来るので認証しておしまいです。
実際の画面がこちらです。思ってたよりもかなりしっかりしてる印象です。
コースの一覧
テキスト
履修状況
まとめ
ただ動画見るだけとかではなく、しっかりと手を動かせそうで楽しみです。
ここで履修状況をチョイチョイ報告できたらなと思います。
お読み頂きありがとうございました。
Rancher の Vagrant Quick Start が起動しなくなったけど直した話
どうした
以前紹介した、Rancher の Vagrant Quick Start が凄く楽なので、今日も気分良くk8s触ろうとと思って vagrant up したら、
こんなログがずーーーーーっと出続けて上がらないんですわ。
server-01: 6dbf555297f9: Pull complete
server-01: Digest: sha256:09e1bef888ef4e1119eb6aa9a95413c7b0fecc7512700b8546502933a2eaa22b
server-01: Status: Downloaded newer image for rancher/rancher:latest
server-01: + sleep 2
server-01: + docker inspect rancher/rancher:latest
server-01: + docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v /opt/rancher:/var/lib/rancher rancher/rancher:latest
server-01: 273a7a2cfca60eb322727ea3ab66073e1267a86484cd496f5cf59c84d3deee39
server-01: + true
server-01: + docker run --rm --net=host appropriate/curl -sLk https://127.0.0.1/ping
server-01: + sleep 5
server-01: + true
server-01: + docker run --rm --net=host appropriate/curl -sLk https://127.0.0.1/ping
server-01: + sleep 5
server-01: + true
server-01: + docker run --rm --net=host appropriate/curl -sLk https://127.0.0.1/ping
server-01: + sleep 5
server-01: + true
server-01: + docker run --rm --net=host appropriate/curl -sLk https://127.0.0.1/ping
server-01: + sleep 5
server-01: + true
どうしたオイ。上がらなくなってもうた
ログ見る限りは、 server-01 内で自分にcurlして失敗してるように見える。
調べよう
VMはどうなってるんだ
$ vagrant status Config: {"admin_password"=>"admin", "version"=>"latest", "ROS_version"=>"1.5.1", "k8s_version"=>"", "server"=>{"cpus"=>1, "memory"=>2048}, "node"=>{"count"=>4, "cpus"=>2, "memory"=>4096}, "ip"=>{"master"=>"172.22.101.100", "server"=>"172.22.101.101", "node"=>"172.22.101.111"}, "linked_clones"=>true, "net"=>{"private_nic_type"=>"82545EM", "network_type"=>"private_network"}} Current machine states: server-01 running (virtualbox) node-01 not created (virtualbox) node-02 not created (virtualbox) node-03 not created (virtualbox) node-04 not created (virtualbox)
多分 server-01 が出来上がってから node ができる仕様なんだろうな。
server-01 にログインしてみる。
$ vagrant ssh server-01 $ uname -a Linux server-01 4.14.85-rancher #1 SMP Sat Dec 1 12:40:08 UTC 2018 x86_64 GNU/Linux $ docker -v Docker version 18.06.1-ce, build e68fc7a $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 273a7a2cfca6 rancher/rancher:latest "entrypoint.sh" About an hour ago Restarting (1) 36 seconds
rancher コンテナが動いてると見せかけて、なんか再起動しまくってないか君？
コンテナのログ見てみると
$ docker logs -f 273a7a2cfca6 ERROR: Rancher must be ran with the --privileged flag when running outside of Kubernetes
ほうほう。 privileged フラグがないよダメだよと言ってるな。
前は動いてたのにな…何もしてないのに壊れた…
とりあえず調べてみると、 configure_rancher_server.sh ていうのでコンテナを起動してるみたいで、以下の部分で失敗してるっぽい
確かに privileged フラグはついてない。
for image in $curlimage $jqimage "rancher/rancher:${rancher_version}"; do until docker inspect $image > /dev/null 2>&1; do docker pull $image sleep 2 done done docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v /opt/rancher:/var/lib/rancher rancher/rancher:${rancher_version} # wait until rancher server is ready while true; do docker run --rm --net=host $curlimage -sLk https://127.0.0.1/ping && break sleep 5 done
とりあえず privileged フラグをつけるように修正すると無事に上がった。
docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged -v /opt/rancher:/var/lib/rancher rancher/rancher:${rancher_version}
てか privileged フラグて何？
privileged フラグをつけると、コンテナが特権モードで起動し、ホストマシンのデバイスにアクセスが可能になったりします。
Rancherは最近v2.5.0が出たので、そこから privileged フラグが必須になった？
issue をあげた
とりあえず中学生並みの英語で issue を上げてみた。
とりあえずissueを上げたので様子を見ようと思います。
お読み頂き有難うございました。
【読書メモ】システム障害対応の教科書 その2
経緯
こちらの本を買ったので、心に残ったことと、ToDo（行動に移すこと）をメモしていいきます。
前回の続きで、今日は最後の第8章まで。
第5章 障害対応に必要なドキュメント
心に残ったこと
- 関係者の認識合わせのために、抜けや漏れがないように資料を作る
- 障害対応フロー図
- 役割を明確に
- 連絡先管理表
- 障害レベル管理表
- レベルに応じた連絡方法
- 障害対応フロー図
ToDo
- 資料の作成、共有を行う
- 情報の多重管理にならないようにする
第6章 システム障害対応力を高めるツールと環境
心に残ったこと
- システム監視ダッシュボードの効果的な使い方
- 時系列データを表示
- 時系列ではない、今の数字を表示
- 多くの情報を1画面に押し込まない
- 組織のレイヤごとに見せ方を変える
- 指揮を執る人には広範囲、低粒度
- 実作業の人には詳細な情報をリアルタイムで
- CMDB
- スモールスタートで作る
- 組織感での名称を統一する
- CMDBのメンテナンスに工数を取られないようにする
ToDo
- レイヤに応じたダッシュボードの作成
- CMDBの運用を考える
第7章 組織の障害対応レベル向上と体制づくり
心に残ったこと
- 自組織のアセスメントを以下のポイントで行う
- 障害対応時の人の動き
- 対応から完了までのプロセス
- ドキュメント充実度
- ツールや環境
- 本格対策のスピード
- 対応方法の改善
- 教育や訓練
- SREやDXといった潮流の変化を柔軟に受け入れられるようにする
ToDo
- アセスメントを行い、必要なアクションを洗い出す
- 数年スパンを見据えた組織づくり、育成を考える
第8章 システム障害対応力の改善と教育
心に残ったこと
- ポストモーテム
- 障害内容や原因分析だけでなく、対応が適切だったかも検証する
- KPTを使うと良い
- 判断に迷ったことも書く
- 改善や分析の場では、ポジティブな空気づくりを心がける
- 障害内容や原因分析だけでなく、対応が適切だったかも検証する
- BCP訓練
- 訓練の目的、対象範囲をしっかりする
- 机上訓練と実施訓練を行う
- 教育
- 教育を設計し、目標とするスキルセットを決める
- システムのレクチャー
- シャドーイング
- 手順を渡すだけでなく、考えさせる
- 経験させる
- 教育を設計し、目標とするスキルセットを決める
ToDo
- 障害報告書の運用を考える
- BCP訓練を計画する
- 教育方法を計画する
以上です。
とても学びの多い本なので、何度も読み返すことになりそうです。
良い本に出会えてよかった。
【読書メモ】システム障害対応の教科書 その1
経緯
『システム障害対応の教科書』を買ったので、心に残ったことと、ToDo（行動に移すこと）をメモしていいきます。
今回はとりあえず第4章まで。
第1章 システム障害対応を学ぶ意義
心に残ったこと
- 同じ障害は何度も起きないので、反復による教育が難しい
- 障害対応はぶっつけ本番で鍛えないとダメという誤解があるが、体制や報告の仕方などの改善で対応能力を上げることができる
- 仮想化技術クラウドの普及に伴い、システム障害対応の難易度は上昇している
- 障害対応の「漏れ」に注意
- 連絡漏れ
- 影響調査漏れ
- 作業漏れ
- 確認漏れ
ToDo
- 障害対応能力が上がることを目的とした障害対応訓練の策定
- インフラ構成の理解度を調査
- 漏れがないようなフローを作成
第2章 システム障害の定義
心に残ったこと
- システム障害の定義はプロセス開始のトリガー
- ユーザ業務に影響が出ていなくてもシステム障害と定義し、プロセスを開始する
- システム障害定義をサーバ停止などの具体的な事象にしない
- 障害対応の振り返り項目の一つに「障害対応のタイミングや方法が適切であったか」を加え、ドキュメントの陳腐化を防ぐ
- システム障害対応の目的、範囲を定義し共有する
- 共有するときはそのプロセスの用語や内容に齟齬がないようにする
ToDo
- システム障害の定義をし共有する
- 障害対応フロー図や連絡先管理表を作成し共有する
- 振り返り項目に「障害対応のタイミングや方法が適切であったか」を加える
第3章 システム障害対応の登場人物と役割
心に残ったこと
- 障害対応の際は役割を分けて
- インシデントコマンダーには技術力よりも自体を掌握するマネジメント、コミュニケーションスキルが重要
- 必ず根拠・事実に基づいた報告を受ける
- 他部所などから作業担当に直接支持が行かないようにする
- インシデントコマンダーは組織の上長である必要はない（部下の成長が止まるため）
- 最後まで真摯さを失わずに対応する
ToDo
- 障害対応時の役割を分ける（しかし、小さい会社の場合はどうしたら良いんだろう）
- インシデントコマンダーは人員の育成も視野に入れる * スキルレベルに応じて分けていいかも
- 真摯に対応するよう心がける
第4章 各プロセスの基本動作 発生から終息まで
心に残ったこと
- 検知・事象確認で必要なもの
- コミュニケーションツール
- システムの今の状態がわかるもの（監視ツールとか）
- 本来の機能・仕様が分かるもの（仕様書とか）
- 初報は不明な点があってもいいので、とにかくスピード重視
- 影響調査で大事なこと
- 影響あり/影響なし/調査中、を漏れなく伝える。断片的な情報はミスリードにつながる
- 原因調査プロセスで大事なこと
- システム構成図などで意志の疎通を図る
- アプリとインフラで調査方法が異なる
- アプリはインプット・アウトプット・業務仕様を押さえて調査検証
- インフラはシステム障害事象の共通性などから想定箇所の仮説を立てて調査検証を行う
- 早急に業務を復旧させるのが優先なので、What（どこが壊れたのか）までで良く、Why（なせそうなったのか）までは必要ない
- 事実と仮説を混同しない。そのために原因調査ステータスを共有したり、有識者を集める
- 過去に起きた障害の構成やエラーログを保存し検索できるようにしておくと良い
- 復旧対応で大事なこと
- インフラ障害の復旧確認は、システム全体に対して行う
- イベントの確認・事後対応で大事なこと
- 通知されるイベントをできるだけ減らす
- 自動復旧を推進する
ToDo
今回は以上です 最後までお読み頂き有難うございました。
Rancher の Vagrant Quick Start を試す
Rancher Vagrant Quick Start とは
Rancher Server 用のVM1台と、kubernetes node用のVM数台をサクッと構築できるツールです。
こちらがその記事です。
gitのリポジトリはここですね。
動かしてみる
必須なのは
- Vagrant
- Virtualbox
- 4GB以上のメモリ
まずはVagrantからVirtualboxを動かすPluginを入れます。
$ vagrant plugin install vagrant-vboxmanage $ vagrant plugin install vagrant-vbguest
gitから適当なディレクトリにcloneします。
$ git clone https://github.com/rancher/quickstart Cloning into 'quickstart'... remote: Enumerating objects: 81, done. remote: Counting objects: 100% (81/81), done. remote: Compressing objects: 100% (57/57), done. remote: Total 747 (delta 51), reused 41 (delta 24), pack-reused 666 Receiving objects: 100% (747/747), 317.15 KiB | 648.00 KiB/s, done. Resolving deltas: 100% (432/432), done.
quickstart ていうディレクトリができます。第1階層はこんな感じで、Vagrant以外にもAzure、AWS、GCPにも対応してそうです。
$ tree -L 1 quickstart/ quickstart/ ├── Makefile ├── README.md ├── aws ├── azure ├── azure-windows ├── cloud-common ├── do ├── gcp ├── rancher-common ├── test └── vagrant
今回はVagrantでやりたいので、vagrant ディレクトリの中を見てみましょう。
$ tree quickstart/vagrant/ quickstart/vagrant/ ├── README.md ├── Vagrantfile ├── config.yaml ├── scripts │ ├── configure_rancher_node.sh │ └── configure_rancher_server.sh ├── vagrant-provision-reboot-plugin.rb └── vagrant_rancheros_guest_plugin.rb
非常にシンプル。設定は config.yaml にするみたいなので見てみましょう。
admin_password: admin version: latest ROS_version: 1.5.1 # Empty defaults to latest non-experimental available k8s_version: "" server: cpus: 1 memory: 1500 node: count: 1 cpus: 1 memory: 1500 ip: master: 172.22.101.100 server: 172.22.101.101 node: 172.22.101.111 linked_clones: true net: private_nic_type: 82545EM network_type: private_network
とりあえずこのままの状態で作成してみましょう
$ vagrant up
数分待ちます。
無事終了したので、statusを見てみましょう。
$ vagrant status
Config: {"admin_password"=>"admin", "version"=>"latest", "ROS_version"=>"1.5.1", "k8s_version"=>"", "server"=>{"cpus"=>1, "memory"=>1500}, "node"=>{"count"=>1, "cpus"=>1, "memory"=>1500}, "ip"=>{"master"=>"172.22.101.100", "server"=>"172.22.101.101", "node"=>"172.22.101.111"}, "linked_clones"=>true, "net"=>{"private_nic_type"=>"82545EM", "network_type"=>"private_network"}}
Current machine states:
server-01 running (virtualbox)
node-01 running (virtualbox)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
kubernetesを管理するRancherが入っているであろう server-01 と、 多分マスタ兼ワーカな node-01 ができたようです。
https://172.22.101.101 にブラウザでアクセスしてみましょう。
おお！Rancherですよ奥さん！
Vagrantあげたら3分でRancher！
ログインしてみると、 quickstart というクラスタができてます。
node-01 やはりマスタ兼ワーカみたいですね。RancherOS v1.5.1 というOSなのも確認できました。
まとめ
拍子抜けするくらい簡単にkubernetes+Rancher環境ができました。
ちなみにnodeの数を増やしたい場合は、config.yaml の count の値を変えて vagrant up すれば勝手に増えて既存のクラスタに追加されます。
開発とか勉強ならminikubeとかkindでも全然いいと思うんですけど、どうしてもVM作成からやってみたいとか、 ローカルマシンを汚したくないみたいな人にはうってつけなのではと思います。
KVMで無線LANとVMのブリッジができない問題に真剣に向き合った
TL;DR
- Wifiに接続したマシンでKVM使うと、作成したVMがブリッジ使えなくなるよ
- Linuxの仕様らしいので、自分で工夫するか、VirtualBoxのようなWifiブリッジできるプロダクト使ってね
- ちなみにVirtualBoxはMACアドレスを書き換えてるよ
- Libvirtガチ勢はいい人が多いよ
どうした
前回の記事で
『WiFiはレイヤー2転送に対応していない』
と書きました。
具体的にはWifi接続したUbuntuにkvmを入れて、作成したVMをWifiにつないだNICとブリッジしようとしてもできませんでした。
なにをしたかったのか
イメージとしてはこういうことです。VMがホストマシンのブリッジを介して無線LAN NICを使って通信し、ホストマシンの同じL3ネットワークに所属させたかったのです。
ハイパーバイザにKVM、VMの管理にはvirt-managerを使っていました。
なにができなかったのか
VMを作成してもネットワークの設定が有効になりません。ブリッジを介してDHCPサーバ（Wifiルータ）と通信できていないようでした。
ぐぐってみると、KVMの場合、ホストマシンがwifi接続をしている場合はVMとのブリッジ接続ができず、iptablesとかで工夫が必要なのがわかりました。
なるほどiptableとかで曲げないとダメなのか。
つぶやいたら神が降臨した
できないのは分かったんですが、調べた記事の中には『無線LANはL2レベルでの転送をサポートしてない』との書き込みあり、なんでだろなと気になってツイッターでつぶやいてみました。
すると！なんと！こんなリプが！
以前、Wi-Fi ブリッジ開発してました。Layer 2 的な unicast と multicast(含む broadcast) で取り扱いが異なるので面倒ですが、一般にはブリッジできます。
おおおおおー！神きたー！凄い！
確かにWifi中継機とかあるしな。うん。
技術的に不可能ではないですし、無線LAN NIC のドライバが未対応なのだと「予想」します。https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC
なるほど、ドライバの仕様かもしれないと。
AdHoc でなく AP/STA 構成の場合、無線区間中の AP->STA は 1:n の構成になり、以前の無線チップのファームウェアでは無線区間の ack を待たない(待てない)実装がほとんどでした。低い転送レート(bps)で到達確率上げてます。
AdHocていうのはアドホック・モードといい、無線LANアクセスポイントを経由せず、無線につないだ機器同士で直接通信する方式です。 APはWifiアクセスポイント（AccessPoint）のことで、STAはPCのような端末（Station）の事です。
無線通信は基本的に半二重で、APが複数のSTAとやり取りしてるようでも通信は1:1で行われて、他の人は空くのを待ちます。（シングルコアのCPUみたいな感じです）
加えて通信品質が悪いと転送レートを下げるので（≒速度低下）、相手の受信したよっていう返事（ACK）を待てないケースもあったりしたようで、苦労が伺われます。
無線区間中の STA->AP は 1:1 の構成なので無線区間の ack を待てますし、結果として高い転送レート(bps)で送信できます。無線区間中の STA 間通信は STA->AP->STA になるので、また面倒です。RFC ではなく IEEE の話題でしょうか、IEEE802.11bgani とか。
RFCでも調べてみようかと思ってたんですけど、IEEEではないのかというお話。深淵に入り込みそうだな…
libvirtのメーリングリストで聞いてみた
それでもやはりWifi使うとVMがブリッジ使えなくなる理由が知りたくて色々とググってると、libvirtのドキュメントを見つけました。
その中に
Important Note: Unfortunately, wireless interfaces cannot be attached to a Linux host bridge, so if your connection to the external network is via a wireless interface ("wlanX"), you will not be able to use this mode of networking for your guests.
『訳：悪いんだけど、無線インターフェースはLinuxホストのブリッジにアタッチできないぜ。だからもしお前が無線インターフェース（wlan的なやつ）越しに外部と通信したいなら、この方法（ブリッジ）をゲストOSに使うことはできないな』
その理由を知りたいんだよぉ。教えてほしいな。
なので勇気を出してlibvirtメーリングリストにメールで聞いてみることにしました。
勘違いして欲しくないんですが、私は決してGAFAみたいな外資系ITで働いてる人間でも、自己研鑽のためにTOEICの勉強をしてるような人間でもありません。高校生の時にとった英検2級をピークに惰眠を貪る毎日を過ごし、Google翻訳なしでは生きていけない人間です。
Linuxに関しても雰囲気で触ってる人間で、libvirtに関しても『kvmと一緒に入れるやつ？』くらいの認識でした。libvirtメーリングリストなんか絶対ガチ勢の集まりで、変なこと聞いたらF__KとかGIYF (Google Is Your Friendの略で日本語で言うググれカス)とか言われるんじゃないかと戦々恐々としておりました。
でも頑張って聞いてみました。こちらがそのアーカイブです。
ご覧ください紳士淑女の集まりです。むしろ優しい。
機械翻訳を褒めらてもらって、なぜか私まで嬉しいです。
何人かの神から回答を頂いたんですが、以下の回答がFAのようでした。
（私の文章）Is it a limitation of the NIC driver for the wireless LAN?
Not really.
（私の文章）Or is it a limitation of libvirt?
Definitely not. Completely out of libvirt's control.
It is a limitation of
1) the way that almost all wireless connections work (only traffic to/from a single MAC address is allowed on a particular wireless connection). (Yes, I know there are some wireless modes that allow multiple MAC addresses on a single association. But those modes aren't supported by most wireless APs or clients.)
2) Because of (1), the Linux kernel doesn't allow wireless network devices to be attached to a Linux host bridge device.
Some people have had success with IPv6 by enabling proxy ARP on the bridge device and wireless interface (without directly attaching them to each other, then manually adding a host route pointing to the guest's IP. It might be possible to do something similar for IPv4 using proxy ARP, but I personally haven't played with the idea.
意訳：
『それは、Wifiアダプタのドライバの制限でも、ましてやlibvirtの制限でもないよ、libvirtの管理外のところだ。
１）ほとんどの無線接続が使う動作方式っていうのがある（特に無線接続においては単一のMACアドレス間のみ許可される）。 （ああ、もちろん単一の接続で複数のMACアドレスを許可するモード（アドホックのこと？）があるのは知ってるよ。でもそのモードは大抵の無線LAN APやクライアントではサポートされていないんだ）
2）１）の理由から、Linuxカーネルは無線LANアダプタがLinuxホストのブリッジデバイスにアタッチするのを許可してないんだ。
何人かの人はＩＰｖ6と、ブリッジデバイスと無線LANアダプタでARPプロキシを有効にすることで成功してるみたいだ（それぞれアタッチせずに、ゲストOSへのルーティングを手動で設定しながらね）。似たようなことはIPv4でもARPプロキシを使えばできるだろうけど、個人的にそれを試したことはないよ。』
なるほど
さらにツイッターでリプくれた神はこうも言ってました。
無線でブリッジする時は、MAC Addr が 4つ登場します。無線区間の Src/Dst と、有線区間の Src/Dst これに対応してない場合が多いと言う意味だと思います。AP から見ると、どの STA の先に、どの有線MAC があるかも要管理です。別の STA 配下に有線端末がローミングすることも想定しますし大変です。
なるほど、その変換は大変そうだ。
そういえば、神が紹介してくれたDebianの資料にこういう一文がありました。
Just like you can bridge two wired ethernet interfaces, you can bridge between an ethernet interface and a wireless interface. However, most Access Points (APs) will reject frames that have a source address that didn’t authenticate with the AP. Since Linux does ethernet bridging transparently (doesn’t modify outgoing or incoming frames), we have to set up some rules to do this with a program called ebtables.
『訳：有線LAN同士をブリッジさせるような感じで、お前は有線LANと無線LANをブリッジできるぜ。でもよお、大抵のAPっていうのは認証してない送信元アドレスがあるフレームを拒否るんだわ。Linuxは透過的なブリッジをするから（行き/帰りどっちのフレームに対しても、変更するようなことはしないぜ）、どーしてもブリッジしてぇなら、「ebtables」っつープログラムを使っていくつかのルールを設定しなきゃダメだぜ。』
私の脳内で、ようやく話がつながってきました。
神々の教えを図にすると、こういうことでしょうか
Linuxカーネルは様々な用途で使用されるため、想定ケースが多くて大変なんでしょうね。
なので、基本的に無線ブリッジとして使うことはさせないけど、どうしてもやりたいなら自分で工夫してね。ということなんだと思います。
でも、VirtualBoxはできるんですよコレが。ではどういう工夫をしてるんでしょうか？
資料を見てみましょう
こうありますね
Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore Oracle VM VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface.
『訳：ほとんどの無線LANアダプタはプロミスキャストモードをサポートしてないので、無線LANのブリッジは有線LANのブリッジとは違うんだ。（パケットを編集するために）すべてのトラフィックがホストの無線LANアダプタを経由させる必要があり、そのためVirtualBoxは戻りパケットがホストのNICに来るように、送信パケットのEthernetヘッダの送信元MACアドレスを（ホストの無線LANアダプタのMACアドレスに）書き換える必要があるんだぜ。』
なるほどー
じゃあ確かめてみよう！！
パケットキャプチャしてみる
VMからPING送信
VirtualBoxで作ったVMからPINGを送信してみます。
まずは仮想化ホスト（Ubuntu20.04）ののMACアドレスとIPアドレスを確認
$ ip addr show wlp8s0
3: wlp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 08:d2:3e:a2:a2:29 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.8/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp8s0
valid_lft 85067sec preferred_lft 85067sec
inet6 240d:1a:5af:9a00:9ed:344d:e634:58fe/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7064sec preferred_lft 7064sec
inet6 fe80::7293:7384:ea6c:ed7c/64 scope link noprefixroute
valid_lft forever preferred_lft forever
次にVM(CentOS8.2)のMACアドレスとIPアドレスを確認
# ip addr show enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:9a:8d:e0 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s3
valid_lft 78571sec preferred_lft 78571sec
ホストマシンとVMのIPアドレスとMACアドレスは以下であることが確認できました
| マシン種別 | IPアドレス | MACアドレス |
|---|---|---|
| ホストマシン | 192.168.1.8 | 08:d2:3e:a2:a2:29 |
| VM | 192.168.1.10 | 08:00:27:9a:8d:e0 |
# ping -4 google.co.jp
ホスト側でキャプチャしたのが以下の画像です
青枠を見てもらうと分かると思うんですが、VMからの1回目は失敗していますが、2回目で送信元MACアドレスを書き換えて再送信してます。 戻りパケットはホストのMACアドレスです。
まさにこの文章と一致する動きなのが確認できました。
図解するとこんな感じでしょうか
まとめ
- Linuxホストのブリッジはそのままだと無線LANアダプタとブリッジ接続できない
- 仮想マシンとホストWifiデバイスとブリッジしたい場合は、自分でARPプロキシやiptablesを使うか、VirtualBoxのように対応している製品を使う
- Libvirtユーザメーリングリストは神々が集ってるところ
- 勇気を出して聞けばなんとかなる
- 機械翻訳の精度は高く、英語圏もびっくり
最後に
- WireSharkの使い方を教えてくれた黒ブラさん
- 神リプをくれたotsuka0752さん
- libvirtメーリングリストで回答してくれた皆さん
本当にありがとうございました！
最後までお読みいただきありがとうございました。
自宅k8sクラスタ作るぞ 1日目
TL;DR
どうした
今まで自宅PCには、Win10（Dell Inspiron3250）マシンを使っておりました。 Core i5にメモリを16GBまで積んでましたがマザボの限界で16GB以上は搭載できないし、もうちょっと拡張したいなあなんて考えていました。
そんな私に
- win10マシンが不調になる（電源とSSD死亡）
- 一時給付金の配布決定
というBIGチャンスが来たわけですよ。
給付金1号
家族（嫁と子供1人）でPCを共有してるので、『PCが壊れると不便だから、新しいPC買わないと駄目だよね』という上長（嫁）の同意を取るのは容易でした。
メモリ64GB欲しかったのでIntel NUCなんかも考えましたが、
長期運用を考えるとパーツ単位での交換が可能な自作という結論になりました。
昔はPCを自作してたし、今はWebで構成を見積もれるツールなんかもあるので、見積もりに時間はかかりませんでした。
そして予算10万でメモリ64GB乗るマシンとして誕生したのが『給付金1号』です。
構成は以下の通りです。
M.2のSSDを基本として、バックアップとか長期保存するデータはHDDに入れる作戦です。 メモリは予算の都合で32GB（16GB*2）しか買えませんでしたが、後にもう32GB増設する予定です。
それらと、ケースやら電源を買って総額91,766円(税込)。すべてツクモで買いました。がんばれニッポン。
組み上がったあとに壊れませんようにと、世界中の基幹システムを支えている『IBM Z』のシールを前面に貼りました。
少し強くなった気分です。
NWは家庭の都合で無線LANにしました。
こちらの製品をPCI-Eにつけました。上り下り両方共300Mbpsくらいですので全く問題ありません。（このときは…）
やりたいこと
『64GBもメモリ積んで何がやりたいのか』ということの説明をしましょう。
私もインフラエンジニアの端くれなので、自宅にkubernetes検証環境が欲しいです。
しかも超大手ECサイトの方の話を聞くと、k8sのアップデート時には更新などせずに、クラスタごと捨てて新規に作成するという話を聞きました。
リスクのあるローリングアップグレードをするくらいなら再作成する。再作成しやすいようにIaaS基盤としてOpenstackを使ってるようでした。
VMベースでコンテナホストを作って、不要になったらサクッと再作成。
めっちゃ格好いい。絶対モテるじゃないですか。
みなさんもこういう光景見たことあるでしょう。
間違いなくモテますよ。
というわけで、この構成イメージで行きます。すべてコード管理することでいつでも作り直しができる。
OpenstackのようなIaaS基盤も入れようかと思ったんですが、流石にシンドイので今回は見送ってます。代わりにTerraformできっちりコード化していきます。sshしたら負け。
なんでUbuntuかって言うと、『ずーっと使ってきたWinに飽きた』『WSLもいいけど、だったら最初っからUbuntuで良くない？』ていうのが大きいです。
あとはDocker for win と Virtual Boxが同居できないとか、自作の場合はOS買い直しになるとか色々とですね。
Ubuntu 20.04 LTSをPCをに入れる
ここはまあ、dvdとかusbにisoイメージつくってインストーラに従えば大丈夫です。
インストール後の設定とかは以下の記事を参考にしました。
あと、自動ログインを有効にしたあとに再起動すると、突然ログインできなくなって死んだと思ったんですが、こちらの記事に助けられました。
Desktop環境
とりあえず
を入れてます。よくあるVimかEmacsかという宗教戦争に関して私は、『vi派』という中立の立場です。
インフラ系のSIerで働いていたのでVimもEmacsも入ってない（お客様のサーバなので勝手に入れられない）環境が長かったためです。
今のデスクトップはこんな感じです。ターミナルを透けさせて後ろの文字を見ながらやることが多いので透過させてます。
Ubuntuにkvmを入れる
さて本題。徐々にやっていきましょう。
以下の記事を参考にしました。
https://help.ubuntu.com/community/KVM/Installation
CPUが仮想化をサポートしているか確認
$ egrep -c '(vmx|svm)' /proc/cpuinfo 6
1以上ならOKです。仮想化支援機能がONかどうかを確認してます。vmxがIntelでsvmがAMDです。
kvmをインストール
$ sudo apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils
するとですね
$ sudo apt-get install qemu-kvm libvirt-bin virt-top libguestfs-tools virtinst bridge-utils パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 パッケージ libvirt-bin は使用できませんが、別のパッケージから参照されます。 これは、パッケージが欠落しているか、廃止されたか、または別のソース からのみ利用可能であることを意味します。 E: パッケージ 'libvirt-bin' にはインストール候補がありません
そう来るか。どうした話聞くぞ。
そのパッケージはもうないんだな。 libvirt-daemon を使えと。なるほどわかった
$ sudo apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager
これで無事入りました。
サービスの状態を確認
$ sudo systemctl status libvirtd.service
vmを作っていませんが、virshコマンドが有効になってるか見てみましょう。
$ virsh list --all Id Name State --------------------
virt-managerも入れたので、GUIで確認もできます。
NW設定でハマる
VM作成時にNATかブリッジか選べるんですけど、NATだとkubernetes入れた後が面倒そうなのでブリッジで行きたかったんですよ。
ところがですね、『WiFiはレイヤー2転送に対応していない』という事実が発覚します。
有線LANだと全く意識せずに「ブリッジでいいべ」くらいに選択してたものが、wifiにした途端にできなくなるんですよ奥さん。
参考記事
記事の通りやってもうまく行かず途方に暮れてたら救世主が現れました。
求めていたものがそこにありました。virtualboxならwifiでもブリッジできます。
インストールもダウンロードして apt install コマンドで終わり。なんて便利なんだ…
構成イメージもしれっと直しておきます
もし僕と同じように困ってて特別こだわりがない場合は、kvmではなくVirtualBoxでやってみたほうがいいと思います。
というわけで、初日にして最初の設計から変更せざるを得なくなる波瀾の幕開け。
次回はTerraform入れて、gitにプロジェクト作ったりしたいですね。
最後までお読みいただきありがとうございました。
