#contents *cron 空白時間帯 [#qe9b0a58] JavaがDNS固定なので0分以後に作業してDNS切り替えを確認すること! 実質土日00から15分の間しかできぬ!23時以降ならとまっているので00分にこだわらんでもOK |0,20,40|道路情報(HPの更新は05,20,45なのでずらし検討)| |0,15,30,45|道路情報jpeg| |0,15,30,45|株式情報5時に終了して7時に開始。更新間隔は10分未満・・| |0,30|鉄道情報。4-23まで| |毎時20分|空室情報、10-24まで| |13:30|スキーエリア情報| 結論毎時00-15か45-00までが一番あいている時間帯。 土日であれば40分でも作業可能。 jpegも20分単位にできないか見直す。 Azureの書き込みがある場合は、そろそろ15分ではきつくなって来た。 Azure同士だと30分は必要で段階移行必須。 *Ansible移行手順 [#w1b04009] -さくらの場合はsecureタスク実施後、PermitRootLogin noをyesに変更する必要がある。 +secure +setup +apps(maven以外はなくてもOK) +myapps +cron +移行元でS3へバックアップ +recover +migrate(間に合わなかった場合個別DB移行) -起動確認を忘れて取り逃がしが過去頻発しているので注意。 **移行元手作業(なくしたいが、今のところレアなので) [#c387e053] -wordpressの接続先を新サーバーに -toolsはいったんそのまま(cronもあるので) **移行先手作業 [#h86d09ae] -toolsを旧サーバーに向ける(デフォルトをリモートへ) -移行後にlocalhostに戻す。 **移行定番作業 時間差DB移行 [#q35ac8bc] ansible taskにしたのでそちらを利用せよ。DBを指定して一度にexportとimportを実施できる。 ***移行元 [#zebebcb5] mysqldump -u root -p cakephp | gzip > cakephp.sql.gz scp cakephp.sql.gz NEW_SERVER:/var/tmp ***移行先 [#z9bddd45] drop database cakephp create database cakephp default charset utf8; mysql -u root -p cakephp < /var/tmp/rooms.sql ***アプリの接続先をlocalhostに変更する [#h5a7eb6f] **移行に必要な時間 [#n044da8d] azureは移行元でも時間がかかるし、移行先にしても時間がかかる。(体感ではSakuraVPSの5倍!)azure同士の移行だとまず15分に収まらないので注意。 (db+svnのインポートで12分で時間オーバー!エクスポートも5分は見ておく!) *残作業 [#u6ec7302] -KAGOYA不正アクセスログをスナップショットから復元 -Jarticをいい加減バックアップとAnsible化 -その他必要なものバックアップして4月後半までにsakuraリニューアルさせたい。 *2012/04 [#yb2216ef] さくらのVPS512から1Gへ移行。 **スケジュール [#od6163e2] -2012/04/04 apacheコンテンツ移行。DBインポート完了。設定まだ。wiki.rutake.com移行完了 -2012/04/05 DB設定完了。cakephp,blog.rutake.com移行完了 -2012/04/09 SVN移行完了。SSLはIP指定をしているのでそこを変えないといけなかった。 -2012/04/11 Cronジョブ移行。バックアップでDBパスワードが変わっていたためそれなりにシェルを変更 **トラブル [#rfb3a05e] -PostgreSQLのEUC_JPのDBを作成するときにそのままだとエラーが出るようになった。-T template1で回避 -PostgreSQLの仕様変更により、date型をsubstrする場合は明示的にtext型にする必要が生じた。substr(userdate::text,4,3) -MySQLの全部のデータを移行したが、ユーザ認証のみできない。コマンドラインから権限変更もできない状態だったので、phpMyAdminから該当ユーザ削除→追加で復旧。後日flush privilegesでOKということが判明 *2013/07 自宅内サーバー移行 [#r60f5665] 一か月かけて準備。普段からrsyncでデータの同期はとっていた。 **トラブル [#x95ab77f] IP変えて再起動したら反応せず。コンソールから復旧させたが、原因不明だった。 ファイヤーウォールでSquidのポートを通していなかった。こちら設定漏れが多いので注意。Sambaのユーザー移行漏れ! *2013/12 さくらVPS再構築 [#z9c8448e] **下準備 [#j9750ef5] まずは、それほどアクセスのないページや自分専用コンテンツなどを自作サーバーに移行する。基本的にhttpd.confとssl.confを持ってきて、SVNのアクセス制限元を変更するぐらいで動いた。ssl.conf持ってこないとSSLに強制接続になるので今後の課題。 **移行対象 [#g835d28e] +tools.rutake.com以下のアプリ +wiki.rutake.com **要塞化 [#sa5fcb6d] -SSHDのアクセス元制限。ポートを閉じる。 **tools.rutake.comのpostgres移行 [#c056dfdb] +postgres自動起動の設定 +DBインポート(DB作成必要) +PHPツール移植(ツールは問題なしだが、DB接続で下記問題発覚) -トラブル発生 psql: FATAL: Ident authentication failed for user "postgres" SQLSTATE[08006] [7] FATAL: Ident authentication failed for user "postgres" -pg_hda.confを下記のように編集し再起動。ローカルからのUNIX接続をOKにした。 # "local" is for Unix domain socket connections only local all all trust -PHPからの接続は元の設定をコメントアウトし、パスワード認証をかけるようにした。 #host all all 127.0.0.1/32 ident sameuser host all all 127.0.0.1/32 md5 -12/4 toolsのpostgres部分移行完了(一部svn登録モレモジュールがあり消滅・・・) -CakePHPをTools配下へ移植 2.4にしてみた。いつものようにhttpd.confの設定が必要。 appのみSVNからコピーして無事接続成功 DB単位でエクスポート mysqldump -u root -p MYDATABASE > /var/tmp/MYDATABASEdmp.sql 移行元のDBを消す。 [root@epox cake2.4]# mysqladmin -u root -p drop MYDATABASE 空のDBを作成 mysql> create database MYDATABASE default charset utf8; インポート mysql -u root -p MYDATABASE < MYDATABASEdmp.sql -12/5 cakephpのツールを移行完了。残る大物はblogのみ -12/7 バックアップを実施だが、mysqlがパスワードなしでバックアップできている理由が不明。コマンドラインにもろ記載が後日判明 -12/30 blogの移行テスト。DB移動とblog以下一括移動が一番楽とのことでそれで実施。コンテンツ領域20MとDBが2M 目的のディレクトリの一階層上に移動 cd /var/www/UPPER_DIR tar cvzf blog.tar.gz blog/ DBも同じようにバックアップして圧縮しておく(18Mが十分の一に) 受け取りサーバー側では同じく一階層上で解凍 DBもインポートしておく 空のDBを作成(utf-8でOK) mysql> create database MYDATABASE default charset utf8; インポート mysql -u root -p MYDATABASE < MYDATABASEdmp.sql -12/31 空室情報取得バッチの移植に苦労。理由は<?phpを入れてなくてバッチ実行クラスが見つからないというなんとも初歩的なもの。翌日に移植完了とhtml形式の違いで取得できなかったものにも対応。 -1/1 テーブル移行 移行元 mysqldump -u root -p --add-drop-table cakephp rooms > rooms.sql gzip rooms.sql 移行先 gzip -d rooms.sql.gz mysql -u root -p cakephp < /var/tmp/rooms.sql -1/1 httpdのカウントテーブル作成 mysql> CREATE TABLE httpd_count ( -> recorded DATETIME not null, -> httpd_count int unsigned not null -> ); mysql> LOAD DATA LOCAL INFILE '/var/log/httpd_count.log' INTO TABLE httpd_count FIELDS TERMINATED BY ','; -1/6 svn移行 svnadmin dump /home/svn/repos | gzip > /var/tmp/myrepos.tar.gz -1/6 夜移行 サーバー再インストールからコンソール上がりきるまで10分は見ておいたほうがよい。DNSがなかなか切替わらず見切り発車で実施。SSLの秘密鍵のバックアップを忘れてSSL月だと起動失敗したのでSSLは後日。blogとwikiは移行完了。cronの改行コードがおかしくてエラーとなっていた。LFじゃないとNG -1/16 セキュリティ設定 SVN移行,hosts設定, -1/17 IP設定 210.148.59.13,serverToken除去,php.iniの設定変更など *移行漏れ [#z9bb5946] SSL証明書,.htpasswd *移行前の下準備 [#a93e7d30] +公開鍵のバックアップ(OK) +blog関係バックアップ +cron関係チェック(OK) +yumの履歴(OK) +SVNバックアップ(OK) -2/4 UTF-8移行 createdb homedb_uft -E UTF-8 -T template0 ダンプSQLをUTF-8に変換 SET client_encoding = 'UTF-8'; -4/19 cakephp戻し データベース移行は順調。 シンボリックリンクを介してのリライトはNGのようなのでディレクトリ名変更 DBアクセス。ユーザーを追加していなくてアクセス失敗。 simple_dom_htmlライブラリを入れてなくて失敗 -6/02 pukiwiki更新検討 *2015/04 攻撃を受けてセキュリティ強化とアプリケーション分離と作り直し [#jf9aea84] **基本方針 [#w97e0c01] 内部向けは自宅サーバーにおいておくか? wikiはアクセス数が減少しているのでどうする? 旧MTのコンテンツを廃止したい。 **対象 [#ff1e215a] **作業手順 [#da913c76] **トラブル [#y09767b6] *2015/11 一部アプリケーション分離 [#r71a0eb0] **移行スケジュール [#c2a9a26b] |11/17-12/07|KAGOYA VSPでCentOS7検証。wiki| |12/07-|Azureにてより自動構築重視の設定。wiki,postgresqlのtools| **全体計画 [#jba4e101] |項目|計画日|実施日|備考| |wiki|11/16|11/16|| |S3バックアップ|11/16|11/17|バックアップスクリプト修正| |toolsアプリのみ|11/17|11/17|cake2.6で動かしてみる。.htacessではまった| |バッチをローカルDBにて動かす|11/17|11/17|すんなり動いた。| |cake2.6プロビジョニング|11/18|11/19|ちょいと後回しで、無事成功。| |cronプロビジョニング|11/18|11/18|ansible化するが、cronファイルを復元するのでもよいかも| |postgresリモート接続にて、tftool移植|11/18|11/18|postgresql.conf,hg_hda.conf,iptables,postgresユーザー以外での接続に変更など結構大変だったがphpモジュールは普通に動いた| |postgres移植|11/20|11/20|ローカルから接続させる| |postgresバックアップansible化|11/20|11/20|ローカルから接続させる| |CentOS7 iptables化|11/25||ほんとはfirewalldにしたいが、共存させたいので!| |Azureに舞台を移し,postgresアプリAnsible化|12/05|12/05|OK| |postgre設定をAnsible化|12/07|12/07|ローカル接続はOK!| |IP更新できない理由を突き止める|12/07||publicipは取得できている| |S3バックアップジョブ分離|12/16|12/18|credential周りでcron経由だとトラブルあり!| |svn移行|12/26|12/25|ほぼ自動で行けた。svnだけ証明書があるので手動となる。| |tools移行|12/25|12/25|MySQLと管理ツールは残して、postgresは完全移行| |Kagoyaのcron|12/26|12/28|なぜか動かなかったがいろいろインストールしてたら動くようになった。cronie-noanacronかな?| |cakephp DB完全移行|01/09|01/09|DB単位の移行が思いのほか簡単だったので一気に作り込みしてbatchはリモートを見るようにしてみた。| |cakephp バッチ部分移行|01/10|01/10|SNOW,ROOM,TRAIN,ROADを早朝移行。STOCKは午後までに移行。起動スクリプトコミット漏れ発覚で注意| |Azure移行プロジェクトII|01/18|01/27|fail2banをキチンと運用したいのでKAGOYAからazureへまたしても再構築。クレジットの残りを待って27日wiki,postgres移行が。バックアップ取得わすれで手作業多く、wikiが動かず失敗。SELinuxのせいであると判明。設定ファイルを焦って変更したため、再起動したらつながらず!| |Azure移行プロジェクトIII|01/28|01/28|A1のインスタンスで大丈夫だったが、A2にスケールアップしたところCustomLogの設定でエラー再発。バージョンも一緒なのに!謎なので作り直してwikiとpostgres移行。| |Azure移行プロジェクト|01/29|01/29|A2インスタンスにて。cakephpのDBのみとcronも次々移行。blogの試験開始からついにblogまで移植完了!初の全部移植。以前のCentOS6のときには見られなかったPHPつまりが発生。その後料金懸念が発生し約10日で料金切れ懸念。即時出ていくプランに変更| |Kagoya移行プロジェクト|02/05|02/05|AzureはIOが遅い。ansibleの早さがKagoyaだと段違いなので戻る。rsyslogをインストールしないとsecureやmessageが出ない。本来は週明け予定だが、6日で2500円近く食いつぶしたazureが週末をこせないと判断で夜30分でblog,cron含め全移行。6日夜停止でA2は一日約400円!| |Kagoya SSDプラン移行プロジェクト|02/10|02/10|前日にSSDプラン登場なので、スナップショット(約10分)を取って衝動的に朝の通勤時間で移行。しかし手順が行き当たりばったりで時間足りず駅のホームで完了。空白時間は9:25から10:00の間。スナップショット作成と起動をすぐに行えば45から00までの間にぎりぎり間に合う| |Azure移行プロジェクト|03/08|03/10|Vhostを変更忘れでwikiでリダイレクトループ発生かつCloudFrontにキャッシュさせるミス。wiki,tools,postgres,svnを一気に移行して、MySQLとBlogは後日。3/14からSubcriptionは4/7に尽きる予定だが、実測したところ30日まででもっと早いだろう!二週間と考えておく。3月中に戻す予定。StaticPressインストール後にサブディレクトリが見えなくなる障害発生。3/16早朝から3/18まで停止してた!!| |Kagoya移行&新AWS完全移行|03/10|03/31|3/26日に実施。やはりVHOST切り替えミスでリダイレクトループ発生!| |Sakura CentOS7にて復帰|04/03|04/10|CentOS7でリビルド。minimalにしておけばほぼkagoyaと一緒で構築OK。MySQLだけ後日移行のつもりがローカルを見る設定にしており、自動化必須。自動化仕上げて予定より早く4/4中に完全移行完了| |Kagoya 移行|04/28|4/30|セットアップを済ませて、recoverタスクで一気に切り替える計画。Ansibleがインストール失敗!15分ではギリだがトラブルなければ45分前にsetup終えておき、旧サーバーバックアップのリカバリーで余裕持っていける。すべて立ち上げると1.4Gで落ち着く。すべて落とすと100M程度| |Azure A2 移行|05/06|05/07|EPELのansibleがsvn checkout後にこけるバグあり。前日セットアップ後にwwwを午後一移行。それ以外は40分から作業着手だが、mysql-php/dstatのインストール漏れ、ESの許可IP漏れ、またしてもリダイレクトループキャッシュなどミスが目立つ。IOは相変わらず遅いがメモリは随一なので、ElasticSearch同居しても問題なし!月替わりの計算だと1000円以上残して1ヶ月持つがこれはあてにならん!| |Sakura 移行|05/31|05/31|残り800円であったので急遽前倒し実施。SELinux無効化忘れでSVNチェックアウトできなかったり、バックアップ削ったらディレクトリも削ったり、postgresが復元されなかったり障害レベルのミス頻発。電車降りそびれるし散々である。そして5/7の移行時にアメリカ証券のみcronされていなかった。ansibleは記載済みなのになぜ?おそらくコメントが一緒だったため。さらにはasiaがajiaとなっておりロスト!| |Azure 移行|06/30|06/30|完全MySQL移行完了。課金切れが怖いのでA1でスタート。前日準備の当日22時45分から着手だが、スクリプト修正やらアクセス元許可再起動忘れなどで21時からやり直し。それでもcakephpの解凍失敗(直実行だと問題なし)とsvnチェックアウトの失敗(日本語ディレクトリ関連)で時間間に合わず差分移行| |Sakura to Azure 移行|10/27|10/27|思い立って即日実施。トラブルなしだが、Azureへのインポートが10分以上かかるのでひやひや。ミスなしかと思いきやcron解除し忘れでまたしてもロスト&実行時間UTC問題解消されず| |Azure to Sakura 移行|11/20|11/25|CentOS7が標準OSとして追加されたのを発見したので旅先でansible確認して、後日夜のファミレスで実施。10分で終わったがLIFE PW更新忘れとCloudFrontがおかしいことになっていたので次回以降はキャッシュクリア必須| |Sakura to Azure A2 移行|12/08|12/10|デフォルトのVirtualHostのリダイレクトの設定がまずかったようだ。二回もキャッシュクリア。移行は13分で終わったが途中で切れやがった!| |Azure A1 to A1 移行|12/19|12/20|MariaDBが落ちたのとFirewalldが止まっていた期間があったため、今回は段階移行の練習。エクスポートインポート20分でDB段階移行5分。またjavaパスとクラウドフロントリダイレクトループミスあり| |Sakura 移行|2017/01/15|01/15|思い立ったら1時間で実施!| |Aaure A2移行|2017/02/06|02/06|事前にセットアップまで終えておき、一気に切り替え移行元がSakuraだと余裕| **Ansible状況 [#wdd67cec] |CentOS 6 さくらのVPS|セットアップ完了。DBの移行断念| |CentOS 6 nagoya VPS|セットアップ完了。DBの移行断念| |Azure OpenLogic CentOS 7.1|セットアップ完了。移行も完了| |Azure OpenLogic CentOS 7.2|セットアップ完了。Sonhrqube以外OK| |さくら CentOS 7.2|セットアップ完了。セットアップタスクが5分程度(ほか14-15分)で終わるので、一番早い!| |KAGOYA CentOS 7.0|セットアップ完了。TybeBだとセットアップ5分、リカバー2分で終わる| ***チェックリスト [#zee56420] +認証周りがキチンとされているか?(管理画面に入ること) +旧コンテンツ(blog/techmemo)やwikiのリダイレクトが完璧であること。 +アクセス制限が移行されていること ***postgresのユーザーに権限付与(シーケンスリード権限がなかった) [#tb2938a8] GRANT ALL ON テーブル名 TO ユーザー名; GRANT ALL ON シーケンス名 TO ユーザー名; ***cron移行周りのはまり(現在進行中) [#m7a684ef] -ntpdateが見えない フルパスに変更 -さくらでaws configureの内容が見えてない。翌日cron経由だと動かなくて発覚。 →単なる設定ミス。 aws s3 lsで設定の確認をすること -未解決 /etc/cron.daily/s3_backup.shがさくらだけ上記のエラーがでる。 5分ごとに実行だとでないのに! *wordpressのサブディレクトリからサブドメインへ移行 [#r1f14d3d] +http://blog.shun-ichiro.com/howto/move-wordpress/ *各VPSの特徴 [#befc41ca] **さくらのVPS [#k08a6438] カスタムOSを入れるときはChromeじゃないと操作できない致命的な欠点はあるが、性能は一番安定している。スナップショットが取れないのがいまどき時代遅れ感。 **Azure [#ea0ee128] IOが遅い。あとOpenLogicのCentOS7.1を使っているが、それ以外に変えると不具合出たりしてこまったもんだ。 **Kagoya VPS [#f3efa16c] 最初は何も入ってなくて苦労したけれども、ノウハウをためていくうちにAzureよりセットアップが早いので利用しまくり。スナップショット機能がお気に入りだ。 ただし保証メモリが1Gなのでメモリ不足は一番陥りやすい。 #counter