まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

2017年03月

IBM Bluemix の提供サービスの1つに WAS(WebSphere Application Server) があります:
2017031901
(https://console.ng.bluemix.net/docs/services/ApplicationServeronCloud/index.html)


この IBM Bluemix の WAS サービスを利用する場合、サービスインスタンスのダッシュボード画面から VPN に必要なモジュールや設定ファイルをダウンロードして、VPN で WAS ホスティングサーバーに接続した上で管理コンソールにアクセスしたり、アプリケーションをデプロイしたり、といった手順で管理・利用することが可能になります。

そして必要な設定を変更したり、アプリケーションをデプロイした後に(URL を通知したりして)ユーザーへ公開するわけですが、ユーザーが利用する段階では管理者のように VPN などの利用を条件にしたりはせず、パブリックネットワークから直接アクセスさせるという使い方も少なくないと思います。そのための設定方法を紹介します:
2017031900



まず、IBM Bluemix の WAS サービスをパブリックネットワーク上に公開するには、WAS の HTTP サーバーを 80(http)/443(https) 番ポートで起動させる必要があります(少なくともユーザーにアクセスさせるアプリケーションは 80/443 番ポートで listen している必要があります)。そのため事前に VPN 接続をした状態で WAS 側の設定変更を済ませておく必要があります。WAS Liberty / WAS それぞれの起動ポート番号変更手順については以下を参照ください:
WAS Liberty Core を 80/443 番ポートで動かす
WAS を 80/443 番ポートで動かす


なお、以下は WAS Liberty Core 版の図を使ったりして紹介しますが、WAS フルプロファイル版でも同様だとお考えください。

まずは 80/443 番への起動ポート番号の変更を行った WAS(Liberty) のダッシュボードを IBM Bluemix 上で開きます。以下のようにホストの IP アドレスが確認できる状態になっているはずです(この IP アドレスはプライベートアドレスなので、アクセスするには VPN 接続が必要です):
2017031901


VPN 接続が確立していれば、このアドレスをウェブブラウザで開くと、WAS(Liberty) のトップページが表示されます。他にデプロイ済みのアプリケーションがある場合も同様です:
2017031902


ではこのページに VPN なしでパブリックネットワークからアクセスできるようにするための設定を行います。上記のダッシュボードページに戻り、「パブリック IP へのアクセスを管理」ボタンをクリックします:
2017031903


最初の段階ではまだパブリック IP アドレスが割り振られていないので、「パブリック IP アドレスを要求」します:
2017031904


しばらく処理を待つと先程の画面に戻ります。この時点ではパブリック IP アドレスが割り振られていますが、まだ VPN 内のホストへの転送がクローズされています。再度「パブリック IP へのアクセスを管理」をクリックします:
2017031906


割り振られた IP アドレスからの利用ができるよう、「アクセスのオープン」をクリックします:
2017031907


三度元の画面に戻ってきました。今回は IP がオープンされて、この段階でパブリックアクセスが可能になりました:
2017031908


最後に、(接続済みであれば VPN 接続を切断してから)パブリック IP アドレスにウェブブラウザでアクセスし、元の画面が表示できていることを確認します:
2017031909


なお、この仕組の説明などは以下のドキュメントを参照ください:
https://console.ng.bluemix.net/docs/services/ApplicationServeronCloud/networkEnvironment.html#configureLibertyForPublicAccess


前回(「WAS Liberty Core を 80/443 番ポートで動かす」)の続きです。

今回は軽量版ではなく、いわゆる「フルプロファイル版」などと呼ばれている、従来の WAS(Websphere Application Server)を対象に起動ポート番号を変更する手順を紹介します。また今回も具体的には IBM Bluemix 内の WAS on Bluemix サービスの BASE プランインスタンスを使って紹介します。


では実際に起動ポートを変更します。ウェブブラウザで https://(ホスト名):9433/ibm/console/ にアクセスして管理コンソールを開き、正しいユーザー名とパスワードを入力してログインします:
2017031601


WAS の管理コンソールにアクセスしました:
2017031602


WAS の場合、起動ポート番号はアプリケーションサーバー内の Web コンテナのトランスポートチェーンで管理しています。というわけで、まずは左ペインから サーバー - サーバータイプ - WebSphere Application Server を選択し、アプリケーションサーバーとして起動ポートを変更したいサーバーの名称(デフォルトでは server1)を選択します:
2017031603


選択したアプリケーションサーバー内から Web コンテナー設定 - Web コンテナー・トランスポート・チェーン を選択します:
2017031604


現在設定されている Web トランスポートチェーンの一覧が表示されます。この中に 80 番(http)と 443 番(https)を追加します。まずは 80 番ポートを追加するために「新規作成」ボタンをクリックします:
2017031604


作成するトランスポートチェーンの名称(下図では WCInboundDefault80)を入力し、テンプレートに WebContainer が選択されていることを確認して「次へ」をクリックします:
2017031605


利用するポート番号をここで指定します。「新規ポートの作成」が選択されていることを確認して、ポート名は "80"、ホストは "*" 、ポートは "80" をそれぞれ入力して「次へ」:
2017031606


確認の画面で「終了」を選択します:
2017031607


トランスポートチェーン一覧の画面に戻るので、今回の変更をマスター構成として「保存」します:
2017031608


追加したトランスポートチェーンが一覧に含まれていることを確認します:
2017031609


同様にしてもう1つ、443 番ポート(https)のトランスポートチェーンも新規に作成します。その場合、テンプレートには "WebContainer-Secure" を選択することに注意してください:
2017031601

また、ポート名とポートには "443" を入力します:
2017031602


こうして 80 番ポート(http)と 443 番ポート(https)のトランスポートチェーンが追加されたことを確認します:
2017031603


ここまでの作業ができれば後はサーバーを再起動して、変更を反映するだけです。が、ここも前回紹介した理由により root ユーザー権限でサーバーを起動する必要があります。具体的には ssh 等でログイン後、root ユーザーに su/sudo して、root ユーザー権限でサーバーを止めて、再び起動する、という手順を実行します:

$ sudo /bin/bash

# /opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1

# /opt/IBM/WebSphere/AppServer/bin/startServer.sh server1

# exit

$

これで WAS Liberty Core の時と同様に WAS も 80/443 番ポートで利用できるようになっているはずです。

IBM の Java アプリケーションサーバーである WAS(Websphere Application Server) は標準設定のまま導入して使い始めると、9080 番ポート(http)や 9443 番ポート(https)でサーバーが起動します。これを一般的な 80 番や 443 番で起動させるための設定を紹介します。方法自体はいくつかあるのですが、ここで紹介するのは「とりあえずてっとり早くできる方法」です。 また今回は軽量版である WAS Liberty Core を対象として紹介します(フル機能版は次回)。具体的にはパブリッククラウドであるIBM Bluemix 内の WAS on Bluemix サービスの Liberty Core インスタンスを使って紹介します:


では実際に起動ポートを変更します。WAS Liberty Core の場合はアプリケーションサーバーの server.xml を編集することで変更できるので、まずはこのファイルを探します。

既にアプリケーションサーバーが起動している場合はウェブブラウザからも変更できます。 https://(ホスト名):9080/ にアクセスして、"Open Admin Console" をクリックします:
2017031601


認証が有効に設定されている場合は認証画面になります。正しいユーザー名とパスワードを入力して「送信」します:
2017031602


管理コンソールにアクセスできました。server.xml を編集するには "Server Config" を選択します:
2017031601


構成ファイルとして server.xml が表示されている(これしか表示されてない??)ので、server.xml をクリック:
2017031602


すると server.xml の編集画面に移動します。「ソース」タブで表示すると、XML テキストを直接編集することも可能です:
2017031603


なお、SSH 等でアプリケーションサーバーシステムに直接ログインできる場合であれば、server.xml は以下に存在しているので、このファイルを直接テキストエディタで編集しても構いません:
/opt/IBM/WebSphere/Profiles/Liberty/servers/server1/server.xml


以下の赤字部分4箇所を変更します。変更が完了したら保存(管理コンソールであれば右上のボタン)します:
<server description="Default Hypervisor Server">
  <!-- Simple application server, supporting servlets and jsps -->
  <featureManager>
    <feature>jsp-2.2</feature>
    <feature>adminCenter-1.0</feature>
  </featureManager>
<remoteFileAccess>
<writeDir>${server.config.dir}</writeDir>
</remoteFileAccess>
<virtualHost id="default_host" allowFromEndpointRef="defaultHttpEndpoint">
 <hostAlias>*:80</hostAlias>
 <hostAlias>*:443</hostAlias>
</virtualHost>
<!-- virtualHost id="external_host">
 <hostAlias>*:80</hostAlias>
 <hostAlias>*:443</hostAlias>
</virtualHost -->

  <quickStartSecurity userName="wsadmin" userPassword="{xor}am07ZzlubWg=" />
  <keyStore id="defaultKeyStore" password="{xor}am07ZzlubWg=" />
  <!-- disable automatic configuration and application updates, but leave mbean support enabled -->
  <config updateTrigger="mbean"/>
  <applicationMonitor updateTrigger="mbean" dropinsEnabled="true"/>
  <ssl id="defaultSSLConfig"
     sslProtocol="SSL_TLSv2"
     keyStoreRef="defaultKeyStore"
     clientAuthenticationSupported="true"/>

  <!-- open port 9080 for incoming http connections -->
  <httpEndpoint id="defaultHttpEndpoint"
                host="*"
                httpPort="80"
                httpsPort="443">
      <tcpOptions soReuseAddr="true"/>
  </httpEndpoint>
  <!-- httpEndpoint id="publicHttpEndpoint"
              host="*"
              httpPort="80"
              httpsPort="443">
      <tcpOptions soReuseAddr="true"/>
  </httpEndpoint -->
</server>


設定の変更そのものはこれだけです。後はアプリケーションサーバーを再起動・・・なのですが、OS が Linux の場合はもう1点注意が必要です。

Linux の場合、1024 番未満のポートはデフォルトでは root 権限がないと listen できません
。つまり上記の設定変更をしても再起動の際に root 以外のユーザー権限で再起動するとポートを listen できないのです。

特に IBM Bluemix 環境での場合、OS は RedHat で、その一般ユーザーである virtuser の権限で WAS は起動します。つまり上記の制約をまともに受けてしまうのでした。というわけで、WAS 再起動の際には注意が必要です。具体的にはまず root ユーザーに su(または sudo)し、root ユーザー権限でサーバーを止めて、再び起動、という手順が必要です:
$ sudo /bin/bash

# /opt/IBM/WebSphere/Liberty/bin/server stop server1

# /opt/IBM/WebSphere/Liberty/bin/server start server1

# exit

$


これで WAS Liberty Core が 80/443 番ポートで利用できるようになっているはずです:
2017031603


 

Java で(Web)アプリケーションから REST API を実行する時など、HTTP のクライアント機能を java.net.* から作るのは面倒です。現実的にはなんらかのライブラリを使うことになると思います。

そんな場合によく使われるのが Apache HTTP Client だと思ってます。2017/Mar/16 現在の最新バージョンは 4.5.3 でした。モジュールはこちらからダウンロードできます:
https://hc.apache.org/downloads.cgi

2017031501


上記サイトの HttpClient カテゴリから 4.5.3.zip と書かれたリンクをクリックすると 4.5.3 のバイナリが zip アーカイブとして取得できます(ファイル名は httpcomponents-client-4.5.3-bin.zip)。ダウンロードした zip ファイルを展開し、lib フォルダから jar ファイル群を取り出します(今回のサンプルで最低限必要なのは以下の6ファイルです):
  • commons-codec-1.4.jar
  • commons-logging-1.2.jar
  • httpclient-4.5.3.jar
  • httpclient-cache-4.5.3.jar
  • httpcore-4.4.6.jar
  • httpmime-4.5.3.jar

Eclipse 等で Java のウェブアプリケーションプロジェクトを作成し、lib フォルダ(Webcontent/WEB-INF/lib など)に上記作業で取り出した jar ファイル群をまとめてコピーしておきます。これで準備完了:
2017031502


では実際にこれらのモジュールを使って HTTP アクセスを実現するプログラムを書いて実行してみます。今回はスタンドアロンに HTTP GET を実行する、こんなプログラムにしてみます:
import org.apache.http.HttpEntity;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.util.EntityUtils;

public class HttpClient1 {
  public static void main(String[] args) {
    // TODO Auto-generated method stub
    String url = "https://www.ibm.com/developerworks/jp/"; //. HTTP GET する URL

    try{
      CloseableHttpClient client = HttpClients.createDefault();
      HttpGet get = new HttpGet( url );
      CloseableHttpResponse response = client.execute( get );
      int sc = response.getStatusLine().getStatusCode(); //. 200 の想定
      HttpEntity entity = response.getEntity();
      String html = EntityUtils.toString( entity, "UTF-8" );
      System.out.println( html ); //. 取得結果をコンソールへ
      client.close();
    }catch( Exception e ){
      e.printStackTrace();
    }
  }
}

指定した URL(上記の場合は https://www.ibm.com/developerworks/jp/")に HTTP でアクセスして、GET した結果をコンソールに出力する、というものです。この内容を記述したファイル(HttpClient1.java)を Eclipse から実行します:
2017031503


で、指定した URL  の HTML が取得できることを確認します。HTTP GET は呼び出すだけなのでシンプルですね:
2017031504


アクセス先として HTML のようなテキストではなく、画像のようなバイナリデータの場合は以下のように byte 配列として結果を取得します(HTTP リクエストヘッダを設定する例も加えています):
import org.apache.http.HttpEntity;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.util.EntityUtils;

public class HttpClient2 {
  public static void main(String[] args) {
    // TODO Auto-generated method stub
    String url = "https://dw1.s81c.com/developerworks/i/f-ii-ibmbluemix.png"; //. HTTP GET する URL

    try{
      CloseableHttpClient client = HttpClients.createDefault();
      HttpGet get = new HttpGet( url );
      get.addHeader( "User-Agent", "MyBot/1.0" );  //. HTTP リクエストヘッダの設定
      CloseableHttpResponse response = client.execute( get );
      int sc = response.getStatusLine().getStatusCode(); //. 200 の想定
      HttpEntity entity = response.getEntity();
      byte[] img = EntityUtils.toByteArray( entity );
      System.out.println( "" + img.length ); //. 取得結果をコンソールへ
      client.close();
    }catch( Exception e ){
      e.printStackTrace();
    }
  }
}

一方、HTTP POST の場合も同様ですが、GET の時との違いとしてポストデータを送信する必要もあります。以下はテキスト情報とファイルのアップロードを同時に(Multipart で)送信する場合の例です:
import java.io.File;
import java.io.FileInputStream;

import org.apache.http.HttpEntity;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.entity.ContentType;
import org.apache.http.entity.mime.MultipartEntityBuilder;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.util.EntityUtils;

public class HttpClient3 {
  public static void main(String[] args) {
    // TODO Auto-generated method stub
    String url = "https://xxx.com/posturl"; //. HTTP POST する URL

    try{
      CloseableHttpClient client = HttpClients.createDefault();
      HttpPost post = new HttpPost( url );

//. 文字情報2つとファイル1つをポスト MultipartEntityBuilder builder = MultipartEntityBuilder.create(); builder.addTextBody( "name", "K.Kimura", ContentType.TEXT_PLAIN ); builder.addTextBody( "email", "dotnsf@jp.ibm.com", ContentType.TEXT_PLAIN ); File f = new File( "./logo.png" ); builder.addBinaryBody( "image_file", new FileInputStream( f ), ContentType.APPLICATION_OCTET_STREAM, f.getName() ); HttpEntity multipart = builder.build(); post.setEntity( multipart ); CloseableHttpResponse response = client.execute( post ); int sc = response.getStatusLine().getStatusCode(); //. 200 の想定 HttpEntity entity = response.getEntity(); String html = EntityUtils.toString( entity, "UTF-8" ); System.out.println( html ); //. 取得結果をコンソールへ client.close(); }catch( Exception e ){ e.printStackTrace(); } } }

PUT や DELETE の場合も同様に。

Node.js で画像を扱う際に使える便利なミドルウェアモジュールの1つが easyimage です。内部的に ImageMagickを使うので別途導入が必要ですが、このモジュールを使うことで画像のリサイズや切り取りといった処理が簡単にできるようになります。以前にこのブログでも紹介した IBM Watson の類似画像検索サンプルの中でも使っています。


ところが、最近このモジュールを使って画像のリサイズを行っている中で不思議な挙動に遭遇することが何度かありました。現象の特徴はこんな感じでした:
  1. resize() メソッドを実行するとエラーが発生する
  2. エラーメッセージは [Error: File not supported.]
  3. このエラーが発生しても、リサイズ処理そのものは成功している
  4. 以前はこのようなエラーは発生しなかった
    • Node.js や easyimage モジュールのバージョンは以前から同じ
    • 以前は Linux で開発しており、その時はこのエラーには遭遇しなかった。このエラーが発生しているのは Windows 環境

要はリサイズ処理そのものは成功するのですが、Windows だとエラーが発生する(Linux だとしない)という、なんかややこしそうな、嫌な感じの特徴です。しかも Node.js なので非同期にこのリサイズ処理が実行されるため、
var easyimg = require( 'easyimage' );
  :

var option = { src: 'images/src.png', dst: 'images/dst.png', width: 800 };
easyimg.resize( option ).then(
  function( file ){
    :  // 成功した場合の処理
  },
  function( err ){
    :  // エラーになった場合の処理
  }
);

というコードになっています。そして Linux 環境で実行すると成功した場合の処理が行われ、Windows環境だとエラーになった場合の処理で 'File not supported' なエラーが発生するのですが、実際にはどちらもリサイズされた結果が images/dst.png に作られている、という状況になります。ややこしいでしょ?

最初は自分のコードのミスを疑っていたのですが、調べてみるとこの現象は Open Issue として公開されている(要するに障害としては認識されている)ことがわかりました:
https://github.com/hacksparrow/node-easyimage/issues/27


とはいえ、現時点で有効な修正が提供されているわけではないため、Linux でも Windows でも動くようにワークアラウンドを考える必要があります。自分の場合はシンプルに「成功したら普通に処理、エラーが発生しても無視して処理」するようにしました:
var easyimg = require( 'easyimage' );
  :

var option = { src: 'images/src.png', dst: 'images/dst.png', width: 800 };
easyimg.resize( option ).then(
  function( file ){
    :  // 成功した場合の処理
  },
  function( err ){
    :  // エラーになった場合
 (エラーを無視して成功した場合と同じ処理を実行)
  }
);

もう少し便利な方法ないかなと思いつつ、早くこの障害が直ることを期待しつつ、とりあえずこの方法で回避しています。

このページのトップヘ