Amazon Web Services ブログ

Category: Amazon EC2 Container Registry

モダンアプリケーション開発ホワイトペーパー(日本語改定版)が公開されました

皆さん、こんにちは! モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー(日本語版)がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS(英語版)の日本語版になります。   ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」(日本語版)というタイトルの51ページのドキュメントで、 はじめに モダンアプリケーション開発 モダンアプリケーションの設計パターン AWSでのCI/CD まとめ の各章から構成されています。各章の簡単なご紹介は下記の通りです。

Read More

Amazon ECRのネイティブなコンテナイメージスキャン機能について

本投稿は Richard Nguyen と Michael Hausenblas による寄稿を翻訳したものです。 コンテナセキュリティは、開発者、セキュリティ運用エンジニア、およびインフラ管理者を含む、さまざまなアクティビティとツールで構成されます。クラウドネイティブサプライチェーンの重要な要素の 1 つは、コンテナイメージをスキャンして脆弱性を検出し、そこから行動に移せる洞察を得ることです。 私たちはコンテナロードマップのIssue 17で、AWSネイティブソリューションを提供することがいかにお客様にとって重要であるかを学び、そして、ECRイメージスキャン機能を一般公開いたしました。この投稿では、ECR ネイティブのソリューションについて説明し、ユースケースの一つである「定期スキャン」の実装戦略を説明します。 Scanning 101 最初にコンテナスキャンに関する用語を解説し、前提知識を合わせましょう。 コンテナスキャンに精通している場合は、このセクションをスキップいただいても大丈夫です。 概念的には、コンテナセキュリティの一部としてのスキャンは次のようになります。 コンテナ化されたアプリケーションを見てみると、開発者(developer)がContinuous Integration(CI)パイプラインでコンテナイメージをbuildし、これらのアーティファクトをECRにプッシュしています。一方、セキュリティ運用エンジニア(secops)は、1つもしくは複数のECRリポジトリと、ECSやEKSなどのコンテナオーケストレーターを管理しています。この文脈でいうと、コンテナセキュリティは共同の責任であるということに着目することが重要で、developerと secops の役割は、クラウドネイティブのサプライチェーン全体のセキュリティに対処するために連携しています。たとえば、developerは、コンテナのUSER を定義し、イメージ内の不要なビルドツールを削除して攻撃対象領域を最小限に抑えるといった、セキュアなコンテナイメージをbuildするための推奨プラクティスに従います。同様に、secops も、runtimeポリシーを検証して適用するといったことを行ないます。 さらに、2種類のスキャンに分類することができます。 Static scanning (静的スキャン) :デプロイ前のフェーズで実行されるため、developers (もしくは secops) はコンテナが実行される前に脆弱性に気づくことができます。ECR イメージスキャン機能は、このカテゴリに分類され、コンテナイメージ内の OS パッケージをスキャンして、既知のセキュリティ上の脅威公開リストである共通脆弱性識別子 (CVE) を検出します。ECR イメージスキャン機能を利用すれば、独自のスキャンインフラを設定したり、サードパーティのスキャンライセンスを購入したりする必要はありません。 Dynamic scanning (動的スキャン):ランタイム環境で実行されるスキャンのことです。テスト環境、QA 環境、または本番環境で、すでに実行されているコンテナの脆弱性を特定することが可能であり、ビルド時点でインストール済みのソフトウェアに脆弱性が含まれていることが後日発覚した際や、ゼロデイの脆弱性なども検出可能です。動的(またはランタイム)コンテナセキュリティについては、CNCF Falcoなどのオープンソースソリューションから、Aqua Security、Trend Micro、Twistlock など、AWS コンテナコンピテンシーパートナーが提供するサービスまで、サードパーティ製のさまざまなオプションが利用可能です。 みなさまからお寄せいただいたフィードバックとさまざまな選択肢の評価結果に基づき、我々は人気のあるオープンソースプロジェクトであるCoreOS ClairをECRイメージスキャン機能で利用して脆弱性の静的解析を実行することに決定しました。イメージスキャン機能を備えるように ECR API、AWS CLI、SDK の拡張を行い、CI パイプラインやコマンドラインで使用しやすい形で、スケーラブルで信頼性の高いマネージドサービスを実装しました。 具体的な現実世界のユースケースから始めましょう。ECRでのコンテナイメージの定期スキャンです。 […]

Read More

Docker on AWS: AWSのコンテナ関連サービスの選定例の紹介

本記事ではこれからAWS上でDockerコンテナを活用される方向けに、AWSのコンテナ関連サービスのどれを選択すると良いかの一例を紹介します。前提としては、example.com社の技術者Aさんが、自社のWebサービスをAWS上で構築するにあたって構成を決めるために、AWSのソリューションアーキテクト(SA)に相談するという流れの記事になります。AWSのどのサービスを使うかのご参考に是非ご覧ください。※こちらの選定はあくまで一例です。要件によっては選択すべきAWSのサービスが異なる点、予めご了承ください。

Read More

Amazon ECR をソースとしてコンテナイメージの継続的デリバリパイプラインを構築する

2018 年 11 月 27 日(米国時間)、Amazon Elastic Container Registry (Amazon ECR) を AWS CodePipline のソースプロバイダとして利用可能になりました。これにより Amazon ECR に新しいイメージをアップロードすることにより、AWS CodePipelineを起動することができるようになります。AWS Developer Tools による CI/CD 実現が一段と容易になりました。 Amazon ECR をソースとして使うには、AWS CodePipline コンソールでAWS CodeDeploy による Blue/Green デプロイメントを実装している必要があります。CodePipelineを使わず、Amazon Elastic Container Service (Amazon ECS) コンソールを使って Blue/Green デプロイメントを実装するより詳しい情報については、AWS CodeDeploy による AWS Fargate と Amazon ECS でのBlue/Greenデプロイメントの実装を参照してください。 この投稿では Amazon ECR とAWS CodePipeline を使用してエンドツーエンドの継続的デリバリ […]

Read More

2018年2月のAWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの有岡です。2018年2月のAWS Black Belt オンラインセミナーの配信についてご案内をさせて頂きます。 re:invent 2017の振り返りを終え、2018年2月のBlackBeltセミナーでは、ソリューションカットとしてAWS上での位置情報と動画配信ソリューション、Amazonのコンテナサービスをご紹介します。 サービスカットでは、クラウド型仮想デスクトップサービスのAmazon Workspaces、同じくBIツールのAmazon QuickSight、AWS Lambdaをエッジロケーションで活用する方法、エンタープライズのお客様でお使いになるケースの多いAWS Organizationsなど、盛り沢山でお送りします。   2月の開催予定 ソリューションカット 2月6日(火) 12:00~13:00 AWS における位置情報 2月13日(火) 12:00~13:00 動画配信 on AWS 2月20日(火) 12:00~13:00 Amazon Container Services サービスカット 2月7日(水) 18:00~19:00 Amazon Workspaces 2月14日(水) 18:00~19:00 AWS Organizations 2月21日(水) 18:00~19:00 AWS Lambda @ Edge 2月28日(水) 18:00~19:00 Amazon QuickSight お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同、みなさまのご参加をお待ちしております。    

Read More

Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ

本日よりAmazon EC2 Container Registry (Amazon ECR)で利用可能になったライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。 Amazon ECRはフルマネージドのDockerコンテナレジストリで、同時に何百ものプルを捌くための典型的なスケールの問題を心配することなく、Dockerコンテナイメージを保存し管理しデプロイすることができます。スケールの意味する所として、Amazon ECRを活発に利用している開発チームはしばしばたくさんのコンテナイメージのバージョンによってレポジトリが埋め尽くされていることを発見することがあります。これは問題になっているコードの変更を探すことを困難にし、不必要なストレージ料金も引き起こします。以前は、レポジトリをクリーンアップするには、手動で古いイメージを削除するのに時間を費やしたり、スクリプトを書いて実行する必要がありました。 今日からライフサイクルポリシーを使うことで、古いコンテナイメージを自動的に削除するためのいくつかのルールを定義することが可能になりました。ルールが実行された時に影響を受けるコンテナイメージを実際にプレビューで確認することも可能です。これによって、レポジトリはより組織化され問題になっているコードのリビジョンを簡単に見つけられ、そしてストレージコストも抑えられます。 それでは、ライフサイクルポリシーがどのように動くかを見てみましょう。 基本的なルール コンテナを使ってコードをデプロイすることの最も大きい利点の1つは、素早く簡単に過去のバージョンにロールバックできるということです。これにより、リスクを抑えてデプロイすることが可能になります。なぜならば、もし何かおかしかったら、過去のコンテナのバージョンに戻して、失敗したデプロイ以前の状態でアプリケーションを動作させることが簡単にできるからです。多くの人は、数個前のバージョンにロールバックするということはおそらくしないでしょう。もしこういった状況であれば、1つのシンプルなライフサイクルルールとしては、最新の30イメージを保持するというものが考えられます。 最新の30イメージ ECRレジストリの中から、Dry-Run Lifecycle Rules, Addを選択します。 Image Statusには、Untaggedを選択します。 Match criteriaでは、Count TypeにImage Count More Thanを入力します。 Count Numberには30を入力します。 Rule actionにはexpireを選択します。 Saveを選択します。どのイメージがクリーンアップされるかを見るには、Save and dry-run rulesを選択します。 もちろん、数による保持ではなく、コンプライアンスの理由で期限によっていくつかのイメージを保持したいチームも存在します。そういった場合には、90日以前のイメージをクリーンアップするという選択もできます。 最新90日分 先程作成したルールを選択し、Editを選びます。パラメータを変更して、タグがついていないイメージを90日だけ保持する様に変更します: Match criteriaでは、Count TypeにSince Image Pushedを入力します。 Count Numberには90を入力します。 Count Unitにはdaysを選択します。 タグ もちろん90日というのは任意の時間に設定できますが、ある特定の種類のイメージだけもっと長い期間保持するようなポリシーが必要なこともあります。そういった場合で、でも大掃除は続けたいというときには、タグがつけられたイメージだけ削除するというのを検討することも可能です。 こちらのルールのリストは、タグが無いもの、development、staging、そしてproductionなイメージへのルールの例をまとめてみたものです: タグのないイメージは90日以前を削除 developmentタグのついたイメージは90日以前を削除 stagingタグのついたイメージは180日以前を削除 productionタグのついたイメージは1年以前を削除 ご覧頂いた通り、新しいAmazon ECRのライフサイクルポリシーは強力で、必要なイメージだけを保持するのが簡単になり、もう必要のないイメージをクリーンアップしてくれます。この機能は本日よりAmazon […]

Read More