Infra Study 2nd #2「クラウドネイティブを支えるインフラ技術」に参加した
6/11に開催された、Infra Study 2nd #2「クラウドネイティブを支えるインフラ技術」に参加したのでログを残す。
「コンテナの歴史を追いながらいまいちどコンテナについておさらいしてみる」
講師は株式会社IDCフロンティアの加藤 泰文氏。
仮想マシン(VM)はメインフレームでは1970年代からある技術
実はコンテナも軽量仮想マシンとして古くから(1979年頃)存在していたコンテナとは
- OSから見るとプロセスであり、Linuxではnamespaceやcgroup等の機能で作成されている
コンテナは以下3つの機能で専用のファイルシステムが作られている
PID Namespace
- コンテナごとに独立したPIDを持たせる機能だが、ホストからコンテナのプロセスは見える
vethインタフェース
- ホストとコンテナ間(Namespace)で対になるインタフェースを作成する
2010年ごろからIaCの流れでコンテナが注目される
当時はLXCが存在したが、イマイチな箇所をラップしたDockerが登場し、話題の技術に
→このため、初期のDockerは裏でLXCが動いていたDockerの注目により、Linuxカーネルにコンテナ関連機能が入りやすくなった
- cgroup v1/v2
- PSI などなど
感想
仮想化の誕生から現在までの流れが体系的にまとめられており、
コンテナはこんな歴史があったんだなと驚いた。
今ある新しい技術も様々な技術が積み重なってできたものだと考えると、感慨深いものがある。
「VM時代からコンテナ時代へストレージ管理の移り変わり」
講師はゼットラボ株式会社の坂下 幸徳 氏。
コンテナはステートフルアプリは苦手だと言われているが、そのようなことはない
→2020年の調査では全体の55%が商用環境でステートフルアプリをコンテナ化しているただし、ステートフルアプリにおいては以下を考慮する必要がある
- シャットダウン前のsync
- スケールアウトやバージョンアップ時のデータ同期やリストア
→これらはステートレスアプリでは不要となるため、
正しい認識は「ステートレスアプリに比べ、ステートフルアプリは大変」となる
今今の運用としては、スクリプト等でデータ同期を行うのが主流
→運用自動化のツールも開発中コンテナにおけるストレージの性能について
→VMと比較すると、間にハイパーバイザが存在しないため、むしろベアメタルとほぼ同等。
感想
コンテナ、特にk8sの物理面から見たストレージの情報はあまり見ないため、VMと比較した性能面の話は非常に勉強になった。
元々自分がストレージ担当だったということもあり、面白く聞くことができた講演の1つだった。
ストレージはしばらくご無沙汰していたが、また勉強してみようかと思う。
「クラウドネイティブ時代のデータベース - ストレージエンジンと分散トランザクション -」
講師はこば氏。
ストレージエンジンとは
RDBMSにおいてデータ管理の中心的役割を果たすコンポーネント。
B+Tree、LSM-Treeの2種類のアルゴリズムが使用されている。B+Tree
従来のRDBMSで使われてきたストレージ構造。HDDと相性が良い。LSM-Tree
Immutableでシーケンシャルな書き込みを行うストレージ構造。SSDと相性が良い。最近は記憶媒体としてNVMが登場しているため、一般化すれば上記とは異なるストレージ構造が出現する可能性も。
感想
DBは完全に専門外であるため、内部技術や用語については今一つ理解できないところもあったが、
それでも記憶媒体の変遷でDBの在り方も変わっていく、というのは興味深かった。
NVMという新たな記憶媒体が登場した中で、DBのみならず他のコンポーネントに与える影響も見ていきたい。
Puppet Enterpriseインストール
※過去にまとめたwikiからの移行記事
Puppet Enterpriseインストールのメモ。
環境はmaster、agent共にCentOS6.10。
事前準備
ホスト間での名前解決
エージェントマスタ構成をとる場合、両方のホスト間で名前解決が行えるようにしておく必要がある。
小規模環境等でDNSサーバを立てるまでもない場合は、以下のようにhostsファイルを設定しておく。
$ cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.33.50 puppetmaster 192.168.33.60 puppetagent
設定後、hostnameコマンドでホスト名を確認しておく。
$ hostname -f puppetmaster
オフライン環境でのインストール
master、agent共にインターネットに接続されていない環境でのインストールを行う場合は、
以下のようにbaseレポジトリファイルを無効化しておく。
これをやっておかないと、インストール時にエラーが発生する。
インストール完了後は元に戻すことを忘れないこと。
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.org
ダウンロード
puppet社のHPからtarファイルをダウンロードする。
試用版は10台までであれば無料で使用でき、それ以上はライセンスを購入する必要がある。
インストーラー起動
ダウンロードしたtarファイルを展開する。
$ cd /tmp/ $ ls puppet-enterprise-2019.0.1-el-6-x86_64.tar.gz $ $ tar xvf puppet-enterprise-2019.0.1-el-6-x86_64.tar.gz (中略) $ ls puppet-enterprise-2019.0.1-el-6-x86_64 puppet-enterprise-2019.0.1-el-6-x86_64.tar.gz $ $ cd puppet-enterprise-2019.0.1-el-6-x86_64 $ $ ls -l 合計 184 -rw-r--r-- 1 root root 19630 12月 13 21:18 2017 LICENSE.txt -rw-r--r-- 1 root root 1037 10月 27 07:55 2018 README.markdown -rw-rw-r-- 1 root root 9 11月 2 06:54 2018 VERSION drwxr-xr-x 2 root root 4096 12月 9 14:52 2018 conf.d drwxr-xr-x 4 root root 4096 12月 9 14:52 2018 locales drwxr-xr-x 4 root root 4096 12月 9 14:52 2018 packages -rwxrwxr-x 1 root root 63429 11月 2 06:54 2018 puppet-enterprise-installer -rwxrwxr-x 1 root root 80727 11月 2 06:54 2018 puppet-enterprise-uninstaller
展開したディレクトリ内のインストールスクリプトを実行する。
なお、既にpe.confを作成している場合は以下のようにファイルパスを指定するだけで、インストールが可能。
./puppet-enterprise-installer -c <pe.confのファイルパス>
そうでない場合は引数なしでスクリプトを実行する。
$ ./puppet-enterprise-installer \[WARNING\] Unable to load gettext.sh.
\[WARNING\] Please install the gettext package if you would like
translated instructions. /tmp/puppet-enterprise-2019.0.1-el-6-x86_64
/tmp/puppet-enterprise-2019.0.1-el-6-x86_64
=============================================================
Puppet Enterprise Installer
============================================================= Puppet
Enterprise offers two different methods of installation.
\[1\] Text-mode Install (Recommended)
This method will open your EDITOR (vi) with a PE config file (pe.conf)
for you to edit before you proceed with installation.
The pe.conf file is a HOCON formatted file that declares parameters and
values needed to install and configure PE. We recommend that you review
it carefully before proceeding.
\[2\] Graphical-mode Install
This method will install and configure a temporary webserver to walk you
through the various configuration options.
NOTE: This method requires you to be able to access port 3000 on this machine from your desktop web browser.
=============================================================
How to proceed? [1]:
インストール方法はCLI、GUIの2種類存在する。
デフォルトで、PuppetはPostgreSQLがインストールされるが、既存のデータベースを使用したい場合にCLIインストールを行う。
インストール(マスタ)
CLIインストール
CLIインストールの場合、1を選択する。
pe.confファイル(PuppetEnterpriseの設定ファイル)が存在しない場合、編集画面が表示される。
既存データベースを使用する設定はここで行うが、今回はPuppet内部のPostgreSQLを使用する。
最低限の設定として、コンソールのパスワードを記載しておく。
"console_admin_password": "<パスワード>"
編集後、保存すると作成した設定ファイルでインストールするかを確認される。
Proceed with installation using the pe.conf at /tmp/puppet-enterprise-2019.0.1-el-6-x86_64/conf.d/custom-pe.conf? [Yn]y
インストール後、"puppet agent -t"コマンドを2回実行する。
$ puppet agent -t
$ puppet agent -t
GUIインストール
GUIインストールの場合、2を選択する。
How to proceed? [1]: 2
インストーラーが開始されるので、しばらく待つ。
インストールの準備ができると下記のメッセージが表示されるので、指示にしたがって該当URLにアクセスする。
## Go to https://puppetmaster:3000 in your browser to continue installation.
## Be sure to use 'https://' and that port 3000 is reachable through the firewall.
2018-12-09T14:54:50.394+09:00 Running command: RACK_ENV=production /opt/puppetlabs/puppet/share/installer/vendor/bundler/bin/thin start --debug -p 3000 -a 0.0.0.0 --ssl --ssl-disable-verify &> /dev/null
指示されたURLにアクセスするとインストール画面が表示されるので、「セットアップ開始」をクリックする。
以下をそれぞれ設定する。
インストールの検証が行われる。
問題があればメッセージをヒントに修正する。
インストールが開始されるので、数分間待つこと。
完了すると下記のような画面になる。
コンソールログイン
インストール後、https://\<masterホスト名>にアクセスすると、コンソールのログイン画面が表示される。
adminユーザ、インストール時に入力したパスワードでログインする。
無事ログインできるとダッシュボードが表示される。
インストール(エージェント)
puppetagentはLinuxでは以下のコマンドを実行するだけでインストール可能。
$ curl -k https://<ホスト名>:8140/packages/current/install.bash | sudo bash
インストール後、以下コマンドでmasterに証明書署名リクエストを送信する。
$ puppet agent -t
リクエスト送信後はmasterのGUIにて証明書を承認する。
「無署名の証明書」から追加したいノードを選択し、承認する。
承認後、agentをインストールしたノードが追加されている。
追加されていない場合は、"puppet agent -t"コマンドを再度実行する。
トラブルシューティング
agentからの証明書署名リクエストを間違って拒否してしまった
agentからの証明書署名リクエストを拒否した場合、再度リクエストを送信してもmasterに表示されなくなってしまう。
自分の場合はマニュアルを参考に、証明書を再生成した。
まずは、agentのサービスを停止する。
puppet resource service puppet ensure=stopped puppet resource service pxp-agent ensure=stopped
次に、agentにて証明書が格納されているディレクトリを削除。
rm -r /etc/puppetlabs/puppet/ssl
最後に、agentのサービスを起動する。
puppet resource service puppet ensure=running
これで、masterに証明書署名リクエストが送信される。
masterの承認後、ノード一覧に追加ノードが表示されない場合は"puppet agent-t"コマンドを実行する。
EagerZeroedThickのVMDK仮想ディスクを拡張するとLazyZeroedThickに変換される
※過去にまとめたwikiからの移行記事
EagerZeroedThickでフォーマットしたVMDK形式の仮想ディスクについて、vSphereClient(WebClientも含む)で拡張するとLazyZeroedThickになってしまう。
実際にやってみた
仮想マシンにEagerZeroedThickでフォーマット8GBの仮想ディスク(ハードディスク1)を接続。
このディスクを10GBに拡張すると、LazyZeroedThick形式のディスクになってしまう。
これって仕様なの？
下記KBにもあるが、製品のバグではなく仕様通りの動作とのこと。
KB2054563
当初のEagerZeroedThick形式にしたい場合はvmkfstoolsでLazyZeroedThickから変換してあげる必要がある。
ただ、この挙動で困ったことが発生する場合がある。
困ることって？
普通の環境では無いと思うが、仮想ディスクがぶら下がっているSCSIバスの共有設定が「物理」である場合。
SCSIバスの共有設定が「物理」である場合、仮想ディスクの形式はEagerZeroedThickにしなければならないという制約がある。
そのため、このまま仮想マシンをパワーオンしようとすると、「VMware
ESXはクラスタリング目的で仮想ディスクを開くことができません。」という下記のエラーが表示され、起動できない。
ちなみに、仮想マシンが起動状態の場合は「ディスクの拡張操作に失敗しました: msg.disklib.UNSUPPORTEDFEATURE」という下記のエラーが表示され拡張できない。
従って、LazyZeroedThick形式の仮想ディスクのパワーオン・拡張を行う場合は、SCSIバスの共有設定を変えてあげるか、vmkfstoolsを使ってディスク形式をEagerZeroedThickに変換する必要がある。
partedコマンド使用時におけるディスクのアライメント
※過去にまとめたwikiからの移行記事
アライメントとは一列に並べる、調節するという意味からディスクパーティションの開始位置を調整することを指す。
通常はアライメントを行う必要がないのだが、パーティションを切る場合に気にしなければならないシーンがある。
アライメントを気にする場面
下記のようにpartedコマンドでパーティションを作成する。
$ parted -s /dev/sdb mkpart primary 0 1GB
すると、下記の警告が表示される場合がある。
警告: The resulting partition is not properly aligned for best performance.
これはアライメントが最適でないため、パフォーマンスに影響が出るかもというメッセージだ。
実際にどのようにパーティションが切られたかを確認すると、
$ parted -s /dev/sdb print モデル: ATA VBOX HARDDISK (scsi) ディスク /dev/sdb: 1074MB セクタサイズ (論理/物理): 512B/512B パーティションテーブル: gpt 番号 開始 終了 サイズ ファイルシステム 名前 フラグ 1 17.4kB 1074MB 1074MB primary
となっている。
これの何が問題かというと、ディスクのセクタサイズが関係している。
【前提知識】ディスクのセクタサイズについて
基本的にディスクは1セクタ＝512バイトである。
※なお、最近では1セクタ＝4096バイト(4Kディスク)も見られるが、今回は512バイトとしておく。
4Kディスクの場合でも考え方は同じ。
HDDは物理的にセクタ単位でデータを読み取るため、基本的には512バイトずつ読み込まれる。
ちなみに、メモリやファイルシステムは4096バイト単位でデータを扱うため、OS的には4096バイト単位となる。
4096バイト/512バイト＝8セクタとなるため、HDDとしては8セクタのアクセスとなる。
問題点
先ほどの結果の何が問題だったかというと、
モデル: ATA VBOX HARDDISK (scsi) ディスク /dev/sdb: 1074MB セクタサイズ (論理/物理): 512B/512B パーティションテーブル: gpt 番号 開始 終了 サイズ ファイルシステム 名前 フラグ 1 17.4kB 1074MB 1074MB primary
開始位置が17.4kB＝17817.6バイト、1074MBサイズとなってしまっている点。
つまり、セクタの途中から開始してしまっているため、物理的に読み込む際に効率が悪くなってしまうのだ。
効率の良いデータ配置
効率の悪いデータ配置
このため、partedコマンドが警告を出している。
これを回避する方法としては、開始位置に0%を指定することで、partedコマンドが適切なアライメントを算出してくれる。
$ parted -s /dev/sdb mkpart primary 0% 100% $ parted -s /dev/sdb print モデル: ATA VBOX HARDDISK (scsi) ディスク /dev/sdb: 1074MB セクタサイズ (論理/物理): 512B/512B パーティションテーブル: gpt 番号 開始 終了 サイズ ファイルシステム 名前 フラグ 1 1049kB 1073MB 1072MB primary
開始位置である1049kBはセクタの始まり(512Bで割り切れる)であるため、先ほどのような警告は表示されなかった。
Puppetにおけるディレクトリ作成時の権限仕様
※過去にまとめたwikiからの移行記事
puppetでは、fileリソースタイプを使用してディレクトリを作成すると、 読み取り許可が設定されている場合に実行権限が付加される仕様がある。
具体例
/tmp直下にtestディレクトリを作成。 root:wheelの644で設定する。
file {'/tmp/test':
ensure => directory,
owner => 'root',
group => 'wheel',
mode => '0644',
}
実行する。
[vagrant@localhost ~]$ sudo puppet apply directory.pp Notice: Compiled catalog for localhost.localdomain in environment production in 0.07 seconds Notice: /Stage[main]/Main/File[/tmp/test]/ensure: created Notice: Applied catalog in 0.02 seconds [vagrant@localhost ~]$ [vagrant@localhost ~]$ [vagrant@localhost ~]$ ls -l /tmp/ total 40 drwxr-xr-x. 2 root wheel 4096 Nov 30 13:19 test #rwxr-xr-x(655) -rw-r--r--. 1 root root 22256 Nov 24 07:27 vboxguest-Module.symvers -rw-------. 1 root root 286 Nov 23 10:29 yum_save_tx-2018-11-23-10-29tO5wVu.yumtx -rw-------. 1 root root 286 Nov 23 10:33 yum_save_tx-2018-11-23-10-33Zm7Doq.yumtx -rw-------. 1 root root 286 Nov 24 09:47 yum_save_tx-2018-11-24-09-47zwLb4x.yumtx
testディレクトリのmodeは644に指定しているにもかかわらず、実際は655で作成されている。
これは仕様であり、puppetでは読み取り許可が設定されている場所に実行許可を設定する。
リソースタイプドキュメントより引用
When specifying numeric permissions for directories, Puppet sets the search permission wherever the read permission is set.
ディレクトリに対する数値アクセス権を指定する場合、Puppetは読み取り許可が設定されている場所で検索許可を設定します。
Windowsでrsync(Cygwin使用)
※過去にまとめたwikiからの移行記事
やりたいこと
- WindowsとLinux間でrsyncを使ったファイルの同期がしたい
- 事情により、rsyncはWindows上にてデーモンモードで動作させたい
- Windows(サーバ) ⇔ Linux(クライアント)
前提条件
Cygwin(サーバ)側設定
rsyncをデーモンモードで動作させるため、設定ファイルである/etc/rsyncd.confファイルを作成する。
- /etc/rsyncd.conf
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
[rsync_test]
path = /cygdrive/c/test
use chroot = true
auth users = root
secrets file = /etc/rsyncd.secrets
read only = true
次に、認証ユーザを記載した/etc/rsyncd.secretsファイルを作成する。
ここでのユーザはOSユーザとは無関係であるため、rootユーザを作成する必要は無い。
※あくまでrsync上での認証ユーザ
- /etc/rsyncd.secrets
root:Password
なお、rsyncd.secretsはotherユーザに権限が付与されていると正常に動作しないため、 otherユーザから権限を剥奪しておく。
chmod o-rwx /etc/rsyncd.secrets
Linux(クライアント)側設定
サーバ側の/etc/rsyncd.secretsに記載したパスワードを設定する。
- /etc/rsyncd.passwd
Password
ここまで出来たら準備完了。
ファイル転送
Linux(クライアント)側にて以下コマンドを実行する。
rsync -a --delete --password-file=/etc/rsyncd.passwd rsync://root@<サーバ側IPアドレス>:/rsync_test /tmp/
なお、 rsync://root@<サーバ側IPアドレス>:/rsync_test について、rsync_testの部分はサーバ側のrsyncd.confで記載したモジュール名([rsync_test])とすること。
FWやSELinuxで防がれている等なければ、ファイル転送が行われる。
ファイル転送時に警告メッセージが出た場合
rsyncコマンドを実行した際、下記メッセージが出力される場合がある。
file has vanished: "/proc" (in rsync_test)
file has vanished: "/cygdrive/c" (in rsync_test)
rsync warning: some files vanished before they could be transferred (code 24) at main.c(1650) [generator=3.1.2]
どうもrsyncが/procや/cygdrive/cを見に行っているようだが、
rsyncd.confで同期ディレクトリはきちんと指定しているため、謎。
同期自体は行われているため動作上問題は無いのだが、気持ち悪いのでrsyncd.confファイルに以下の設定を追加する。
[rsync_test]
(省略)
exclude from = /etc/rsyncd.exclude
上記設定は、指定したディレクトリ・ファイルをrsyncの同期対象外とするもの。
実際の対象外設定は、以下rsyncd.excludeファイルに記載する。
- /proc
- /cygdrive
上記設定により、rsyncコマンド実行時の警告メッセージは出力されなくなる。
rsyncをWindowsサービスに登録
Cygwinではcygrunsrvコマンドにて、Windowsにサービスを登録することが可能。
先ほど設定したrsyncコマンドをサービス登録してみる。
Cygwinを管理者権限で起動した上で、以下コマンドを実行する。
cygrunsrv --install rsync --path /cygdrive/c/cygwin64/bin/rsync.exe -a "--daemon --config=/etc/rsyncd.conf" -f 'Rsync daemon service'
–pathオプションでコマンドの場所を指定、-aオプションで引数を指定している。
-fはWindowsのサービス画面にて表示される“説明”の部分。
Windowsでファイルのハッシュ値を確認する
※過去にまとめたwikiからの移行記事
Windowsにおいてファイルのハッシュ値は下記コマンドで確認可能。
certutil -hashfile <ファイルパス> <ハッシュアルゴリズム>
具体例
今回はPowerShellで実行しているが、コマンドプロンプトでも実行可能。
> certutil -hashfile C:\Users\mozukku\Downloads\logo.png MD5
MD5 ハッシュ (対象 C:\Users\mozukku\Downloads\logo.png):
18d5bb229438f7fc258432277b4d1e88
CertUtil: -hashfile コマンドは正常に完了しました。
使用できるハッシュアルゴリズムは以下の通り。
> certutil -hashfile -?
(中略)
ハッシュ アルゴリズム: MD2 MD4 MD5 SHA1 SHA256 SHA384 SHA512
