継続的デリバリー効率化のヒント
「Docker」と「AWS」は“継続的デリバリー”のゴールデンコンビか
昨今のソフトウェアのリリース頻度の高さは著しい。リリース効率を上げて企業の対応力を高める鍵が継続的デリバリーの手法だ。このパイプラインを構築するのに役立つノウハウを紹介する。
昨今、ITチームがソフトウェアの更新をリリースする頻度は異常なほど高まっている。効率良くリリースするために、ITチームはアジャイルソフトウェア開発プラクティスに従い、DevOpsの考え方を採用している。ここまで効率を高める主な目的の1つは、新しい変更がアプリケーションに組み込まれたときに素早くフィードバックを入手することだ。このプロセスを加速するために、多くの組織がコンテナとクラウドプラットフォームを組み合わせて使用し、毎日のように複数のアプリケーションの更新を素早くリリースしている。このような組み合わせの1つが、「Docker」と「Amazon Web Services」(AWS)だ。
「Amazon Elastic Compute Cloud(Amazon EC2)」インスタンスはカスタムのアプリケーションコードを実行するのに適しているが、起動に時間がかかるため、開発者はOSが起動するのを待たなくてはならない。その一方コンテナは、移植可能かつ軽量で、典型的な仮想マシン(VM)につきものの障害が全くない。 CPU、メモリ、ストレージリソースの一部を取得するために既存のホストでプロセスの分離を使用するが、既存のクラスタ化されたホストをAmazon EC2で実行すれば、ITチームはコンテナを素早く稼働させることができる。
Dockerは事実上のコンテナ向けのオープンソーステクノロジーである。継続的デリバリーを構築するのに強力なタッグとなるのがDockerとAWSだ。「Amazon EC2 Container Service(ECS)」を使えば、EC2インスタンスのマネージドクラスタでDockerコンテナを実行可能になる。また、必要に応じて、単一のEC2インスタンスでDockerを実行することもできる。
DockerとAWSによる継続的デリバリー
AWSは、ITチームが継続的デリバリーのパイプラインをコンテナベースで構築できるようにする機能を、Amazon ECS以外にも幾つか提供している。そのようなパイプラインをAWSでセットアップする方法を以下で簡単に説明する。
ローカルでの開発
ローカルで作業する際、開発者はOS XまたはWindowsで「Docker Toolbox」を使用できる。このツールを使用すると、運用環境で実行するのと同じコンテナ環境でアプリケーションを素早くテストできる。まず、使用する基本イメージやインストールするソフトウェアパッケージなど、コンテナの設定を定義するDockerfileを作成する。docker runコマンドを使用して開発用コンピュータのローカルでコンテナを実行すれば、アプリケーションが期待通りに動作することを確認できる。複数のコンテナが必要なマルチティアアプリケーションの場合は、docker-composeコマンドを使用すれば、docker-compose.yml構成ファイルで定義されている複数のコンテナを稼働させることが可能だ。
ソース管理
アプリケーションに問題がないことを確認したら、コードをバージョン管理リポジトリにコミットできる。ここで、変更点についてソース管理リポジトリにクエリして残りのパイプラインを開始するために、オーケストレーションツールが必要になる。これは「AWS CodePipeline」を使えば簡単で、CodePipelineは「AWS CodeCommit」に変更をクエリするように構成することができる。また、GitHubでホストされているリポジトリも使用可能だ。このリポジトリには、アプリケーションコードに加え、Dockerfileとdocker-compose.ymlファイルを保存する。
ビルド
開発者がバージョン管理リポジトリにコードをコミットしたら、CodePipelineがビルド段階をトリガーする。 CodePipelineと互換性のあるビルドサーバは多数存在する。「Jenkins」が一般的だが、他にもサードパーティー製のツールを使える。 ビルド段階では、アプリケーションのソースコードをコンパイルできる。また、コンテナのイメージを作成するためにDockerビルドを実行することが可能だ。 コンテナのイメージは、パブリックまたはプライベートのコンテナレジストリからアクセスできなければならない。 なお、ビルド段階では、これらのDockerイメージを「Docker Hub」か「Amazon EC2 Container Registry」にプッシュできる。
テスト
AWSでコンテナを使用する一般的な方法として、CodePipelineで1つ以上のテスト段階を作成するというものもある。例えば、テスト段階ではコンテナを実行する前にアプリケーションコードに対して単体テストを実行できる。全てが稼働した後、もう1つの段階が必要になる。この段階では、アプリケーションが機能してアクセス可能で適切なコンテンツを提供していることを確認するための統合テストを実行する。
展開
コンテナのセットアップが全ての段階を通過したら、変更を運用環境にプッシュできる。変更をプッシュするとコンテナは、ビルド段階でコンテナレジストリにプッシュされたイメージから実行する。運用環境への展開は2通りある。自動的に行われる場合は継続的展開と見なされる。また、チームの準備ができたら最新バージョンのアプリケーションが運用環境に展開可能と見なされる方法もある。DockerとAWSがあればITチームは、継続的デリバリーのパイプラインを構築するための展開段階をさまざまな方法でセットアップできる。例えばECSと直接連係させることも、「AWS Elastic Beanstalk」を使用することも可能だ。AWS Elastic Beanstalkは、1つ以上のコンテナのDocker環境もサポートしている。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
5
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
6
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
7
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
10
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー