Compose: Compose에서 만든 컨테이너의 기본 이름 지정 체계

죄송합니다. 죄송합니다.

여기도 마찬가지입니다. 이 슬러그 기능은 선택 사항이어야합니다. up 또는 build 명령에 플래그를 전달하여 끄는 것이 얼마나 어렵습니까?

동의합니다. 이것은 선택 사항이어야합니다. Docker Compose를 사용하는 여러 프로그램은 이제 1.22로 다운 그레이드하는 경우에만 실행됩니다.

동의합니다. 이것은 선택 사항이어야합니다. 우리는이 슬러그 기능이 전혀 필요하지 않으며 많은 bash 스크립트가 이전 이름 ​​지정 형식을 사용하고 있습니다.

우리도 마찬가지입니다. "volumes from"기능을 사용하고 이전 이름 ​​지정 체계에 의존하므로 1.22를 유지해야합니다. 1.24에서 옵션 기능으로 만드십시오.

이 기능은 컨테이너가 업업 된 후 참조하기 어렵게 만듭니다.

나는이 변화의 요점을 이해하지 못한다. 현재 docker도 compose도 서비스 검색을 제공하지 않습니다. 따라서 컨테이너 내부에서 호스트 이름을 얻으려면 어떻게해야합니까? 나만의 서비스 검색을 롤링 하시겠습니까?

BTW,이 변경의 이점은 무엇입니까? 정말 이전 버전과의 호환성을 깨뜨릴 가치가 있습니까?

기본 _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

그리고 그게 다야. 이제 이것은 전혀 작동하지 않습니다.

이것이 적어도 선택 사항이 아닌 이유는 무엇입니까?

도커의 또 다른 단계는 죽음을 구성합니다.

따라서 해결 방법이 있습니다. container_name 매개 변수는있는 그대로 사용되고 slug 는 사용되지 않습니다. 적어도 도움이됩니다.

@ shin-, 이에 대한 버그 리포트를 고려하지 마십시오 slug 사용되지 않는 container_name . 그대로 두십시오. 나는 말 그대로 여기에 포장하고 있습니다.

오 소년! https://github.com/ansible/ansible/issues/47978

변경에 대한 인센티브는 이해하지만, 특히 개발자에게 스크립트를 조정할 시간을 줄 수있는 유예 기간이 없기 때문에 매우 혼란 스럽습니다. 문자 그대로 영원히 존재하는이 명명 규칙을 염두에두고 많은 스크립트가 작성되었습니다. 기본적으로이 변경으로 인해 docker-compose 1.23은 다른 docker-compose와 역 호환되지 않습니다.

@ shin- 개인적으로 그리고 모든 도커-작곡 및 도커 팀은 이전 버전과 호환되지 않는 변경이 무엇인지, 그리고 전체 산업이 의존하는 널리 채택 된 프로젝트에 적용하는 방법을 이미 배워야합니다.

첫째, 이전 버전과 호환되지 않는 변경은 이전에 보장하지 않았던 것을 깨뜨리는 것이 아닙니다. 이 물건을 아무도 사용하지 않아도 아무도 신경 쓰지 않습니다.

역 호환되지 않는 변경은 사용자 기반이 실제로 의존하는 것을 깨뜨릴 때입니다. 그리고 그것은 결국 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- 당신은 개인적으로 당신의 프로젝트에 직접 기여하지 않고 당신의 사용자 인 사람들과 대화하는 방법을 배워야합니다. 프로젝트의 향후 개발을 이해하고 다른 솔루션으로 마이그레이션하는 데 더 많은 자원을 투자하지 않으려는 유일한 희망으로 여기에서 요청을 제출하고 토론에 참여하는 데 시간을 투자하십시오.

넷째, 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.0 GA는 한 달 이상 뒤에 출시되었으며 변경 사항이 논란의 여지가 있음을 알고 있습니다. 변경 로그의 맨 위에 큰 경고로 표시했습니다. 이 변화를 가시화하기 위해 제가 할 수있는 일이 더 있다면, 다음 번에 이와 같은 위험한 변화를 고려할 때 경청하고이를 수행하게되어 기쁩니다.
  
  
  
  • 반대로, 여기서 일반적인 요점이 "절대 변경하지 마십시오. 아니면 모든 항목을 무기한 옵트 아웃하도록 놔두십시오"라면 대부분의 사람들은 이것이 건강하고 합리적인 방법이 아니라는 것을 알고 계실 것입니다. 다양한 Docker Engine 버전, Compose 파일 형식 및 더 이상 사용되지 않는 관용구와의 이전 버전과의 호환성을 유지하기 위해 이미 많은 문제를 겪고있는 Compose 크기로 소프트웨어 프로젝트를 유지하는 방법에 대해 설명합니다.
  
  

여기서 해결되지 않은 사항이 있으면 알려주세요. 저는 이것이 많은 분들에게 중대한 과속 충돌이며 예상치 못한 상황을 처리 할 때 화를 낼 수 있음을 이해합니다. 업그레이드를 진행하는 데 필요한 시간을 갖고 당분간 Compose 버전을 고정하십시오. "예측 가능한 이름없이 XYZ를 수행하려면 어떻게해야합니까?"와 같은 질문에 대해 기꺼이 도와 드리겠습니다. 그때까지는이 스레드 또는 Slack에서. 그리고 이러한 포럼에서 다른 사람들과 상호 작용하는 방식에 대해 배려하고 공유하는 정보가 올바른지 다시 확인하십시오 (이 변경 사항과 관련이없는 몇 개의 스레드가 언급되거나 리디렉션되는 것을 이미 보았습니다. , 불필요한 경각심을 불러 일으키고 여기로 오해되는 문제를 가진 사람들을 돕지 않습니다.) 대화를 방해하지 마십시오. 시간과 인내심에 감사드립니다.

커뮤니케이션 부분에서는 이와 같은 변경이 사전에 커뮤니케이션 채널을 통해 전달되고 설명되기를 기대합니다. 기본적으로이 스레드에서 방금 수행 한 방식으로 이유와 지금해야 할 일을 설명하지만 이전에 수행 한 방식으로 모든 여파.

@ shin- 내가 제공 한 마지막 댓글과 링크를 읽지 않았습니까?

마지막 사람은 친절 해 보이지만 똑같은 느낌입니다.

이 변경 사항이 어떻게 더 잘 전달 될 수 있었는지에 대한 제안에 관심이 있습니다.

TL; DR

• docker-compose.yml 의 새로운 version 소개
• 업데이트를 설명하고 마이그레이션하려는 사용자를위한 샘플 솔루션을 제공하는 문서 링크와 함께 external_links DeprecationWarning 를 추가합니다.
• 새 버전 이전의 모든 작성 파일 형식 버전에 대해 이전 동작을 지원합니다.

참고로, 변경 사항은 릴리스 노트에서 언급되었습니다.

변경 로그는 기여자에게 중요합니다. 사용자는 그것을 읽지 않습니다. 사용자가 docker-compose 하고 어제 이후에도 작동하기를기도합니다.

반대로, 여기서 일반적인 요점이 "절대 변경하지 마십시오. 아니면 모든 항목을 무기한 옵트 아웃하도록 놔두십시오"라면 대부분의 사람들은 이것이 건강하고 합리적인 방법이 아니라는 것을 알고 계실 것입니다. 다양한 Docker Engine 버전, Compose 파일 형식 및 더 이상 사용되지 않는 관용구와의 이전 버전과의 호환성을 유지하기 위해 이미 많은 문제를 겪고있는 Compose 크기로 소프트웨어 프로젝트를 유지하는 방법에 대해 설명합니다.

좋은 소식이 있습니다. 당신은 이미 "어떤 중요한 변경도하지 마십시오. 아니면 모든 것을 무기한 옵트 아웃하도록 놔두십시오"라고 이미 보장했습니다. 그리고 더 많은 기능이 있습니다. docker-compose.yml 파일의 version 입니다. 따라서이 변경 사항을 최대한 빨리 되돌리고 다음 version 번호에 도입하는 것을 고려하십시오.

"예측 가능한 이름없이 XYZ를 수행하려면 어떻게해야합니까?"와 같은 질문에 대해 기꺼이 도와 드리겠습니다. 그때까지는이 스레드 또는 Slack에서.

이 스레드의 다른 docker-compose.yml 에서 external_links 및 container_name 정의되지 않은 외부 볼륨에 대한 솔루션을 제공하십시오 (항상 작동하지는 않음).

이것은 사용자가 프로젝트를 사용하는 인기있는 방법입니다. 대부분의 사용자는 로컬 개발을 위해 docker-compose를 사용합니다. 종종 하나는 개발중인 여러 상호 연결된 프로젝트를 가지고 있습니다. 이러한 경우 여러 개의 도커 구성 파일을 동일한 네트워크로 지정하고 다른 프로젝트의 서비스가 개발자의 컴퓨터에서 서로 도달 할 수 있도록 external_links 를 정의하는 것이 일반적입니다.

대화를 방해하지 마십시오

@ shin- 지금까지 읽은 모든 대화는 사람들이 가진 문제를 해결하기 위해 아무것도하지 않기 때문에 탈선됩니다.

진지하게, 이러한 태도로 사용자의 요청을 끊임없이 거부하고이 프로젝트를 다른 사람에게 더 잘 전달하는 것을 피할 수있을 때 커뮤니티 투쟁을 강요합니다.

추신 : 다른 "주제에서 벗어난"코멘트에 대해 죄송합니다. 당신도 익숙하므로이 문제를 잠그십시오.

이 스레드의 다른 docker-compose.yml에서 container_name이 정의되지 않은 외부 링크 및 외부 볼륨에 대한 솔루션을 제공하십시오 (항상 작동하지는 않음).

이미 그랬습니다. 이전 의견을 참조하십시오.

서로 다른 프로젝트의 컨테이너가 통신하도록 허용하는 권장 방법은 external 네트워크를 공유하고 다른 서비스의 별칭을 사용하는 것입니다. 마찬가지로 프로젝트 전체에서 volumes_from 대신 external 명명 된 볼륨을 활용해야합니다.

나머지 게시물은 불필요하게 적대적이므로 응답하지 않습니다. 나는 여기 있고 토론을 할 의향이 있지만 당신의 괴롭힘을 받아 들일 필요는 없습니다.

솔직히 @ shin-

이 변경 사항이 어떻게 더 잘 전달 될 수 있었는지에 대한 제안에 관심이 있습니다.

나는 당신이 "관심"이있는 것 같지 않습니다. 작성 파일을 작성하고 "스팸"(웃음)으로 표시하기 전에 이미지를 가져 오는 것에 대한 티켓을 닫으면 커뮤니티에서 제안하는 내용에 확실히 관심이 없음을 알 수 있습니다. 무엇을 이루고 싶은지 잘 모르겠지만 커뮤니티와의 관계를 유지하는 것은 다른 사람이해야한다고 생각합니다.

나는 여기 있고 토론 할 의향이 있습니다

우리가 순수한 공덕 적 주장을 제공하더라도 무시하면됩니다. 그럼 왜 귀찮게?

추신. 이것을 주제에서 벗어난 것으로 표시하고 계속해서 우리의 의견을 존중하는 방법을 보여주십시오. 서로 다른 의견에 대해 너무 많은 찬성 투표를 보는 것이 아파요?

이미 그랬습니다. 이전 의견을 참조하십시오.

작동하는 샘플 솔루션이 보이지 않습니다. 죄송합니다.

나머지 게시물은 불필요하게 적대적이므로 응답하지 않습니다. 나는 여기 있고 토론을 할 의향이 있지만 당신의 괴롭힘을 받아 들일 필요는 없습니다.

죄송합니다. 그런 기분이 든다면. 현재 docker compose 파일 버전에 대한 이전 동작을 지원하는 것을 고려하고 새로운 방식으로 동작 할 새로운 형식 버전을 도입하십시오. 이것은 사용자층에 좋은 솔루션을 제공 할 수있는 유일한 옵션입니다.

부디. 내가 당신의 마음에 프로젝트를 기꺼이 돕겠다는 생각으로이 두 개의 내 의견을 다시 읽는 것을 고려하십시오.

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

Re the communication : 우리는 Mac 용 Docker를 통해 업데이트를 받았는데,이 변경 사항을 지적하는 어떤 종류의 변경 로그도 표시되지 않는 것 같았으므로 환경 변수가 변경된 이유를 파악하는 데 시간이 조금 걸렸습니다.

일단 나는 이것을 v1에서 v3으로 업그레이드하고 환경 변수 대신 서비스 이름을 사용하여 연결하는 기회로 삼았지만 실제로는 훨씬 더 깔끔하게 만들었습니다 👍

FWIW, compose에 의해 생성 된 컨테이너에서 exec에 대한 이전 버전과 호환되는 해킹 :

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 이것은 docker-compose에 의해 생성 된 expected 이름의 변경을 중심으로 작동합니다. 이 해결 방법은 명명 체계를 변경하지 않은 경우 존재하지 않습니다.

@joebowbeer 이 변경 후 주요 문제는 docker-compose 파일을 연결하는 것입니다. docker cmd를 통해 docker-compose가 시작한 컨테이너를 찾는 방법이 있습니다. 그러나 이것은 주제에 대한 약간의 도움이됩니다.

@ shin- 나는 우리 모두가 왜 우리가 스웜 라인 컨테이너 이름을 생성하기 위해 docker composer가 필요한지에 대한 설명을 기다리고 있다고 생각합니다.

제게는 정상 상태에있는 누구도 제작 목적으로 작곡가를 사용할 필요가 없다는 것이 분명합니다. Compose는 로컬에서 테스트 할 프로젝트를 늘리는 강력한 도구입니다. 로컬 전용 테스트에 대량으로 사용되는 도구에 docker swarm perk / 기능을 제공하는 것이 매력적이지 않습니다. 용기에 떼와 같은 이름이 필요하면 떼를 사용합니다. 권리?

여기서 두 번째 큰 질문은 왜 이것이 인수를 통해 옵션 기능으로 포함되지 않았는가입니다. 내 포럼과 커뮤니티에서이 동작을 기본 동작으로 호소하는 사람들이 보이지 않습니다. 그래서 우리는 아마도 그것을 새로운 arg : 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.

과거에는 엔터프라이즈에서 작업 할 때 변경 사항에 대해 "두 가지 주요 버전"규칙을 사용하는 경향이있었습니다. 하나는 지원 중단하고 다음에는 제거하는 방식이었습니다. 어떻게 이것이 옵트 인이 될 수 있었는지 잘 모르겠지만, _ 임시 _ 옵트 아웃은 정말 감사했을 것입니다.

Docker-compose에는 주 버전의 개념이없는 것 같지만 일시적인 "disable this"옵션 (명령 줄에서든 작성 파일에서든)이 하나 또는 두 개의 릴리스 (1.23 및 가능하면 1.24) "무기한"을 구성합니다.

이것이 비 리눅스 사용자를위한 자동 업데이트와 관련이있는 것 같다는 점을 감안할 때, 많은 사람들이 놀랐고, 나머지 분기 동안 "스크립팅을 업데이트하는 동안이 명령 줄 플래그로 실행"하는 대신에 많은 사람들이 놀랐습니다. 스크립트를 업데이트하기 위해 수동으로 다운 그레이드 및 / 또는 수행중인 작업을 삭제해야하는 수많은 개발자가 있습니다.

이 중대한 변화는 재앙입니다. 갑자기 많은 자동 배포가 중단되었습니다. 다시는 그러지 마세요.

* 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- 제시된 합리적인 제안을 고려하지 않기 때문에 여기에 토론이 없다는 것이 분명합니다. 또한 누군가가 괴롭힘을당하는 경우-당신은-이 중대한 변화로 전 세계의 수많은 개발자를 효과적으로 괴롭히는 것입니다.

많은 사람들 (나와 다른 사람)은 떼 모드에 compose를 사용하지 않습니다. 나는 과거에 컴 포즈 파일이 떼에 대한 서비스를 정의하는 데 사용되는 가정이있는 문제로 인해 내 compose 파일에 대해 낮은 버전을 지정합니다. 내가 지정한 버전이 내 도커 노드에서 생성 된 결과와 연결되어 있고 버전을 낮은 수준으로 잠그면 일관성있는 결과를 얻을 수 있고 도커 버전과의 호환성을 유지하기 위해 구성하는 업데이트를 수행 할 수 있다고 생각했습니다. 나는 뛰고있어. 분명히 여기에서 적절한 버전 관리를 기대할 수 없습니다.

그들이 갑자기 우리 물건을 부수 지 않도록 docker-compose를 고정시킬 수 있습니까?

가장 좋은 해결책은 컨테이너 이름에 슬러그 부분을 추가하는 것이 비활성화 될 수있는 docker-compose.yml 파일에 새로운 구성 옵션을 도입하는 것입니다.

s / 비활성화 / 활성화 /. 최소한 기존 작성 파일 버전에서.

이 동작은 작성 파일의 버전 번호에 연결해야합니다. 이 동작이 "지정"되었는지 여부에 관계없이 매우 널리 사용되므로 이전 버전과 호환되지 않는 변경입니다. 바이너리를 업그레이드 할 때 compose 파일이 동일한 방식으로 작동하는 것이 보장되지 않는데 왜 그 시점에서 사양을 버전 화합니까? compose 파일 사양을 비추천 (물론 docker-compose 이 실행될 때 많은 경고가 표시됨)하고 제거하면 내 모든 항목이 더 이상 작동하지 않지만 릴리스를 읽을 것으로 예상됩니다. 내 얼굴에 경고 메시지를 인쇄 할 수있는 권한이있는 프로그램에 대한 메모?

이와 같이 변경하는 것은 형식 외에도 사양의 동작을 버전 화하는 데 매우 좋은 동기로 보입니다. 경고와 함께 다른 사람의 코드 가정을 비난 할 수 있습니다. 이 문제에 이름을 올린 외부 문제의 양은 이것이 많은 사람들에게 얼마나 놀라운 일인지를 말해줍니다. 코드가 복잡해지지 않도록 레거시 동작이 깨지는 것을 보는 것은 정말 대단하지만 이와 같은 변경 사항은 한 번에 모두 적용 할 수 없습니다. 컨테이너 이름 작성에 대한 다른 가정이 깨질 것으로 예상 할 수 있습니까? 서비스 이름이 항상 컨테이너 이름에 포함됩니까? 아니면 예측 가능한 이름처럼 제거 할 수 있습니까?

이것은 일관성있는 네트워크 장치 이름 지정 이 Linux에서 널리 채택되었을 때를 생각 나게합니다 (그러나 이것은 wrt 이름 지정 ... idk의 반대입니다). 많은 코드가 ethN 용으로 하드 코딩되었으며 (여전히 놀라운 위치에 있음) 실제로 변경되지 않았습니다. 이 systemd 시스템에서 이전 동작 다시 얻을 수있는 방법 그러나 (그리고 다른 시스템,하지만 그것은 다를 수 있음)를 추가하여 net.ifnames=0 커널 인수에.

(2 차 통과로 인해 미안하지만, 첫 번째는 매우 건설적이지 않다고 생각합니다.)

이 변경으로 인해 --scale 옵션이 쓸모없는 것 같습니다. 서비스의 확장 된 인스턴스에 도달하려면 임의 접미사를 알아야하기 때문입니다.

예를 들어 Nginx의 업스트림 서버로 여러 서비스 인스턴스가 있습니다.

편집 : 자세한 내용은 # 6365 참조

와, 정말 끔찍한 변화입니다. 👎

스크립트에서 사용하기 위해 무작위로 생성 된 문자열을 어떻게 구해야합니까?

이 문제도 만났고 향후 하위 호환되지 않는 변경 사항에 대한 권장 사항을 표현하고 싶습니다. 우리도 project_service_index 형식에 의존하는 스크립트를 가지고 있으며 많은 사람들이 Mac에서 이러한 스크립트를 사용합니다. 이상적인 세상에서는 사람들이 사용하는 Mac 용 Docker 버전을 제어 할 수 있지만 지금은 자동 업그레이드 대화 상자가 나타나면 사람들이 업그레이드합니다.

내 문제 및 권장 사항은 다음과 같습니다.

1) 업그레이드 대화 상자에이 중대한 변경 사항이 표시되지 않았으므로이 변경 사항에 대한 명확한 경고가 없었습니다. 이상적인 세계에서는 각 업그레이드에 대한 모든 릴리스 정보를 확인하지만 지금은 확인하지 않습니다. 따라서 이와 같은 중요한 것이 업데이트 대화 상자에서 명시 적으로 호출되면 크게 감사 할 것입니다.

2) 1)로 인해 명백한 경고가 없었습니다. 이전 업그레이드에서 이와 같은 변경 사항이 호출되면 좋을 것입니다. 예를 들어, 최신 버전 이전의 업그레이드는 "컨테이너 이름 지정 체계가 다음 버전에서 변경됩니다. 스크립트를 업그레이드하십시오"와 같이 표시됩니다.

3)이 스레드를 읽은 후 우리가 사용하는 명명 체계가 보장되지 않는다는 것을 이해하고 컨테이너를 참조 할 수있는 더 좋은 방법이 있음을 깨달았습니다. 그러나 우리 모두는 바쁜 업무 생활을하고 있으며 작업을 계획해야하므로 스크립트 관리자로서 컨테이너 이름 사용을 더 나은 것으로 즉시 변환 할 수 없습니다. 권장되는 모범 사례를 사용하게되어 기쁘게 생각하지만 코드를 마이그레이션하는 데 시간이 필요합니다. 따라서 이와 같은 변경에 대한 지원 중단 전략이 있으면 좋을 것입니다.

여기서 핵심 사항은 대부분의 사람들이 docker compose 사용에 기본이되는 컨테이너 이름 지정 체계를 가정하고 있으며 명백한 사용 중단 전략없이 기본 동작을 변경하면 이러한 워크 플로에 해로울 수 있다는 것입니다.

사람들은 항상 의도 한 방식대로 소프트웨어를 사용하지 않으며, 가정이 실패 할 때 문제를 해결하는 데 소유권이 있습니다. 그러나 몇 가지 간단한 의사 소통을 통해 향후 변경 사항에 대비하고 최신 모범 사례로 이동하도록 동기를 부여 할 수 있습니다.

이전에 docker container exec -it project_php_1 bash 에 의존했다면 더 이상 사용할 수 없습니다.

서비스 ID를 찾으려면 docker ps 를 사용해야합니다.

그러나 project_php 및 project_php_xdebug 또는 project_php 과 일치하는 다른 서비스와 일치하므로 docker ps -q --filter=name=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 할 수 있습니다.

변화에 대한 생각을 공유 해주신 모든 분들께 감사드립니다. 우리는이 제대로 처리되고 우리의 부분에 조금 지나치게, 그리고 부분적으로 복귀 된 동의 작성 1.23.2 우리가 만든 컨테이너 임의 접미사를 유지하고 ( docker-compose run 우리가 더 적절이 처리 할 수있는, : # 4688 # 4549 # 5240, 원래 의도대로).

해결해야 할 미해결 문제가 있으면 알려주세요.

기본값이 예전처럼 작동하도록 --no-slug 또는 더 바람직하게는 --slug 를 끄는 명령 줄 옵션을 추가 할 계획이 있습니까?

1.23.2 이전 방식으로 되돌립니다.

docker-compose up 에 대해서만 되돌 렸지만 docker-compose run 대해서는 되 돌리지 않았습니다.

빠른 해결 감사합니다 !!

2018 년 11 월 28 일 오후 8시 9 분에 Joffrey F [email protected] 은 다음과 같이 썼습니다.

변화에 대한 생각을 공유 해주신 모든 분들께 감사드립니다. 우리는 이것이 제대로 처리되지 않았고 우리 측에서 약간 지나치게 열성적이라는 데 동의하며 Compose 1.23.2에서 부분적으로 되돌 렸습니다. 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> !!로 인벤토리를 계속 업데이트할까요?
정말 나쁘다!