Я знаю, что контейнеры используют ядро хоста, и, насколько я понимаю, именно поэтому нам не нужна ОС. Мои вопросы (и я не нашел хорошего объяснения в Интернете):
1) Если это так, то получим ли мы приглашение оболочки и как у нас есть такие вещи, как systemctl, services и т. Д. В контейнере
2) Как установить контейнер CentOS, например, на хост Ubuntu? в этом случае у контейнера установлена ОС в образе контейнера?
Это во многом зависит от того, что вы думаете о O.S. является.
По сути, контейнеры - это метод изоляции как запущенного процесса от всех других процессов на машине, так и двоичного файла и всех его зависимостей от файловой системы хост-машины. Это упрощает их перемещение и запуск на любом количестве машин. Они никоим образом не являются виртуализацией, поэтому, как вы упомянули в своем вопросе, любой процесс, запущенный в контейнере, выполняется на ядре хост-машины. С некоторых точек зрения операционная система - это, по сути, ядро.
Уравновешивается это тем, что большая часть программного обеспечения не строится как монолитное, а вместо этого связывается во время компиляции с любым количеством разделяемых библиотек. Итак, когда вы устанавливаете дистрибутив операционной системы, а также ядро, вы получаете целый ряд библиотек и утилит, а также любые программы, которые вы устанавливаете из ОС. репозитории будут построены на основе библиотек, поставляемых с этим дистрибутивом ОС.
Теперь при сборке контейнера все, что требуется это двоичный файл, который вы хотите запустить, плюс все, от чего зависит этот двоичный файл. Нет необходимости упаковывать полную версию O.S. файловая система дистрибутива. Если ваш двоичный файл не связан с какой-либо другой библиотекой, вы можете почти полностью отказаться от одного двоичного файла и ничего больше. Посмотрите этот проект https://github.com/davidcarboni-archive/ddd написано человеком, который работает с тем же клиентом, что и я, что демонстрирует, как мало требуется для создания функционального контейнера.
Таким образом, в идеальном мире, учитывая, что передовой практикой в основном является создание контейнера, который запускает один процесс, каждый контейнер будет состоять из ничего, кроме соответствующего двоичного файла, а также любых необходимых ему библиотек, файлов конфигурации и рабочих каталогов. Однако во многих случаях это довольно сложный и трудоемкий процесс. Поэтому теперь стало очень распространенным шаблоном просто упаковать всю файловую систему из донорской ОС в контейнер, так как таким образом вы знаете, что будут присутствовать любые зависимости, которые имеет запускаемый процесс. Это также добавляет удобство, означающее, что будут присутствовать инструменты управления пакетами, что упрощает создание контейнера. Это также означает, что также присутствуют такие утилиты, как оболочки, что упрощает отладку контейнера (хотя, по мнению некоторых людей, кроме, возможно, когда вы разрабатываете новый образ контейнера, если вам нужно получить доступ к оболочке внутри контейнера, Ты делаешь это неправильно).
Хотя я понимаю, почему этот шаблон стал настолько распространенным, я все же думаю, что у него есть недостатки. Сначала продемонстрировал ваш вопрос - он сделал контейнеры очень похожими на виртуализацию и, таким образом, посеял много путаницы. Более того, поскольку человек, который только что закончил применять усиление защиты серверов CIS к большому количеству машин, упаковывая все, включая кухонную раковину, в каждый контейнер, не кажется хорошей практикой безопасности, и я подозреваю, что в какой-то момент это может вернуться к укусите нас.
Чтобы расширить ваши два конкретных вопроса:
1) Я уже обращался к теме снарядов. Что касается таких вещей, как systemd, по сути, им нет места в контейнере. Dockefile определяет процесс, запускаемый при запуске контейнера. Если вы пытаетесь запустить диспетчер служб и несколько служб внутри контейнера, вы, вероятно, делаете это неправильно.
2) Это снова вопрос о том, что такое ОС? Единственный смысл того, что вы устанавливаете данный дистрибутив в контейнер, заключается в том, что вы получаете файловую систему и, следовательно, копии дистрибутивов двоичных файлов и разделяемых библиотек. Это не то же самое, что виртуализация, когда у вас есть копия, скажем, Centos, запущенная на виртуальной машине на хосте, на котором работает, скажем, Debian.
Да, это так. Каждый контейнер основан на образе ОС, например Alpine, CentOS или Ubuntu.
Они просто используют общее ядро хоста, но запускают каждый процесс пользовательского пространства в отдельном пространстве имен, специфичном для этого контейнера.
Посмотрите в пример dockerfile (адаптировано мной), чтобы понять это:
FROM ubuntu
MAINTAINER Kimbro Staken version: 0.1
RUN apt-get update && apt-get install -y apache2 && apt-get clean && rm -rf /var/lib/apt/lists/*
ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2
EXPOSE 80
CMD ["/usr/sbin/apache2", "-D", "FOREGROUND"]
Это указывает Docker создать контейнер из базового образа Ubuntu (последняя версия, если версия не указана), установить и запустить в нем Apache и открыть порт 80 для ОС хоста.
Что такое ОС?
Ядро Linux само по себе удовлетворяет большинству ключевых требований к операционной системе. Он разделяет ЦП по времени, управляет вводом-выводом консоли, дисковым вводом-выводом и сетью, он может предоставить аппаратно-независимый кадровый буфер для вывода графики и так далее. Вы жестяная банка напишите программу, которая работает на ядре Linux без загруженных библиотек и использует эти возможности.
Однако, говоря о современных операционных системах общего назначения, большинство людей имеет гораздо более широкое представление о том, что такое ОС. В дополнение к ядру они включают множество других вещей. Оболочка, система инициализации, X-сервер, общие библиотеки, система загрузки модулей драйверов, поэтому вам не нужно встраивать все драйверы в ядро, инструменты для подключения сетевых интерфейсов, инструменты для монтирования дополнительных файлов. -системы, менеджер пакетов и так далее. В совокупности мы называем эти части, которые используются в дополнение к ядру для создания современной ОС, «пользовательской средой».
Большая часть идентичности дистрибутива Linux происходит от пользователя. Если у вас есть пользовательская среда Centos, работающая на ядре Ubuntu, она будет больше похожа на Centos, чем на Ubuntu.
Контейнеры - это функция, которая позволяет одному ядру притворяться несколькими отдельными ядрами. У каждого есть свои PID, своя собственная файловая система, свои сетевые интерфейсы и собственные учетные записи пользователей.
Как и в реальной системе с ядром Linux, вы можете написать программу, которая работает в контейнере без поддержки. Действительно, в контейнере это проще, чем в реальной системе, потому что вам не нужно беспокоиться о драйверах, и ваш контейнер-менеджер может иметь возможность предварительно инициализировать контейнер, чтобы правильные файловые системы уже были смонтированы, а сетевые интерфейсы уже подключены.
Но в большинстве случаев от контейнеров хотят «виртуализации, но дешевле». Они хотят разделить логические функции сервера, чтобы для каждого из них можно было выполнять резервное копирование, перенос, обновление и т. Д. По отдельности, но они хотят продолжать использовать стек программного обеспечения, который они используют, который использует преимущества некоторых или всех вышеупомянутых не- части ядра современной ОС, и они не хотят платить за виртуальные машины.
Таким образом, контейнеры часто в конечном итоге содержат всю пользовательскую среду обычного дистрибутива Linux. В комплекте с системой инициализации, оболочкой, ssh-сервером. Считается ли это ОС? ну, в конечном счете, вопрос в том, как вы определяете ОС!
1) Если это так, то получим ли мы приглашение оболочки и как у нас есть такие вещи, как systemctl, services и т. Д. В контейнере
Вы можете использовать контейнер полного образа ОС, несколько примеров:
все предыдущие образы являются официальными образами, что означает, что они поддерживаются той же группой, обслуживающей ОС. Запустив этот образ, вы запускаете всю ОС, и они работают на ЛЮБОМ хосте Linux.
Получить доступ к подсказке можно двумя способами:
Для второго метода вы должны открыть порт 22 для внешнего слова.
2) Как установить контейнер CEntOS, например, на хост Ubuntu? в этом случае у контейнера установлена ОС в образе контейнера?
Запустить контейнер CEntOS в среде докеров очень просто, просто установите докер и запустите:
docker run --rm -p 2020:22 -v vol_data:/data centos:7
Предыдущая команда:
--rm-p 2020:22 (это позволяет избежать конфликта на уже используемом хост-порту.vol_data и смонтируйте его внутри контейнера в / datacentos:7Чтобы запустить systemd внутри контейнера, на странице Docker Hub образа будет описано, как это сделать.
Еще один способ достичь своей цели, о котором вы могли бы подумать, используя machinectl (должен быть частью systemd, не уверен в этом), вот ссылка: https://www.freedesktop.org/software/systemd/man/machinectl.html
Конечно, вы также можете использовать среду chroot, но вы должны делать все это постепенно, и это не очень удобно для реализации.
Чтобы прояснить один момент относительно ОС, операционная система - это среда, готовая к использованию (графический интерфейс или нет), поэтому ядро является одной из многих частей операционной системы, короче говоря, да, внутри образа контейнера у вас будет ОС которые просто не имеют прямого доступа к физическому оборудованию, можно сказать вообще без оборудования. Образ контейнера, предназначенный для запуска только службы, представляет собой минимальную установку компонентов, необходимых для запуска этой конкретной службы (в любом случае может быть расширен).
Чтобы лучше понять, что такое ОС и все ее части (конечно, ОС Linux), предлагаю вам взглянуть Проект LFS.
да, каждый образ докера создается поверх базового образа. первая инструкция в файле dockerfile определяет базовый образ, который будет использоваться для создания нового образа докера. скажем, вы хотите построить на ОС CentOS. затем используйте ниже
Он инструктирует Docker создать образ с использованием centos в качестве базового образа FROM centos: latest
Они есть, но эти ОС являются эмуляциями ОС, а не настоящей ОС.
Чтобы понять разницу, мы должны вспомнить архитектуру ОС, например любой вариант Unix (будь то AIX, Linux, SVR4, Solaris, SunOS и т. д.) или Windows. Ядром каждой ОС является так называемая исполнительная система реального времени, которая управляет всеми доступными ресурсами, такими как память, ЦП, файловая система, сетевые ресурсы, драйверы потоков и т. Д., И распределяет их оптимальным образом для запущенных программ (процессов, задач). Исполнитель реального времени также называется ядром. Например, когда вы создаете новые разновидности дистрибутивов Linux, вы, по сути, выполняете «сборку ядра», то есть настраиваете ядро для этого конкретного дистрибутива).
Следовательно, у ОС есть пространство ядра, пространство пользователя и интерфейс между ними. Прикладные программы запускаются в пользовательском пространстве как процессы или задачи, а также могут напрямую связываться с пространством ядра через системные вызовы (например, sysctl () в Unix). Интерфейс между пространством пользователя и пространством ядра в контейнерах реализован иначе, чем в виртуальных машинах. В виртуальных машинах этот интерфейс реализован так же, как и на любой другой платформе с этой ОС. В контейнерах реализация этого интерфейса использует базовое пространство ядра ОС, то есть базовое ядро ОС может отличаться от ОС, эмулируемой в пользовательском пространстве. Демон контейнера запускается в пользовательском пространстве ОС хоста и переводит все системные вызовы из ОС контейнеров в системные вызовы ОС хоста и наоборот. Короче говоря, в контейнерах пространство ядра их ОС эмулируется, а в виртуальных машинах - нет.