AWS Cloud9 with オンプレ開発環境の構築

概要

AWS Cloud9と自宅の開発サーバを接続して、クラウドコーディング環境を構築する手順についてまとめています。
(2018年1月時点の情報です)

やりたいこと

以下の前提で開発環境を構築。

  • 自宅のDMZセグメントにUbuntu16.04 Desktopを立てる
  • Cloud9での開発構築デプロイ時、EC2を選ばず、On-Premisesを選択
  • Cloud9からSSHでUbuntuに接続させる

AWS Cloud9 with On-Premises

開発環境構築後の利用イメージ

  • 開発者は自宅、外出先を問わずCloud9のIDEにブラウザからアクセス
  • IDEから投入したコードはEC2ではなく、Cloud9→(SSH)→自宅開発サーバに対してデプロイされる
  • テストコードの実行、開発者からのテストアクセスは自宅の開発サーバに対して行われる

利用イメージ

EC2ではなくオンプレミスを選択する理由

EC2を選択した方が構築は遙かに楽なのですが、あえてオンプレを選んだ理由は、

  1. 好きなDistributionが選べる。
    CentOS, Red Hat, Ubuntuなど、自分が普段使い慣れているものをそのまま使える。
    (EC2だと強制的にAmazon Linux一択になる)
  2. 気軽にSnapshot取得→切り戻ししたい。
    AWSより自宅のESXiでのSnapshotの方が楽。
    (AWSでもSnapshotは取れるが、戻すのがVMwareより少し面倒)

費用面
3番目の理由として『AWSのEC2を借りるより安上がり』を書こうとしましたが、ちょっと無理でした。
Cloud9ではユーザのアクティビティ(IDEに対する何かしらのアクション)が一定時間無かった場合、EC2インスタンスを自動でサスペンドしてくれるため、ランニング費用が相当節約できます。
オンプレミスの常時稼働サーバでは(ラズパイでも使わない限り)電気代の面で勝てません。


構築手順

開発用Linuxマシンの準備

OSインストール

OS:
Ubuntu16.4.3 Desktop
(ubuntu-16.04.3-desktop-amd64.iso)

ESXi上にVMとして構築。
インストールはカスタマイズ一切無しのデフォルト構成。

既存パッケージのアップデート

sudo apt-get update
sudo apt-get upgrade

必要なパッケージの追加

OpenSSH server

sudo apt-get install openssh-server

Cloud9に使わせるユーザについて、sudo時にパスワードを訊かれないようにする。

sudo visudo

末尾に追記
Cloud9に使わせるユーザ名 ALL=(ALL) NOPASSWD: ALL

tmux

後続の手順にて、Cloud9がローカルのUbuntuに環境を構築する際にtmuxを入れようとしましたが、configureのステップでなぜかエラーになり、そこで止まってしまう事象がでていました。
なので、先回りして手動で入れておきます。

sudo apt-get install tmux

Node.jsのインストール

この開発環境でNode.jsのお勉強をするのがそもそもの目的ですので、Node.jsも入れておきます。
以下のサイトを参考にさせていただきました。
Ubuntu16.04で任意のバージョンのNode.jsをインストールする方法(トライフィールズ様)

sudo apt-get install nodejs npm
sudo npm install -g n
sudo n stable
sudo apt-get purge nodejs npm
suto apt-get autoremove
node -v
npm -v
n --version

Cloud9側で環境作成

開発環境の作成

AWSコンソールからCloud9を選択。
Create environmentを選択。

環境に名前とDescriptionを設定。

開発環境(サーバ)に何を使うか選択します。

  • Environment type
    デフォルトでEC2が選択されていますが、今回はConnect and run in remote server(SSH)を選択します。
  • SSH server connection
    User: Cloud9がオンプレのLinuxサーバにssh接続してくる時に使うユーザ名。
    Host: Cloud9がオンプレのLinuxサーバにssh接続してくる時の宛先ホスト名もしくはIPアドレス。
    本例では自宅で使用しているダイナミックDNSのホスト名を指定しました。

  • Port
    デフォルトで22が設定されているので、そのまま。
    ※自宅のFirewallでInboundのTCP:22をDMZ上のUbuntuサーバにPort Forwardingするよう別途設定しておきます。

  • Copy key to clipboard
    Cloud9からのSSH接続はパスワードを用いず、証明書認証が使われているようです。
    このボタンをクリックして、Cloud9側の公開鍵をコピーし、ローカルの開発サーバ上で~/.ssh/authorized_keysに追記します。
    (vimで直書きするか、catで追記。Permissionは600に指定)

Advanced settings
– Environment path
Cloud9の開発環境のRootディレクトリを指定。
IDEを開くと、ここで指定したパスをRootとしてコードやフォルダを配置することとなります。

  • Node.js binary path
    which nodeコマンドでNode.jsのパスを探して指定。
    本例では/usr/local/bin/node

Cloud9からオンプレのUnbutuに対してSSH接続され、環境構築が始まります。

1~2分程度待つと
“想定より時間がかかりすぎている。何かおかしくない?”
ダイアログが出ることがあります。

  • ローカルの環境が処理性能があまり高くないせいで、時間がかかっているだけ
  • 本当に何かエラーがおきている
  • ブラウザ環境の問題

のいずれかが考えられます。

ウチの環境では、

  • 環境構築時にCloud9がtmuxを入れようとしていたが、configureのステップでなぜかエラーになり、そこで止まっていた。
  • Adblockが画面遷移をBlockしていた

の2件のトラブルを経験しました。
前者については、手動でapt-get install tmuxしておく
後者については、Adblockの設定でこのドメイン上では実行しないに設定
で対処できました。

Cloud9のIDE画面が表示されます。

※どうしても画面が遷移しない、という場合には、実は環境構築は完了していることがありますので、ブラウザで別タブを開いて、そちらでAWS Cloud9コンソールを開いてみるといけたりします。

IDE上でのテスト

画面下のbashタブでターミナルのCLI操作ができます。
pwdすると、環境構築時に指定したパス(本例では/home/kowloon/cloud9)がデフォルトで指定されていることが分かります。

テストコードを打ち、拡張子「.js」で保存します。
FileNew File

console.log('Hello, World!');

console.log('The sum of 2 and 3 is 5.');

var sum = parseInt(process.argv[2], 10) + parseInt(process.argv[3], 10);

console.log('The sum of ' + process.argv[2] + ' and ' +
  process.argv[3] + ' is ' + sum + '.');

Runボタンから実行すると、無事エラーとなりました。

node: bad option: --nocrankshaft
node: bad option: --nodead_code_elimination

Process exited with code: 9
  • ターミナルコンソール上でnode ファイル名で直接実行する。
    もしくは
  • デバッグモードを無効(虫アイコンを押してグレー状態)にしてからRun

であれば問題なく実行できました。

http serverの起動についても試してみましたが、全く同様の挙動でした。

Runボタンからの実行(デバッグモード有効)はエラー↓↓

ターミナルからの直接実行は成功↓↓

デバッグモードを無効にすれば、Runボタンからでも成功↓↓

対策
本事象について、Cloud9本家のフォーラムにも話題が上がっていましたが、解決策は不明です。

Node: bad option: –nocrankshaft (Cloud9 community)

デバッグモードでコードを動かせないので、開発時のトラブルシュートが少ししんどくなるかもしれませんが、今の私の知恵では根本対処が思いつきません。

「どうにもうまくコードが動かない!デバッグモードが欲しい!」というときは、
ローカルのMacにインストールしたVisual Studio CodeにコードをCloneしてデバッグする、などの対処で逃げることとします。