Amazon Web Services ブログ

Category: Containers

Amazon EFS CSI dynamic provisioningの御紹介

このブログはMike Stefaniak (Sr. Product Manager for Amazon EKS)、Marco Ballerini (DevOps Architect)によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。 企業がワークロードの多くをKubernetesに移行するにつれ、データをコンテナの外で共有したり持続させたりする方法を必要とするアプリケーションを導入するケースが増えています。Kubernetesは、Container Storage Interface(CSI)を介してブロックおよびファイルストレージシステムをコンテナ化されたワークロードに提供することで、このニーズに対応しています。Amazon Elastic Kubernetes Service (Amazon EKS) は現在、CSIを介して、Amazon Elastic File System (Amazon EFS)、Amazon Elastic Block Store (Amazon EBS)、およびAmazon FSx for Lustreの3つのストレージオプションをサポートしています。この記事では、お客様に人気のストレージオプションであるAmazon EFSに焦点を当てます。Amazon EFSは、同じAWSリージョン内の異なるアベイラビリティーゾーンからアクセス可能な共有ファイルシステムを提供し、高い耐久性を持つように設計されています。これは、Amazon EKSクラスタが複数のアベイラビリティーゾーンにまたがっている場合、またはコンテナ化されたアプリケーションが設定ファイル、静的資産、または複数のポッドで共有される何かを保持するために永続的なストレージを必要とする場合に特に役立ちます。 Kubernetesは、同じクラスタ内のストレージ関連の業務を論理的に分離します。PersistentVolumes (PV)は、管理者によってプロビジョニングされた、又はCSIドライバを使って動的にプロビジョニングされた、クラスタ内のストレージの単位です。PersistentVolumeClaim (PVC)は、通常、ユーザーまたはアプリケーションによって作成され、ストレージ領域を必要とする時にPVを要求します。これはポッドと似ており、一般的にはアプリケーションのライフサイクルに沿って行われます。 これまで、Amazon EFS CSIドライバを使用するKubernetes管理者は、ユーザーがPVCを作成する前に、PV(および必要なAmazon EFSリソース)を静的にプロビジョニングする必要がありました。今回、Amazon EFS CSIドライバーの最新バージョンにダイナミックプロビジョニングが搭載されたことをお知らせします。ダイナミック・プロビジョニングは、EFSアクセスポイント(EFSファイルシステムへのアプリケーション固有のエントリーポイント)を使用して、単一のファイルシステムで最大120のPVを自動的にプロビジョニングすることができます。 このブログの残りの部分では、新しくリリースされたAmazon EFS CSIドライバーのバージョン1.2を使用して、ダイナミック・プロビジョニングを開始する方法を紹介します。 セットアップ ドライバは、EFS アクセスポイントを作成および管理するために IAM 権限を必要とします。IAM roles for […]

Read More

Red Hat OpenShift Service on AWS の新機能

この記事は What’s new with Red Hat OpenShift Service on AWS を翻訳したものです。 お客様は、数年前から AWS 上の Red Hat OpenShift 内にアプリケーションワークロードをデプロイすることができました。AWS と Red Hat は、お客様からのフィードバックに対応し、労力を削減し、お客様が望むアジリティの要件を満たすための支援を続けてきました。 モダナイゼーションは、アプリケーションの進化に留まらず、インフラストラクチャ、プロセス、マインドセットの変化といったビジネスのあらゆる側面に関わってきます。しかし、AWS 上で OpenShift のような製品を扱う際に、アプリケーションプラットフォームやインフラストラクチャのチームはどのようにして敏捷性を高めればよいのでしょうか?推奨されるプラクティスに従って Red Hat OpenShift を調達し、AWS アカウントに最短時間でデプロイするにはするにはどうすればよいでしょうか? Red Hat OpenShift Service on AWS は、お客様のデプロイとクラウドへの移行をスピードアップするいくつかのメリットを提供します。まず、AWS 上の Red Hat OpenShift に必要なサブスクリプションをどのように購入すればよいのでしょうか?次に、Red Hat OpenShift Service を AWS アカウントにデプロイするにはどのくらいの労力と時間が必要でしょうか? 私はかつては、購買や調達のプロセスは重要な問題ではないと考えていました。しかし、お客様からのフィードバックや私自身の経験では、大規模な運用や移行を行う際には、これが課題となることがあります。過去に私は AWS のアカウントチームと Red Hat のアカウントチームの間を行ったり来たりしました。OpenShift […]

Read More
Multi-Account-App-Mesh-and-Amazon-EKS

マルチアカウント環境の Amazon EKS における App Mesh の活用

この記事は、Leveraging App Mesh with Amazon EKS in a Multi-Account environment を翻訳したものです。 今日、多くのお客様がマイクロサービスを採用してソフトウェア開発の高速化やイノベーションを実現し、新機能や製品の市場投入までの時間を短縮しています。マイクロサービスのアプローチは、特定のビジネスニーズに対応し、明確に定義された API を介して通信する小さな独立したソフトウェアの実装です。大きな組織ではこの開発モデルを実装するために、サービスのデプロイを変更し、複数の AWS アカウントを使用してワークロードを実行するという別の戦略を導入しています。このアプローチでは異なるチームやビジネスユニットのすべてのアプリケーションを単一の環境に持つことで発生する障害影響範囲を減らすことができますが、アカウントをまたいだマイクロサービスがお互いに会話ができるようにする必要があります。 重要なのは、マイクロサービスを実装する時に注意が必要なのものはネットワーク通信だけではないということです。大抵、時間を消費したりイノベーションのプロセス(主にクラウドのセットアップとガバナンス)をスローダウンさせる新しいタスクが発生します。AWS Organizations や AWS Control Tower などのサービスが AWS のマルチアカウント環境のガバナンスの整備を手助けします。 マイクロサービスを実装するときに重要になるのは通信を制御することです。マルチアカウントでの設定では、環境内で実行されているアプリケーション間の可視性をもたせ、ネットワークポリシーを強制する必要があります。ここで AWS App Mesh が重要になります。 AWS App Mesh は、アプリケーションレベルのネットワーキングを提供するサービスメッシュで、複数のタイプのコンピューティングインフラストラクチャだけでなく、さまざまな AWS アカウント間でサービスが相互に通信しやすくなります。App Mesh は、サービスの通信方法を標準化し、エンドツーエンドの可視性を実現し、アプリケーションの高可用性を確保します。クロスアカウントメッシュを使用すると、相互 TLS、接続のリトライ、タイムアウト処理などの機能を使用して、アプリケーションを変更することなく、相互通信サービスの信頼性とセキュリティが向上します。これは、コードの複雑さを軽減するのに役立ちます。

Read More

AWS で Red Hat OpenShift サービスの一般利用が可能に

AWS のお客様は、さまざまな経験とスキルセットをお持ちです。AWS では、そんなお客様方に快適にご使用いただく方法を常に検討しています。そのような中、当社は AWS での Red Hat OpenShift サービス(ROSA) を立ち上げることができ光栄に感じております。このサービスにより、Red Hat OpenShift ツールや API に精通したお客様は、データセンターを AWS に簡単に拡張できるようになります。 ROSA では、AWS と Red Hat の共同サポートにより、完全マネージド型の OpenShift サービスをご利用いただけます。このサービスでは、AWS に統合されたクラスター作成のエクスペリエンスや、利用量ベースの請求モデルが利用いただけ、デプロイの請求書も AWS に統一されます。 当社と Red Hat とのパートナーシップにより開発されたこのサービスでは、既存のデプロイの一部または全部を AWS に移行する、迅速かつ明快な方法が提供されます。また、お客様へのサポートも、Red Hat と AWS が共同でご提供してまいります。 既に Red Hat OpenShift に精通しているお客様は、標準 API と既存の Red Hat OpenShift ツールを AWS でのデプロイ用に活用することで、アプリケーション開発プロセスを迅速化していただけます。また、AWS が提供するコンピューティング、データベース、分析、機械学習、ネットワーキング、モバイル、その他のさまざまなサービスを活用して、ユーザーに対する俊敏性、イノベーションの速度、そしてスケーラビリティを向上させることも可能です。 ここでは、ROSA のしくみをご紹介するために、新しいクラスターの作成方法をお見せしていきます。 ROSA […]

Read More

Amazon EKS 上の AWS App Mesh での SPIFFE/SPIRE による mTLS の使用

本記事は、Efe Selcuk、Apurup Chevuru、Michael Hausenblas による Using mTLS with SPIFFE/SPIRE in AWS App Mesh on Amazon EKS を翻訳したものです。 AWS では、セキュリティを最優先事項と考え、責任共有モデルの観点から、お客様の責任部分をケアするためのコントロールを提供しています。サービスメッシュの一般的な使用例の 1 つは、通信経路のセキュリティ対策を強化することが挙げられますが、これは AWS App Mesh でも重点的に取り組んでいます。また、mTLS を安全かつ正しく利用するという課題は、実務者の間でも議論の対象となっています。AWS は App Mesh roadmap からの mTLS (mutual TLS、相互 TLS) の要望に応え、この機能のサポートを開始しました。このブログ記事では、mTLS の背景を説明し、Amazon Elastic Kubernetes Service (EKS) クラスターを使用したエンドツーエンドの例を紹介します。 背景 mTLS にあまり詳しくない場合は、このセクションをご覧ください。そうでない場合は、ウォークスルーに進んでください。 SPIFFE (Secure Production Identity Framework for Everyone) プロジェクトは、CNCF (Cloud Native […]

Read More

AWS Copilot を使用して、AWS Fargate で実行されるコンテナのインタラクティブシェルに接続する

この記事は、Connecting to an interactive shell on your containers running in AWS Fargate using AWS Copilot を翻訳したものです。 2017 年に AWS Fargate をローンチしてから、多くの開発者の方がコンテナにサーバーレスコンピューティングモデルを採用しています。これらの開発者は、コンテナを実行するための EC2 インスタンスを管理する代わりに、コンテナサイズとコンテナの数の観点からスケーリングについて考えることができます。EC2 で実行可能なワークロードと同じものを AWS Fargate で実行できるように、AWS Fargate はローンチ以降も多くの機能拡張を実施してきました。それらの新機能の一つが “ECS exec” です。ECS exec では、コンテナに対してインタラクティブシェルを開くことができます。ECS exec のさらなる詳細については、ローンチブログを参照してください。 ECS の主要なゴールの一つは、あらゆる規模でお客様のニーズに応えることができるような基盤となる機能を備えた、パワフルな API を提供することです。また、API が使いやすくなるように、基盤となる API の上にユーザーフレンドリーなツールを構築しています。AWS Copilot もその一つで、ECS on Fargate におけるデベロッパーフレンドリーなコマンドラインのエクスペリエンスを提供します。AWS Copilot は、コンテナアプリケーションの構築、リリース、運用までのすべてのプロセスを通じて開発者をガイドします。AWS Copilot は、上記で紹介した “ECS exec” をすでにサポートしています。Copilot […]

Read More

Amazon ECS 上の Linux コンテナでの Windows 認証の使用

この記事は、Using Windows Authentication with Linux Containers on Amazon ECS を翻訳したものです。 本投稿は、Sr Solutions Architect の Matt Cline により寄稿されました。 統合 Windows 認証 (または統合認証) は、クライアントおよびアプリケーションが SQL Server データベースに接続するための推奨メカニズムですが、コンテナ化されたワークロードを実行する場合、統合 Windows 認証の使用は複雑な場合があります。一般的に統合 Windows 認証クライアントは SQL Server データベースと同じドメインに参加しますが、個々のコンテナは恒久的な実行ではないためにドメインに参加することは適切ではありません。 この記事は、Amazon Elastic Container Service (Amazon ECS) で実行されている Linux コンテナを設定して、コンテナをドメインに参加させることなく、統合 Windows 認証を使用して SQL Server データベースに接続する方法を示します。この例では AWS Fargate を使用してコンテナを実行しますが、このソリューションを少し変更して別のコンテナランタイムまたはコントロールプレーンにデプロイすることもできます。 概要 この例は Microsoft Active Directory 用のAWS […]

Read More

New – Amazon ECS Exec による AWS Fargate, Amazon EC2 上のコンテナへのアクセス

この記事は、 NEW – Using Amazon ECS Exec to access your containers on AWS Fargate and Amazon EC2 を翻訳したものです。 本日、開発者、運用者を含むすべての Amazon ECS ユーザに向けて、 Amazon EC2 もしくは AWS Fargate にデプロイされたタスク内のコンテナに “Exec” する機能を発表しました。この新しい機能は、 ECS Exec と名付けられ、コンテナに対して対話型のシェル、あるいは一つのコマンドを実行できるようになります。これは AWS コンテナロードマップ上で最も要望の多かった機能の一つであり、一般公開できることを大変嬉しく思います。 ユーザが個々のコンテナに SSH 接続すべきでなく、監視やデバッグ、ログ分析のために適切な可観測性の仕組みを導入することは、コンテナ利用においてよく知られるセキュリティのベストプラクティスです。この発表は、ベストプラクティスを変更することなく、アプリケーションのセキュリティを改善するのに役立ちます。アプリケーション開発サイクルの初期段階においては、迅速なフィードバックループを回す必要がある場面がしばしばあります。例えば、あなたがローカル環境で開発とテストを行っていて、 docker exec を利用している場合、この新しい ECS の機能はきっと役に立つでしょう。またこの機能は、本番環境で重要度の高い問題をデバッグするために、コンテナへの “緊急用アクセス” が必要になる場合にも役立ちます。ここで、コンテナに対して “Exec” する時に利用できるツールと機能は、コンテナ内にインストールされているもののみであることに注意が必要です。つまり、例えば netstat や heapdump コマンドがコンテナのベースイメージにインストールされていない場合、それらを使用することはできません。 この機能をアナウンスするまでは、 ECS ユーザが EC2 […]

Read More

Docker Hub による AWS Container Services の認証

本投稿は Nathan Arnold による記事 Authenticating with Docker Hub for AWS Container Services を翻訳したものです。 Docker Hub は最近利用規約を更新し、コンテナイメージ Pull の rate limits を導入しました。これらの制限は Pro や Team プランのアカウントには適用されませんが、匿名ユーザーは IP アドレスごとに6時間あたり 100 Pull まで、認証済みの無料アカウントは6時間あたり200 Pull までと制限されています。この記事では、新たに設けられた制限による運用の混乱を回避し、プライベートコンテナイメージへのアクセスを制御するために、Amazon ECS と Amazon EKS の両方を使用してプライベートリポジトリからイメージを Pull するために Docker Hub で認証する方法を学びます。まだ Docker Hub を使用していない場合は、AWSクラウド環境とネイティブに統合されたフルマネージドの代替手段としてAmazon Elastic Container Registry (Amazon ECR) を検討してみてはいかがでしょうか。 Amazon ECS による Docker […]

Read More

EKS と Fargate、AWS Compute Savings Plans で Pod の料金を節約する

この記事は、Saving money a pod at a time with EKS, Fargate, and AWS Compute Savings Plans を翻訳したものです。 re:Invent 2019 では、Amazon Elastic Kubernetes Service (Amazon EKS) で、Kubernetes の Pod を AWS Fargate にデプロイできるようになったことが発表されました。その発表以降、多くのお客様が実際に Fargate 、つまりコンテナを実行するためのサーバーレスインフラストラクチャーに Kubernetes の Pod をデプロイしています。Fargate を利用することで、クラスターの管理やパッチの適用、セキュリティやアイソレーション、スケーリングといった様々な運用業務、「差別化にならない重労働( undifferentiated heavy lifting )」から解放されます。 Amazon EKS と Fargate の詳細については、re:Invent のブレイクアウトセッションでも掘り下げられています。 AWS Fargate は AWS Compute Savings Plans […]

Read More