ConoHa
1GBプランのバックアップイメージを512MBプランへ展開することはできない ようなので、結局手動で移設したなど。同期に失敗してデータ欠損しないかと動悸が止まりませぬ。
前提条件
現サーバー | 新サーバー | |
---|---|---|
ConoHaプラン(ともに東京リージョン) | 1GBプラン(月額900円) | 512MBプラン(月額630円) |
メモリ1GB+SSD50GB | メモリ512MB+SSD20GB | |
OwnCloud | 8.1.5.2 | 9.1.1.3 |
OS(ConoHa製アプリケーションサーバーイメージ | CentOS 6.7 (Final) | CentOS 7.2.1511 |
データ格納 | ConoHaオブジェクトストレージ |
- 現サーバー
- ConoHa 東京リージョン・メモリ1GB+SSD50GB
- OwnCloud 8.1.5.2
- OS (ConoHa製アプリケーションサーバーイメージ) CentOS 6.7 (Final)
- 新サーバー
- ConoHa 東京リージョン・メモリ512MB+SSD20GB
- OwnCloud 9.1.1.3
- OS (ConoHa製アプリケーションサーバーイメージ) CentOS 7.2.1511
データ格納先はともにConoHaオブジェクトストレージ
手順
- ownCloudとの同期アプリを全て終了(自動起動もOFFにしておくとなお安心)
- 現サーバーでmysqlのフルダンプを取得
$ mysqldump -u root -p owncloud_db |gzip -c > owncloud_db.dump.gz
- 新サーバー構築
- ConoHaコントロールパネルへログイン
- [サーバー追加]タブ
- タイプ=VPS
- メモリ=512MB
- イメージタイプ=アプリケーション
- アプリケーション=[その他] – ownCloud
- ディスク容量=SSD20GB
- その他の設定=適宜
- サーバー起動後、OSアップデート、作業ユーザー追加等々のセキュリティ対策は適宜。
- 現サーバーから新サーバーへmysqlのフルダンプをコピー
$ scp owncloud_db.dump.gz <新サーバーIP>:
- 現サーバーの /var/www/html/owncloud/config/config.php を新サーバーへコピー (注: このファイルはapacheオーナーのみ参照可になっているので、適当にセキュリティ突破すること)
$ scp /var/www/html/owncloud/config/config.php <新サーバーIP>:
- 新サーバーへログイン
- mysqlのダンプを新サーバー上mysqlへロード
$ zcat owncloud_db.dump.gz |mysql -u root -p -D owncloud_db
- config.php を /var/www/html/owncloud/config/ へ配置 (注: 既にファイルが存在するので、適宜バックアップ)
$ sudo cp config.php /var/www/html/owncloud/config/config.php
- /var/www/html/owncloud/config/config.php の内容を編集
- trusted_domainsの配列内に現サーバーのhostname, IPアドレス等があるので、これを新サーバーのものへ変更
- overwrite.cli.url のドメイン名部分を現サーバーから新サーバーのものへ変更
- version を 現サーバー(8.1.5.2)から新サーバー(9.1.1.3)へ変更
- dbpasswordを新サーバーのmysqlサーバー、owncloud_userアカウントのものへ変更
- /var/www/html/owncloud/config/config.php のオーナーを user=apache, group=apacheに変更(なお、SELinuxはDisabledになっていました)
$ sudo chown apache.apache /var/www/html/owncloud/config/config.php
- apache2をリスタート
$ sudo systemctl restart httpd
- 新サーバーのOwncloudへWebアクセスしてみる (成功していれば、セットアップ画面ではなく通常のログイン画面が表示されるはず)
- このあたり、初回はプラグインのアップデートが始まる場合も
- 新サーバーのOwnCloud上にあるべきファイルがあることを確認
- 各OwnCloud同期アプリを起動
- 現サーバーの設定を削除し、新サーバーの設定を追加
- 同期が成功することをConoHaたんに祈る
- 現サーバーはこれにてお役御免ですので、最後にバックアップするなり、きれいに削除するなり、お好きに。
新サーバーへの残項目
- HTTPS化
- SELinuxがDisabledなので有効化したい
- PHPが5.6系なので7.x系にしたい
- ていうかこのPHP、PHP-fpmになってないよね?
新サーバー(512MBプラン)の注意点
- やっぱりメモリに余裕ない感じ(以下は一通りの移設作業を終えた状態での計測)
$ free —mega
total used free shared buff/cache available
Mem: 489 386 10 1 91 75
Swap: 2047 121 1926
- yum upgradeしたら最初のyumリポジトリへのアクセスが遅いように感じました。メモリでしょうか…?
Twitterのほうで呟いていたものを整理しました。「諦めて手動で移行しろ」←結論。
問題
ConoHaでメモリ512MB、SSD20GBプランが新設されました。既存の最安プラン(メモリ1GB、SSD50GB)より300円弱お安くなります。
以前からConoHaの1GBプランでOwnCloudのアプリケーションイメージをロードし、データ格納先としては同じくConoHaのオブジェクトストレージを使用していたのですが、この場合フロントエンドとなるVPS側はほとんどディスクを使用しません。ルートディレクトリからの実測で9GBくらいです。
これで50GBはもったいないし、とはいえリアルタイム同期させている都合上開発サーバー等にするのは扱いが面倒になるので、新プランのSSD20GBに縮小移行しようと思ったわけです。
で、VPS上で通常シャットダウン→ConoHaコントロールパネルで手動バックアップ→新しいVPSを512MBプランで選択、イメージタイプ:「保存イメージ」で作成しようと思ったのですが…イメージのリストに出てきません。
1GBプランで選択すると出てくるので、モノとしては存在する様子。というか以前別の目的でバックアップした開発環境VPSのイメージもリストに出てこない。
調査
挙動からして何かフィルタリングされているように見えたので、 ConoHa API 側からつつけば理由が分かるかと調査を開始。
以前開発した ConoHaでメール送信するツール でAPIアクセスの基本部分は出来ていたので、これを改造して利用しました。…というかこのアクセスライブラリ部分は切り分けて公開しましょうかね。OpenStackクライアントライブラリだとConoHa独自(?)のメールサーバー機能とか、使えない様子だし。
以前作ったコード に機能を追加。
def list_image( self ): try: response = urlopen( urllib2.Request( urljoin( self.imageservice_endpoint(), '/v2/images' ), None, self.auth_headers ) ) self.http_status = response.getcode() if self.success(): infos = json.loads( response.read() ) image_info = {} for info in infos['images']: image_info[info['name']] = info response.close() return image_info else: response.close() return self.http_status except HTTPError as err: self.http_status = err.code return self.http_status else: response.close()
さらに呼び出し側も改造。
from conoha import ConoHa import sys import json def exit_if_failure( conoha ): if not conoha.success(): print( 'HTTP_STATUS: ' + str( conoha.http_status() ) ) exit( 1 ) with open( sys.argv[1], 'r' ) as config_reader: config = json.loads( config_reader.read() ) conoha = ConoHa( config['identity_url'], config['user_agent'] ) connect_response = conoha.connect( config['username'], config['password'], config['tenant_id'] ) exit_if_failure( conoha ) image_list = conoha.list_image() for name,image_info in image_list.items(): if 'private' == image_info['visibility']: for key in image_info.keys(): print( key + ':' + str(image_info[key]) ) print( "\n" )
結果(だめでしたー)
APIの「 イメージ一覧を取得 」でチェックしてみると、「min_disk:50」となっています。
$ python list_image.py config.json container_format:ovf min_ram:0 updated_at:2016-11-02T01:13:15Z file:/v2/images/XXXXXXXXXX/file owner:YYYYYYYYYY id:XXXXXXXXXX size:35246112768 self:/v2/images/XXXXXXXXXX disk_format:qcow2 direct_url:file:///var/lib/glance/images/YYYYYYYYYY/XXXXXXXXXX app:ownCloud-8-64bit schema:/v2/schemas/image status:active tags:[] hw_qemu_guest_agent:yes visibility:private min_disk:50 instance_uuid:ZZZZZZZZZZ name:owncloud checksum:ed2798eb07530bc79aa073c6e26f6e76 display_order:280 protected:False os_type:lin created_at:2016-11-02T01:08:03Z
(他のバックアップ情報は割愛、IDの類はマスク)
同じAPIから取得できる、ConoHa提供の既存OSテンプレートは概ね「min_disk:20」、一部のみ「min_disk:50」となっているので、どうやらこれが、イメージをロードするVPSが最低限持つべきディスク容量のようです。
…ただ、メモリ512MBプランでディスク容量を「SSD 220GB」にしても表示できないので、微妙に別の問題が絡んでいそうな気もします。
あと何故か実測9GBしか使用していないOwnCloudフロントエンドを手動バックアップすると32.83GBになるので、どちらにしてもこのままではSSD 20GBにロードすることはできないのですが。
min_diskを20に出来れば、あとはsizeが20GB以下ならロードできそうな気もするのですが、APIを見る限りこの情報を書き換える機能は無い様子なので、まあ詰みましたかね、と。
後はAPI側のVPS構築機能でメモリ512MBプラン+min_disk:50 のイメージを指定した場合にどこかでチェックされているか否か、というポイントがあるのですが…さて。
現状このWebサイト等を公開運用している「さくらのVPS」は、OSがCentOS6.x系。そろそろCentOS7.xにしたい。あとリバースプロキシとかも一度再設定したいところ。
OS更新は面倒くさいし、どうせ6.xから7.xは色々変わるのでOS再インストールからやってしまいたいのだけど、いかんせんWebサイトを公開運用しているので長いこと止めるわけにもいかない。どこかに仮サーバーを設置しないと。
で、仮サーバーとして「さくらのVPS」を使うか「さくらのクラウド」を使うか、はたまた「ConoHa」に逃げるか。できれば同じさくらインターネット上のサービスを使ったほうが、仮移設時の問題が少ないように思う。「さくらのクラウド」にはVPSのイメージを元にクラウド側を構築する機能があるので、先ずこれで仮移設してしまえばよさげ。あとはDNS切り替えの問題とか。
問題は料金。
- 「さくらのVPS」は初期費用がそこそこかかる。現在と同一プランだと月額972円+初期費用1,620円(合計2,592円)
- 「さくらのクラウド」は初期費用は無いけど利用料金がそこそこかかる。VPSと同等で試算すると、14日利用で2,478円、月額3,132円…の筈。これ単一サーバー稼動の場合はネットワーク等のオプション要らなかったよな…?
- 参考までに「ConoHa」は初期費用なし、月額900円または時間あたり1.3円。14日利用だと1.3円×24時間×14日=436.8円。このはたんサイキョー。
なお「さくらのVPS」は現在「2週間無料お試し」があり、まあ今回用途だと2週間もあれば用は済むので「お試し」だと言い張れば無料で使うこともできる。が、お試しではないし色々お世話になっているところなので、きちんと支払いをしておきたい。
無料お試し期間中でも決済をすれば支払いはできる筈なのだけど、"お試し期間中であっても、会員メニューより「本登録(決済)」いただくと、すぐに本サービスを開始することができます。なお、すぐに本サービスを開始いただいた場合でも、2週間は無料でご利用いただけます。"とあり、これ決済して2週間以内に解約するとどうなるんだろう…的な疑問も。
また"さくらのVPSの最低利用期間は3ヶ月"なので、2週間程度の利用目的でも3ヶ月分費用が発生してしまう。3ヶ月+初期費用だと4,536円。これを考えると「さくらのクラウド」で1ヶ月利用したほうが良いか。
「さくらのVPS」をもう1台契約、新契約のほうに移設後DNS切り替え、旧契約を解約という方法もあるのだけど、現契約は年間契約にしているため次の更新は2017年5月末…。今解約するのはもったいない。
結論としては、「さくらのクラウド」を試しに使いつつ1ヶ月以内でVPS側を再セットアップ、というところかな。VPSをそこそこ長く使っているとこの手の問題は出て来る筈なので、何か便利なサービスがあっても良いと思う今日この頃。
ConoHaのownCloudとオブジェクトストレージでオンラインストレージを作る(前編)の続き。いよいよオブジェクトストレージと連結し、Windowsの同期バックアップストレージとして運用しますよ。
ownCloudのデータ保存領域をオブジェクトストレージにする
ownCloud のドキュメントに設定のサンプルがあります。ただ、一部項目の入れ替えが必要となりますので注意。
ConoHaオブジェクトストレージを契約する
- ConoHa管理画面の「オブジェクトストレージ設定」 を開く
- 「ディスク容量」バーの右端にある設定アイコンをクリック
- お好みでディスク容量をセット。最低100GBからなので、予め使う容量が分かっているのでなければ、とりま100GBでよろしいかと。容量セット後から課金スタートです。
ConoHaオブジェクトストレージのAPI情報を確認する
APIユーザーにパスワードを設定します。既にある場合はテナント名、パスワード、エンドポイントURLを確認。
- 左側グローバルメニューの上から7つめ「API」をクリック
- 「APIユーザー」の右側「+ユーザー」ボタンをクリック
- 適宜パスワードをセット。ConoHaアカウント自体、ownCloud管理者、ownCloud運用VPSのroot(権限を持つ)アカウント等とはパスワードを変えておいたほうがより安全かと思われ。
- パスワードの他、画面上段の「テナント情報」内「テナントID」と「エンドポイント」内「Identity Service」の情報も確認。
ownCloudにオブジェクトストレージの情報をセットする
/var/www/htmi/owncloud/config/config.php に以下の内容を追加します。’dboassword’等と同じ階層になるよう注意。
'objectstore' => array(
'class' => 'OC\\Files\\ObjectStore\\Swift',
'arguments' => array(
'username' => ←APIユーザー名
'password' => ←APIパスワード
'container' => 'owncloud', ←任意のコンテナ名(別途作成が必要)
'region' => ← Identity Service URLの identity と conoha.io の間にあるサブドメインを指定。認証情報の endpoints.region としても得られます
'url' => ← Identity Service のURL
'tenantId' => ←テナントIDをセット
'serviceName' => 'Object Storage Service' ←ConoHa APIのエンドポイント名
),
),
ハマった点としては tenantIdがありました。ownCloudのサンプルコードでは tenantName を使用しており、ConoHaのAPI情報にも「テナント名」があるのでてっきりコレかと思ったのですが、「テナントID」のほうを渡してやらないとConoHaの認証エンドポイントから他のエンドポイント一覧が提供されないという罠。しかも tenantName があると tenantId を書いてあっても無視される。…というのを ownCloud のソースコードを追いかけまわしてようやく見つけましたよ…。
ConoHaオブジェクトストレージにコンテナを作成する
コンテナは自動では作成されない模様。 autocreate オプションは true にしてみても反応しないし、ソースコード中には「テスト用」的なコメントがあったのでどこかで無効化されているんだろうな。ともあれ、仕方ないので node.js でコンテナ生成だけ実行するスクリプトを書きました。gistにテンプレートがありますので宜しければどうぞ(以下)。こちらでの注意としては、認証URL(AuthURL)にバージョン番号が入らない点があります。node.jsは v5.2.0-linux-x64 を使用していますが、ほぼ同一の JavaScript を他のサーバーでかなり前に入れた v0.12.7 で動かしていたりしますので、概ね動くかと思われ。しかし node.js のバージョン番号はよく分からん。なんで1年も経たないうちにこんなに上がるんだ。
Windows 7 との同期
できれば WebDAV でスマートにいきたいのですが、HTTPS にしないといけないようです(レジストリをいじればいけるっぽい)。後々ちゃんとしたSSL証明書を取得する方向でいきたいので、今回はひとまず ownCloudの公式デスクトップアプリを使うことにします。
- owncloud.org の ダウンロード画面 から「Desktop Clients」をクリック、Windows用インストーラをダウンロード
- さくさくとインストール(これといった選択肢もありませぬ)
- さくさくと起動すると、サーバーアドレスを入力する画面が現れますので、http://
/owncloud/ を入力(結局ここでもHTTPS問題が発生…致し方なし) - ユーザ名とパスワードを入力
- サーバー側の同期対象フォルダ、ローカル側の同期対象フォルダを選択
あとはローカル側に作成された同期フォルダにがつがつとモノを入れていけば同期されるようデス。
ファイルの行先を確認など。
本当にちゃんとConoHaオブジェクトストレージに収まっているんでしょうか…?
- owncloud をインストールした VPS の
/var/www/html/owncloud/data/administraotr/files/
にはファイルが作成されていません - ConoHaオブジェクトストレージのディスク使用量を確認すると、イイ感じに増加しております
ということで、まあオブジェクトストレージには収まったかな、と。次の疑問は、具体的にどういうオブジェクトになっているのか、とか、メタデータとかどうなんですかね?といった点ですが。
あと、HTTPSは早めに対応しないとなぁ…。
ConoHa VPSに標準で用意されているownCloudアプリケーションサーバーとConoHaオブジェクトストレージを組み合わせて、Windows PCから同期可能なオンラインストレージを作る試み。まずはowncloudを起動するまで。
[2015.12.10] 追記
後編 も書きました。
レシピ
- ConoHa VPS (ownCloudパッケージ)
- ConoHa オブジェクトストレージ
- ownCloudのリファレンス
- このはへの愛(ん?)
VPSとオブジェクトストレージを契約
- 清楚可愛いこのはちゃんと契約する
- 言語モードを「このは」にする(重要!)
- ConoHaチャージ(月額で最低金額1500円くらいかな)またはクレジットカードを登録する
- ConoHa VPSは次の仕様で組んでみた
- vCPU 1個
- メモリ1GB
- 東京リージョン
- イメージタイプは「アプリケーション」を選択(初期値)
- アプリケーションは「その他」から「ownCloud」を選択、バージョンは8-x64固定
- なお、ベースになっているOSは CentOS release 6.7 (Final) カーネルは 2.6.32-573.7.1.el6.x86_64 でした (2015.12.06現在)
- owncloud自体は 8.1.3 がinstalled、yumで 8.1.4 が来ていますね(後程アップデートしませぅ)
- rootパスワードをセット
- 自動バックアップはお好みで。今回はアプリケーションサーバーとしてのみ使用するので、変更した設定さえ別途保管しておけば全体バックアップは不要かも。
- ディスク容量は最低のSSD50GBで十分。これでも多いかも?
- インストール後の空き容量は / が 51GB割り当て、47GB空きなのでがら空き…
- 準備が整うまでは色々危ないので、取り敢えず接続許可ポートはすべてOff(コントロールパネルのブラウザコンソールで作業する)。なお、ここのポートはConoHa VPS外部のファイアウォールらしく、VPS側でSSHポートを22番以外にした場合は「すべて許可」一択となる。
- SSHキーはお好みで新規作成するなり、手持ちをセットするなり
- ネームタグもお好みで
あとは料金を確認して「追加」ボタンを押し、準備が整うまでこのはちゃんのお姿を堪能して待ちませぅ。
コンソールを開いてVPSの初期設定
- 左側「サーバー」から目的のサーバーを見つけ、ネームタグをクリック
- 「コンソール」アイコンをクリック(新しいWebブラウザ画面で仮想コンソールが開く)
- 画面が真っ暗ならEnterとか押してみる
- 作業アカウントを作る
- rootで作業すると失敗が致命的になるし、rootでのSSHログインは拒否しておきたいので、通常作業するための作業アカウントを作り、sudo権限を与える
- [注意!] ConoHaのコントロールパネルでセットした公開鍵は、rootアカウントに紐付けられています(/root/.ssh/authorized_keysに書き込まれる)。作業アカウントは別途キーを準備するなり、rootからキーを奪ってくるなりしましょう(rootのキーを移動した場合はパーミッションとオーナーに注意)。
- /etc/ssh/sshd_config を開いて編集
- 「Port 22」のコメントアウトを外し、22番以外の未使用ポートに変更 (ポート22狙いのアタッカーが回避できます)
- 「PermitRootLogin」を「no」に変更 (SSH経由でのrootログイン不可)
- /etc/sysconfig/iptables を開いて編集 (空だった)
-A INPUT -m state --state NEW -m tcp -p tcp --dport <SSH port> -j ACCEPT
を追記- (owncloudのWeb画面を開くために)
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
を追記 - あとはお好みで。基本的に全部 REJECT してホワイトリストのポートだけ ACCEPT すれば良いかと。
- この辺りのことは覚えたところで、どうせ CentOS 7になればfirewalldに代わって役に立たなくなりますよ… (今回firewalldを探して10分くらい彷徨った…)
- sshdとiptablesを(再)起動
$ sudo service sshd restart
$ sudo service iptables restart
- ConoHaのコントロールパネルの「ネットワーク情報」をプルダウンさせ、「接続許可ポート」で「すべて許可」を選択(以後、ポートアクセス制御はVPS側のiptablesに委任)
- お好みのターミナルエミュレーターから接続できることを確認 (以降はターミナルエミュレーターから作業)
- 念のため、rootでログインできないことも確認しませぅ
- さらに念のため、ConoHaコントロールパネルのWebブラウザコンソールからはrootでログインできることを確認しませぅ
- 適当なタイミングで
sudo yum upgrade
でも打って最新環境にするべし
ownCloudの設定
- コンソールにログインするとwelcomeメッセージとして URLやらMySQLのパスワードやらが表示されるので、URLにアクセスする。
- 管理者アカウントを作成する
- 試しに適当なファイルをアップロードしてみる
たぶん通常アカウントを作って、そっちで使ったほうが良い…いや所詮プライベートストレージだからこのままでもいいか…な?
なおアップロードしたファイルは /var/www/html/owncloud/data/<アカウント名>/files/ に収まる様子。 (/var/www/html/owncloud/data/ 以下はapacheユーザー/グループ管轄、otherにアクセス権無し)アカウント名>
残項目
- HTTPSアクセスにしたほうが良い気がするぞ
- ポートをガチガチに塞ぎ過ぎてメールアラートも出なくなってるので、必要なポートを開けたい
- ていうかちゃんとドメイン割り当ててメールサーバーも設定しておこう
- 本題であるWindowsとの同期とオブジェクトストレージの使用はどうした
[2015.12.08] 追記
yum upgrade したのち reboot してそのまま気持ちよく作業を終えたところ、数日経ってからアクセスしたら owncloud がメンテナンスモードに入ってしまっているという仕打ちが発生。モード解除自体は /var/www/html/owncloud/config/config.php 内の ’maintenance’ を false にすればOKだったのだけど、なんでメンテナンスになったんだ…。しかも画面には「owncloudを再起動すれば解除されます」とある割に、 httpd をリスタートしても何も変わらんかったし。
もしかして yum upgrade で owncloud 自体が 8.1.3 から 8.1.4 にアップデートされたので、このタイミングで自動的にメンテナンスモードになるんですかね…?
あと数日放置してたら、案の定 httpd にアタッカーの皆さんからご訪問を受けておりました。幸い突破された様子は無かったけど、一度アクセス範囲を見直したほうが良さげ。
[2015.12.10] 追記
後編 に続く…!