Aws-cli: CI / CDシナリオで使用するためのAWSCLIを使用した公式のDockerイメージ

私もCI / CD環境で使用する公式のaws-clidockerイメージを探しているのでここにいます。 代わりに、別のパイプラインを作成して、元のパイプラインで公式のパイプラインを参照できるときにawscliを含むDockerイメージを作成します。

また...他の誰かもそれを取得しますhttps://hub.docker.com/r/google/cloud-sdk。

@mattiと@nscavell 、このトピックをフォローアップしていただきありがとうございます。 これを開いたままにするために、この機能リクエストに十分な関心があるようです。 この問題は、AWSCLIの公式Dockerイメージを追跡するために使用されます。 +1して興味を示し、優先順位を付けてください。

ありがとう。

+1は有害とは見なされません;）

とにかく、これはこれについて作成された3番目の（？）問題です...

👍私の+1を追加

CIにawsCLIのみを含めるには、独自のDockerイメージを作成する必要があります。 私は公式のものを好みます

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

これは、その間に最新バージョンを探している他の人のために、最新のCLIがインストールされた高山（修正後）の画像です。

@justnance十分ですか？

+1

+1

+1

+1

もう1つの理由は、パッケージ管理がないcoreOSのようなOSを使用する場合、物事を実行する慣用的な方法はコンテナーを介することです。 私はこれの必要性が疑問視されることさえあることに驚いています、それは明らかな省略です。 👍

+1

：+1：

+1

+1

+1

+1

+1

＃3291（引用された3つの問題の最初の問題）のオープナーとして、この問題がようやく勢いを増しているのを見てうれしいです。 将来のすべてのレスポンダーにとって、 いいねを追加することを意味します。これは、メンテナのメールボックスにスパムを送信しないように、GitHubで+1する適切な方法です。 。

+1してリポジトリの所有者に通知し続ける

+1

彼らが+1に問題を言うとき、彼らが意味するのは👍ボタンをクリック

@ davidham-明確にしてくれてありがとう。 同感です。 GitHubリアクションを使用して、👍ボタンをクリックしてください。

私は2日前に同じことを言いましたが、ねえ、私たちはすべて同じ側にいます🙃

+1

+1

+1

+1

+1

+1

+1

+1を止められますか？ +1したい場合は、一番上で行います。

あなたは貴重なエンジニアの時間を無駄にしています。 私たちはこの問題を購読しています...

私は2年以上aws-cliイメージを維持しています。 必要に応じてお気軽にご利用ください（1日に数回使用しています）。 新しいバージョンリリースのアップデートを（IFTT経由で）受け取り、アップデートをかなり迅速にプッシュします。 私自身のイメージを実行することの名声と栄光にもかかわらず（ha！）、私は公式のイメージを使用するように人々を_喜んで_延期し、プッシュします。

• GitHubリポジトリ
• DockerHub

私の画像を長い間使用した後、公式の画像にjq含まれていると_非常に役立つと思います（APIはJSONが多いため）。 「最新のECSタスク定義を取得し、変更を加え、それをプッシュバックする」などのすべてを単一のCI / CDパイプラインステージで実行することは非常に便利です。

この問題に対するさらに別の代替ソリューション： https ：

使用理由：

• シンプルに保ちます。
• 公式のpython3.7-stretchをベースイメージとして使用します。
• インストールにAWS推奨の戦略を使用します--python + pip。 ここを参照してください。
• サーバーレスオタク向けのaws-sam-cliが含まれています8-）。
• そのパブリックであり、ログインを必要としません。
• CI / CDパイプラインに最適-他の用途には使用していないため、長所と短所を比較検討していません。

まだ公式画像を期待しています。 今人々について考えなさい

https://hub.docker.com/r/google/cloud-sdk/ 。 すみません、みんな。 AWSのような巨人にとってそれはとても難しい仕事です。

+1

+1は有害とは見なされません;）

とにかく、これはこれについて作成された3番目の（？）問題です...

第4に、 https：//github.com/aws/amazon-linux-docker-images/issues/10を検討する場合

それをCircleCIに入れて、それで済ませることはできませんか？ Dockerfileまたはパイプラインを喜んでお手伝いします。

開発者がこの一見些細な作業を実行することを妨げる内部制限や事務処理がAmazon内にあるのではないかと思います...

k lol

「公式」画像に含めると便利なバリエーションがいくつかあります。 たとえば、現在、aws cliとcurlを使用してコンテナーを取得しようとしています（IAMメタデータエンドポイントを確認するため）。取得してk8sデプロイメントにプラグインできるコンテナーを見つけると非常に便利です。

公式画像を提供するためのセキュリティ上の理由もあります。

通常はシステムへのアクセスが多いCI / CDパイプラインなどの価値の高いターゲットで使用されるイメージを維持する「インターネット上のランダムな人物」への依存を排除​​することで、脅威モデルを簡素化します。

docker：18 （現在の安定版）イメージ（https://hub.docker.com/_/docker）に基づく公式のaws-clidockerイメージが欲しいです-例： aws-cli-docker-18これは、現在docker:18イメージを使用しているCI / CD環境でDockerイメージをビルドし、それをAWSECRに公開したいためです。

+1

+1

コメントが目前の問題に寄与しない場合、人々がコメントを控えることができれば素晴らしいと思います。 「+1」などのコメントは、サブスクライバーにスパムを紹介するだけで、問題を必要以上に長くします。 代わりに、問題の最初のコメントに賛成してください。

コメントが目前の問題に寄与しない場合、人々がコメントを控えることができれば素晴らしいと思います。 「+1」などのコメントは、サブスクライバーにスパムを紹介するだけで、問題を必要以上に長くします。 代わりに、問題の最初のコメントに賛成してください。

この号は昨年9月から発行されています。 明らかに関心があるので、AWSにこの問題をもう一度確認するように依頼する必要があると思います。 どれだけの関心が「十分」であるかを教えてもらう必要があります。

明らかにそれに興味があるので

興味だけでなく、より多くの：+ 1：反応：

https://github.com/aws/aws-cli/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

最も反応の多い2番目は2014年に、3番目は2015年に開かれましたが、この号は2018年9月に開かれました（ 1年未満前）。

+1000

aws-cliを機能させるための適切な依存関係の設定に関して、ローカルマシンで常に問題が発生しています。 そのため、docker内でaws-cliに切り替えることにしました。 docker-hubで公開されている画像をいくつか見つけましたが、公式ではないため、デフォルトでは信頼していません。更新されたバージョンが利用可能になるたびに、信頼できる画像を検索して再度見つける必要があります。 安全に使用できます。 AWSは、Dockerハブを介して安全なaws-cli dockerイメージを構築、維持、提供してください。 前もって感謝します

コミュニティが提供するaws-cli画像の巨大な断片化があります。 しかし、前述のように、人々は、Amazonによって公式に維持およびサポートされているものを好むでしょう。 いくつかの理由：

1）古くなることはありません-コミュニティの画像は、最終的に古くなることで有名です。
2）より安全-コミュニティメンバーがどれほど信頼されていても、信頼できるリソースからのものであり、正式にはAmazonを代表していないため、「すべての保証は無効」です。
3）公式サポートとは、バグ、バージョンの競合、下位互換性などが発生した場合の公式サポートを意味します。
4）AWSは、履歴タグを含め、 aws cliを更新するときに、イメージを更新できます。

+1

+ 1Amazonがこれを提供していないのは本当に残念です

それ以来、便利な別の画像を追加しました。 DockerのDockerをAWSおよびSAMCLIと組み合わせて、完全なECR統合を実現します。

dind-aws-cli

+1

手入れの行き届いた非公式の画像がたくさんありますが、ある日、「Pfft、これを更新するポイントは何ですか。これがAmazonの仕事です！」と言わないようにするにはどうすればよいでしょうか。

+1

+1

人々がAWSAmazonでの作業を自動化するのを支援することになると、大きな失敗に終わります。これが、私たちが彼らを離れることを考えている理由の1つです。

これがロードマップ上にあるかどうかについて、メンテナからの公式の回答はありますか？ 他の多くの人と同じように、私も公式の画像を使用したいと思います...

+1

AWS CLIの公式イメージがある場合、それはスクラッチコンテナ内にある実行可能ファイルになります。 それは個人にとって信じられないほど役に立たないので、最善の方法は次のとおりです。

• 公式のPythonコンテナを使用して、ソースからCLIをビルドします
• 結果のAWSCLIバイナリをbusyboxまたはスクラッチコンテナにコピーします

ここで議論が起こっているにもかかわらず、それ以上のものは過剰設計になります。

AWSは、すべてのECRおよびCodeDeployサービスのデモを行うのが大好きです。 なぜ彼らはそのすべての火力を彼ら自身のコンテナ化されたCLIに向けないのでしょうか？

テーブルの上の申し出は、コミュニティの誰かがそれを維持するためのもののようです。

@balibebasコミュニティの誰かがすでにそれをやっています。 そこにはたくさんの画像がありますが、ここでのポイントは、すべての秘密を公開した状態でCI環境でrandomguy/aws-cli:canbechangedanytimeを実行したくないため、AWSによる画像があるということです。

では、F-Droidについてどう思いますか？

それはこの猫と同じくらいこの問題に関連しています：

あなたは有料の顧客のように聞こえます。

たぶんそれは_I__am_

合唱団に説教します。 とにかく、Brewフォーミュラは、まだ動きがなく、より長くトローリングされているため、より良いチャンスがありました。 そのため、先に指摘したように、スクラッチコンテナやbusyboxコンテナの外に一般的なユースケースがない場合、猫の写真はすぐに逆効果になります。 あなたのデザイン提案は何ですか？

私と他の多くの人は現在、たとえばDockerで実行してECR認証資格を取得するために「busyboxコンテナー」を実行しています。 ドッカーの物がいくつあるかを考えると、公式のパッケージが存在しないことは意味がありません。

たぶん、彼らはただ何か他のものに取り組んでいます。 ;）

これが整理されてよかったです。 +1コメントに戻る：

Dockerlessの場合は+1

@matti @balibebas現在、この問題の会話だけで64人が参加しており、すべての応答が役に立たない電子メールと通知をトリガーし、購読している64人以上のすべての人に送信される可能性があることに

しかし、本当に、物事を専門的にしてください。 猫の写真は素晴らしいですが、このスレッドがレールから外れるほど、メンテナが真剣に受け止められる可能性は低くなります。 残念ながら、スパムはスパムです。

これが、クリックしたばかりの購読解除ボタンの機能です。

それは良いことだろう。 私は、何の行動も取られていないか、これが維持されていることに驚いています（NOと言われることを含む）。
とにかく、上記の人々は、公式のawscliイメージの重要性を正しく指摘しています。
人々はすでに自分自身を個人的に、または他の誰かが構築したイメージ/パッケージマネージャールートなどを介して使用していると思います。
同じためのさらに別のサンプルスクリプト

しかし、最も単純で避けられない問題は同じままです。

• 開発者が自分で物事を統合することに依存している場合に飛び込む依存関係と不確実性の終わりのないリスト。 人々が1つのものをインストールし、次に他のいくつかのものをインストールして、環境を汚染する作業を完了し、CI / CDまたは同様の分離された状態の作業の目的を損なうため、最終的にはリポジトリでより多くの問題が発生します。
• あなたの仕事のために他の誰かのDockerイメージを実装して追跡することを信頼するのは難しいです。 これにより、新しいawscliイメージ、つまり別のリポジトリ、つまり維持する別のもののために、Dockerレジストリに別のパイプラインとエントリが追加されます。
• CI / CDには、私の好みはちょうど（社内または正式な）イメージを
• 公式イメージはソースリリース自体からすぐにビルドでき、パッケージマネージャーなどとの動的な依存関係が少ないため、ビルドとライブラリの問題が発生します。

それ以外
=>誰もが自分で作ることになります。

ここでも同じですが、現在はセルフビルドイメージを使用していますが、

• https://hub.docker.com/_/awscli

名前空間。 これを使用して、他のDockerイメージを作成し、それらをECRにプッシュします。ここで、クレデンシャルを取得するためにawscliが必要です。

FROM docker:18.06

RUN apk update && \
apk -Uuv add python py-pip && \
pip install awscli && \
apk --purge -v del py-pip && \
rm /var/cache/apk/*

これをawscliビルドパイプラインに追加するのはそれほど大したことではないはずです... :)

-

@ mikesir87の提案に従ってDockerfileを更新しました、そのためのthx（最小の画像を取得するためにコミュニティの貢献を伴う標準画像を使用するもう1つの理由です）

全員にスパムを送信して申し訳ありませんが、（他の誰かが@ jens-meissのスニペットを使用したい場合に備えて）、3つのRUNステートメントを1つのステートメントにチェーンすることを_本当に_検討する必要があることを指摘したいと思います。 それ以外の場合は、最終的なコンテナがアクセスできない場合でも、 py-pipのコンテンツと中間レイヤーのapkキャッシュを出荷します。

別の注意点として、コメントは別の有効なユースケースを示しています... aws-cliを使用してECRが画像をプッシュするためのクレデンシャルを取得する場合のみ。 これは、 ECRクレデンシャルヘルパーを画像にパッケージ化する必要があるようにも

みなさん、こんにちは。メンテナです。 明確にしたかったのですが、これは起こっています、私たちはこれを行っています。

特にcliv2のリリースアーティファクトをさらに出荷するため、より多くのタイプのリリースアーティファクトをビルド/テスト/サポートできるように、より優れたリリースインフラストラクチャを社内で構築中です。

現時点では正確なタイムラインはありませんが、発生しています。

アマゾンの開発者や他の多くの人によると簡単なことですが、2年経ってもETAはありません😂

+1

内部リリースインフラストラクチャ（2019 Q4）
法務チームの評価（2020年第1四半期）
aws / cli-dev-testの下でのパブリックベータ（2020 Q2）
最終リリース（2020 Q3）

この楽観的なタイムラインでは、10か月以内に必要なものを入手できます。 🥇

jeffbarrsのブログ投稿を待っています

私はこれを待っているのが気になります。

少なくとも公式の発表やコミットメントを得ることができますか？ たぶんターゲットリリース？

@bhmckendrickは、このコメントがあなたのコメントをそれほど上回っていないというコミットメントではありませんか？

https://github.com/aws/aws-cli/issues/3553#issuecomment -519280276

1年以上経過していて、更新はありませんか？ 画像？

ねえ@jamesls 、共有するものができるまでこのスレッドをハードロックすることを検討しますか？

完全に読みたがらず（ヒントヒント）、代わりに70人以上のウォッチャーに、彼らがどのようにイライラしているかについてスパムを送信することを選択した人の数は、このスレッドをフォローすることへのすべての人の関心を大幅に低下させると確信しています。

また、これを実現するためのあなたの仕事に感謝します！

この号の原作者として（まあ、以前に閉じた「ウォントフィックス」のものをコピーして貼り付けるのに十分勇気がありました）、大規模な+1スパムと猫の写真との時折の戦いのために、私はすでにこの号の購読を解除しました（申し訳ありません） 。

この問題が解決された場合にのみ通知を受け取るように、通知設定を調整するだけです。

CI / CDを除いて、一部の開発者（@LongLiveCHIEFを参照）は、ドッキングされた開発環境を好み、ネイティブにインストールしたり、次のバージョンマネージャーに対処したりすることを好みません。それらのCLIツールが必然的に依存するネイティブ言語。

docker pull aws-cliは、既存のインストール手順よりも簡単です...言うまでもなく、Python開発者でない場合は、ユーザーに適したPythonバージョンと環境をセットアップするオーバーヘッドがあります。各プロジェクトですら。

開発者が使用する可能性のあるすべての異なるツール（RubyベースのCLI、ノードベースのCLI）に合わせてスケーリングし、コーディングしたことがない言語の環境設定を学習する必要があります。

ここで私が指摘しているのは、docker runはどこにでもあり、母国語のセットアップ/構成を取り除き、ユーザーにとって物事を簡単にするということです。

ユーザーが独自のDockerイメージを作成したとしても、それらのセットアップタスクに苦労する必要があります。

私はPythonでコーディングしていませんが、ツールプロバイダーがそれを「些細なこと」と見なしているという理由だけで、さまざまなバージョンのPythonから仮想環境の詳細とそのベストプラクティスを学ぶことを余儀なくされています。

すべての開発者がツールを作成した開発者と同じ経歴を持っているわけではなく、Dockerイメージを提供することは敬意の表れです。 ツールプロバイダーは、母国語固有の環境の癖のオーバーヘッドを非常に迅速かつ簡単に引き受けることができますが、採用者は、製品の開発のさまざまなライフサイクルステージを通じてこのオーバーヘッドを管理するためにはるかに多くの時間を費やす必要があります。

でも食べ物。

@jameslsここでコミュニティのフィードバックを聞いてくれてありがとう。 公式にホストされているDockerイメージを待っている間、役立つ中間ステップは、いくつかの人気のあるベースDockerイメージ（ノード、アルパイン、ubuntu、amazon2、pythonなど）のインストールに関する推奨事項をここに投稿することです。 これは私たちにとってすぐに価値があります。

私は大きなお尻の企業で働いているので、これであなたに仕えさせてください：
https://github.com/aws/aws-codebuild-docker-images
https://hub.docker.com/r/amazon/aws-codebuild-local

これはよく維持されているようには見えませんが、ここに別のものがあります

https://hub.docker.com/r/amazon/lambda-build-node10.x

私はこれを野生に見つけました： https ：

いよいよここにあるようです:)

@pablosjvこれは公式または認定された画像ではありません。 そのことに注意してください。

@anjakammer Dockerによって公開された公式のアマゾン画像のようです。

彼らはまだこの問題で何も言っていないので、それが生産準備が整っているかどうかはわかりません。

このAWSイメージが98.42MBであるのに対し、他のイメージ（ 興味があります。

https://aws.amazon.com/blogs/developer/aws-cli-v2-docker-image/

ここにCLIチームメンバー。 はい、AWS CLIv2用のDockerイメージを正式にリリースしたことを確認できます。 以下を読むことをお勧めします。

• それを紹介するブログ投稿： https ：
• ユーザーガイドエントリ： https ：
• DockerHubリポジトリ： https ：//hub.docker.com/r/amazon/aws-cli

この問題を解決します。 画像に関するフィードバックや質問がある場合は、このリポジトリで別のGitHubの問題を開いてください。

何年も前の元の問題＃3291のオープナーとして、私の痛む❤️は私の懸念が最終的に検証され、公式のDockerイメージが利用可能になるのを見るのにとても喜びに満ちています。 この画像を脇に置くのにどれくらいの時間がかかったかについてのポットショット、これは言うよりもはるかに簡単だったと確信しているので、これを実現させたアマゾンの開発者に大いに感謝します。 あなたは皆素晴らしい仕事をしています。 👏🎉👏

_オーケーアレクサ、私は彼らに感謝します、私の家族を今行かせてください。_

Dockerfileどこでも利用できますか？

@zerkmsああ、 v2ブランチで見つかりました：
https://github.com/aws/aws-cli/blob/v2/docker/Dockerfile

彼らはついにそれをやっていると思いますが、GitlabCIで実行することができませんでしたhttps://hub.docker.com/r/amazon/aws-cli

代わりに、GitlabのAWS CLI Dockerイメージを使用していますが、これは完全に機能します。 使用するだけ

image: registry.gitlab.com/gitlab-org/cloud-deploy:latest

アップデート：

上記の画像は廃止されました。代わりに新しい画像を使用してください。

image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest

amazon/aws-cliイメージはエントリポイントを/usr/local/bin/aws設定するため、GitLab CIでイメージを使用するには、空のエントリポイントを手動で設定する必要があることに注意してください。 例...

image:
    name: amazon/aws-cli
    entrypoint: [""]

@ mikesir87なんでそれ？

@pSnehanshuこれは、 docker run --rm amazon/aws-cli <<command>>ようにCLI自体であるかのようにイメージを実行するためだと思います。これは、 docker run --rm amazon/aws-cli aws <<command>>ではなくaws <<command>>でCLIを実行するのと似ています。 。 それぞれのアプローチには、好みやイメージの実行方法に応じて長所と短所がありますが、エントリポイントをオーバーライドすると、とにかくうまくいくはずです。

@lucasbasquerottoとにかくGitlabのイメージに落ち着きました。 とにかく、説明ありがとうございます。

AWS CLIv2をAlpineLinuxで動作させることにまだ興味がある人のために、Dockerfileの例を次に示します。

FROM alpine:3.11 AS builder

ENV GLIBC_VER=2.31-r0

# install glibc compatibility for alpine
RUN apk add --no-cache --virtual .build-deps \
        binutils \
        curl
RUN curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub
RUN curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk
RUN curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk
RUN apk add --no-cache \
        glibc-${GLIBC_VER}.apk \
        glibc-bin-${GLIBC_VER}.apk

# install AWS CLI
RUN curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip
RUN unzip awscliv2.zip
RUN aws/install

FROM alpine:3.11
MAINTAINER Barry Lagerweij
RUN apk --update --no-cache --virtual .build-deps add \
    groff \
    && rm -rf /var/cache/apk/*
COPY --from=builder /usr/local/aws-cli/ /usr/local/aws-cli/
COPY --from=builder /usr/local/bin/ /usr/local/bin/
COPY --from=builder /usr/lib/ /usr/lib/
COPY --from=builder /lib64 /lib64
COPY --from=builder /usr/glibc-compat/ /usr/glibc-compat/
COPY --from=builder /lib/ld-linux-x86-64.so.2 /lib/

問題は、AWS CLI v2がGLIBCを使用することでしたが、Alpine LinuxではGLIBCのサポートが制限されています（軽量の代替手段である「musl」を使用します）。 上記のDockerfileは、欠落しているglibcライブラリをインストールし、マルチステージDockerfileを使用して最終的なイメージを小さく保ちます。 少しの努力で、本当に必要な/ usr / libからのファイルだけを含めることで、おそらくイメージサイズをさらに小さくすることができます。

いくつかのリファクタリングの後、私は画像サイズをさらに小さくすることができました：

FROM alpine:3.11

ENV GLIBC_VER=2.31-r0

# install glibc compatibility for alpine
RUN apk --no-cache add \
        binutils \
        curl \
    && curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub \
    && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk \
    && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk \
    && apk add --no-cache \
        glibc-${GLIBC_VER}.apk \
        glibc-bin-${GLIBC_VER}.apk \
    && curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip \
    && unzip awscliv2.zip \
    && aws/install \
    && rm -rf \
        awscliv2.zip \
        aws \
        /usr/local/aws-cli/v2/*/dist/aws_completer \
        /usr/local/aws-cli/v2/*/dist/awscli/data/ac.index \
        /usr/local/aws-cli/v2/*/dist/awscli/examples \
    && apk --no-cache del \
        binutils \
        curl \
    && rm glibc-${GLIBC_VER}.apk \
    && rm glibc-bin-${GLIBC_VER}.apk \
    && rm -rf /var/cache/apk/*

オートコンプリートインデックスとサンプルファイルが削除され、「groff」も削除されます（Dockerイメージにヘルプページは必要ないと思います）

これは非常に単純で、 https：//github.com/flaccid/docker-awscli/blob/master/Dockerfileで機能しますが、画像に他に何か必要な場合はgithubの問題で知らせてください（有効なユースケース）。

これは非常に単純で、 https：//github.com/flaccid/docker-awscli/blob/master/Dockerfileで機能しますが、画像に他に何か必要な場合はgithubの問題で知らせてください（有効なユースケース）。

上記のAPKは、v2CLIではなくAWS-CLI1.18に基づいています。

Amazonがバージョン1のCLIでイメージを作成することを検討する可能性はありますか？

@keeganwittそのリクエストに対して新しいIssueを開く必要があります。 ：+1：