Cloud9のワークスペースをEC2に作って爆速開発環境構築
Cloud9のワークスペースをEC2に作って爆速開発環境構築
Cloud9がAmazonに買収されて早数ヶ月。もう少しするとEC2専用のサービスが登場しそうですね。 現状のままでも、Cloud9とEC2を連携して、かなりシームレスな開発ワークフローが構築できますので、参考までにご紹介します。
前提条件
EC2インスタンス
SSHで接続できるインスタンスを用意します。今回はJetwareアプライアンス「Optimized LAMP Stack PHP 5.6」(Amazon Linuxベース)で起動したLAMP環境のインスタンスを使います。Jetwareアプライアンスを使ったインスタンスの作成方法に関しては、以下の記事をご参照ください。
・JETWAREでラクラクLAMP環境構築(AWS&ローカルPC)
cloud9のアカウント
Cloud9のアカウントが必要です。そして、これが肝かつこの話の全てなのですが、Individual以上のプランの購入($19/month)が必要です。 そうです。快適な環境を得るには、相応の対価を払う必要があるということです。。。
ですが、チームで使う場合は、1つのアカウントだけ購入していればOKです。Cloud9にはコラボレート機能があるので、メンバーアカウントを招待することで、他のメンバーも恩恵に預かれます。 そう考えると結構お得だと思います。AWS案件のサーバ運用費として$19/monthを追加計上してもらうよう、ぜひ決裁者に上申してみてください。
ここからはIndividualアカウントにアップグレードした前提で、話を進めます。
EC2インスタンスに公開鍵を追加
Cloud9からSSH接続を許可するため、公開鍵を追加します。 まずは、Cloud9のメニューから「Account Settings」を選択し、設定画面に遷移します。
メニュー「SSH Keys」の中にある公開鍵をコピーして、EC2インスタンス側のユーザの~/.ssh/authorized_keysファイルに追加(なければ新規作成)します。Terminalで接続して、お好みのエディタを利用してください。ここではviを使って編集します。
$ vi ~/.ssh/authorized_keys
viで開いたら、「o」キーを押してAppendモードにしてから「⌘+v」で貼り付けます。貼り付けが完了したら「ZZ(大文字)」で保存終了。
これで、Cloud9から接続する準備ができました。
必要パッケージのインストール
今回利用したAMI「Optimized LAMP Stack PHP 5.6」(Amazon Linuxベース)だと、node.js(0.6.16以降)やglibc-staticなどのパッケージを追加インストールする必要がありましたので、yumでインストールしておきます。
$ sudo yum install epel-release $ sudo yum install nodejs npm --enablerepo=epel
$ sudo yum install glibc-static
これらのパッケージがインストールされていない場合は、このあとの手順で、/usr/bin/nodeが見つからない、cursesが見つからない等のエラーがでて、ワークスペースの作成が失敗しますので、ご注意ください。
ワークスペース作成
Cloud9にログインして、ダッシュボードからワークスペースを作成します。「Creat a new workspace」をクリック。
画面中段のタブから「Remote SSH workspace」を選択し、必要事項を入力します。
- Workpace name: 英数小文字で指定
- Description: 説明文を指定(日本語OK)
- Username: EC2側のユーザ名を指定
- Hostname: EC2インスタンスの接続先ホストまたはIPアドレスを指定
- Initial path: ワークスペースのPATHを指定(任意)
- Port: SSHのポートを22以外に変更している場合は指定
- Node.js binary path: /usr/bin/node(空欄でOK)
「Create Workspace」をクリックしたら、SSHで接続〜ワークスペース作成まで全て自動でやってくれます。エラーが出た場合はログを追って対処してください。待つこと数十秒でリモートワークスペースが出来上がります。
開発環境完成
ものの数分です。あっという間にできました。 EC2上のファイルを直接編集できます。SCPやS3経由でという手間もありませんので、便利に使えると思います。
余談ですが、Project Setting > Run > Preview で 「When Saving Reload Preview:」を「Always」にしておくと、⌘+Enterを押さなくても、保存(⌘+s)と同時にプレビューがリロードされます。便利ですね。
Freeプランのアカウントとのコラボレート
チーム開発で使う場合は、ワークスペースから「Share」で、メンバーを招待すれば、コラボレーションできます(招待アカウントはFreeプランでOKです)。
インストール作業に無駄なコストを費やさず、コーディングに全力を尽くしてください。以上です。
参考にした手順
リモートワークスペースの作成手順は以下の公式ドキュメントを参考にしました。 Setting Up an SSH Workspace
JETWAREでラクラクLAMP環境構築(AWS&ローカルPC)
JETWAREでラクラクLAMP環境構築(AWS&ローカルPC)
ローカルPC(MacやWindows)にLAMP環境を構築するのに、MAMPやScotch Boxを使っているという方は多いかと思います。 また、AWSに商用環境/ローカルPCに開発環境を作る場合などは、BitnamiのLAMP環境を使うという方もいらっしゃると思います。
上記の方法は色々と紹介されているようですので、今回はそれ以外の方法、ということで「JETWARE」アプライアンスを利用した環境構築方法をご紹介しようと思います。これを使うことで、本番環境と同様の構成で素早くローカルの開発環境を立ち上げることができます。こちらは最近仕事でまとめた手順を公開用に一部手直ししたものです。
症状と効能
特にこのような方によく効きます。
- 環境構築よりコーディングに集中したい人
- AWSと同じ環境をローカルPCに作るのが面倒と感じている人
- 開発チームで仮想コンテナ等を導入したいが、メンバーのスキルレベルと温度差で導入が進まず苦労している人
- DockerやECS(EC2 Container Service)の商用利用に不安を感じている人
仮想コンテナを個人の興味でお試し程度に触る分には、手間も学習コストもあまり関係ありませんが、会社の開発チームで導入となるとすんなりとはいかないことが多いと思います。案件の性質や、システム管理・運用の都合、メンバーの温度差など、色々な諸事情が絡んでしまい、導入が難しいこともままあるかと思います。
今回構築する環境は
- AWS商用環境は、普通のEC2+AMI
- ローカルPC開発環境はVirtualBox+Vagrantで構築(Vagrantが面倒なら、それも不要)
- 開発環境はVMイメージまたはVagrantFileで共有
ということで、構築も簡単で、複雑な手順や学習も不要であるため、チーム内でも拒絶反応は少ないのではないかと思います(少なくとも、Dockerでのデプロイよりは)。
注意事項
AWSは使わない、ということなら別にMAMPでもScotch Boxで十分だと思いますし、BitnamiのUbuntuベースのLAMP環境に満足されているのであれば、今回の方法を知る必要もないかと思いますので悪しからずご了承ください。
それでは早速環境構築手順に移りたいと思います。
EC2の環境構築
AMI「Optimized LAMP Stack PHP 5.6」を使ったインスタンス作成
今回はJetwareが提供するアプライアンスを使います。 awsmarketplaceで選択します(0円です).
今回選んだ「lamp_php56_optimized」の構成はこのような感じです。
その他、インストールディレクトリなど詳細情報はこちらを参照ください。
EC2上にも開発環境や動作確認環境を構築するのであれば、このAMIを選んでEC2のインスタンスを作成するだけで完了です(EC2インスタンスの起動方法は、AMIを選択するところ以外は通常の手順とまったく同じですので、割愛します)。必要なものは全て/jet以下に配置してあります。
バックエンドはRDSなんだけど、という場合には、mariadbのデーモンを停止して、そのままフロントエンドのWebサーバとして使うのが手間なく簡単です。
ミドルウェアの構成を変えたい方は、構成違いのアプライアンスをこちらから選ぶというのでも良いかと思います。今回は他社製組込モジュールの制約上、PHP5.6を選択しましたが、PHP7.xのアプライアンスも用意されてます。お好みでどうぞ。
以上で、EC2の環境構築は完了です(はや)。
ローカルPCの環境構築
まずは事前準備としてVirtualBoxを用意します。
VirtualBox本体のダウンロード:macOS版dmg(ver. 5.1.6)
ダウンロードしたdmgファイルをダブルクリックしてインストール完了です。
さて、上記のAWSと同じJETWAREのアプライアンス環境をローカルに構築するには、以下の3つの方法があります。
- VirtualBoxイメージをダウンロードして設定
- VagrantFileを用いて環境設定
- Linux環境から環境設定用のシェルスクリプトを実行。
お手軽なのは1です。違いはチームメンバー間で共有・配布する手段です。 1ならVMイメージを、2ならVagrantFileを共有すればOKです。各自の事情にあわせてお選びください。3の方法は、お好きなLinux OS上にJETWAREアプライアンスを再現する方法です。オンプレに開発サーバ等を別途立てる場合にはこの方法でも良いでしょう(今回はローカルPCに環境を構築するという主旨ですので、3の説明は割愛します)。 以下に、それぞれの手順を記します。
1.VirtualBoxイメージをダウンロードして設定
イメージファイル(ova)のダウンロード:centos7版ダウンロード
Virtual MachineのOSは、CentOS7,Debian8/Ubuntu14.04からお好きなものを選べます。AWS側がAmazon Linux(CentOSベース)であることを鑑み、今回はCentOS7を選びました(Cent6.5があれば尚良かったんですが)。
VirtualBoxを起動して、Finderメニュー>ファイル>「仮想アプライアンスのインポート」を選択。
画面の指示に従ってインストール完了したら、起動。これで完了です。/jet以下に、同じ構成でアプリケーションがインストールされています。ログインIDとパスワードは以下の通りです。
User | Password |
---|---|
jet | jet |
その他デフォルトのセッティングに関する詳細はこちらを参照してください。
デーモン(サービス)の起動・停止は、Upstart(start/stopコマンド)で制御できます。
$ start apache $ stop memcached $ restart mysqld
以上。とても簡単ですね。
2.VagrantFileを用いて環境設定
Vagrantで制御したい場合は、こちらの方法で環境を構築します。こちらも簡単です。
2-1. Vagrantインストール
dmgファイルをダブルクリックしてインストール完了。
Terminalを起動して、以下のコマンドが正常実行できればOKです。
$ vagrant -v Vagrant 1.8.6
2-2. Boxファイルを登録
記載のとおり、Terminalから以下のコマンドを実行して、Boxファイルのイメージをダウンロードしてaddします。
$ vagrant box add "http://jetware.org/appliances/aws/lamp_php56_optimized/download/image:base_image:vagrant?os=centos_7" --name "jetware/aws-lamp_php56_optimized-centos_7" ==> box: Box file was not detected as metadata. Adding it directly... ==> box: Adding box 'jetware/aws-lamp_php56_optimized-centos_7' (v0) for provider: box: Downloading: http://jetware.org/appliances/aws/lamp_php56_optimized/download/image:base_image:vagrant?os=centos_7 ==> box: Successfully added box 'jetware/aws-lamp_php56_optimized-centos_7' (v0) for 'virtualbox'!
ダウンロードしたBoxファイルが利用可能かを確認して起動します。
$ vagrant box list jetware/aws-lamp_php56_optimized-centos_7 (virtualbox, 0)
仮想サーバ初期化 (Vagrantfileが生成されます)
$ vagrant init jetware/aws-lamp_php56_optimized-centos_7
仮想サーバ起動
$ vagrant up
以上で、Vagrantを使った環境構築は完了です。 こちらも手順どおりやるだけで、とても簡単に構築できました。
Vagrantの詳しい使い方に関しては、別の参考文献を当たってください。以下に基本的な使い方だけ抜粋して紹介しておきます。
2-3. 仮想サーバ初期化、起動、停止
仮想サーバ初期化 (Vagrantfileが生成されます)
$ vagrant init jetware/aws-lamp_php56_optimized-centos_7 A `Vagrantfile` has been placed in this directory. You are now ready to `vagrant up` your first virtual environment! Please read the comments in the Vagrantfile as well as documentation on `vagrantup.com` for more information on using Vagrant.
仮想サーバ起動 (以下の起動メッセージでは、SSHのポートは2200にマッピングされているのがわかります)
$ vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Importing base box 'jetware/aws-lamp_php56_optimized-centos_7'... ==> default: Matching MAC address for NAT networking... ==> default: Setting the name of the VM: sample_default_1475743729445_85292 ==> default: Fixed port collision for 22 => 2222\. Now on port 2200. ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat ==> default: Forwarding ports... default: 22 (guest) => 2200 (host) (adapter 1) ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2200 default: SSH username: vagrant default: SSH auth method: private key default: default: Vagrant insecure key detected. Vagrant will automatically replace default: this with a newly generated keypair for better security. default: default: Inserting generated public key within guest... default: Removing insecure key from the guest if it's present... default: Key inserted! Disconnecting and reconnecting using new SSH key... ==> default: Machine booted and ready! ==> default: Checking for guest additions in VM... default: The guest additions on this VM do not match the installed version of default: VirtualBox! In most cases this is fine, but in rare cases it can default: prevent things such as shared folders from working properly. If you see default: shared folder errors, please make sure the guest additions within the default: virtual machine match the version of VirtualBox you have installed on default: your host and reload your VM. default: default: Guest Additions Version: 5.0.16 default: VirtualBox Version: 5.1 ==> default: Mounting shared folders... default: /vagrant => /Users/tkikuchi/Documents/VirtualBox/sample
起動状態の確認
$ vagrant status Current machine states: default running (virtualbox) The VM is running. To stop this VM, you can run `vagrant halt` to shut it down forcefully, or you can run `vagrant suspend` to simply suspend the virtual machine. In either case, to restart it again, simply run `vagrant up`.
仮想サーバの再起動
$ vagrant reload ==> default: Attempting graceful shutdown of VM... ==> default: Clearing any previously set forwarded ports... ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat ==> default: Forwarding ports... default: 22 (guest) => 2200 (host) (adapter 1) ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2200 default: SSH username: vagrant default: SSH auth method: private key ==> default: Machine booted and ready! ==> default: Checking for guest additions in VM... default: The guest additions on this VM do not match the installed version of default: VirtualBox! In most cases this is fine, but in rare cases it can default: prevent things such as shared folders from working properly. If you see default: shared folder errors, please make sure the guest additions within the default: virtual machine match the version of VirtualBox you have installed on default: your host and reload your VM. default: default: Guest Additions Version: 5.0.16 default: VirtualBox Version: 5.1 ==> default: Mounting shared folders... default: /vagrant => /Users/tkikuchi/Documents/VirtualBox/sample ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision` ==> default: flag to force provisioning. Provisioners marked to run always will still run.
2-4. 仮想サーバの設定変更
前述の$ vagrant init box名
を実行すると、カレントディレクトリに設定ファイル「Vagrantfile」が生成されています。
$ ls -la total 8 drwxr-xr-x 4 tkikuchi staff 136 10 6 17:48 . drwxr-xr-x 4 tkikuchi staff 136 10 6 17:16 .. drwxr-xr-x 3 tkikuchi staff 102 10 6 17:48 .vagrant -rw-r--r-- 1 tkikuchi staff 3045 10 6 17:47 Vagrantfile
「Vagrantfile」の編集
$ vi ./Vagrantfile
例) IPアドレスをスタティックに設定
# IPアドレス設定 サンプル config.vm.network "private_network", ip: "192.168.33.10"
例)ローカルPCのカレントディレクトリを、仮想サーバの /var/www/html に同期。
# フォルダ同期 サンプル config.vm.synced_folder ".", "/var/www/html", :owner => "vagrant", :group => "vagrant", :mount_options => ["dmode=775,fmode=775"]
config.vm.provision "shell", inline: <<-SHELL # Git yum install -y postfix SHELL
その他記法の詳細は、こちらを参照してください。
手動プロビジョニング
$ vagrant provision
2-5. 仮想サーバ基本操作コマンド
仮想サーバログイン
$ vagrant up ... 起動 $ vagrant ssh ... sshでログイン
$ ssh jet@127.0.0.1 -p 2200
その他 主要操作コマンド(詳細はvagrant -h)
box追加
$ vagrant box add {VM名} {boxファイルダウンロードURL}
利用可能box一覧
$ vagrant box list
boxの削除
$ vagrant box remove {box名}
初期化(Vagrantfile作成)
$ vagrant init
起動
$ vagrant up
SSH設定確認
$ vagrant ssh-config
仮想サーバにSSHログイン
$ vagrant ssh
シャットダウン
$ vagrant halt
再起動
$ vagrant reload
$ vagrant suspend
レジューム
$ vagrant resume
破棄
$ vagrant destroy
以上です。Vagrantを使っても、とても簡単に環境構築ができました。手順どおり行えば誰でもできますので、ぜひ皆さんの環境でもお試し頂ければと思います。
最後に
S3を介さず、EC2とローカルPC環境とのファイル同期をしたいとき、皆さんどうされているんでしょうか。今のところlsyncd、rsyncdやownCloudくらいしか思いつきません。他にベスト・プラクティスをご存知の方がいらっしゃいましたらぜひご教授ください。
無料のドメインを取得する(2016年10月)
無料のドメインを取得する
最近はドメインも安く取得できるようになりましたので、需要はあまり多くはないかも知れませんが、「無料」で気軽に取得できるという点で、コストコンシャスな方々に一定の需要があると信じて投稿します。
症状と効能
- オリジナルドメインで手軽にブログを始めたい(タダで)
- ネームサーバのテスト用のドメインを一時的に取得したい(タダで)
- フリーランスの名刺にオリジナルドメインのURLとメアドを刷り込みたい
- せっかくAWSが無料試用期間なのにドメイン取得費用を払うのはイヤ
とにかくドメイン取得に一銭も払いたくない、という方向けに寄稿します。
無料で取得できるドメイン
Freenomからは5種類のドメイン(.tk/.ml/.ga/.cf/.gq)が無料で取得できます。どれを使うかはお好みで。今回は.tkで取得を進めます。
.tkドメインの注意事項
90日間で25アクセス以下の場合は、登録が削除されます。3ヶ月の間に25回以上のドメインのリクエストが必要ですが、普通に使う分には殆ど問題にならないと思います。
2017.09.06 追記: ドメイン取得時に、ミニマムリクエストに関する要件が明記されなくなったようです。利用規約等にも記述が見当たりませんでした。
取得方法
ドメインプロバイダFreenomのページから空きドメインを検索~取得可能です。
ためしに、「my-free-domain」で検索してみたところ、いずれの無料ドメインも取得可能でした。
さっそく取得手続きに移ります。「今すぐ入手」をクリックし、表示された「チェックアウト」ボタンをクリック。
Use your new domain は、後から設定変更できるので、取り急ぎ「Forward this domain」を選択し、適当なURLを入力。 Period は「12Months @ FREE」を選択し「Continue」をクリック。
Priceが$0.00USDなのを念のため確認し、ユーザ登録手続きを開始。私は Googleアカウントを使ってサインインしました。
GoogleのOAuthの認証が終わるとユーザ情報詳細を入力するフィールドが表示されます。特段追加入力は不要なようですので、「I have read and agree to Terms & Conditions」にチェックをして「Complete Order」をクリック。
無事ドメイン取得が完了しました。「Click here to go to your Client Area」でfreenomのclientareaページに遷移します。
これでドメインの取得は完了です。
有効期限の更新
ドメインの有効期限が近付くと、登録したメールアドレス宛にお知らせメールが届きますので、こちらの画面から「Renew Domains」を選択して、ドメインの有効期限を延長してください。
ドメインの設定・管理全般
管理画面からドメインの各種設定変更が行えます。右上のメニューからServices > My Domainsを選択。
My Domainsのリストに、先ほど取得したドメインが表示されます。「Manage Domain」をクリック。ここでドメインに関する設定を行います。
ブログに転送するだけの設定
ブログに飛ばすだけなら、「Management Tools」からURL Forwardingを設定すればOKです。「URL Forwarding」に転送先のURLを入力、「Forward mode」を「Redirect(HTTP 301 forwarding)」に設定して、「Set URL」をクリック。しばらくすると、http://[今回取得したドメイン]/で、目的のページが表示されるようになります。
ネームサーバを指定する場合
ネームサーバを指定する必要がある場合(www、mailなどのホスト名を登録するなど)は、「Management Tools」から、「Name Servers」を選択します。freenomが提供するネームサーバ(無料です)を使うなら「Use default nameservers」を選択します。「Management Tools」から「Manage Freenom DNS」を選択すれば、任意のDNSレコードを登録することができます。登録画面の使い方は、Route53やDozens、お名前.comほか、一般的なネームサーバ管理ツールと変わらないため、説明は割愛します。
AWSのRoute53($0.5/month~)や、Dozens(無料/15レコード迄)等のDNSサービスや自前で構築したBind等、ネームサーバを別途用意する場合は、「Use custom nameservers(enter below)」を選択し、Nameserverを入力してください。
以上、簡単ですが無料ドメイン取得とネームサーバ指定まで、レジストラでの作業はこれでOKです。Route53やDozensなどでのDNSレコード登録手順は、気が向いたら投稿します。
AWS EC2インスタンスにSSHで接続できなくなったとき
設定ミスでログインできなくなったインスタンスを復旧することになった時の作業記録です。 Unix系OSにおける一般的な起動ディスクの障害対応手順を、単にAWSならこうやる、というだけの話で恐縮ですが、何かのお役に立てれば幸いです。
症状と効能
こんな人によく効きます。
何かしらの原因で、ログインできなくなったり、インスタンスが起動しなくなったりしたときにファイルシステムにアクセスすれば糸口が掴める、といった時に使えます。
オンプレミス環境やホスティングサービスなら、ブートディスクを変更してからの復旧や、コンソールログインからの設定修正など、何かしらの手段が提供されていますが、AWSだとこのような方法になるかと思います。
なお、利用しているインスタンスはAmazon Linux、rootボリュームはElastic Block Store(EBS)ですが、LinuxのDistributionならば、ほぼ共通の手順になると思われます。
注意点
システムステータスチェックやインスタンスステータスチェックがNGのケースは、この方法では対処できない可能性が高いと思われますのであしからず。その場合は、こちらを参考に対処してください。 参考:『Amazon EC2ユーザガイド』インスタンスのステータスチェック
対応手順サマリ
- 障害が発生した「インスタンスA」を停止
- 「インスタンスA」のEBSボリュームをデタッチ
- 正常起動できる「インスタンスB」に対象ボリュームをアタッチ
- 「インスタンスB」を開始&ログイン
- 対象ボリュームをマウント
- 原因調査と対処
- 対象ボリュームをアンマウント&デタッチ
- 「インスタンスA」に対象ボリュームをアタッチ&起動
以下に順を追って内容を記します。
障害が発生したインスタンスの停止
まずはマネジメントコンソールで作業します。 対象インスタンスの「ルートデバイス」名を確認してから、インスタンスを停止します。 ルートデバイス名は、「/dev/xvda」もしくは「/dev/sda1」となっているかと思います。今回使用しているAmazon Linuxでは、「/dev/xvda」となっていました。 AWS CLIコマンドを使って調べることも可能です。この辺の詳細は『Amazon EC2ユーザガイド』Linux インスタンスでのデバイスの名前付けを参照してください。
対象デバイスを右クリックして「停止」を選択します。
EBSボリュームをデタッチ
インスタンスが停止されたことを確認してから対象のEBSボリュームをデタッチします。 対象ボリュームを右クリックして「ボリュームのデタッチ」を選択します。
正常なインスタンスにボリュームをアタッチ
ボリュームの状態が「available」になったら、別の正常なインスタンスにアタッチします。
対象ボリュームを右クリックして「ボリュームのアタッチ」を選択します。 アタッチ先のインスタンスを選択し、ブロックデバイス名を指定します。今回は「/dev/sdf」を指定。
ボリュームの状態が「in-use」になれば、アタッチ完了です。
正常なインスタンスを開始~ログイン
通常の手順どおり、ボリュームをアタッチしたインスタンスを「開始」(=起動)し、SSHでログインしてください。ちなみに、今回使用したインスタンスはCentOS6.7です。
対象ボリュームをマウント
ログイン後、先ほどアタッチしたボリューム「/dev/sdf」をマウントします。 このときのデバイス名は、/dev/sdfか/dev/xvdfなど、異なる名前でアタッチされる可能性があります。 参考:『Amazon EC2 ユーザガイド』Amazon EBSボリュームを使用できるようにする
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 7.8G 666M 6.7G 9% / tmpfs 498M 0 498M 0% /dev/shm
ここで、ルートデバイスが/dev/xvとなっていたら、先ほどアタッチしたボリュームの名前も/dev/xvとなっています。
$ ls -la /dev |grep sd $ ls -la /dev |grep xv lrwxrwxrwx. 1 root root 5 Oct 8 14:47 root -> xvda1 brw-rw----. 1 root disk 202, 0 Oct 8 14:47 xvda brw-rw----. 1 root disk 202, 1 Oct 8 14:47 xvda1 brw-rw----. 1 root disk 202, 80 Oct 8 14:47 xvdf brw-rw----. 1 root disk 202, 81 Oct 8 14:47 xvdf1
$ lsblk -i NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 8G 0 disk `-xvda1 202:1 0 8G 0 part / xvdf 202:80 0 8G 0 disk `-xvdf1 202:81 0 8G 0 part
マウントするディレクトリを作成して、マウント実行。
$ sudo mkdir /mnt/vol_ebs
$ sudo mount /dev/xvdf1 /mnt/vol_ebs $ mount /dev/xvda1 on / type ext4 (rw) ...<snip>... /dev/xvdf1 on /mnt/vol_ebs type ext4 (rw)
正常にマウントされました(マウントポイントは/)
原因調査と対処
システムログや、作業履歴などから原因を調査し、設定を修正するなどして復旧します。 今回はTCP Wrapperの設定ミスで、SSHログインができなくなっていたため、hosts.allowおよびhosts.denyを適切に修正しました(修正内容は割愛)。
アンマウント~対象ボリュームをデタッチ
念のためアンマウントして、対象インスタンスを停止してから、EBSボリュームをデタッチします。
$ sudo umount /mnt/vol_ebs
$ mount /dev/xvda1 on / type ext4 (rw) ...<snip>... none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
マネジメントコンソールで停止 対象デバイスを右クリックして「停止」を選択します。
インスタンスの状態が「stopped」に変わったことを確認して、EBSボリュームをデタッチします。 対象ボリュームを右クリックして「ボリュームのデタッチ」を選択します。
対象ボリュームをアタッチ~インスタンス開始
デタッチしたボリュームは元のインスタンスにルートデバイスとしてアタッチします。 ボリュームの状態が「available」であることを確認の上、アタッチします。 対象ボリュームを右クリックして「ボリュームのアタッチ」を選択します。
アタッチ先のインスタンスを選択し、ブロックデバイス名を指定します。元の状態に戻すため「/dev/xvda」を指定してアタッチします。
ボリュームの状態が「in-use」になれば、アタッチ完了です。
通常の手順どおり、ボリュームをアタッチしたインスタンスを「開始」(=起動)し、SSHでログインしてください。無事ログインできれば成功です。
以上です。
参考にした記事
手順をまとめるにあたり、こちらの記事を参考にさせて頂きました。ありがとうございます。 AWSサーバーにログインできなくなった場合の対処