野菜不足ですかね...どうもボクです。
家庭の料理で野菜を増やしたいのに、その機会が減っている…。この矛盾こそが野菜不足につながっているのかもしれません。
⇧ いや、単純に時間が無いんじゃないっすかね？
現代人は多忙ですからな...
By the way,
ちょっと、マルチノードなKubernetes環境をオンプレミス環境に構築してる方がおられたので、自分でも試してみようかと思ったのですが、
- Three servers running CentOS 8 – 1 Master Node and 2 Worker Nodes.
- It is recommended that your nodes should have at least 2 CPUs with 2GB RAM or more per machine. This is not a strict requirement but is largely driven by the needs of the application you intend to run.
⇧ 仮想マシンを3台用意しようとあったので、まずは、仮想マシンの用意をしていこうかと。
問題は、仮想マシンのメモリよね...
私のホストOSのマシンのメモリが、8GBしかないんよね...
⇧ 何度見てみても、「実装メモリ（RAM）: 8.00 GB」に変わりはなく...これが格差社会というやつですよ！
せめて、16GBぐらいのメモリが欲しいっす。
ゲストOSのマシン（仮想マシン）にどれぐらい割り当てられるものなのか...
そんなこんなでUbuntuがさくさくインストールできたので調子に乗ってAndorid7やCentOSやらをインストールしてみたのだが、Virtual Boxはメモリについてオーバーコミットをしない構造だそうで、複数の仮想マシンを立ち上げるとそれぞれの割り当て分メモリが実際に使用される。
このため8GBしかない私のPCでは２GB割り当てのOSを４つも立ち上げるとスワップしまくりになってしまった(^^;
⇧ オーバーコミットって何じゃらほい？
メモリについては単純に搭載している物理メモリを各仮想マシンで必要な分だけ配分して使うことになります。
VMwareでは搭載している物理メモリ以上の仮想メモリをゲストOSに割り当てるメモリのオーバーコミット機能を実装していますが、個人的にはこれは使えない機能だと思っています。メモリをオーバーコミットさせる仕組みは、実際に仮想マシンが物理メモリを超えるメモリを確保して書き込みを行おうとした際に、ちょうどOSがディスク上にSwap領域を設けているのと同じ要領でディスクをメモリとして割り当て、それを仮想マシンはメモリであるという様に認識させるというものです。
⇧ どうやら、VirtualBoxは、ホストOSのマシンの物理メモリの範囲内で、ゲストOSのマシン（仮想マシン）にメモリを割り当てる必要がありそう（涙）。
VirtualBoxに「オーバーコミット機能」は搭載されてないようですが、
ご存知のようにディスクというのは非常にアクセスに時間を要するデバイスです。これを当然のようにメモリとして使用すると耐え難いシステムのスローダウンを招きます。この速度の低下は通常本番稼動しているシステムが許容できる範囲を大きく超えています。このような不安定な動作を引き起こす仕組みは、プロダクションシステムはおろか開発環境でも使用をためらわざるを得ません。
⇧ 本番環境では、システムの処理性能などを考慮すると「オーバーコミット機能」の使用は避けるべきですと。
最低の2GBの割り当てで頑張ってみますか...
⇧ 界王様も、2倍までって言ってたしね...
そんでは、レッツトライ～。
必要なソフトウェアの確認
流れとしましては、
ってな感じですかね。
今回、使用するソフトとしてインストールしてるものとしましては、
| ソフトウェア | バージョン |
|---|---|
| Oracle VM VirtualBox | 6.1.4r136177 |
| Vagrant | 2.2.7 |
| Packer | 1.5.4 |
ですかね。
「VirtualBox」と「Vagrant」のバージョンは組み合わせによっては動かなかったりするようなのでご注意ください。
「VirtualBox」と「Vagrant」のバージョンの対応表とか見当たらんのが辛い（涙）。
Windowsの場合は、Chocolatey、Scopeなどのパッケージ管理ツールでインストールするのも良いかもしれません。
SDKMANは、Windowsだと上手く動かない可能性もあるらしい。
ちなみに、私は、Chocolateyでインストールしました。
Packerの処理を担うTemplates（JSONファイル）
Packerで行われる処理は、すべて、TemplatesっていうJSONファイルで設定してあげるのが良さ気ですかね。
Templates are JSON files that configure the various components of Packer in order to create one or more machine images.
⇧ 仮想マシンのイメージ作成できると。複数のイメージもOKらしい。
Templates なら、
Templates are portable, static, and readable and writable by both humans and computers.
⇧ 人間もコンピューターも読み書きできるし、
This has the added benefit of being able to not only create and modify templates by hand, but also write scripts to dynamically create or modify templates.
⇧ 手動、自動、どっちでも編集できるらしい。
Templates are given to commands such as packer build, which will take the template and actually run the builds within it, producing any resulting machine images.
⇧ まぁ、最終的には、packer build ってコマンドを実行する必要はありますが。
複数の仮想マシンイメージなんだけど、
Packer can create multiple images for multiple platforms in parallel, all configured from a single template.
⇧ 異なるプラットフォーム毎には作成できるらしい。
ただ、やりたいことは、単に「CentOS 7」「CentOS 8」とか異なるOS（isoイメージファイルが複数のパターン）の仮想マシンイメージを同時に作成したいってことなんだけどな...
Templatesの設定できる項目の説明を見た感じ、
iso_urls ([]string) - Multiple URLs for the ISO to download. Packer will try these in order. If anything goes wrong attempting to download or while downloading a single URL, it will move on to the next. All URLs must point to the same file (same checksum). By default this is empty and iso_url is used. Only one of iso_url or iso_urls can be specified.
⇧ 残念ながら、でき無さそうね。
っていうか、「VirtualBox」とか「VMware」とかで変わってくるのかな？
何にせよ、異なるOSの仮想マシンイメージは、同一のTemplatesで作成するのは無理くさいんで、もし、異なるOSを準備ってなったら、その数の分だけ、Templatesファイルが必要ってことか、しかもバージョンとかも異なれば、その数の分も...
ありえないとは思うけど、10000ぐらいTemplatesファイル用意するってなったら、自動化の恩恵があんまり無さそうね...
CentOS 8系はDockerは、サポート外とな
んで、OSのisoイメージファイルとして、Linuxのディストリビューションとしては「CentOS 8系」を使っていこうと思ったんですが、Red Hatさんが何か独自路線を推し進めてますと。
Starting from CentOS 8 (and by extension RHEL 8), docker has now natively been replaced by podman and buildah which are tools from Redhat. As a matter of fact, the docker package has now been removed from the default package repository.
⇧ 「CentOS 7」と「CentOS 8」で、標準で搭載されてるDockerの操作に使用するコマンドが変わってるらしいですと。
っていうか、「CentOS 7」から、Dockerって標準搭載ってたっけ？
⇧ デフォルトで使用できるリポジトリで用意されてるってことね、自分でインストールする必要はあるってことね。
基本的にCentOS7時とインストール方法に大きな違いはありませんが公式ではまだCentOS８のサポートはされていなさそうなのでしっかりとした環境を作るならまだCentOS7のほうがよさそうです
⇧ 上記サイト様によりますと、公式では正式サポートされてないらしい。
RHEL8からDockerコンテナーエンジン、Dockerコマンド等は無くなり、サポート対象外になっています。そのクローンOSであるCentOS8も同等であります。
デフォルト状態では、yum、dnfでインストールしようとしてもリポジトリにDockerが無いことも確認できます。
⇧ まぁ、CentOSはRHEL（Red Hat Enterprise Linux）を元にしてるから、Red Hatがそう言うんなら、RHEL系のLinuxディストリビューションを使っていくのなら「podman」にしていかないといけなくなるんでしょうな。
Linuxのディストリビューションで、「コンテナ」に関わる操作とかは変えるんでなくて、統一して欲しいんだけどな...
DockerとPodmanの違いって？
「Podman」推しなのは分かったんだけど、「Docker」とどう違うんですかと。
んで、Red Hatさんの説明だと、
Essentially the Docker daemon does all the work with registries, images, containers, and the kernel. The Docker command-line interface (CLI) asks the daemon to do this on your behalf.
⇧ Docker の仕組みだと、Docker daemonが全での役割を担ってますと。
んで、Dockerの問題点がいろいろ見えてきていることから、Red Hatとしては「Podman」を推奨しますと。
The Podman approach is simply to directly interact with the image registry, with the container and image storage, and with the Linux kernel through the runC container runtime process (not a daemon).
⇧ 「デーモンプロセス」を無くそうってことを言いたいのかね？
つまり、従来の「Docker」なんかだと、
The Docker Engine (container runtime) is the infrastructure software that runs and orchestrates containers.
Docker: All you need to know — Containers Part 2 - Hacking Talent - Medium
⇧ 「docker client」→「docker daemon」→「containerd」→「runc」って流れになってましたと。
ちなみに、「コンテナ」の仕組みは、
⇧ 上記のPDFにあるように、変遷があるんだけど、最近だと、
| runtime | 仕様 |
|---|---|
| High-level Runtime | CRI（Container Runtime Interface） |
| Low-level Runtime | OCI（Open Container Initiative） |
⇧ レイヤーが分かれてる感じですかね。
仕様から、「CRI runtime」「OCI runtime」とか言われることが多いんですかね？
⇧ 上記サイト様がまとめてくださってますが、「CRI runtime」「OCI runtime」は様々なものが出てきていますと。
開発するアプリケーションによって適した「CRI runtime」「OCI runtime」の組み合わせについても様々ですと。
話は戻り、「Podman」は、
Red Hat decided to invest in Podman because it’s an easy change for anyone used to the Docker command line, but doesn’t require a daemon to be running when one isn’t needed. Also, Podman shares many of the same underlying components with other container engines, including CRI-O, providing a proving ground for new and different container runtimes, and other experiments in underlying technology like CRIU, Udica, Kata Containers, gVisor, etc.
⇧ 「Docker」での「Docker Engine」に当たるの部分が、「Podman 」ってのに変わってるらしいんだけど、内部の仕組みのアーキテクト図が無いからよく分からんけど、少なくとも、「デーモンプロセス」だけは無いんでしょうな、必要ないって言ってるし。
PackerのTemplates（JSONファイル）などを準備
まぁ、 「Podman」の情報が少ないってのと、RHEL系のLinuxディストリビューション以外で使えるのかも分からんので、今回は「Docker」を導入していこうかと。
その前に、仮想マシンのOS（ゲストOS）としては、
In order to conserve the limited bandwidth available, ISO images are not downloadable from mirror.centos.org
The following mirrors in your region should have the ISO images available:
http://isoredirect.centos.org/centos/8/isos/x86_64/CentOS-8.1.1911-x86_64-dvd1.iso
⇧ CentOS-8.1.1911-x86_64-dvd1.iso のisoイメージファイルを参照していきます。
isoイメージファイルのチェックサムの値は、どのミラーサーバも同一の値なので、どれか1つのサイトのものを、確認しておきます。
私は、JAIST（Japan Advanced Institute of Science and Technology）、日本語だと「北陸先端科学技術大学院大学」のミラーサーバのものを使用させていただきました。
# CentOS-8.1.1911-x86_64-dvd1.iso: 7554990080 bytes SHA256 (CentOS-8.1.1911-x86_64-dvd1.iso) = 3ee3f4ea1538e026fff763e2b284a6f20b259d91d1ad5688f5783a67d279423b
ちなみに、isoイメージファイルのダウンロードには、
⇧ 上記のように「1-1」「1-2」「2-1」「2-2」の4パターンがありますと。
それぞれの違いなんかについては、
⇧ 上記サイト様が詳しいです。
Vagrantで複数の仮想マシンを作成・起動できるのですが、ネットワーク周りの設定については、
⇧ 上記サイト様を参考にさせていただきました。
今回用意するファイル群を配置した作業ディレクトリは、
C:\Users\Toshinobu\Desktop\soft_work\virtualbox_work\centos8
│ .env
│ .gitignore
│ packer_cent_8.json
│ Vagrantfile
│
│
├─box
├─http
│ ks.cfg
│
└─provisioners
cleanup.sh
virtualbox.sh
⇧ こんな感じ。
Vagrantのドキュメントの酷さと、ネットの適当な情報にハマりました...
Vagrantfile 内で環境変数などを読み込むときは、
⇧ 外部ファイルに設定しないと駄目みたい。
「dotenv」ってのを使おうと思ってたら、
⇧ いろいろ難しい問題が。
「Direnv」ってのがあるらしいんだが、
⇧ 「Direnv」の更新がかなり前に止まってる...って思ったら、
⇧ こちらのほうは、ちゃんとメンテナスされておりました。
ですが、UnixライクなOSじゃないと使えないって...Windowsは常に除け者ですと。早く、WSL2（Windows Subsystem for Linux 2）が正式リリースされて欲しいもんです。
そんな感じで、他にも、いろいろ泥沼にハマりました。
qiita.com
ディストリごとにパッケージ名が異なるため調べる昼用がありますが、CentOS 8 の場合は
elfutils-libelf-develという名前になっていました。
CentOS 8 + Gnome Shell環境でVBoxGuestAdditionをインストールする方法 – 株式会社シーポイントラボ ｜ 浜松のシステム・RTK-GNSS開発
⇧ パッケージ名を変えてくるとか本当にやめて欲しいよね。
⇧ ファイルなどは、GitHubにアップしたので、もし宜しければご参照ください。ただ、動くには動いたけど、知識ないので、だいぶ適当です。
あと、「.env」ファイルとかは、本当は、公開しちゃ駄目な情報とかを管理するものらしいので、アップしないようにしましょう。（アップしちゃったけどね...）
地味にハマったので、isoイメージファイルをダウンロード元のミラーサーバが稼働してるかチェックしといたほうが良いです。
Templatesで、iso_urlsを設定してるから、Packerが切り替えしてくれたのかもしらんけど、確認できてません。
いちいち、ping 打つの面倒という方は、
⇧ 上記サイト様がスクリプトを作ってくださってる方がおられましたので参考になるかと。
PackerでVagrantのBoxイメージファイルの作成
PackerのTemplatesのあるディレクトリに移動しておいて、
packer build [PackerのTemplates]
かなり時間かかるけど、VagrantのboxイメージできたらOK。
Vagrantで仮想マシンの作成・起動
Vagrantfileでプラグインのインストールをしてるので、1回目のvagrant up では、プラグインのインストールだけで終わってます。
2回目の vagrant up で何とか立ち上がりました。
3台起動できました。
1台目の仮想マシンにログインして、2台目にpingで疎通確認できました。（疎通を終了するときは、Ctrl + C で。）
3台目にもpingで疎通確認できました。
仮想マシンの停止で。
いや～、今回も泥沼にハマって疲れましたな...
あ、GuestAdditions がインストールできてるか確認するの忘れてもうた...
2020年4月17日（金）追記：↓ ここから
GuestAdditions ちゃんと動いてました～。
ネットワークアダプターがNATのほうのゲストOSのIPアドレスを表示。
ネットワークアダプターがホストオンリーアダプターのほうのゲストOSのIPアドレスを表示。
2020年4月17日（金）追記：↑ ここまで
今回はこのへんで。
