Это старая версия документа!
docker-compose.yml - Примеры конфигурационных файлов для композитора
- Если во время выполнения определена только одна из инструкций, то и CMD и ENTRYPOINT будут иметь одинаковый эффект.
- Те же результаты будут, если использовать CMD вместо ENTRYPOINT.
Правила использования
- Если используется режим shell для ENTRYPOINT, CMD игнорируется.
- При использовании режима exec для ENTRYPOINT аргументы CMD добавляются в конце.
- При использовании режима exec для инструкции ENTRYPOINT необходимо использовать режим exec и для инструкции CMD. Если этого не сделать, Docker попытается добавить sh -c в уже добавленные аргументы, что может привести к некоторым непредсказуемым результатам.
- Инструкции ENTRYPOINT и CMD могут быть переопределены с помощью флагов командной строки.
- Все вышеперечисленные факты справедливы, но разработчики имеют возможность переопределять флаги в команде docker run
Использование
- Используйте ENTRYPOINT, если вы не хотите, чтобы разработчики изменяли исполняемый файл, который запускается при запуске контейнера. Вы можете представлять, что ваш контейнер – исполняемая оболочка.
- Используйте только CMD (без определения ENTRYPOINT), если требуется, чтобы разработчики могли легко переопределять исполняемый файл. Если точка входа определена, исполняемый файл все равно можно переопределить, используя флаг –entrypoint.
command
В файле Compose переопределяет CMDDockerfile. Есть некоторые незначительные синтаксические различия (в частности, Compose никогда не будет автоматически вставлять sh -cза вас оболочку оболочки), но они контролируют одно и то же в метаданных контейнера.
Однако помните, что помимо Compose существуют и другие способы запуска контейнера. docker run не прочитает ваш docker-compose.yml файл и не увидит эту command: он также не читается такими инструментами, как Kubernetes. Если вы встроите Dockerfile CMD в, оно будет использовать во всех вариантах.
Переопределение действительно необходимо command:в том случае, если вам нужно запустить основной процесс, отличный от стандартного, для контейнера.
endpoint
kanban
proxy: image: leanlabs/nginx:1.0.1 volumes: - "./build/conf.d:/etc/nginx/conf.d" - "./build/certs:/etc/nginx/certs" - "./build/sites-enabled:/etc/nginx/sites-enabled" links: - kanban:kanban ports: - "443:443" - "8082:80" kanban: image: leanlabs/kanban:1.7.1 environment: # URL on which Leanlabs Kanban will be reachable - KANBAN_SERVER_HOSTNAME=http://kanban.gitlab.com # This string is used to generate user auth tokens - KANBAN_SECURITY_SECRET=qwerty # Your GitLab host URL - KANBAN_GITLAB_URL=https://gitlab.com # Your GitLab OAuth client ID - KANBAN_GITLAB_CLIENT=qwerty # Your GitLab OAuth client secret key - KANBAN_GITLAB_SECRET=qwerty # Wheter to enable sign up with user API token - KANBAN_ENABLE_SIGNUP=true # Redis server address - IP:PORT - KANBAN_REDIS_ADDR=redis:6379 links: - redis:redis command: ./kanban server redis: image: leanlabs/redis:1.0.0 volumes: - "/data:/data"