normalian blog

Let's talk about Microsoft Azure, ASP.NET and Java!

Microsoft AzureのNetwork Security Groupを使ってなんちゃってネットワーク設計(インスタンスのインターネットアクセス禁止とか)をする

御大ブログにて以下の新機能リリースがあった。

上記の機能のうち、Network Security Groupと呼ばれる機能の提供により、仮想ネットワーク上で簡易なネットワーク設計が可能となった。以下の様な社蓄心をくすぐる要件にこたえることが可能なナイス機能となっているので、今回はNetwork Security Groupの機能について紹介する。

Network Security Group の概要

MSDN - About Network Security Groups に概要がある。Network Security Group は仮想ネットワーク上に設定された サブネット or 仮想マシン、またはサブネットと仮想マシン両方に通信制御を可能とする機能だ。
IP アドレス、ポート、TCP/UDP プロトコルを指定して通信制御を行うため、冒頭で記載したインターネットへのアクセス禁止やインスタンス間(またはサブネット間)における通信制御が可能となる。
Network Security Group で利用可能なコマンドは以下となるため、詳細は MSDN を確認してほしい。

PS C:\Temp> Get-Command *NetworkSecurity*

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Cmdlet          Get-AzureNetworkSecurityGroup                      Azure
Cmdlet          Get-AzureNetworkSecurityGroupConfig                Azure
Cmdlet          Get-AzureNetworkSecurityGroupForSubnet             Azure
Cmdlet          New-AzureNetworkSecurityGroup                      Azure
Cmdlet          Remove-AzureNetworkSecurityGroup                   Azure
Cmdlet          Remove-AzureNetworkSecurityGroupConfig             Azure
Cmdlet          Remove-AzureNetworkSecurityGroupFromSubnet         Azure
Cmdlet          Remove-AzureNetworkSecurityRule                    Azure
Cmdlet          Set-AzureNetworkSecurityGroupConfig                Azure
Cmdlet          Set-AzureNetworkSecurityGroupToSubnet              Azure
Cmdlet          Set-AzureNetworkSecurityRule                       Azure

また、Network Security Groupの主な制限は以下になるので、実際に利用する際には参考にして欲しい。

  • 一つのサブスクリプションに100個までNetwork Security Groupを作成できる
  • 一つのNetwork Security Groupにつき、ルールは 200個まで設定可能
  • ACL とは併用できない(Network Security Group利用時に、あらかじめ削除しておく必要がある)
  • Multi NIC を利用している場合、デフォルト NIC にしか適用されない
  • VM 単位、Subnet 単位、または両方に適用可能

試しにネットワークを設定してみる

以下のネットワークを設定してみる。
f:id:waritohutsu:20141115163958p:plain

また、あらかじめ以下の仮想ネットワーク、インスタンスが作成済みとする。

DMZ 向けの Network Security Group を適用する

以下の PowerShell スクリプトを実行する。

# DMZ用のNetwork Security Group作成
New-AzureNetworkSecurityGroup -Name "NSG01" -Label "for vnet01 DMZ NSG" -Location "Japan East"

# インターネットからの HTTP アクセスを許可
Get-AzureNetworkSecurityGroup -Name NSG01 | Set-AzureNetworkSecurityRule -Name "AllowWEBFromInternet" -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix INTERNET -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 80 -Protocol *

# インターネットからの RDP を許可
Get-AzureNetworkSecurityGroup -Name NSG01 | Set-AzureNetworkSecurityRule -Name "AllowRDPFromInternet" -Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix INTERNET -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 3389 -Protocol *

# インターネットへのアクセスを禁止
Get-AzureNetworkSecurityGroup -Name NSG01 | Set-AzureNetworkSecurityRule -Name "DenyToInternet" -Type Outbound -Priority 1100 -Action Deny -SourceAddressPrefix VIRTUAL_NETWORK -SourcePortRange * -DestinationAddressPrefix INTERNET -DestinationPortRange * -Protocol *

# NSG01 の情報を表示(なくても勝手に表示されますが、一応
Get-AzureNetworkSecurityGroup -Name NSG01 -Detailed

# Subnet-DMZ へのNetwork Security Groupの適用
Get-AzureNetworkSecurityGroup NSG01 | Set-AzureNetworkSecurityGroupToSubnet -SubnetName Subnet-DMZ -VirtualNetworkName vnet01

# Subnet-DMZ へのNetwork Security Groupへの適用の確認
Get-AzureNetworkSecurityGroupForSubnet -SubnetName Subnet-DMZ -VirtualNetworkName vnet01 -Detailed

以下の実行結果が出力されるはずだ。

Name  : NSG01
Rules :

           Type: Inbound

        Name                 Priority  Action   Source Address  Source Port R Destination Addr Destination Po Protocol
                                                Prefix          ange          ess Prefix       rt Range
        ----                 --------  ------   --------------- ------------- ---------------- -------------- --------
        AllowWEBFromInternet 100       Allow    INTERNET        *             *                80             *
        AllowRDPFromInternet 500       Allow    INTERNET        *             *                3389           *
        ALLOW VNET INBOUND   65000     Allow    VIRTUAL_NETWORK *             VIRTUAL_NETWORK  *              *
        ALLOW AZURE LOAD BAL 65001     Allow    AZURE_LOADBALAN *             *                *              *
        ANCER INBOUND                           CER
        DENY ALL INBOUND     65500     Deny     *               *             *                *              *


           Type: Outbound

        Name                 Priority  Action   Source Address  Source Port R Destination Addr Destination Po Protocol
                                                Prefix          ange          ess Prefix       rt Range
        ----                 --------  ------   --------------- ------------- ---------------- -------------- --------
        DenyToInternet       1100      Deny     VIRTUAL_NETWORK *             INTERNET         *              *
        ALLOW VNET OUTBOUND  65000     Allow    VIRTUAL_NETWORK *             VIRTUAL_NETWORK  *              *
        ALLOW INTERNET OUTBO 65001     Allow    *               *             INTERNET         *              *
        UND
        DENY ALL OUTBOUND    65500     Deny     *               *             *                *              *
AP/DB 向けの Network Security Group を適用する

以下の PowerShell スクリプトを実行する。

# APサーバ、DBサーバ用のセキュリティグループ作成
New-AzureNetworkSecurityGroup -Name "NSG02" -Label "for vnet01 AP_DB NSG" -Location "Japan East"

# インターネットからの HTTP アクセスを許可
Get-AzureNetworkSecurityGroup -Name NSG02 | Set-AzureNetworkSecurityRule -Name "AllowWEBFromInternet" -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix INTERNET -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 80 -Protocol *

# インターネットからの RDP を許可
Get-AzureNetworkSecurityGroup -Name NSG02 | Set-AzureNetworkSecurityRule -Name "AllowRDPFromInternet" -Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix INTERNET -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 3389 -Protocol *

# インターネットへのアクセスを禁止
Get-AzureNetworkSecurityGroup -Name NSG02 | Set-AzureNetworkSecurityRule -Name "DenyToInternet" -Type Outbound -Priority 1100 -Action Deny -SourceAddressPrefix VIRTUAL_NETWORK -SourcePortRange * -DestinationAddressPrefix INTERNET -DestinationPortRange * -Protocol *

# DMZ Subnet(NSG01) へのアクセスを禁止
Get-AzureNetworkSecurityGroup -Name NSG02 | Set-AzureNetworkSecurityRule -Name "DenyToNSG01" -Type Outbound -Priority 2000 -Action Deny -SourceAddressPrefix 10.0.1.0/24 -SourcePortRange * -DestinationAddressPrefix 10.0.0.0/24 -DestinationPortRange * -Protocol *

# DMZ Subnet(NSG01) からのアクセスを許可
Get-AzureNetworkSecurityGroup -Name NSG02 | Set-AzureNetworkSecurityRule -Name "AllowFromNSG01" -Type Inbound -Priority 2100 -Action Allow -SourceAddressPrefix 10.0.0.0/24 -SourcePortRange * -DestinationAddressPrefix 10.0.1.0/24 -DestinationPortRange * -Protocol *

# Subnet-AP_DB へのNetwork Security Groupの適用
Get-AzureNetworkSecurityGroup NSG02 | Set-AzureNetworkSecurityGroupToSubnet -SubnetName Subnet-AP_DB -VirtualNetworkName vnet01

# Subnet-AP_DB へのNetwork Security Groupへの適用の確認
Get-AzureNetworkSecurityGroupForSubnet -SubnetName Subnet-AP_DB -VirtualNetworkName vnet01 -Detailed

以下の実行結果が出力されるはずだ。

Name  : NSG02
Rules :

           Type: Inbound

        Name                 Priority  Action   Source Address  Source Port R Destination Addr Destination Po Protocol
                                                Prefix          ange          ess Prefix       rt Range
        ----                 --------  ------   --------------- ------------- ---------------- -------------- --------
        AllowWEBFromInternet 100       Allow    INTERNET        *             *                80             *
        AllowRDPFromInternet 500       Allow    INTERNET        *             *                3389           *
        AllowFromNSG01       2100      Allow    10.0.0.0/24     *             10.0.1.0/24      *              *
        ALLOW VNET INBOUND   65000     Allow    VIRTUAL_NETWORK *             VIRTUAL_NETWORK  *              *
        ALLOW AZURE LOAD BAL 65001     Allow    AZURE_LOADBALAN *             *                *              *
        ANCER INBOUND                           CER
        DENY ALL INBOUND     65500     Deny     *               *             *                *              *


           Type: Outbound

        Name                 Priority  Action   Source Address  Source Port R Destination Addr Destination Po Protocol
                                                Prefix          ange          ess Prefix       rt Range
        ----                 --------  ------   --------------- ------------- ---------------- -------------- --------
        DenyToInternet       1100      Deny     VIRTUAL_NETWORK *             INTERNET         *              *
        DenyToNSG01          2000      Deny     10.0.1.0/24     *             10.0.0.0/24      *              *
        ALLOW VNET OUTBOUND  65000     Allow    VIRTUAL_NETWORK *             VIRTUAL_NETWORK  *              *
        ALLOW INTERNET OUTBO 65001     Allow    *               *             INTERNET         *              *
        UND
        DENY ALL OUTBOUND    65500     Deny     *               *             *                *              *

しかして

上記で設定は完了だが、設定がうまく反映されたり反映が遅れたりする場合があるようだ。MSDN にも以下の記載があり、反映に数分はかかることが記載されているが、体感で30分以上の時間が過ぎたにも関わらず設定が反映されていない場合もあった(逆に、ルールを変更したら即座に反映された場合もあった)ので、利用時には注意してほしい。

Associating an NSG to a VM - When a NSG is directly associated to a VM, the Network access rules in the NSG are directly applied to all traffic that is destined to the VM. Whenever the NSG is updated for rule changes, the changes are reflected in the traffic handling within minutes. When the NSG is dis-associated from the VM, the state goes back to whatever it was before the NSG, i.e. the system defaults before the introduction if NSG will be used.
Associating an NSG to a Subnet - When a NSG is associated to a subnet, the Network access rules in the NSG are applied to all the VMs in the subnet. Whenever the access rules in the NSG are updated the changes are applied to all Virtual machines in the subnet within minutes.

Exchange Web Services Managed API SDK を使ってみた

前回のエントリで試した PowerShell を利用した CUI での Exchange Server への疎通はうまくいかなかった。今回は Exchange Web Services Managed API SDK の利用を検討してみた。
Exchange Web Services Managed API SDKExchange Server 2007 SP1 以降で利用可能であり、開発者側で理解しやすい API を用いて Exchange Server 側の情報を容易に操作することができる。
以下の様の NuGET で取得が可能であるため、簡単に取得することができる。今回はこちらを利用してオンプレ向けの Exchange Server に疎通を取ってみる。

上記の通り、32bit 版と 64bit 版があるので留意が必要だ。

Exchange Web Services Managed API SDK を利用した疎通を実施

Exchange Web Services Managed API SDK は NuGet 経由で取得できるため、以下の画面を参考に「Exchange」の文字列で検索して Exchange Web Services Managed API SDK を取得してほしい。
f:id:waritohutsu:20140504161809p:plain

Exchange Web Services Managed API SDK のインストール後、以下のコードを記載して Exchange Server から予定を取得する。

using System;
using System.Linq;
using Microsoft.Exchange.WebServices.Data;

namespace ExchangeConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            // エンプラ向けに古いバージョンの Exchange Server を指定だが、用途に合わせてオプション指定
            ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2007_SP1);

            // EWS のレスポンス情報をログに出力
            service.TraceEnabled = true;
            service.TraceFlags = TraceFlags.All;

            // 環境によっては Autodiscover が無理だが、以下に Autodiscover を推奨する記載がある
            // http://msdn.microsoft.com/en-us/library/dn467891(v=exchg.150).aspx
            // service.AutodiscoverUrl("<ユーザ名>@<ドメイン>", RedirectionUrlValidationCallback);

            // Autodiscover を設定せず、直接 URI を指定する
            service.Url = new Uri(@"https://<Exchange Server アドレス>/EWS/Exchange.asmx");
            service.Credentials = new WebCredentials("<ユーザ名>@<ドメイン>", "<パスワード>");

            // 現在からひと月前~ひと月後を指定して予定を取得する
            var folder = CalendarFolder.Bind(service, WellKnownFolderName.Calendar);
            DateTime dtStart = DateTime.Today;
            dtStart = dtStart.AddMonths(-1);
            DateTime dtEnd = dtStart.AddMonths(1);
            var view = new CalendarView(dtStart, dtEnd);
            foreach (var appointment in folder.FindAppointments(view))
            {
                Console.WriteLine("---------------------");
                Console.WriteLine("Subject = {0}", appointment.Subject);
                Console.WriteLine("Start = {0}", appointment.Start);
                Console.WriteLine("End = {0}", appointment.End);
                Console.WriteLine("IsAllDayEvent = {0}", appointment.IsAllDayEvent);
                Console.WriteLine("IsReminderSet = {0}", appointment.IsReminderSet);
                if (appointment.IsReminderSet == true)
                {
                    // appointment.IsReminderSet == true の状態で参照しないとエラーが出る
                    Console.WriteLine("ReminderDueBy = {0}", appointment.ReminderDueBy);
                }
            }

            Console.WriteLine("!!!!!!!!! end !!!!!!");
            Console.ReadLine();
        }
    }
}

上記のコードにおける「service.TraceEnabled = true; service.TraceFlags = TraceFlags.All;」の指定により、以下のように Exchange Server とのやり取りがログとして出力される。
f:id:waritohutsu:20140504201755p:plain

さらに、標準出力には以下が出力され、無事に Exchange Server から予定が取得されていることが確認できる。
f:id:waritohutsu:20140504201618p:plain

2007以前の Exchange Server から予定をひっこ抜こうとした件

所用で 2007 以前の Exchange Server から予定をひっこ抜こうとしたのだが、疎通の時点で色々と問題があってうまくいかなかった。備忘録としてやったことを簡単にまとめておく。

実施した内容

まずは基本中の基本である以下 TechNet 記事を参照した。

上記は Exchange Online が適用先となっているが、一応オンプレの Exchange Server で出来るかためしたところ以下のエラーが出た。

SSL 証明書の失効チェックできませんでした。取り消しを確認するために使用するサーバーがアクセスできない可能性があります。

調べてみたところ、Windows 専用の Office 365 でのリモート PowerShell を使用して接続するときに、「SSL 証明書をチェックできませんでしたの失効」エラー に記載がある通り、オンプレ Exchange Server の様にインターネットアクセスを持たないために証明書の失効がチェックができない場合に発生するらしい。

次に、上記のオプションを考慮して以下の PowerShell コマンドを実行した。

# Exchange Server ログイン用の認証情報取得
$myCredential = Get-Credential

# オンプレ向けにインターネットへルート証明書の失効期限を聞きに行かないようにする
$sessionOption = New-PSSessionOption -SkipRevocationCheck

# オンプレ Exchange Server に接続しに行く
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://<サーバ名> -Credential $myCredential -Authentication Basic -AllowRedirection -SessionOption $sessionOption

が、以下のエラーが出てきて目頭が熱い気味。どうやら Exchange Server 側で WS-Management プロトコルを有効化する必要がある?らしい。

New-PSSession : [<サーバ名>] リモート サーバー <サーバ名> への接続に失敗し、次のエラー メッセージが返されました: WinRM クライアントは HTTP サーバーに要求を送信し、要求された HTTP URL が使用不能であるとい
う応答を受け取りました。 これは通常、WS-Management プロトコルをサポートしていない HTTP サーバーによって返されます。詳細については、about_Remote_Troubleshooting のヘルプ トピックを参照してください。
発生場所 行:1 文字:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri ht ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : URLNotAvailable,PSSessionOpenFailed

その他の方法は?

Exchange Server 2007 SP1 以降なら Microsoft Exchange Web Services Managed API が利用可能とのこと。以下の SDK を利用することで何とかなりそうだが、Exchange Server 2007以前では…orz

色々と操作されている情報が以下にあった。後で見よう
MS Exchangeからスケジュールを抜き出すんだぜ

Azure Automaiton を試してみる

2014年4月に開催された BUILD 2014 では様々な機能が追加されたが、ちょっとだけ触ってみた Azure Automation について記載してみる。現時点ではまだプレビュー機能なので、管理ポータルから Activate を実施する必要がある。Azure Automation の公式サイトは以下になるが、まだ情報は少ないようだ。。。

Azure Automaiton の概要

Azure Automaiton を利用することで、Microsoft Azure 上で PowerShellスクリプトを利用/組み合わせで様々な処理を実施することができる。こちらの Get started with Azure Automation にも記載されているが、Windows PowerShell Workflows としての利用ができるようだ。
後述するが、PowerShellスクリプトRunbook として登録して利用することから、どうやら System Center 2012 R2 Orchestrator の Microsoft Azure 版というのがイメージしやすそうだ*1

Get Started を試す

さっそく Get started with Azure Automation を参照しつつ試してみようと思う。
まずは Script Centor から、以下の Write-HelloWorld.ps1 をダウンロードする。

  • Write-HelloWorld.ps1
workflow Write-HelloWorld {
    param (
        [parameter(Mandatory=$false)]
        [String]$Name = "World"
    )
        Write-Output "Hello $Name"
}

次に、管理ポータルから Automation のアカウントを作成する。現在はプレビュー版であり「米国東部」しか選択できない点に注意してほしい。
f:id:waritohutsu:20140407041053j:plain

更に RUNBOOKS タブを選択し、IMPORT ボタンを押下して RUNBOOK 向けの *.ps1 ファイルを選択してアップロードする。
f:id:waritohutsu:20140407041106j:plain

IMPORT の完了後に登録した RUNBOOK を選択し、AUTHOR → DRAFT のタブを選択してスクリプトを PUBLISH する。
f:id:waritohutsu:20140407041241j:plain

PUBLISH の実施後、START を押下することで RUNBOOK が実行される。実行の結果は以下の様に確認できる。
f:id:waritohutsu:20140407041629j:plain

複数の RUNBOOK を実行する

上記で実施した Hello Worldスクリプトに続き、Script Centor のサンプルに登録された How to Invoke a Child Runbook を参照し、以下のスクリプトを作成した。こちらのスクリプトは Write-HelloWorld.ps1 を子供として呼び出すスクリプトになる。

workflow Invoke-ChildRunbookSample
{
    
    [OutputType( [object] )]
    param (
		# Variable
        [parameter(Mandatory=$true)]
        [String]$MyVariable
    )
    
    Write-HelloWorld -Name "Hello World を書いてみる"
    Write-HelloWorld -Name $MyVariable
}

上記のスクリプトを RUNBOOK として登録して PUBLISH の実施*2後、START を押下することで以下の様にログ出力されていることが確認できる。
f:id:waritohutsu:20140407041755j:plain

参考情報

*1:System Centor の OrchestratorRunbook デザイナー相当のものがまだ存在しないため、利用はハードルが高そうだ…

*2:または Asset に必ず登録する必要がある

JBoss AS 7.1.1 Final & WildFly のhttpポートを変更する方法

Azure の Webサイトで Java の APサーバを動作させる際、必要に駆られて調べたので簡単にメモ。JBoss AS は 7 以降から大きく構成が変わっており、以下のファイルに http ポートのポート番号が記載されている*1

  • %JBOSS_HOME%\standalone\configuration\standalone.xml
  • %WILDFLY_HOME%\standalone\configuration\standalone.xml

これら standalone.xml 等の変更方法については、以下の記事が参考になる。
http://duke4j.wordpress.com/2011/10/03/jboss-as-7-admin-guide-core-management-concepts-general-configuration-concepts/

JBoss AS 7.1.1 Final の http ポート番号を変更する場合

以下のファイルの一番下部に、http のポートが 8080 と直接記載されているのが確認できる。

  • %JBOSS_HOME%\standalone\configuration\standalone.xml
    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>

こちらを以下の様に編集する。

        <socket-binding name="http" port="${jboss.http.port:8080}"/>

後は以下のコマンドで起動すれば、JBoss AS 7.1.1 Final の起動ポートが 9090 になる。

C:\opt\jboss\jboss-as-7.1.1.Final\bin>standalone.bat -Djboss.http.port=9090

WildFly の http ポート番号を変更する場合

WildFly は最初から以下の記載となっているため、特に設定ファイルに修正は要らない。

  • %WILDFLY_HOME%\standalone\configuration\standalone.xml
    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
        <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
        <socket-binding name="http" port="${jboss.http.port:8080}"/>
        <socket-binding name="https" port="${jboss.https.port:8443}"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
</server>

後は以下のコマンドで起動すれば、WildFly の起動ポートが 9090 になる。

C:\opt\jboss\wildfly-8.0.0.Final\bin>standalone.bat -Djboss.http.port=9090

*1:といっても、こちらは standalone モードだけなので、domain モードを利用している場合は修正対象ファイルが異なる

2014年3月, 4月の JAZUG のイベント

Japan Windows Azure User Group が 2014年3月、4月に実施するイベントをまとめてみた。都合が合いそうな方(合わなくとも是非調整して)は是非参加してほしい!

3/29(土) Global Windows Azure Boot Camp 2014 in Japan!! at 品川

Global Windows Azure Bootcamp 2014 in Japan!! は、全世界で同一日に Windows Azure イベントの日本枠になる。Global Windows Azure Bootcamp を主催するスウェーデンからの Magnus氏 が来日する他、ブルガリアの Mihail 氏とも協力してブルガリアの Global Windows Azure Bootcamp とも内容を連携しあう。世界的なイベントになる!

4/12(土) JAZUG女子部 第6回勉強会 ~日本DCがやって来たヤァ!ヤァ!ヤァ! at 品川

Japan Windows Azure User Group 女子部 第6回勉強会が 4/12 に開催されます。 JAZUG女子部 第6回勉強会 ~日本DCがやって来たヤァ!ヤァ!ヤァ! から参加登録可能であり、Windows Azure の日本データセンタって何が美味しいの?、MS本社で新機能が多々発表される Build 2014 参加者の内容連携だったりと、内容盛りだくさんだ。

4/26(土) 第3回JAZUG静岡勉強会 at 浜松

JAZUG の静岡支部、第三回目の勉強会になる。第3回JAZUG静岡勉強会から参加登録可能だ。主催・運営メンバーはJAZUGのコアメンバなので運営クオリティは期待できるのはもちろんなので、内容は普段都内に出てくるのが難しい方は是非参加してほしい。
また、静岡の美味しい食べ物に興味のある方も参加してみても良いかも?

Windows Azure の Webサイトで Tomcat, Jetty の稼働をサポート!!!

さて、今回はWindows Azure アドベントカレンダー の15日目だが、ここで大きなニュースがある。
来た! Web サイトで Java が動く日がついに来たのだ! さあ皆、↓の画面を見るんだ!!
f:id:waritohutsu:20140315204517j:plain

上記の様に JDK 1.7 update 51 が選択可能で、ついでに Tomcat と Jetty が動くのが確認できる。今回はこのネタを話したいと思う。

Kudu を利用したフォルダ構成、環境変数の確認

次にちょっとフォルダ構成を確認するために、Kudu を利用したいと思う。Kudu を知らない人は、No.1 が詳しい記載のある Windows Azure Web Sitesの魅力を120%引き出す を確認してみよう!

一旦は Tomcat 側で設定した Web サイトを作成し、Web サイトに https://<サイト名>.scm.azurewebsites.net/ でアクセスして、構造を確認してみよう。Kudu の Debug Console を利用するこでフォルダ構成をチェックできる。Tomcat のインストールディレクトリを確認したところ、以下の様に D:\Program Files (x86)\ 以下に配置されている。

D:\Program Files (x86)\apache-tomcat-7.0.50>dir
Volume in drive D is Windows
Volume Serial Number is 6416-721C
Directory of D:\Program Files (x86)\apache-tomcat-7.0.50
03/11/2014 10:20 PM <DIR> .
03/11/2014 10:20 PM <DIR> ..
03/11/2014 10:20 PM <DIR> bin
03/11/2014 10:20 PM <DIR> conf
03/11/2014 10:20 PM <DIR> lib
03/11/2014 10:20 PM <DIR> logs
03/11/2014 10:20 PM <DIR> temp
03/11/2014 10:20 PM <DIR> webapps
03/11/2014 10:20 PM <DIR> work
03/11/2014 10:20 PM 57,862 LICENSE
03/11/2014 10:20 PM 1,228 NOTICE
03/11/2014 10:20 PM 9,258 RELEASE-NOTES
03/11/2014 10:20 PM 16,742 RUNNING.txt
4 File(s) 85,090 bytes
9 Dir(s) 9,324,318,720 bytes free

次に、war を配置する webapps の設定を確認するために conf/server.xml の中身の一部も確認してみる。

D:\Program Files (x86)\apache-tomcat-7.0.50\conf>cat server.xml 

<中略>

<Host name="localhost" appBase="d:\home\site\wwwroot\webapps" xmlBase="d:\home\site\wwwroot\"
unpackWARs="true" autoDeploy="true" workDir="${site.tempdir}">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="${site.logdir}"
prefix="site_access_log." suffix=".txt"
pattern="%h %l %u %t &quot;%r&quot; %s %b" />
</Host> 

以下の様に war を配置するフォルダは appBase="d:\home\site\wwwroot\webapps" で記載されている。どうやらここに war を配置すればよいのだと推察できる。次に d:\home\site\wwwroot\webapps を確認すると、ROOT フォルダが存在し、以下に一つだけ index.jsp ファイルが存在している。
f:id:waritohutsu:20140315204906j:plain

ここで http://<サイト名>.azurewebsites.net にアクセスすると以下の画面が表示され、Oracle JDK かつ GMT タイムゾーンであることが確認できる。
f:id:waritohutsu:20140315204947j:plain

次に、環境変数を確認する。ここでは JDK, Jetty, Tomcat 向けに設定された環境変数の情報が確認可能だ。
f:id:waritohutsu:20140315205001j:plain

自前アプリをデプロイ

Kudu さんの Debug Console からドラッグアンドドロップで HelloWorld.war を d:\home\site\wwwroot\webapps 以下に配置した後、https://<サイト名>.azurewebsites.net/HelloWorld にアクセスすると以下の様に自前で作成した HelloWorld.war が正しくデプロイしていることが確認できる。
f:id:waritohutsu:20140315205519j:plain

次に git clone を利用して Web サイトをクローンしたところ、d:\home\site\ から引っこ抜かれてしまったので、毎度 war を push する必要がありそうだ。この辺りは Eclipse からのデプロイ等の改善が期待されるところだ。

C:\xxxxxxxxxxxxx\ilovejava>dir /a
 ドライブ C のボリューム ラベルがありません。
 ボリューム シリアル番号は D461-5218 です

 C:\xxxxxxxxxxxxx\ilovejava のディレクトリ

2014/03/15  15:15    <DIR>          .
2014/03/15  15:15    <DIR>          ..
2014/03/15  19:28    <DIR>          .git
2014/03/15  15:15            65,954 hostingstart.html
2014/03/15  20:51    <DIR>          webapps