世はまさに、大コンテナ時代！...はい、技術の進化の波に完全に取り残さてます、どうもボクです。マイクロサービスを実現する上でコンテナ技術が利用されるんだと。マイクロサービスについては、
⇧ 上記サイト様が詳しいです。
サービス・メッシュという言葉は、
⇧ 株式会社ドリーム・アーツが主催の勉強会で、CTOの石田さんに教えていただきました。
BTW（By the wayの意味）、ちょっと前の記事で、Kubernetes環境のスクラッチ構築を試みようとした時に、ファイルシステムのrootパーティションの容量が足りず、必要なファイル群をインストールできなかった... と思ってたんだけど、足りないのは「/」にマウントされてる「tmpfs」ってファイルシステムの容量だったらしい...気づくのに3日ぐらい無駄にしました（涙）、まじで時間を返して欲しい...。
詳細は後半で。
⇧ この回ですね...
で、今回、ファイルシステムの拡張にトライしようってな具合です。
BTW（By the wayの意味）、Javaに詳しい寺田さんのブログで、
⇧ 『Quarkus』って技術がRed Hut 社が公開したと紹介されてました。
こちらの技術も時間を見つけて取り組んでみたいですね。
さらに、BTW（By the wayの意味）、
⇧ シングルノードなKubernetes 環境で良ければ、上記サイト様の「MicroK8s」ってのが手軽にKubernetes環境を構築できるらしいです。
まずは、仮想マシンのファイルシステムのrootパーティションの拡張に、レッツトライ～。
LVMを使っていく方針で
Linuxのディスク（ボリューム）を管理するコマンドは、
⇧ 上記サイト様によりますと、結構な数ありますかね。
そんな中で、
⇧ 上記サイト様を参考に、今回は、LVMっていうユーティリティを利用していこうってことで。
まずは、仮想マシンを起動で。自分は、Windows 10 Homeを利用しているので、Docker ToolBoxで作った仮想マシンを使っていきます。
Docker ToolBoxで作成してある仮想マシン一覧を表示してみます。
docker-machine ls
⇧ 仮想マシン名の「defualt」って、スペル間違えてますね...
⇧ 仮想マシンのリネーム方法がむちゃくちゃ面倒臭そうなので、リネームは時間ある時で。
とりあえず、仮想マシンを起動で。
docker-machine start [仮想マシン名]
あとは、指示通りコマンドを実行...って、デフォルトの仮想マシン名（『default』）でない場合は、仮想マシン名まで付けたコマンドを実行する必要があるらしい。
sshログインする時も同様に仮想マシン名の指定が必要ですね...
無事ログインできたということで。
Docker ToolBoxで作成された仮想マシンはデフォルトの状態では、Tiny Core Linuxってディストリビューションを元にしているらしいんだけど...
⇧ 『Operating System：Boot2Docker 18.09.3（TCL 8.2.1）』の「TCL」が「Tiny Core Linux」のことを指しているとしたら、むちゃくちゃ分かりづらいわ～！
⇧ uname -a でカーネルのバージョンなどの表示を行うことで、ある程度の情報は知ることができるらしい、Tiny Core Linux の情報はどこにも出てこないけど...
まぁ、よく分からんのだけれど、boot2dockerってディストリビューションが、Tiny Core Linuxってディストリビューションをラッピングしてるようなイメージなんですかね？
なのでかは分からんのだけれど、パッケージ管理ツールは、Tiny Core Linux のものを利用するらしい...分かりづらいわ！
⇧ 上記サイト様を参考に、いま、仮想マシンにインストールされてるライブラリ（Tiny Core Linuxでは、エクステンションっていうらしい）を確認。
tce-status -i
んで、Tiny Core Linux でLVMを利用するには、「lvm2」ってのをインストールする必要があるらしい。
⇧ 上記サイト様が詳しいです。
Tiny Core Linux で利用できるライブラリ群（エクステンション）は、以下のサイトで確認できるようです。
lvm2 で絞ってみました。
ということで、
⇧ 「69-dm-lvm-metad.rules」ってファイルもしくはディレクトリが存在しないと...どういうこっちゃ？
docker@defualt:~$ ls -la /usr/local/share/lvm2/files / total 0 drwxr-xr-x 2 root root 120 Apr 27 2017 . drwxr-xr-x 3 root root 60 Jan 2 2014 .. lrwxrwxrwx 1 root root 55 Apr 28 01:17 10-dm.rules -> /tmp/tcloop/lvm2/usr/local/share/lvm2/files/10-dm.rules lrwxrwxrwx 1 root root 59 Apr 28 01:17 11-dm-lvm.rules -> /tmp/tcloop/lvm2/usr/local/share/lvm2/files/11-dm-lvm.rules lrwxrwxrwx 1 root root 60 Apr 28 01:17 13-dm-disk.rules -> /tmp/tcloop/lvm2/usr/local/share/lvm2/files/13-dm-disk.rules lrwxrwxrwx 1 root root 62 Apr 28 01:17 95-dm-notify.rules -> /tmp/tcloop/lvm2/usr/local/share/lvm2/files/95-dm-notify.rules
⇧ なんか、「/tmp/tcloop/lvm2/usr/local/share/lvm2/files/69-dm-lvm-metad.rules」へのシンボリック・リンク「69-dm-lvm-metad.rules」が「/usr/local/share/lvm2/files/」に存在しないらしい...というか、「/tmp/tcloop/lvm2/usr/local/share/lvm2/files/69-dm-lvm-metad.rules」が存在しないからシンボリック・リンク「69-dm-lvm-metad.rules」が作成されなかったってことですかね？
権限の問題とか？と思って、
⇧ 上記サイト様を参考に、rootユーザーに切り替えて試してみるも、
⇧ そもそも、root ユーザーじゃ実行すらできないしね...
パッケージ管理ツールでインストールしてんのにな～...っていうか、バグ？こちらとしてはどうにも手の施しようが無い気が...
いけるとこまで、行ってみるということで。fdiskコマンドで現在のディスク構成（どんなディスクがパソコンに搭載されているのか）を確認
fdisk -l
dfコマンドでディスクとパーティションの関係を確認
df -h
結果
root@defualt:~# df -h Filesystem Size Used Available Use% Mounted on tmpfs 890.4M 229.5M 660.9M 26% / tmpfs 494.7M 0 494.7M 0% /dev/shm /dev/sda1 29.2G 48.8M 27.6G 0% /mnt/sda1 cgroup 494.7M 0 494.7M 0% /sys/fs/cgroup /c/Users 464.9G 263.0G 201.8G 57% /c/Users /dev/sda1 29.2G 48.8M 27.6G 0% /mnt/sda1/var/lib/docker /dev/loop0 868.0K 868.0K 0 100% /mnt/sda1/tmp/tcloop/lvm2
「/」の容量が、1GBに満たないって...あと、「/mnt/sda1/tmp/tcloop/lvm2」にマウントされた「/dev/loop0」 のファイル使用率が100%になってるのが「69-dm-lvm-metad.rules」が作成されなかった原因な気がしますかね、いや～、容量の調整したいからlvm2 を入れようとしているのに、lvm2 のインストールでも容量が足りずって...
一旦、仮想マシンを作り直しました。（仮想マシンの内容がすべて無くなってしまうので、内容を取っておきたい場合は、他サイト様を参考で）
容量が増えてますね。
ただ、rootパーティションの容量はまったく変わらずという...
当然のごとく、lvm2 のインストールでも同じエラー。
ちなみに、boot2docker（Tiny Core Linux）のfilesystem はというと、「extfs」の「ext4」ってものになるらしい。
docker@default:~$ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on tmpfs tmpfs 911788 235084 676704 26% / tmpfs tmpfs 506548 0 506548 0% /dev/shm /dev/sda1 ext4 48340772 55248 45760396 0% /mnt/sda1 cgroup tmpfs 506548 0 506548 0% /sys/fs/cgroup /c/Users vboxsf 487436396 277841628 209594768 57% /c/Users /dev/sda1 ext4 48340772 55248 45760396 0% /mnt/sda1/var/lib/docker
「/dev/sda1」のタイプが「ext4」となっとるので。
で、3日ぐらい無駄にして気づいたんですが、私のやりたかったことは、タイプが「tmpfs」ってもので「/」にマウントされてるファイルシステムの容量を増やしたいってことってことになるらしい。
⇧ 上記サイト様を参考にリサイズできました...すみません、LVMとか一切不要だったという...私の費やした3日間を返していただきたい（哀）
というわけで、改めて、仮想マシンを作り直しました。仮想マシンを削除する際は、仮想マシンは必ず停止しておきましょう。
⇧ コマンドが受け付けない場合でも、「Oracle VM VirtualBox マネージャー」から強制的に「電源オフ(W)」で停止できます。
では、仮想マシンの再作成で。メモリとか、CPUを増やしてます。
docker-machine create -d virtualbox --virtualbox-cpu-count 4 --virtualbox-memory 5120 --virtualbox-disk-size 50000 default
そしたらば、指定のあるコマンドを実行後、sshログインし、rootユーザーに切り替え、「/」にマウントされてる「tmpfs」の容量を増やします。
mount -o remount,size=10G tmpfs /
結果は、
root@default:~# df -h Filesystem Size Used Available Use% Mounted on tmpfs 10.0G 229.6M 9.8G 2% / tmpfs 494.7M 0 494.7M 0% /dev/shm /dev/sda1 46.1G 53.9M 43.6G 0% /mnt/sda1 cgroup 494.7M 0 494.7M 0% /sys/fs/cgroup /c/Users 464.9G 265.0G 199.8G 57% /c/Users /dev/sda1 46.1G 53.9M 43.6G 0% /mnt/sda1/var/lib/docker
できました。
そんじゃ、いよいよ、Kubernetesのスクラッチ構築で。
まずは、Kubernetes 本体をダウンロードしていきます。
調子に乗って、「pre-release」版をダウンロードしてしまった...
ダウンロードしたgzファイルを展開していきます。
展開されました。
んで、「~/kubernetes/server/」「~/kubernetes/client/」ともに、まだバイナリ群が無いので、
Kubernetesに必要なものをインストールするために、スクリプトを実行する必要があるらしい。
スクリプトを実行で。
sudo ~/kubernetes/cluster/get-kube-binaries.sh
⇧ なんか、パスを追加すれば良いらしいんだけど、「/home/docker/」は仮想マシンが再起動されるたびに、リセットされちゃうんで、ファイル群を移動しておく必要があるかと。
移動で。「/usr/local/bin/」配下なら大丈夫かと。
sudo mkdir -p /usr/local/bin/kubernetes/client/bin/
sudo mv ~/kubernetes/client/bin/* /usr/local/bin/kubernetes/client/bin/
そしたら、パスを追加で。
export PATH=$PATH:[追加するディレクトリ名]
一応、「kubernetes-server-linux-amd64.tar.gz」「kubernetes-client-linux-amd64.tar.gz」が配置されたんだけど、
⇧ クライアント側は、展開してくれてるんだけども、何故かしらは分からんのだけれども、サーバー側は自力で展開する必要があるらしい...
tuxknight-notes.readthedocs.io
⇧ で、上記サイト様を参考にしようとしたんだけども、
https://kubernetes.io/docs/setup/scratch/
⇧ 上記のアドレスに飛んでみると、
⇧ まさかの公式サイトは 404 Page Not Found...もしや、スクラッチ構築は非推奨になったんですかね...まじか...5日間ぐらい無駄にしちまってるんですが...
とりあえず、続けてみます。
「/home/docker/kubernetes/server/」に移動しておいてから、
tar -xzf kubernetes-server-linux-amd64.tar.gz
⇧ tar を実行した時に、うんともすんとも言わないから成功してるのかが分からんのだけれども...一応、ファイル群は展開されたようです。
っていうか、「kubernetes-src.tar.gz」は展開すべきなのかが分からん...
⇧ だいぶ、前に、「kubernetes-src.tar.gz」に何もソース入ってないけどってissueがあったそうな...
展開してみたら、なんか、むっちゃファイルがおるんですが...必要なファイルが分からんのだけれども...
⇧ 「kubernetes-src.tar.gz」関連については、保留で。
んで、「~/kubernetes/server/kubernetes/server/bin/*」を「/usr/local/bin/」へ移動で。
そしたらば、kubernetesの「api-server」を動作させるのに必要な「etcd」をインストールしていきます。
⇧ 上記サイト様の適当なバージョンを選択し、「リンクのアドレスをコピー(E)」しちゃいましょう。
そしたら、ダウンロードで。
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-amd64.tar.gz
そしたら、展開で。
tar -xzvf etcd-v3.3.12-linux-amd64.tar.gz
etcd～系のものを、「/usr/local/bin」に配置すれば良いらしい。
sudo mv ~/etcd-v3.3.12-linux-amd64/etcd/* /usr/local/bin
「etcd」の起動に、仮想マシンのIPアドレスが必要らしいので、コマンドプロンプトをもう1つ起ち上げて、IPを確認。
そんでは、「etcd」を起動で。
etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://[仮想マシンのIPアドレス]:2379 &> /tmp/etcd.log &
etcd が動いているか確認。
etcdctl cluster-health
そしたらば、「api-server」 の起動で。「api-server」は、サーバー側のバイナリ群に入ってるものらしいので、「/usr/local/bin/」に移動済みってことになるようです。
kube-apiserver --etcd-servers=http://localhost:2379 --service-cluster-ip-range=[kubernetes のクラスタ内でのみ疎通が可能な ClusterIPの範囲]/24 --bind-address=0.0.0.0 --admission-control="" --insecure-bind-address=0.0.0.0 &> /tmp/apiserver.log &
起動確認。
curl http://localhost:8080/api/v1/nodes
一応、「api-server」が動くところまでは行けたらしい。
5日間ぐらい無駄にしてしまった...公式のドキュメントにkubernetesのスクラッチ構築の手順とか載せて欲しいですな...見つけれないだけで、存在するのかしら？
連休の半分が潰れてしまったではないか（涙）
ということで、今回はこのへんで。
