【ITニュース解説】flisk up Treats Goose Like Every Other BYO App

Fliskは、ユーザーが作成したアプリケーション（BYOアプリ）を、使用言語に関わらず動かせるプラットフォームだ。この記事では、Go言語のGooseアプリケーションを例に、Flisk環境でBYOアプリを動作させる際に直面しがちな共通の問題とその解決策を解説する。これらはGoose特有の問題ではなく、Flisk上の多くのアプリケーションで起こりうるものだ。

Fliskでアプリケーションを動かすにはDockerコンテナ技術を利用する。通常のdocker runコマンドだけでは不十分な場合があり、Flisk独自のflisk upコマンドを使う。これはFliskがTraefikのようなルーティングコンポーネントと連携するためだ。 最初にflisk upを実行すると、Fliskの共通ベースイメージ構築やアプリケーションのコンパイルが行われ、完了まで時間がかかる場合がある。準備が整ったら、flisk up shop --dry-runで示されるURL（例: http://api.<project>.localhost/api/goose/health）にcurlコマンドでアクセスし、{"status":"ok"}という応答が得られるかを確認する。これがFlisk上でアプリケーションが正常に動作しているかの初期判断となる。

この初期確認に至るまでに、いくつかの一般的な問題が発生する可能性がある。

一つ目は、アプリケーションが127.0.0.1（ループバックアドレス）にのみバインドされている問題だ。アプリケーションはコンテナ内で起動しても、Traefikのような外部からのアクセスを受け付けないため、200 OKの応答が返ってこない。これはアプリケーションが自分自身からの接続しか許可しない設定になっているためだ。解決策として、アプリケーションを0.0.0.0にバインドさせる必要がある。0.0.0.0は、すべてのネットワークインターフェースからの接続を受け入れ、外部アクセスを可能にする。Railsなどのフレームワークでは、Dockerfile内でこの設定を明示的に変更することが求められる場合がある。

二つ目は、ホスト許可リスト（Host allowlist）に関する問題だ。一部のフレームワーク、例えばRailsなどは、セキュリティのため特定のホスト名からのアクセスしか許可しない設定を持つ。Flisk環境では、アプリケーションにはapi.<project>.localhostのようなホスト名でアクセスされる。このホスト名がアプリケーションの許可リストに含まれていないと、Blocked-host responseというエラーでアクセスが拒否される。この問題を解決するには、アプリケーションの設定ファイルにapi.<project>.localhost、またはワイルドカードを使って任意のホスト名からのアクセスを許可するように追加する必要がある。GinやFlaskのようなフレームワークでは、この設定変更が不要なことが多い。

三つ目は、DATABASE_URL環境変数に関する問題だ。FliskはBYOコンテナにDATABASE_URLという環境変数を自動で設定するが、Gooseサーバーの例のようにデータベースを必要としないアプリケーションもある。そのような場合でもこの変数が設定されるため、アプリケーションが不要なDATABASE_URLを読み込もうとして、クラッシュしたり、500 Internal Server Errorを返したりすることがある。この問題の解決には、アプリケーションがDATABASE_URLを読み込まないようにするか、データベースが不要な場合はその環境変数を適切に無視するようにコードを調整する必要がある。

四つ目は、404 Not Foundエラーの発生だ。このエラーには二つの原因が考えられる。一つは、アプリケーション内部で期待されるパス（例えば/health）が定義されていない場合だ。この場合、アプリケーション自身がパスを見つけられずに404を返す。もう一つは、Traefikが404を返す場合で、これはFliskがアプリケーションへの経路（ルート）を正しく登録できていないことを意味する。原因としては、ルーティング名の重複、--no-proxyオプションの使用、またはアプリケーションコンテナが起動し続けていないことが考えられる。

五つ目は、Dockerのネットワークアドレスプール枯渇による問題だ。all predefined address pools have been fully subnettedというエラーメッセージが表示され、サービスが起動しないことがある。これは、Dockerが使用できるネットワークアドレスのプールが、多くのプロジェクト作成によって使い果たされてしまった状況を示している。この問題を解決するには、flisk down --prune-networksコマンドを実行して、現在使用していないプロジェクトのネットワークを解放し、利用可能なアドレスプールを確保する必要がある。

これらの問題が解決され、curlコマンドで{"status":"ok"}という応答が得られれば、その言語のアプリケーションがFlisk上で基本的な動作をすることが確認できる。ただし、これは動作確認であり、プロダクション環境での負荷試験が行われたことを意味しない。Gooseの例は小規模なヘルスチェッカーであり、開発環境での動作確認用コンテナとして扱うのが適切である。

アプリケーションのコードを変更した場合、例えばserver.gooseファイルを編集した際には、Fliskが自動でコンテナに変更を同期するわけではない。そのため、変更を適用するにはDockerイメージの再ビルドが必要となる。しかし、Fliskが自動生成する.autogenerated/ディレクトリ内のファイルを直接編集しない限り、flisk config verifyコマンドは引き続き成功する。

FliskのBYO機能は、「任意の言語、一つのリソースタイプ、独自のDockerfile、そして四つのルール」という共通の原則に基づいている。Gooseのようなアプリケーションも、これらの原則と上記で解説した一般的なトラブルシューティングのポイントを理解し適用することで、Flisk上で円滑に動作させることができるだろう。