tech dropbox で DR対策 自宅環境で最も頭を悩ましている問題が家族の写真と動画の管理。これはロストすると痛い上に、既に500GBに到達しているため、メディアに書き出すのも億劫。以前もraid5がどうとかこうとうか記事にしたこともあるんだけど、所詮自宅内でいくら冗長化したって火事一発でデータは消えてしまう。災害対策として、どこか別の拠点にデータをバックアップできないか検討し続けていた。例えば、実家にサーバ置いてしまうとか。 答えは割りと簡単でクラウドストレージを使えばよいだけ。今まで頑にクラウドサービスを避けてきていたんだけど、結局サービス周りをVPSからクラウドに移したり、膨大なメモ管理もevernote任せになったりと、世の中の便利なサービスを使う形に。避けてきた理由はOSS使って冗長性の高いサービスを自分で用意すればいいじゃんという考えだったから。という訳で、データのバックアップも大人しくクラウドストレージを使う事に。 要件としてはlinuxから触れて、安価な事。実はクラウドサーバ系のサービスも確認してみたけど、シンプルなクラウドストレージの方が容量単価が安い。双璧はgoogleドライブとdropb
tech ドコモ光 マルチセッション 再発編 マルチセッションでNATしてると数時間でフリーズしていたルータが一週間弱安定していたため復旧と判断したが、またもフリーズ病が再発。その後は悪夢の6時間インターバルでのフリーズに逆戻り(フリーズというかハング？)。以前はUDPのNAT利用時のみ起きてた問題が、TCPのNATでも普通に起きるようになってしまった。今まで調べてきた法則は一瞬でなかった事に。状況証拠だけの問題特定は所詮この程度の精度か。。。 この一週間もあれやこれやとネットワーク周りはいじっていたので、どこかに問題があったかもしれないが、いずれにせよセンシティブな不具合をこれ以上綱渡りする気にはなれなかった。結局フリーズを抑制するにはセッション2全てのNATをやめるしか手はない。逆を言えば、セッション2でのNATさえやめれば、マルチセッションは安定して使える可能性が高い。断言できないのは一週間単位での再発があった以上、何を以て安定とするか、もはや自信がないからだ。 セッション2をNAT以外でどのように使うかと言うと、例えば宛先ポート80をセッション2に割り当てるとか。これでいわゆるブラウジング全般がセッション
tech ドコモ光 マルチセッション 試行編 大分遠回りをしたが、やっと本来のマルチセッションについての検証。ルータはひかり電話用のPR-S300SEで、メインセッションをドコモnet(動的IP)に、セッション2をi-revo(固定IP)に繋げている状態。セッション2の接続ルール設定で自宅内サーバを送信元アドレスに設定し、ssh/dns/vpnをNATする。もう少し正確に言うとTCPが22と53を、UDPが53と1149をNATしている。vpnはGMOクラウド側にいるopenvpnクライアントと常時接続。 この設定でインターネットを利用していると、ルータが数時間でフリーズしてしまう。見た目上はランプも通常点灯のままなのだが、ブラウザで管理画面を表示する事は出来ず、それどころかpingにすら応答してくれない。結局ルータには通信不可能なので何もわからないのだが、きっとハングしてしまっているのだろう。 問題点を絞り込むために、まずは最も通信が多そうなvpnのNATをやめてみる。すると3時間過ぎてでも落ちない。それまで1〜2時間で確実に落ちていたので、3時間生き残るのは朗報。いきなり当たりを引いたか。以前はメインセッションでvpn
tech ドコモ光 マルチセッション 障害編 前回、ドコモ光でマルチセッションを実現しようとしたら、それ自体でも問題起きたんだけど、レンタルしてるブロードバンドルータが逝ってしまったという話。ブロードバンドルータはひかり電話対応のPR-S300SE。マルチセッションの設定入れてると数時間で応答不能になってしまうので、その度に電源ケーブルの抜き差しで再起動していたんだけど、繰り返しているうちに電源入れてもルータが起動しなくなってしまった。 表面にある殆どのランプが点灯状態で全く動作しない。具体的には以下のような状態。 ルータ電源 : 緑点灯 アラーム、PPP : 赤点灯 ひかり電話、ACT : 緑点灯 登録、初期状態、無名 : 赤点灯 認証 : 緑点灯 UNI : 消灯 光回線、電源、映像出力 : 緑点灯 マニュアルの故障時確認フローチャート見ると、アラーム赤の時点で異常らしい。初期状態のランプも同時に点灯しているとファームウェアの更新になるようだが、10分待っても20分待っても変化せず。ついさっきまで普通に動いていたのに、なぜこんなことに。。。 埒があかないので、ドコモ光の問い合わせ先を探す。どうやらドコモの故障
tech ドコモ光 マルチセッション 設定編 ドコモ光のプロバイダオプションはタイプA/Bと単独型がある。単独型はタイプAに比べて200円安い代わりに自由にプロバイダを選べる。私は今までこの単独型でi-revoというISPを利用していた。このISPは月額500円で固定IPを付与してくれるという太っ腹。ただ、ピーク時の通信速度は値段相応と考える必要がある。更に問題なのはアップロードのデータサイズ上限で1日5GBまで。家族の画像や動画をクラウドストレージにバックアップしようと思うと、この上限はきつくなる。 早速、ドコモ光をタイプAに切り替えて、転送量制限の緩いプロバイダをもう1つ契約する事にした。タイプAで選べるプロバイダのうちで、バックボーンOCNとされているドコモnetを選択した。前日予約をしてドコモショップ店頭で契約変更。一週間くらいで準備が整って連絡が来るとの事。既存と新規ISPの併用期間について確認すると、切替予定日に既存接続は使えなくなってしまうとの話だった。事実なら面倒な事だが、きっと勘違いだろうと信じない。こういうときに食って掛かって質問すると、各所への確認等で多くの時間を奪われるので、さらっと聞き流しておく。
tech さくらのVPSを自宅サーバ(KVM)へ移植 数年前のVPS全盛期な頃に、さくらやGMOなどで幾つかサーバを借りて運用を始めた。それ以前の専用物理サーバレンタルに比べれば非常に安価だったので、幾つものサーバを作り易かった。しかし、最近のパブリッククラウドにその機能を移植したことによって、私のVPSたちはその役目を終わる事になった。 正直、そのまま捨ててしまってもよかったのだが、永続化されないような形で書き殴ったコードや自分に最適化した形に書き換えたLAMPツールなどが山ほどあったので、一応バックアップを取っておこうと思う。そこで今回はさくらのVPSを自宅サーバのKVMとして移植してみる。 まずはVPSのデータをバックアップする方法だが、バーチャルコンソールでddしてデバイスそのものを書き出す事もできるかもしれない。しかし、今回はパーティションを1つにまとめ、且つ最低限のサイズにシュリンクさせてしまいたいので、この方法は取らず、dumpコマンドを使って論理データを書き出す事にする。 VPSサーバ側でdump後のデータサイズは実データ容量に依存するので、不必要なファイルを削除したり、chattr
tech wordpress マルチサイト化 別ドメイン編 前回、検証機でのマルチサイト化に成功したので、同じ設定を本番機に適用する。その上で、サブドメインによるマルチサイトを別ドメインによる複数ドメインのマルチサイトに切り替える。稼働中のサーバに対して変更を実施する場合は、変更適用後に現行サービスの復帰を最優先する。検証機でマルチサイト化後に現状復帰のため必要だった作業は以下。 * パーマリンク設定がデフォルトに戻っていたので元の設定に。 * wp-highlight.jsのテーマがデフォルトに戻っていたので元の設定に。 * WP Super Cacheの設定が停止になっていたのでキャッシング利用に。 これを踏まえて以下のような流れで進めていく。 1. 既存サイトのプラグイン停止 2. マルチサイト化の変更作業 3. 既存サイトのプラグイン再開 4. 既存サイトのパーマリンク設定修正 5. 既存サイトのプラグイン再設定 6. 新サイト構築 前回同様に、既存サイトの全プラグインを停止して、wp-config.phpに『WP_ALLOW_MULTISITE』の設定を追加。管理ページのネットワークの設置からインスト
tech wordpress マルチサイト化 サブドメイン編 久々にwordpressネタを。とある事情でもう1つサイトを作る必要が出てきた。別に何で作ってもよかったんだけど、最近はすっかりwordpressを使い込み始めているし、環境も揃っているから、wordpressでささっと作ってみる事にした。当初は律儀にもう1つwordpress環境を作るつもりだったけど、コードの二重修正とか両者の運用的な同期とか手間の方が大きそうなので、マルチインスタンス的なことが出来ないか調べてみた。 すると、マルチサイトという機能で要件が満たせそう。同一ドメインだけかと思いきや、サブドメインでのマルチサイト化も可能。更にプラグインを組み込めばが別ドメインも対応できそうだ。結構怖そうな修正になるので、バックアップサーバ側を切り離して実験することに。念のため、ソースディレクトリのバックアップは取っておく。mysqlのデータはマスターサーバ側のデータを戻せばよいだけ。 既に運用に入っている www.nodoka.org に新サイト newdomain.com (仮称)を追加するつもりだが、まずはサブドメインで機能評価からやってみる。newdomain.nodok
tech DBサーバ 比較 MySQL vs MariaDB 人気のRDBであるMySQLが方針の問題でMariaDBと分かれた形で開発が進んでいる。今回構築しようとしている新環境で両方使うというのは出来れば避けたいので、どちらを利用するか選定する必要がある。自宅環境はともかく問題はGMOクラウド環境で内部通信の品質が期待できない点をどうするかが課題。 wordpressチューニング(2) mysql編でまとめた通り、DB処理のボトルネックがネットワーク通信になってしまうので、出来れば全てのサーバにDBを持ちたい。例えばMariaDBにはgalera clusterという機能があり、マルチマスターを組める。これを使えば全サーバにDBを置いて参照も更新もローカル通信で完結させることが出来る、と思えなくもない。 ところが、マルチマスターの場合はノード間のデータ一貫性を保証するために非同期でなく、同期的なレプリケーションを行う事を考慮する必要がある。数台のうちはよいが、台数が増えてくるとそのすべてのサーバで同期的なレプリケーションを行うため、更新処理のcommitが著しく遅延する可能性が高い。かといって、マルチマスターで非同期レプリケーションを
tech BIND+MyDNS 構成 再考 何年も前の記事で、BINDとMyDNSの連携についてまとめたことがあった。その記事が未だに参照される事が多いので、今回は現在のDNS周りの考え方を整理しておく。結論から言うと、以前と考え方は大分変わり、BIND+MyDNSの構成は既にやめて、BIND単体での運用に切り替えている。MyDNSをコンポーネントから外した理由は幾つかあるのだが、最も大きな理由がオープンリゾルバの問題だ。数年前にオープンリゾルバの脆弱性を利用して悪質な攻撃の踏み台にされてしまう問題が起きた。それ以降リゾルバの利用に対し制限をかけて最低限の範囲でのみ使える設定に変更した。 BINDでオープンリゾルバの問題を回避するには、自ゾーンのみはどこからでも無制限に引けて、それ以外のゾーンは任意の接続元のみ引けるような設定にしたい。しかし、前段BINDで自ゾーンのみ後段MyDNSにforwardする構成の場合はそういう設定が出来ず、全てのゾーンに対するリゾルバを無制限に解放するしか手がない。これは当然オープンリゾルバとなってしまうので、この構成を取る事が出来ない。 では、逆に前段MyDNSで自ゾーン以外を後段BIND
tech wordpress チューニング (6) nginx編 長々と続けてきた、wordpressチューニング。当初3秒だった処理速度も前回の改善で300msec前後と10倍ほどの高速化に至った。あと残されている改善余地はwebサーバくらいなので今回はnginxを見ていく。webサーバのチューニングにおいて、httpdそのものの処理速度はあまり問題にならないので、通信速度についての改善を考えてみる。nginxのレベルで通信速度をチューニングするとなると、最初に思いつくのはHTMLやcss等のテキストコンテンツの圧縮。設定はそれほど難しくなくnginx.confに以下のような設定を追加する。 : gzip on; gzip_http_version 1.0; gzip_types text/plain text/html text/xml text/css application/xml
tech wordpress チューニング (5) plugin編 前回までで、当初3秒だったトップページの表示は400msec前後まで改善した。今回はwordpressのプラグインで処理速度を改善できないか見ていく。クラウド環境の場合、リモートのDB通信がボトルネックになることはわかっているので、出来ればwordpressのロジック内でDBの値をキャッシュ出来ると望ましい。reverse proxy等でページそのものをキャッシュする事も同じような効果を得られるが、その場合はログイン時の出し分けなどが難しくなってしまうことになる。 最初に気になったプラグインは『DB Cache Reloaded Fix』というもので、まさにDBネックとなっている当サイトにとって効果的な機能に感じた。が、このプラグインはわりと長い間更新が止まっているようなのと、ネガティブな意見を言うブログを幾つか見かけてしまったので躊躇してしまう。 次に見かけたのは『WP Super Cache』で、こちらはDBに限ったものではなくて、あらゆるステップで網羅的にキャッシュを行ってくれるらしい。このプラグインも人によってはネガティブな評価をしているが、見かけたのはログイン時の処理
tech wordpress チューニング (4) php編 前回、php-fpmということでサーバプロセスを中心に見てみたが、今回はphpそのものについてのチューニングを考える。今更だけど、phpは仕事で扱った事ないので基本的には門外漢。適当にぐぐってみたところ、opcacheという機能によるチューニングが筋よさそう。opcacheはphp5.5から使えるようなので、現在のphp5.4を一旦消し去って、remiリポジトリからopcacheも加えた形でphp5.5を入れ直す。 yum remove -y php php-mbstring php-mysql php-fpm php-gd php-common yum install -y http://rpms.famillecollet.com/enterprise/remi-release-7.rpm yum install -y --enablerepo=remi55 php php-mbstring php-mysql php-fpm php-gd php-opcache php-common とりあえず設定はデフォルトのままで、opcacheありの性能検証をしてみた。現時点で6
tech wordpress チューニング (3) php-fpm編 前回のmysql編に続き、今回はphp-fpmを見ていく。apache時代はmod_phpもあったが、nginxの場合はphp-fpmを使う事になる。まあ、mod_php使った場合のリソースのばらつきもひどい有様だったので、リソースの効率的な再利用という意味でphp-fpmの選択は順当と考えている。php-fpmの設定はほぼデフォルトのままだったので改善余地がないか探る。 この手のミドルウェアについて注意する点は、プロセスのメモリサイズと数の妥当性。本番サーバを見てみると40MBくらいのプロセスが10個くらい存在している。普通に考えればそれほどでもないプロセスなのだが、メモリ最低の512MBで動かしているクラウドミニサーバなので、この数値は非常にまずいｗ負荷試験の並列度に合わせて更にプロセスをforkし、メモリ枯渇でswapしてしまうためスループットが出ていなかったようだ。 デフォルトだとリクエスト数に合わせて、dynamicにプロセス数を変更する形になっているが、何度も言うようにこんな過疎サイトではオーバースペック。余計なforkが発生しないようにプロセス数固定の少数設定とす
tech wordpress チューニング (2) mysql編 前回のOS編はほぼ改善なしで、相変わらずトップページが3秒かかる状態。早速今回はDB周りで改善余地がないかを見ていこうと思う。まずDBがローカルかリモートかで変化するか確認したところ、mysqlをwordpressが動いているサーバと一緒にするだけで、処理時間が1秒超縮まり、2秒弱で処理できるようになった。もともとクラウドの内部通信は品質低いと思っていたが、これほどとは。。。 とはいえ、mysqlをローカルにしか置けないというのも困るので、DBとの接続確立が遅いのか、データ転送が遅いのかを一応絞り込む。mysql接続をphpのmysql_pconnect()に置き換えて改善するかどうか。結果としてはmysqlの永続接続にしてもまるで改善が見られなかった。つまり遅いのはmysqlのデータ転送ということになる。 現時点では、数える程度のページビューしかない過疎サイトなので、1号機にwordpressとmysqlを一緒に配置してしまう。負荷低いのに何で2台も使っているの、とか悲しくなる事は聞かないようにｗ2号機の方もwordpressと非同期レプリケーションによるスレーブDBを用意し
tech wordpress チューニング (1) OS編 wordpressを自宅環境からクラウド環境に移設した。クラウド上でwordpressを本番稼働させながら、諸々の整備を進めているため、わりと頻繁にchef-clientを実行したりしているのだが、その際のHTTPレスポンスが著しく劣化しているような気がしていた。実際、chef-clientしつつブラウザで触ってみると、ほぼレスポンスできてないに等しい状態が数分続く事になっている(chefの処理も遅い)。 これはさすがにまずいだろうとスループットを計測してみたところ、通常状態でもトップページの処理時間が3秒を越えており絶望的な数値。。。いくら過疎サイトとはいえ、これではお話にならないので真面目にチューニングする事にした。 まずはそのチューニングのゴールと意義を説明しておく。現時点では日々数える程度のページビューしかない過疎サイトではあるが、一応レスポンスタイムは100msec前後を目指したい。単純なロジックであればそれくらいは難しくないのと、キリがいいからｗ では、そんな過疎サイトにもかかわらず、なぜレスポンスをそれほど気にするのか。ここで言う過疎というのは、あくまで人間的
tech DLNAサーバ 比較 mediatomb vs minidlna ファイルサーバ(samba)を自前で用意しているため、DLNAサーバも自分で立てる必要がある。今まではDLNAサーバにmediatombを使って何とかやりくりしてきた。このツールはとにかく文字コードに対してセンシティブで運用が大変。ファイルシステムをUTF8にしてしまえば何て事はないのかもしれないが、移行前のファイルサーバは歴史が古くEUCだったため、とにかく苦労した。 ファイル名はEUCで、音楽ファイルヘッダ(taglib)の曲名はUTF8にもかかわらず、それらを取り込むときのstring_converterは同じ関数を使っているため、普通に使っていると、どちらかは間違いなく文字化けしてしまう。無理矢理関数追加してごまかしてたけど、もうUTF8の統一環境を作れない限りはmediatombは使いたくないなと思っていた。 そういう背景もあって、今回はOSもファイルサーバもUTF8で構築した。mediatombを使うための準備は整っていたのだが、centos7用のrpmが存在しない。もちろんmakeすれば対応できるだろうが、もはや開発の進展も期待できそうにないので他のツールを探して
media ひかりTV IPv6問題 スマートスイッチ対応 後日、問題が発覚したのでこちらを参照下さい(2016年4月追記) 前回の復習から。ひかりTVの放送波はIPv6 multicastを使って転送されてくるため、MLDスヌーピングに対応したスイッチを使わないと全ノードにbroadcastされる。実質的な性能影響を受けるのは、おそらく無線LAN機器くらいなので、普通に使う分にはそこさえ気を付ければ問題はないかもしれない。ひかり電話用ルータのようにNTTからレンタルしているブロードバンドルータは MLDスヌーピングに対応している可能性がある(我が家はそうだった)。このルータに直結するような形でひかりTVチューナー(st3200)を扱うのであれば問題はない。 うちはBBルータが2階でst3200を配置するリビングが1階なので構造的に直結は無理。2階側はBBルータ直結を上手く使ってリビングのみにIPv6 multicastを絞り込む。リビング側をIPv6対応したスイッチにリプレイスする事で放送波をst3200のみに送りたい。という訳で、MLDスヌーピング対応したスイッチを探してみるが、手頃なもののないことｗCiscoやAllied Te
tech Count per Dayのカウントを日本のみに その後も必要に応じてちょこちょこwordpressのプラグインを追加している。それなりに作り直すとやはり気になるのがPVで、自分について言えばアクセスログでも確認できるんだけど、やはりカウンター的なものを設置したくなる。いろいろ調べてみた結果、見た目も含めて選んだのがCount per Day。自分の場合wordpressの運用は初めてではないので、何となく前も使ってたような。閉鎖する前に使っていたプラグインのリストをメモっておけばよかったな。 いつもならプラグインの新規追加で、さくっと検索してインストールして反映で終わりなのだが、このプラグインは検索しても出てこない。どうやら公式プラグインではなくなったようなので、以下のサイトから直接ダウンロードする。 Count per Day : Toms Dimension プラグインの新規追加ページに『このページから zip 形式のプラグインをアップロード』というリンクがあるので、そちらをクリックして落としたファイルを選択してアップロードする。 ちなみに、この手のアップロードや本体、プラグインの更新機能はhttpdやphpプ
tech raid運用の変遷 ファイルサーバやコンテンツサーバを出来合いのものを使うのが世の中の流れだが、以前、tera stationでデータロストの危機に陥った自分としては、ファイルサーバは絶対に自前で管理したい。tera stationの危機というのは、ディスク障害でなくマザーボード障害が起きてしまい、修理には関西への配送が必要な上、問題ない筈のディスクも搭載したまま送らねばならなかった。 この一件以来、自前でディスクケースを購入してsoftware raidを組んでいる。当初はraid5すら信用せずに、mdadmでraid1を2組とかで運用していた。software raidを使う理由は、安価なhardware raidだとraid controlerが単一障害点になってしまって、マザボ障害のように怖い目を見そうなためだ。加えて、raid1だとディスク単体でもそのままマウントできるので、raidそのものの不具合も回避できる。 それぞれ3TBの実効容量なんだけど、現在はそれを越えるスペースが必要になってきたので、結局当たり前にraid5を使う事にした。とはいえ、実効容量9TBの3TBx4本のraid5
media ひかりTV IPv6問題 前回、コスト削減の観点でスカパー光から移行したひかりTV。サービスそのものには満足しているんだけど、導入初日からネットワーク問題が発生した。ひかりTVチューナーst-3200のセットアップは簡単で、電源入れて手近なスイッチにLANケーブルを接続するだけ。起動して幾つかの設定を済ませると、すぐにCS放送を視聴できるようになった。 その一方で、この辺りから徐々に異変に気付き始める。リビング作業だったのでwifi接続しているVAIOが手元にあったのだが、まずはそのノートPCがインターネットに繋がらなくなる。おかしいと思って手元のスマホをwifi接続で試してみても繋がらない。もしやとスイッチを見てみると8ポート分のLEDが全て点滅し続けている。他の部屋用のスイッチどれを見ても全てのLEDが点滅しているので、この時点ではLANの結線ミスで輻輳が起きているのではないかと疑った。 【送料無料 + ポイント20倍】【延長補償付】トリプルチューナー AM900 いつも通り、まずは切り分けから。st-3200を落としみる。LEDの点滅が止む。切り分け終わり！ｗ 何だ、やっぱりこいつかあ。も
tech GMOクラウドALTUS lxcの利用 前回、GMOクラウドにてcentos6もcentos7も作れるようになったので、今度はその仮想サーバ上でlxcが使えるか検証してみた。rpmでinstallしてlxcコンテナを作成、問題は外部との通信が行えるかどうかだ。GMOクラウドでは、申請すればホストと同じセグメントのprivate IPをもらう事ができる。理想は追加したIPをブリッジ接続した内部コンテナにアサインして外部と通信させる事。 結論から言うと、内部コンテナが外部と通信する事は不可能だった。vethだけでなくmacvlanを試してみたり、centos7でなくcentos6で試してみたり。改善する気配がないので、真面目に調べようと思ってguestでtcpdumpしてみた。ブリッジ接続なので、guestにはhostと同じgatewayを設定しているんだけど、そのdefault gatewayに対して延々とarp requestを送っている。 外部接続するには、まずdefault gatewayのmac addressを覚える必要があるんだけど、guestのarp requestに対してクラウド環境側のg
tech GMOクラウドALTUS kickstart install 前回、適当なテンプレートで1ノード作成して、外からsshできるようにした。次は好きなOSをkickstartなりで自動インストールしてsetupを進めていく。標準のOSテンプレートやISOだとcentos6系までしかないので、centos7を使いたければ自分で用意するしかない。GMOクラウドALTUSはcitrixのcloudstackがベースとなっているので仮想環境にxenを使っており、自力でOSをインストールする場合はxs-toolsというxen用のツールを入れる必要がある。さらっと見た限りcentos7用のツールはなさそうなので、centos7はNGかもしれない。管理コンソール『OSの種類』プルダウンメニューにはcentos7の項目があるからいいのかな。 OSテンプレートが存在するクラウド環境なのに、あえてkcikstartの手順を確立する理由は、テンプレートや私用ISOを配置するバックヤードのストレージ領域も有料だからだ。10GBで月100円とか微々たる金額ではあるが、殆ど使わないのに払い続けるのはイマイチ。できればバックヤードのストレージ領域を使わないで済む
tech パブリック クラウド 比較 GMO vs IDCF vs NTTCom 個人的な月次ランニングコスト・チューニングのためにVPSの運用も見直した。今回からは柔軟性を上げるために内部通信可能な複数台での運用可否を重視したい。また、外部環境にスペックは求めないので、低スペックでもよいから1ノードが安価なこと。そうすると必然的に選択肢たりうるのはパブリッククラウド環境である。自宅環境との親和性を高めるためにもcentos7, lxc, vpn辺りが使えると尚よい。格安スペックを用意しているサービスは以下の3つ。 * GMOクラウドALTUS Basicシリーズ (参考ページ) * CPU 1コア(1GHz) * メモリ 512MB * HDD 20GB * 月額¥500 * IDCF Cloud (参考ページ) * CPU 1コア(0.8GHz) * メモリ 1GB * HDD 15GB * 月額¥500(CPU+メモリ:¥200 + HDD:¥300) * Cloud n (参考ページ) * CPU 1コア(0.4GHz) * メモリ 512MB
tech コンテナ 比較 docker vs lxc 10年振りに新サーバを買ったので、自宅環境の設計を検討する。chefに代表される構成管理ツールの充実でゼロからの再構築が容易になった。その一方で物理サーバやKVM等の仮想サーバだと再構築の検証が重い。それ以外にも個人用途の貧弱なサーバの場合、KVMによるリソースの分断は管理的に面倒だったり、ノード数の制限が付きまとってしまう。 そこで今回はKVMに代わる仮想化を検討していきたい。まずはdockerから触ってみたが、結果から言うと今はまだ使えないと判断した。全ての面で否定する訳ではないが、シンプル且つ統一的に構造化されたインフラ基盤として使っていくにはまだ成熟度が足りないという判断だ。良い面も幾つもあるが、気になる点は以下のものだった。 * プロセス1つのみフォアグラウンドで動かすという原則 もちろんプロセス2つ以上で動かす方法はいくらでもあるが、dockerの考え方を尊重した使い方をする場合、smbとnmbのようなプロセスをどう扱うのか結論が出せない。 * IPアドレスを固定する方法がない これも未成熟なツールを使うか、host networkingを使うか、l