Під час використання Docker ми починаємо з базового зображення. Ми завантажуємо його, створюємо зміни, і ці зміни зберігаються в шарах, утворюючи інше зображення.
Отже, в кінцевому підсумку у мене є зображення для мого примірника PostgreSQL та зображення для мого веб-додатка, зміни якого продовжують зберігатися.
Що таке контейнер?
Відповіді:
Екземпляр зображення називається контейнером. У вас є зображення, яке представляє собою набір шарів, як ви описуєте. Якщо ви запускаєте це зображення, у вас є запущений контейнер цього зображення. Ви можете мати багато запущених контейнерів одного зображення.
Ви можете бачити всі ваші зображення, docker imagesтоді як ви можете бачити ваші запущені контейнери з docker ps(і ви можете бачити всі контейнери з docker ps -a).
Отже, запущений екземпляр зображення є контейнером.
З моєї статті про автоматизацію розгортання Docker :
У Докерленді є зображення, є контейнери . Два тісно пов'язані, але чіткі. Для мене розуміння цієї дихотомії надзвичайно прояснило Докера.
Зображення - це інертний, незмінний файл, який по суті є знімком контейнера. Зображення створюються за допомогою команди збірки , і вони будуть створювати контейнер при запуску із запуску . Зображення зберігаються в реєстрі Docker, таких як register.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
Деякі речі, які слід зазначити:
-tпрапора docker buildкоманди або від docker tag-ing наявного зображення. Ви можете тегувати зображення за допомогою номенклатури, яка має сенс для вас, але знайте, що докер використовуватиме тег як місце реєстру в docker pushабо docker pull.[REGISTRYHOST/][USERNAME/]NAME[:TAG]. Для ubuntuвищевикладеного, REGISTRYHOST вважається рівним registry.hub.docker.com. Отже, якщо ви плануєте зберігати ваше зображення, викликане my-applicationв реєстрі, на docker.example.com, ви повинні позначити це зображення docker.example.com/my-application.latestТег не чарівна, це просто тег за замовчуванням , якщо ви не вкажете тег.<none>TAG та REPOSITORY. Про них легко забути.Більш детальна інформація про зображення доступна в документації та словнику 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
Тут я запускаю докерізовану версію реєстру докерів, щоб у мене було приватне місце для зберігання зображень. І знову:
docker psвиводить тільки запущені контейнери. Ви можете переглядати всі контейнери ( запущені або зупинені ) за допомогою docker ps -a.--nameпрапор.Одним із моїх ранніх розчарувань у Докера було, здавалося б, постійне нарощування нетазованих зображень та зупинених контейнерів . За декілька випадків цього накопичення призвело до того, що змішані жорсткі диски сповільнили мій ноутбук або зупинили автоматизований конвеєр побудови. Говоріть про "контейнери скрізь"!
Ми можемо видалити всі немальовані зображення, поєднавши docker rmiз останнім dangling=trueзапитом:
docker images -q --filter "dangling=true" | xargs docker rmi
Докер не зможе видалити зображення, які стоять за існуючими контейнерами, тому вам, можливо, доведеться спочатку видалити зупинені контейнери docker rm:
docker rm `docker ps --no-trunc -aq`
Це відомі больові точки з Докером, і вони можуть бути вирішені в майбутніх випусках. Однак, маючи чітке розуміння зображень та контейнерів, цих ситуацій можна уникнути за допомогою кількох практик:
docker rm [CONTAINER_ID].docker rmi [IMAGE_ID].docker image pruneдля очищення звисаючих зображень. Зріжте невикористані предмети Докера
docker system pruneдля очищення ВСЕ
Легкими словами.
Зображення -
Файлова система та конфігураційна програма (лише для читання), яка використовується для створення контейнерів. Більш детально .
Контейнери -
Це запущені екземпляри зображень Docker. Контейнери запускають фактичні програми. Контейнер включає додаток та всі його залежності. Він поділяє ядро з іншими контейнерами і запускається як ізольований процес у просторі користувача на хост-OS. Більш детально .
Інші важливі умови, які слід помітити:
Декер Докер -
Фон-сервіс, що працює на хості, який керує будівництвом, запускає та розповсюджує контейнери Docker.
Докер-клієнт -
Інструмент командного рядка, що дозволяє користувачеві взаємодіяти з демоном Docker.
Докер-магазин -
Магазин - це, серед іншого, реєстр зображень Docker. Ви можете розглядати реєстр як каталог усіх доступних зображень Docker.
Малюнок із цієї публікації в блозі вартує тисячі слів.
(Для глибшого розуміння будь ласка, прочитайте це .)
Підсумок:
docker run image_name:tag_name) => Дає запущене зображення, тобто контейнер (для редагування)Хоча найпростіше думати про контейнер як про запущене зображення, це не зовсім точно.
Зображення - це справді шаблон, який можна перетворити на контейнер. Щоб перетворити зображення в контейнер, механізм Docker бере зображення, додає файлову систему зчитування і запису зверху та ініціалізує різні настройки, включаючи порти мережі, ім’я контейнера, ідентифікатор та обмеження ресурсів. У запущеному контейнері в даний час виконується процес, але контейнер також можна зупинити (або вийти з нього в термінології Докера). Вийшов контейнер - це не те саме, що зображення, оскільки його можна перезапустити і збереже його настройки та будь-які зміни файлової системи.
docker create.
Можливо, пояснення всього робочого процесу може допомогти.
Все починається з Dockerfile . Dockerfile - вихідний код зображення.
Після створення Dockerfile ви створюєте його для створення образу контейнера. Зображення є лише "складеною версією" "вихідного коду", який є Dockerfile.
Отримавши зображення контейнера, слід перерозподілити його за допомогою реєстру . Реєстр схожий на сховище Git - ви можете натискати та тягнути зображення.
Далі ви можете використовувати зображення для запуску контейнерів . Запущений контейнер багато в чому схожий з віртуальною машиною (але без гіпервізора ).
Ось поточний робочий процес, що показує різні команди та пов'язані з ними входи та виходи. Це повинно з’ясувати зв’язок між зображенням і контейнером.
+------------+ docker build +--------------+ docker run -dt +-----------+ docker exec -it +------+
| Dockerfile | --------------> | Image | ---------------> | Container | -----------------> | Bash |
+------------+ +--------------+ +-----------+ +------+
^
| docker pull
|
+--------------+
| Registry |
+--------------+
Щоб перелічити зображення, які можна було запустити, виконайте:
docker image ls
Щоб перерахувати контейнери, над якими можна виконувати команди:
docker ps
Я не міг зрозуміти концепцію зображення та шару, незважаючи на те, щоб прочитати тут усі питання, а згодом натрапив на цю чудову документацію від Докера (так!).
На прикладі дійсно є ключ до розуміння всієї концепції. Це довгий пост, тому я підсумовую ключові моменти, які потрібно дійсно зрозуміти, щоб отримати чіткість.
Зображення : зображення Докера складається з ряду шарів, доступних лише для читання
Шар : кожен шар являє собою інструкцію в Dockerfile зображення.
Example: Нижче Dockerfile містить чотири команди, кожна з яких створює шар.
ВІД ubuntu: 15.04
КОПІЯ / додаток
RUN make / app
CMD python /app/app.py
Важливо , що кожен шар - це лише сукупність відмінностей від шару перед ним.
Отже, основна відмінність контейнера від зображення - це верхній шар, що можна записати . Усі записи в контейнер, які додають нові або змінюють існуючі дані, зберігаються в цьому шарі, що можна записати. Коли контейнер видаляється, шар, що записується, також видаляється. Основне зображення залишається незмінним.
Розуміння зображень cnd-контейнерів з точки зору розміру на диску
Щоб переглянути приблизний розмір запущеного контейнера, ви можете скористатися docker ps -sкомандою. Ви отримуєте sizeі virtual sizeяк два виходи:
Розмір: кількість даних (на диску), які використовуються для записуваного шару кожного контейнера
Віртуальний розмір: кількість даних, що використовуються для даних зображення лише для читання, використовуваних контейнером. Кілька контейнерів можуть обмінюватися деякими або всіма зображеннями лише для читання. Отже, вони не є добавками. Тобто ви не можете додати всі віртуальні розміри, щоб обчислити, який розмір на диску використовується зображення
Ще одна важлива концепція - стратегія копіювання на запис
Якщо файл або каталог існує в нижньому шарі зображення, а інший шар (включаючи шар, що записується) потребує доступу до нього для читання, він просто використовує наявний файл. Перший раз, коли інший шар потребує зміни файлу (під час створення зображення або запуску контейнера), файл копіюється в цей шар і змінюється.
Я сподіваюся, що це допомагає комусь іншому, як я.
Докерфайл → (Збірка) → Зображення → (Виконати) → Контейнер .
Dockerfile : містить набір інструкцій Docker, який забезпечує вашу операційну систему так, як вам подобається, та встановлює / налаштовує все ваше програмне забезпечення.
Зображення : складений Dockerfile. Економить ваш час від відновлення Dockerfile кожного разу, коли потрібно запустити контейнер. І це спосіб приховати ваш код надання.
Контейнер : сама віртуальна операційна система. Ви можете схилитись до нього і виконувати будь-які команди, які ви хочете, як ніби це реальна середовище. Ви можете запускати 1000+ контейнерів з одного зображення.
Контейнер - це лише виконуваний двійковий файл, який повинен запускатися хост-оператором під набором обмежень, які попередньо встановлені за допомогою програми (наприклад, Docker), яка знає, як сказати ОС, які обмеження слід застосувати.
Типові обмеження пов'язані з ізоляцією процесів, пов'язаними із захистом (наприклад, із використанням захисту SELinux ) та системними ресурсами (пам'ять, диск, процесор та мережа).
До недавнього часу лише ядра в системах на базі Unix підтримували можливість запускати виконувані файли під суворими обмеженнями. Ось чому сьогодні більшість контейнерних розмов стосується переважно Linux або інших дистрибутивів Unix.
Docker - це одне з тих додатків, яке знає, як сказати ОС (здебільшого Linux) під якими обмеженнями для запуску виконуваного файлу. Виконавчий файл міститься в зображенні Docker, що є лише тарфілом. Цей виконуваний файл, як правило, є скороченою версією дистрибутива Linux (Ubuntu, CentOS, Debian тощо), попередньо налаштований для запуску одного або декількох додатків всередині.
Хоча більшість людей використовує базу Linux як виконуваний файл, але це може бути будь-яке інше бінарне додаток до тих пір, поки хост ОС може запустити його (див. Створення простого базового зображення за допомогою нуля ). Незалежно від того, чи є двійковим у зображенні Докера ОС або просто додаток, для хоста ОС це лише інший процес, який міститься в процесі, який визначається заздалегідь встановленими межами ОС.
Інші додатки, як Docker, можуть вказати хост-операційній системі, які межі застосовувати до процесу під час запуску, включають LXC , libvirt та systemd . Докер використовував ці програми для опосередкованої взаємодії з ОС Linux, але тепер Докер безпосередньо взаємодіє з Linux, використовуючи власну бібліотеку під назвою " libcontainer ".
Отже контейнери - це просто процеси, що працюють в обмеженому режимі, подібно до того, що робив chroot .
IMO, що відрізняє Docker від будь-якої іншої технології контейнерів, є його сховищем (Docker Hub) та їх інструментами управління, що робить роботу з контейнерами надзвичайно просто.
Основна концепція Докера полягає у спрощенні створення "машин", які в даному випадку можна вважати контейнерами. Контейнер допомагає в повторному використанні, що дозволяє створювати та випускати контейнери з легкістю.
Зображення зображують стан контейнера в кожний момент часу. Отже, основний робочий процес:
Як багато відповідей вказували на це: Ви будуєте Dockerfile, щоб отримати зображення, і запускаєте зображення, щоб отримати контейнер .
Однак наступні кроки допомогли мені краще відчути, що таке зображення та контейнер Docker:
1) Створіть 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, і ви побачите всі шари. Якщо зануритися глибше в кожен шар, то можна побачити, які зміни були додані в кожному шарі. (Вони повинні бути досить близькими до команд у Dockerfile).
3) Щоб заглянути в контейнер, ви можете:
sudo docker run -it my_image bash
і ви бачите, що це дуже схоже на ОС.
Зображення є еквівалентом визначення класу в OOP, а шари - це різні методи та властивості цього класу.
Контейнер - це фактична інстанція зображення, подібно до того, як об'єкт є екземпляром або екземпляром класу.
Я думаю, що краще пояснити на початку.
Припустимо, ви запускаєте команду docker run hello-world. Що сталося?
Він викликає Docker CLI, який відповідає за прийняття команд Docker та перетворення на виклик команд сервера Docker . Як тільки сервер Docker отримує команду запустити зображення , він перевіряє погоду, кеш зображень містить зображення з таким ім'ям.
Припустимо, привіт-світ не існує. Сервер Docker переходить до Docker Hub (Docker Hub - це просто безкоштовне сховище зображень) і запитує, ей Хаб, чи є у вас зображення, яке називається hello-world? Відповіді Hub - так, я. Тоді дайте мені, будь ласка. І процес завантаження починається. Як тільки завантажується зображення Докера, сервер Docker поміщає його в кеш зображень .
Отже, перш ніж ми пояснимо, що таке зображення Docker та контейнери Docker, почнемо з вступу про операційну систему на вашому комп’ютері та про те, як вона працює з програмним забезпеченням.
При запуску, наприклад, Chrome на своєму комп’ютері, він викликає операційну систему, операційна система сама викликає ядро і запитує, ей, я хочу запустити цю програму. Ядро вдається запустити файли з вашого жорсткого диска.
А тепер уявіть, що у вас є дві програми, Chrome і Node.js. Для запуску Chrome потрібна версія Python 2, а Node.js для запуску версії 3 Python. Якщо на комп'ютері встановлено лише Python v2, запускається лише Chrome.
Для того, щоб обидва випадки спрацювали, потрібно якось використовувати функцію операційної системи, відому як простір імен. Простір імен - це функція, яка дає вам можливість ізолювати процеси, жорсткий диск, мережу, користувачів, імена хостів тощо.
Отже, коли ми говоримо про зображення, ми фактично говоримо про знімок файлової системи. Зображення являє собою фізичний файл , який містить інструкції і метадані для побудови конкретного контейнера . Сам контейнер - це екземпляр зображення ; він ізолює жорсткий диск за допомогою простору імен, який доступний лише для цього контейнера . Отже контейнер - це процес або сукупність процесів, які групують різні призначені йому ресурси.
Зображення Docker пакує додаток та середовище, необхідні для запуску програми, а контейнер є запущеним екземпляром зображення.
Зображення - це частина упаковки Docker, аналогічна "вихідному коду" або "програмі". Контейнери - це частина виконання Докера, аналог "процесу".
У питанні згадується лише «програмна» частина, і це зображення. "Запуск" частини Докера є контейнером. Коли контейнер запускається і вносяться зміни, це ніби процес вносить зміни у власний вихідний код і зберігає його як нове зображення.
Як і в аспекті програмування,
Зображення - це вихідний код.
Коли вихідний код складається і складається, він називається додатком.
Аналогічно тому, "коли для зображення створюється екземпляр", він називається " контейнер ".
Зображення є «моментальний знімок» з контейнера . Ви можете створювати зображення з контейнера (нові "знімки"), а також можете запускати нові контейнери із зображення (створювати "знімок").
Наприклад, ви можете створити екземпляр нового контейнера з базового зображення, виконати кілька команд у контейнері, а потім зробити знімок, як новий образ. Тоді ви можете запустити 100 контейнерів із цього нового зображення.
Інші речі, які слід врахувати:
docker images.Я хотів би заповнити пропущену частину тут між docker imagesі containers. Docker використовує файлову систему об'єднання ( UFS ) для контейнерів, яка дозволяє встановити декілька файлових систем в ієрархію та з'являтися як єдина файлова система. Файлову систему із зображення встановлено як read-onlyшар, а будь-які зміни в запущеному контейнері вносяться до read-writeшару, встановленого поверх цього. Через це Докер повинен лише переглянути найвищий шар читання-запису, щоб знайти зміни, внесені до запущеної системи.
Для аналогії фіктивного програмування ви можете подумати про те, що Docker має абстрактний ImageFactory, який містить ImageFactories, які вони надходять з магазину .
Потім, як тільки ви захочете створити додаток із цього ImageFactory, у вас з’явиться новий контейнер, і ви зможете його змінити, як вам захочеться. DotNetImageFactory буде непорушним, оскільки він виступає як абстрактний заводський клас, де він надає лише бажані вам випадки.
IContainer newDotNetApp = ImageFactory.DotNetImageFactory.CreateNew(appOptions);
newDotNetApp.ChangeDescription("I am making changes on this instance");
newDotNetApp.Run();
Коротко:
Контейнер - це поділ (віртуальний) в ядрі, яке розділяє загальну ОС і запускає зображення (зображення Докера).
Контейнер - це самостійкий додаток, який буде мати пакети та всі необхідні залежності для запуску коду.
Контейнер Docker виконує екземпляр зображення. Ви можете пов'язати зображення з програмою та контейнером з процесом :)