ライブサイトを壊すことなく自分のWebサイトに安全に変更を加えることができるように、Linux開発環境をセットアップしようとしています。
Linodeは私のライブサイトをホストしています。簡単な解決策は、開発サーバーをLinodeでホストすることですが、ホスティングコストが2倍になるのは避けたいと思います。
私が見る最も安価な方法は、WindowsワークステーションでVagrantを使用して開発環境をホストすることです。
バックアップをVagrantに復元してVMを再起動しようとすると、VagrantホストにSSH接続できなくなります。
バックアップを復元することで、特別なVagrant構成を上書きしたためと思われますが、それを回避する方法がわかりません。
このアプローチを機能させるにはどうすればよいですか?私のアプローチが根本的に間違っている場合、別の方法を提案できますか?
Linodeでは、これらのコマンドを使用して、バックアップに含めるべきではないものを無視しながら、ファイルシステム全体の圧縮コピーを作成しました。
$ Sudo rsync -ahvz --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/backup/*} /* /backup/2
$ Sudo tar -czf /backup/2.gz /backup/2
これが2番目のバックアップであるため、バックアップファイルは2.gz
と呼ばれます。最初のバックアップは1.gz
と呼ばれます。
WinSCPを使用してバックアップファイルをWindowsワークステーションにコピーします。
Linodeオペレーティングシステム(Ubuntu 12.04.3 LTS、カーネル3.9.3)に一致するVagrantボックスが必要です。 vagrantbox.es からクローゼットのマッチを選択しました:
buntu Server Precise 12.04.3 AMD64
カーネルはDockerの準備ができています(Dockerは含まれていません)
私のワークステーションで、次のコマンドを実行してボックスを追加し、インスタンスを初期化して起動しました。
$ vagrant box add ubuntu-precise http://nitron-vagrant.s3-website-us-east-1.amazonaws.com/vagrant_ubuntu_12.04.3_AMD64_virtualbox.box
$ mkdir linode-test
$ cd linode-test
$ vagrant init ubuntu-precise
$ vagrant up
これで、Vagrantはポート2222でSSHを使用するマシンを実行しています。
オペレーティングシステムのバージョンは同じです。カーネルバージョンは3.8.0です。十分に近い音。
WinSCPを使用して、バックアップファイル2.gz
をVagrantボックスの/home/vagrant/2.gz
にコピーしました。
PuTTYを使用して、ssh経由で新しいVagrantボックスに接続しました。
ボックスで、バックアップをファイルシステムルートに移動します。
$ Sudo mv 2.gz /
アーカイブをファイルシステムルートに抽出します。
$ Sudo tar -xvpz -f 2.gz -C / --strip-components=2
(アーカイブ内のすべてのファイルにプレフィックスbackup/2/
が付いているため、ストリップコンポーネントを使用する必要があることがわかりました。次のバックアップでこれを修正します。)
Tarコマンドが完了したら、箱から出してログアウトします。
もう一度ログインしようとすると、パスワードを使用してvagrantとしてログインできなくなります。
ライブLinodeのユーザーであるiainとしてパスワードを使用してログインできます。ライブのLinodeでパスワード認証を無効にしたので、それは私を驚かせました。変更を有効にするには、sshサービスを再起動する必要があると考えました。
Sshだけを再起動する代わりに、システム全体を再起動することにしました。
今はログイン画面にも行けません。接続しようとすると、PuTTYから「接続が拒否されました」と表示されます。
何が悪かったのか?
これ以上vagrantとしてログインできなかった理由は、 shadow を含む/ etcをバックアップしたためです。 linodeのシャドウファイルにはvagrantユーザーのエントリが含まれていないため、その資格情報でログインすることはできません。資格情報は/ etc/shadowファイルにあるため、linodeユーザーを使用してログインできますが、sshデーモンはすべてのユーザーにパスワード認証を許可するデフォルト設定を使用していました。すべて問題がなければ、sshサービスをリロードして、新しい構成(バックアップからパスワード認証を無効にする構成)を取得することができます。
ただし、復元中に問題が発生した可能性があります。提供された情報から、私は何についての推測しかできません、そして私はそれを避けたいです。ただし、vagrantボックスをシャットダウンした状態でvirtualbox管理ウィンドウを開くと、仮想マシンを正常に起動できます。これにより、コンソールに表示されるエラーを確認できます。エラーが存在しない場合は、少なくとも(SSHではなく)コンソールを使用してログインできます。通常のアカウントを使用してアクセスを取得し、周りを見回して何が問題なのかを確認できます。/var/logの何かが、正しい方向を示します(おそらく/ var/log/syslog)。
少し調整すれば、ほとんどの場合はうまくいくアプローチが得られるでしょうが、まったく別のアプローチをお勧めします。
ライブサーバーと開発サーバーの一般的な構成を同期させるには、puppetを使用してデプロイするか、非常に注意してください。 Webコードとアップロードされたファイルを同期するために、rsyncはOKです。何を含めるかを定義し、それを狭くしてください。システム全体ではなく、アプリのみ。 rsyncを使用するのではなく、gitまたは別のリビジョン管理システムを使用することをお勧めします。 devからの変更をチェックインしてから、ライブにチェックアウトします。どこかで、継続的デプロイシステムを使用してこれを自動化できます。
データベースのコンテンツを同期する方法もおそらく必要になります。 mysqlがデータを保存するファイルをコピーすることだけを期待しないでください。ただし、実行中にデータベースエンジンを両端で停止する準備ができている場合、またはファイルシステムレベルで何らかのスナップショットメカニズムを使用している場合を除きます(たとえば、 LVM)。
ライブから開発へのデータ更新の同期をバックアップシステムと組み合わせることができます。つまり、ライブのバックアップを取り、それらをdevにリカバリします。これは、バックアップを常に検証しているので便利ですが、毎日バックアップしている場合は、昨日のバックアップの回復が不便なほど古い場合があります。
多分そのやり過ぎ。たぶん今より少し多い気がします。少なくとも、モデルを時間の経過とともに移動するものとして理解してください。