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

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

タグ:iaas

前回dokku を使ったプライベート PaaS 環境の構築、およびシンプルなアプリケーションのデプロイ手順を紹介しました。 今回はより実践的なアプリケーションとして PostgreSQL データベースを併用するアプリケーションのデプロイ手順を紹介します(といっても、実は heroku を CLI で操作する時の手順とあまり変わりません・・)。

なお今回紹介する内容は、前回のセットアップ時に "withcorona.world" という独自ドメインを設定している想定で紹介しています。異なるドメインで設定されている場合は自分で設定したドメインに適宜読み替えてください。


【dokku 内で PostgreSQL データベースを動かす】
まず dokku 環境内にデータベースサーバーを用意します。今回は PostgreSQL を使うケースを想定して以下で紹介します。まずは dokku サーバーにログインしておきます。

dokku ではいくつかのサービスが「プラグイン」という形で連携できるよう用意されています。PostgreSQL もその1つです。というわけで、まずは dokku にログインして PostgreSQL プラグインをインストールします:
# dokku plugin:install https://github.com/dokku/dokku-postgres.git

インストールが完了すると PostgreSQL データベースをインスタンス化することができるようになります。例えば "mydb" という名前を付けて1インスタンス作るには以下のように入力します:
# dokku postgres:create mydb

作成後に作ったデータベースインスタンスの情報を確認する場合は以下のように入力します:
# dokku postgres:info mydb

=====> mydb postgres service information
       Config dir:          /var/lib/dokku/services/postgres/mydb/data
       Config options:
       Data dir:            /var/lib/dokku/services/postgres/mydb/data
       Dsn:                 postgres://postgres:XXXXXXXX@dokku-postgres-mydb:5432/mydb
       Exposed ports:       -
       Id:                  a017a6896694987cb0e729b4ec1042f831eecd0d8f726d52eeea435ecd9fcf4e
       Internal ip:         172.17.0.3
       Links:               -
       Service root:        /var/lib/dokku/services/postgres/mydb
       Status:              running
       Version:             postgres:14.2

この確認結果の Dsn 値として紹介されている "postgres://" で始まる文字列がいわゆる接続文字列になっていて、(後述する)環境変数の値になります。 このインスタンスのシェルに入って PostgreSQL の CLI を使ってテーブルを1つ定義しておきたいので、以下のように実行してください(データベースに接続する時は接続文字列の "dokku-postgres-mydb" 部分を "localhost" に変えて実行してください):
# dokku postgres:enter mydb (シェルにログイン)

/# psql "postgres://postgres:XXXXXXXX@localhost:5432/mydb" (psql でデータベースに接続)

mydb=# create table if not exists items ( id varchar(50) not null primary key, name varchar(50) default '', price int default 0, created bigint default 0, updated bigint default 0 ); (SQL で items テーブル作成)

mydb=# \q (データベースから切断)

/# exit (シェルからログアウト)

これで dokku 環境内に mydb という名前の PostgreSQL データベースを1つ作り、items という名前のテーブルを1つ定義する所まで用意できました。続いて、この mydb データベースと items テーブルを使ったウェブアプリケーションを dokku 内で動かします。


【dokku 内で PostgreSQL データベースに接続するアプリケーションを動かす】
dokku 内で PostgreSQL データベースを使うアプリケーションを動かします。今回は以下のサンプルを使います(上記で作成した items テーブルを使うアプリケーションです):
https://github.com/dotnsf/cnapp_postgresql


このアプリケーションの PostgreSQL と接続する部分は以下のように記述されています:
  :
  :
var database_url = 'DATABASE_URL' in process.env ? process.env.DATABASE_URL : settings.database_url; 
var pg = null;
if( database_url ){
  console.log( 'database_url = ' + database_url );
  pg = new PG.Pool({
    connectionString: database_url,
    idleTimeoutMillis: ( 3 * 86400 * 1000 )
  });
  :
  :


具体的な挙動としては、アプリケーション実行時の "DATABASE_URL" という環境変数値を参照し、値が設定されていたらその内容を接続文字列とみなして PostgreSQL サーバーに接続する、という実装内容になっています(説明は省略しますが、接続後に items テーブルを読み書きする内容になっています)。

なので、このアプリケーションが dokku 内で実行される時に、先ほど作成した mydb データベースへの接続文字列が環境変数 DATABASE_URL として定義されていればこのアプリケーションは正しくデータベースに接続して動く、ということになります。

この辺りは heroku ユーザーであればなんとなく「同じだ・・」とわかると思います。で、その環境変数を設定するためには dokku 内のアプリケーションとデータベースがリンクさえされていれば実現できるようになっています(この辺りはクラウドネイティブアプリケーションを開発する際の 12 factors と呼ばれるベストプラクティスに沿った仕様となっています)。

というわけで、まずは dokku にアプリケーションを追加し、データベースとのリンクを設定します。今回は "cnapp" という名前のアプリケーションを作ることにして、この "cnapp" アプリケーションと "mydb" データベースをリンクしておきます(これで cnapp アプリの実行時にデータベース mydb に接続するための接続文字列が環境変数 DATABASE_URL にセットされて起動します):
# dokku apps:create cnapp

# dokku postgres:link mydb cnapp

そして前回同様にこのサンプルアプリを Git clone して、リモート接続先に dokku を追加して、main ブランチを push します:
# git clone https://github.com/dotnsf/cnapp_postgresql

# cd cnapp_postgresql

# git remote add dokku dokku@withcorona.world:cnapp

# git push dokku main

ここまでのコマンドが正しく実行されていると http://cnapp.withcorona.world/ でアクセスできるようになります※:

2022060101


※稀にこの URL では想定していないページ(Nginx のデフォルトページなど)が表示されることがあります。その場合は http://cnapp.withcorona:8080/ のようにポート番号をつけてアクセスするとうまくいきます。その後に以下のコマンドを実行するとポート番号指定なしでも正しく表示できるようになります:
# dokku proxy:ports-add cnapp http:80:8080


これだけでも一応動きますが、ついでに(?) https 接続できるよう、Let's Encrypt プラグインの設定も行っておきます:
# dokku letsencrypt:enable cnapp

最後にウェブブラウザで https://cnapp.withcorona.world/ にアクセスして動作確認します:
2022060102


最初は何も登録されていませんが、名前(name)と価格(price)を入力して追加(Create)すると、そのデータが( PostgreSQL の)mydb データベースの items テーブルに登録され、一覧として表示されるようになります:
2022060103


以上、dokku でデータベース連携アプリケーションを作って動かすための設定でした。PostgreSQL 以外にも dokku には公式機能として MySQL や Redis 、ElasticSearch といったプラグインが用意されているので、クラウドで認証した結果をセッション共有するようなアプリケーションでも動かすことができると思います。




ある程度 heroku を使ったことがある人であれば、dokku は文字通りに heroku ライクなプライベート環境に感じることができると思います(ただ dokku だとほとんどの作業が CLI からのコマンドになる点が、ウェブ GUI で色々用意されている heroku とは異なる点です)。また Cloud Foundry と比較しても、Cloud Foundry では
$ cf push (app)

のようにしてアプリをデプロイしていましたが、dokku はほぼ同様にして、
$ git remote add dokku (app) (を一度実行してから)
$ git push dokku main

といった形でアプリのデプロイができるので、Cloud Foundry の代わりとしても使いやすい環境のように感じています。今回紹介した withcorona.world というドメインは実験用の捨てドメインなのでおそらくこの紹介記事でしか使うことはないと思っていますが、他の取得ドメイン(とちょっと規模の大きめな IaaS 環境)を使って自分のプライベート Cloud Foundry 環境を作って運用してみるつもりでいます。



唐突ですが、自分も使っている IBM Cloud の PaaS 機能の1つである Cloud Foundry ランタイムのサービス終了がアナウンスされました:
Cloud Foundry on IBM Cloud サービス提供終了のお知らせ


個人的にもサービス開始とほぼ同時期から使っていたユーザーとして、またソースコードから一発でクラウド環境で動かすことができる環境として使っていただけに、とても残念なニュースでした。実は少し前から知ってはいたのですが、公開できるのが今日からということで公にできずに悶々としていました(代わりにこのブログの公開準備を進めていました)。

で、IBM Cloud として推奨している移行先は Kubernetes 系サービスや Code Engine とされています:
IBM Cloud FoundryからCode Engineへのマイグレーションに関するベスト・プラクティスの紹介:サービス・バインディングとコード


Code Engine は Kubernetes の K-native をベースとしたコンテナ・ランタイム環境です。無料で使用可能なリソース枠も用意され、これまで Cloud Foundry で動いていたアプリケーションを比較的容易に移行できる環境となっております。


ただ、私自身はこの Code Engine に加えて、以下で紹介する dokku 環境も Cloud Foundry からの移行先としてアリだと思っています。Cloud Foundry よりも heroku と比較されることが多く、また残念ながら無料で運用できるわけではない(プライベート環境なので、そのサーバーリソースが必要)のですが、一方で独自ドメインが使える上にコンテナイメージを意識することなくソースコードから稼働環境を簡単に作れる、という点で相性は悪くないと思っています。 そんな意味も含めて、このタイミングで紹介させていただくことにしました。

予定としては2回に分けて、前半である今回はセットアップ部分を中心に、次回の後半でデータベースなど外部リソースとの連携について触れるつもりでいます。





昨年あたりから heroku を使うことが多くなってきました。無料でもある程度利用できるクラウドリソースが PaaS で提供され、Git と連動してアプリケーションのデプロイができるのが非常に便利です。

とても便利なので利用頻度が高くなっていき、あっという間に無料枠の限界が近づき・・・そして同時に無料枠の制約(インスタンスが使われていないと自動的に止まっちゃうとか、複数インスタンスで運用できないとか)を超えた使い方にも興味が出てきます。そうなってくるとパブリックな heroku 利用もいいけど、プライベートな heroku 環境を自由に使えたらいいなあ、というエンジニア欲も出てきます。

そんな背景もあって、「プライベート版 heroku 」という側面もある dokku を使ってみることにしました。dokku は内部的に docker を使って1台のサーバー内に仮想的な PaaS 環境を構築するものです。heroku (や Cloud Foundry )同様にビルドパックを使った git push デプロイが可能なので、手元のソースコードを簡単に(Dockerfile とか docker イメージ化などを意識せずに)ウェブ上に公開することもできます。1台のサーバーで運用することを想定しているため可用性という面では足りないと感じる面があるかもしれませんが、自分のように作ったアプリを試験的に公開する、という機会が多い場合に非常に重宝します。またプライベート PaaS はインフラ部分の管理を自分で行うことを意味していますが、その点では1台のサーバーの面倒だけみればよい、というのはある意味でアドバンテージにもなり得るものと考えています。

今回は以下の条件で環境を構築してみました:
 ・(2022/06/01 時点で最新の)dokku v0.27.5 を使用する
 ・IBM Cloud 上に Ubuntu サーバーを1台用意して、この中に dokku 環境を導入する
 ・GoDaddy.com で取得した独自ドメイン(withcorona.world)を使った PaaS 環境を作る

IBM Cloud 上に IaaS サーバー(Ubuntu 18.04)を用意するので、このサーバー料金が必要です。IBM Cloud である必要はありませんが、後述のように DNS の設定ができる IaaS 環境が必要です(Vultr.com では同様の設定ができることを確認しています)。なお、dokku は独自ドメインを使わなくても、sslip.io サービスを併用した疑似サブドメインを使って環境構築することもできますが、今回の紹介内容では軽く触れる程度とし、動作確認などは除外させていただきます。


【dokku 環境構築】
では早速 dokku 環境を用意して、アプリケーションを dokku 上で動かしてみます。まずは1度行う必要のある環境構築の手順を紹介します。

最初にクラウド上に Ubuntu サーバーを用意します。今回利用する dokku v0.27.5 では Ubuntu 18.04, Ubuntu 20.04, Ubuntu 22.04 までがサポート対象となっていましたが、古い記事で Ubuntu 18.04 だけがサポートされていたドキュメントを参照していたこともあり、自分も Ubuntu 18.04 を使うことにしました。なお Debian 系はサポート対象ですが、RHEL/CentOS 系は 2022/06/01 時点では Experimental 機能としての提供です。

(自分の場合は)IBM Cloud 上に Ubuntu 18.04 サーバーを1台用意します。スペックは 1 vCPU で 2GB RAM のものとしましたが、ここで選ぶスペックが自分の dokku 環境となるので、比較的多くのアプリケーションを動かす場合や、(多くの DB など)多くのリソースを使うことが想定される場合は少し大きめのサーバーを用意してください:
2022060101


サーバーが用意できたら次はネームサーバーをはじめとする DNS の設定が必要です(独自ドメインを使わない場合はここを無視して dokku のインストール作業まで進んでください)。まずは自分が使うサーバー(今回だと IBM Cloud のサーバー)で DNS を設定するために必要なネームサーバー設定を確認します。IBM Cloud の場合は以下のように
 ・プライマリサーバー: ns1.softlayer.com
 ・セカンダリサーバー: ns2.softlayer.com
を設定するように指定されていることが分かります。ここは皆さんが用意したクラウドサーバーのプロバイダーによって異なるので、自分の環境のネームサーバー設定を調べる必要があります:
2022060102


このネームサーバー設定を自分が取得した独自ドメインに適用します。今回の例では GoDaddy.com で取得した独自ドメインを使うので、GoDaddy.com の DNS 設定を変更することになります。 なお今回は "withcorona.world" という独自ドメインを使って、app1.withcorona.world, app2.withcorona.world, ... といった名称のアプリケーションを運用する前提とします。まずは自分がドメインを取得したベンダーのネームサーバー設定画面(DNS 設定画面)に移動します:
2022060103


ここでネームサーバーを変更します。GoDaddy.com の場合は DNS 管理画面の少し下に設定済みのネームサーバーが表示されている画面があるので、ここの「変更」ボタンをクリックします:
2022060104


そして先ほど確認したプライマリ/セカンダリサーバーを指定します。IBM Cloud の場合はプライマリが ns1.softlayer.com 、セカンダリが ns2.softlayer.com だったので、以下のように入力し、最後に「保存」ボタンをクリックします:
2022060105


この作業はこれまで使っていた独自ドメインの DNS 設定を大きく変えることになるので警告メッセージが表示されることがあります。内容を確認して「続行」します:
2022060106


無事に設定が変更されていることを確認します(この変更内容が実際に有効になるまで1時間程度かかることがあります):
2022060107


ネームサーバーの設定変更が出来たら、次は DNS を dokku 向けのものに変更します。新しい DNS 設定画面(今回の例では IBM Cloud の DNS 設定画面)に移動し、まずメインサーバーとなる独自ドメイン名(今回の例では "withcorona.world")と、 Ubuntu サーバーの IP アドレスを入力してドメインを登録します:
2022060108



そして残りの設定を行います。dokku を独自ドメインで利用するには、以下の内容を設定する必要があります:
レコードターゲット
A@(サーバーの IP アドレス)
CNAME*(独自ドメイン名)


なお IBM Cloud の場合は上述の設定ではなく、以下の設定が必要でした(* は CNAME レコードではなく A レコードとして、ターゲットは独自ドメイン名ではなく IP アドレスで指定する必要がありました):
レコードターゲット
A@(サーバーの IP アドレス)
A*(サーバーの IP アドレス)


最終的にこのような DNS 設定となりました:
2022060109


ここまでの作業で dokku 導入前の事前準備が完了です。ここからは dokku のインストール作業を紹介します。


まず SSH 等で Ubuntu サーバーのシェルにログインします。root 以外でログインした場合は "sudo -i" を実行するなどして root に切り替え、"apt update" と "apt upgrade" を済ませておきます:
$ sudo -i

# apt update -y

# apt upgrade -y

以下のコマンドを実行して dokku を(dokku v0.27.5 を)インストールします:
# wget https://raw.githubusercontent.com/dokku/dokku/v0.27.5/bootstrap.sh;

# DOKKU_TAG=v0.27.5 bash bootstrap.sh

2つ目のコマンドが完了(5~10分くらい)すると(docker ごと)dokku が導入されています。

独自ドメインを利用する場合はそのドメインを登録するため、以下のコマンドを実行します(最後の withcorona.world 部分に独自ドメイン名を指定します):
# dokku domains:set-global withcorona.world

このコマンド実行後に、/home/dokku/VHOST ファイルの中身が指定した独自ドメインになっていることを確認してください:
# cat /home/dokku/VHOST

withcorona.world (と表示されることを確認)

また独自ドメインを所有していない(使わない)場合は以下のコマンドを実行して、sslip.io サービスを使った疑似サブドメインを登録します(最後の 11.22.33.44 部分に Ubuntu サーバーの IP アドレスを指定します):
# dokku domains:set-global 11.22.33.44

# dokku domains:set-global 11.22.33.44.sslip.io


次に、実際に dokku を使う前に(dokku の git 利用時に必要な)秘密鍵と公開鍵のペアを登録する必要があります。普段使っている秘密鍵&公開鍵があればそれを使っても構いませんし、今回の作業のために新たに1ペア作って使っても構いません。鍵ファイルの作り方はこちらなどを参照してください。ここでは秘密鍵: id_rsa 、公開鍵: id_rsa.pub という2つの鍵ファイルが手元にあるものとします。

これらを dokku のサーバー環境に登録します。まずは sftp などでこれら2つのファイルを Ubuntu サーバーの /root/.ssh/id_rsa および /root/.ssh/id_rsa.pub となるよう転送しておきます。ここまでの作業ができているものとして以下の説明を続けます。

まず鍵ファイルはファイルパーミッションが正しくないと正しい挙動になりません。これら2つのファイルのパーミッションを 400 にしておきます:
# chmod 400 /root/.ssh/id_rsa*

これら2つのファイルを dokku 環境に登録します。まずは以下のコマンドを実行して秘密鍵を登録します:
# eval `ssh-agent`

# ssh-add -k ~/.ssh/id_rsa (秘密鍵のパスフレーズ入力を求められるので正しく入力します)

続けて公開鍵も登録します:
# cat ~/.ssh/id_rsa.pub | dokku ssh-keys:add admin

dokku 作業としてはここまででほぼ完了しているのですが、ついでに SSL(https) 接続を想定した準備もしておきましょう。以下の2つのコマンドで Let's Encrypt プラグインを導入・設定しておきます:
# dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git

# dokku config:set --global DOKKU_LETSENCRYPT_EMAIL=(自分のメールアドレス)

実際にアプリケーションをデプロイする前の、dokku 環境構築に必要な(1回だけの)作業は以上で終わりです。


【dokku でウェブアプリを動かす】
では構築した dokku 環境を使って実際にウェブアプリケーションを稼働させてみます。ここからの内容は dokku に新しいアプリケーションをデプロイするたびに必要な作業です(ここよりも上で紹介した作業は環境構築時に1回行うだけ)。

まずはウェブアプリケーション(のソースコード)が必要ですが、今回は自分が作ったシンプルな「ハローワールド」アプリであるこれを使って紹介することにします(自分で作ったウェブアプリがある場合はそちらを使っていただいても構いません):
https://github.com/dotnsf/simpleweb


このサンプルはアプリというほどの内容ではないのですが、起動してアクセスすると以下のような画面が表示される、というものです。GitHub ページでも公開しているので、実際のサンプルを見たい場合はこちらにアクセスしてください:
https://dotnsf.github.io/simpleweb/

2022060112
(機能はこれだけ)


過去に heroku や Cloud Foundry、Docker、Kubernetes などのコンテナ環境でクラウドネイティブなアプリを作ったことがある人であれば問題ないと思いますが、ウェブアプリケーション起動時のポート番号を環境変数 PORT から取得するようにしている点にご注意ください(以下はこの simpleweb アプリの app.js のソースコード):
//. app.js
var express = require( 'express' ),
    app = express();

app.use( express.static( __dirname + '/web' ) );

var port = process.env.PORT || 8080;
app.listen( port );
console.log( "server starting on " + port + " ..." );

では改めてこのコードを例にして dokku 環境で動かすまでの手順を紹介します。まずは "dokku apps:create" コマンドで新しいアプリケーション(今回はアプリケーション名を simpleweb としています)を作成します:
# dokku apps:create simpleweb

次に git clone でソースコードを入手して、ディレクトリ内に移動します:
# git clone https://github.com/dotnsf/simpleweb

# cd simpleweb

(heroku と同様ですが)このソースコードに新しいリモート Git オリジン(dokku)として、dokku 内の Git リポジトリを追加します:
# git remote add dokku dokku@withcorona.world:simpleweb

そして今追加したオリジン dokku に main ブランチを git push します:
# git push dokku main

(秘密鍵のパスフレーズを聞かれるので入力する)

秘密鍵のパスフレーズを聞かれるので入力すると、GitHub ではなく dokku の内部ソースコードリポジトリにコードが Push され、該当ソースコード向けのビルドパック(今回の例であれば Node.js ビルドパック)を使ってソースコードが dokku 内のコンテナとしてデプロイされて起動します(1分くらいかかります)。この辺りの一連の流れは Cloud Foundry のものに近いです。


無事にデプロイが完了すると、http://(アプリ名).(ドメイン名)/ という URL でパブリックアクセスできるようになります。今回の例であれば http://simpleweb.withcorona.world/ です(この時点ではまだ https ではアクセスできません)※。 なおドメイン名を使わない場合は http://(アプリ名).xx.xx.xx.xx.sslip.io/ でアクセスできます(xx.xx.xx.xx は Ubuntu サーバーの IP アドレス):
2022060110


※稀にこの URL では想定していないページ(Nginx のデフォルトページなど)が表示されることがあります(そうなったりならなかったりします・・・)。Nginx のデフォルトページが表示されてしまう場合は http://(アプリ名).(ドメイン名):8080/ のようにポート番号をつけてアクセスするとうまくいきます。その後に以下のコマンドを実行するとポート番号指定なしでも正しく表示できるようになります:
# dokku proxy:ports-add simpleweb http:80:8080



https でアクセスできるようにするにはもう少しコマンドが必要です。単に https でアクセスできるようにするには(Let's Encrypt で証明書を取得して適用するだけであれば)以下の dokku コマンドを入力するだけです:
# dokku letsencrypt:enable simpleweb

更に証明書の自動更新までを有効にする場合は、続けて以下のコマンドを実行します:
# dokku letsencrypt:auto-renew simpleweb

ここまで正しく完了すると SSL 証明書が発行&適用されて https://simpleweb.withcorona.world/ でもアクセスできるようになります(ドメインを使わない場合はこの作業を省略しても https アクセスできます):
2022060111


なお、この方法で dokku にデプロイされたアプリケーションは heroku の無料利用時のように(アクセスが一定時間以上なかった場合に)自動停止することはなく、また以下のコマンドでスケールアウトすることもできます(この例ではインスタンス数=3):
# dokku ps:scale simpleweb web=3

利用想定規模と環境構築先の Ubuntu サーバーの規模を合わせて構築することで、非常に有用なプライベート PaaS 環境になりうると思いました。


【まとめ】
今回紹介した dokku を使ったプライベート環境は(無料ではありませんが) heroku ユーザーにとってもメリットを感じられるものだと思います。

今回は dokku 環境の構築と、ランタイム部分(ウェブアプリケーション部分)を dokku 環境でデプロイするまでの手順を紹介しました。次回は(これも heroku での作業とほぼ一緒だったりしますが)PostgreSQL などのデータベースサービスを dokku 内に作ったり、データベースと組み合わせてウェブアプリケーションを動かす方法を紹介する予定です。


【参照】
今回は最小限のインストール手順やコマンドだけを紹介しましたが、詳しくは以下も参照ください:

dokku 公式インストール手順
dokku デプロイコマンド


(2022/06/04 追記)
後編はこちら
http://dotnsf.blog.jp/archives/1080505175.html
 

普段 IBM Bluemix の紹介ばかりしている。ので、少し毛色の違うエントリにしてみます。IaaS と PaaS の共生というか、共存環境についてです。


IBM Bluemix をはじめとする PaaS(Platform as a Service) の特徴の1つはアジャイル性だと思っています。オンプレミス環境や IaaS(Infrastructure as a Service) の環境と比べて、目的のサーバー環境を短時間&少手間で用意できる、という点です。

もう少し詳しく説明すると、例えばこのような構成が必要なアプリケーションの実行環境を作るケースを考えてみるとわかりやすいかもしれません。


(概念図ですが)Java アプリケーションサーバーとデータベースを使って動くアプリケーションがあるとします。この図ではそれぞれが1台ずつで構成されているのですが、小規模利用であればこのままの構成で使うこともあるでしょう(A):
2015081101


この環境を IaaS で作るべきか、PaaS で作るべきか、を判断するケースは珍しくないでしょう。後述する自由度の問題もありますが、このプラットフォームの環境構築に絞って考えると、具体的には手順というか、手間は全く異なります。IaaS だと最初に用意されるのは最小限のネットワーク構成がなされた最小構成の Linux や Windows といった "OS" です。ここにログインしてネットワーク構成を変えたり、場合によってはファイアウォールの変更もした上で Java のアプリケーションサーバーを導入し、セットアップします。ここまでの手順を経てようやく Java アプリケーションサーバーとして利用可能になります。 一方 PaaS であれば、はじめからプラットフォームとして「Java アプリケーションサーバー」を選べばいいので、サーバーの稼働と同時に Java アプリケーションサーバーが使えるようになります。極端な言い方になりますが、「楽に作るなら PaaS」で「自分なりの設定をしたいなら IaaS」という感じになりますかね。どちらかいいのか、の答はケースバイケースだと思います:
2015081103


また、同じアプリケーションを大規模に利用しようとすると少し構成が変わります。ユーザーからの大量アクセスに備えてアプリケーション部分を複数台構成にする必要が出てきます。ということはそれらの振り分けを行うロードバランサも必要になります(B):
2015081102



これら (A) と (B) は同じアプリケーションを異なるお客様が利用するケースといえます。IaaS で (B) の環境を作ろうとした場合に、(A) で行った環境構築の作業をサーバー数の分だけ繰り返して行う、という必要はありません(1つ作った環境をコピーすればよい)が、ロードバランシングの設定は必要です。

一方、PaaS の場合は初めからアプリケーションサーバー目的でインスタンスを作ることを想定しているということもあり、IBM Bluemix を含む多くのケースでロードバランサが内蔵または標準装備されています。要はそもそも1台で動かすのか複数台で動かすのかの違いを意識する必要がないような提供形態になっています。


このように、アプリケーションプラットフォームの構築において、PaaS は単に「手間がかからない」というだけでなく、構成自体がアプリケーションサーバー用に最適化されていることで、同じアプリケーションでも色々なパターンでの提供にアジャイルに対応できる、という特徴があると考えています。


でも PaaS にも弱点があります。それが「自由度」です。PaaS はアプリケーションプラットフォームを提供する形態であるため、「アプリケーションサーバーのインスタンスを作る」ことに最適化されています。ただアプリケーションプラットフォーム全体の中にはアプリケーションサーバー以外の用途で使いたいインスタンスが存在しているケースもあります。

例えば「クローラー」と呼ばれるエージェント機能がその典型です。インターネットやイントラネット上の情報をかき集め、構造化してデータベースに記録して、ウェブのアプリケーションから利用できるような情報を収集する機能です。ユーザーからのリクエストに応じて動く機能ではなく、基本的には24時間365日、バックグラウンドでずっと動き続ける機能といえます。

このクローラー機能に関しては IaaS であれば何通りかの方法で実現できます。典型的なものが cron と呼ばれるスケジュールタスク機能を使って、定期的に指定のアプリケーションを実行させて、この中でクローラーを動かすことで実現できます。常に動かす必要がないクローラーに関しても、サーバーに直接ログインしてコマンドを実行すれば動かすことができるので、自由度高くクローラーを実現することができます。

一方でこのクローラー機能に関しては PaaS は不利です。もともとがウェブアプリケーションプラットフォームを便利に提供するためのサービスであり、ウェブアプリケーションサーバー以外の機能については本体だけでは提供されていないことも多くあって、なんらかの外部サービス等で補足する必要があったりします。

ちなみに IBM Bluemix の場合であれば、スケジュールされたタスクを動かす "Workload Scheduler" サービスを使うことで cron ライクな機能をランタイム内に実現することができるようになっています。なので Bluemix 環境に限ってはこのサービスを使う方法もありますが、必ずしも全ての PaaS 環境で実現されているわけではありません。また Bluemix 環境でもこのサービスの仕様にある程度は依存してしまうので、自由度の面ではやはり不利といえなくもありません。この「クローラー」機能を実装するようなケースは、PaaS のアジャイル性が不利になってしまうケースと言えます。


ただ、これらを調べていくことでクラウドプラットフォームの中での IaaS/PaaS の使い分けや共存に関するヒントが見えてくるように感じます。要は「適材適所に得意分野を任せる」という考え方です。上記のようなアジャイル性が求められる部分が PaaS で、クローリングやスケジュールタスクに関する部分は IaaS で、というのはその一例と言えます。他にも基本機能は PaaS の実装が理想であるが、一部にネットワークパフォーマンスが求められる特定処理があるケースであれば、その部分がボトルネックにならないよう、その処理はネットワークパフォーマンスの高いプラットフォーム(例えば IBM SoftLayer)を使う、という選択肢も考慮に入れるべきです。

クラウドが普通になってくると、IaaS と PaaS の共存も普通になっていくのでしょうかね。そういった際の考慮ポイントを理解するためにも、IaaS / PaaS それぞれの得意/不得意分野を正しく理解しておくことが大事になるのだと思います。


・・・で、長い前置きに続いて、ここからは宣伝です(笑)。

実はこのような内容のセミナーを9月2日(水)の SoftLayer Bluemix サミット2015 内の一講演としてさせていただくつもりです:
http://softlayer.connpass.com/event/17037/

※↑TrackE の 16:30 - 17:00 の回です


講演では IaaS と PaaS の両方を使って構築するようなアプリケーションの実例を紹介し、具体的にどのような構成が理想的なのか、というポイントをアプリケーションの特性に合わせながら考えていくような内容にする予定です。 Bluemix に限った内容ではなく、PaaS/IaaS 全般に対する内容にするつもりです。

興味とお時間があれば、是非9月2日にベルサール渋谷へお越しください。お待ちしております。

以上、宣伝でした(笑)。


 

まず最初に、今回のブログエントリは IBM Bluemix の中でも現状では承認制のベータ機能を紹介するものなので、Bluemix アカウントを持つ全ての人が使えるわけではない、ということをお断りしておきます。

ただ、それでもこの機能はこれまでの IBM Bluemix では苦手としていた自由度の高いサーバーインスタンスを作る(もはやサーバーである必要もなく、デスクトップでもいいけど)という点で大きなアドバンテージのある機能なので、既に使える人や、今後承認されて使えるようになる人向けに紹介します。


IBM Bluemix はオープンソースの PaaS である CloudFoundry をベースにしたクラウド環境です。ということもあって、これまでは「Bluemix は PaaS」と紹介することも多くありました。これはこれで間違いではないのですが、PaaS 故の得意・不得意分野がありました。例えば「アプリケーションサーバーを追加する」とか「データベースサーバーを追加する」といった目的であれば PaaS の土俵なので、IaaS 環境と比べても非常に高いアドバンテージを発揮できていました。しかし「サーバーではなくひたすらバッチ処理を実行するインスタンスを追加したい」とか「SSH でログインして必要に応じて各種ログを見たい」といった自由度の高い目的を実現しようとすると PaaS の特徴が制約となってしまい、IaaS 環境と比べて面倒に感じることもありました。

そんな中、IBM Bluemix は進化を遂げました。もともとは CloudFoundry をベースとした PaaS でしたが、今では Docker コンテナとして利用することもできます(これも承認制)し、更には今回紹介する OpenStack の VM インスタンスを作成することもできます。こうなるともはや PaaS と呼ぶことに抵抗が出てきます。IBM Bluemix は今や「CloudFoundry をベースとした IBM サービスの PaaS であり、Docker のコンテナであり、OpenStack VM の IaaS でもある統合クラウド環境」と説明する方が的確だと感じます(長いけど)。
2015050601


これは非常に魅力的なクラウド環境です。例えばアプリケーションサーバーは Docker のコンテナ資産として用意されているものを流用しながらバックエンドサービスで IBM のコグニティブ(認識型人工知能)サービスを使ったり、あるいはアプリケーションサーバーは OpenStackVM で自由にミドルウェアや管理機能を導入してパブリッククラウドを構築した上で、IBM CastIron をベースとした統合サービスを使って社内データに安全にアクセスする機能と統合したり、といったエンタープライズクラウド環境を IBM Bluemix だけで実現することができるようにもなったことを意味しています。


前置きが長くなりましたが、今回はこの中の OpenStack VM インスタンスを生成して利用する手順を紹介します。この IaaS 的なインスタンスが Bluemix にどのように統合されているのか、といった点で、今後この機能を利用できるユーザーが増えた時の手助けになれば嬉しいです。


では改めて Bluemix 環境内に OpenStack の VM を作成する手順を紹介します。2015/05/06 現在、この機能を使うためには事前に申請を行う必要があります。そしてその申請が受け付けられた、というメールを受け取れば Bluemix 上に OpenStack VM を作成することができるようになります。この点を事前にクリアしている場合のみ以下の手順が使えるようになります:
2015050501


Bluemix にログイン後、ダッシュボードの「仮想マシン」を選択すると OpenStack の VM の状態が表示されます。この図では8つの vCPU、12GB のメモリ、11 個のパブリック IP が使える状態になっていることが分かり、この範囲内で VM を生成して利用することができます。またこの図ではまだ1つも VM が動いていませんが、生成済みの VM がある場合はこの画面から参照することもできます。ここで「仮想マシンの作成」をクリックして、今から作る VM の内容を指定します:
2015050502


VM の内容を指定する画面に切り替わります。この画面では作成する VM の OS、名前、スペック、そしてアクセス用の認証鍵を指定します。なお OS は手持ちのディスクイメージをアップロードすることも可能です。ここでは OS は CentOS 6.5、名前は dotnsf-vm1(任意)、スペックは m1.small(CPU * 1、メモリ 2GB、ディスク 10GB)を指定しました。最後に認証鍵を新規に追加します。Secret Key と書かれた箇所の下の "+Add Key" 部分をクリックします:
2015050503


ここで認証に使う鍵をインポートして追加します。こちらで紹介した方法などであらかじめ鍵ファイルのペア(秘密鍵と公開鍵)を用意しておきます。"Add Key" 画面で "IMPORT" を選び、Key Name に鍵の名前を入力します。そして公開鍵をテキストエディタで開き、その中身を Public Key to import 欄にコピー&ペーストして最後に "OK" をクリックします:
2015050504


ここまでの手順が成功すると公開鍵がインポートされ、一つ前の画面に戻った時の Secret Key として、追加した鍵が選択できるようになります。インポートした鍵を選択して最後に "CREATE" ボタンで VM を作成します:
2015050505


これで指定されたスペックの VM が作成され、起動が始まります。ダッシュボード画面で少し待つと起動も完了し、IP アドレスの割り振りも完了して VM インスタンスとして利用可能な状態になります。なお IP アドレスはパブリックアドレスとプライベートアドレスの2つが割り振られますが、最初に表示されているのがパブリックアドレスです。なおこの画面からインスタンスの数を変更することも可能です:
2015050506


また左ペインの "Auto-scale" を選択するとオートスケールの設定を行うことも可能です:
2015050511


最後に作成した VM に SSH からログインしてみます。用意した秘密鍵が使えるツール(Windows であれば TeraTerm など)で VM のパブリック IP アドレスに SSH2 でログインします:
2015050507


認証ではユーザー名は ibmcloud 、パスフレーズは秘密鍵を作成した時に指定したパスフレーズ、そして秘密鍵として用意した秘密鍵のファイルを指定します。最後に OK ボタン:
2015050508


全て正しい情報が指定されていれば作成した VM に ibmcloud ユーザーで SSH ログインできます:
2015050509


この ibmcloud ユーザーは sudo 権限を持っているので "sudo /bin/sh" と実行すると root ユーザーでのシェルに切り替わります。こうなればツールのインストールも設定ファイルの書き換えも自由にできます:
2015050510


ここまでできればもう普通の CentOS インスタンスと同様です。アプリケーションサーバーをインストールするなり、データベースサーバーをインストールするなり、X Window と VNC サーバーを導入してリモートデスクトップ環境にしたり、自由な目的で使えるインスタンスが Bluemix 内に生成できました!


今回は Bluemix 上に仮想マシンを生成する手順を紹介しました。Bluemix はこれ以外にも Docker コンテナを扱うこともできます。PaaS としてのリリースから1年経ちますが、いつの間にか IaaS 環境まで取り込まれていました。この進化のスピードについていくのも大変ですが(苦笑)、ますます魅力的なプラットフォームになりました。







 

Amazon EC2IDCF のサーバーインスタンスを使っていますが、どうしても気になるのはデフォルト状態ではスワップ領域が確保されていないことです:
2015020601


↑メモリは1GBで残り65MBほど。
 もうすぐメモリが足りなくなりそう、でもスワップ領域はゼロ・・・


特に高速化のために memcached とかを使うアプリを動かそうとすると、どうしてもメモリが不足しがちになります。スワップ領域がない状態で、一瞬でもメモリが足りなくなってしまうとアウトです。回避するにはなんとかしてスワップ領域を確保する必要があります。


EC2 や IDCF クラウドでは静的にスワップ領域が確保されているわけではないため、EBS などの追加ディスクを使う方法もありますが、これだとスワップ領域のために料金がかかる上、EBS は I/O にも課金されるので、スワップファイルを作る先としてはコスト的に不利です。

というわけで、インスタンスの起動時にディスクの空き部分を使ってスワップファイルを作ってスワップ領域とする、という方法を紹介します。これなら(ディスクに空きがあれば、の前提が必要ですが)ディスクを追加せずにスワップ領域を確保することができます。

具体的には /etc/rc.local あたりに以下のような内容を追加します。この例ではスワップサイズをメモリ量から動的に変更するようにしていますが、あくまで一例です。固定値を書き込んでしまってもいいと思います(青字は僕のコメント):
  :
  :
SWAPFILENAME=/swap.img スワップファイル名
MEMSIZE=`cat /proc/meminfo | grep MemTotal | awk '{print $2}'` 現在のメモリ量(KB)を取得

メモリ量からスワップ領域のサイズを決定
if [ $MEMSIZE -lt 1012293 ]; then
  SIZE=${MEMSIZE}k メモリ 1GB 以下の場合、スワップ領域はメモリサイズと同じ
elif [ $MEMSIZE -lt 2097152 ]; then
  SIZE=${((MEMSIZE * 2))}k メモリ 2GB 以下の場合、スワップ領域はメモリサイズの倍
elif [ $MEMSIZE -lt 8388608 ]; then
  SIZE=${MEMSIZE}k メモリ 8GB 以下の場合、スワップ領域はメモリサイズと同じ
elif [ $MEMSIZE -lt 67108864 ]; then
  SIZE=${((MEMSIZE / 2))}k メモリ 64GB 以下の場合、スワップ領域はメモリサイズの半分
else
  SIZE=4194304k メモリ 64GB 以上の場合、スワップ領域は8GB
fi

スワップファイルを作成してスワップオン
fallocate -l $SIZE $SWAPFILENAME && mkswap $SWAPFILENAME && swapon $SWAPFILENAME
  :
  :

/etc/rc.local は他の初期化スクリプトが実行された最後に実行される設定コマンドファイルです。なのでサービスやらの自動実行が行われた最後にこのコマンドが実行され、/swap.img というスワップファイルが作成されて、スワップ領域として動き始めます。このスワップファイルのサイズは物理メモリサイズに応じて動的に切り替わるようにしています。


これでサーバーインスタンスを再起動すると、今度は起動時に上記のスクリプトが実行され、スワップ領域が動的に作成されます。これで少し安心:
2015020602



(参考)
http://dev.classmethod.jp/cloud/ec2linux-swap-bestpractice/

 

このページのトップヘ