経緯 巷ではどこもかしこもk8s, GKE, EKS, Fargateとコンテナで盛り上がっている。 昨年末、Fargateはある程度触ったのでそろそろk8sも触っておこうと思ったのが今回の背景。 その上で、k8sを構築する先を新規で購入しようか考えていたのだが、自宅サーバーである「MX130 S2」をスペックアップすることで代替できるかもしれないとわかったのでまずは調査と下準備ということで、その記録。 調査（CPU編） MX130 S2のデフォルトCPUは 「AMD Sempronプロセッサー145（2.80GHz,1コア）」 という代物で、とてもVMホストに耐えられるものではない。 今まではCentOS上のコンテナをいくつか並べてWordPressを運用するだけだったが、今後はVMホストにしたいのでマルチコアでないと運用に耐えられない。 ということで調べていたところ下記記事を見つけた。 富士通 PRIMERGY MX130 S2 に FX-6100 を載せる どうやらマルチコアのCPUでの動作報告のようで、CPU載せ替えが現実的であることがわかった。 ヤフオクで4000円程度だったのポチった。 調査（ストレージ） 今まではSATAの HDD300GB だったが、この間池袋のツクモに行ったところ、 hpのSSD250GB が3000円だったので即購入。 本当は2本のRAID1にしたかったが、何かあったら作り直す覚悟で一旦はシングルで行くことにした。 調査（ハイパーバイザーの選定） 次にハイパーバイザの選定だが、過去構築経験があるものとしてはKVMとESXiで、触れたことのあるものであればOpenStackであった。 OpenStackだったらハイパーバイザの構築勉強にもなるかと思ったのだけど、ESXiであればMacからもウェブで管理できるようになってるらしいと知った。 MacでESXiを操作したいって？Host Clientを使えばできるよ。ESXi6.0 Update 2ならね！ 私が初めてESXiに触ったのはおおよそ8年前で、当時はWindowsだったのでvSphere Client経由で操作していた記憶がある。 今のはHTML5で作られているらしいので、やはり需要があってのことだと思う。※これならMacユーザーも使えるし 調査（VM管理） 調べてみたらTerraformでESXiのVMが管理できるという。（さすがTerraform…） terraform by HashiCorp * VMware vsphere ESXi5.5 で VM を自動生成 Terraformで構成できるなら、最初だけ作り込めばあとは作ったり削除したりが容易になるので、上述のこともありハイパーバイザはESXiにすることにした。 ということでそれなりの道のりになりそうだけど、とりあえず、自宅サーバーをk8s化すべく動きだした。 準備その１ – さくらのVPSのAnsible化 実は叔父の会社のサイトをWordPressで運用しており、それにさくらのVPSを使っている。 構築をむかーし担当して、運用はゆるゆると任されてやっている。 契約は叔父の会社なのだが、しばらくk8s環境を作って運用できるまで間借りさせてもらい、自宅サーバーにあるサイト2つを退避させるべくまずはここから手を付けた。 このサーバーは CentOS6+Apache+mod_php5.3+MySQL5.1 だった。 定期的に yum update all からの再起動はしているもののインフラエンジニアになりたての頃に一生懸命手で作ったので、もちろん構成管理はしていなかった。

【障害内容】 https://inamuu.com/, https://wiki.inamuu.com/ にアクセスすると、504 Gateway Timeoutが表示されて、サイトへアクセスできない。 【障害日時】 2018.10.23.火 20:30 ~ 22:13 【復旧方法】　 電源投入により、通常起動を確認。 【障害原因】 子供がサーバーの電源を誤って押したため。 【時系列】 20:30 WordPressのプラグインであるJetpackによるサイトの監視で、サイトへアクセスできないメールを受け取る。ただし、仕事により気が付かず。 21:00 メールにてサイトへアクセスできないことが判明。対象サイトへアクセスするも、2サイトとも504 Gateway Timeoutであることを確認。なお、サイトの前段にはリバースプロキシとしてnginxのコンテナを稼働させているが、エラー画面がnginxのエラーではなかったので、Dockerプロセス自体が停止していると推測。 21:30 奥さんへLINEにて、本日停電がなかったか確認するも、特に無いとの報告をうける。 22:10 帰宅後、サーバーの電源LEDが点灯していないことを確認。電源ボタンを押下し、起動を確認。 22:13 サイトが閲覧できること、およびJetpackモニターより復旧のメールを受信。 22:15 サーバーへSSHできることを確認し、調査を開始したところ、子供より誤ってサーバーの電源を押下したことを聞き、原因と判断。messagesやsar,dfでも特に問題が見受けられないことから、調査を終了した。 【実施済みの対策】 子供への注意喚起と報告があったことについて褒めた。 奥さんへのサーバーの電源の位置、およびLEDの点灯がサーバー起動状態であることを共有。 【今後の対策】 サーバーの電源ボタンカバーを検討。 サーバーの配置変更を検討。 RaspberryPiによるk8s化を検討。 Jetpack通知をSlack化、または監視をMackerel移行。 なんかそれっぽくポストモーテムを雑に書いた。というか単なる障害報告だな、これは笑 息子から緑に光るから気になって電源を押してしまったという報告を受けたのは流石に吹いてしまった笑 今の家は宅内配線がなく、リビングのテレビ台の脇に光の配線がきているので、必然的に一番家族がいる場所にサーバーやらネットワーク機器をおいている。 今回はそのせいで発生してしまっと言っても過言ではない。 しかし、息子がちゃんと報告してくれたのでモヤモヤせずに済んだし、注意喚起はしたが、報告してくれたことは褒めた。 間違ったことをしてしまった場合にはちゃんと謝らなければいけないということをわかってくれているので、それはとても安心した。※ちなみに息子は3歳。 自宅にサーバーなんて置くなよとも思うかもしれないが、非エンジニアだった頃、インフラエンジニアになりたくてノートPCで自学習のために自宅サーバーを運用しはじめたのもあり、筐体の世代は交代はしつつも思いが深いのもあってまぁユルリと運用できれば良いかなと思っている。（ノートPCは連続稼働に向かないことを知り、タワー型へ移行した） Twitterだったかどこかで見たけど、自宅サーバーは盆栽だなんて言うし、多分そうなんだと思う。盆栽知らんけど。 今の筐体は小型で、1コアだけどメモリ8GBで十分だし、何も問題が無い。筐体のサイトから調べて、月々の電気代も900円くらいというのがわかっているので、同じスペックのVPSを同じ値段で探すのは難しいと思っている。 RaspberryPi複数台でk8s構築して運用しても面白いかなと思いつつ、またいずれかな、と。 いつ筐体が死んでも大丈夫なようにバックアップも日次7世代取得しているので、筐体死んだらどこかに移す予定。 それまではなんとか頑張りたい。 新人エンジニアのためのインフラ入門 (Think IT Books) SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム <p style='padding: 5px;'>

今年の7月に自宅にあるNASのHDDが1本お亡くなりになった。 RAID1なので新しいHDDに交換して事なきを得たけれど、先日もう片方のHDDも逝ってしまった。 前回と若干異なる作業だったので、今回も備忘録をこめて残しておく。 元々中古のHDDを2本差してRAIDを組んでおり、まる3年が経過していたので、もった方だと思う。 前回同様、SEAGATEの2TB 7200rpmのものを購入してリビルドすることにした。 前回と違うのが、今回は予兆無くNASが停止してしまったことと、エラーがDEGRADE MODEではなく、SATA INITIALIZEだったこと。 BUFFALOのサイトでエラー内容を見たところ、ハードディスクの故障以外に基板故障の可能性もあるとのことだった。 家に古い2TBのHDDがあったので、試しに差し込んでみたところ、OSは起動し、disk2_broken_errorに切り替わった。 この時点で筐体側の問題ではないと判断して、新しいHDDを購入した。 TeraStationにはUSB接続で、外付けHDDにバックアップする機能があり、それを有効にしていたのでバックアップが正常に取れているかだけザックリと確認（最近保存した写真がバックアップされているかの確認）して、HDDが到着するまでNASは停止しておいた。 HDDが到着したので、新しいHDDを差し込んだ。 左が故障したHDDで右が新しいHDD。 新しいHDDを差し込んでTeraStationを起動したものの、disk2_broken_errorは変わらない。 RAIDの再構成ボタンがあったと記憶しているが見当たらなくて、少々戸惑ったけれど、BUFFALOのサイトをみたところ、筐体前面のfunctionボタンを3秒間音がなるまで長押しすると書いてあったので実行した。 すると、筐体のディスプレイの表示が変わり、ディスクチェック等がなされたあとにリビルドが開始された。 前回は7時間半程度でリビルドが完了したが、今回はそれ以上かかり、私が仕事にいっている間に完了した。 試しにファイルの書き込みを行ったが、問題なく実施できた。 今回で2つのHDDが新しくなったので、筐体が壊れてしまわない限りは、あと3年くらいはもってほしいなぁという気持ち。※筐体自体も中古で購入していて3年経過した。 とは言え、想定どおりに復旧したので良かった。 おしまい。

経緯 自宅ではTerastationのNASを運用しています。 これは、サーバーのバックアップの他に、家族の写真なども保存されているので大変重要なサーバーです。 我が家では、0時を越えたあたりから、各種サーバーのバックアップが始まるのですが、この日はいつもと状況が異なりました。 バックアップが開始されたと同時に、Terastationのディスプレイが真っ赤に点灯し、警告音が鳴り出し、最終的にはシャットダウンしました。 いつもは緑色のバックライトですが、今日は真っ赤でした。いかにも警告。ディスプレイの内容を見ると「DEGRADE MODE」となっておりました。 ここ3ヶ月くらい前からHDDから異音がしていたので、ついに壊れたかという気持ちです。 この日のために、すでに奥さんには了承をもらってHDDは購入していたので、準備はバッチリ。 右が古いHDDで左が新しいHDD.いずれもSEAGATEでした。 古い方は5400rpmでしたが、新しい方は7200rpmで正常な方のHDDも5400rpmなので、回転数は低い方に引っ張られます。 もったいない感はなきにしもあらずですが、致し方ないので、次は7200rpmのHDDにしようと思いまいた。 リビルド リビルドは自動で行われないので、HDDを指してTerastationを起動後、管理画面から対象HDDを選択してRAIDの再構成を選択すると、REBUILDが開始されます。 今回は7時間半弱で完了しました。 2TBのRAID1で、データ使用率56%程度なので、想定範囲のリビルド時間だったと思います。 アップデート ついでにファームのアップデートが降ってきており、SAMBAの脆弱性対応が含まれていたので、アップデートも同時にやってしまいました。 先程スマホの10GB越えのデータを移してみましたが、異音はしないで無事にコピーできたので問題は解消したと判断して良さそうです。 今回故障したHDDは中古のHDDだったので、個人使いでも3~4年程度で故障してしまいました。 Terastation自体も古い筐体なので、いずれは起動しなくなることも想定して、Terastationのデータを外付けHDDへバックアップしています。 いずれはTerastationそのもののリプレイスも検討しないとなぁという気持ちですが、またそれはいずれ。 おしまい。

概要 このinamuu.comをやっとHTTPS化しました。 wikiの方はさっくり出来たのですが、WordPressの方で少しハマってしまったので、メモとして残しておきます。 構成(下記roleは全てdockerコンテナで稼働) nginx → WordPress(apache2+mod_php) 証明書作成（Let’sEncrypt） Let’sEncryptのサイト通りにやります。 # git clone https://github.com/certbot/certbot # cd cert-bot # ./certbot-auto -n # ./certbot-auto certonly --webroot \ -w DOCUMENTROOT1 \ -d inamuu.com \ -d www.inamuu.com \ -w DOCUMENTROOT2 \ -d wiki.inamuu.com \ -m メールアドレス \ --agree-tos -n # ls -l /etc/letsencrypt/live/inamuu.com 合計 4 -rw-r--r-- 1 root 543 5月 25 23:08 README lrwxrwxrwx 1 root 34 5月 25 23:08 cert.pem -> ../../archive/inamuu.com/cert1.pem lrwxrwxrwx 1 root 35 5月 25 23:08 chain.

やろうやろうと思ってできていなかった自宅サーバーのOSアップデートと、アプリケーションのDocker移行をこのGWでやってました。 サーバー構成図（変更前と変更後） 変更前 CentOS6 apache+mod_php（PHP5.4）で全てのアプリケーションを動かしていた 設定変更時はファイルの日付で世代管理! 変更後 CentOS7 Docker（docker-compose）で分けているので、アプリケーションに応じてPHPのバージョンを変えている。（PHP7だと既存のPukiwikiが動かなかった…） itamaeでプロビジョン（git管理,RaspberryPiのgitbucketサーバー） 移行時に困った点 移行時に困ったのはfirewalldとdockerの衝突でした。 標準搭載のfirewalldを使用するためにセキュリティ設定を入れていたのですが、dockerのコンテナ起動時にdocker自身がiptablesコマンドでDNATを追加しているらしく、それが失敗してdockerへ接続できないことがありました。 結局、良い解決方法が見つからず、firewalldは諦めてiptables-servicesを動かすことにしました。 移行して良かった点 docker-composeでアプリケーションを管理しているので、手元で色々やりやすくなりました。（検証とか） ホストサーバーとアプリケーションがDockerを中心に分離出来ているので、管理する側としても状態が判別しやすくなりました。 今回itamaeを初めて使ってみましたが、普段仕事ではPuppet（どちらもRuby製のツール）を使っているので、erbなどは同じように使えてとても導入しやすかったように感じてます。 Gitで管理しているので、ファイルの日付による世代バックアップが不要になりました笑 今後の課題 今回はとにかくOSのアップデートとdockerへ移行することを目的にメンテナンスを実施したので、いくつかのアプリケーションは移行作業時には含まず、後回しにしたのでそれらをゆるりとdocker上で動かしていきたいです。

前回、RapberryPiのDockerでGitbucketを動かすという記事を書きましたが、やっぱりDocker上だと重かったです… Dockerでnginxやphp-fpmで軽量のアプリケーションを動かす程度であれば全然大丈夫だと思うのですが、Javaを動かすのは流石にRasperryPi3といえど厳しかったです。 そこで、Dockerはやめて直接GitBucketをRaspberryPi3へインストールして利用することにしました。 概要 RaspberryPi3へGitBucket4.10.0(2017/3/19時点の最新)をインストールする 保存先データは外付けHDD 外付けHDDのフォーマットとマウント フォーマットの細かい手順は省略するとして、RaspberryPi3でXFSフォーマットするには、下記パッケージが必要なのでインストールします。 [code lang=”bash”] $ sudo apt-get install xfsprogs [/code] これでXFSでフォーマットができるようになります。 あとは、いつも通りに、 [code lang=”bash”] $ sudo fdisk -l <– ブロックデバイス名を確認する $ sudo fdisk /dev/sda [/code] もともと使っていたHDDであれば「d」オプションでパーティション消して、「n」で作成します。最後に「w」で書き込み。 パーティションが作成できたら、mkfsでXFSフォーマットします。 [code lang=”bash”] $ sudo mkfs.xfs /dev/sda [/code] XFSフォーマットが完了したら、外付けHDDをマウントする先を準備します。 [code lang=”bash”] $ mkdir /mnt/usbhdd/ [/code] fstabにマウント先を書いて、再起動後もマウントされるようにします。 [code lang=”bash”] $ sudo vim /etc/fstab ~~ snip ~~ /dev/sda1 /mnt/usbhdd xfs rw 0 0 [/code] 保存したらマウントします。 [code lang=”bash”] $ sudo mount -a

もうすぐ社内で某大会が開催される。 それに触発された形にはなるけれど、そう言えば最近自宅サーバーが遅くて辛いなぁと思ってたので少しだけ手をいれることに。 と言ってもベタにリバースプロキシとして使ってるNginxでキャッシュさせるというもの。 アクセスが多いわけではないのにメモリが10GBくらいあるのでもったいないと思い、キャッシュディレクトリ用にはtmpfsを作成した。 [code] $ sudo mkdir -p /mnt/nginx/{cache,tmp} $ vim /etc/fstab ### 追記 nginxcache /mnt/nginx/cache tmpfs size=128M 0 0 nginxtmp /mnt/nginx/tmp tmpfs size=64M 0 0 $ sudo mount -a $ df -h nginxcache 128M 0K 128M 0% /mnt/nginx/cache nginxtmp 64M 0 64M 0% /mnt/nginx/tmp [/code] んで上記tmpfsにproxyするようにNginxにサッと書いてreloadした。 [code] http { proxy_ignore_headers X-Accel-Redirect X-Accel-Expires Cache-Control Expires Set-Cookie; proxy_cache_path /mnt/nginx/cache levels=1 keys_zone=cache-space:4m inactive=7d max_size=100m; proxy_temp_path /mnt/nginx/tmp; [/code] [code] location / {

ログの出力は直接ファイルに書き込みが走るので、ディスク性能がモロに影響する。 Apache2.2で低速なディスクを使っていて、それなりにアクセスがある環境だと、BufferedLogsをOnにするだけで体感速度が変わるくらい大きな影響がある。 Nginxでも同じようにバッファーできないのかな？と思ってみたら、やはりあった。 http://nginx.org/en/docs/http/ngx_http_log_module.html 試しに自宅サーバーで設定してみた。 設定はaccess.logの後にbuffer=サイズを追記するだけ。 [root@master01]/etc/nginx# diff nginx.conf.20160819 nginx.conf 35c35 -- access_log /var/log/nginx/access.log custom; --- ++ access_log /var/log/nginx/access.log custom buffer=32k; これでNginxをrestartすればOK。 実際にログをtailで見てもちゃんとバッファーされた。 自宅サーバーだとアクセス少ないので、32kだと中々ログ出力されない笑 どの程度影響があるかわからないけれど、これは知っておいて損はなさそうに思う。 また、良さそうなパラメータがあったら設定してみたい。

前回「自宅サーバーの静音化パート1」で自宅のメインサーバーのCPU温度を下げるために、フィンにアルミの洗濯バサミをつけた内容をご紹介しました。 今日はもう少し趣向を凝らして、NASのファン交換をした話をご紹介します。 まず、対象のNASの型番はTerastationシリーズの「ts-wxl」です。 [blogcard url=http://buffalo.jp/products/catalog/storage/ts-wxl/] こちらの製品は既に生産終了していますが、ベイが２つあって従来のTerastationと同じようにRAIDが構成できます。 私は2TBのHDDでRAID1を構成しております。 ヤフオクで安価に手に入れることができるのでおすすめです。 ちなみに、もともと音自体はかなり静かなのですが、もっと静かにさせたい！という思いが強く交換することにしました。 もともと搭載されているファンはこれです。 [blogcard url=http://www.nidec.com/ja-JP/product/fan/category/F010/G080/P2000346/] 2000rpmで25dBA。 特にPCファンに詳しいわけではないので、上記だけを頼りに最近できた池袋のツクモへ行ってみました。 そこで購入したのがこれ。 1500rpmで、15dBA。 回転数は下がりますが、音が小さくなるので、バランスを鑑みてこれにしました。 このts-wxlシリーズは背面のファンが上記のように簡単に交換できるようになってます。 過去にファン交換する人が多かったのかもしれませんね。 実際に交換してみて音を比較してみたところ、やはりかなり音が小さくなりました。 ファンの音のによる影響はかなり大きいようですね。 回転数が下がっているので夏が心配ですが、交換してよかったです。 自宅のパソコンの音が大きい場合は、パソコンの中を掃除したり、上記のようにファンを思い切って交換してみるのも一つだと思います。  以上、自宅サーバーの静音化パート2でした。