アプリケーションリファクタリング FOR コンテナ【Builders Online】
業務ではオンプレサーバでWebアプリケーションを管理しています。
そのWebアプリケーションをオンプレ形式とAWS形式の両方で提供できるようにするためにコンテナで管理していきたいと考えていました。
そのような要望にピッタリなセッションがあったので受講しました。
セッション内容
セッションはオンプレで開発しているサンプルアプリを基に、それをコンテナへ移行するという流れで説明がありました。
アプリケーションとステート(状態) とコンテナ
- 既存アプリ
- セッション情報:アプリサーバ内
- ログ:ローカルファイル出力、定期的バックアップ
- DB接続情報:アプリ内ハードコーディング
上記環境での課題は次の通り
- ステートを持っている
- サーバー中断でセッション情報を失う
- サーバ停止時に、ログのバックアップができない
- DBがセキュアでない、接続先変更でアプリ修正と再デプロイが必要
ステートを持っているのが大きな課題である。
一方で、ステートレスなアプリとはどのようなものか?
- ステートをアプリから切り離せている
- アプリレイヤーのみでスケールできる
コンテナとはどのようなものか?
- ステートレス
- イミュータブル(不変)
このような特性があるため、環境間の差異を吸収できる
アプリケーションのリファクタリング
変更前(ステートフル)
- アプリ:Java、Tomcat
- セッション情報:メモリ上
- ログ:Log4jでファイル出力
- DB接続情報:context.xml
変更後(ステートレス)
- アプリ:Java、Tomcat
- セッション情報:Amazon ElasitCache for Redis
- ログ:Amazon CloudWatch Logs
- DB接続情報:AWS Secrets Manager、環境変数から参照
上記の変更をするための、リファクタリング内容は次の通り。
- セッションの外だし
- ログの外だし
- DB接続情報の環境変数からの参照
コンテナ化とデプロイ
Dockerfile の基本はEC2 でのアプリケーションの作りと同じである。
コンテナオーケストレーションサービス(ECS)にデプロイする。
コンテナ向けのコマンドライン用のインタフェースとしてAWS Copilot CLIがある。
- AWS Copilot CLI
- AWSが開発したOSS CLIツール
- Manifestファイルを使う
ローカル環境でのコンテナ開発
ローカル環境では次のようなツールを使う
- Docker Desktop
- Rancher Desktop
- Finch(AWSのサービス)
- Dockerと同様に使うことができる
docker compose up -d finch compose up -d
ローカル環境とAWS 環境では次の点が異なる
- NW環境:
- localhost vs VPC内通信
- 環境変数:
- environment vs SSM Parameter Storeなど
- volumes:
- volumes vs Amazon RDSなど
まとめ
オンプレからAWSへ移行するのを目指して、まずは環境のDockerfile化にチャレンジしたいと感じました。docker以外にも使えるAWSサービスがあったので、そのあたりも使いながらDockerfileにしていきたいです。
ディスカッション
コメント一覧
まだ、コメントがありません