> ## Content Index > Fetch the complete content index at: https://kwmr.ghost.io/llms.txt > Use this file to discover other available public pages before exploring further. # Cloud n を利用したBlogzineのArchive - URL: https://kwmr.ghost.io/2014/06/08/blogzinenoarchive/ - Published: 2014-06-08T02:12:28.000Z - Updated: 2018-08-21T13:32:52.000Z - Author: AKira Kawamura - Tags: #redirect, #blogzine, #archive, Blog, #Blogzine ![main-image](https://storage.ghost.io/c/92/e2/92e20a9b-f588-4641-9b97-2143a3728e37/content/images/2014/Jun/cloudn.png) ずっとそのままにしておこうと考えていたブログ人のコンテンツだけど、先日のサービス停止の発表で引っ越し先を考えなければならなくなった。 できるだけそのままの形で移行したかったので、静的コンテンツとしてダウンロードして、それをs3とかのオブジェクトストレージサービスにアップ、Webサイトとして利用するという方法を試してみた。 ドメインは今のkwmr.meのサブドメイン、blogzine.kwmr.meを使うことにした。[s3だと静的なWebサイトを作ることが売り](http://docs.aws.amazon.com/ja%5Fjp/AmazonS3/latest/dev/WebsiteHosting.html?ref=kwmr.ghost.io)にもなっていて、比較的簡単に出来てしまうのだけど、通信量で従量課金というのがネック。今回は通信量による課金のない[国産パブリッククラウドサービス Cloudn](http://www.ntt.com/cloudn/?ref=kwmr.ghost.io)の[オブジェクトストレージ](http://www.ntt.com/cloudn/data/storage.html?ref=kwmr.ghost.io)でトライした。:p ![](https://storage.ghost.io/c/92/e2/92e20a9b-f588-4641-9b97-2143a3728e37/content/images/2014/Jun/Strage-1.png) #####以下、手順のメモ。 #### Step 1\. ドメインの用意とコンテンツのダウンロード Blogzineを新ドメイン：blogzine.kwmr.meにドメインマッピングすることで、旧URLからblogzine.kwmr.meを指すようにして、再構築する。 再構築したらwgetを使ってブログをダウンロード。 `wget -rk [http://kwmr.blogzine.jp](http://kwmr.blogzine.jp/?ref=kwmr.ghost.io)` （OSXにはwgetがないのでHomebrewとかでインストールすること） 再帰的にかつ絶対アドレスを相対アドレスに変えるとか、Wgetはいろいろ便利。これで、カレントディレクトリにblogzine.kwmr.meの静的コンテンツがダウンロードできて準備が整った。（リンク先とか問題があればテキストエディタなどで修正） #### Step 2\. オブジェクトストレージの用意 ダウンロードしたコンテンツをツール等でオブジェクトストレージサービスへアップロードする。 アップロードのツールはFreeで高機能なクラウドストレージクライアント[DragonDisk](http://www.dragondisk.com/?ref=kwmr.ghost.io)を使った。このツールは、Win/OSX/Linux（ubunt,debianのパッケージあり）のマルチプラットフォームで動作し、ファイル操作全般、一括でパーミションを変える機能（要はAWS-APIでできること）なども具備しているところが◎。CloudnはAWS互換なのでdragondiskのようなエンドポイントが修正出来るツールであれば自己責任で利用はできる。 !\[\](/content/images/2014/Jun/DragonDisk\_1\_05.png) File-AccountでProviderに Other S3 compatible service を選びServiceEndpointにCloudnオブジェクトストレージのエンドポイント"str.cloudn-service.com"、アクセスキー、シークレットキーを設定してCloudn に接続する。 接続後、バケツを作る。オブジェクトストレージのバケツ名は、後からのドメインマッピングでうまく動作するように紐付けるドメイン：blogzine.kwmr.meにしておくこと。（**ここ要注意**） #### Step3\. パーミッション設定とアップロード 次にバケツの公開設定と各ファイルのパーミッションを公開に設定する。DragonDiskはパーミション設定もクライアントから行えるのがいいところだ。 環境設定-Option-Operationの inherit permissions from parent folder にチェックしておくとパーミッションは親ディレクトリに合わせて設定してくれる。パーミッションを公開に設定し、ダウンロードしたコンテンツをCloudn側にアップロードする。 設定後にブラウザから [http://blogzine.kwmr.me.str.cloudn-service.com/index.html](http://blogzine.kwmr.me.str.cloudn-service.com/index.html?ref=kwmr.ghost.io) にアクセスして表示されるか、確認した。OK! ここで、問題が発覚した。Cloudnの場合、Apachのようにindex.htmlを省略したような場合、システム側がそれを補完してくれないのだ。省略すると４０４エラーとなる。 いろいろ考えて、[Cloudflare](http://cloudflare.com/?ref=kwmr.ghost.io)というパーソナルCDNサービスを使うことで問題解決した。 !\[\](/content/images/2014/Jun/CloudFlare.png) CloudflareにはCDNの他にDNSと特定のページ（ワイルドカードが使える）のアクセスにルール（条件）を設定し飛び先を変えるという機能があって、それをうまく使うことでindex.htmlを補完できた。設定したルールは ` blogzine.kwmr.me/*/ -> blogzine.kwmr.me/$1/index.html blogzine.kwmr.me/ -> blogzine.kwmr.me/index.html ` Cloudflareは、キャッシュによる高速表示はもちろん、その他にDNSを細かく設定したり、GoogleAnalyticsなどの設定をキャッシュ経由でワンタッチで行え、なにより無料で使えることが最大の利点だ。 そのDNS設定を利用してblogzine.kwmr.meの振り先を上記アドレスに変更、ドメインの浸透を待つ。 #### Step4．リダイレクトとおまじない 最後に旧ブログ人側のコンテンツから新サイト側にリダイレクトさせるためにmetaタグを全コンテンツに挿入する。本来であれば301でリダイレクトさせたいのだがブログ人ではその機能を具備していないので、Head部分にゼロ秒リダイレクトさせるコードを加え、合わせてSEO対策のための重複コンテンツの設定（rel="canonical"）も行っておく。ジャンププランなのでMTタグを使ってコンテンツ毎に飛び先を細かく設定できた。 `＜meta http-equiv="refresh" content="0;URL=http://blogzine.kwmr.me/hogehoge.html＞ ＜link rel=”canonical href=”[http://blogzine.kwmr.me/hogehoge.html＞](http://blogzine.kwmr.me/hogehoge.html%EF%BC%9E?ref=kwmr.ghost.io)` ジャンププラン以外では残念ながら重複コンテンツの設定などの細かい設定はできないがリダイレクトのみであればブログのサブタイトル欄にタグを仕込むという荒技でリダイレクトだけは出来る。 これでおおまかな作業は終了。URLが浸透されたらドメインマッピングの設定を有効化して旧アドレスでも新アドレスにリダイレクトされることを確認。 ということで、**GHOST\_URL**/ のサイドバーにBlogzineアーカイブを設定した。これでブログ人が終了するまでは、旧アドレスから新アドレスにリダイレクト処理がなされるはず。 #### ああ、疲れた... にしても...このあたりの処理は終了するサービス側で簡単にできるようにしてもらいたいなぁ。10年間利用してきたドメインを廃止されるユーザーへの配慮をもう少し真剣にやっていただきたい。指定された推奨ブログのみしか、リダイレクトを許さないとかいまいち。狭量に過ぎるだろう...。 サービスの廃止に当たっては、この辺りの配慮を何処まで出来るかにその成功がかかっていると、ブランドの価値を如何に下げないようにするのが大切か...なんて書いても伝わらない、あるいは理解できないかも知れないけどなぁ...うーむ。