こんにちは、hmです。

ここ最近、監視ツールの調査をしており、面白そうなものを見つけたので、
紹介したいと思います。

なお、今回はあくまで特徴をお伝えするにとどめます。
構築手順は別途お伝えしますが、すごく楽です。
(この点もPrometheusのいいところでもあります。)

Prometheus

ふわっと特徴をお伝えすると、

1.Pull型のOSS監視ツール
Pull型とは、サーバー側から監視先ホストのポートをたたいて回ります。
そのため、サーバー側にはホストの情報を覚えさえてなければなりませんが、
すべて書く必要はなく、service discoveryを使えば簡単に設定、かつ監視対象の絞り込みが
できます。

scrape_configs:
- job_name: ‘my_ec2_hosts’

# EC2 Service Discovery Config
ec2_sd_configs:

- region:
access_key:#アクセスキー
secret_key:#シ-クレットキー
port: 9100 # 監視対象ポート

2.Golang製

3.扱えるのは数値のみ(ログ監視もできそうですが、まだ調査中です)
ここは私がまだわかってないところですが、サーバーがとってくる情報は、数値情報です。
ログの文字列をとってくるというのは、exporter(エージェント)を書かなければならないのですが、あるのかは今はまだ調査中です。

4.ラベルで監視したい項目の絞り込みが簡単
例えば、「この役割で、このステージで、こういうグループの…」
みたいな絞り込みが可能です。

・サービスやステージにかかわらず、Webサーバーのロードアベレージが見たい!
ということであれば、下記のようなクエリを投げれば見ることができます。
node_load5{Role="web"}

また、クエリ自身もぱっとみてわかりやすく、使いやすいです。
クエリ詳細はこちらから!

アーキテクチャ
Prometheusでやっていることは、主に下記の3つです。
・情報をあつめて、ためる。
・アラートを上げる
・クエリへの回答

architecture of prometheus

Web UI
下記は実際に構築したものです。ただし、このWeb UIだけではパッと見て、
わかりづらいかなというのが個人的な意見です。ですので、Grafanaで可視化をしてあげると
よりわかりやすいのかなと。別の記事で紹介をしようかと思います。

下記はホーム画面です。デフォルトは、http://localhost:9090/graphです。
WS000003
クエリはこんな感じでリストになってます。
WS000004
これはmetricsです。監視対象にexporter(エージェント)が入ってないため、
prometheusサーバー自身の情報を表示してます。
WS000005
PrometheusのコンフィグもWeb UIからのぞけます。
WS000000

今回は、ここまでです。次回は、Grafanaの可視化とservice discoveryを設定してみたいと思います。

お付き合いいただきありがとうございました。

備考:
性能については、ユースケースをもとにKibana+Elasticsearchとの組み合わせと比較をしている下記が参考になります。
http://qiita.com/sugitak/items/ff8f5ad845283c5915d2#%E9%AB%98%E6%80%A7%E8%83%BD

ALBでパスベースのルーティングができると何が嬉しいのか~中継ぎ編~

batchiです。

前回の続きからです。
http://www.simpline.co.jp/tech/?p=1739

パスベースのルーティングが必要となるのはどんな場合?というところからです。

ケース1:同じFQDNで別サーバで稼働している場合

パスベースの振り分け

HPと技術ブログを、同じFQDNで異なるサーバ上で動かしていた場合。

ALBであればパスで判断してサーバの振分けが可能ですが、CLBだとそれができません。

上記の構成でCLBを採用した場合、CLBのルーティングアルゴリズムによって
いずれかのサーバにルーティングされ、
運が良ければ然るべきサーバにたどり着くかもね、という状態になります。

ケース2:同一サーバの別ポートで稼働している場合

パスベースの振り分け2

HPと技術ブログが、同一のサーバ上で、異なるポートで動いていた場合。

CLBの場合、下記のような縛りがあるので、基本的に対応できません。

  • ロードバランサーのポート1つあたり設定できるインスタンスのポートは1つ
  • ロードバランサーのポートを重複して指定できない

(80で待ち受けてインスタンスの80に渡す、443で待ち受けて8080に渡す、という無理くりならできる?)

ALBであれば「単一のインスタンスで複数のポートにルーティング」ができます。

CLBを使わざるを得ないのであれば、
FQDNの異なる2つのCLBを用意する、といった対策が必要になります。

余談

「ALBでパスベースのルーティングできると何が嬉しいのか」に対する答えは、
「上記のケースにも対応できるから」で終了なのですが、
自分がこんがらがっていた部分があるので、
FQDNがらみでの「こんな時どうする?」のケースを書きます。

異なるドメインで同一サーバにルーティングしたい

例えば、https://infilic.co.jpでも、
https://simpline.co.jpでも、同じサーバを向かせたい。

こうしましょう。これはCLBでもALBでも変わりません。

異なるFQDN

…と書いていて思ったのですが、
異なるDomeinNameのHostedZoneが、
同一のELBに対してAレコードのエイリアス設定をすれば、
ELBは1つで済んだりするのでしょうか。

HTTPSで待ち受けたい時どうするの、
(どっちか片方の証明書しかELBにインストールできないでしょ、)と思いましたが、
ACMであれば複数ドメインに対する証明書を用意できると聞いたような聞いてないような。

宿題としてとっておきます。

同じドメインで複数のホスト名を持たせて同じサーバにルーティングしたい

例えばhttps://simpline.co.jpでも、
https://www.simpline.co.jpでも、
https://hoge.simpline.co.jpでも、同じサーバを向かせたい。

Route53でがんばりましょう。CLBでもALBでも変わりません。

ホスト名異なる

レコードセットではワイルドカードが使えるので、
最少で、zoneapexである「simpline.co.jp」と、
「*.simpline.co.jp」の2つを作ってあげれば事が足りそうです。
証明書が対応している前提で。

同じドメインで複数のホスト名を持たせて違うサーバにルーティングしたい

上に同じです。
レコードセットごとに、エイリアス設定するELBを分ければ実現可能です。

続く

実際にパスベースのルーティングをどう実現するかの設定を書くつもりでしたが、
構成図を書くのに疲れたので次回にします。

以上です。

XenServer6.5へXenCenterから接続+Zabbix2.4で監視する②

こんにちはmollyです。

前回のXenServer6.5へXenCenterから接続+Zabbix2.4で監視する①の続きになります。

 

1. XenCenter(Windows専用GUI)をインストールする

XenServer6.5へXenCenterから接続+Zabbix2.4で監視する①の最初にダウンロードした
”XenServer-6.5.0-xenserver.org-install-cd.iso”をダブルクリックすると、
ローカルPCの[スタート]→[コンピュータ]で以下のようにXenServerがBD-ROMドライブとして表示されます。

479f17e8-bf9d-8598-899b-d1c286aedcfe

・「BD-ROM ドライブ(E:)XenServer-6.5.0」→「client_install」と開き、「XenCenterSetup.exe」というアプリケーションを選択すると以下のようなセットアップウィザードが表示されます。そして[Next]をクリック。

WS000005

・XenCenterをどこに置くか、XenCenterを誰が使用するかを決定し、[Next]をクリック。
(インストール作業者のみでなく、全員が利用できるようにする場合はAll Usersを選択します)WS000007

・画面が切り替わって[Install]をクリックすると、インストールが始まります。インストールが終わったら[Finish]を押してセットアップウィザードを閉じます。

WS000008

 

2. XenCenterを利用してXenServerへ接続する

・Windows画面左下の[スタート]から「citrix」と検索するとXenCenterが出ます。
・XenCenterを選択すると以下の画面が表示されます。

WS000009

・画面中央の[ADD a server]を選択すると以下の画面が表示されるので接続先のXenServerの情報を入力して[Add]をクリックします。(XenServerのネットワーク設定が出来ているかチェックしておく)

WS000011

・接続できました。

無題

 

3. XenServerにZabbixエージェントをインストール/設定する

・まずXenServerにSSHで接続します。
・SSHで接続できたら以下のコマンドでzabbix-agentのリポジトリを登録します。

rpm -ihv http://repo.zabbix.com/zabbix/2.4/rhel/5/x86_64/zabbix-release-2.4-1.el5.noarch.rpm

・次に以下のコマンドでzabbix-agentをインストールします。

yum install zabbix-agent --disablerepo=citrix,base,epel

◆/etc/zabbix/zabbix_agentd.confの中を編集

Zabbixサーバーを指定
Server=192.168.XX.XX

Zabbix サーバーを指定
ServerActive=192.168.XX.XX

XenServerのホスト名を指定
Hostname=test-XenServer

◆zabbix-agentの起動と自動起動設定

service zabbix-agent start
chkconfig zabbix-agent on

◆XenServerのポートの開放
zabbixと通信するにはデフォルトで10050ポートを使用する為、10050ポートを開放します。

/etc/sysconfig/iptablesの中に以下の一文を追加
-A RH-Firewall-1-INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 10050 -j ACCEPT

追加したらiptablesを再起動します
/etc/init.d/iptables restart

 

4. Zabbixサーバのブラウザ上で設定する

・zabbixサーバのダッシュボードにアクセスし、[設定]→[ホスト]→[ホスト作成]を選択します。
「ホスト」タブで以下のように設定します。(例)
  【ホスト名】XenServer
  【所属グループ】Virtual machines
  【エージェントのインターフェース】IPアドレス/ポート10050

・「テンプレート」タブで[Template OS Linux]を選択し、そこまで設定したら一旦[追加]します。

zbxagnt

・テンプレートまで設定すればグラフが自動で出来るのでそれらでスクリーンを作成すればXenServerに関するグラフを一気に見ることが出来ます。

graph

 

長々と書いてきましたが以上になります。
AWSはまったく関係のない記事でしたがXenAppやXendesktopがバージョン7.5からAWSでも使えるようになったみたいなので、そちらもキャッチアップ出来たら挑戦してみたいと思います。

ありがとうございました。

XenServer6.5へXenCenterから接続+Zabbix2.4で監視する①

初めまして、mollyです。

技術ブログを更新する機会をいただきました。
AWS関連ではないのですが、自分がせっかく学んで実践してみたことを
共有したいので今回はXen+Zabbixのお話を書かせて頂きます。
長くなってしまいそうなので2つに分けて投稿します。

新しく携わる案件のためにXenを学んだので、XenServer6.5の構築と
継続して勉強していたZabbix2.4での監視をしてみようと思いました。
今回、XenServer6.5はVirtualboxに構築します。

前提
・Zabbixサーバ2.4構築済み+ブラウザでダッシュボードが見られる環境
・Virtualboxにエクステンションパックが入っている

 

1. まずVirtualboxにXenServerの起動準備をします。

ここから「XenServer Installation ISO」を選択してダウンロードします。
・Virtualboxを管理者権限で開いて、[新規]をクリックします。
・【名前】XenServer→【タイプ】Linux→【バージョン】Other Linux(64-bit) このように設定しました。
・次からは以下のように設定しました。
  【メモリサイズ】4096
  【仮想ハードディスク】仮想ハードディスクを作成する
  【ハードディスクのファイルタイプ】VDI(VirtualBox Disk Image)
  【物理ハードディスクにあるストレージ】(可変サイズ)
  【ファイル名】XenServer
  【仮想ハードディスクのサイズ】16GB
・作成した仮想マシンを選択し、画面上の[設定]を押して[システム]→[プロセッサー]→プロセッサー数を2CPUに設定します。

 

2. XenServerを起動します。

・作成した仮想マシンを選択し、画面上の[起動]を押します。
・「起動ハードディスクを選択」という画面が出るので、先ほどダウンロードしてきた”XenServer-6.5.0-xenserver.org-install-cd.iso”を選択する。
・言語選択画面で日本語([qwerty] jp106)を選択。

WS000001

・インストールを続行するか聞かれるので[OK]を選択してEnterを押します。

WS000002

・「End User License Agreement」は、ライセンスに関する同意画面なので[Accept EULA]を選択してEnterを押します。

WS000020

・インストール先のストレージを選択する画面が表示されるので対象のディスクを選択して[OK]を押します。

WS000022

・「Select Installation Source」画面では[Local media]を選択して[OK]を押します。

WS000023

・Supplemental Packのインストールをするかどうか聞かれるので、[Yes]を選択(自由)する。
次に聞かれるテスト(Verify Installation source)も行うかはどちらもでもよい。

WS000024

WS000025

・その他もろもろの設定をします。
  【rootのパスワード】自由に設定(2回入力して[OK])
  【NetWorking】DHCPか固定IP(今回は固定IPにしました)
  【ホスト名/DNSサーバ】環境に合わせて設定
  【タイムゾーン】Asia>>Tokyo
  【System Time】Manual time entry(NTPを使う場合は次の画面で設定)

・ここまで設定したら以下の画面になるので[Install XenServer]を選択してEnterを押すとインストールが始まります。
(Supplemental Packのインストールを行うと選択している場合、「New Media」という画面が表示されるが特にインストールしないので、[Skip])

WS000032

・しばらく待つとインストールが終了し、「Installation Complete」という画面になるので[OK]を押して再起動します。

WS000035

・起動すると、以下の画面になるのでここからはWindows専用XenClientのXenCenterから設定などの変更が出来るようになります。

WS000034

この段階ではXenServerを構築したのみで、まだ何と接続しているわけではありません。
きりが良いので一旦ここまで、、、②に続きます。
次回はXenCenterのインストール~接続~Zabbixでの監視編です。

ALBでパスベースのルーティングができると何が嬉しいのか~前置き編~

batchiです。

早いものでALB(Application Load Balancer)が登場してから数ヶ月。
先輩のpinoco氏はALBが登場してすぐにブログに書いていたのですが、

ELB(Application Load Balancer)をおさわりする

当時の僕はパスベースとはなんぞや状態で、
いまいち「ALBならでは」の挙動を理解できておりませんでした。

ここにきてようやく理解が追いついてきたので、
数ヶ月前の自分に向けて噛み砕いた説明を記していきます。

まずはCLBとALBの違い

ALB(Application Load Balancer)が登場したことによって、
従来のLoad BalancerはCLB(Classic Load Balancer)と称されることになりました。

以下記事中の呼称はALB、CLBに統一します。

公式ドキュメントで両者の比較表が作られていますので確認しましょう。
http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/what-is-load-balancing.html#elb-features

ALBとCLBの違い

[パスベースのルーティング]という行には、
ALBにのみチェックがついていることがわかります。

あとはまぁ、いろいろ違いますね。

いきなり脱線して日本語訳への不満

[スティッキーセッション (Cookie)]の行をご確認ください。
ALBの列に、「生成されたロードバランサー」と書いてあります。

ちょっと意味が分からないですね。

英語表記に切り替えると、
「load balancer generated」と記載されています。
「generated」によって「load balancer」が修飾されているという訳し方ですね。

正しくは「load balancer generated」が「cookies」を修飾していて、
「ロードバランサーが生成した(クッキー)(によるスティッキーセッション)」のはずです。

CLBであれば、
アプリケーション制御のcookieによるスティッキーセッションも、
ロードバランサー制御のスティッキーセッションも選択できるけど、
ALBでは後者しか使えません。という意味でした。

パスベースのパスとは

話は戻ってパスベースの話です。
パスベースにおけるパスとは何を指しているのかをきちんと理解するために、
URLの構成をおさらいしておきましょう。

https://www.cman.jp/network/term/url/
↑こちらのサイト様がわかりやすくまとまっていました。

簡単に言うとこういった構成になります。

http://<FQDN> <パス>

FQDNとは、「(ホスト名+)ドメイン」のことです。

弊社のHPのURLで見ると…
https://www.simpline.co.jp

ホスト名 www
ドメイン simpline.co.jp
パス なし

技術ブログの場合だと…
http://www.simpline.co.jp/tech/

ホスト名 www
ドメイン simpline.co.jp
パス /tech/

「パスベースのルーティング」には、
URLにおけるこの「パス」が関係してくるというわけです。

パスベースのルーティングが必要ないケース

ここで、弊社のサーバ構成をごく簡単にご説明します。

パスベースでないケース

簡単すぎますね。

EC2上でwebサーバを動かしており、
そのフロントにはCLBが立っています。

HPや技術ブログの他にも社員ブログ、代表ブログなど様々ありますが、
基本的に同じサーバの同じポート番号で動かしています。

クライアントはwww.simpline.co.jp <何がしかのパス>というURLにアクセスしてくるわけですが、
ここで<パス>が何であっても、
クライアント→hosted zone→CLB→80番ポートに至るまでの経路は全く同じです。

こういった構成においては、パスベースのルーティングは必要ありません。

では一体どういったケースで必要になってくるかというと…
肝心なところは次回に持ち越しです。

以上です。

AWS Certificate ManagerでSSL証明書を取得した話を読んで調べてみた話

batchiです。

前回はhm君がACMに関する記事を書いてくれたのですが、
見ている内になかなか面白そうだということになりまして、
自分でも調べてみることにしました。

AWS Certificate ManagerでSSL証明書を取得した話

基本的にはhm君が書いてくれたことに乗っかりつつ、
2016年12月現在日本語に対応していないドキュメントと、
http://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html

じゃあもうざっくりしたことはこちらで見ます!でおなじみのBlack Beltの資料をお供に、進めていきます。

ACMのさっくりとした特徴

■証明書取得は無料

 うれしいですね。証明書だけでなくACMというサービス自体が無料です。

■証明書の種類は「ドメイン検証済み証明書」

 ACMの「よくある質問」ではそういう言い回しになっていますが、
 一般的には「ドメイン認証証明書」ですね。
 https://aws.amazon.com/jp/certificate-manager/faqs/

 Black Beltのスライドの16ページに、証明書の種類が載っています。

■証明書の更新を自動で行ってくれる

 証明書の有効期間は13ヶ月で、
 早い場合期限切れの60日前から更新プロセスを実施してくれます。

■証明書のデプロイは、ELBかCloudFrontにのみ対応

 EC2やらオンプレで建てたWeb/APサーバに入れましょう、
 というのは(現在のところ)できませんということですね。

デュアルアクセスはできないが

証明書ベンダーによっては、
コモンネーム「www.hoge.co.jp」で証明書を取得すれば、
zoneapexである「hoge.co.jp」にも証明書が有効となったりします。

それをデュアルアクセスと呼ぶのだそうです。

ACMに置き換える前はデュアルアクセス対応の証明書だったので、
「じゃあACMではワイルドカードかなんかでまるっと有効にすればよろしんじゃないー」
なんて無責任に言っていたのですが、

ワイルドカード指定でプロテクトできるのは、
飽くまで「apexドメインのサブドメイン」までということでした。

つまり、「*.hoge.co.jp」と指定すれば、
www.hoge.co.jpもbatchi.hoge.co.jpも対象となりますが、
www.fuga.hoge.co.jpや、hoge.co.jpはプロテクトしてくれないのでした。

ただし

ACMでは1枚の証明書に複数ドメインを設定できるので、
今回はドメイン名「*.hoge.co.jp」で証明書を取得し、
そこに[追加の名前]として「hoge.co.jp」を指定することで、
やりたいことがひとまず実現されました。
(ワイルドカードでなくてwwwで良かったかもしれない)

↓そこらへんの仕様がつらつらと書いてあります。

http://docs.aws.amazon.com/acm/latest/userguide/acm-certificate.html

[Wildcard Names]
When you request a wildcard certificate, the asterisk (*) must be in the leftmost position of the domain name and can protect only one subdomain level. For example, *.example.com can protect login.example.com and test.example.com, but it cannot protect test.login.example.com. Also note that *.example.com protects only the subdomains of example.com, it does not protect the bare or apex domain (example.com). However, you can request a certificate that protects a bare or apex domain and its subdomains by specifying multiple domain names in your request. For example, you can request a certificate that protects example.com and *.example.com.

証明書にタグがつけられるが

ELBのリスナーにデプロイする選択画面では、
<ドメイン名>+<長ったらしい識別子>で表示されていました。残念。

証明書取得の事前準備

ドメイン認証証明書、というからには、
当然ドメインの管理者である必要があるわけで、
管理者あてに送られてくるメールを受け取れなければいけないわけです。

ではどこ宛にメールが送られてくるか、
というと、「whois情報に紐づく担当者」です。

正確に言うと、証明書リクエストに記載された各ドメイン名に対して WHOIS ルックアップが実行され、
そのドメインの連絡先情報に登録されている、
ドメインの登録者、管理者、および技術担当者の連絡先に送信されます、とのこと。

加えて、下記5つのアドレス。
administrator@your_domain
hostmaster@your_domain
postmaster@your_domain
webmaster@your_domain
admin@your_domain

whois情報とは何ぞや

このドメインはどこそこの誰が管理しているか、
というのは一般に公開されているものです。

「whois情報検索」なんかで検索すれば、
そういったサイトがいくつも出てきます。

試しに弊社のドメインのwhois情報を確認してみると…
あぁ。なるほど。

お名前.comなどでドメイン取得するケースが多いかと思いますが、
その際に登録する情報ですね。

whois代行みたいなオプションを有効にすれば、
この検索結果をお名前.comのものにしてくれると。

Validation Not Complete

上述のように、(可能性としては)たくさんの宛先に確認メールが送られるわけですが、
それを全部承認しなければ有効にならない、ということはありません。
(スライドの30Pの記述からそう判断した)

[ドメイン名]と[追加の名前]で証明書を取得したなら、
それぞれに(可能性としては複数の宛先に対して)承認メールが送られるので、
その両方で(1通以上のメールにおいて)承認を行えば、晴れてValidationがCompleteになります。
なるはずです。

http://docs.aws.amazon.com/acm/latest/userguide/troubleshooting.html#troubleshooting-incomplete

If your request includes more than one domain name in the certificate, then you must approve every domain name that you included.

2分くらい時間かかるそうです。

以上です。

AWS Certificate ManagerでSSL証明書を取得した話

こんにちは、hmです。

今回は、AWSのサービスであるAmazon Certificate managerで、
SSL証明書を取得し、現行のものと置き換えたお話です。

サービス利用の背景
現在、複数ドメインを取得・管理をしておりますが、
その中の一つが更新時期を迎えたので、この際見直しをすることになりました。

検討時、候補として挙がったのが、AWS Certificate managerで取得できる
SSL証明書でした。

ACMとは?

ACMは、ざっくりいうとSSL証明書を管理するサービスです。
AWSでも新規のSSL証明書を発行してもらえます。

下記は、サービスの特徴をさらにざっくりまとめました。

・証明書取得は、無料である。
・現在は、ドメイン検証済み証明書のみが取得可能。
・有効期間は1年間、更新は自動でOK!
・証明書発行は、CloudFrontとELBのみ対応

詳細は、こちら
今回の要件としては、ドメイン証明書レベルで大丈夫だったので、
早速実装いたしました。

実装編
1,今回要件として、www.XXXXXX.co.jpがSSL証明書取得対象

現行では、www.XXXXXX.co.jpでSSL証明書取得をすると、
zoneapexであるXXXXXX.co.jpにも効力が及んでいたが、
ACMでは分けて設定する必要があるようです。
なので、ワイルドカードで指定をします。

取得後のキャプチャはこちら。
2016-12-05 (2)
塗りつぶされてわからなくなってますが、
追加の部分にzoneapexで指定をしたものをいれています。

SSL証明書のリプレース

今回は、ロードバランサーにつけます。
20161206

矢印の部分がSSL証明書です。右側の変更ボタンを押して、
変更ができます。

変更ボタン後は下記のようになります。
ここで、選択肢の一番上を選び、取得したものをさらに選んで保存を押して終了。
2016-12-05 (3)

余談
SSL証明書取得時にAWSからユーザーへ承認のメールが届きます。
メールのあて先は、下記です。

administrator@your_domain
hostmaster@your_domain
postmaster@your_domain
webmaster@your_domain
admin@your_domain

今回は、上記のうち、2つに届いていて、
1つだけ承認をしましたが、承認していることにはなりませんでした。

どうやら確認ができる複数のアドレスに来ている場合、
すべてのドメインで承認が必要だという意味なのでしょうか。

念のため、ドキュメントを探していると、
2つ以上ドメインを指定するとすべて認証しなければならない。
Validation Not Complete の important
という記述を見つけましたが、よくわかりません。

簡単ですが、今回はここまで。

どうもありがとうございました。

WorkSpacesをQuick Setupで構築してみた③

前回の続きから。
WorkSpacesインスタンスのローンチが完了したので、
クライアントから接続してみます。

接続情報の通知

インスタンスのステータスがAVAILABLEになると、
ユーザーにメールで通知が行われます。

宛先となるメールアドレスは、セットアップ時のバンドルの選択画面で入力したものです。

件名:Your Amazon WorkSpace
本文:

Dear Amazon WorkSpaces User,

Your administrator has created an Amazon WorkSpace for you. Follow the steps below to quickly get started with your WorkSpace:

1. Complete your user profile and download a WorkSpaces client using the following link: https://xxxxxxxxxxxxxxx

2. Launch the client and enter the following registration code: yyyyyyyyyy

3. Login with your newly created password. Your username is <ユーザ名>

You may download clients for additional devices at https://clients.amazonworkspaces.com/

If you have any issues connecting to your WorkSpace, please contact your administrator.

Sincerely,

Amazon WorkSpaces

1.プロファイルの設定とクライアントダウンロード

メール内のリンクに飛ぶと、ブラウザ上でユーザプロファイルの設定画面に移ります。

▼パスワードの初期設定と、必要に応じて姓・名の変更を行います。
ちなみにパスワードポリシーは、Quick Setupの場合下記の通り。
・8 ~ 64 文字
・次の 4 つのうち 3 つを含む
 英小文字、英大文字、数字、特殊文字

Wokspacesユーザ情報

▼画面遷移してクライアントのダウンロードへ

workspacesクライアント

▼インストーラをダウンロードしたらウィザードを順に。

クライアント1

クライアント2

クライアント3

クライアント4

クライアント5

2.クライアントソフトの起動とレジストレーションコードの入力

インストールが完了したクライアントソフトを起動します。
(ショートカットが作成されています)

▼レジストレーションコードを入力。

Workspacesレジストレーションコード

3.ユーザ名とパスワードを入力してログイン

▼しましょう。

Workspaces認証

▼次回以降入力をスキップしたければ。

Wprkspaces確認

ついに仮想デスクトップへ

前工程までを済ませれば、ついに仮想デスクトップへ接続できます。

▼しょっぱなはWindows2008ライクな画面が…
撮り損ねましたが背景にばっちり2008の表記が見えました。

(追記)
撮っている時と書いてる時は「Windows セキュリティの重要な警告」が
仮想デスクトップ上で表示されてるもんだと思ってましたが、
冷静に見たらこれはクライアントPC側のポップアップでした。    

でも裏側で2008の表記が見えたのは確か!

WorkSpaces画面2008

WindowsServerの機能でデスクトップエクスペリエンスというものがあって、
裏側ではそれが動いているんですね。とはいえ見えちゃうのはかっこ悪いですね。

https://aws.amazon.com/jp/workspaces/faqs/

Q: Amazon WorkSpaces はどのオペレーティングシステムで実行できますか?
Amazon WorkSpaces では Windows 7 デスクトップエクスペリエンスを提供します (Windows Server 2008 R2 で提供)。

▼インターネットにもつながる!

WorkSpacesインターネット

てっきり下記の記述よりデフォルトではつながらないものだと思っていましたが、
Quick Setupで立ち上げた場合はここでいうデフォルトには当てはまらないようですね。
http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/cloud_internet_access.html

確かにVPCにはインターネットゲートウェイがアタッチしてあり、
ルートテーブルにもルーティング設定があり、
WorkSpacesインスタンスのENIがパブリックIPを持っていたので、
つながって然るべしという気はしますね。

Simple ADの設定でパブリックIP付与の有無をコントロールできて、
Quick Setupにおいてはそれが「有効」の状態で立ち上がるようですね。

おしまい

ひとまずゴールにたどり着いたので終了です。
とりあえずQuick Setupで繋がるところまで、
ということであればサクサクとすすめることができました。

あとは使用していく上でのもろもろの注意点などが調べられたらいいなぁと思っております。

使い心地に関しては、まだほぼ触っていませんが、
ウインドウの大きさ変えたりする時にもっさり感が気になりました。

(ウインドウというのはWorkSpaces自体のものです)
(WorkSpacesの仮想デスクトップ上でウインドウ開いたり…とかではなくて)

こちらからは以上です。

WorkSpacesをQuick Setupで構築してみた②

前回からの続きです。
WorkSpacesインスタンスのローンチを待っている状態。

Quick Setup(高速セットアップ)が作成してくれるもの

待っている間に彼がどんなことをやってくれるのかを確認してみます。

-高速セットアップの詳細
http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/quick_start_details.html

IAMロール

ロール「workspaces_DefaultRole」が作成されていました。
インラインポリシー(管理ポリシーではない)の記述は下記の通り。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:CreateNetworkInterface",
        "ec2:DeleteNetworkInterface",
        "ec2:DescribeNetworkInterfaces",
        "galaxy:DescribeDomains"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

VPC

VPCを作成してくれていますが、果たしてどれがそのVPCなの?
というのを、一発でリンクで飛んでいけたりはしないようでした。

▼Workspacesインスタンスの詳細画面

WorkSpaces画面

Elastic Network Interface

というわけなので、ENIからさかのぼって確認することにします。

▼作成されたENIは3つ。
WorkSpacesインスタンス用が一つと、Directory用が二つ。
前者にはパブリックIPが振られています。(EIPではない)
所有者が自分自身のアカウント番号ではないのも目新しいですね。
ここからVPCが割り出せます。

WorkSpacesENI

セキュリティグループ

それぞれのENIから確認できます。

WorkSpacesインスタンス用が、
グループ名「d-xxxxxxxx_workspacesMembers」。

 インバウンド:ルールなし
 アウトバウンド:すべて許可

Directory用が、
グループ名「d-xxxxxxxx_controllers」。

 インバウンド:すごくいっぱい(下画像参照)
 アウトバウンド:すべてのトラフィックを自分と同一のセキュリティグループに許可

▼インバウンドはこんな感じ。編集しないことを推奨されてます。

workspacesセキュリティグループ

さかのぼってVPC

今回リージョンをシドニーにして作成したのですが、
172.16.0.0/16で作成されていました。

下記ページより、てっきり172.31.0.0/16か
192.168.0.0/16で作成されるものかと思っていましたが、また別の話のようでした。
http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/admin_details.html

ちなみにVPC上ではサブネットが二つ作成済み。
それぞれ違うアベイラビリティゾーンに作成されています。
そして先述の二つのDirectory用ENIは、もちろん違うAZに配置されているというわけです。

▼ちなみに上記のサブネットには同じルートテーブルが関連付けられています。
ルートテーブルの情報はlocalとインターネット向けの2種類のみです。

WorkSpacesルートテーブル

▼VPCのタグにこんな感じの情報が付与されています。

workspacesVPC

Simple AD

WorkSpacesのダッシュボードからでも、
Directory Serviceのダッシュボードからでも確認できます。

▼前者ではこのような感じ

WorkSpacesDirectory

▼後者ではこのような感じ
ここから作成されたVPCを判断することもできますね。

WorkspacesSimpleAD

ありがとうそしてさようならQuick Setup(高速セットアップ)

Quick Setup(高速セットアップ)が選択できるのは、
というか、セットアップタイプが選択できるのは、
リージョンごとに初回のみのようでした。

今後WorkSpacesインスタンスを追加していく際には、
初回で作成されたSimple ADを利用するか、
新たにAWS Directory Serviceを作成して追加していく必要があるようです。

次回いよいよクライアントからの接続

確認すべきことが盛り沢山だったので、
またここで一旦切って次回に回します:D

WorkSpacesをQuick Setupで構築してみた①

本記事について

・WorkSpacesの構築について大まかに理解したい方向けです。
・製品概要・詳細等は公式のページを見てください。
https://aws.amazon.com/jp/workspaces/
http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2016-workspaces

・EC2とかVPCとかいじったことあります!というレベルの方を想定しています。
・このドキュメントを参考にしつつ、実際に構築しながらまとめていきます。
http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/what_is.html

Quick Setup(高速セットアップ)でひとまず立てる

とりあえずゴールはWorkSpacesインスタンスを1台立てて、
クライアントから繋いでみるところまで、とします。

▼スタート。

WorkSpaces開始

▼セットアップタイプを選択します。

WorkSpacesセットアップ方法

セットアップタイプとは

下記2種類があります。
・Quick Setup(高速セットアップ)
・Advanced Setup(高度な設定)

何が違うかというと、AWS Directory Serviceの設定に関わる部分です。

AWS Directory Serviceとは

「フルマネージドのディレクトリサービス」です。
下記3種が存在します。

SimpleAD ・フルマネージドのディレクトリサービス
・AWS上に独立して存在
・Active Directoryと「互換性」(ここ大事)がある
AD Connector ・既存のディレクトリサービスへの接続
・既存のディレクトリサービスはオンプレでもVPC上でも可
Microsoft AD ・簡単に言うとSimple ADの「互換じゃなくてそのもの版」
・Windows Server2012R2によるActive Directory機能の提供
・既存ドメイン/フォレストとの信頼関係がサポートされる

話は戻ってセットアップタイプの話

・Quick Setup(高速セットアップ)…VPCとSimpleADが新規作成される。
・Advanced Setup(高度な設定)…AWS Directory Serviceの3種から好きなものを選べる。既存のVPCを選択できる。

後者でセットアップしていくなら、
予めVPCとAWS Directory Serviceの設定を完了させたほうが構築がスムーズに進みそうですね。

今回は前者でいきます。

▼バンドルの選択。バンドルにどんな種類があるの?などは本記事の範囲外です。

ちなみに、Tokyoリージョンの場合だけLanguageで日本語が選択できます。
ユーザーも1人ずつではなく複数同時に設定可能ですが、新規作成時は5が上限であるかと思います。
Amazon WorkSpaces 制限

WorkSpacesバンドル

▼ちょっと画面の下のほうが切れてたのでもう一枚。
ちなみに赤枠で囲っているところでは各バンドルの説明が見れるだけで、
実際にバンドルを選択するのは青枠のところです。

WorkSpacesバンドル2

▼ローンチが始まります。

WorkSpacesローンチ

▼失敗しました。

WorkSpaces失敗

An Error Has Occurred

もちろん分かっていましたよ。
こうなることは分かっていました。

ただ、エラーの情報が載っていたほうがより有用かな、と思ったまでです。

VPC limit reached. Please delete a VPC to use Amazon WorkSpaces. for activityId="1" of activityType={Name: validateCustomerLimits,Version: 8}

先程述べたように、Quick Setup(高速セットアップ)ではVPCが新規作成されるので、
VPCの数が上限に達しているとエラーが起こります。

気を取り直して違うリージョンでセットアップ

VPCの上限緩和申請を出したり、
既存のVPCを削除したりするのも手間だったので、
おとなしくVPCに空きがある違うリージョンで実施しました。

▼ローンチがきちんとはじまりました。

WorkSpaces成功

WorkSpaesインスタンスの作成には20分ほど時間を要し、
接続可能な状態になったらメールで教えてくれるそうです。
長いな。

長いので、いったん切ります。
続きはまた次回へ:D