HN 日本語サマリー

← 一覧へ戻る
Web開発

flociを使用してクラウドプラットフォーム(GCP、AWS、Azure)をエミュレートする

Using floci to emulate Cloud platforms (GCP, AWS, Azure) (flowg.cloud)

12 pointsby linkdd2 コメント

要約

FlowGプロジェクトでは、クラウドプロバイダー(AWS、GCP、Azure)のログ収集・管理サービスとの統合テストを容易にするため、ローカルエミュレーターとしてflociを活用した。flociはDockerコンテナとして簡単にセットアップでき、AWS CloudWatchやGoogle Cloud Loggingのエミュレーションはスムーズに行えたが、Azure MonitorはHTTPS設定や認証トークンの扱いで追加の工夫が必要だった。flociはテスト用途に非常に有用だが、本番環境での認証との違いには注意が必要である。

全文翻訳

Amazon AWS、Google Cloud、Microsoft Azureにようこそ! FlowG 1.0の安定リリースが着実に近づくにつれて、私たちのチームは最初の安定リリースでユーザーが何を見逃している可能性があるかを見直しました。すでに8つの汎用フォワーダーがありますが、主要なクラウドプロバイダーとの直接統合が欠けていました。3つの最大のクラウドプロバイダーはすべて、独自のログ収集・管理ソリューション、プロプライエタリな実装、カスタムライブラリを持っています。ライブラリの使用は一般的に簡単ですが、それらをテストするのははるかに困難であることが証明されました。主要なクラウドプロバイダーとのソフトウェア統合のテストには、通常、各サービスのアカウントが必要であり、プロジェクトに破壊的な変更が導入されていないことを保証するために定期的に実行されるCI/CDパイプラインの一部である場合、かなりのコストがかかります。 AWS CloudWatchエミュレーションにflociを使用する 実装した最初の統合は、AWS CloudWatchサービス用でした。ローカルクラウドエミュレーターを探している中で、flociが最もプロフェッショナルに見えるソリューションとして際立っていました。flociの使用はこれ以上ないほど簡単でした。必要だったのは単一のDockerコマンドだけで、多くのAWSサービスのローカルバージョンを入手できます。 ``` docker run -p 4566:4566 floci/floci:latest ``` go aws-sdk-go-v2ライブラリをローカルエンドポイントを使用するように設定するのはさらに簡単です。設定構造体に単純なURL文字列を渡すだけで、ローカルのflociインスタンスを使用できます。公式のAWS CLIツールまたはPythonライブラリを使用してロググループとストリームを作成し、すぐに転送されたログが期待どおりに機能していることを確認できました。 ``` export AWS_ENDPOINT_URL=http://localhost:4566 export AWS_DEFAULT_REGION=us-east-1 export AWS_ACCESS_KEY_ID=test export AWS_SECRET_ACCESS_KEY=test aws logs create-log-group --log-group-name flowg aws logs create-log-stream --log-group-name flowg --log-stream-name logs ``` Google Cloud Loggingエミュレーターを探す AWSの成功物語に続いて希望に満ちて、Google Cloud Loggingを追加するのも同様に簡単だろうと期待していました。少し調査した結果、flociがAWSに提供したものと非常によく似たソリューションがいくつか見つかりましたが、それらをすべて試した後、どのソリューションも実際には機能しませんでした。いくつかは機能的なダウンロードリンクさえ持っていなかったり、提供された指示が完全に間違っていたりしました。他のソリューションを調査している間、flociチームは静かにfloci-gcpに取り組んでおり、以前に欠けていた機能を追加しました。再びflociを使用できることに気づき、そのシンプルさと使いやすさに再び迎えられました。Googleのライブラリは、安全でないローカル接続を許可するために少し設定が必要でしたが、ストリームやグループの作成は必要なく、AWSと同じくらい簡単に使用できました。 最終ボス:Microsoft Azure 他のクラウドプロバイダーがこれほど簡単だったので、floci-azがすでにAzure Monitorをサポートしていることを知っていたので、これはルーチンワークであり、すぐに完了するだろうと思いました。しかし、Microsoftは常に物事を複雑にする方法を見つけます。以前のすべてのローカルクラウドサーバーはHTTPを使用していました。認証がなく、実際のデプロイではなくCI/CD内でのみ使用されるためです。AWSは変更なしで動作し、GoogleはHTTPのために明示的な設定が必要で、Microsoftも同様ですが、実際に使用しようとするまでです。MicrosoftはInsecureAllowCredentialWithHTTPフラグを設定できるようにしますが、デバッグ後、そのフラグが読み取られていないことが明らかになりました。幸いなことに、floci-azもそこで役立ちました。FLOCI_AZ_TLS_ENABLED環境変数を使用してサーバーをHTTPSで実行するオプションがあります。Microsoftは、システム全体の構成を使用しない場合、カスタム認証トークン実装を作成する必要もありました。また、ワークスペース、ワークグループ、ログを送信するために必要なDCRを作成するために、2つの異なるクライアントライブラリを使用する必要がありました。あなたのインフラストラクチャがすでにMicrosoft Azureに大きく依存していない限り、私はあなたのプロジェクトのためにそれを使用することをお勧めしません。 認証 flociの最大の利点は、最大の弱点でもあります。flociは認証を必要とせず、安全なトークンの代わりに任意のランダムな文字列で動作します。これは、機能のテストやCI/CDパイプライン内での使用には最適ですが、統合が実際のプロバイダーのインフラストラクチャで機能するという自信を与えてはくれません。だからこそ、結局のところ、私たちはまだ少なくとも一度は各クラウドプロバイダーを手動で試して、私たちの認証が実際に現実世界で機能することを確認する必要があります。flociはこの旅で私たちを大いに助けてくれましたが、時には自分で物事をしなければならないこともあります。