2016年10月12日水曜日

Cloud9のワークスペースをEC2に作って爆速開発環境構築

Cloud9のワークスペースをEC2に作って爆速開発環境構築

cloud9_www.png
Cloud9がAmazonに買収されて早数ヶ月。もう少しするとEC2専用のサービスが登場しそうですね。 現状のままでも、Cloud9とEC2を連携して、かなりシームレスな開発ワークフローが構築できますので、参考までにご紹介します。

前提条件

EC2インスタンス

SSHで接続できるインスタンスを用意します。今回はJetwareアプライアンス「Optimized LAMP Stack PHP 5.6」(Amazon Linuxベース)で起動したLAMP環境のインスタンスを使います。Jetwareアプライアンスを使ったインスタンスの作成方法に関しては、以下の記事をご参照ください。

cloud9のアカウント

Cloud9のアカウントが必要です。そして、これが肝かつこの話の全てなのですが、Individual以上のプランの購入($19/month)が必要です。 そうです。快適な環境を得るには、相応の対価を払う必要があるということです。。。
ですが、チームで使う場合は、1つのアカウントだけ購入していればOKです。Cloud9にはコラボレート機能があるので、メンバーアカウントを招待することで、他のメンバーも恩恵に預かれます。 そう考えると結構お得だと思います。AWS案件のサーバ運用費として$19/monthを追加計上してもらうよう、ぜひ決裁者に上申してみてください。
cloud9_price.png
ここからはIndividualアカウントにアップグレードした前提で、話を進めます。

EC2インスタンスに公開鍵を追加

Cloud9からSSH接続を許可するため、公開鍵を追加します。
まずは、Cloud9のメニューから「Account Settings」を選択し、設定画面に遷移します。
cloud9_settings.png
メニュー「SSH Keys」の中にある公開鍵をコピーして、EC2インスタンス側のユーザの~/.ssh/authorized_keysファイルに追加(なければ新規作成)します。Terminalで接続して、お好みのエディタを利用してください。ここではviを使って編集します。
authorized_keysを編集
$ vi ~/.ssh/authorized_keys
viで開いたら、「o」キーを押してAppendモードにしてから「⌘+v」で貼り付けます。貼り付けが完了したら「ZZ(大文字)」で保存終了。
ec2_terminal.png
これで、Cloud9から接続する準備ができました。

必要パッケージのインストール

今回利用したAMI「Optimized LAMP Stack PHP 5.6」(Amazon Linuxベース)だと、node.js(0.6.16以降)やglibc-staticなどのパッケージを追加インストールする必要がありましたので、yumでインストールしておきます。
node.js関連パッケージのインストール
$ sudo yum install epel-release
$ sudo yum install nodejs npm --enablerepo=epel
glibc-staticのインストール
$ sudo yum install glibc-static
これらのパッケージがインストールされていない場合は、このあとの手順で、/usr/bin/nodeが見つからない、cursesが見つからない等のエラーがでて、ワークスペースの作成が失敗しますので、ご注意ください。

ワークスペース作成

Cloud9にログインして、ダッシュボードからワークスペースを作成します。「Creat a new workspace」をクリック。
cloud9_newworkspace.png
画面中段のタブから「Remote SSH workspace」を選択し、必要事項を入力します。
cloud9_create_newworkspace.png
  • 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で接続〜ワークスペース作成まで全て自動でやってくれます。エラーが出た場合はログを追って対処してください。待つこと数十秒でリモートワークスペースが出来上がります。

開発環境完成

cloud9_cake.png
ものの数分です。あっという間にできました。 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)

jetware_www.png
ローカル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」の構成はこのような感じです。
jetware_lamp_php56.png
その他、インストールディレクトリなど詳細情報はこちらを参照ください。
EC2上にも開発環境や動作確認環境を構築するのであれば、このAMIを選んでEC2のインスタンスを作成するだけで完了です(EC2インスタンスの起動方法は、AMIを選択するところ以外は通常の手順とまったく同じですので、割愛します)。必要なものは全て/jet以下に配置してあります。
バックエンドはRDSなんだけど、という場合には、mariadbのデーモンを停止して、そのままフロントエンドのWebサーバとして使うのが手間なく簡単です。
ミドルウェアの構成を変えたい方は、構成違いのアプライアンスをこちらから選ぶというのでも良いかと思います。今回は他社製組込モジュールの制約上、PHP5.6を選択しましたが、PHP7.xのアプライアンスも用意されてます。お好みでどうぞ。
以上で、EC2の環境構築は完了です(はや)。

ローカルPCの環境構築

まずは事前準備としてVirtualBoxを用意します。
VirtualBox本体のダウンロード:macOS版dmg(ver. 5.1.6)
virtualbox_download.png
ダウンロードしたdmgファイルをダブルクリックしてインストール完了です。
さて、上記のAWSと同じJETWAREのアプライアンス環境をローカルに構築するには、以下の3つの方法があります。
  1. VirtualBoxイメージをダウンロードして設定
  2. VagrantFileを用いて環境設定
  3. Linux環境から環境設定用のシェルスクリプトを実行。
お手軽なのは1です。違いはチームメンバー間で共有・配布する手段です。 1ならVMイメージを、2ならVagrantFileを共有すればOKです。各自の事情にあわせてお選びください。3の方法は、お好きなLinux OS上にJETWAREアプライアンスを再現する方法です。オンプレに開発サーバ等を別途立てる場合にはこの方法でも良いでしょう(今回はローカルPCに環境を構築するという主旨ですので、3の説明は割愛します)。 以下に、それぞれの手順を記します。

1.VirtualBoxイメージをダウンロードして設定

イメージファイル(ova)のダウンロード:centos7版ダウンロード
jetware_vmdownload.png
Virtual MachineのOSは、CentOS7,Debian8/Ubuntu14.04からお好きなものを選べます。AWS側がAmazon Linux(CentOSベース)であることを鑑み、今回はCentOS7を選びました(Cent6.5があれば尚良かったんですが)。
VirtualBoxを起動して、Finderメニュー>ファイル>「仮想アプライアンスのインポート」を選択。
virtualbox_menu.png
画面の指示に従ってインストール完了したら、起動。これで完了です。/jet以下に、同じ構成でアプリケーションがインストールされています。ログインIDとパスワードは以下の通りです。
UserPassword
jetjet
その他デフォルトのセッティングに関する詳細はこちらを参照してください。
デーモン(サービス)の起動・停止は、Upstart(start/stopコマンド)で制御できます。
サービスの開始・停止
$ start apache
$ stop memcached
$ restart mysqld
以上。とても簡単ですね。

2.VagrantFileを用いて環境設定

Vagrantで制御したい場合は、こちらの方法で環境を構築します。こちらも簡単です。

2-1. Vagrantインストール

vagrant_download.png
dmgファイルをダブルクリックしてインストール完了。
Terminalを起動して、以下のコマンドが正常実行できればOKです。
バージョン表示
$ vagrant -v
Vagrant 1.8.6

2-2. Boxファイルを登録

jetware_vagrant_add.png
記載のとおり、Terminalから以下のコマンドを実行して、Boxファイルのイメージをダウンロードしてaddします。
boxファイル追加
$ 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」が生成されています。
設定ファイル「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で編集
$ 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"]
例)yumでpostfixの追加インストール
config.vm.provision "shell", inline: <<-SHELL

# Git
yum install -y postfix

SHELL
その他記法の詳細は、こちらを参照してください。
手動プロビジョニング
$ vagrant provision

2-5. 仮想サーバ基本操作コマンド

仮想サーバログイン
$ vagrant up  ... 起動
$ vagrant ssh  ... sshでログイン
IPアドレスとポートを指定してSSH接続も可能
loopbackアドレスに接続
$ 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月10日月曜日

無料のドメインを取得する(2016年10月)

無料のドメインを取得する

freenom_portal2.png
最近はドメインも安く取得できるようになりましたので、需要はあまり多くはないかも知れませんが、「無料」で気軽に取得できるという点で、コストコンシャスな方々に一定の需要があると信じて投稿します。

症状と効能

  • オリジナルドメインで手軽にブログを始めたい(タダで)
  • ネームサーバのテスト用のドメインを一時的に取得したい(タダで)
  • フリーランスの名刺にオリジナルドメインのURLとメアドを刷り込みたい
  • せっかくAWSが無料試用期間なのにドメイン取得費用を払うのはイヤ
とにかくドメイン取得に一銭も払いたくない、という方向けに寄稿します。

無料で取得できるドメイン

Freenomからは5種類のドメイン(.tk/.ml/.ga/.cf/.gq)が無料で取得できます。どれを使うかはお好みで。今回は.tkで取得を進めます。
freenom_freedomains.png

.tkドメインの注意事項

90日間で25アクセス以下の場合は、登録が削除されます。3ヶ月の間に25回以上のドメインのリクエストが必要ですが、普通に使う分には殆ど問題にならないと思います。
2017.09.06 追記: ドメイン取得時に、ミニマムリクエストに関する要件が明記されなくなったようです。利用規約等にも記述が見当たりませんでした。

取得方法

ドメインプロバイダFreenomのページから空きドメインを検索~取得可能です。
ためしに、「my-free-domain」で検索してみたところ、いずれの無料ドメインも取得可能でした。
さっそく取得手続きに移ります。「今すぐ入手」をクリックし、表示された「チェックアウト」ボタンをクリック。
freenom_checkout.png
Use your new domain は、後から設定変更できるので、取り急ぎ「Forward this domain」を選択し、適当なURLを入力。
Period は「12Months @ FREE」を選択し「Continue」をクリック。
freenom_domain.png
Priceが$0.00USDなのを念のため確認し、ユーザ登録手続きを開始。私は
Googleアカウントを使ってサインインしました。
freenom_reviewandcheckout.png
GoogleのOAuthの認証が終わるとユーザ情報詳細を入力するフィールドが表示されます。特段追加入力は不要なようですので、「I have read and agree to Terms & Conditions」にチェックをして「Complete Order」をクリック。
freenom_completeorder.png
無事ドメイン取得が完了しました。「Click here to go to your Client Area」でfreenomのclientareaページに遷移します。
freenom_orderconfirmation.png
これでドメインの取得は完了です。

有効期限の更新

ドメインの有効期限が近付くと、登録したメールアドレス宛にお知らせメールが届きますので、こちらの画面から「Renew Domains」を選択して、ドメインの有効期限を延長してください。
freenom_renewdomains.png

ドメインの設定・管理全般

管理画面からドメインの各種設定変更が行えます。右上のメニューからServices > My Domainsを選択。
freenom_clientmenu.png
My Domainsのリストに、先ほど取得したドメインが表示されます。「Manage Domain」をクリック。ここでドメインに関する設定を行います。
freenom_managedomein.png

ブログに転送するだけの設定

ブログに飛ばすだけなら、「Management Tools」からURL Forwardingを設定すればOKです。「URL Forwarding」に転送先のURLを入力、「Forward mode」を「Redirect(HTTP 301 forwarding)」に設定して、「Set URL」をクリック。しばらくすると、http://[今回取得したドメイン]/で、目的のページが表示されるようになります。
freenom_urlforward.png

ネームサーバを指定する場合

ネームサーバを指定する必要がある場合(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を入力してください。
freenom_nameserver.png
以上、簡単ですが無料ドメイン取得とネームサーバ指定まで、レジストラでの作業はこれでOKです。Route53やDozensなどでのDNSレコード登録手順は、気が向いたら投稿します。

AWS EC2インスタンスにSSHで接続できなくなった時

AWS EC2インスタンスにSSHで接続できなくなった時


設定ミスでログインできなくなったインスタンスを復旧することになった時の作業記録です。
Unix系OSにおける一般的な起動ディスクの障害対応手順を、単にAWSならこうやる、というだけの話で恐縮ですが、何かのお役に立てれば幸いです。


症状と効能

こんな人によく効きます。
  • iptablesやTCP Wrapperの設定をミスったとき
  • キーペアを紛失したとき
  • OSの設定をミスって起動しなくなったとき
何かしらの原因で、ログインできなくなったり、インスタンスが起動しなくなったりしたときにファイルシステムにアクセスすれば糸口が掴める、といった時に使えます。

オンプレミス環境やホスティングサービスなら、ブートディスクを変更してからの復旧や、コンソールログインからの設定修正など、何かしらの手段が提供されていますが、AWSだとこのような方法になるかと思います。
なお、利用しているインスタンスはAmazon Linux、rootボリュームはElastic Block Store(EBS)ですが、LinuxのDistributionならば、ほぼ共通の手順になると思われます。

注意点

システムステータスチェックやインスタンスステータスチェックがNGのケースは、この方法では対処できない可能性が高いと思われますのであしからず。その場合は、こちらを参考に対処してください。
参考:『Amazon EC2ユーザガイド』インスタンスのステータスチェック

対応手順サマリ

  1. 障害が発生した「インスタンスA」を停止
  2. 「インスタンスA」のEBSボリュームをデタッチ
  3. 正常起動できる「インスタンスB」に対象ボリュームをアタッチ
  4. 「インスタンスB」を開始&ログイン
  5. 対象ボリュームをマウント
  6. 原因調査と対処
  7. 対象ボリュームをアンマウント&デタッチ
  8. 「インスタンスA」に対象ボリュームをアタッチ&起動
以下に順を追って内容を記します。

障害が発生したインスタンスの停止

まずはマネジメントコンソールで作業します。
対象インスタンスの「ルートデバイス」名を確認してから、インスタンスを停止します。
confirm_rootdevice.png
ルートデバイス名は、「/dev/xvda」もしくは「/dev/sda1」となっているかと思います。今回使用しているAmazon Linuxでは、「/dev/xvda」となっていました。
AWS CLIコマンドを使って調べることも可能です。この辺の詳細は『Amazon EC2ユーザガイド』Linux インスタンスでのデバイスの名前付けを参照してください。
stop_instance.png
対象デバイスを右クリックして「停止」を選択します。

EBSボリュームをデタッチ

インスタンスが停止されたことを確認してから対象のEBSボリュームをデタッチします。
detach_ebs.png
対象ボリュームを右クリックして「ボリュームのデタッチ」を選択します。

正常なインスタンスにボリュームをアタッチ

ボリュームの状態が「available」になったら、別の正常なインスタンスにアタッチします。
atach_ebs.png

対象ボリュームを右クリックして「ボリュームのアタッチ」を選択します。
atach2_ebs.png
アタッチ先のインスタンスを選択し、ブロックデバイス名を指定します。今回は「/dev/sdf」を指定。

atach3_ebs.png
ボリュームの状態が「in-use」になれば、アタッチ完了です。

正常なインスタンスを開始~ログイン

通常の手順どおり、ボリュームをアタッチしたインスタンスを「開始」(=起動)し、SSHでログインしてください。ちなみに、今回使用したインスタンスはCentOS6.7です。
centos_login.png

対象ボリュームをマウント

ログイン後、先ほどアタッチしたボリューム「/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となっています。
stop_instance.png
ブロックデバイスを確認
$ 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)
マネジメントコンソールで停止
stop_instance.png
対象デバイスを右クリックして「停止」を選択します。

インスタンスの状態が「stopped」に変わったことを確認して、EBSボリュームをデタッチします。
detach_ebs.png
対象ボリュームを右クリックして「ボリュームのデタッチ」を選択します。

対象ボリュームをアタッチ~インスタンス開始

デタッチしたボリュームは元のインスタンスにルートデバイスとしてアタッチします。
ボリュームの状態が「available」であることを確認の上、アタッチします。
atach_ebs.png
対象ボリュームを右クリックして「ボリュームのアタッチ」を選択します。

atach2_ebs.png
アタッチ先のインスタンスを選択し、ブロックデバイス名を指定します。元の状態に戻すため「/dev/xvda」を指定してアタッチします。

atach3_ebs.png
ボリュームの状態が「in-use」になれば、アタッチ完了です。

通常の手順どおり、ボリュームをアタッチしたインスタンスを「開始」(=起動)し、SSHでログインしてください。無事ログインできれば成功です。
login_success.png
以上です。

参考にした記事

手順をまとめるにあたり、こちらの記事を参考にさせて頂きました。ありがとうございます。
AWSサーバーにログインできなくなった場合の対処