AWS上でWin2016をデプロイしてアクセスする方法

はじめに

タイトルの通りです。個人的な備忘録的な記事です。
目的は、AWS上でWinServerを立ち上げたことが無かったので、
立ち上げと接続方法の確認です。

構成図

cloudcraftを使用して、構成図を描きました。

WindowsServer2016 (1).png

とっても簡単な構成ですね。四角がEC2です。

構築

  1. AWSのホーム画面から「EC2」を選択
  2. 青いボタンの「インスタンスを作成」を選択
  3. AMIは「Microsoft Windows Server 2016 Base – ami-157fe573」を選択
  4. タイプは「t2.micro」を選択して、「次の手順」を選択。
  5. インスタンスの詳細の設定は「インスタンス数」を1に設定して、「次の手順」を選択。
  6. 「ストレージの追加」は30Gを選択して、「次の手順」を選択。
  7. 「タグの追加」は特に指定せず、「次の手順」を選択。
  8. 「セキュリティグループの設定」は以下が設定されていることを確認して、「確認と作成」を選択。
    画面遷移したら「作成ボタンを」選択。
タイプ プロトコル ポート範囲 ソース
RDP TCP 3389 カスタム 0.0.0.0/0

※ソースを0.0.0.0/0にしている為、どこからでもアクセス可能になっています。
テスト用にデプロイしているので、セキュリティ的にザルな設定になっているので、本番運用を考慮するなら、自宅や職場のグローバルIPからのみ接続できる設定の方が好ましいです。

9. キーペアの作成について聞かれるので、今までに作っていないor新しく作りたい場合は、作成する。

パスワードの確認

AWSの画面からキーペアを使ってユーザー名とパスワードを確認する。
Lunux等に対してSSHで接続する場合はあらかじめ設定されている初期値を入力すれば良いが、Windowsに対してRDP接続する場合は事前にキーペアから独自に作成されるパスワードを確認する必要がある。めんどい

  1. AWSのホーム画面から「EC2」を選択。
  2. インスタンスを選択。
  3. 接続したいインスタンスに対して右クリックし、「Windowsのパスワードの取得」を選択
  4. 先ほど保存したキーペアをアップロードして、ユーザ名とパスワードを確認。

接続

Windowsだと標準のリモートデスクトップを利用、MacだとMicrodsoft Remote Desktopをダウンロードして接続する。
1. リモートデスクトップを起動。
2. 接続先に先程作成した、インタスタンスのIPorホスト名を入力する。
3. 画面が表示されることを確認する。

その他

2018年2月現在で使えるWin2016は全て英語版のみでした。
その内、日本語版も出ると思うけど、案件とかで今すぐ対応しなきゃの人は大変そうですね。

続きを読む

AWS EC2のUbuntuにWindowsからリモートデスクトップで接続し、Ganacheを起動する手順

やりたいことはこちら

  • AWS EC2のUbuntu 16.04に、ローカルのWindows 7からリモートデスクトップで接続する
  • Ganacheを起動する

参考: https://aws.amazon.com/jp/premiumsupport/knowledge-center/connect-to-ubuntu-1604-windows/

まずは、Ubuntuでリモートデスクトップが使えるように設定していきます

EC2インスタンスの設定

TeraTerm等のターミナルからインスタンスにSSH接続して設定をします

パスワードでログインできるように設定

$ sudo vi /etc/ssh/sshd_config 

---------
# 以下のように編集
PasswordAuthentication no
 ↓
PasswordAuthentication yes
---------

# ssh再起動
$ sudo /etc/init.d/ssh restart

# リモートデスクトップのログインに使うパスワードを設定します
# 推測されやすいものにしないように注意
$ sudo passwd ubuntu

デスクトップ表示に必要なパッケージをインストール

$ sudo apt install xrdp xfce4 xfce4-goodies tightvncserver

# いろいろ設定を変更
$ echo xfce4-session> /home/ubuntu/.xsession
$ sudo cp /home/ubuntu/.xsession /etc/skel

$ sudo vi /etc/xrdp/xrdp.ini

# 以下のように編集
---------
 [xrdp1]
port=-1
 ↓
 [xrdp1]
port=ask-1
---------

$ sudo vi /etc/xrdp/startwm.sh

# 以下のように編集
---------
. /etc/X11/Xsession
 ↓
startxfce4
#. /etc/X11/Xsession
---------

# xrdp再起動
$ sudo service xrdp restart

EC2コンソールでポートを開放

RDPポートを開放するために、AWSのEC2コンソールを表示してセキュリティグループの設定を変更します。
開放するポート番号は 3389 です。

インスタンスを選択し、セキュリティグループをクリックします。
「インバウンド」を以下のように編集し、3389ポートでアクセスできるようにします。
WS000299.JPG

ここまででインスタンスの設定は終わりになります。

リモートデスクトップで接続しましょう

ここからはWindows 7で操作していきます

リモートデスクトップでインスタンスに接続します
WS000298.JPG

usernameはubuntu、パスワードは先ほど設定したものを入力します
ポート番号は-1のままで、OKを押します
WS000293.JPG

デスクトップが表示されました!
WS000294.JPG

せっかくなのでアプリケーションを起動してみます

ここからは、リモートデスクトップで操作していきます
GanacheというEthereumのウォレットを起動してみることにします

ブラウザを起動し、Ganacheをダウンロードします
http://truffleframework.com/ganache/
WS000295.JPG

ターミナルを開き、実行権限を付与しておきます

chmod a+x ~/Downloads/ganache-1.0.2-x86_64.AppImage

ファイルマネージャで、ファイルをダブルクリックします
WS000296.JPG

Ganacheが起動しました
WS000297.JPG


ここまで、以下の手順についての説明でした。

  • AWS EC2のUbuntu 16.04に、ローカルのWindows 7からリモートデスクトップで接続する
  • Ganacheを起動する

続きを読む

LightSailでWindows Server立ち上げて日本語化してみた

はじめに

kintoneでSAML認証を使用したSSOを実現するのWindows Server部分の設定です。

ちょっと検証用にサーバー使いたいってなった時に、EC2もラクはラクなんですがもっと手軽なものあるやんけ!ということでLightSail使ってみたのでメモ。

リージョンもいろいろ選べるようになっているのと、うまく使えばEC2よりコスト抑えられるのと、単体でぽこっと立てるだけならこれで十分やんって感じ。

EC2は一応これで1ヶ月あたりのランニング費用を試算。
AWS Simple Monthly Calculator(簡易見積ツール)

LightSailの価格体系

うん。わかりやすい。今回はADとADFS入れるだけで他に何かバックエンドでゴリゴリ動かすわけでもないので、LightSailの1番安いプランにする。
lightsail_plan.png

しかもStaticIP(AWSでいういわゆるEIP)ひとつ付けられるみたいなのでなんだかお得感。
セキュリティグループとか細かく設定したいならEC2のほうがいいかもしれないけど、個人ユースでテスト用って考えるとこれくらいで十分。

構築のプロセス 〜 LightSail起動

マネコンからプランとリージョン選択してぽちぽちするだけでインスタンスが立ち上がる。
東京リージョンも選択できます。
lightsail2.png

インスタンスの名前をつけて・・・
lightsail3.png

WindowsはWS2K16と2K12R2のどちらか選択可能。
特に支障ないのでWS2K16にしたよ。
lightsail4.png

構築のプロセス 〜 立ち上げたLightSailにStaticIPアタッチ

起動までは数分もかからない。この時点でもPublicIPは振られるんだけど、これがおそらくrebootとかかけるとIPが変わっちゃう。なのでIPを固定化するためにStaticIPをアタッチする。
lightsail5.png

アタッチする時も画面に沿って設定するだけ。
lightsail6.png

StaticIPがアタッチされた。
lightsail7.png

アタッチした後はIP表示のところにピンマークが付きます。
lightsail8.png

Windows Server 〜 ログイン

ここまでできたらいよいよログインです。ラクなのがなんとRDP用のターミナルがあるんだよ。セルフで自分のRDP Clientを利用することも可能だけど、特に問題なかったらこれで十分かも。
lightsail10.png

Windows Server 〜 ロケール設定

デフォルトのロケールが英語なので、そのままでも良いんだが今回はわかりやすいように日本語に変更する。
ロケールの設定は普通のWindowsと同じ。
Add a languageで言語を追加してOptionsからLanguage Packをダウンロードする。
lightsail11-1.png

その後Set as defaultでデフォルト設定にする。
lightsail14-1.png

サインインし直すと言語変わるよーと出ているのでログインし直す。
lightsail12.png

ちゃんと日本語になってることを確認。
lightsail13.png

このあとWindows Updateとかかけたけど時間帯のせいなのかレスポンスが重かった。。。
午前中とかだとRDPのターミナルとかもさくさく快適だし、試す時間帯は考えたほうがよさげ。

続きを読む

AWSアカウントのセキュリティ設定

AWSを利用してセキュアなインフラを構築する上で、EC2インスタンスなどの設定も大事ですが、AWSアカウント自体のセキュリティ設定を行うこともとても重要です。
本投稿ではCIS(Center of Information Security)が提供しているCIS Amazon Web Services Foundationsを題材に、AWSアカウントのハードニングについて説明したいと思います。

概要

CISドキュメントは大きく分けて以下の章から構成されています。
1. 認証・アクセス制御 (Identity and Access Management)
2. ロギング (Logging)
3. モニタリング (Monitoring)
4. ネットワーク (Networking)

各ポイントを抑えていくことで、特定のアクセスのみを許可し、それらのアクセスを記録し、意図しないアクセスを検知することが実現されます。
1~3ではIAMを使ってAWSアカウント内のイベントを対象として設定を行っていきますが、4ではVPC内のトラフィックについて個々のネットワーク設定に依存しないAWSアカウント内で共通の設定を行います。

1~3ではIAMを中心として, AWSが提供する複数のサービスを利用して設定を行っていきます。下図が設定全体の概要になります。
全体概要図

以下、CISドキュメント内の各章について順番に説明していきます。

1. 認証・アクセス制御 (Identity and Access Management)

認証・アクセス制御概要図

AWSアカウントの認証・アクセス制御はIdentity and Access Management(IAM)を用いて行います。IAMを用いることで、AWSアカウント内のリソースへアクセスを行うユーザの管理、各ユーザの多要素認証・パスワードポリシなどの認証設定、呼び出し可能なAPIの制限などのアクセス制御を行う事ができます。

AWSアカウント作成直後はルートアカウントのみが用意されていますが、ルートアカウントはすべての操作を行う権限があるためアカウント全体の管理を行う場合のみ利用し、通常はIAMユーザを使うことが推奨されています。

また、CISドキュメントにはインシデント発生時に用いられるAWSからの連絡窓口の登録や、詳細な請求情報表示を有効化する、といったIAMの設定以外の項目も含まれています。

使用したサービス

  • IAM: ユーザアカウントの認証・アクセス制御

2. ロギング (Logging)

ロギング概要図

CloudTrailを使うと、管理画面へのログインやセキュリティグループの変更などAWSアカウント内の様々なイベントログを自動的に保存することができます。これにより意図しない操作が行われていないかを監視したり、インシデント発生時などにAWSアカウント内でいつ、何に対して、どのような操作が行われたのかを調査したりすることが可能になります。

これらのログはSimple Storage Service(S3)に保存されますが、Key Management Service(KMS)を使うことでS3内に保存されたログを暗号化したり、S3のアクセスログ機能を有効化することでログを保存したバケット自体の完全性をチェックすることができます。

CloudTrailのログはS3に保存するだけでなく、同時にCloudWatch Logsにも保存することができます。CloudWatch Logsを利用することで、リアルタイムにログの検索を行ったり、特定の条件に合致するログレコード発生を自動的に検知できるようになります。

上図に示したCloudTrailによるログ保存以外にも、Configを有効化することが推奨されています。Configは監査ポリシーを設定しておくことで、AWSアカウント内の各設定がそのポリシーに違反していないかを定期的にチェックしてくれるサービスです。また、これを有効化するとAWSアカウント内のリソースの変更履歴が自動的に保存されるため、インシデント発生時などの調査にも利用することができます。

使用したサービス

3. モニタリング (Monitoring)

モニタリング概要図

前章でCloudTrailによるCloudWatch Logsへのログ転送を設定しました。CloudWatch Logsにはあらかじめ設定した条件に合致したログレコードの出現を監視し、Simple Notification Service(SNS)を使って通知を行う機能があります。SNSを使うとこれらの通知をEメールやWebhookなど様々な手段で受け取る事ができます。

CISドキュメントでは例えば以下のような条件の監視設定を推奨しています。

  • 認証失敗や許可されない操作の実行
  • セキュリティグループなどのネットワーク設定変更
  • CloudTrailなどロギング設定の変更

これらの監視設定は14項目ほどの具体的な設定内容がCISドキュメントに記載されているので、すべて設定することをお勧めします。

使用したサービス

  • CloudWatch Logs: 特定パターンに適合するログの自動検出
  • SNS: ログから検出されたイベントの通知

4. ネットワーク (Networking)

AWSアカウント内に実際にネットワークを構築していくにはVirtual Private Cloud(VPC)を使いますが、本章では実際に構築する個々のネットワークではなくAWSアカウント全体として行っておくべき設定について記載されています。

VPC Flow Logsを有効化することで、VPC内で発生したIPトラフィックをすべてログとして保存することができます。各ログレコードにはそのトラフィックが許可(ACCEPT)されたか、拒絶(REJECT)されたかも含まれるため、例えば拒絶されたトラフィックのログを監視することで攻撃の検知などを行うことができます。

また、CISドキュメントではその他に以下のようなチェックを推奨しています。

  • すべてのSecurityGroupで22番(SSH)や3389番(RDP)のポートがインターネット全体へ公開されていないか?
  • デフォルトのSecurityGroupですべてのトラフィックが遮断されているか?
  • VPCピアリングが使用されている場合に最小の権限設定が行われているか?

使用したサービス

まとめ

VPCネットワークやEC2インスタンスなどのセキュリティ対策に目が行きがちですが、AWSではアカウント全体のセキュリティ対策を行う手段を多く提供しています。本投稿ではCISが提供するCIS Amazon Web Services Foundationsを基に、AWSアカウントのハードニングを行う手段について説明しました。

また、AWSがGitHub上に公開しているaws security benchmarkにはCIS Amazon Web Services Foundationsへの適合状況をチェックして採点してくれるPythonスクリプトが含まれています。自身のAWSアカウントが適切に設定されているか、また設定が終わった際に設定ミスがないか、などをチェックする際に便利かと思います。

続きを読む

AWS VPC環境構築 ピアリング接続

前回AWS VPC環境構築で一つのPublic VPCを作ってみましたが、複数VPCを作って、VPC間の通信を実現した場合、Peeringを利用します。

VPC構成イメージ

前回のPublic VPCの横に、Private VPCを作成します。Private VPCはオンプレとつなぐため、よりセキュアなネットワーク環境を構築するためによく利用されます。

VPC作成

手順は省略しますが、
image1.png
IPv4 CIDR blockは10.100.1.0/24として作成します。

image2.png

Subnet作成

Public VPC同様にsubnetを二つ作成します。

IPv4 CIDR block アベイラビリティゾーン 有効なIPv4数
10.100.1.0/27 ap-northeast-1a 27
10.100.1.32/27 ap-northeast-1c 27

image3.png

構成図は以下となります。
image4.png
10.100.0.0/24は前回作成したPublic VPC、10.100.1.0/24は今回作成したPrivate VPCです。

EC2インスタンス作成

VPCとSubnet構築したら、同じくEC2インスタンスを作成可能です。

詳細は省略しますが、Step3:Configure Instance Detailsの設定だけ配置したいVPCとSubnetを選択し、Createします。
今回はPrivate VPC内にEC2インスタンスを作成するため、Internet接続なくてもよいので、Auto-assign Public IPをDisableにします。
image5.png
構成図にEC2が追加されます。
image6.png

Private VPCにIGWもないので、EC2へのアクセスやRDPができない状態です。ここで、Peeringを作成して、sample-public-ec2を踏み台として、接続します。

Peering作成

VPCのメニューから「Peering Connections」を押して、一覧画面を表示します。
「Create Peering Connection」ボタンでPeeringを作成します。
image7.png

項目 入力値 説明
Name tag sample-vpc-peering ピアリング名(任意)
VPC(Requester) sample-public-vpc ピアリング接続を作成するアカウントのVPC
VPC(Accepter) sample-private-vpc 接続先のVPC

image8.png
「Create Peering Connection」を押して、
image9.png
この状態では、Peeringはまだ有効ではありません。

PeeringのActive

image10.png
「Accept Request」して、初めて有効になります。
image11.png
image12.png
image13.png
これで構成図は変わります。
image14.png
だだし、この状態だけではVPC間の接続はまだできないです。理由はルーティングテーブルは未設定です。

ルーティングの構成

VPCのルーティングテーブルにPeeringの設定はないので、追加が必要です。
image15.png
まずPublic VPCのルーティングテーブルに送信先のPrivate VPC(10.100.1.0/24)のターゲットを作成したPeering(pcx-xxxxxx)に設定
image16.png

次にPrivate VPCのルーティングテーブルに送信先のPublic VPC(10.100.0.0/24)のターゲットを作成したPeering(pcx-xxxxxx)に設定
image17.png
必ず両方を設定する必要があります。
image18.png

疎通確認

sample-public-ec2とsample-private-ec2を起動して、sample-public-ec2からsample-private-ec2にRDPします。
image19.png
成功!!!
image20.png

続きを読む

AWS VPC環境構築

一つのAWSアカウント上に複数プロジェクト環境を構築する際に、VPCごとに分けると管理がしやくなります。
デフォルトはVPCは172.31.0.0/16なので、それと同じ環境を自前で構築してみました。

制約

1.AWSではリージョンごとに最大5VPCが作成可能です(上限緩和申請すれば、それ以上も作成可能)
2.VPCを作成する際に利用するIPアドレス範囲は/16~/28のサイズまで指定可能
3.VPCで利用するIPアドレス(プライベートIPアドレス)は下表で

Private IP範囲
10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

VPC構成イメージ

もっともシンプルな構成をまず作ってみます。
image1.png

VPC作成

AWSのサービスでVPCを選択し、VPCダッシュボートで作成できます。
「Start VPC Wizard」ボタンで、用意された各種テンプレートから簡単に作成できますが、
理解するために、Wizardを利用せず、マニュアルで作っていきます。

your VPCsで一覧を表示し、「Create VPC」ボタンをクリックします。
image1.png
Name tagに適切な名前を入力し、IPv4 CIDR blockは10.100.0.0/24として、小さめに作成します。
image3.png

構成図からは下記となります。
image2.png

Subnet作成

上記通り、VPCはあくまでネットワークアドレスを確保しただけで、インスタンスを配置するにはSubnetを作成し、その中に作る必要があります。
同じVPCメニューからSubnetsを選んで、サブネット一覧画面へ行きます。
「Create Subnet」ボタンを押して、まず以下のような二つを作成します。

IPv4 CIDR block アベイラビリティゾーン 有効なIPv4数
10.100.0.0/27 ap-northeast-1a 27
10.100.0.32/27 ap-northeast-1c 27

AWSにおけるIPv4 用の VPC とサブネットのサイズ設定は以下を参考
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Subnets.html#vpc-sizing-ipv4

作成
image4.png
image5.png
「Yes, Create」ボタン押して作成完了
image6.png

構成図からは下記となります。
image7.png

EC2インスタンス作成

VPCとSubnet構築したら、次はEC2インスタンスを作成可能です。

詳細は省略しますが、Step3:Configure Instance Detailsの設定だけ配置したいVPCとSubnetを選択し、Createします。
※Auto-assign Public IPをEnableにすることを忘れるとInternetでRDPができなくなります。
image8.png

構成図からは下記となります。
image9.png

早速RDPして、サーバに入りたいですが、まだこの段階ではサーバに接続できないです。
Internetをつなげるためにはインターネットゲートウェイが必要です。

IGW作成&アタッチ

同じVPCのメニューから「Internet Gateways」を押して、一覧画面を表示します。
「Create Internet Gateways」ボタンでインターネットゲートウェイを作成します。
Name tagに sample-igw-publicを入れて、「Yes, Create」をクリック
image10.png

image11.png

作成したら、Stateはまだdetachedの状態です。
右クリックして、「Attach to VPC」を選択、対象VPCにアタッチします。
image12.png
Stateが変わりました。
image13.png
アタッチはできたものの、インターネットと通信するために、サブネットのルートテーブルをシュウセイする必要があります。

ルーティングの構成

VPCのRoute table IDからRoute talbeの設定画面にたどり、
image14.png
Routesタブで「Edit」ボタンを押して、項目追加します。
このルートテーブルに対して、「0.0.0.0/0」を送信先としてターゲットに対する通信を、作成したインターネットゲートウェイ(igw-xxxx)をターゲットとする項目を追加します。
「Save」して確定します。
最後に、EC2 sample-public-ec2を起動して、RDP接続します。
image15.png

続きを読む

アクセスできなくなったWindowsインスタンスをAWSSupport-ExecuteEC2Rescueで復旧する

概要

AWSからEC2Rescueというツールが提供されていて、EC2インスタンスのトラブルシューティングに使用できます。

ただしネットワーク的な問題がありインスタンスにログインできないといった場合、復旧作業用のインスタンスを立ち上げて問題のあるインスタンスからEBSボリュームをデタッチ、復旧用インスタンスにアタッチしてEC2Rescueを実行、ボリュームを再び元のインスタンスに戻すというような手順が必要でした。
トラブル発生中にこの手順を間違いなく実行するのは難しいものがあります。

今回、そんな一連の作業をSSM Automation(自動化)でまとめて実行してくれるAWSSupport-ExecuteEC2Rescueドキュメントが提供されているのを見つけたので試してみました。
(※2017/10現在Windows限定)

詳細については以下公式ドキュメントを確認してください。

事前準備

IAM Roleの作成

事前準備としてSSM Automationが使用するIAM Roleを作成します。
Role作成用のCloudFormationテンプレートが提供されていたのでそのまま利用しました。
http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/automation-ec2rescue.html#automation-ec2rescue-access-cfn
IAM_Management_Console.png

障害EC2インスタンスの作成

障害が発生したという想定のインスタンスを作成します。
EC2_Management_Console.png

UnreachableInstance.png

手違いでDHCPで割り当てられているアドレスと関係ないアドレスを設定してしまいました。
UnreachableInstance 2.png

RDP接続が切断され、
UnreachableInstance 5.png

しばらくするとインスタンスステータスチェックにも失敗するようになります。
EC2_Management_Console 2.png

AWSSupport-ExecuteEC2Rescue を実行

マネジメントコンソールからAutomationを開きます。
AWSSupport-ExecuteEC2Rescueドキュメントを選択、パラメータに復旧したいインスタンスのID、作成したIAM RoleのARNを入力し実行します。
EC2_Management_Console_3.png

復旧処理が開始されました。
EC2_Management_Console 4.png

CloudFormationでLambda Function、復旧用インスタンスなどが展開されます。
Lambda_Management_Console.png

EC2_Management_Console 5.png

一連の処理が完了したようです。この時は障害インスタンスの再起動に15分、作業時に作成されたリソースの削除も含めた完了に20分程度かかっていました。
createBackup がタイムアウトしていますが作業前に障害インスタンスのAMIバックアップが行われており、実際には問題なく作成されていました。
EC2_Management_Console 8.png

確認

障害インスタンスのインスタンスステータスチェックに合格しています。
EC2_Management_Console 7.png

RDP接続も問題なくでき、DHCP設定が元に戻されていました。
UnreachableInstance 6.png

ステップrunEC2Rescueのログはこうなっていました。
DHCPを有効化すると同時にWindows Firewallも無効化したようです。

runEC2Rescue
CommandId : 9b0b2297-0838-40cd-b49e-fb924bbadc29

Output : ===== System Information =====
Operating System: Windows Server 2016 Datacenter
Service Pack: -
Version: 10.0.14393
Computer Name: EC2AMAZ-4T6ARMO
Time Zone: UTC
.NET Framework:
    v4.7 (4.7.02053)
EC2Launch Version: 1.3.630

===== Analysis =====
System Time
  OK - RealTimeIsUniversal (Enabled): This registry value should be enabled when timezone is not UTC.
Windows Firewall
  Warning - Domain networks (Enabled): Windows Firewall will be disabled.
  Warning - Private networks (Enabled): Windows Firewall will be disabled.
  Warning - Guest or public networks (Enabled): Windows Firewall will be disabled.
Remote Desktop
  OK - Service Start (Manual): Sets Remote Desktop service start to automatic.
  OK - Remote Desktop Connections (Enabled): The RDP listening port will be changed to TCP/3389.
  OK - TCP Port (3389): The RDP listening port will be changed to TCP/3389.
EC2Launch
  OK - Installation (Installed): EC2Launch 1.3.630 is installed.
  Information - Reset Administrator Password (Disabled): 
Network Interface
  OK - DHCP Service Startup (Automatic): The service will be set to start automatically.
  Information - ?????? 2 detail (N/A): AWS PV Network Device (7.4.6.0)
  Warning - DHCP on ?????? 2 (Disabled (Static: 172.21.27.100)): DHCP will be enabled.

===== Changes =====
Windows Firewall
  OK - Domain networks (Disabled)
  OK - Private networks (Disabled)
  OK - Guest or public networks (Disabled)
Network Interface
  OK - DHCP on ?????? 2 (Enabled)



ResponseCode : 0

Status : Success

まとめ

障害発生時に大きな手間なくトラブルシューティングを行えるので重宝しそうです。
IAM Roleだけでも事前に作成しておくと良さそう。

Linux対応版にも期待したいですね。

続きを読む

Amazon EC2(ubuntu)にTalend Open Studioをセットアップしてみる

Amazon EC2(ubuntu)にTalend Open Studioをセットアップしてみる

概要

とあるサービスの移行ジョブ一式を最速で作る必要があり、ローカルのmacでtalendを使って移行ジョブをガリガリ作りました。

作るのすごく楽で、最高!…と、そこまでは良かったのですが、全資材がローカルPCにあり、最終的には共有しとかないとメンテが面倒な代物となってしまいました。

適切に引き継ぎできるようAmazon EC2上に構築して、ジョブを移設したいと思います。

注意:本記事は、うまくいったぜ!という記事ではありません。

Linux Desktopを採用したことで片付けなければならない事が割とあったね!という内容の記事です。jobを実行するだけのニーズなら満たせると思います。

インストール要件

ちょっと調べた限りだとこんな感じかと。

amazon workspaceだとtalendは動作しないっぽい?→talend forum

後から気付きましたが、よく読むと「for BigData」限定の話っぽい。

  • JDK1.7.x(注:talend 6.4系よりjdk1.8.xが標準
  • Ubuntu 14.4(公式のTalend Data PresentetionのAMIがこのバージョンだった)
    • desktopをインストール
  • talend 6.3(2017/03時点のバージョン.このバージョンでジョブ作成していた注:2017/07/10現在、talend 6.4系がダウンロード可能
  • t2.smallまたはt2.medium

FYI

Talend Open Studio for ESB インストレーションガイド

実際に入れるのは「for Data Integration」ですが、参考情報です。

手順

事前準備

EC2インスタンス作成は、記述から割愛します。
「ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-20170619 (ami-8c4055eb)」を使いました。

まず接続。。。

chmod 400 ST_Talend01.pem
ssh -i "ST_Talend01.pem" ubuntu@ec2-XXX-XXX-XXX-XXX.ap-northeast-1.compute.amazonaws.com
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-121-generic x86_64)

…(中略)

パッケージアップデート

sudo apt-get update
sudo apt-get -y upgrade

日本語環境に変更

ありがちな文字コードやロケール、timezoneの設定などです。
root権限に変えてコマンド実行します。

sudo su
apt-get install -y language-pack-ja
update-locale LANG=ja_JP.UTF-8

timedatectl set-timezone Asia/Tokyo

確認するために、一度、sshを抜け、再度接続。

以下のようになっていればOK.

$ locale
LANG=ja_JP.UTF-8
LANGUAGE=
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=
$  timedatectl 
      Local time: 火 2017-07-11 16:40:01 JST
  Universal time: 火 2017-07-11 07:40:01 UTC
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

追記

http://uyama.coffee/wp/【決定版】aws-ec2でリモートデスクトップ/
に従い、以下パッケージも追加インストールしました。

$ sudo apt-get install ibus-anthy
$ sudo apt-get install scim-anthy
$ sudo apt-get install fcitx-anthy

1. ubuntu desktopをインストール

amazon ec2 ubuntu マシンに windows からリモートデスクトップ接続する

こちらを参考に、そのまんまの手順を実施しました。

2. ubuntu desktopへリモート接続できるようにする

前提条件

セキュリティグループの設定で以下ポートのインバウンドを許可していること。

種類 ポート
RDP 3389
VNC 5901

セキュリティグループ設定時は、インバウンドを許可するIPを厳密に指定しましょう。

mac

  1. サーバ側でvncserverコマンドを実行。
  2. 接続パスワードを設定。
# vncserver

You will require a password to access your desktops.

Password:
Verify:
Password too long - only the first 8 characters will be used
xauth:  file /root/.Xauthority does not exist

New 'ip-XXX-XXX-XXX-XXX:1 (root)' desktop is ip-XXX-XXX-XXX-XXX:1

Creating default startup script /root/.vnc/xstartup
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/ip-XXX-XXX-XXX-XXX:1.log
  1. vncserverの設定を変える。
rm ~/.vnc/xstartup
ln -s /etc/X11/Xsession ~/.vnc/xstartup

画面共有.appを使い、ホスト名:5901で接続。

こんな感じです。

mac_to_ubuntu.png

FYI

一部、以下ページを参照しました。

AWS EC2 の Ubuntu に GUI を入れてブラウザ操作を自動化する話

windows

apt-get install xrdp
 * Starting Remote Desktop Protocol server 

apt-get install xfce4
sudo vim /etc/xrdp/xrdp.ini

[xrdp1]
name=sesman-Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
#port=-1
port=ask-1

windows のリモートデスクトップで接続確認できればOK

※再起動後にリモート接続できていない。
RDP, vnc両方とも。

https://futuremix.org/2009/01/linux-vnc-server-install
vncserverの自動起動を設定

トラブルシューティング

Q. 接続できたけど、何も表示されない…

Xubuntu 14.04 を再起動したら、デスクトップにアイコンが表示されず、右クリックもできず、壁紙も設定したものではなくデフォルトのものから変更できなくなっていました(設定しても反映されない)。

最初は、設定 > デスクトップ > メニュー でデスクトップにアイコンを表示しない設定にしてしまったのかと思いましたが、そういうわけでもないようです。再起動しても直らず、おそらくデスクトップの機能を提供するサービスが立ち上がってなさそうです。

解決策としては、 terminal で

$ xfdesktop

でデスクトップが復活します。

3. javaをインストール

sudo add-apt-repository ppa:webupd8team/java
sudo apt update
sudo apt install oracle-java8-installer
失敗例

jdk7を入れたが、talend 6.4系からjava8が標準になっていた

sudo apt-get install openjdk-7-jdk

確認。

# java -version
java version "1.7.0_131"
OpenJDK Runtime Environment (IcedTea 2.6.9) (7u131-2.6.9-0ubuntu0.14.04.2)
OpenJDK 64-Bit Server VM (build 24.131-b00, mixed mode)

4. talendをインストール

  • linuxデスクトップにリモート接続し、talendサイトより「Talend Open Studio for BigData 20170623_1246-V6.4.1」をダウンロード

「Open Studio for Data Integration」

  • 「/usr/local/talend」フォルダを作成し、同フォルダに解凍。

  • TOS_DI-linux-gtk-x86_64 を実行。

ここまででtalendの起動はできました。

詰めが甘かったと反省

特に拘りなくubuntu + xfce4を選んだのですが、ここまで突っ走り過ぎました。。。
色々と不都合があり、さぁどうしよう状態に。

自動起動の設定が足りていない
  • vncserver
  • xfdesktop
macの日本語キーボードで、日本語入力がうまくいかない

…macだけでいい感じにしても、後任者は使えるのだろうか…

画面解像度を「1440×900」に変えたいが、できない

disp_config.png
disp_config_err.png

xfce特有の問題にぶちあたり、デスクトップ設定に関しては、見直した方が良さそうな結果に。

一見わかりづらいですが、talendでジョブを組むうえで画面領域が小さすぎるのは、かなり致命的。

  • mac

mac_talend2.png

  • ubuntu + xfce

talend_1280_1080.png

初期処理でモニターの解像度を指定する

このあたりを対処すればOKなのかもしれませんが、1日で完結させるつもりだったので一旦時間切れ。

もう一声!をつぶせばボチボチ使い物にはなるのでしょうが、私の場合は「他の方が使える」という目的から外れてた…と作業中に気づいてしまいました。

windowsベースのamazon workspaceに立て直そうかな、と思います。

続きを読む

AWS Windows Server 2016でのJMeter環境構築

この記事では、AWS ec2のWindows Server 2016に、JMeter3.2の環境構築をしました。リモートデストクップクライアントは、Microsoft Remote Desktop for Mac Beta version 8.2.31を利用しています。

この記事の発展として、CentOSでのスレーブと組み合わせた分散環境の構築について「AWS Windows Server 2016でのJMeter環境構築(分散環境編)」で解説しています。

1. Windows Serverの環境構築

1.1. Windows Serverのインスタンス作成

AMIのクイックスタートから、Microsoft Windows Server 2016 Base、インスタンスタイプt2.mediumを選択します。

セキュリティグループを以下に設定します。

タイプ プロトコル ポート範囲 送信元
すべてのトラフィック すべて すべて 172.31.0.0/16
RDP TCP 3389 マイIP

タグとして、Name: ec2-JMmasterを追加します。

キーペアを作成するか既存のものがあれば選択して、インスンスを作成します。

1.2. リモートデスクトップ接続

ec2マネジメントコンソールから、先ほど作成したec2-JMmasterを選択して、上にある「接続」ボタンを押下します。ダイアログボックスにおいて「パスワードの取得」を選択して、キーペアの中身をコピーして、バスワードを表示させます。

リモートテスクトップクライアントに表示された内容を設定します。

サーバーをシャットダウンするとパブリックIPアドレスが変わるため、リモートデスクトップクライアントのPC nameを再設定する必要がありますので、注意してください。

これで、リモートデスクトップからWindows Serverにログインできます。

自動的に初期設定された後、他のPCから検索されてよいか?と出ますので、とりあえずNOとしておきます。

1.3. Windowsの日本語化

コントロールパネルからAdd a languageを選択します。日本語を追加して、Optionsをクリックして、Download and install language packをクリックし、インストールします。

インストール完了後、再度Optionsをクリックして、Make this the primary languageをクリックし、ログオフします。

再度リモートデスクトップからログオンすると、日本語環境になっています。

コントロールパネルから、時計、言語、および地域を選択して、タイムゾーンを日本に変更します。また、地域をクリックして、ダイアログボックスの場所タブで日本を、管理タブでシステムロケールを日本に変更します。(再起動が必要です)

次に、キーボードを日本語配列にしたいのですが、macのリモートデスクトップで日本語配列キーボードを使うのは難関のようです。いろいろググって試すものの、私の環境ではうまくいきませんでした。

1.4. IEのセキュリティ設定の解除

デフォルトでは、IEセキュリティ強化の構成がオンになっており、あちこちブラウズして必要なソフトをダウンロードするにあたって、頻繁にアラートが表示されますので、これをオフにしておきます。

「サーバー マネージャ」で、「ローカル サーバー」「プロパティ」セクションで、オプション「IE セキュリティ強化の構成」の設定を「オフ」に切り替えます。

2. JMeterのインストール

2.1 Javaランタイムのインストール

Javaのランタイムをインストールします。この記事では、Version 8 Update 131(リリース日 2017年4月18日)でした。

2.2 JMeter本体のインストール

Download Apache JMeterのページから最新版v3.2をダウンロードして、展開します。出来上がったapache-jMeter-3.2フォルダを、Program Filesに移動して、bin配下のjmeter(Windowsバッチファイル)のショートカットを、デスクトップに配置してくと便利です。

バッチファイルにより、JMeterが無事に起動することを確認します。

スクリーンショット 2017-05-05 13.57.57.png

2.3 JMeter pluginsのインストール

Download JMeter-Plugins.org から、plugins-managerをダウンロードして、JMeterのlib/extに配置します。再度JMeterを起動すると、オプションメニューでPlugins Managerを選択できるようになります。

ここでは、Plugins Managerから、3 Basic Graphsを選択して、イントスールしておきましょう。

3. JMeterの実行

3.1 テスト計画の作成

ツリーメニューの中から、テスト計画を右クリックして、スレッドグループを選択します。

スクリーンショット 2017-05-05 14.11.06.png

スレッド数1000、Ramp-Up期間10、ループ回数10を設定します。
なお、スレッド数をかなり大きくすると、テストが正常に終了しないようです。

スクリーンショット 2017-05-05 15.11.40.png

テスト計画を再度右クリックして、リスナーからjp@gc – Transactions per Secondを選択します。

スクリーンショット 2017-05-05 14.15.17.png

スレッドグループを右クリックして、サンプラーからHTTPリクエストを追加します。

スクリーンショット 2017-05-05 14.17.47.png

別に用意してあるWebサーバー名(IPアドレス)と、パスを指定します。

スクリーンショット 2017-05-05 14.20.08.png

以上で準備は終わりです。作成したテスト計画をセーブしておきます。

3.2 テスト実行と結果の確認

ツールバーから、緑の右三角をクリックしてテストを実行します。
実行結果はグラフで見ることができます。

スクリーンショット 2017-05-05 15.12.43.png

続きを読む