The Doppler Quarterly (日本語) 春 2018 | Page 57

チームは、このアプリケーションに欠けていた以下の 3 つが問題であることを確認しました。
1. ビルドと展開を自動化するための標準化された CI/CD のパイプライン
3. より小規模かつ頻繁なリリース
2.
安定した繰り返し可能な展開
ベースイメージの作成
私たちはまず、コンテナー化を進める中でのコード変更の量を最小限に抑えたいと考えまし
た。そうすれば複雑性が低減されるうえ、 VM からコンテナーへのプラットフォーム変更の
前後に回帰テストを行うことが可能になります。そして本番環境のコンテナーでアプリケー
ションを実行した後、コンテナーのメリットを活かしてアプリケーションのリファクタリングと
再設計を行う計画を立てました。
これは「リフト & シフト」のシナリオだったため、オペレーティングシステムとライブラリの定
義は既存のアプリケーションで行い、こうした依存関係をコンテナーに組み込む最善のアプ
ローチを決定することを目標としました。アプリケーションには Linux と Java Development
Kit が必要だったため、 Alpine LinuxとOpenJDK をベースとする、 Docker Hub のオープン
ソースイメージを活用しましたが、状況に応じて、サポートが必要な場合は Docker Store の
認証済みのイメージをはじめとする別のオプションを使用したり、社内全体のポリシーとツー
ルを維持するためにゼロからカスタムイメージを作成したり することも可能です。後者は最も
柔軟性に優れていますが、サポートとメンテナンスのための作業が別途必要になります。
私たちは、オープンソースベースのイメージから継承した Dockerfile を作成し、アプリケー
ションの jar をコンテナーのファイルシステムにコピーした後、コマンドで jar を実行してアプ
リケーションを稼働させました。
2018 年春号 | THE DOPPLER | 55