docker репозиторий - В чем разница между изображением Докера и контейнером?





tag latest (17)


Проще говоря, если образ является классом, то контейнер является экземпляром класса, являющимся объектом времени выполнения.

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

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

Итак, вопрос: что такое контейнер?




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

Вы можете видеть все ваши изображения с изображениями docker images тогда как вы можете видеть свои запущенные контейнеры с docker ps (и вы можете увидеть все контейнеры с docker ps -a ).

Таким образом, исполняемый экземпляр изображения представляет собой контейнер.




Хотя простейший вопрос о контейнере как о запущенном изображении, это не совсем точно.

Изображение - это действительно шаблон, который можно превратить в контейнер. Чтобы превратить изображение в контейнер, движок Docker принимает изображение, добавляет файловую систему чтения-записи сверху и инициализирует различные параметры, включая сетевые порты, имя контейнера, идентификатор и ограничения ресурсов. Рабочий контейнер имеет текущий исполняемый процесс, но контейнер также можно остановить (или выйти из терминологии Докера). Вышедший контейнер не совпадает с изображением, поскольку его можно перезапустить и сохранить его настройки и любые изменения файловой системы.




Изображение представляет собой класс как контейнер для объекта.

Контейнер представляет собой экземпляр изображения, поскольку объект является экземпляром класса.




Для аналогии с манекеном вы можете подумать, что Docker имеет абстрактный ImageFactory, который содержит ImageFactories, которые они приходят из store .

Затем, как только вы захотите создать приложение из этого ImageFactory, у вас будет новый контейнер, и вы можете его изменить, как хотите. DotNetImageFactory будет непреложным, поскольку он действует как абстрактный заводский класс, где он только предоставляет экземпляры, которые вы желаете.

IContainer newDotNetApp = ImageFactory.DotNetImageFactory.CreateNew(appOptions);
newDotNetApp.ChangeDescription("I am making changes on this instance");
newDotNetApp.Run();



Как и в аспекте программирования,

Изображение является исходным кодом.

Когда исходный код компилируется и создается, он вызывается как приложение.

Simillar к этому «когда экземпляр создан для изображения», он называется « Контейнер »,




Легко.

Изображения -

Приложение файловой системы и конфигурации (только для чтения), которое используется для создания контейнеров. Более подробно .

Контейнеры -

Это запущенные экземпляры изображений Docker. Контейнеры запускают реальные приложения. Контейнер включает приложение и все его зависимости. Он разделяет ядро ​​с другими контейнерами и запускается как изолированный процесс в пользовательском пространстве на основной ОС. Более подробно .

Другие важные условия:

Docker daemon -

Фоновая служба, запущенная на хосте, который управляет построением, запуском и распространением контейнеров Docker.

Докер-клиент -

Инструмент командной строки, который позволяет пользователю взаимодействовать с демоном Docker.

Docker Store -

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

Одна картинка стоит тысячи слов.

(Для более глубокого понимания, пожалуйста, прочтите this .)

Резюме:

  • Вытяните изображение из концентратора Docker или создайте из Dockerfile => Дает изображение Docker (не редактируется).
  • Запуск изображения ( docker run image_name:tag_name ) => Дает текущее изображение, т.е. контейнер (редактируемый)



Контейнер Docker запускает экземпляр изображения. Вы можете связать изображение с программой и контейнером с процессом :)




Как многие ответы указывали на это: вы создаете Dockerfile для получения изображения, и вы запускаете изображение, чтобы получить контейнер .

Однако следующие шаги помогли мне лучше понять, что изображение и контейнер Docker:

1) Build Dockerfile:

docker build -t my_image dir_with_dockerfile

2) Сохраните изображение в файле .tar

docker save -o my_file.tar my_image_id

my_file.tar сохранит изображение. Откройте его с tar -xvf my_file.tar , и вы увидите все слои. Если вы погружаетесь глубже в каждый уровень, вы можете увидеть, какие изменения были добавлены в каждом слое. (Они должны быть очень близки к командам в файле Docker).

3) Чтобы заглянуть внутрь контейнера, вы можете сделать:

sudo docker run -it my_image bash

и вы можете видеть, что это очень похоже на ОС.




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

Типичные ограничения связаны с технологической изоляцией, связанными с безопасностью (например, с использованием защиты SELinux) и связанными с системным ресурсом (память, диск, процессор, сеть).

До недавнего времени только ядра в Unix-системах поддерживали возможность запускать исполняемые файлы под строгими ограничениями. Вот почему большинство сегодняшних обсуждений в контейнерах включает в основном Linux или другие дистрибутивы Unix.

Docker является одним из тех приложений, которые знают, как сообщить ОС (в основном Linux), какие ограничения запускать исполняемый файл. Исполняемый файл содержится в изображении Docker, которое является только tarfile. Этот исполняемый файл обычно представляет собой усеченную версию дистрибутива Linux (Ubuntu, centos, Debian и т. Д.), Предварительно сконфигурированную для запуска одного или нескольких приложений внутри.

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

Другие приложения, которые, например, Docker, могут указать ОС хоста, границы которых применяются к процессу во время работы, включают LXC , libvirt и systemd . Docker использовал эти приложения для косвенного взаимодействия с ОС Linux, но теперь Docker взаимодействует напрямую с Linux, используя собственную библиотеку под названием « libcontainer ».

Таким образом, контейнеры - это просто процессы, запущенные в ограниченном режиме, подобно тому, как это делал chroot .

IMO, что отличает Docker от других технологий контейнеров, - это его хранилище (Docker Hub) и их инструменты управления, которые делают работу с контейнерами чрезвычайно простой.

См. https://en.m.wikipedia.org/wiki/Docker_(Linux_container_engine)




Из моей статьи « Автоматизация развертывания докеров» :

Docker Images против контейнеров

В Dockerland есть изображения и есть контейнеры . Эти два тесно связаны, но отличаются друг от друга. Для меня, схватив эту дихотомию, яростно прояснил Докера.

Что такое изображение?

Изображение представляет собой инертный, неизменный файл, который по сути является снимком контейнера. Изображения создаются с помощью команды build , и они будут создавать контейнер при запуске с run . Изображения хранятся в реестре Docker, например, registry.hub.docker.com . Поскольку они могут стать довольно большими, изображения предназначены для того, чтобы состоять из слоев других изображений, позволяя при передаче изображений по сети получать сообщение со значительным количеством данных.

Локальные изображения можно указать, запустив docker images :

REPOSITORY                TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
ubuntu                    13.10               5e019ab7bf6d        2 months ago        180 MB
ubuntu                    14.04               99ec81b80c55        2 months ago        266 MB
ubuntu                    latest              99ec81b80c55        2 months ago        266 MB
ubuntu                    trusty              99ec81b80c55        2 months ago        266 MB
<none>                    <none>              4ab0d9120985        3 months ago        486.5 MB

Некоторые примечания:

  1. Идентификатор IMAGE - это первые 12 символов истинного идентификатора для изображения. Вы можете создать много тегов данного изображения, но их идентификаторы будут одинаковыми (как указано выше).
  2. VIRTUAL SIZE является виртуальным, потому что он объединяет размеры всех отдельных слоев. Это означает, что сумма всех значений в этом столбце, вероятно, намного больше, чем дисковое пространство, используемое всеми этими изображениями.
  3. Значение в столбце REPOSITORY исходит от флага -t команды docker build докеров или от docker tag - к существующему изображению. Вы можете пометить изображения, используя номенклатуру, которая имеет для вас смысл, но знайте, что докер будет использовать тег в качестве места регистрации в docker push или docker pull .
  4. Полная форма тега - [REGISTRYHOST/][USERNAME/]NAME[:TAG] . Для ubuntu выше, REGISTRYHOST вызывается как registry.hub.docker.com . Поэтому, если вы планируете хранить изображение под именем my-application в реестре на docker.example.com , вы должны пометить это изображение docker.example.com/my-application .
  5. Столбец TAG - это только часть [: TAG] полного тега. Это печальная терминология.
  6. latest тег не волшебный, это просто тег по умолчанию, когда вы не указываете тег.
  7. Вы можете иметь непомеченные изображения, которые можно идентифицировать только с помощью идентификаторов IMAGE. Они получат <none> TAG и REPOSITORY. Легко забыть о них.

Более подробную информацию о изображениях можно найти в документах и glossary Docker .

Что такое контейнер?

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

Просмотр локальных запущенных контейнеров с docker ps :

CONTAINER ID        IMAGE                               COMMAND                CREATED             STATUS              PORTS                    NAMES
f2ff1af05450        samalba/docker-registry:latest      /bin/sh -c 'exec doc   4 months ago        Up 12 weeks         0.0.0.0:5000->5000/tcp   docker-registry

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

  1. Идентификатор контейнера, как идентификатор IMAGE, является истинным идентификатором контейнера. Он имеет ту же форму, но он идентифицирует другой тип объекта.
  2. docker ps выводит только запущенные контейнеры. Вы можете просмотреть все контейнеры ( запущенные или остановленные ) с помощью docker ps -a .
  3. NAMES могут использоваться для идентификации запущенного контейнера с --name флага --name .

Как избежать наращивания изображений и контейнеров?

Одним из моих ранних разочарований с Docker было, по- видимому, постоянное наращивание немаркированных изображений и прекращение контейнеров . В течение нескольких эпизодов это наращивание привело к тому, что жесткие диски с максимальной производительностью замедляли мой ноутбук или останавливали мой автоматизированный трубопровод сборки. Расскажите о «контейнерах везде»!

Мы можем удалить все немаркированные изображения, объединив docker rmi с последним dangling=true :

docker images -q --filter "dangling=true" | xargs docker rmi

Docker не сможет удалять изображения, которые находятся за существующими контейнерами, поэтому вам может потребоваться сначала удалить остановленные контейнеры с docker rm :

docker rm `docker ps --no-trunc -aq`

Это известные болевые точки с Docker и могут быть рассмотрены в будущих выпусках. Однако при четком понимании изображений и контейнеров эти ситуации можно избежать с помощью нескольких практик:

  1. Всегда удаляйте бесполезный контейнер с docker rm [CONTAINER_ID] .
  2. Всегда удаляйте изображение за бесполезным, остановленным контейнером с docker rmi [IMAGE_ID] .



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

Изображения показывают состояние контейнера в каждый момент времени. Таким образом, основной рабочий процесс:

  1. создать изображение
  2. запустить контейнер
  3. вносить изменения в контейнер
  4. сохранить контейнер обратно как изображение



Изображение Docker собирает приложение и среду, необходимые для запуска приложения, а контейнер - это исполняемый экземпляр изображения.

Изображения - это упаковочная часть докера, аналогичная «исходному коду» или «программе». Контейнеры являются исполняющей частью докера, аналогичной «процессу».

В этом вопросе упоминается только часть «программы», и это изображение. «Бегущая» часть докера - это контейнер. Когда контейнер запускается и изменения производятся, это как если бы процесс внес изменения в собственный исходный код и сохраняет его как новое изображение.




Возможно, объяснение всего рабочего процесса может помочь.

Все начинается с файла Docker . Файл Docker является исходным кодом изображения.

После создания файла Dockerfile вы создадите его для создания изображения контейнера. Изображение - это просто «скомпилированная версия» «исходного кода», которая является файлом Docker.

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

Затем вы можете использовать изображение для запуска контейнеров . Бегущий контейнер очень похож, во многих отношениях, на виртуальную машину (но без hypervisor ).

В этом сообщении объясняются многие основные вещи о контейнерах докеров (речь идет о Docker и Puppet, но есть много концепций, которые можно использовать в любом контексте)




Я не мог понять концепцию изображения и слоя, несмотря на то, что читал здесь все вопросы, а затем в конце концов наткнулся на эту отличную документацию от Docker (duh!).

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

  • Изображение : изображение Docker создается из серии уровней только для чтения

  • Layer : Каждый уровень представляет собой команду в файле Docker.

Example : ниже Dockerfile содержит четыре команды, каждая из которых создает слой.

ОТ ubuntu: 15.04

КОПИРОВАТЬ. /приложение

RUN make / app

CMD python /app/app.py

Важно отметить , что каждый слой представляет собой только набор отличий от слоя перед ним.

  • Контейнер . Когда вы создаете новый контейнер, вы добавляете новый слой для записи поверх нижних слоев . Этот слой часто называют «контейнерным слоем». Все изменения, внесенные в запущенный контейнер, такие как запись новых файлов, изменение существующих файлов и удаление файлов, записываются на этот тонкий перезаписываемый контейнерный слой.

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

Понимание изображений cnd Контейнеры с точки зрения размера на диске

Чтобы просмотреть приблизительный размер работающего контейнера, вы можете использовать команду docker ps -s . Вы получаете size и virtual size как два из выходов:

  • Размер: количество данных (на диске), которое используется для записываемого слоя каждого контейнера

  • Виртуальный размер: объем данных, используемых для данных изображения только для чтения, используемых контейнером. Несколько контейнеров могут совместно использовать некоторые или все данные изображения только для чтения. Следовательно, они не являются аддитивными. Т.е. вы не можете добавить все виртуальные размеры, чтобы рассчитать, сколько размера на диске используется изображением

Еще одна важная концепция - стратегия копирования на запись

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

Надеюсь, это поможет кому-то другому, как я.




Dockerfile похож на ваш сценарий bash, который создает tarball (изображение Docker).

Контейнеры-докеры похожи на извлеченную версию tarball. Вы можете иметь столько копий, сколько захотите, в разных папках (контейнерах)




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





docker docker-container docker-image