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

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

タグ:paas

このブログエントリは Oracle Cloud Infrastructure アドベントカレンダー 2023 に参加しています。シリーズ2の 12/03 ぶんの記事です(↓の記事内容は 2023 年 12 月 02 日時点の内容で記載しています):
2023120101


このブログで紹介するテーマは「プライベート heroku っぽい PaaS 環境を無料で作る」というものです。個人プログラマにとって無料で使える環境というのはありがたいもので、Oracle Cloud Infrastructure(OCI) の always free tier は本当に貴重な環境であります。この環境に加えて、
sslip.io
dokku
という2つの無料サービス+無料アプリを使って、自分専用の heroku っぽい PaaS 環境を構築する(ついでに GitHub Actions も併用して CI/CD 環境も用意する)、というものです。


【heroku っぽい環境】
そもそも「heroku っぽい PaaS 環境」の「heroku っぽい」 環境というのがどんな環境なのか、heroku をご存じな人であれば heroku そのものをイメージしていただくのがいいと思うのですが、ご存じない人向けに私の理解で簡単に紹介しておきます。

heroku は 2007 年に創業したクラウドサービス事業名であり、その運営会社名です。Java, JavaScript, Ruby, PHP といった各種プログラミング言語によって開発されたウェブアプリケーションを仮想コンテナ上で実行するプラットフォームを提供しています。ウェブアプリケーションに加えて各種データベースや管理・監視系サービスも併せて利用することができます。最大の特徴は PaaS(Platform as a Services) を体現するシンプルさで、手元にアプリケーションのソースコードがあれば(あるいは GitHub などのソースコードリポジトリがあれば)コマンド1つでクラウド上にアプリケーションをデプロイ/更新/スケールすることができます。"*.herokuapp.com" というアプリ公開用ドメインが提供されていて、早い者勝ちでこのドメインを使ったホスト名によるアプリケーション公開ができます(カスタムドメインを利用することも可能です)。2010 年には買収に伴う形でセールスフォース・ドットコム傘下となり、セールスフォース連携機能も強化されました。

heroku は 2022 年 8 月までは無料枠を提供していましたが、現在は無料で利用することはできません。この記事で紹介する内容は、この heroku 環境を模した(というか、ほぼそのものの)「heroku っぽい」環境を自分専用に構築する、という内容です。


【sslip.io】
自分専用の heroku っぽい環境を作る、実はこれ自体は後述の dokku を使うことでさほど難しくなく構築することができます。問題は「無料で」の部分です。肝心のサーバーは OCI の always free tier などを使うことでなんとかなりそうなものですが、選択肢が少ないのが「アプリ公開用のドメインをどうするか?」でした。

この PaaS 環境はアプリケーションを1つだけ公開するわけではなく、リソースの許す限り(今回の例だと OCI の always free tier 環境の限界まで)使うことができます。つまり "app1.domain.net" と "app2.domain.net" と "app3.domain.net" と・・・のように複数のアプリケーションをこの環境で公開することができるのです。そこでこの "domain.net" に相当するドメインが問題になります。無料のホスト名を入手する DNS サービスなどもありますが、このような heroku っぽいプラットフォームを作ろうとすると、単に1つや2つのホスト名が使える DNS サービスでは不十分で、ワイルドカード DNS("*.domain.net" というワイルドカード付きホスト名に対応した DNS サービス)を、それも無料のものを使う必要があります。

そこで今回使うのが sslip.io です。ここは無料のワイルドカード DNS に対応した無料サービスなのですが、特筆すべきはその便利さです。事前のユーザー登録や設定なども不要(!)で、例えば
 XX.XX.XX.XX
というパブリック IPv4 アドレスであれば、
 XX.XX.XX.XX.sslip.io
という名前でアクセスできます。しかもワイルドカード DNS に対応しているので、
 *.XX.XX.XX.XX.sslip.io
というワイルドカードホスト名を(無料で)使うことができます。まさに今回のテーマのための神サービス! この sslip.io を使って PaaS 上にデプロイした各アプリケーションにホスト名でアクセスすることができるようになります。


【dokku】
そして dokku です。オープンソースの PaaS 環境は数あれど、構築や運用がここまで簡単なものは他にないと思っています(その代わり1サーバーで全環境を構築することになります。複数サーバーを束ねて PaaS 環境を作るのではなく、1サーバーだけのシンプルな構成で構築します)。

dokku 自体が「プライベート版 heroku」という代名詞で呼ばれることもあり、heroku と非常に似たインターフェースを持っています。dokku 本体が docker を内蔵しており、デプロイした各アプリケーションやデータベースは全て docker コンテナとして稼働します(docker コマンドを使って構築・運用するわけではありませんが、docker コマンドでコンテナの様子を確認したりもできます)。

また多くのプラグインも公開されており、例えば今回も使う Let's Encrypt プラグインを使うことでウェブアプリケーションを SSL 証明書に対応させることも(https アクセスに対応させることも)可能です。


これらのサービスやソフトウェアを組み合わせることで heroku っぽい PaaS 環境を無料で構築していきます。


【前提準備】
以下の構築作業に入る上での事前準備として、以下の準備までは完了しているものとします:

・OCI アカウント取得
Ubuntu ベースの always free tier インスタンスの作成
・同インスタンスへの SSH ログイン
・同インスタンスへの TCP 80 番ポート、および TCP 443 番ポートの解放

重要な点として、always free tier インスタンスは CentOS ベースではなく Ubuntu ベースのもの(デフォルトユーザー名が opc ではなく ubuntu のほう)にする必要があります。CentOS の場合、dokku の標準インストーラーではインストールすることができません。なんか色々工夫することで dokku インストール自体はできるようになるかもしれませんが、インストール後の運用手順とかにも影響ありそうなので、今回の記事では対象外とします。

また今回の作業の最終結果として構築する PaaS 環境ではデプロイされたウェブアプリケーションに 80 番(http)および 443 番(https)ポートで接続することになります。したがって Ubuntu 側もこれらのポートにアクセスされる想定でファイアウォールを準備しておく必要があるのでした(デフォルトでは OCI のサブネットと Ubuntu の ufw の両方が閉じられています)。この辺りはこちらの記事が参考になると思います(私も参考にさせていただきました):
Oracle Cloud(OCI)でポートを開放する方法


前提準備がそろった所で dokku を使ったプライベート PaaS 環境の構築を行います。


【dokku 環境構築作業手順】
SSH で対象の Ubuntu サーバーにログインします。以下、しばらく CLI での作業になります。とりあえずお約束のリポジトリ更新コマンドを実行しておきます:
$ sudo apt update -y && sudo apt upgrade -y

dokku はインストール用のスクリプトが提供されているので最初にダウンロードします:
$ wget -NP . https://dokku.com/bootstrap.sh

sudo を付けてインストールスクリプトを実行します。その際にバージョン番号(2023/12/02 時点での最新バージョンは v0.32.3)を指定します:
$ sudo DOKKU_TAG=v0.32.3 bash bootstrap.sh

このインストール作業は結構時間がかかります(docker のインストールや初期状態で必要なイメージのダウンロードも含みます)。作業が完了してプロンプトが戻るまでしばらく待ちます(ネットワーク次第ですが 10 分前後?)。

インストールが完了したら dokku にドメインを設定します。今回使う always free tier の Ubuntu サーバーのパブリック IP アドレスが XX.XX.XX.XX であったとして、以下のコマンドを実行します(XX.XX.XX.XX 部分を実際の IP アドレスに替えて実行してください):
$ dokku domains:set-global XX.XX.XX.XX.sslip.io

次に秘密鍵と公開鍵を dokku に登録します。dokku は dokku 自体が git リポジトリを内包していて、この内包 git リポジトリを使ってアプリケーションをデプロイするのですが、その際に利用する鍵ペアを登録する必要があるのでした。お持ちの鍵ペア(秘密鍵ファイルと公開鍵ファイル)があればそれを使うこともできるのですが、後述する CI/CD 機能のため「パスフレーズのない鍵ファイル」を用意することをお勧めします。ここではパスフレーズのない鍵ファイルを作成する手順を紹介します。

以下のコマンドを実行します。実行直後に作成する鍵ファイル名が表示されるので(特に変更の必要がなければ)そのまま Enter キーを押してください。次にパスフレーズの入力を求められますが、今回は何も指定せずにそのまま Enter キーを押してください(再度同じパスフレーズの入力を求められた時もそのまま Enter):
$ ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): ←[Enter]キーを押す
Enter passphrase (empty for no passphrase): ←パスフレーズを入力せず [Enter] キーを押す
Enter same passphrase again: ←もう一度そのまま [Enter] キーを押す
Your identification has been saved in /home/ubuntu/.ssh/id_rsa.
Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub.

この操作が完了すると /home/ubuntu/.ssh/ フォルダ内に秘密鍵(id_rsa)と公開鍵(id_rsa.pub)の2つが作成されます。念のためパーミッションを 400 に変更しておきます(デフォルトでそうなっていると思いますが、念のため):
$ chmod 400 ~/.ssh/id_rsa*

これで dokku で使う秘密鍵ファイルと公開鍵ファイルが用意できました(既に所有していた鍵ファイルを使う場合はここから)。

まず以下のコマンドを実行して秘密鍵を登録します:
$ eval "$(ssh-agent)"

$ ssh-add -k ~/.ssh/id_rsa

続いて以下のコマンドを実行して公開鍵を dokku に登録します:
$ cat ~/.ssh/id_rsa.pub | sudo dokku ssh-keys:add admin

dokku 自体の環境構築はこれでほぼ完了していますが、ついでに前述の Let's Encrypt プラグインも導入しておきます。以下のコマンドを実行してください(2つ目のコマンドは Let's Encrypt で SSL 鍵を作る際に必要なメールアドレスの指定です):
$ sudo dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git

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

ここまでの作業で dokku のインストール/セットアップは完了しました。


【アプリケーションをデプロイ】
dokku の動作確認の意味も含めて、この状態で一度ウェブアプリケーションをデプロイしてみましょう。自分で使ってみたいアプリケーションがあればそれを使っていただいてもいい※のですが、特にない方は私のアプリを使ってみてください(一応 Node.js で作られていますが、単にメッセージを表示するだけの本当にシンプルなウェブアプリケーションです):
https://github.com/dotnsf/simpleweb


※自作のものなど、他のアプリケーションを使っても構いませんが、この段階ではデータベースなどを併用しないものを用意してください。


まずはアプリケーションのソースコードを入手します。改めて Ubuntu の CLI で以下を実行してソースコードを git clone してください(自分のソースコードを使う場合は自分のコードの URL を指定してください):
$ cd

$ git clone https://github.com/dotnsf/simpleweb

$ cd simpleweb

このローカルリポジトリに dokku 用のオリジンを追加します(localhost の git を使って dokku という名前で simpleweb のオリジンを作成しています):
$ git remote add dokku dokku@localhost:simpleweb

このオリジンからデプロイする先のアプリケーション(simpleweb)を dokku 環境にあらかじめ追加しておきます:
$ dokku apps:create simpleweb

では実際にアプリケーションをデプロイします。git コマンドで作成したオリジンに push することで dokku 内へのデプロイが実行される仕組みが提供されているので、デプロイ作業は単に目的のオリジン(dokku)へ main ブランチを git push するだけです(秘密鍵にパスフレーズが指定されている場合はここで入力を促されるので正しいパスフレーズを入力してください):
$ git push dokku main

git push 実行後にデプロイが開始されます。ここではソースコードの内容からプラットフォーム環境(この simpleweb アプリの場合は Node.js 環境)を特定し、このプラットフォーム向けに docker コンテナイメージが作成され、そのイメージが dokku 内の docker コンテナとしてデプロイされることで完了します(というわけで、他のコマンドと比較して長い時間(約1~2分)がかかります):
2023120102


無事にデプロイが完了したら、最後にポート番号のプロクシ設定をします。この simpleweb アプリケーションは 8080 番ポートで稼働するよう作られているので、80 番ポートから 8080 番ポートに転送してアクセスできるよう設定します:
$ dokku proxy:ports-add simpleweb http:80:8080

2023120103


これで simpleweb アプリケーションが 80 番ポートで公開されているはずです。ウェブブラウザを起動して、
  http://simpleweb.XX.XX.XX.XX.sslip.io/
にアクセス("XX.XX.XX.XX" は Ubuntu サーバーの IP アドレス)し、以下のような画面になることを確認してください。このような画面が表示されれば成功です。dokku が正しくインストールされ、アプリケーションもデプロイできて、sslip.io を使ったホスト名での(HTTP による)アプリケーションアクセスができることが確認できました:
2023120104


ついでに HTTPS アクセスを有効にしましょう。コマンドラインで以下のコマンドを実行します:
$ dokku letsencrypt:set simpleweb email (自分のメールアドレス)

$ dokku letsencrypt:enable simpleweb

2023120105


ここまで正しく実行した上でウェブブラウザをリロードすると(TSHS が有効になっているので)自動的に HTTP から HTTPS に切り替わり、https アクセスで同じ画面が表示できるはずです(もちろん直接 https://simpleweb.XX.XX.XX.XX.sslip.io/ にアクセスしても同じ結果になります):
2023120106


【CI/CD】
最後に Github Actions を使った CI/CD 環境の構築手順についても紹介しておきます。GitHub でバージョン管理しているソースコードが更新されたタイミングで自動的に dokku 上のアプリケーションを最新ソースコードのアプリケーションに更新する、というものです。

まずは GitHub 上に管理対象のソースコードリポジトリを用意します。プライベートリポジトリでもパブリックリポジトリでもどちらでも構いません。以下では https://github.com/dotnsf/web-app-test というリポジトリを使った例を紹介しますが、実際に試す場合は実際の(自分が開発者としてアクセスできる)リポジトリを使ってください:
https://github.com/dotnsf/web-app-test


そしてそのリポジトリを使って上述のアプリケーションデプロイ手順を実行しておきます。つまり一度手動でオリジンを追加(git add remote origin)して、アプリケーションを作成(dokku apps:create)して、デプロイ(git push dokku main)して、HTTPS アクセスを有効(dokku letsencrypt:enable)にしておき、アプリケーションに HTTPS アクセスができる状態を作っておきます:
2023120105


この状態から CI/CD 環境を構築していきます。まずは GitHub Actions を定義するのですが、手始めに秘密鍵を登録します。GitHub の該当リポジトリで "Settings" メニューを選択します:
2023120107


"Settings" 画面の左メニューから "Secrets and variables" - "Actions" を選択します:
2023120108


秘密鍵を登録したいので "Secrets and variables" 画面内の "New repository secret" ボタンをクリックします:
2023120101


秘密鍵を登録する画面が表示されます。NAME 欄には SSH_PRIVATE_KEY と入力します。また value 欄には上述の作業中に作成して使った秘密鍵ファイル(id_rsa)のテキスト内容を "-----BEGIN RSA PRIVATE KEY-----" から "-----END RSA PRIVATE KEY-----" まで)をそのままコピー&ペーストして入力し、最後に "Add secret" ボタンをクリックします:
2023120102


以下のように表示されれば、GitHub リポジトリへの秘密鍵の登録は完了です:
2023120103


次にリポジトリ内にプッシュ時に実行される GitHub Actions を定義します。そのためにソースコード内に .github/workflows/ というフォルダを作成し、その中に deploy.yml(つまり .github/workflows/deploy.yml ファイル)を以下の内容で作成します:
---
name: 'deploy'

# yamllint disable-line rule:truthy
on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Cloning repo
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Push to dokku
        uses: dokku/github-action@master
        with:
          # specify the `main` branch as the remote branch to push to
          branch: 'main'
          git_remote_url: 'ssh://dokku@XX.XX.XX.XX:22/web-app-test'
          ssh_private_key: ${{ secrets.SSH_PRIVATE_KEY }}

青字XX.XX.XX.XX は Ubuntu サーバーのパブリック IP アドレスで、赤字web-app-test 部分は(dokku apps:create した時に指定した)アプリケーション名で、それぞれ置き換えて作成してください。またソースコードの書き換えが視覚的にもわかるよう、アプリケーション側にも何らかの変更を加えておいてください。

これらのファイルをリポジトリに追加して更新します:
$ git add .

$ git commit -m 'dokku CI/CD with Github Actions'

$ git push

最後の "git push" が完了すると上記で作成した Github Actions が起動し、定義内容に従って自動的にビルド/デプロイが開始されます。デプロイの様子は Github リポジトリの "Actions" メニューから確認することが可能です:
2023120104


デプロイ完了後にアプリケーションにアクセスすると、最新のソースコードでデプロイされたアプリケーションが表示されるはずです(元のアプリで表示されていたメッセージの最後に "!" を追加する変更を加えていたのですが、正しく反映されていました):
2023120106


これで CI/CD も実現できたことになります。ソースコードの main ブランチが更新されてコミット/プッシュされるたびにアプリケーションも自動更新されてデプロイしなおされる、という便利な機能も使うことができそうでした。


【おまけ】
自分が dokku を使っていて気付いたことなのですが、どうもデプロイのたびに変なゴミというか、使われることのないファイルが残ってしまうらしく、特に CI/CD を使って何度もデプロイしていると、どんどんディスクの残り容量が減っていってしまうようでした。これを回避するには定期的に以下のコマンドを実行する必要があります:
$ docker system prune -f && docker system prune --all -f

面倒でなければ手入力でもいいと思いますし、面倒な場合は crontab にでも登録してアクセス数が比較的少なそうな時間帯に実行するのがいいと思っています。


【まとめ】
以上、無料のサービスだけを組み合わせる形で、CI/CD 含めたプライベート heroku (っぽい)環境を作ることができました。理論上はこの環境にいくつでも複数のアプリケーションを登録して、別々に運用することができる環境なのですが、さすがに always free tier の環境(メモリ 1GB ディスク 30GB)で運用することを考えると、5~6アプリが限界ではないかと思っています。もちろんこのリソーススペック上の制約は有償版を使うことで回避できます。また有償版の OCI なら DNS も使えるので(sslip.io を使う形ではなく)カスタムドメインを利用して環境構築することもできるようになります。 とはいえ、「無料で構築できる PaaS 環境」という素敵な響きにも替え難い魅力がありますよね。いずれはリッチなスペックの VM +カスタムドメインで運用するとしても、初めのうちはこの無料環境でプライベート PaaS を楽しむのも悪くないと思っています。なお(無料というわけにはいきませんが)カスタムドメインやその DNS のセットアップまで含める形で dokku 環境を作ったこともあります(OCI は全く使ってませんけど・・)。その時の内容に興味ある方は私の dokku 関連の過去の記事を参照ください。

dokku に関して、とりあえず環境構築と試験的な運用までが可能な一連の手続きについてはこのブログエントリ内で紹介していますが、実際にはこの中で紹介していない色々な機能があります(スケール対応とか、データベース系のプラグインを併用するとか、・・)。dokku はオンラインヘルプも充実しているので、詳しくはドキュメントを参照してください。

最後に注意点を。今回紹介した方法で dokku 環境を構築してアプリケーションを公開すると、事実上サーバーの IP アドレスを公開する形になります(sslip.io を使っているので、アプリケーションのホスト名の中に IP アドレスが含まれることになるからです)。サーバーの IP アドレスがバレても困らないように SSH などはしっかりセキュアに対策しておくといった対策はしっかりしておきましょう。

私自身は実際に dokku で(カスタムドメインを使って)自作サービスをいくつか運用しています。2年以上使っていますが、とても便利です。この記事が私と同じような技術クラスタの人のお役に立てれば何よりもうれしいです。


Stackato を使ってプライベート環境に構築した Cloud Foundry 環境に、App Store というアプリケーション一覧からアプリケーションをデプロイしてみます。Stackato 環境構築の手順はこちらを参照してください:
Stackato を導入してプライベートな Cloud Foundry 環境を(KVM に)構築する
 ↑これの続きです


Stackato 管理コンソールにログインして、最初のページを下にスクロールすると "Deploy from the App Store" と書かれたリンクがあります。ここをクリックします:
2014051501


"App Store" という、Stackato 対応アプリケーション(正確にはサーバー&アプリケーション)の一覧が表示されます。CMS の Joomla やアプリケーション開発フレームワークの cakePHP など、メジャーどころが結構対応しています。これらは全て以下に紹介する簡単な手順で Stackato にデプロイできるようになっています:
2014051502


試しに、ブログや CMS では定番の1つになっている WordPress をデプロイしてみます。一覧の最後の方までスクロールして、"WordPress" を見つけたら、"Deploy App" ボタンをクリックします:
2014051503


WordPress アプリケーションサーバーのデプロイ情報を入力します。といってもここで気をつけるべきは一番上の "App Name" 欄だけです。デフォルトで設定されている名称をそのまま使ってもいいし、変更してもいいのですが、これがアプリケーションサーバー名の一部(****.stackato-mm7d.local の **** 部)になります。とりあえずこの例では "wordpress-y7unx" という名称にしています。最後に "Deploy Application" ボタンをクリックすると Stackato 環境にデプロイが開始されます:
2014051504


デプロイ中の画面はこんな感じでログが表示されます。しばらく待ちます・・・:
2014051505


ログに "Created app 'wordpress-y7unx(App Nameの値)'" と表示されて、ログの動きが止まったらデプロイが完了しています:
2014051506


この状況で画面左の "Instance" をクリックすると、Stackato 環境内で動いているサーバーインスタンスの一覧が表示されます。先程作成した WordPress サーバーがちゃんと Stackato 内で動いていることが確認できます。またこの画面から再起動などの管理オペレーションが可能になっています:
2014051507
 ↑仮想環境の KVM の中で動いている Stackato の中で動いている WordPress サーバー、です


では実際のアプリケーションにアクセスしてみます。

・・・が、その前に、このアプリケーションは Stackato 内で動いていて、IP アドレス自体は Stackato と同じものです。(恐らく VirtualHost 設定などで)アクセスサーバー名で切り替えられるようなので、この WordPress にアクセスするには改めて /etc/hosts を編集するなどして、サーバー名(wordpress-y7unx.stackato-mm7d.local)でアクセスできるようにしておく必要があります。

前回も紹介したように、ブラウザを利用するマシンの hosts ファイルを更に変更して、サーバー名と IP アドレスの対応を追加しておきます:
192.168.0.101 stackato-mm7d.local api.stackato-mm7d.local wordpress-y7unx.stackato-mm7d.local
(↑内容は各自の環境に合わせるようにして赤字部分を追加します


そしてブラウザで http://wordpress-y7unx.stackato-mm7d.local/ を開くと、、、WordPress の初期設定画面が表示されています。あっけなく動いてますね:
2014051508


初期設定を済ませれば、そのまま WordPress を使いはじめることができます:
2014051509


この WordPress の例に限らず、Stackato の App Store には初めから使えるアプリケーションが数多く用意されているので、これらを使ってアプリケーションをすぐに構築したり、ミドルウェア環境を手早く用意する、といったことができそうです。この WordPress アプリケーションの場合は 128MB メモリ環境で動作するようなので、これ1つ作った時点であればまだまだ余裕があるので他のアプリケーションを同時に作って動かす、ということもできると思っています(他のリソースはともかくメモリ的には)。

今回使った Stackato の mini Cloud Foundry 環境の場合はメモリ上限が 4GB と比較的小規模運用が前提になっていますが、この範囲で収まる使い方であれば、社内やチーム内利用には充分すぎる環境だと思います。仮に収まりきらなくなった場合でも、(有料の)上位エディションに移行したり、各社から提供されている Cloud Foundry ベースの環境に移行ことで運用先に困ることはないと思っています。 

こういう移行選択肢がある、ということがオープン環境の素晴らしいところです。


Cloud Foundry をベースとした PaaS 環境は色々な会社から提供されていますが、その商用プライベート版の1つに Stackato (スタッカート)があります。

Stackato は(PaaS なので当たり前といえば当たり前ですが)ホスティングされた環境を利用することもできますし、Amazon EC2 や HP Cloud Services 上にデプロイして利用するためのパッケージも用意されています。また小規模向け限定だと思われますが、仮想環境用のイメージファイルをダウンロードすることで、自社のオンプレミスなどの全くのプライベートな環境内に構築して利用することも可能です。

この最後のケースですが、イメージファイルは VirtualBox / VMWare / vSphere / KVM 環境それぞれ用意されているので、これらのいずれかの環境があれば試してみることができます。

というわけで、自分の KVM 環境を使って Stackato を導入してみた時の様子を、最初のセットアップまで紹介します。仮想環境を今から用意するのであれば PC に VirtualBox をダウンロードしてインストールするのが手軽かな、と思っていますが、もし KVM 環境を整えるのであればこちらを参照ください:
CentOS に KVM 環境を構築する

まずは Stackato のイメージをダウンロードします。 ダウンロードサイトから目的の仮想環境にあったものを選んで "Direct" と書かれた箇所をクリックするとダウンロードが始まります(1ファイルが2GB近くあります):
2014051400


ダウンロードしたファイルを展開すると、選択した仮想環境用のマシンイメージファイルが現れます。Stackato V3.2.1 の KVM 用イメージであれば stackato-img-kvm-v3.2.1.img というファイル名でした(展開後のサイズは10GB近く)。


これを KVM 内で稼働させます。VirtualBox や VMWare など、他の環境を使う方はその環境なりの方法でイメージファイルを仮想マシンとして起動させてください。以下しばらくは KVM で仮想マシンマネージャーを使って起動させる場合の説明になります。

まずは KVM のホストマシン上で「仮想マシンマネージャー」を起動します:
2014051401


仮想マシンマネージャーが起動したら "localhost" と書かれた箇所を右クリックし、「新規」を選択します:
2014051402


作成する仮想マシンの名前を適当に(図では "stackato")入力します。また先程展開したイメージファイルから作成するので「既存のディスクイメージをインポート」を選択して「進む」をクリックします:
2014051403


「既存のストレージパス」には「参照」ボタンをクリックして、先程展開した Stackato のディスクイメージファイルを選択します。また「OS の種類」には "Linux" を、「バージョン」はこのイメージの元になっている "Ubuntu 10.04" を選択します:
2014051404


「メモリー」欄には Stackato に割り当てるメモリサイズを指定します。推奨値は 2GB 以上となっているので 2048(MB) と入力します。メモリに余裕がある環境であればもっと大きな数値でも構いません(但し、このダウンロードイメージを使う場合の上限は4GBらしいです)。なお1GB(1024) を指定した場合でも起動はしましたが、起動時に警告メッセージが表示されました。CPU は Stackato 環境に割り当てる仮想CPU数を指定してください:
2014051405


最後に内容を確認して「完了」をクリックします:
2014051406


Stackato 仮想マシンが起動している様子です:
2014051407



仮想イメージの起動が完了するとこんな感じの画面になります(IP Address はDHCPで割り振られた、この Stackato マシンのIPアドレスです)。また画面内に "https://stackato-mm7d.local" と書かれたURL(赤字部分は環境によって変わります)は管理コンソールへアクセスするための URL ですが、後で使うのでメモしておきます。
ここからは KVM に依存しない内容に戻ります:
2014051408


まずはこの Stackato 環境にログインしてみます。"l"(エル)キーを押して、ログイン画面に移ります。デフォルト状態ではユーザー名/パスワードともに "stackato" が設定されているので、この内容を入力してログインします:
2014051409


ログインできました。CPU やメモリの状態、内部アドレスなどが表示されてプロンプトになります。なお stackato ユーザーが sudo 権限を持っているので、sudo を使うことでシャットダウンやリブートを含めた管理者権限でのコマンド実行を行うことも可能です:
2014051410


管理コンソールへアクセスするには、自分の PC や仮想ホストマシンから先程のログイン画面に表示されていた URL にブラウザでアクセスします。が、このホスト名は Stackato が自動的に割り振ったものであって、当然ですがそのままでは(名前解決ができないため)アクセスできません。 これを解決するために DNS を設定してもいいのですが、手っ取り早い方法としてはブラウザを使うマシンの hosts ファイル(Unix/Linux 系であれば /etc/hosts、Windows 系であれば C:\Windows\System32\drivers\etc\hosts)を編集して以下の1行を追加します:
192.168.0.101 stackato-mm7d.local api.stackato-mm7d.local

この最初のアドレス部分は作成した Stackato 仮想マシンの IP アドレス(画面に表示されているもの)で、その右にホスト名、更にスペースを空けて api. を頭に付けたホスト名を記述します。

これでブラウザからホスト名指定でアクセスできるようになりました。改めてブラウザのアドレス欄に https://api.ホスト名/ (上記の一番右に追加した api. 付きの名前)と入力してアクセスします。すると以下の様な管理画面(の初期設定画面)が表示されます:
2014051411


それぞれ以下の内容を入力し、"Yes, I agree to the Stackato Terms of Services" にチェックを入れて、最後に右下の "Setup First Admin User" ボタンをクリックします:
- Username: 管理ユーザー名
- Email Address: メールアドレス
- User Password: 管理ユーザーのパスワード
- Confirm Password: (確認用)同じパスワード
- Organization Name: 組織名/社名
- Space Name: デプロイ空間名称(適当に "dev" とか)


するとログイン画面が表示されます。ここに先程入力した管理ユーザー名とパスワードを指定してログインします:
2014051412


正しくログインが完了するとこのような画面が表示され、各種管理機能にアクセスすることが可能になります:
2014051413


とりあえず導入から起動、そして一通りのセットアップをした上で、管理コンソールにアクセスするまでを紹介しました。

実際のアプリケーションのデプロイなどはもう少し調べた上で別途紹介したいと思っています。

(2014/May/17 追記)
続きはこちらです。


 

このページのトップヘ