Введение в Docker мониторинг
В нашей компании мы часто используем докер, и поэтому решили перевести статью и пролить немного света на тему мониторинга ресурсов.
Мониторинг Docker окружения – непростая задача. Ведь каждый контейнер запускается в одном процессе, имеет свою собственную среду, использует виртуальные сети или имеет различные методы управления системами хранения. Традиционные решения для мониторинга контролируют метрики каждого сервера и приложения, на котором они запущены. Серверы и приложения, работающие на них, как правило, статичны, т.е. работают непрерывно. Docker формирует различные наборы контейнеров и может запускать множество приложений, совместно использующих ресурсы одного или нескольких хостов. Docker под силу запускать тысячи «временных» контейнеров (например, для пакетных заданий), параллельно осуществляя работу набора постоянных служб в штатном режиме.
Традиционные инструменты мониторинга не используются для динамических сред и не подходят для таких задач. С другой стороны, некоторые современные системы мониторинга (например, SPM от Sematex) были созданы для динамических систем и поддерживают средства для мониторинга и отчётов Docker «из коробки». Кроме того, совместное использование ресурсов контейнера предусматривает строгое соблюдение ограничений на использование ресурсов, которое необходимо контролировать.
Для того чтобы внести соответствующие изменения в квоты ресурсов, необходимо видеть каких ограничений достиг контейнер сейчас, и какие ошибки это вызывает (может вызвать). Мы рекомендуем использовать оповещения в соответствии с настроенными лимитами. Таким образом вы можете установить лимиты или настроить использование ресурсов ещё до того, как появятся ошибки.
Docker контейнеры ≠ VMs или серверы. Забудьте про старый «дедушкин мониторинг» — используйте мониторинг, предназначенный для Docker.
Все изображения в этой статье из инструмента мониторинга SPM производителя Sematext и его интеграции для мониторинга Docker
Контролируйте ресурсы вашей Docker машины
Процессор
Информация об утилизации CPU хостов помогает оптимизировать использование ресурсов Docker машины. Использование CPU может быть уменьшено для того, чтобы избежать ситуации, когда один контейнер занимает все процессорное время, замедляя работу других контейнеров. Уменьшение процессорного времени является хорошим способом обеспечить минимум вычислительных мощностей для всех сервисов — это как старые добрые уровни в Unix/Linux.
Даже когда использование ресурсов оптимизировано, все же могут возникать ситуации, когда загрузка процессора близка к максимуму. Оповещения имеют смысл только в случае, когда утилизация процессора падает (происходит сбой в работе службы) или в течение длительного периода увеличивается до некоторого максимального предела (например, 85%).
Сверхутилизация Docker машины является признаком неисправности.
Недоиспользование Docker машины является признаком того, что вы переплачиваете за неиспользуемые ресурсы.
Память
Для выполнения текущих операций и планирования мощностей необходимо знать общий объем используемой памяти каждым Docker хостом. Динамические кластер-менеджеры, такие как Docker Swarm, используют общий объем памяти, доступный на хосте, а также дополнительную запрашиваемую память для контейнеров, чтобы решить, на каком хосте лучше запустить контейнер. Приложения не получится развернуть, если кластер-менеджер не сможет найти хост с достаточными ресурсами для запуска контейнера. Поэтому важно знать об утилизации памяти хоста и ограничениях памяти контейнеров.
Регулировка мощности новых узлов кластера в соответствии с утилизацией приложений Docker может помочь оптимизировать использование ресурсов.
Linux не перерасходует оперативную память. Однако когда буфер кэшируются, памяти не остается, а значит необходимо расширить кластер.
Дисковое пространство
Образы Docker и контейнеры потребляют дополнительное дисковое пространство. Например, образ приложения может включать в себя операционную систему Linux и иметь размер 150-700 Мб в зависимости от размера базового образа и установленных инструментов в контейнере. Постоянные Docker тома также потребляют дисковое пространство на хосте. По нашему опыту, наблюдение за дисковым пространством и применение инструментов очистки диска обязательно при постоянной эксплуатации Docker машины.
Хорошие дети убирают в комнате.
Хорошие Docker OPS убирают со своих дисков неиспользуемые контейнеры и образы.
Использование дискового пространства на Docker хосте
Поскольку необходимо всегда иметь запас дискового пространства, важно установить оповещения на использование дискового пространства, чтобы они предупреждали о нехватке места и обеспечили достаточное время для очистки дисков или возможности добавить дополнительный объем. Например, SPM автоматически устанавливает правила уведомления использования дискового пространства и вам не нужно больше помнить об этом.
Периодически выполнять задачи по очистке диска, удаляя неиспользуемые контейнеры и образы — хорошая практика.
Общее количество запущенных контейнеров
Текущее и накопленное количество контейнеров является интересной метрикой по многим причинам. Очень удобно во время развертывания и обновлений проверять, что все работает, как и раньше. Когда кластер-менеджеры, такие как Docker Swarm, Mesos, Kubernetes, CoreOS/Fleet, автоматически планируют запуск контейнера на разных компьютерах, используются разные политики планирования. Количество контейнеров, работающих на каждой машине может помочь проверить активированные политики планирования на ней. Гистограмма ниже показывает количество контейнеров на каждой машине и общее число контейнеров, демонстрируя как кластер-менеджер распределил контейнеры по доступным машинам.
Количество контейнеров с течением времени
Контроль нештатного поведения, в отличие от оповещений на основе пороговых значений, позволит «поймать» внезапные миграции контейнера, что может являться предвестником серьёзного сбоя.
Данная метрика использует различные «модели» в зависимости от варианта применения. Например, пакетные операции, выполняющиеся посредством контейнеров, в сравнении с работающей постоянно службой, формируют модель, представляющую собой множество контейнеров. Пакетные операции обычно запускают контейнер по требованию или периодически, и контейнер с этими операциями завершается через относительно короткое время. В таком случае можно было бы увидеть большой разброс в количестве работающих контейнеров, в результате чего метрики контейнеров отобразят пиковые значения.
С другой стороны, постоянно работающие сервисы, такие как веб-серверы или базы данных, как правило, функционируют до тех пор, пока они не будут перезапущены во время обновления программного обеспечения. Хотя механизмы масштабирования могут увеличить или уменьшить количество контейнеров в зависимости от нагрузки, трафика и других факторов, при расчете метрики как правило, будет учитываться относительно устойчивый контейнер, так как в таких случаях контейнеры часто добавляются и удаляются более постепенно. Из-за этого нет общего шаблона, который мы могли бы использовать по умолчанию для правил оповещения о количестве запущенных контейнеров в Docker.
Тем не менее, оповещения на основе обнаружения нештатного поведения контейнеров, которые обнаруживают внезапные изменения количества контейнеров в общей сложности (или для определенных хостов) в коротком временном периоде очень удобны в большинстве случаев. Простые предупреждения на основе пороговых значений имеют смысл лишь когда максимальное или минимальное количество запущенных контейнеров известно и, в динамическом окружении, масштабируется вверх и вниз на основе внешних факторов. Но зачастую это не так.
Метрики Docker контейнеров
Метрики контейнеров в основном те же показатели, что и доступные для каждого процесса Linux параметры, но они включают в себя ограничения, установленные с помощью контрольных групп в Docker, такие как ограничение для использования CPU или памяти. Обратите внимание, что сложные решения для мониторинга Docker, такие как SPM, способны агрегировать метрики контейнера на разных уровнях Docker хостов/узлов кластера, названиях или ID образов и название или ID контейнера.
Такие возможности позволяют легко отслеживать использование ресурсов хоста, типов приложений (имен образов) или специальных контейнерах. В следующих примерах, приведены параметры которые мы могли использовать для агрегирования данных на различных уровнях.
Используйте современные решения для мониторинга Docker, чтобы получить продольные и поперечные срезы хоста, узла, образа или контейнера.
Контейнер CPU — 100% утилизация CPU
Одним из самых основных метрик является информация о том, сколько CPU потребляется всеми контейнерами вместе, образами, или отдельными контейнерами. Большим преимуществом использования Docker является возможность ограничить загрузку процессора по контейнерам. Конечно, вы не можете настроить и оптимизировать что-то, если вы не измеряете это, поэтому мониторинг таких ограничений является необходимым условием. Наблюдая за общими метриками загрузки CPU контейнерами, стало понятно, что CPU был утилизирован почти на 100%, поэтому необходимо настроить параметры для совместного использования процессоров в Docker.
Обратите внимание, что CPU имеет высокую утилизацию только тогда, когда использование хост-процессора максимизировано. До тех пор, пока у хоста есть запасные мощности CPU, доступные для Docker, он не уменьшит использование процессора для контейнера. Таким образом, повышенная утилизация CPU или нулевая является пиком этой метрики, и как правило, это является хорошим показателем одного или нескольких контейнеров, требующих большей мощности процессора, чем хост может обеспечить.
Использование CPU, контейнер использовал все процессорное время
На следующем снимке показаны контейнеры с квотой 5% CPU, запущенные с помощью команды docker run -cpu-quota=5000 nginx. Отчётливо видно, как утилизация CPU растет, пока не достигнет порога примерно в 5%.
Использование CPU контейнером, и утилизация процессорного времени CPU при квоте 5%
Контейнер памяти — счетчик сбоев
Установка лимитов памяти для контейнеров — хорошая практика. Лимиты памяти помогают избежать проблем, когда контейнер, которому не хватает памяти, забирает всю доступную память из системы, обрекая «голодать» все другие контейнеры на этом сервере. Ограничения на ресурсы могут быть определены в команде запуска Docker. Например, -m 300M устанавливает верхний предел памяти для контейнера на уровне 300 МБ. Docker устанавливает метрику контейнера — счетчик сбоев памяти.
Этот счетчик увеличивается каждый раз, когда не удаётся выполнить распределение памяти — то есть, каждый раз, когда заранее установленное ограничение памяти достигает предела. Таким образом, пики в этой метрике указывают на один или несколько контейнеров, которым требуется больше памяти, чем было выделено изначально. Если процесс в контейнере завершается из-за этой ошибки, мы также можем увидеть событие нехватки памяти в Docker.
Счётчик ошибок памяти Docker показывает, когда контейнеру нужно больше памяти.
Пик в счетчике сбоев использования памяти является критическим событием, и оповещения могут помочь найти некорректные настройки ограничений потребления памяти или контейнеры, которые пытаются потреблять больше памяти, чем ожидалось изначально.
Использование памяти контейнером
Каждое приложение потребляет память в своем определенном объёме. Понимание необходимого объема памяти контейнеров приложений крайне важно для обеспечения стабильной работы окружения. Ограничение объема памяти для контейнеров позволяет убедиться, что приложения работают хорошо, без излишнего потребления памяти, которое может повлиять на другие контейнеры, находящиеся на этом же хосте.
Оптимальный подход в данном случае — настройка памяти в несколько итераций:
- Мониторинг использования памяти приложения в контейнере.
- Настройка лимитов памяти по результатам наблюдения.
- Продолжение мониторинга памяти, счётчика сбоев памяти и событий нехватки памяти.
Если нехватка памяти происходит, то может потребоваться увеличение лимитов памяти контейнера или отладка, чтобы найти причину высокого потребления памяти.
Использование памяти контейнером
Swap в контейнерах
Как и в памяти любого другого процесса, память какого-либо контейнера может быть выгружена на диск. Для приложений, таких как Elasticsearch или Solr, часто приходилось находить инструкции, чтобы отключить swap на Linux машине, но при запуске таких приложений на Docker это может быть сделано достаточно просто, необходимо добавить в команду запуска -memory-swap=-1.
Как быстро отключить Swapping в Docker – контейнере?
Используйте команду -memory-swap=-1
Контейнер swap, страницы памяти, и скорость подкачки
Контейнер дискового ввода/вывода
В Docker несколько приложений одновременно могут использовать одни и те же ресурсы. Таким образом, наблюдения за дисковой системой ввода/вывода помогают определить пределы для конкретных приложений и обеспечивают более высокую пропускную способность для критически важных приложений, таких как хранилища данных или веб-серверы. Например, утилизация дисковых операций ввода/вывода для пакетных операций достигает 100%, и в этом случае команда docker run -it -device-write-bps /dev/sda:1mb mybatchjob будет актуальна: она ограничит максимальную скорость записи на диск до 1 МБ/с.
Контейнер дискового ввода/вывода
Чтобы ограничить контейнер Docker от потребления всего вашего диска необходимо использовать команду -device-write-bps /dev/sda:1mb
Сетевые метрики контейнера
Мониторинг использования контейнерами сетевых ресурсов также достаточно сложная задача. По умолчанию все контейнеры используют ресурсы одной сети, или контейнеры могут быть связаны друг с другом, чтобы иметь свою подсеть на одном хосте. Тем не менее, когда речь идет о сети между контейнерами, работающими на разных компьютерах, требуется или наложение сетей или контейнеры могут разделить сеть одного хоста. Такое множество вариантов сетевых конфигураций может стать причиной возникновения сетевых ошибок.
К тому же ошибки или пропущенные пакеты – не единственные события, которые необходимо отслеживать. На сегодняшний день, большинство приложений сильно зависит от сети. Пропускная способность виртуальных сетей может стать узким местом, особенно для таких контейнеров, как балансировщики нагрузки. Кроме того, сетевой трафик может быть хорошим индикатором того, сколько приложений используются клиентами. Высокие пики на метриках свидетельствуют об отказах в обслуживании, проведении нагрузочного тестирования или сбоях в клиентских приложениях. Так что следите за сетевым трафиком — это полезная метрика во многих случаях.
Мониторинг сетевого трафика
Заключение
Теперь у вас есть главные показатели работы контейнеров Docker, на которых стоит сфокусировать внимание. Также не стоит забывать, что проведенный должным образом анализ поможет избежать многих трудностей при внедрении Docker на таких платформах как Docker Swarm, Docker Cloud, Docker Datacenter или любой другой платформе, поддерживающей контейнеры Docker.
Комментарии переводчика
Мы рекомендуем придерживаться следующих пороговых значений для выявления проблем:
- Процент свободного дискового пространства — обратите внимание на то, что если его значение упало ниже 15 процентов, то возникает опасность нехватки свободного места для хранения важных файлов операционной системы. Одно из очевидных решений в этом случае состоит в добавлении места на диске.
- Процент использования памяти — если это значение превышает 80 процентов, это указывает на недостаточный объем памяти. Очевидным решением в этом случае является добавление памяти.
- Процент загруженности процессора — если загруженность превышает 85 процентов, процессор перегружен, и серверу, возможно, требуется более быстрый процессор и пора задуматься о масштабировании или оптимизации производительности.
- Загрузка сетевого интерфейса — сеть перегружена, если выясняется, что используется более 70 процентов скорости сетевого канала. В случае сетевой карты со скоростью обмена 100 Мбит/с потребляемый траффик составляет 8,7 МБ/с (100 Мбит/с = 100 000 кбит/с = 12,5 МБ/с* 70 процентов). В подобной ситуации, возможно, придется установить более быструю сетевую карту или провести сегментирование сети.
Оригинал статьи http://govit.sys-con.com/node/3880796.
В docker’е существует встроенная команда, позволяющая увидеть сколько CPU, памяти, сетевых операций ввода-вывода (network I/O) и блочных операций ввода-вывода (block I/O) используют запущенные контейнеры. Давайте разберемся!
Знать, сколько ресурсов используется тем или иным docker-контейнером очень полезно. Вооружившись этими знаниями, можно планировать апгрейд существующих и разворачивать дополнительные docker-хосты, соответствующие используемым ресурсам. В перспективе это знание позволяет сэкономить серьезные деньги на инфраструктуре.
Все, что вам нужно сделать, — запустить команду docker stats на docker-хосте. Вывод команды будет примерно следующим:
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
1fbfd146c892 0.00% 7.562MiB / 15.57GiB 0.05% 58MB / 84.4MB 831kB / 0B 4
3e18760df407 0.03% 21.7MiB / 15.57GiB 0.14% 43.4MB / 56MB 17.5MB / 29.4MB 21
059c84d3606b 0.00% 7.52MiB / 15.57GiB 0.05% 87.7MB / 145MB 9.38MB / 0B 22
c7cff2a01c4b 3.00% 12.3MiB / 15.57GiB 0.08% 10GB / 4.71GB 340kB / 0B 20
d696ab70fe4b 0.00% 12.09MiB / 15.57GiB 0.08% 9.48GB / 4.41GB 532kB / 0B 20
54f2f9e5fb82 0.00% 17.88MiB / 15.57GiB 0.11% 96.8MB / 2.02GB 2.4MB / 0B 18
6f1b0479d00b 0.00% 13.32MiB / 15.57GiB 0.08% 38.6MB / 83.9MB 856kB / 0B 12
7e4e93b694fb 0.00% 8.777MiB / 15.57GiB 0.06% 162MB / 168MB 434kB / 0B 19
9b1d756a0b1e 0.00% 15.45MiB / 15.57GiB 0.10% 37.7MB / 83.4MB 1.78MB / 98.3kB 12
29d0cac48303 0.00% 15.27MiB / 15.57GiB 0.10% 39.2MB / 83.8MB 410kB / 3.07MB 12
124fae38e06c 0.00% 5.617MiB / 15.57GiB 0.04% 68.7MB / 99.9MB 1.07MB / 0B 4
809143ebbd38 0.00% 9.441MiB / 15.57GiB 0.06% 158MB / 165MB 651kB / 0B 19
2158ae2f51ab 2.25% 453.3MiB / 15.57GiB 2.84% 842MB / 64.5MB 1.3GB / 41.4GB 22
aaa9c93137b2 0.00% 10.22MiB / 15.57GiB 0.06% 343MB / 156MB 4.3MB / 0B 19
e917f287bb0c 0.00% 10.77MiB / 15.57GiB 0.07% 198MB / 91.7MB 7.13MB / 3.13MB 21
62f86fb57627 2.22% 54.01MiB / 15.57GiB 0.34% 55.8MB / 1.16GB 211MB / 1.43MB 24
a173fb7cacda 0.00% 15.04MiB / 15.57GiB 0.09% 49.5MB / 110MB 1.44MB / 0B 5
256c8d25e9f9 0.09% 1.598MiB / 15.57GiB 0.01% 12.8GB / 13.2GB 4.49MB / 0B 2
304cd30dbc10 15.82% 3.824GiB / 15.57GiB 24.56% 49.2GB / 14.4GB 12.6GB / 9.64GB 170
74a23eb1bdf0 1.18% 3.083GiB / 15.57GiB 19.80% 170GB / 56.4GB 111GB / 106GB 210
9a14993f1238 6.52% 1.123GiB / 15.57GiB 7.21% 66.9GB / 213GB 69.1GB / 679GB 127
При желании, вывод данной статистики можно сузить, добавив в него один или несколько ID контейнеров в качестве параметров для команды. Например, так docker stats 304cd30dbc10 74a23eb1bdf0:
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
304cd30dbc10 0.98% 3.824GiB / 15.57GiB 24.56% 49.2GB / 14.4GB 12.6GB / 9.64GB 163
74a23eb1bdf0 0.19% 3.083GiB / 15.57GiB 19.80% 170GB / 56.4GB 111GB / 106GB 210
Также можно использовать флаг --format, чтобы выводить только интересующие столбцы информации. Например, для вывода статистики использования CPU и памяти используйте:
docker stats --format "table {{.Container}}\t{{.CPUPerc}}\t{{.MemUsage}}"
CONTAINER CPU % MEM USAGE / LIMIT
1fbfd146c892 0.00% 7.562MiB / 15.57GiB
3e18760df407 0.04% 21.71MiB / 15.57GiB
059c84d3606b 0.00% 7.535MiB / 15.57GiB
c7cff2a01c4b 0.00% 12.79MiB / 15.57GiB
d696ab70fe4b 0.00% 11.76MiB / 15.57GiB
54f2f9e5fb82 0.00% 17.88MiB / 15.57GiB
6f1b0479d00b 0.00% 13.29MiB / 15.57GiB
7e4e93b694fb 0.00% 9.535MiB / 15.57GiB
9b1d756a0b1e 0.00% 15.46MiB / 15.57GiB
29d0cac48303 0.06% 15.27MiB / 15.57GiB
124fae38e06c 0.00% 5.617MiB / 15.57GiB
809143ebbd38 0.00% 9.441MiB / 15.57GiB
2158ae2f51ab 3.55% 445.8MiB / 15.57GiB
aaa9c93137b2 0.00% 10.22MiB / 15.57GiB
e917f287bb0c 0.06% 10.73MiB / 15.57GiB
62f86fb57627 2.53% 54.98MiB / 15.57GiB
a173fb7cacda 0.00% 15.04MiB / 15.57GiB
256c8d25e9f9 0.00% 1.598MiB / 15.57GiB
304cd30dbc10 0.16% 3.836GiB / 15.57GiB
74a23eb1bdf0 0.24% 3.083GiB / 15.57GiB
9a14993f1238 0.08% 1.123GiB / 15.57GiB
Или комбинируйте эти команды:
docker stats --format "table {{.Container}}\t{{.CPUPerc}}\t{{.MemUsage}}" 304cd30dbc10 74a23eb1bdf0
CONTAINER CPU % MEM USAGE / LIMIT
304cd30dbc10 2.52% 3.836GiB / 15.57GiB
74a23eb1bdf0 7.79% 3.152GiB / 15.57GiB
Содержание:
-
1.
Предыстория -
2.
Windows контейнер -
3.
В мире контейнеров Windows -
4.
Связь с Docker -
5.
Мир Windows
Начиная с Windows Server 2016 в операционной системе от Microsoft включена нативная поддержка контейнеров. Это не Linux контейнеры, это контейнеры, которые работают на Windows, и запускают Windows внутри себя.
Данный факт является результатом присоединения Microsoft к Open Container Initiative (OCI). Контейнеры в Windows позволяют запускать приложения, которые изолированы от остальной части системы в переносимых контейнерах. Эти контейнеры включают в себя все, чтобы ваше приложение было полностью функциональным. Так же как это произошло с Linux, Microsoft надеется, что контейнеры изменят характер поставки программного обеспечения для пользователей и в Windows.
Предыстория
Контейнеры являлись основой вычислений в Linux в течение целого ряда лет. Google, например, уже очень давно использует решения, основанные на контейнерах по всей своей империи, чтобы предоставлять распределенные приложения не только своим сотрудникам, но и своим пользователям по всему миру.
Тем не менее, Google не был долгое время одинок в своем увлечении контейнерными вычислениями. В какой-то момент из ниоткуда появился Docker, который в отличии от Google стандартизировал процессы доставки контейнеров, а также управления ими. Более того, Docker развивался сообществом энтузиастов в мире открытого исходного кода, что сделало его простым и очень популярным решением. С развитием проекта Docker буквально у каждого желающего появилась возможность получить скорость, гибкость и простоту управления программным обеспечением и инфраструктурой, которую предоставляют контейнеры.
Docker революция стала настолько значительной, что даже Microsoft присоединился к этой инициативе в первую очередь за счет поддержки Docker и Linux в Azure, а теперь и за счет интеграции этой технологии в Windows Server 2016. Самое интересное это то, что контейнеры Windows Server не основаны на Linux, это нечто совершенно новое. Windows контейнеры — это контейнеры, которые работают в Windows и запускают Windows внутри себя.
Причем Microsoft настолько серьезно стала относится к контейнерам, что сейчас активно участвует в Open Container Initiative (OCI), пытаясь перетягивать одеяло на себя так, как будто бы она сама придумала эту технологию.
Windows контейнер
Контейнер в Windows имеет много общего с его аналогом в Linux. Оба обеспечивают изолированную среду для запуска приложений. И там и там контейнеры используют передовые технологии изоляции для обеспечения портативной, но одновременно ограниченной среды, которая включает в себя практически все, чтобы приложение могло быть полностью функциональным.
Контейнер очень похож на виртуальную машину (ВМ) и часто рассматривается как отдельный тип виртуализации, но это два совершенно разные понятия. Да, каждый работает под управлением операционной системы (ОС), предоставляет внутри себя локальную файловую систему и может быть доступен по сети так же как физический компьютер. Тем не менее, при использовании ВМ вы имеете дело с полной и независимой ОС вместе с виртуальными драйверами устройств, управлением памятью и другими компонентами, которые добавляют к накладные расходы.
Контейнер переиспользует большее количество общих ресурсов хост-системы нежели виртуальная машина, а значит, он более легкий, быстрее разворачивается и проще масштабируется между различными датацентрами. Таким образом, контейнер может предложить более эффективный механизм для инкапсулирования приложения, обеспечивая ему при этом необходимые интерфейсы хост-системы — все из этого приводит к более эффективному использованию ресурсов и улучшению переносимости приложений.
Microsoft планирует предложить два типа контейнеров в Windows Server 2016: контейнер Windows Server и Hyper-V контейнер. Оба типа функционируют одинаковым образом, и могут быть созданы и управляются одинаково. Там, где они различаются — это в уровне изоляции, который каждый из них обеспечивает.
Контейнер Windows Server разделяет ядро с ОС работает на хост-машине, что означает, что все контейнеры, работающие на этой машине, разделяют одно и то же ядро. В то же время, каждый контейнер поддерживает свой собственный вид на операционную систему, реестр, файловую систему, IP-адреса и другие компоненты, сочетая это с изоляцией, предоставляемой каждому контейнеру при помощи процессов, пространства имен и технологий управления ресурсами.
Контейнер Windows Server хорошо подходит для ситуаций, в которых и основная ОС, и приложения в контейнерах лежат в пределах той же зоны доверия, например для приложений, которые охватывают несколько контейнеров или образуют общую службу. Тем не менее, контейнеры Windows Server обсуждаются в связи с их зависимостью от процесса обновления ОС хост-системы, который может осложнить обслуживание и препятствовать процессам. Например, патч примененный к хосту может сломать приложение, работающее в контейнере. Что еще более важно, в таких ситуациях, как многопользовательские среды, модель разделяемого ядра может раскрыть систему для уязвимостей приложений и кросс-контейнерных атак.
Hyper-V контейнер решает эти проблемы, предоставляя виртуальную машину, в которой нужно запустить контейнер Windows. При таком подходе контейнер больше не разделяет ядро хост-машины и не имеет зависимости от патчей ОС этой машины. Конечно, такой подход означает некоторую потерю скорости и эффективности упаковки, которые вы получаете с обычным контейнером в Windows Server, но взамен вы получаете более изолированную и безопасную среду.
Вне зависимости от типа контейнера, который вы используете, теперь у вас есть возможность использовать контейнеры с такими технологиями Windows как .NET или PowerShell, что не было возможно раньше. Контейнер для Windows предоставляет все необходимое для обеспечения работы приложения на любом компьютере под управлением Windows Server 2016, давая вам тот уровень переносимости, который был не доступен на протяжении большей части истории Windows. Вы можете создавать свои контейнеры локально, делать их доступными процессов для тестирования и контроля качества, а затем отправить их в команде, занимающейся продуктивом, без необходимости беспокоиться о сложных установках и конфигурациях на каждом шаге этого пути.
В мире контейнеров Windows
Ряд компонентов принимают участие в процессе создании и запуска контейнеров, начиная с хоста, на котором они должны работать. Хост может быть как физическим компьютером, так и ВМ с Windows 2016 Server. Единственное, что важно, чтобы была включена функция контейнеризации для Windows.
Вы можете разместить контейнеры на любой версии Windows: Server Full UI или же Core, которая устанавливается по умолчанию. Microsoft также представляет Nano издание для Windows Server 2016 — минимальную версию ОС, которая не включает в себя локальный графический пользовательский интерфейс или консоль.
Microsoft также добавила вложенную виртуализацию для Windows Server 2016, так что вы можете запустить Hyper-V контейнеры, если хостом является ВМ. Если вы планируете запускать такой тип контейнера, необходимо включить функцию Hyper-V на хост-ОС. Microsoft также добавляет поддержку контейнера для Windows 10, хотя только для Hyper-V контейнеров.
Как и с контейнерами Docker, вы разворачиваете контейнеры для Windows из образов. Каждый образ начинается с образа ОС контейнера — базового образа, включающего в себя операционную систему, которая будет работать внутри контейнера. В настоящее время Microsoft предоставляет два базовых образа: образ Server Core и образ Nano Server. Вы должны загрузить хотя бы один из этих образов ОС от Microsoft, прежде чем сможете развернуть контейнер.
Microsoft строго определяет, какие образы вы можете использовать с каким типом контейнера на основании хост-ОС, как описано в следующей таблице.
|
Хост-ОС |
Контейнер Windows Server |
Контейнер Hyper-V |
|
Windows Server Full UI |
Образ Server Core |
Образ Nano Server |
|
Windows Server Core |
Образ Server Core |
Образ Nano Server |
|
Windows Server Nano |
Образ Nano Server |
Образ Nano Server |
|
Windows 10 |
N/A |
Образ Nano Server |
Как вы можете видеть, Hyper-V контейнеры в настоящее время поддерживают только образ Nano сервера, но ваш выбор контейнеров Windows Server зависит от того, с какой версией Windows Server вы работаете.
Для этого типа контейнера, образ ОС должен также соответствовать хост-системы в отношении сборки и уровня обновления. Несоответствие может привести к непредсказуемому поведению как для контейнера, так и хоста. Это означает, что вы должны обновить образ базового контейнера ОС при обновлении ОС хоста. Это также означает, что вы не будете иметь возможность запускать Linux контейнер на Windows машине, или наоборот, и это также верно для Hyper-V контейнеров.
Образы обеспечивают высокую степень гибкости, когда речь идет о развертывании контейнеров. Вы можете создавать образы на основе существующего образа и обновлять новые образы так часто, как это необходимо. После этого вы можете развернуть один или несколько контейнеров из этого образа.
Например, предположим, что вы создаете образ, основанный на Server Core. В новый образ, вы устанавливаете приложение, которое в настоящее время находится в разработке вместе со всеми зависимостями этого приложения. Затем вы можете развернуть один или несколько контейнеров из этого образа. Каждый контейнер функционирует как песочница, которая включает все компоненты, необходимые для полной работоспособности приложения.
Образ может быть развернут так часто, как это необходимо, а также совместно использоваться любым количеством контейнеров. Вы создаете контейнеры по мере необходимости, а затем избавляетесь от них, когда вы с ними закончите. Но лучше всего то, что вы можете обновить и повторно развернуть образ в любое время, а затем создать из него новые контейнеры, которые содержат последние изменения.
Вам не нужно выбирать тип контейнера (Windows Server или Hyper-V) до тех пор, пока вы не будете готовы запустить фактический контейнер. Тип контейнера не имеет никакого отношения к тому, как вы собираете ваши образы. Образы хранятся в репозитории и доступны по запросу для разворачивания контейнеров, где и когда они необходимы, будь то контейнеры Windows Server или Hyper-V.
Связь с Docker
Помимо компании, Docker также является проектом с открытым кодом, которая облегчает процесс развертывания и управления контейнерами. Контейнеры Windows теперь являются частью этого проекта, и сообщество Docker интенсивно работает, чтобы полностью интегрировать контейнеры Windows в экосистему Docker. В рамках этой же инициативы Docker предлагает Docker Engine для Windows, и Docker Client для Windows.
Docker Engine обеспечивает функциональность, необходимую для управления Docker окружением. Например, Docker Engine позволяет автоматизировать создание контейнеров из образов. Хотя вы можете создавать образы вручную, Docker Engine предлагает целый ряд преимуществ, т.к. возможность хранения образов как кода, легкого пересоздания этих образов или включения их в цикл непрерывной интеграции в процессе разработки.
Тем не менее, Docker Engine не является частью установки Windows. Вы должны загрузить, установить и настроить его отдельно от Windows. Docker Engine работает как служба Windows. Можно настроить эту службу, используя файл конфигурации или Windows Service Control Manager (SCM). Например, вы можете установить отладку по умолчанию и параметры журнала или настроить, как Docker Engine принимает сетевые запросы. Microsoft рекомендует использовать файл конфигурации, а не SCM, но отмечает, что не каждый параметр конфигурации в файле применим к контейнерам Windows.
Docker Engine по существу делает всю рутинную работу по управлению контейнером за вас, расширяя API, необходимый для клиента Docker для взаимодействия Docker Engine. Клиент представляет собой интерфейс командной строки, который предоставляет набор команд для управления образами и контейнерами. Это те же самые команды, которые позволяют создавать и запускать контейнеры Docker в Linux. Хотя вы и не можете запустить контейнер для Windows на Linux или контейнер Linux на Windows, вы можете использовать один и тот же клиент для управления как Linux и Windows контейнерами, будь то контейнеры Windows Server или Hyper-V.
Как и с Docker Engine, вам необходимо загрузить и установить клиент Docker самостоятельно. Клиент может работать как на Windows 10 или Windows Server 2016. Вам нужно только указать клиенту Docker службу, которой необходимо начать управлять.
Мир Windows
Microsoft и Docker осталось сделать еще много работы, прежде чем контейнеры для Windows будут полностью функциональны, но то, что мы видим уже сейчас представляет собой значительный шаг вперед. Пользователям Windows, наконец, получат возможность пользоваться всеми преимуществами гибкости и переносимости, которые контейнеры предлагали миру Linux на протяжении более десяти лет.
In this tutorial, you will learn how to use the docker command for checking memory and CPU utilization of your running Docker containers.
Monitoring the health of your containers is crucial for a happy and reliable environment. It’s very important to know if your container is hittings its head against a CPU, Memory, Network, or Block limit, which could be severely degrading it.
Docker Stats
The Docker command-line tool has a stats command the gives you a live look at your containers resource utilization. We can use this tool to gauge the CPU, Memory, Networok, and disk utilization of every running container.
Run the docker stats command to display the status of your containers.
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
e51898f31223 lucid-lemon 0.00% 8.824MiB / 1.944GiB 0.44% 0B / 0B 0B / 0B 7
bc97fe8bcd66 funky-monkey 0.01% 12.05MiB / 1.944GiB 0.61% 0B / 0B 0B / 0B 6
17714162a329 hairy-lemon 0.15% 82.09MiB / 1.944GiB 4.12% 0B / 0B 0B / 0B 28
340bec496cf7 silly-sunshine 0.50% 20.28MiB / 1.944GiB 1.02% 0B / 0B 0B / 0B 32
- Memory is listed under the MEM USAGE / LIMIT column. This provides a snapshot of how much memory the container is utilizing and what it’s memory limit is.
- CPU utilization is listed under the CPU % column.
- Network traffic is represented under the NET I/O column. It displays the outgoing and incoming traffic consumption of a container.
- Storage utilization is shown under the BLOCK I/O column. This show you the amount of reads and writes a container is peforming to disk.
No Stream
By default, the docker stats command will display a live stream of stats. If you would prefer outputting the first stats pull results, use the --no-stream flag.
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
e51898f31223 k8s_postgres_postgres-778965fcc7-rc2wj_default_8c8e771b-5b1a-43ee-a9ea-e4af2c1e9319_0 0.00% 8.695MiB / 1.944GiB 0.44% 0B / 0B 0B / 0B 7
bc97fe8bcd66 k8s_wordpress_wordpress-69b59478c4-5lvkk_default_1c19bdb0-2dbc-4c74-9c23-fd1f19c785bc_0 0.01% 12.05MiB / 1.944GiB 0.61% 0B / 0B 0B / 0B 6
17714162a329 k8s_mysql_wordpress-mysql-b5ddc8dd9-4xmqr_default_7694cbcb-ae3e-4bc8-a767-56c4261202f8_0 0.12% 82.09MiB / 1.944GiB 4.12% 0B / 0B 0B / 0B 28
340bec496cf7 k8s_mongodb_mongodb-5d75bdb4d7-7phxp_default_14986721-98a2-4e22-9e4a-94c569b7702e_0 0.47% 20.46MiB / 1.944GiB 1.03% 0B / 0B 0B / 0B 32
All Containers
By default, docker stats will only output results for running containers. If you would like to output stats for all containers you can use the -a or --all flags with the command.
docker stats --no-stream -a
You maybe wondering why someone would want to output stats for containers that are not running. One use case is ensuring that a container is no longer running, or displaying a list of stopped containers with the running containers and their stats.
Bitbucket Pipelines, Gitlab CI, and Github Actions
Container-based continuous integration pipelines have grown in populartiy over the last couple of years, and all major CI tool providers support it. These pipelines run containers in a non-interactive mode, which means you will not be able to use the docker stats command to monitor the health of your containers. In fact, it’s unlikely you will be able to run any Docker commands as part of your pipeline, as the container itself will not have access to the Docker socket for security reasons.
To overcome not being able to execture docker stats from within a container, we can simply add the following commands to our pipeline in addition to the steps that are already there.
- while true; do echo "Memory usage in bytes:" && cat /sys/fs/cgroup/memory/memory.memsw.usage_in_bytes; sleep 2; done & 2
- while true; do date && ps aux && echo "" && sleep 2; done &
The commands above capture the output of the ps aux command, which displays the current processes running on the container, and the memory usage of the container. The output is then streamed to the pipeline logs every 2 seconds.
The processes run in the background, so the pipeline will continue to run as normal. The output of the commands will be displayed in the pipeline logs, which you can use to monitor the health of your container.
Conclusion
The native Docker tools provide a limited glimps into the health of your containers, but its enough to understand how each one is utilizing system resources. We determine whether a container is CPU or Memory blocked, how much network traffic is hitting or being generated by a container, and how hard it’s disk storage is being hit.
In cases where we have no access to the Docker socket, we can use the ps aux command to display the current processes running on the container, and the memory usage of the container.
References
- Atlassian: Troubleshooting Bitbucket Pipelines
- Stackoverflow
-
Dockerizing MCP – Bringing Discovery, Simplicity, and Trust to the Ecosystem
Discover the Docker MCP Catalog and Toolkit, a new way to source, use, and scale with MCP tools.
Read now
-
Securing Model Context Protocol: Safer Agentic AI with Containers
Learn about the new challenges of MCP security, where many current MCP tools fall short, and how containers help maintain best practices.
Read now
-
Introducing Docker MCP Catalog and Toolkit: The Simple and Secure Way to Power AI Agents with MCP
With the Docker MCP Catalog and Toolkit, you can easily discover tools and connect with your favorite MCP clients.
Read now
-
Simplifying Enterprise Management with Docker Desktop on the Microsoft Store
Find Docker on the Microsoft Store for simplified installs, updates, and enterprise management with native Intune support and seamless deployment.
Read now