docker создание контекста
Обратитесь к options section за обзором доступных OPTIONS для этой команды.
Description
Создает новый context . Это позволяет быстро переключать конфигурацию cli для подключения к разным кластерам или отдельным узлам.
Примеры использования этой команды см. ниже для examples section .
Options
| Name, shorthand | Default | Description |
| —default-stack-orchestrator | deprecated Оркестратор по умолчанию для операций стека для использования в этом контексте (swarm|kubernetes|all) |
|
| —description | Описание контекста | |
| —docker | установить конечную точку docker | |
| —from | создать контекст из именованного контекста | |
| —kubernetes | deprecatedKubernetes установить конечную точку kubernetes |
Examples
Создайте контекст с конечной точкой docker и kubernetes.
Для создания контекста с нуля укажите опции docker и, при необходимости, kubernetes. В приведенном ниже примере создается контекст my-context с конечной точкой docker /var/run/docker.sock и конфигурацией kubernetes, полученной из файла /home/me/my-kube-config :
$ docker context create \ --docker host=unix:///var/run/docker.sock \ --kubernetes config-file=/home/me/my-kube-config \ my-context
Создание контекста на основе существующего контекста
Используйте параметр —from= , чтобы создать новый контекст из существующего контекста. В приведенном ниже примере создается новый контекст с именем my-context из существующего контекста existing-context :
$ docker context create --из существующего контекста мой контекст
Если параметр —from не установлен, context создается из текущего контекста:
$ docker context create my-context
Это можно использовать для создания контекста из существующего сценария на основе DOCKER_HOST :
$ source my-setup-script.sh $ docker context create my-context
Чтобы получить только конфигурацию конечной точки docker из существующего контекста, используйте параметр —docker from= . В приведенном ниже примере создается новый контекст с именем my-context с использованием конфигурации конечной точки docker из существующего контекста existing-context и конфигурации kubernetes, полученной из файла /home/me/my-kube-config :
$ docker context create \ --docker from=existing-context \ --kubernetes config-file=/home/me/my-kube-config \ my-context
Чтобы получить только конфигурацию kubernetes из существующего контекста, используйте параметр —kubernetes from= . В приведенном ниже примере создается новый контекст с именем my-context с использованием конфигурации kuberentes из существующего контекста existing-context и конечной точки docker /var/run/docker.sock :
$ docker context create \ --docker host=unix:///var/run/docker.sock \ --kubernetes from=existing-context \ мой-контекст
Конфигурации конечных точек Docker и Kubernetes, а также оркестратор стека по умолчанию и описание можно изменить с помощью docker context update .
Для получения подробной информации см. docker context update reference .
Parent command
| Command | Description |
|---|---|
| docker context | Manage contexts |
Related commands
| Command | Description |
| docker создание контекста | Создать контекст |
| Экспорт контекста docker | Экспорт контекста в файл tar или kubeconfig |
| импорт контекста docker | Импорт контекста из файла tar или zip |
| docker проверка контекста | Отображение подробной информации об одном или нескольких контекстах |
| docker контекст лс | List contexts |
| docker контекст РМ | Удалить один или несколько контекстов |
| Обновление контекста docker | Обновить контекст |
| Использование контекста docker | Установить текущий контекст docker |
What is context: . in docker-compose?
I am trying to learn Docker and created my first Docker compose file. Basically, I am trying to create a Django web microservice and use docker compose file to manage it. Here is my code for my docker-compose.yml :
version: "3" services: app: build: context: . ports: - "8000:8000" volumes: - ./app:/app command: > sh -c "py manage.py runserver 0.0.0.0:8000" I don’t understand the use of context: . Can someone please explain me this
18.8k 9 9 gold badges 55 55 silver badges 82 82 bronze badges
asked Jan 8, 2021 at 2:06
Aryan Pandhare Aryan Pandhare
613 1 1 gold badge 5 5 silver badges 5 5 bronze badges
How to include files outside of Docker’s build context? includes some examples of cases where you will need to specify a different context: directory.
Jan 8, 2021 at 3:03
Does this answer your question? What is happening when using ../ with docker-compose volume
Jan 8, 2021 at 3:13
Also, when providing no other attributes: you can provide the context to build directly: build: .
Jan 8, 2021 at 8:06
3 Answers 3
CONTEXT
Either a path to a directory containing a Dockerfile , or a url to a git repository.
When the value supplied is a relative path, it is interpreted as relative to the location of the Compose file. This directory is also the build context that is sent to the Docker daemon.
Compose builds and tags it with a generated name, and uses that image thereafter.
build: context: ./dir That mean, its a path to the directory that contains Dockerfile file. It purposes to build a new image for the service.
context: .
Dockerfile file should be existing in the current directory (in the same folder of the docker-compose.yml file).
1,830 1 1 gold badge 23 23 silver badges 32 32 bronze badges
answered Jan 8, 2021 at 2:13
Thanh Nguyen Van Thanh Nguyen Van
10.5k 6 6 gold badges 35 35 silver badges 53 53 bronze badges
how can we use it in different environments?
Aug 21, 2022 at 15:58
How can we use context to point directly to a dockerfile that is named?
Nov 10, 2022 at 23:54
dockerfile: your_docker_file_name @DouglasGaskell
Nov 29, 2022 at 11:53
context defines either a path to a directory containing a Dockerfile, or a URL to a git repository.
In your case, . is a relative path representing the current directory where you run docker-compose command and where Compose can find a Dockerfile (and obviously also the docker-compose.yaml file).
The Dockerfile can also be elsewhere using the dockerfile keyword like that in this example:
version: "3.3" services: service-A build: context: ./all-service dockerfile: ./service-A/Dockerfile service-B build: context: ./all-service dockerfile: ./service-B/Dockerfile service-C build: context: ./all-service dockerfile: ./service-C/Dockerfile The additional context keyword here is to tell the Dockerfile where to find its dependent files.
For instance, in one of your Dockerfile there are these lines:
WORKDIR /my-app COPY package.json package.json COPY package-lock.json package-lock.json RUN npm install COPY requirements.txt requirements.txt RUN pip install -r requirements.txt These three files must be in the context directory or git repository: package.json , package-lock.json , requirements.txt .
Полная автоматизация «development» среды с помощью docker-compose
В этой статье мы поделимся опытом автоматизации запуска, тестирования и конфигурации больших проектов с использованием docker-compose. Несколько простых изменений могут помочь Вашей команде быть более эффективной и тратить время на важные, а не на рутинные задачи.
Docker в 2017
На конференции Dockercon 2016 CEO компании Docker рассказал, что количество приложений, которые запускаются в Docker выросло на 3100% за последние два года. Боле 460 тысяч приложений по всему миру запускаются в Docker. Это невероятно!
Если вы все еще не используете Docker, я бы посоветовал почитать отличную статью об использовании Docker во всем мире. Docker полностью изменил то, как мы пишем приложения и стал неотъемлемой частью для разработчиков и DevOps команд. В этой статье мы полагаем, что вы уже знакомы с Docker и хотим дать вам еще одну серьезную причину продолжать использовать его.
Что не так?
С начала моей карьеры, когда я занимался разработкой веб-приложений, запуск приложения в рабочем окружении всегда был непростой задачей. Приходилось делать много дополнительной работы от установки базы данных до конфигурации приложения, чтобы просто его запусить. Разработчики любят не любят писать документацию, и шаги для запуска проекта обычно спрятаны в головах членов команды. В итоге, запуск проекта становится болезненной задачей, особенно для новых ребят.
Многие проекты просты в начале, но становятся больше со временем. Это приводит к увеличению внешних зависимостей, таких как базы данных, очереди. В связи с ростом популярности микросервисов, многие проекты перестают быть монолитными и разделяются на несколько небольших частей. Любое такое изменение требует внимания всей команды, так как после таких изменений, проект нужно запускать по-другому. Обычно, разработчики, занимающиеся корневыми изменениями, пишут письмо, либо создают вики страничку с описанием шагов, которые нужно сделать, чтобы проект снова запустился на рабочих окружениях. Обычно это работает, но не всегда 🙂 Однажды наша команда попала в ситуацию, когда разработчик с другого континента сделал много изменений в проекте, написал длинное письмо и ушел спать. Я полагаю, Вы знаете, что было дальше. Все верно, он забыл упомянуть несколько важных моментов. В результате, на следующий день часть команды просто не смогла запустить проект и день был потерян.
Как инженеру, мне нравится автоматизировать все вокруг. Я верю, что запуск, тестирование и развертывание всегда должны быть одношаговыми. В этом случае, команда сможет сфокусироваться на важных задачах: разработке и улучшении продукта. Это было сложнее сделать 10 лет назад, но сейчас автоматизировать стало гораздо проще и, как мне кажется, каждая команда должна уделять этому время. Чем раньше — тем лучше.
Быстрый старт с docker-compose
Docker-compose это простой инструмент, который позволяет настроить и запустить несколько контейнеров одной командой. До того, как мы нырнем глубже в docker-compose, нужно немного остановиться на структуре проекта. Мы используем «monorepo». Код каждого сервиса (frontend, api, worker, etc) находится в своей директории и имеет Dockerfile. Пример структуры проекта можно посмотреть здесь.
Вся конфигурация для docker-compose описывается в файле docker-compose.yml , который обычно лежит в корне проекта. Начнем с автоматизации простого Node.JS приложения, которое работает с базой данных MongoDB. Вот так будет выглядеть конфигурационный файл:
version: '2' services: web: build: context: ./web dockerfile: Dockerfile.dev volumes: - "./web/src:/web/src" ports: - "8080:8080" mongo: command: mongod image: mongo:3.2.0 ports: - "27100:27017" # map port to none standard port, to avoid conflicts with locally installed mongodb. volumes: - /var/run/docker.sock:/var/run/docker.sockЧтобы запустить проект, нам понадобиться одна команда:
$ docker-compose upПри первом старте, все контейнеры будут построены или скачаны. Если вы работали с Docker, конфигурационный файл для docker-compose должен быть более-менее понятен, но стоит обратить внимание на несколько деталей:
- context: ./web — таким образом указывается путь к докер файлу сервиса внутри нашего репозитория.
- dockerfile: Dockerfile.dev — мы используем отдельный Dockerfile.dev для рабочих окружений. Для «production» окружений, мы копируем код в образ Docker, а на рабочих окружениях мы добавляем код как «volume». При использовании «volume» не приходится перезапускать docker-compose каждый раз после изменений в коде.
- volumes: — «./web/src:/web/src» — так код добавляется как «volume» в Docker.
- Docker-compose автоматически «связывает» контейнеры. Благодаря этому есть возможно обращаться к сервису по имени. Например, из сервиса web вы можете подключится к базе данных MongoDB: mongodb://mongo:27017
Всегда используйте —build
По умолчанию, docker-compose up не будет перестраивать контейнеры, если они уже есть на хосте. Чтобы заставить докер делать это, нужно использовать аргумент —build . Обычно это нужно, когда сторонние зависимости проекта меняются или меняется докерфайл. В нашей команде мы всегда используем docker-compose up —build . Docker умеет кэшировать слои и не будет перестраивать контэйнер, если ничего не поменялось. При использовании —build повсеместно, вы, возможно, потеряете несколько секунд при старте приложения. Но, при этом вы никогда не столкнетесь с магическими проблемами запуска новой версии приложения со старыми зависимостями.
Совет: Вы можете обернуть команду запуска проект в простой баш скрипт:
#!/bin/sh docker-compose up --build "$@"Это даст вам возможность поменять аргументы или подход для запуска приложения в целом. Для команды это всегда будет просто как: ./bin/start.sh .
Частичный запуск
В этом примере docker-compose.yml некоторые сервисы зависят друг от друга:
api: build: context: ./api dockerfile: Dockerfile.dev volumes: - "./api/src:/app/src" ports: - "8081:8081" depends_on: - mongo
В данном случае, api сервису необходима база данных для работы. При запуске docker-compose, вы можете передать название сервиса для того, чтобы запустить только его и все его зависимости: docker-compose up api . Эта команда запустит MongoDB и только после этого запустит api .
В больших проектах всегда есть части, которые нужны лишь время от времени. Различные члены команды могут работать над различными частями приложения. Фронтенд разработчику, который работает над landing сайтом, нет нужды запускать проект целиком. Он может просто запустить только те части, которые ему действительно нужны.
>/dev/null назойливые логи
Часто мы используем инструменты, которые генерируют много логов, тем самым отвлекая нас от полезных логов нашего приложения. Чтобы отключить логи для конкретного сервиса, нужно просто установить logging driver в none.
mongo: command: mongod image: mongo:3.2.0 ports: - "27100:27017" volumes: - /var/run/docker.sock:/var/run/docker.sock logging: driver: none
Несколько файлов docker-compose
По умолчанию, когда вы запускаете docker-compose up , docker-compose ищет конфигурационный файл docker-compose.yml в текущей директории. В некоторых случаях (поговорим об этом через минуту), вам придется создать несколько таких конфигурационных файлов. Чтобы сделать это, вам достаточно использовать аргумент —file :
docker-compose --file docker-compose.local-tests.yml upТак почему же вам может понадобиться несколько конфигурационных файлов? Первый вариант использования — это разбиение большого проекта на несколько более мелких. Интересно, что даже если вы запускаете несколько отдельных docker-compose, сервисы все равно смогут общаться друг с другом по имени из docker-compose. Например, вы можете разделить инфраструктурные контэйнеры (базы данных, очереди и т.д.) и контейнеры приложения в отдельные docker-compose файлы.
Запуск тестов
Наши тесты включают в себя различные типы: юнит, интеграционные, UI тестирование, проверку синтаксиса кода. У каждого сервиса свой набор тестов. Интеграционные и UI тесты требуют api и web frontend для их работы.
В самом начале нам показалось, что мы должны запускать тесты при каждом запуске docker-compose. Но очень скоро мы поняли, что это не всегда удобно и занимает слишком много времени. В каких-то случаях нам также хотелось иметь немного больше контроля над тем, какие тесты запускать. Для этого мы используем отдельный конфигурационный docker-compose файл:
version: '2' services: api-tests: image: app_api command: npm run test volumes: - "./api/src:/app/src" web-tests: image: app_web command: npm run test volumes: - "./web/src:/app/src"Для запуска тестов необходимо, чтобы основной docker-compose был запущен. Интеграционные тесты используют рабочую версию api сервиса, а UI тесты используют web frontend сервиса. По сути тесты просто используют образы, которые собраны в основном docker-compose. Также возможен запуск тестов только для конкретного сервиса, например:
docker-compose --file docker-compose.local-tests.yml up api-testsДанная команда запустит только тесты для api сервиса.
Префикс для контейнеров
По умолчанию, все контэйнеры, которые запускаются с помощью docker-compose, используют название текущей директории как префикс. Название этой директории может отличаться в рабочих окружениях у разных разработчиков. Этот префикс ( app_ ) используется, когда мы хотим сослаться на контейнер из основного docker-compose файла. Чтобы зафиксировать этот префикс, нужно создать файл .env рядом с конфигурационными файлами docker-compose в той директории, из которой запускается docker-compose:
COMPOSE_PROJECT_NAME=appТаким образом, префикс будет одинаковым во всех рабочих окружениях.
Заключение
Docker-compose это очень полезный и гибкий способ автоматизации запуска проектов.
Когда новые разработчики добавляются к нам в команду, мы даем им небольшую задачу, которую они должны закончить к концу первого рабочего дня. Каждый, кто присоединялся к нашей команде, справился с этим и был самым счастливым человеком на Земле. Уже с первых минут новые разработчики могут сфокусироваться на важных задачах и не тратить времени на то, чтобы запустить проект. Наша документация для старта проекта состоит из трех пунктов:
- Установить Docker и Docker-compose
- Склонировать репозиторий
- Запустить в терминале ./bin/start.sh
Для того, чтобы Вам было проще понять эту статью, у нас есть пример проекта на Github. Делитесь вашим опытом и задавайте вопросы.
Надеемся, что статья была полезной и поможет сделать Ваш проект лучше 🙂
Версию на английском, можно почитать здесь.
Как контексты Docker позволяют работать с несколькими хостами – CloudSavvy IT
Контексты в Docker CLI предоставляют оптимизированный механизм для взаимодействия с несколькими конечными точками Docker. Вы можете установить контексты для каждого из ваших хостов и быстро переключаться между ними.
Когда контекст активен, Docker отправляет все ваши команды на этот хост. Если вы обычно используете локальную установку Docker, но иногда вам нужно запускать контейнеры в производственную среду, контексты Docker – один из доступных вам вариантов.
Любая допустимая конечная точка Docker может быть контекстно разрешена. Вы можете подключить обычные установки Docker Engine, кластеры Docker Swarm и кластеры Kubernetes в облаке. Каждый сохраненный контекст содержит всю информацию о соединении для указанного хоста.
Создание контекста
Контексты управляются с помощью docker context заказывать. Вы создаете новые контексты, используя docker context create . Вы должны указать имя для вашего контекста, а также конфигурацию конечной точки.
Вот как создать контекст, который подключается к сокету Docker, отображаемому на удаленном хосте через TCP:
docker context create remote-host --docker host=tcp:///my-remote-host:2735Контексты используют Docker Swarm в качестве оркестратора контейнеров по умолчанию. Вы можете установить это явно с помощью флага:
docker context create remote-host --default-stack-orchestrator=swarm --docker host=tcp:///my-remote-host:2735Измените тип Orchestrator для подключения к Kubernetes. Вам также понадобится. Добавлять —kubernetes выделите и укажите путь к файлу конфигурации Kubernetes:
docker context create kubernetes-host --default-stack-orchestrator=kubernetes --kubernetes config-file=/home/username/.kube/config --docker host=unix:///var/run/docker.sockВыберите контексты
Активный контекст переключается с помощью docker context use . Передайте имя контекста, который хотите активировать.
docker context use remote-hostВсе последующие команды CLI выполняются с использованием конечной точки, предоставленной новым контекстом. Активный контекст останется автоматически, пока вы его не измените. Чтобы переключиться на другой контекст, введите docker context use очередной раз. Вы можете вернуться к контексту по умолчанию с помощью локального сокета Docker, передав default в качестве имени контекста.
Вы всегда можете переопределить выбранный контекст с помощью de —context флаг для каждой команды Docker:
docker run ubuntu:latest --context remote-hostВ DOCKER_CONTEXT переменная окружения также функционирует как альтернатива —context флаг. Оба механизма позволяют временно переключиться на другой контекст без необходимости запускать и возвращаться снова. docker context use заказывать.
Привычки DOCKER_HOST переменная окружения также переопределит активный контекст. Эта переменная заставляет Docker использовать конкретную конечную точку демона вместо той, которая предоставляется контекстом.
Вы можете проверить активный контекст, запустив docker context ls . Эта команда перечисляет все контексты, доступные в вашей конфигурации CLI. Активный контекст отмечен звездочкой. Чтобы удалить контекст, запустите. из docker context rm , где указано имя контекста. Невозможно использовать. удалить default контекст.
Синхронизировать контексты между машинами
Файлы контекста хранятся в папке конфигурации вашего Docker CLI. Это обычно $HOME/.docker в Linux. Вы найдете свои контексты в contexts подпапка. Каждый контекст получает свою папку с уникальным хешем. Внутри вы найдете meta.json файл с описанием контекста. Только созданные контексты имеют файлы на диске. В default context наследует настройки из конфигурации вашего демона Docker.
Если вы хотите синхронизировать конфигурацию контекста, вы можете создать резервную копию contexts папку, чтобы переместить ее на другую машину. Вы можете использовать передачу Rsync или репозиторий Git, чтобы упростить регулярные обновления. В зависимости от ваших требований, вы также можете подключить папку к общему сетевому ресурсу.
Docker также позволяет экспортировать и импортировать контексты через интерфейс командной строки:
docker context export my-contextЭто будет my-context.dockercontext файл в вашей книге. Файл содержит meta.json контент и некоторая дополнительная информация, такая как название контекста. Перенесите этот файл на другой компьютер и запустите docker context import my-context.dockercontext для загрузки конфигурации контекста.
Вы также можете экспортировать автономный файл конфигурации Kubernetes для контекстов Kubernetes:
docker context export kubernetes-context --kubeconfigЭто создаст обычный файл kubeconfig, совместимый с такими инструментами экосистемы Kubernetes, как: kubectl . Возможность получить файл kubeconfig из контекста Docker улучшает взаимодействие инструментальной цепочки. В этом файле нет ничего специфичного для Docker CLI.
Если вам нужно отредактировать контекст, используйте docker context update заказывать. Принимает те же флаги, что и: docker context create . Если вы выполняете массовые обновления, вы можете использовать meta.json файлы для непосредственного управления вашими контекстами. Вы можете проверить контекст meta.json файл из интерфейса командной строки с помощью docker context inspect my-context .
Заключение
Контексты Docker полезны, когда вам нужно развернуть контейнеры в нескольких независимых средах. Вы можете установить контексты для своего локального сокета Docker, промежуточного сервера общих команд и рабочего сервера Kubernetes.
Docker имеет встроенную поддержку контейнерных облаков Microsoft Azure и Amazon ECS, которые также можно добавить в качестве контекста. Количество контекстов, которые вы можете создать, не ограничено, поэтому вы можете быть гибкими при перемещении между хостами.
Возможно, самая большая функциональная проблема с контекстами – это возможность случайного запуска команды в неправильном контексте. Если ты забыл, что ты в своем production контекст, бег docker rm database-container может иметь разрушительные последствия. Если сомневаетесь, бегите docker context ls сначала проверьте, что вы выбрали.