継続的デリバリー効率化のヒント
「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
-
製品資料
[株式会社フィックスターズ] 組み込みデバイスへのAI実装で開発速度と品質を両立する方法 -
製品レビュー
[株式会社セールスフォース・ジャパン] 実画面を見れば納得 営業・設計・開発を「AI×CRM」でつなぐとこうなる -
比較資料
[アイティメディア広告企画] ERP導入ガイド:「OBIC7」「SMILE V 2nd Edition」「Oracle NetSuite」を比較 -
市場調査・トレンド
[アイティメディア株式会社] AI Overviews時代のB2Bマーケ! 成長企業が選ぶ戦略とは? -
市場調査・トレンド
[アイティメディア株式会社] なぜあの施策は失敗したのか? B2Bマーケ施策を成功させる3つの鉄則
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
2
NVIDIA「一強体制」の終わりか データセンターを襲う“電力の壁”
-
3
岐阜県庁が7000人規模でも重くならないテレワークを「Prisma Access」で実現
-
4
Microsoft 365侵害企業の9割はMFA導入済み 1002人調査で見えた盲点
-
5
「アップグレードできないJava」をどう守る IBMとRed HatがAIで400件超修正
-
6
OpenAIやAnthropicでさえ制御不能 2026年夏「3大サイバー攻撃」の衝撃
-
7
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
8
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
9
「セキュリティ運用と侵入後の初動防御」に関するアンケート
-
10
PHPはそもそも必要か? 脆弱性で問われる自社サイト安全性と保守負担のバランス
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
「IT史に名を残すシステム障害」8選
-
3
10G回線の真価をフルに享受するには? 導入前にチェックしたいポイント
-
4
SCS評価制度時代の「SASE選定」ガイド
-
5
顧客対応自動化の要点:RAGとデータ連携で“業務で使える生成AI”にする方法
-
6
マンガで解説:情シスの負担を減らす「MDRサービスのインシデント対応」の中身
-
7
「EDR」選定ガイド:比較・検討フェーズで整理すべきポイントを解説
-
8
なぜAIは組織で定着しないのか? 全社展開を阻む「3つの壁」と突破のヒント
-
9
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
10
ランサムウェア攻撃“究極の対策”はこれだ
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー