Amazon Web Services ブログ

Category: Amazon Elastic Kubernetes Service

【開催報告】「コンテナ × スポットインスタンス」 活用セミナー

スポットインスタンススペシャリスト ソリューションアーキテクトの滝口です。2020年6月10日にオンラインで開催された「コンテナ × スポットインスタンス」 活用セミナーでは、200名を超えるご参加人数という大盛況のもと、AWSのソリューションアーキテクトによる技術解説と、各種コンテナ技術を最大限に活用してスポットインスタンスをご利用いただいている3社のお客様から、実際の事例についてお話いただきました。 本記事では、お客様のご登壇資料を含む当日資料のご紹介、また参加者の皆様からいただいた当日のQ&Aの一部をご紹介します。 当日アジェンダと資料 12:00~13:00 Amazon EC2 Auto Scaling によるスポットインスタンス活用講座 講師:滝口 開資(アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト) 13:00~14:00 具体的実装に学ぶ、Amazon ECS × EC2 スポットインスタンス、Amazon EKS × EC2 スポットインスタンスによる低コスト & 高可用アーキテクチャ 講師:Hara Tori(アマゾン ウェブ サービス ジャパン株式会社 シニアデベロッパー アドボケイト) 14:00~14:30 AWS Batchによる大規模バッチ処理でのスポットインスタンス活用 講師:宮本 大輔(アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト) Containers + EC2 Spot: AWS Batch による大規模バッチ処理でのスポットインスタンス活用 from Daisuke Miyamoto   14:30~15:00 ECS×スポットインスタンス活用の秘訣 講師:田中 […]

Read More

Amazon CloudWatch での Prometheus メトリクスの使用

Imaya Kumar Jagannathan、Justin Gu、Marc Chéné、および Michael Hausenblas 今週の初めに、AWS は CloudWatch Container Insights での Prometheus メトリクスモニタリングの公開ベータ版サポートを発表しました。この記事では、ユーザーがプロビジョニングする AWS クラスター上の Amazon Elastic Kubernetes Service (EKS) および Kubernetes で、コンテナ化されたワークロードに新しい Amazon CloudWatch 機能を使用する方法をご紹介します。 Prometheus は Cloud Native Compute Foundation (CNCF) の卒業プロジェクトで、アクティブで大きなプラクティショナーコミュニティを持つ人気のオープンソースモニタリングツールです。Amazon CloudWatch Container Insights は、コンテナ化されたアプリケーションからの Prometheus メトリクスの検出と収集を自動化します。CloudWatch Container Insights は、カスタム CloudWatch メトリクスを自動的に収集し、フィルタリングして、AWS App Mesh、NGINX、Java/JMX、Memcached、および HAProxy などのワークロード用のダッシュボードで視覚化された集約メトリクスを作成します。デフォルトで、事前に選択されたサービスが 60 秒ごとにスクレイピングおよび事前集約され、クラスターおよびポッドの名前などのメタデータで自動的にリッチ化されます。 AWS では、OpenMetrics […]

Read More

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

皆さん、こんにちは! モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー(日本語版)が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

Amazon EKS Windows Container が一般利用可能になりました

今年 3 月に、当社は Amazon Elastic Kubernetes Service で Windows Container サポートのプレビューを発表し、カスタマーをベータテストにお招きし、フィードバックを提供していただきました。そのフィードバックに基づいて数か月間改修を重ね、Windows Container が一般利用可能になりました。 多くの開発チームは Windows Server で実行されるように設計されたアプリケーションを構築し、継続的にサポートしています。また、この発表により、 Linux アプリケーションと共に Kubernetes で展開が可能となりました。この機能は、システムロギング、パフォーマンス監視、コードデプロイパイプラインでより一貫性を実現します。 Amazon Elastic Kubernetes Service は、Kubernetes の構築、保護、運用、および維持のプロセスを簡素化し、組織が Kubernetes の代わりに、アプリケーションの構築に焦点をあてることができるようにします。AWS は、Kubernetes で Windows Container を一般的に利用可能にした最初のクラウド プロバイダーであることに誇りを思っています。そして、Windows と Linux ワークロードの両方で、Kubernetes のビジネス上の利点をお客様に解放していくことを楽しみにしています。 この機能の動作の方法を示すためには、Amazon Elastic Kubernetes サービスクラスタが必要になります。新しいものを作成しますが、これは Kubernetes バージョン 1.14 以上を使用するクラスタで機能します。クラスタが構成されたら、いくつかの新しい Windows ノードを追加し、Windows アプリケーションをデプロイします。最後に、アプリケーションが期待通りに動作することをテストします。 クラスタのセットアップを行う最も簡単な方法は、EKS の正式な CLI ツールである eksctl […]

Read More

Amazon EKS クラスターエンドポイントへのプライベート接続とワーカノードVPC外からのDNS解決方法

本投稿は AWS のシニアコンテナスペシャリストソリューションアーキテクトである Jeremy Cowan による寄稿です。 Amazon EKS クラスターを作成した時点では、標準ではKubernetes クラスターのエンドポイントはパブリックな設定になっています。エンドポイントにはインターネット経由でアクセスし、Identity and Access Management (IAM) とKubernetes role-based access control (RBCA) のポリシーによるアクセス制御を行います。 ゆくゆくはあなたも Kubernetes クラスターのプライベートエンドポイントを設定する必要が出てくるかもしれません。Kubernetes クラスターのエンドポイントをパブリックからプラベートに変更すると、インターネットをはじめとしたパブリックな経路からのアクセスは完全に無効になります。 実際に、プライベートなアクセスのみを許可するように設定されたクラスタは、以下のネットワークからのみアクセスできます。 ワーカーノードが存在する VPC その VPC とピアリングしているネットワーク AWS Direct Connect (DX) または Virtual Private Network (VPN) を介して AWS に接続されているネットワーク ただし、Kubernetes クラスターエンドポイントは、以下の理由からワーカーノードが存在する VPC からしか名前解決することができません。 エンドポイント用に作成された Amazon Route 53 プライベートホストゾーンは、ワーカーノード用 VPC にのみ関連付けられています。 プライベートホストゾーンは AWSが管理しているアカウントとは分けて作成されており、変更できません。 詳細については、プライベートホストゾーンの使用を参照してください。 […]

Read More

Kubernetes サービスアカウントに対するきめ細やかな IAM ロール割り当ての紹介

本投稿は Micah Hausler と Michael Hausenblas による記事を翻訳したものです AWS ではお客様のニーズに最優先にフォーカスしています。Amazon EKS におけるアクセス権制御に関して、みなさまは「パブリックコンテナロードマップ」の Issue #23 にて EKS でのきめ細かい IAM ロールの利用方法 を求められていました。このニーズに応えるため、コミュニティでは kube2iam、kiam や Zalando’s IAM controller といったいくつかのオープンソースソリューションが登場しました。これらのソリューションは素晴らしいプロダクトであるだけでなく、それぞれのアプローチの要件及び制約は何なのかについて多くの方の理解を促すことを可能にしました。 そして今、柔軟かつ簡単に利用可能なソリューションがやってきました。私たちの重要なゴールとして、粒度の高いロールを Node レベルではなくPod レベルでの提供がありました。私たちが今回考え出したソリューションもオープンソースとして公開されているため、eksctl での Amazon EKS クラスター作成時にも利用できますし、DIY アプローチでの Kubernetes クラスターとしてポピュラーな kops によって作成されたようなクラスタにおいてもご利用いただくことが可能です。 アクセスコントロール: IAM と RBAC Kubernetes on AWS では、補完しあう2つのアクセスコントロール手法が動作します。AWS Identity and Access Management (IAM) は AWS サービスへのアクセス許可、例えばあるアプリケーションが S3 […]

Read More

Fluent Bit による集中コンテナロギング

本投稿は Wesley Pettit と Michael Hausenblas による寄稿を翻訳したものです AWS はビルダーのために作られています。ビルダーは常に最適化の方法を模索し、それはアプリケーションのロギングにも当てはまります。全てのログの重要性が同等ということはありません。あるログはリアルタイムの分析を必要とし、他のログは必要となった時に分析が行えるよう単に長期間保管しておくことを必要としたります。それ故に AWS とパートナーが提供する様々なストレージや分析のツールに容易にログをルーティングできることが重要です。 そこで私たちは Fluent Bit をサポートし、コンテナ化されたアプリケーションから AWS やパートナーのログ保存ソリューション、ログ分析ソリューションへのログストリーム向けに、容易に利用可能な拡張ポイントを作成できるようにします。新しくリリースしたAWSコンテナイメージ向けの Fluent Bit プラグインを用いて、ログを Amazon CloudWatch と Amazon Kinesis Data Firehose の送信先 (Amazon S3、Amazon Elasticsearch Service、Amazon Redshift を含みます)へルーティングすることが可能です。 本投稿では、Fluent Bit プラグインのECS、EKS 両クラスタでの動作をご紹介いたします。ツール自体に慣れていない場合は、こちらの記事(basics of Fluentd and the Kinesis Firehose)にあるチュートリアルを確認いただくと参考になるかもしれません。よろしければ AWS containers roadmap の関連するイシュー #10 と #66 もご参照ください。

Read More

Amazon EKS バージョンライフライクルの更新

本投稿は Nathan Taber と Michael Hausenblas による寄稿を翻訳したものです re:Invent 2017で、私たちは Amazon Elastic Container Service for Kubernetes(Amazon EKS) を紹介しました。当時発表した次の tenets(信条) は、現在に至るまで引き続き確かなものであると考えています。

Read More

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

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

Read More