Архив метки: Devops

Как проверить использование дискового пространства образов, контейнеров и томов Docker

Интересно, сколько места занимает Docker в вашей системе Linux?




В основном, все образы Docker, контейнеры и другие связанные с ними сущности находятся в каталоге /var/lib/docker.




Вы можете проверить размер этого каталога и получить общее дисковое пространство, используемое Docker:




$ sudo du -sh /var/lib/docker
4.9G	/var/lib/docker




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




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




Проверка использования дискового пространства Docker




Самый простой, “докеровский” способ узнать, сколько места занимают образы, контейнеры, локальные тома или кэш сборки:




docker system df




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




$ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          4         4         1.065GB   0B (0%)
Containers      4         4         5.705kB   0B (0%)
Local Volumes   7         7         1.108GB   0B (0%)
Build Cache     0         0         0B        0B







Это определенно лучше, чем смотреть на общий размер /var/lib/docker.




Вы можете увидеть, сколько места занимают образы, контейнеры и тома.




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




На самом деле, это так.




Команда df системы docker имеет опцию verbose -v, которая предоставляет все эти детали.




docker system df -v




Вот подробный вывод:




$ docker system df -v
Images space usage:

REPOSITORY                               TAG       IMAGE ID       CREATED         SIZE      SHARED SIZE   UNIQUE SIZE   CONTAINERS
ghost                                    4.32.0    b40265427368   8 weeks ago     468.8MB   0B            468.8MB       1
jrcs/letsencrypt-nginx-proxy-companion   latest    037cc4751b5a   13 months ago   24.35MB   0B            24.35MB       1
jwilder/nginx-proxy                      latest    509ff2fb81dd   15 months ago   165MB     0B            165MB         1
mariadb                                  10.5.3    f5d2bcaf057b   20 months ago   407MB     0B            407MB         1

Containers space usage:

CONTAINER ID   IMAGE                                    COMMAND                  LOCAL VOLUMES   SIZE      CREATED        STATUS        NAMES
899cc90e85d9   ghost:4.32.0                             "docker-entrypoint.s…"   1               0B        8 weeks ago    Up 8 weeks    ghost_ghost_6
17b58fdafbce   jrcs/letsencrypt-nginx-proxy-companion   "/bin/bash /app/entr…"   4               571B      3 months ago   Up 2 months   letsencrypt-proxy-companion
58f99f46ee03   jwilder/nginx-proxy                      "/app/docker-entrypo…"   5               5.13kB    3 months ago   Up 2 months   jwilder-nginx-proxy
fb907286b60e   mariadb:10.5.3                           "docker-entrypoint.s…"   1               2B        3 months ago   Up 2 months   ghost_db_1

Local Volumes space usage:

VOLUME NAME                      LINKS     SIZE
ghostdb                          1         434.7MB
jwilder-nginx-with-ssl_acme      2         36.09kB
jwilder-nginx-with-ssl_certs     2         25.12kB
jwilder-nginx-with-ssl_dhparam   1         1.525kB
jwilder-nginx-with-ssl_html      2         1.106kB
jwilder-nginx-with-ssl_vhost     2         556B
ghost                            1         674MB

Build cache usage: 0B

CACHE ID   CACHE TYPE   SIZE      CREATED   LAST USED   USAGE     SHARED




Проверка размеров образов docker




Если вы просто хотите посмотреть образы Docker и их размеры, вы также можете использовать эту команду:




docker ps --size




Вы должны увидеть столбец SIZE, добавленный к выводу команды:




$ docker ps --size
CONTAINER ID   IMAGE     COMMAND      CREATED         STATUS         PORTS     NAMES           SIZE
1171dcfb7e06   alpine    "sleep 10"   10 months ago   Up 9 seconds             always-policy   0B (virtual 5.61MB)




Проверка размеров запущенных контейнеров




Аналогично, если вы хотите узнать размер запущенных контейнеров Docker, вы можете использовать команду docker ps:




docker ps --size




Вы должны увидеть столбец SIZE, добавленный к выводу команды:




$ docker ps --size
CONTAINER ID   IMAGE     COMMAND      CREATED         STATUS         PORTS     NAMES           SIZE
1171dcfb7e06   alpine    "sleep 10"   10 months ago   Up 9 seconds             always-policy   0B (virtual 5.61MB)




Вы заметили, как вывод говорит 0B, а затем показывает виртуальный размер 5,61 МБ?




Виртуальный размер включает общий базовый образ.




Давайте вернемся к подходу к Linux более конкретно, на примере образа и контейнера Alpine в качестве практического примера.




Использование стандартных команд Linux для анализа использования дискового пространства Docker




Всякий раз, когда вы используете команду docker pull или запускаете команду docker-compose up -d для подготовки запуска приложений, вот как вы смотрите на использование пространства образа, фактически хранящегося на сервере Ubuntu 20.04:




sudo du -sh /var/lib/docker/overlay2/<hash-named-directory>/




Здесь Overlay2 является драйвером хранилища Docker по умолчанию в Ubuntu.




Вы можете подтвердить это, выполнив команду docker info и поискав Storage Driver:




Storage Driver: overlay2




Если оно отличается от вашего, значит, вы используете другой драйвер хранения для Docker.




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




Доступность драйвера хранилища зависит от поддержки ядра.




Использование диска конкретного образа




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




Например, я извлек образ alpine с помощью команды docker pull alpine.




Выполните следующую команду для его проверки:




$ docker inspect alpine




После выполнения команды вы заметите три поля в подразделе Data в разделе GraphDriver:




...
        "GraphDriver": {
            "Data": {
                "MergedDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/merged",
                "UpperDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
                "WorkDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/work"
            },

...




Исходя из вышеприведенной информации, вы можете видеть, что (упомянутый ранее в синтаксисе команды du) в данном случае равен 64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a525ab9e365e.




Здесь вы можете выполнить следующую команду, чтобы узнать объем пространства, используемого изображением Alpine:




$ sudo du -sh /var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e
6.0M	/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e




Подобно образам, контейнеры также хранятся в одном каталоге на базе драйвера хранилища.




/var/lib/docker/overlay2




Использование диска конкретным контейнером




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




Например, я запустил контейнер alpine с помощью команды docker run -ti -d alpine.




Запустив команду docker ps, вы увидите, что он запущен:




$ docker ps
CONTAINER ID   IMAGE     COMMAND     CREATED         STATUS         PORTS     NAMES
cb341d6a28fa   alpine    "/bin/sh"   6 seconds ago   Up 5 seconds             confident_banzai




Здесь контейнер был произвольно назван confident_banzai.




Давайте проверим его:




$ docker inspect confident_banzai




После выполнения вышеуказанной команды вы заметите все четыре поля, упомянутые ранее в подразделе Data в разделе GraphDriver.




В этих местах данные контейнера физически хранятся на хост-системе, как и в случае с образами:




...
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3-init/diff:/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
                "MergedDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/merged",
                "UpperDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/diff",
                "WorkDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/work"
            },
            "Name": "overlay2"
        },
...




Теперь вы можете снова использовать команду du:




$ sudo du -sh /var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3
32K	/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3




Использование диска конкретного тома




В данном случае существует два типа томов.




Первый – это обычные тома Docker, а второй – bind mounts.




Тома Docker




Если вы ищете местоположение определенных томов, вы можете сначала использовать команду docker volume ls и проверить имя или ID тома.




Скажем, например, я запустил контейнер alpine следующей командой с томом:




docker run -ti -d --name alpine-container -v test-data:/var/lib/app/content alpine




Теперь автоматически будет создан том с именем test-data.




Теперь давайте создадим файл test.md в этом месте:




$ docker exec alpine-container sh -c "touch /var/lib/app/content/test.md"




Убедитесь, что файл действительно был создан:




$ docker exec -ti alpine-container sh
/ # ls /var/lib/app/content/
test.md
/ # exit




Когда вы запустите docker volume ls, в списке появится том с именем test-data:




$ docker volume ls
DRIVER    VOLUME NAME
local     d502589845f7ae7775474bc01d8295d9492a6c26db2ee2c941c27f3cac4449d1
local     e71ee3960cfef0a133d323d146a1382f3e25856480a727c037b5c81b5022cb1b
local     test-data




Наконец, вы можете подтвердить фактическое расположение файла на вашей хост-системе:




$ sudo ls -l /var/lib/docker/volumes/test-data/_data
total 0
-rw-r--r-- 1 root root 0 Oct  6 23:20 test.md




Поэтому путь для смонтированного тома всегда находится в каталоге с именем _data внутри соответствующего каталога тома.




Таким образом, вы можете использовать команду du здесь снова для определенных томов!




$ sudo du -sh /var/lib/docker/volumes/test-data/_data
4.0K	/var/lib/docker/volumes/test-data/_data




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




Bind Mounts




Это единственное исключение в Docker, где необходимо использовать подход Linux для мониторинга использования дискового пространства.




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




$ mkdir /home/avimanyu/test-data
$ docker run -ti -d --name alpine-container -v /home/avimanyu/test-data:/var/lib/app/content alpine




В этом случае смонтированный том с именем test-data станет доступен на стороне контейнера как /var/lib/app/content.




$ sudo du -sh /home/avimanyu/test-data
4.0K	/home/avimanyu/test-data




То же самое можно проверить и внутри контейнера:




$ sudo docker exec -ti alpine-container sh
/ # du -sh /var/lib/app/content
4.0K	/var/lib/app/content




Как вы можете видеть, оба указанных выше размера одинаковы!




Логи Docker на хосте всегда хранятся в томах.




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




Это зависит от приложения и расположения файлов логов в томах приложения.




Бонусные советы




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




sudo du -sh /var/lib/docker/overlay2




Логи Docker на хосте всегда хранятся в томах.




Обычно большой объем Docker, скорее всего, указывает на то, что логи накапливаются и управляются неэффективно.




Используя способ, описанный в разделе “Тома” этой статьи, пользователи также могут сориентироваться и смягчить ситуацию, посмотрев на использование дискового пространства в томах docker.




Это зависит от приложения и расположения файлов журналов в томах приложения.




Резюме




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




Вы также узнали, как сделать это предпочтительным (Docker) способом.




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




Источник: https://itisgood.ru/2022/02/24/kak-proverit-ispolzovanie-diskovogo-prostranstva-obrazov-kontejnerov-i-tomov-docker/



2022-04-14T17:45:17
DevOps

Принудительное удаление зависших подов в Kubernetes

В этом коротком руководстве мы рассмотрим, как удалить удаленные или завершенные поды в кластере Kubernetes.Есть много причин, по которым вы можете обнаружить, что некоторые поды находятся в состоянии Evicted и Terminated.В случае eviction это часто происходит в результате нехватки ресурсов на рабочих нодах или ошибки приложения.Terminated может быть результатом уменьшения масштаба приложения или развертывания новой версии приложения, после которой прекращается работа старых подов.Служба kubelet, которая работает на каждом узле кластера, отвечает за состояние eviction подов.Вы можете получить список подов в пространстве имен, застрявших в состоянии Evicted и Terminated, выполнив следующую команду:




kubectl get pods -n namespace | egrep -i 'Terminated|Evicted'




Как удалить поды в Kubernetes




Вы можете удалить эти поды разными способами.




Использование собственных команд kubectl и Bash




Это команды bash с фильтрацией, которые вы можете запустить для принудительного удаления подов в пространстве имен, которые застряли в завершенном состоянии.




# Определение неймспейса
namespace="mynamespace"

# Получаем поды
epods=$(kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted' | awk '{print $1 }')

# Удаляем их
for i in ${epods[@]}; do
  kubectl delete pod --force=true --wait=false --grace-period=0 $i -n ${namespace}
done




Подтвердите, есть ли еще контейнеры в этом состоянии.




kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted'




Удаление всех исключенных и завершенных модулей из всех пространств имен:




kubectl get pods --all-namespaces | egrep -i  'Evicted|Terminated' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod --force=true --wait=false --grace-period=0




Удалите все контейнеры в состоянии ImagePullBackOff из всех пространств имен – Бонус:




kubectl get pods --all-namespaces | grep -E 'ImagePullBackOff|ErrImagePull|Evicted' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod




Использование фильтров kubectl и jq




Вы также можете отфильтровать вывод команды kubectl и перенаправить в jq для получения определенных столбцов.




Сначала установите команду jq:




--- Ubuntu / Debian ---
$ sudo apt update && sudo apt install jq

--- CentOS/Fedora ---
$ sudo yum -y install epel-release
$ sudo yum -y install jq

--- RHEL ---
wget https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64 -O jq
chmod +x jq
sudo mv jq /usr/local/bin




Затем удалите застрявшие поды с помощью команды:




kubectl get pods --all-namespaces -o json | jq '.items[] | select(.status.reason!=null) | select(.status.reason | contains("Evicted")) | "kubectl delete pods (.metadata.name) -n (.metadata.namespace)"' | xargs -n 1 bash -c




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



2022-04-14T17:43:08
DevOps

Как установить Kubernetes на единый узел Ubuntu

Контейнеры, Kubernetes и IoT/периферийные приложения играют чрезвычайно важную роль в цифровой трансформации предприятия. Они особенно важны для команд DevOps, работающих над ускорением выпуска программного обеспечения и улучшением ИТ-операций за счет интеграции и оптимизации. Большая часть облачного программного обеспечения удобна для пользователя, что позволяет многим разработчикам вносить свой вклад и настраивать соответствующее программное обеспечение. Это привело к появлению упрощенных версий Kubernetes с небольшими следами, которые идеально подходят для задач IoT/Edge. Читать →

🐳 Обзор сканеров безопасности контейнеров Docker для поиска уязвимостей

Безопасны ли ваши контейнеры и образа Docker?

Хакеры стали очень активными в последние несколько лет.

Даже крупные организации, такие как Facebook, Google и Yahoo, стали жертвами атак, потеряв миллионы долларов.

Вот почему сегодня безопасность приложения – это самое важное в любой организации.

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

Таким образом, фактор безопасности этих контейнеров очень важен.

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

У небольших образов контейнеров меньше шансов подвергнуться потенциальным уязвимостям.

Контейнеризация – это один из основных этапов процесса DevOps, на котором безопасность требует серьезного внимания.

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

Следовательно, крайне важно регулярно сканировать и проверять образы и контейнеры.

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

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

Давайте изучим доступные варианты.

 

Clair

 

Clair – это проект с открытым исходным кодом, который предлагает сканирование уязвимостей контейнеров Docker и приложений (appc).

Это механизм анализа, управляемый API, который слой за слоем проверяет наличие недостатков безопасности в контейнерах.

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

 

Также он уведомляет о потенциальной угрозе в контейнере.

А именно, он уведомляет вас о потенциальной угрозе в контейнере на основе базы данных Common Vulnerabilities and Exposures (CVE) и аналогичных баз данных.

Если выявляется какая-либо угроза или проблема, которая уже есть в Национальной базе данных уязвимостей (NVD), инструмент извлекает подробности и предоставляет их в отчете.

Особенности Clair:

  • Сканирует существующие уязвимости и предотвращает их появление в будущем.
  • Предоставляет REST API для интеграции с другими инструментами
  • Отправляет уведомление при обнаружении любой уязвимости
  • Предоставляет отчет в формате HTML со всеми деталями сканирования
  • Регулярно обновляет метаданные

 

Trivy

 

 

Trivy – это простой и комплексный сканер уязвимостей для контейнеров и других артефактов.

Он помогает обнаруживать уязвимости пакетов операционной системы (Alpine, RHEL, CentOS и т. д.) и зависимости приложений (Bundler, Composer, npm, yarn и т. д.).

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

 

Особенности Trivy

  • Обнаружение комплексных уязвимостей
  • Простота – укажите только имя образа или имя артефакта.
  • Быстрота – первое сканирование завершится в течение 10 секунд (в зависимости от вашей сети). Последующее сканирование завершится за считанные секунды
  • DevSecOps – подходит для CI, таких как Travis CI, CircleCI, Jenkins, GitLab CI и т. д.
  • Поддержка нескольких форматов – в том числе: образ контейнера, локальная файловая система, удаленный репозиторий git.
  • Простая установка – возможна установка apt-get, yum install и brew без предварительных условий, таких как установка БД, библиотек и т. д.

Ранее мы уже подробно разбирали его:

Anchore

 

 

Anchore – это проект с открытым исходным кодом для глубокого анализа образов Docker.

Он также удостоверяет образ, сообщая, защищен он или нет.

Anchore может работать как на отдельной платформе, так и на платформах оркестровки, таких как Kubernetes, Rancher, Amazon ECS, Docker Swarm.

Anchore также доступен в плагинах Jenkins для сканирования пайплайнов CI/CD.

Вам необходимо отправить образ в anchore, который проанализирует и предоставит вам подробную информацию, если в нем есть какие-либо уязвимости.

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

 

Dagda

 

 

Dagda – это инструмент с открытым исходным кодом для статического анализа известных уязвимостей, таких как трояны, вредоносное ПО, вирусы и т. д., в образах и контейнерах.

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

Сначала он импортирует все известные уязвимости из CVE, Red Hat Security Advisories (RHSA), Red Hat Bug Advisories (RHBA), идентификаторов Bugtraq (BID), базы данных безопасности Offensive в MongoDB.

Затем в соответствии с импортированными уязвимостями анализируются образы и контейнеры.

Особенности Dagda:

  • Поддерживает несколько образов Linux (CentOS, Ubuntu, OpenSUSE, Alpine и т. д.)
  • Анализирует зависимости от java, python node js, javascript, ruby, PHP
  • Интегрируется с Falco для мониторинга работающих контейнеров
  • Сохраняет каждый отчет анализа в MongoDB для ведения истории каждого образа докера или контейнера.

 

Falco

 

 

Falco – это проект с открытым исходным кодом как механизм обнаружения угроз в Kubernetes.

Это инструмент безопасности во время выполнения для обнаружения аномальной активности на хостах и контейнерах, работающих в Kubernetes.

Он обнаруживает любое неожиданное поведение в вашем приложении и предупреждает вас об угрозах во время выполнения.

Он использует синтаксис, подобный tcpdump, для создания правил и использует библиотеки, такие как libscap и libinsp, которые могут входить и извлекать данные с вашего сервера API Kubernetes или среды выполнения контейнера.

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

Правила фокусируются на системных вызовах и на том, какие системные вызовы разрешены и запрещены в системе.

 

Aqua Security

 

 

Aqua Security защищает приложения, созданные с использованием облачных технологий, таких как контейнеры.

Он обеспечивает сканирование уязвимостей и управление для таких оркестраторов, как Kubernetes.

Это комплексная платформа безопасности, обеспечивающая безопасность приложений, работающих в контейнерах, и их выполнение в безопасной среде.

Когда разработчики создают образы, у них есть набор технологий и библиотек для их создания.

Aqua security позволяет им сканировать эти образа, чтобы убедиться, что они “чистые”, в них нет известных уязвимостей, в них нет открытых паролей или секретов, а также нет угроз безопасности, которые могли бы сделать этот образ уязвимым.

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

Aqua Security также имеет технологии, гарантирующие, что образ не подвергнется атаке или проникновению с какой-либо угрозой безопасности, когда контейнер запущен в продакшен.

 

Docker Bench

Docker Bench Security – это скрипт с несколькими автоматическими тестами для проверки лучших практик развертывания контейнеров в производственной среде.

Чтобы запустить систему безопасности Docker Bench, вам понадобится Docker 1.13.0 или новее.

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

docker run -it --net host --pid host --userns host --cap-add audit_control 

-e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST 

-v /var/lib:/var/lib 

-v /var/run/docker.sock:/var/run/docker.sock 

-v /usr/lib/systemd:/usr/lib/systemd 

-v /etc:/etc --label docker_bench_security 

docker/docker-bench-security

После этого скрипт запустится, и он поделится деталями по северети INFO, WARN, PASS.

После запуска скрипта вы можете проверить все предупреждающие сообщения и внести исправления.

Harbor

Как вывести список контейнеров в Docker

Docker — это платформа контейнеризации, которая позволяет быстро создавать, тестировать и развертывать приложения в виде переносимых самодостаточных контейнеров, которые могут работать практически где угодно. Это де-факто стандарт для развертывания контейнеров, и это важный инструмент для инженеров DevOps и их конвейеров непрерывной интеграции и доставки.

В этой статье мы объясним, как составить список контейнеров Docker. Читать →

Как установить и использовать Docker в Debian 9

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

Docker де-факто является стандартом для контейнерных технологий и является важным инструментом для инженеров DevOps и их конвейера непрерывной интеграции и доставки.

В этом руководстве мы проведем вас через процесс установки Docker на машине Debian 9 и изучим основные концепции и команды Docker. Читать →