Часто задаваемые вопросы по движку Docker

Работает ли Docker в Linux, macOS и Windows?

Вы можете запускать программы и исполняемые файлы для Linux и Windows в контейнерах Docker. Платформа Docker изначально работает в Linux (на x86-64, ARM и многих других архитектурах ЦП) и в Windows (x86-64).

Docker Inc. создаёт продукты, которые позволяют создавать и запускать контейнеры в Linux, Windows и macOS.

Что технология Docker добавляет к простому LXC?

Технология Docker не является заменой LXC. «LXC» относится к возможностям ядра Linux (в частности, к пространствам имён и контрольным группам), которые позволяют изолировать процессы друг от друга и контролировать распределение их ресурсов. Помимо этой низкоуровневой основы функций ядра, Docker предлагает высокоуровневый инструмент с несколькими мощными функциями:

  • Portable deployment across machines. Docker defines a format for bundling an application and all its dependencies into a single object called a container. This container can be transferred to any Docker-enabled machine. The container can be executed there with the guarantee that the execution environment exposed to the application is the same in development, testing, and production. LXC implements process sandboxing, which is an important pre-requisite for portable deployment, but is not sufficient for portable deployment. If you sent me a copy of your application installed in a custom LXC configuration, it would almost certainly not run on my machine the way it does on yours. The app you sent me is tied to your machine’s specific configuration: networking, storage, logging, etc. Docker defines an abstraction for these machine-specific settings. The exact same Docker container can run - unchanged - on many different machines, with many different configurations.

  • Ориентирован на приложения. Docker оптимизирован для развертывания приложений, а не машин. Это отражено в его API, пользовательском интерфейсе, философии дизайна и документации. Напротив, вспомогательные сценарии lxc фокусируются на контейнерах как на легковесных машинах — в основном на серверах, которые загружаются быстрее и требуют меньше оперативной памяти. Мы думаем, что в контейнерах есть нечто большее, чем просто это.

  • Automatic build. Docker includes *a tool for developers to automatically assemble a container from their source code*, with full control over application dependencies, build tools, packaging etc. They are free to use make, maven, chef, puppet, salt, Debian packages, RPMs, source tarballs, or any combination of the above, regardless of the configuration of the machines.

  • Управление версиями. Docker включает в себя возможности, подобные git, для отслеживания последовательных версий контейнера, проверки различий между версиями, фиксации новых версий, отката и т. д. История также включает то, как и кем был собран контейнер, поэтому вы получаете полную отслеживаемость. от производственного сервера до вышестоящего разработчика. Docker также реализует добавочные загрузки и загрузки, аналогичные git pull, поэтому новые версии контейнера можно передавать, только отправляя различия.

  • Повторное использование компонентов. Любой контейнер можно использовать как *родительское образ* для создания более специализированных компонентов. Это можно сделать вручную или в рамках автоматизированной сборки. Например, вы можете подготовить идеальную среду Python и использовать её в качестве основы для 10 различных приложений. Ваша идеальная установка PostgreSQL может быть повторно использована во всех ваших будущих проектах. И так далее.

  • Sharing. Docker имеет доступ к общедоступному реестру в Docker Hub, куда тысячи людей загрузили полезные образы: что угодно, от Redis, CouchDB, PostgreSQL до IRC-баунсеров, серверов приложений Rails, Hadoop и базовых образов для различных дистрибутивов Linux. *реестр* также включает официальную «стандартную библиотеку» полезных контейнеров, поддерживаемую командой Docker. Сам реестр имеет открытый исходный код, поэтому любой может развернуть свой собственный реестр для хранения и передачи частных контейнеров, например, для развертывания внутренних серверов.

  • Экосистема инструментов. Docker определяет API для автоматизации и настройки создания и развертывания контейнеров. Существует огромное количество инструментов, интегрирующихся с Docker для расширения его возможностей. Развертывание в стиле PaaS (Dokku, Deis, Flynn), многоузловая оркестрация (Maestro, Salt, Mesos, Openstack Nova), панели управления (docker-ui, Openstack Horizon, Shipyard), управление конфигурацией (Chef, Puppet), непрерывная интеграция (Jenkins, Strider, Travis) и т. д. Docker быстро зарекомендовал себя как стандарт инструментов на основе контейнеров.

В чем разница между контейнером Docker и виртуальной машиной?

Есть отличный ответ StackOverflow показывая различия.

Потеряю ли я свои данные при выходе из контейнера?

Нисколько! Любые данные, которые ваше приложение записывает на диск, сохраняются в своём контейнере до тех пор, пока вы явно не удаляет данный контейнер. Файловая система для контейнера сохраняется даже после остановки контейнера.

Как далеко масштабируются контейнеры Docker?

Некоторые из крупнейших ферм серверов в мире сегодня основаны на контейнерах. Крупные веб-развертывания, такие как Google и Twitter, и поставщики платформ, такие как Heroku, работают на контейнерной технологии в масштабе сотен тысяч или даже миллионов контейнеров.

Как подключить контейнеры Docker?

В настоящее время рекомендуемым способом подключения контейнеров является сетевая функция Docker. Вы можете увидеть детали как работать с сетями Docker.

Как запускает более одного процесса в контейнере Docker?

Данный подход не рекомендуется для большинства случаев использования. Для максимальной эффективности и изоляции каждый контейнер должен решать одну конкретную проблемную область. Однако если вам нужно запускает несколько служб в одном контейнере, см. Запуск нескольких сервисов в контейнере.

Как сообщить о проблеме безопасности с Docker?

Вы можете узнать о политике безопасности проекта здесь и сообщить о проблемах безопасности по этому адресу почтовый ящик.

Почему мне нужно подписывать свои коммиты в Docker с помощью DCO?

Читает наш блогпост о введении DCO.

При сборке образа следует предпочесть системные библиотеки или комплектные?

Это краткое изложение обсуждения список рассылки docker-dev.

Практически все программы зависят от сторонних библиотек. Чаще всего они используют динамическую компоновку и какую-то зависимость от пакетов, поэтому, когда нескольким программам нужна одна и та же библиотека, она устанавливается только один раз.

Однако некоторые программы объединяют свои сторонние библиотеки, поскольку они полагаются на очень специфические версии данных библиотек.

При создании образа Docker лучше использовать связанные библиотеки или вам следует создавать данные программы так, чтобы они вместо этого использовали системные библиотеки по умолчанию?

Ключевым моментом системных библиотек является не экономия места на диске или в памяти. Речь идет о безопасности. Все основные дистрибутивы серьезно относятся к безопасности, имея специальные группы безопасности, внимательно следя за опубликованными уязвимостями и сами раскрывая рекомендации. (См. Информация о безопасности Debian для примера данных процедур.) Однако разработчики вышестоящего уровня не всегда реализуют подобные методы.

Перед настройкой образа Docker для компиляции программы из исходного кода, если вы хотите использовать связанные библиотеки, вы должны проверяет, предоставляют ли авторы основной ветки удобный способ анонсировать уязвимости безопасности и своевременно ли они обновляют свои связанные библиотеки. Если они этого не сделают, вы подвергаете себя (и пользователей вашего образа) уязвимостям безопасности.

Аналогичным образом, прежде чем использовать пакеты, созданные другими, вы должны проверяет, реализуют ли каналы, предоставляющие данные пакеты, аналогичные рекомендации по обеспечению безопасности. Загрузка и установка «все-в-одном» .deb или .rpm поначалу звучит великолепно, за исключением случаев, когда у вас нет возможности выяснить, что он содержит копию библиотеки OpenSSL, уязвимую для ошибки Кровотечение.

Почему DEBIAN_FRONTEND=noninteractive не рекомендуется использовать в Dockerfiles?

При сборке образов Docker в Debian и Ubuntu вы могли столкнуться с такими ошибками, как:

unable to initialize frontend: Dialog

Данные ошибки не останавливают сборку образа, но информируют вас о том, что процесс установки попытался открывает диалоговое окно, но не смог. Как правило, данные ошибки можно игнорировать.

Некоторые люди обходят данные ошибки, изменяя переменную среды DEBIAN_FRONTEND внутри Dockerfile с помощью:

ENV DEBIAN_FRONTEND=noninteractive

Это не позволяет установщику открывать диалоговые окна во время установки, что устраняет ошибки.

Хотя это может показаться хорошей идеей, у нее могут быть побочные эффекты. Переменная среды DEBIAN_FRONTEND наследуется всеми образами и контейнерами, созданными на основе вашего образа, эффективно изменяя их поведение. Люди, использующие данные образы, сталкиваются с проблемами при интерактивной установке программного обеспечения, поскольку программы установки не отображают никаких диалоговых окон.

Из-за этого, а также из-за того, что установка DEBIAN_FRONTEND на noninteractive является главным образом «косметическим» изменением, мы не одобряем её изменение.

Если вам действительно нужно изменяет его настройку, обязательно возвращает его обратно на значение по умолчанию впоследствии.

Почему я получаю Connection reset by peer при выполнении запроса к службе, работающей в контейнере?

Обычно это сообщение возвращается, если служба уже привязана к вашему локальному хосту. В результате запросы, поступающие к контейнеру извне, отбрасываются. Чтобы решить эту проблему, изменяет конфигурацию службы на локальном хосте, чтобы служба принимала запросы со всех IP-адресов. Если вы не знаете, как это сделать, обратитесь к документации по вашей ОС.

Почему я получаю Cannot connect to the Docker daemon. Is the docker daemon running on this host? при использовании docker-машины?

Эта ошибка указывает на то, что клиент Docker не может подключиться к виртуальной машине. Это означает, что либо виртуальная машина, работающая под docker-machine, не запущена, либо клиент неправильно указывает на нее.

Чтобы убедиться, что док-машина работает, вы можете использовать команду docker-machine ls и при необходимости запускает её с docker-machine start.

$ docker-machine ls
NAME             ACTIVE   DRIVER       STATE     URL   SWARM                   DOCKER    ERRORS
default          -        virtualbox   Stopped                                 Unknown

$ docker-machine start default

Вам нужно сказать Докеру поговорить с этой машиной. Вы можете сделать это с помощью команды docker-machine env. Например,

$ eval "$(docker-machine env default)"
$ docker ps

Где я могу найти больше ответов?

Вы можете найти больше ответов на :