Compose: Composeによって作成されたコンテナのデフォルトの命名スキーム

残念ながら、申し訳ありません。

ここでも同じです。 このスラッグ機能はオプションである必要があります。 upまたはbuildコマンドでフラグを渡してオフにするのはどれほど難しいですか？

同意します-これはオプションである必要があります。 Docker Composeを使用するいくつかのプログラムは、1.22にダウングレードした場合にのみ実行されるようになりました。

私は同意します、これはオプションであるべきです。 このスラッグ機能はまったく必要なく、多くのbashスクリプトが古い命名形式を使用しています。

私たちも同じですが、「ボリュームから」機能を使用し、古い命名スキームに依存しているため、1.22のままにする必要があります。 1.24ではオプション機能にしてください。

この機能により、コンテナがアップされた後、コンテナを参照することが困難になります。

この変更のポイントはわかりません。 現在、dockerもcomposeもサービスディスカバリを提供していません。 したがって、コンテナ内からホスト名を取得したい場合は、どうすればよいですか？ 私自身のサービスディスカバリーをロールバックしますか？

ところで、この変更の利点は何ですか？ 下位互換性を壊すことは本当に価値がありますか？

デフォルトの_slug名の変更は正しいアプローチですが、環境変数またはコマンドラインオプションを使用して無効にする方法がないため、既存のワークフローの多くが破損します。 これを、<= 1.22.0 docker-composeの命名動作を取り戻すために、ある種のフラグを追加する機能要求と見なしてください。

申し訳ありませんが、「external_links」は現在使用できません。 リンクするには、コンテナの名前を知っている必要があります。
オプションにするための+1

@ shin-この新しい動作は完全に多くを台無しにします。 そのランダムなslug前は、あるdocker-composeファイルから起動されたコンテナを次のような別のファイル内でアドレス指定することができました。

services:
  app:
    image: app
    external_links:
      - "other-project_other-app_1:other-app"
networks:
  default:
    external:
      name: other-project_default

以上です。 さて、これはまったく機能しません。

少なくともこれはオプションではないのですか？

Dockerへのもう1つのステップ-死を構成すると私は信じています。

したがって、回避策があります。 container_nameパラメータはそのまま使用され、 slugは使用されません。 少なくとも、それは役に立ちます。

@ shin-これをslugがcontainer_nameで使用されていないというバグレポートとは見なさないでください。 そのままにしておきます。 私は文字通りここで袋詰めしています。

ああ少年！ https://github.com/ansible/ansible/issues/47978

変更の背後にあるインセンティブは理解していますが、特に開発者にスクリプトを調整する時間を与える猶予期間がないため、非常に混乱しています。 多くのスクリプトは、文字通り永遠に存在するこの命名規則を念頭に置いて作成されました。 基本的に、この変更により、docker-compose1.23は他のdocker-composeと下位互換性がなくなります。

@ shin-あなた自身とすべてのdocker-composeおよびdockerチームは、後方互換性のない変更とは何か、そして業界全体が依存している広く採用されているプロジェクトにそれをもたらす方法をすでに学ぶ必要があります。

まず、後方互換性のない変更は、以前に保証したことを破ることではありません。 これが誰にも使われていないかどうかは誰も気にしません。

後方互換性のない変更は、ユーザーベースが実際に依存しているものを壊したときです。 結局のところ、Apache 2.0であり、プロジェクト全体がprovided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KINDため、どのような保証があったかは問題ではありません。 ユーザーは、何に依存するかを決定します。 そして、あなた（チーム全体）は、誰があなたのプロジェクトを使用しているのか、その理由と方法を知る方法を学び始める必要があります。

次に、そのような変更をユーザーベースに導入する方法を学ぶ必要があります。 この「ランダムな接尾辞」は、ユーザーがexternal_linksとvolumes_from使用する方法を確実に破ります。 したがって、明示的なcontainer_name設定されていない場合、またはそのように見える場合の非推奨の警告をいただければ幸いです。 これらのドキュメントは、「他の人が行うこと」に精通していると考えてください。

• https://www.python.org/dev/peps/pep-0004/
• http://api.mongodb.com/python/current/compatibility-policy.html
• https://docs.openstack.org/python-novaclient/pike/reference/deprecation-policy.html
• https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation -policy

第三に、@ shin-、あなたは個人的にあなたのプロジェクトに直接貢献しておらず、あなたのユーザーであるが、同時にあなたのプロジェクトに忠実で貴重な投資をするのに十分忙しい人々と話す方法を学ぶべきですプロジェクトの将来の開発にある程度の意味をもたらし、別のソリューションへの移行に多くのリソースを投資しないようにすることを唯一の目的として、リクエストを提出し、ここでディスカッションに参加する時間を計ります。

第4に、DockerチームはDockerからお金を稼ごうとしていますが、Docker自体についてではありません。 Dockerがお金を払うのに良い方法は、Dockerインフラストラクチャ全体が支払う価値があることを証明するかどうかだけです。 開発チームがほとんどの場合コミュニティに背を向けた場合、それがユーザーの成功を目的とした製品であるかどうかはわかりません。

第五に、もう一度言いますが、私たち全員が敵ではなくあなたの大学や友人であり、私たちは本当にこれらすべてを手伝おうとしています。 そして、私たちはあなたの友達なので、Dockerスタックからの脱出は苦痛になりますが、途中で、別れはまったく非現実的に見えません。

これは、バージョンを壊すメジャーな変更のひどい実装であり、フレームワークをデプロイする機能を完全に壊します。また、事前の警告がまったくない状態で、同じ問題が発生する他のユーザーがどれだけいるか想像もできません。 誰かが手動でdockerの最新の変更ログを探しに行かない限り、彼らはこれについて何も知らないでしょう、そして私はほとんどの人がそれをしないだろうと想像します

@ shin-この変更は既存のワークフローに大きな影響を与えるため、スラッグを生成しないようにフラグを設定する必要があります。 何千時間もの開発時間が、docker-composeの予測可能性に依存するスクリプトの作成とサービスの自動化に費やされました。 適切なサービス検出がない場合、個々のコンテナの自動ターゲティングを許可するためのチームの計画は何ですか？

docker-compose container_nameディレクティブを使用しようとしましたが、GitLabでは有効になりませんでした。
しかし、Mac Os Mojaveの最新バージョンのdocker-composeでは機能しているようです。 何が起こっているのかわからない:)

私の.gitlabci.ymlファイルはtmaierから最後の画像をダウンロードしています（1.23.1である必要があります）。

みなさん、ここで表明された懸念のいくつかに対処したいと思ういくつかの一般的なコメント：

• これがいくつかのスクリプトを壊すことを私は間違いなく理解しています。 1.23.0-rc1以降のリリースノートでは、一番上にそう書かれています。 これは非常に「バンドエイドをはぎ取る」タイプの状況であり、瞬間的な痛みがより健康的な基盤で前進するのに役立ちます。
• 現在のソリューションの利点は数多くあり、この長年の問題で部分的に表現されています：＃1516-そしてdocker-compose runの問題は、特にここで数回報告されています：＃4688＃4549＃5240
• サービス検出は、関連するネットワーク上で静的なサービス名（コンテナ名ではなく）とネットワークエイリアスを使用して処理する必要があるため、問題にはなりません。 具体的には、ネットワークドキュメントを読んで詳細を確認してください。
• これにより、Composeプロジェクト全体でvolumes_fromとexternal_linksが使いにくくなると思います。 この変更の前でさえ、Composeが特定のコンテナー名の「予期される」形式を尊重するという保証はなく（たとえば、＃6155または＃3415に記載されているプレフィックスを参照）、実行されやすい欠陥のあるソリューションになることを考慮してください。長期的にはあいまいな問題に。
  
  
  
  • 異なるプロジェクトのコンテナが通信できるようにするための推奨される方法は、コンテナがexternalネットワークを共有し、他のサービスのエイリアスを使用することです。 同様に、プロジェクト全体のvolumes_fromは、代わりにexternalという名前のボリュームを活用する必要があります。
  
  
• この変更をより適切に伝達する方法についての提案に興味があります。 参考までに、この変更はリリースノートに記載されており、9月26日にリリースされた1.23.0-rc1以降、テストに利用できます。1.23.0GAは1か月以上後にリリースされましたが、変更については議論の余地があります。変更ログの先頭に大きな警告として配置しました。 この変更を可視化するために他にできることがあれば、次にこのような危険な変更を検討するときに、これらのことを聞いて実行できてうれしいです。
  
  
  
  • 逆に、ここでの一般的なポイントが「これまでに重大な変更を加えないでください。または、すべてを無期限にオプトアウトさせてください」である場合、ほとんどの人は、それが健全で合理的​​な方法ではないことを理解していると思います。さまざまなDockerEngineバージョン、Composeファイル形式、および非推奨のイディオムとの下位互換性を維持するために、すでに多くのフープを飛び越えているComposeのサイズのソフトウェアプロジェクトを維持することについて。
  
  

ここで取り上げられていないことがあれば教えてください。 これは多くの人にとって大きなスピードバンプであり、予期しない状況に対処しているときに気性がフレアする可能性があることを理解しています。 アップグレードを実行するために必要な時間を取って、当分の間、作成バージョンを固定してください。 「予測可能な名前なしでXYZを実行するにはどうすればよいですか？」などの質問に喜んでお手伝いします。 それまでは、このスレッドまたはSlackで。 そして、これらのフォーラムで他の人とやり取りする方法に配慮し、共有している情報が正しいことを再確認してください（この変更とは関係のないいくつかのスレッドが言及またはリダイレクトされているのをすでに見ました、これは不必要な警戒感を生み出し、ここで誤った方向に向けられている問題のある人々を助けません）、そして会話を狂わせません。 お手数をおかけしますが、何卒よろしくお願い申し上げます。

コミュニケーションの部分では、このような変更は、基本的にはこのスレッドでここで行った方法で、理由と今のところ何をすべきかを説明する方法で、事前にいくつかのコミュニケーションチャネルを介して伝達され、説明されることを期待しますが、以前にそれを行いますすべての余波。

@ shin-あなたは私が提供した私の最後のコメントとリンクを読んでいませんか？

あなたからの最後のものは親切に見えますが、同じように感じます。

この変更をより適切に伝達する方法についての提案に興味があります。

TL; DR

• docker-compose.ymlの新しいversionを紹介します
• external_linksにDeprecationWarningを追加し、更新について説明し、移行を希望するユーザー向けのサンプルソリューションを提供するドキュメントへのリンクを追加します。
• 新しいバージョンより前のすべての作成ファイル形式バージョンの古い動作をサポートします。

参考までに、変更はリリースノートで指摘されています

変更ログは寄稿者のためのものです。 ユーザーはそれを読みません。 ユーザーがdocker-composeをインストールし、昨日以降も機能することを祈っています。

逆に、ここでの一般的なポイントが「これまでに重大な変更を加えないでください。または、すべてを無期限にオプトアウトさせてください」である場合、ほとんどの人は、それが健全で合理的​​な方法ではないことを理解していると思います。さまざまなDockerEngineバージョン、Composeファイル形式、および非推奨のイディオムとの下位互換性を維持するために、すでに多くのフープを飛び越えているComposeのサイズのソフトウェアプロジェクトを維持することについて。

良い知らせがあります。 あなたはすでに「これまでに重大な変更を加えないでください。または、それらすべてを無期限にオプトアウトさせてください」と保証しています。 さらに、このための機能があります。 これversion 、 docker-compose.ymlファイルのversion番号に導入することを検討してください。

「予測可能な名前なしでXYZを実行するにはどうすればよいですか？」などの質問に喜んでお手伝いします。 それまでは、このスレッドまたはSlackで。

このスレッドの別のdocker-compose.ymlで、 container_name定義されていないexternal_linksおよび外部ボリュームのソリューションを提供してください（常に機能するとは限りません）。

これは、ユーザーがプロジェクトを使用する一般的な方法です。 ほとんどのユーザーは、ローカル開発にdocker-composeを使用しています。 多くの場合、開発中の相互接続されたプロジェクトがいくつかあります。 このような場合、複数のdocker-composeファイルを同じネットワークに転送し、異なるプロジェクトのサービスが開発者のマシンで相互に到達できるようにexternal_linksを定義するのが一般的な方法です。

会話を狂わせないでください

@ shin-私がこれまで読んだあなたに関するすべての会話は、人々が抱えている問題を解決するために何もしていないために狂ってしまいます。

真剣に、そのような態度で常にユーザーの要求を拒否し、あなたがこのプロジェクトを他の誰かに渡す方が良いことを避けることができるときにあなたのコミュニティを苦労させます。

PS：別の「オフトピック」コメントでごめんなさい。 あなたも慣れているので、この問題を自由にロックしてください。

このスレッドの別のdocker-compose.ymlで、container_nameが定義されていないexternal_linksと外部ボリュームのソリューションを提供してください（常に機能するとは限りません）。

すでにしました、私の以前のコメントを参照してください：

異なるプロジェクトのコンテナが通信できるようにするための推奨される方法は、コンテナがexternalネットワークを共有し、他のサービスのエイリアスを使用することです。 同様に、プロジェクト全体のvolumes_fromは、代わりにexternalという名前のボリュームを活用する必要があります。

あなたの投稿の残りの部分は不必要に敵対的であり、私はそれに応答しません。 私はここにいて、話し合いをしたいと思っていますが、あなたのいじめを受け入れる必要はありません。

正直なところ、@ shin-

この変更をより適切に伝達する方法についての提案に興味があります

あなたが「興味を持っている」とは思わない。 作成ファイルを作成する前に画像をプルして「スパム」としてマークすることについてのチケットを閉じると（笑）、コミュニティの提案にはまったく興味が

私はここにいて、話し合いをしたいと思っています

私たちが純粋な功績のある議論を提供したとしても、あなたはそれらを無視するだけです。 では、なぜわざわざ？

PS。 これをオフトピックとしてマークし、先に進んで、私たちの意見をどのように尊重するかを示してください。 さまざまな意見に対する非常に多くの賛成票を見るのは痛いですか？

すでにしました、私の以前のコメントを参照してください：

申し訳ありませんが、実用的なサンプルソリューションがありません。

あなたの投稿の残りの部分は不必要に敵対的であり、私はそれに応答しません。 私はここにいて、話し合いをしたいと思っていますが、あなたのいじめを受け入れる必要はありません。

申し訳ありませんが、そのように感じた場合。 現在のdockercomposeファイルバージョンの古い動作をサポートすることを検討し、新しい方法で動作する新しいフォーマットバージョンを導入してください。 これは、ユーザーベースに優れたソリューションを提供するために必要な唯一のオプションです。

お願いします。 私があなたの心の中でプロジェクトを助けたいと思っているという考えで、これらの2つの私のコメントをもう一度読むことを検討してください：

• https://github.com/docker/compose/issues/6316#issuecomment -438564025
• https://github.com/docker/compose/issues/6316#issuecomment -438934935

通信について：Docker for Macを介して更新を取得しましたが、この変更を示す変更ログは表示されなかったため、環境変数が変更された理由を理解するのに少し時間がかかりました。

これに気付いたときは、構成をv1からv3にアップグレードし、環境変数の代わりにサービス名を使用してリンクする機会として利用しましたが、実際には非常にクリーンになりました👍

FWIW、composeによって作成されたコンテナで実行するための下位互換性のあるハック：

docker container exec -it $(docker container ls -f name=expected -q) cmd

これに気付いたときは、構成をv1からv3にアップグレードし、環境変数の代わりにサービス名を使用してリンクする機会として利用しましたが、実際には非常にクリーンになりました。

さまざまなdocker-composeファイルアプローチ間でリンクするサービス名の簡単な例をここに提供していただけますか？

docker container exec -it $(docker container ls -f name=expected -q) cmd

ただし、これはdocker-composeとは関係ありません。

@ligこれは、 expected名への変更を回避します。 命名スキームの変更がなければ、この回避策は存在しませんでした。

@joebowbeerこの変更後の主な問題は、

@ shin-スウォームラインコンテナ名を生成するためにdockercomposerが必要な理由の説明をまだ待っていると思います。

私にとって、正気の状態にある人が制作目的で作曲家を使用する必要がないことはかなり明らかです。 Composeは、ローカルでテストするプロジェクトを立ち上げるための強力な機能です。 ローカルのみのテストに大量に使用されているツールに、Dockerの群れの特典/機能を追加する魅力はありません。 コンテナに群れのような名前が必要な場合は、群れを使用します。 正しい？

ここでの2番目の大きな質問は、なぜこれが引数を通じてオプション機能として含まれなかったのかということです。 私のフォーラムやコミュニティでは、この動作をデフォルトとして使用するように訴えている人は見当たりません。 したがって、おそらくそれを新しい引数として導入する必要があります： docker-compose up --slug 。 シンプルでエレガントで、誰のスクリプトも壊しません。

  * On the flipside, if the general takeaway here is "don't make any breaking change ever, or let me opt out of all of them indefinitely", I'm sure most of you realize that it's not a healthy, reasonable way to go about maintaining a software project the size of Compose, which already jumps through a lot of hoops to maintain backward-compatibility with a wide array of Docker Engine versions, Compose file formats, and deprecated idioms.

エンタープライズでの作業では、これまで、変更を破棄する際に「2つのメジャーバージョン」ルールを設定する傾向がありました。1つは非推奨、次は削除します。 これをどのようにオプトインできたのかはよくわかりませんが、_一時的な_オプトアウトをいただければ幸いです。

Docker-composeにはメジャーバージョンの概念がないようですが、一時的な「これを無効にする」オプション（コマンドラインからでもcomposeファイルからでも）が1つまたは2つのリリース（1.23およびおそらく1.24）は「無期限に」構成されます。

これはLinux以外のユーザーの自動更新に関連しているように思われるため、多くの人が驚いて、四半期の残りの部分を「スクリプトの更新中にこのコマンドラインフラグを使用して実行する」ことにしました。スクリプトを更新するために、手動でダウングレードしたり、実行していることを削除したりする必要のある開発者がたくさんいます。

この壊滅的な変化は惨事です。 多くの自動展開が突然壊れました。 二度としないでください。

* Introduce the new `version` of the `docker-compose.yml` 
* Add `DeprecationWarning` for `external_links` with a link to a document which describes the update and provides a sample solution for those willing to migrate.
* Support the old behavior for all compose file format versions prior the new one.

あまりにも理にかなっています...なぜそれがこのように行われないのか分かりません。

私はここにいて、話し合いをしたいと思っていますが、あなたのいじめを受け入れる必要はありません。

@ shin-提示された合理的な提案を考慮していないので、ここで議論がないことは非常に明白です。 さらに、誰かがいじめられている場合（あなたはそうです）、この画期的な変更により、世界中の多数の開発者を効果的にいじめています。

多くの人（私とおそらく他の人）は、群れモードに作曲を使用しません。 過去に発生した問題のために、作成ファイルに低いバージョンを指定します。これは、作成ファイルが群れのサービスを定義するために使用されることを前提としているためです。 指定したバージョンは、Dockerノードで生成された結果に関連付けられていると考えました。バージョンを低いものにロックすることで、一貫した結果を取得しながら、Dockerのバージョンとの互換性を維持するために作成するための更新を行うことができます。私は走っています。 どうやら私はここで適切なバージョン管理を期待することはできません。

docker-composeをドッキングして、突然壊れないようにすることはできますか？

最善の解決策は、docker-compose.ymlファイルに新しい構成オプションを導入することだと思います。このオプションでは、コンテナー名へのスラッグ部分の追加を無効にすることができます。

s /無効/有効/。 少なくとも既存の作成ファイルバージョンでは。

この動作は、作成ファイルのバージョン番号に関連付けるdocker-composeが実行されると警告が表示されます）、それを削除すると、間違いなく私のせいですべてが機能しなくなりますが、リリースを読み通すことを期待しています私の顔に警告メッセージを印刷する特権を持っているプログラムのメモ？

このような変更を加えることは、そのフォーマットに加えて、スペックの動作をバージョン管理するためのかなり良い動機のように思えます。警告を出して、他のコードの仮定を非推奨にすることができます。 この問題の名前を落とす外部の問題の量は、これが多くの人々にとってどれほど驚くべきことであったかを物語っていると思います。 コードが複雑にならないようにレガシー動作が破壊されているのを見るのは本当に素晴らしいことですが、そのような変更を一度に適用することはできません。 構成コンテナー名に関する他の仮定が破られることを期待できますか？ サービス名は常にコンテナー名に含まれますか、それとも予測可能な名前のように削除できますか？

これは、一貫性のあるネットワークデバイスの命名がLinuxで広く採用されたときを本当に思い出させます（ただし、これは命名とは逆です... idk）。 多くのコードがethN用にハードコーディングされており（まだいくつかの驚くべき場所にあります）、それは実際には変更されていません。 そこにsystemdシステム上の古い振る舞いを取り戻すための方法がある（と他のシステムでは、それは異なります）を追加することによって、 net.ifnames=0カーネル引数に。

（2回目の暴言は申し訳ありませんが、最初の暴言はあまり建設的ではなかったと思います。）

この変更により、 --scaleオプションが役に立たなくなったようです。 ランダムなpostfixは、サービスのスケーリングされたインスタンスに到達するために知られている必要があるためです。

たとえば、Nginxのアップストリームサーバーとしての複数のサービスインスタンス。

編集：詳細については、＃6365を参照してください

うわー、なんてひどい変化だ。 👎

スクリプトで使用するためにランダムに生成された文字列を取得するにはどうすればよいですか？

私もこの問題に遭遇しました。将来の後方互換性のない変更についての私の推奨事項を表明したいと思います。 私たちにもproject_service_index形式に依存するスクリプトがあり、多くの人がMacでそれらのスクリプトを使用しています。 理想的な世界では、人々が使用するDocker for Macのバージョンを制御できますが、今のところ、自動アップグレードダイアログが表示されたときにアップグレードします。

私の問題と推奨事項は次のとおりです。

1）アップグレードダイアログにはこの重要な変更の兆候がなかったため、この変更について明確な注意を払うことはできませんでした。 理想的な世界では、アップグレードごとにすべてのリリースノートを確認しますが、現時点では確認していません。 したがって、このような重要なものが更新ダイアログで明示的に呼び出された場合は、非常にありがたいです。

2）1）のため、明らかな警告はありませんでした。 前回のアップグレードでこのような変更が呼び出されたら素晴らしいと思います。 たとえば、最新の前のアップグレードでは、「コンテナの命名スキームは次のバージョンで変更されます。スクリプトをアップグレードしてください」のようになります。

3）このスレッドを読んだ後、使用している命名スキームが保証されていないことを理解し、コンテナーを参照するためのより良い方法があることに気付きました。 ただし、私たちは皆忙しい仕事をしており、タスクを計画する必要があるため、スクリプトのメンテナーとして、コンテナー名の使用をすぐに適切なものに変換することはできません。 推奨されるベストプラクティスを使用できてうれしいですが、コードを移行するには時間が必要です。 したがって、このような変更に対する非推奨戦略があると便利です。

ここでの重要なポイントは、ほとんどの場合、docker composeの使用の基本であるコンテナー命名スキームを想定しており、明らかな非推奨戦略なしでデフォルトの動作を変更すると、これらのワークフローに悪影響を与える可能性があります。

人々は常に意図したとおりにソフトウェアを使用するわけではなく、彼らの仮定が失敗したときに物事を修正する責任はそれらの人々にあります。 ただし、いくつかの簡単なコミュニケーションは、将来の変更に備えるのに役立ち、最新のベストプラクティスに移行する動機付けになります。

以前にdocker container exec -it project_php_1 bashに依存していた場合は、これを使用できなくなります。

サービスIDを見つけるには、 docker psを使用する必要があります。

ただし、 docker ps -q --filter=name=project_php 、 project_phpおよびproject_php_xdebugという名前のサービス、またはproject_php一致する他のサービスと一致するため、使用できません。

以前に読み取れたdocker container exec -it project_php_1 bashは、次のようになる必要があります。

docker container exec -it \
    $(docker ps -q \
        --filter label=com.docker.compose.project=project \
        --filter label=com.docker.compose.service=php) \
    bash

これはよく考えられていない変更でした。

@jtreminio FWIW、プロジェクトからはまだdocker-compose exec php実行できます

変更についての考えを共有するために時間を割いてくれたすべての人に感謝します。 これは適切に処理されておらず、私たちの側では少し熱心Compose 1.23.2で部分的に元に戻されdocker-compose runによって作成されたコンテナーのランダムなサフィックスを保持しているため、これらをより適切に処理できます。 ：＃4688＃4549＃5240、当初の意図どおり）。

対処する必要のある未解決の問題がある場合はお知らせください。

これをオフにするコマンドラインオプション--no-slugまたはより好ましくは--slugを追加して、デフォルトが以前と同じように機能するようにする計画はありますか。

1.23.2は以前の状態に戻ります。

docker-compose upのみ元に戻され、 docker-compose run

これを早く解決してくれてありがとう！

2018年11月28日には、20:09で、ジョフリーFの[email protected]は書きました：

変更についての考えを共有するために時間を割いてくれたすべての人に感謝します。 これは処理が不十分で、私たちの側では少し熱心すぎることに同意します。また、Compose 1.23.2で部分的に元に戻されました（docker-compose runによって作成されたコンテナーのランダムなサフィックスを保持しているため、これらをより適切に処理できます。＃ 4688＃4549＃5240、当初の意図どおり）。

対処する必要のある未解決の問題がある場合はお知らせください。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

@ shin-これはある時点で返されると思います-おそらく1.24で（それはそのような重大な変更なので？）。 もしそうなら、あなたはコミュニティと協力して、スラッグなしでこれらを使用していた人々のための代替の軽量メカニズムを理解し、推奨することができますか？ その会話をするのに最適な場所がわからない。

https://github.com/docker/compose/issues/6316#issuecomment -442666873

<project>_<service>_<index>から<project>_<service>_<index>_<slug>

これはバグであり、機能ではありません。
ありがとう！
ansible_connection=docker実行されているansibleプレイブックについて考えてみてください...😔!!
明示的なcontainer_nameを与える必要がありますか？ または、ランダムな<slug> !!で在庫を更新し続けます。
本当にとても悪いです！