Використання nsenter, docker exec та систем журналювання

Уявіть собі таку ситуацію: 2 години ночі, ваш телефон вібрує, і це високопріоритетне повідомлення з продуктивного середовища. Критичний сервіс працює неналежним чином, логи нечіткі, і кожна секунда простою коштує бізнесу. Ви не можете просто перезавантажити контейнер — він має стан і обробляє живі сесії користувачів. Ще гірше, мережеві з’єднання нестабільні, і ваша команда намагається з’ясувати, чи це проблема з додатком, мережею чи чимось іншим.

Ці моменти ілюструють, чому ми, як інженери, витрачаємо стільки зусиль на вдосконалення наших стратегій відлагодження і ведення логів. У контейнеризованих середовищах інструменти, які ви вибираєте, можуть бути різницею між швидким вирішенням проблеми та довгою, виснажливою ніччю відлагодження. Контейнери за своєю природою ізольовані, що є чудовим для безпеки і портативності — але це може зробити відлагодження схожим на навігацію в закритій кімнаті без вікон. Вам потрібні інструменти, які зможуть пробити цю ізоляцію і дати вам уявлення про проблему, при цьому не зупиняючи роботу ваших систем.

Цей посібник — ваш план дій для вирішення подібних ситуацій. Ми детально розглянемо два незамінних інструменти для відлагодження контейнерів: docker exec для прямої взаємодії з контейнерами і nsenter для глибокого занурення в Linux простори імен (namespaces), у яких вони знаходяться. Окрім цього, ми вивчимо, як налаштувати надійні фреймворки для ведення логів, що захоплюють кожну деталь, незалежно від того, де ваші контейнери працюють.

До кінця цього посібника ви будете:

• Розуміти, коли і як використовувати docker exec для відлагодження та обслуговування.
• Навчитесь використовувати nsenter для низькорівневого відлагодження, яке виходить за межі стандартних інструментів Docker.
• Освоїте конфігурації логування для забезпечення повної спостережуваності, навіть у розподілених середовищах.
• Поєднаєте ці інструменти в реальних ситуаціях для швидкого і точного вирішення проблем.

Незалежно від того, чи ви відлагоджуєте некоректно налаштований сервіс, вирішуєте проблеми з нестабільними мережевими з’єднаннями, чи налаштовуєте централізоване логування для розгортання на Kubernetes, цей посібник надасть вам практичні, перевірені стратегії для того, щоб повністю контролювати ваше контейнеризоване середовище.

Давайте почнемо 🚢

Сценарій: Контейнери поводяться неналежно

Уявіть собі таку ситуацію: ваша команда шукає баг, який з’являється тільки в продуктивному середовищі. Логи надходять безперервно, але ключових деталей не вистачає. Тим часом один із контейнерів веде себе неналежно, і перезавантаження порушить сесії користувачів. Що робити?

Саме тут інструменти, як docker exec, nsenter та належні фреймворки логування, виявляються надзвичайно корисними. Вони дозволяють взаємодіяти з контейнерами без порушення їх роботи, занурюватися глибше, коли це потрібно, і забезпечувати, щоб жоден лог не залишався незафіксованим.

Частина 1: Робота з docker exec

Коли йдеться про відлагодження або обслуговування контейнерів, docker exec часто є першим інструментом, до якого ви звертаєтесь. Він простий, ефективний і вбудований в Docker. Незалежно від того, чи ви розслідуєте проблеми з додатком, перевіряєте файлові системи контейнерів або запускаєте команди в реальному часі, docker exec забезпечує потужний спосіб взаємодії з контейнерами без порушення їх роботи.

Основи роботи з docker exec

Команда docker exec дозволяє виконувати команди всередині вже працюючого контейнера. Важливо, що вона не запускає новий контейнер, а замість цього підключається до існуючого простору імен контейнера, що дозволяє безпосередньо взаємодіяти з його середовищем.

Перед тим, як почати, переконайтеся, що контейнер, з яким ви працюєте, активний. Ви можете переглянути список всіх працюючих контейнерів за допомогою:

docker ps

Це виведе список працюючих контейнерів, включаючи їхні імена та ID. Далі використовуйте або ім’я, або ID контейнера в наступних командах docker exec.

Запуск інтерактивної сесії

Найпоширеніший випадок використання docker exec — це запуск інтерактивної оболонки всередині контейнера.
Це особливо корисно для відлагодження, ручного редагування конфігурацій або запуску діагностичних команд.

Наприклад, якщо вам потрібна оболонка всередині контейнера Nginx з іменем my-nginx-container, використовуйте:

docker exec -it my-nginx-container bash

Тут:

• -i забезпечує відкриття потоку вводу.
• -t виділяє псевдо-TTY, що дозволяє взаємодіяти з оболонкою.

Якщо контейнер не має встановленого bash, можна використовувати іншу оболонку, наприклад, sh:

docker exec -it my-nginx-container sh

Опинившись всередині, ви можете переглядати файлову систему, редагувати конфігураційні файли або виконувати діагностику, як якби працювали на окремій системі.

Запуск неінтерактивних команд

Іноді вам не потрібна інтерактивна сесія; достатньо просто виконати одну команду і отримати результат. Наприклад, щоб вивести вміст каталогу /var/log в контейнері, використовуйте:

docker exec my-nginx-container ls /var/log

Результат команди буде виведений безпосередньо у ваш термінал. Такий підхід ідеально підходить для одноразових завдань, як перевірка статусу сервісу, отримання логів або перевірка конфігураційного файлу.

Ось приклад перевірки наявності конфігураційного файлу:

docker exec my-nginx-container cat /etc/nginx/nginx.conf

Якщо файл дійсний та доступний, його вміст буде показаний. Якщо ні, ви отримаєте повідомлення про помилку, що допоможе швидко визначити потенційні проблеми.

Відлагодження додатків за допомогою docker exec

Звичайний сценарій використання docker exec — це відлагодження додатка, що працює всередині контейнера. Припустимо, ваш веб-додаток у контейнері не відповідає належним чином, і ви підозрюєте, що сервіс може не працювати. За допомогою docker exec ви можете перевірити його стан без зупинки контейнера.

docker exec my-app-container ps aux | grep my-service

Якщо сервіс відсутній у виведеному результаті, вам, можливо, доведеться перезапустити його. Наприклад:

docker exec my-app-container service my-service start

Цей підхід дозволяє виконувати швидкі виправлення без необхідності перезавантажувати або перебудовувати контейнер.

Редагування конфігураційних файлів

Під час відлагодження контейнеризованого додатка часто проблеми спричиняють неправильно налаштовані файли. За допомогою docker exec можна перевіряти та навіть редагувати конфігураційні файли безпосередньо.

Щоб відредагувати файл, використовуйте текстовий редактор всередині контейнера, наприклад, vi:

docker exec -it my-app-container vi /etc/app/config.yaml

Після внесення змін перезапустіть відповідний сервіс, щоб застосувати оновлення:

docker exec my-app-container service app-service restart

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

Практичні поради щодо використання docker exec

1. Завжди використовуйте -it для доступу до оболонки: Якщо ви забудете -t, оболонка може працювати некоректно, оскільки не буде виділено правильне інтерфейсне середовище для терміналу.
2. Запускайте команди від імені root, коли це необхідно: Деякі дії, такі як редагування файлів у /etc, вимагають підвищених прав. Використовуйте прапор --user, щоб вказати користувача root:

docker exec --user root -it my-container bash

• bash
• Copy code
• docker exec --user root -it my-container bash

1. Не порушуйте роботу контейнера: На відміну від перезапуску контейнера або змін його конфігурації, docker exec не перериває основний процес контейнера. Це безпечніший спосіб відлагодження живих систем.
   2.
   Забезпечте видимість логів: Під час роботи в контейнері забезпечте, щоб логи записувалися, адже вони надають історичний запис змін та допомагають виявляти повторювані проблеми.

Типові випадки використання docker exec

• Відлагодження аварій: Якщо додаток несподівано аварійно завершується, використовуйте docker exec, щоб безпосередньо перевірити логи або дампи пам'яті в контейнері.
• Діагностика проблем з продуктивністю: Перевіряйте запущені процеси за допомогою команд, таких як top або htop.
• Відлагодження мережі: Використовуйте інструменти, як-от curl, ping або netstat, для діагностики проблем з підключенням.
• Швидке виправлення: Вносьте виправлення в конфігураційні файли або навіть тимчасові зміни в коді під час інциденту.

Обмеження docker exec

Хоча docker exec є потужним інструментом, він має свої обмеження. Він працює на рівні додатка, що означає, що він не підходить для відлагодження глибших проблем у Linux просторах імен, таких як спільні монтування або мережеві конфігурації. Для таких сценаріїв ми звертаємось до nsenter, який буде розглянуто в наступному розділі.

docker exec є вашим надійним союзником для швидких виправлень на рівні додатка. Він показує себе в найкращому вигляді в ситуаціях, коли потрібно заглянути всередину запущеного контейнера без його зупинки, що робить його незамінним інструментом для щоденного керування контейнерами.

Частина 2: Поглиблене використання nsenter

Хоча docker exec є відмінним інструментом для більшості завдань, є моменти, коли його можливостей недостатньо. Якщо вам коли-небудь доводилось відлагоджувати мережеві інтерфейси, перевіряти спільні монтування або відлагоджувати проблеми на рівні ядра, ви, ймовірно, стикались з його обмеженнями. Ось тут і вступає в гру nsenter — інструмент, який дозволяє проникнути в простори імен Linux контейнера та працювати на більш глибокому, системному рівні.

Що таке nsenter і чому його використовувати?

Контейнери Docker покладаються на простори імен Linux для забезпечення ізоляції процесів, мережі та файлових систем. Ці простори імен ефективно створюють "міні-ОС" для кожного контейнера. В той час як docker exec взаємодіє з рівнем додатка контейнера, nsenter дозволяє вам безпосередньо отримати доступ до та маніпулювати підлеглими просторами імен контейнера.

Випадки використання nsenter:

• Перевірка та відлагодження мережі контейнера (наприклад, інтерфейси, таблиці маршрутизації).
• Перевірка точок монтування та діагностика проблем з файловою системою.
• Перегляд просторів імен процесів для відлагодження на рівні ядра.
• Відлагодження проблем, пов'язаних із спільними просторами імен у складних налаштуваннях.

Покрокова інструкція по використанню nsenter

На відміну від docker exec, nsenter вимагає деякої підготовки, оскільки він працює поза межами Docker CLI і взаємодіє з просторами імен через ідентифікатори процесів (PID). Ось як можна ефективно використовувати цей інструмент.

1. Знайдіть PID контейнера

Кожен контейнер Docker є процесом на хост-системі, і nsenter підключається до просторів імен цього процесу. Почніть з ідентифікації PID контейнера за допомогою команди docker inspect:

docker inspect --format '{{ .State.Pid }}' 

Наприклад, якщо ваш контейнер має ID abc123, виконайте:

docker inspect --format '{{ .State.Pid }}' abc123

Приклад виведення:

34567

Це число (34567) — це PID основного процесу контейнера.

2. Підключіться до просторів імен контейнера

Отримавши PID, використовуйте nsenter, щоб підключитись до бажаних просторів імен. Загальна команда для доступу до всіх відповідних просторів імен (наприклад, монтування, мережа, UTS, IPC, PID) виглядає так:

nsenter --target 34567 --mount --uts --ipc --net --pid

Це ефективно поміщає вас всередину середовища контейнера на системному рівні. Звідси ви можете запускати команди, як-от ip addr для перевірки мережевих інтерфейсів або df -h для перевірки використання диска.

3. Перевірка конкретних просторів імен

Якщо ви відлагоджуєте лише конкретний простір імен, можна звузити область пошуку. Наприклад:

• Мережевий простір імен:

nsenter --target 34567 --net  
ip addr

• bash
• Простір монтування:

nsenter --target 34567 --mount  
mount | grep /mnt

Це допоможе ідентифікувати спільні або відсутні монтування в контейнері.

4.
**Відлагодження мережі контейнера

Мережа — одна з найпоширеніших проблем в контейнеризованих середовищах. Завдяки nsenter ви можете відлагоджувати ці проблеми на більш глибокому рівні, ніж це дозволяють вбудовані інструменти Docker.

Наприклад, якщо контейнер не може підключитися до зовнішнього сервісу, ви можете використовувати команду ping або curl зсередини його мережевого простору імен:

nsenter --target 34567 --net  
ping 8.8.8.8

Якщо ping працює, але виникають проблеми з резолюцією DNS, можливо, вам потрібно перевірити /etc/resolv.conf на наявність помилок конфігурації.

Просунуті випадки використання nsenter

1. Перевірка спільних просторів імен Якщо ви працюєте з контейнерами, що ділять простори імен (наприклад, у налаштуваннях Kubernetes або з використанням флагів Docker --pid або --net), nsenter дозволяє безпосередньо перевірити спільне середовище.

Наприклад, у налаштуванні, де два контейнери ділять простір імен PID, ви можете використовувати nsenter, щоб перевірити запущені процеси в обох контейнерах:

nsenter --target 34567 --pid  
ps aux

Це покаже всі процеси, що працюють у спільному просторі імен, незалежно від того, з якого контейнера вони походять.

2. Відлагодження проблем на рівні ядра Іноді контейнери взаємодіють з функціями ядра, такими як cgroups або механізми IPC, несподіваним чином. nsenter надає безпосередній доступ до цих взаємодій, що може бути надзвичайно корисним для відлагодження.

Наприклад, щоб перевірити ліміти семафорів для контейнера:

nsenter --target 34567 --ipc  
ipcs -s

3. Відлагодження монтувань і томів Якщо контейнер не може отримати доступ до змонтованого тому, використовуйте nsenter, щоб перевірити його простір імен монтувань:

nsenter --target 34567 --mount  
mount | grep data

Це покаже всі змонтовані файлові системи в контейнері. Якщо том відсутній, це може вказувати на проблему з конфігурацією монтування на хості або налаштуваннями контейнера.

Як встановити nsenter

У більшості дистрибутивів Linux, nsenter є частиною пакету util-linux. Щоб встановити його, використовуйте менеджер пакетів вашої системи:

• Ubuntu/Debian:

sudo apt-get install util-linux

• RHEL/CentOS:

sudo yum install util-linux

Після установки перевірте його доступність за допомогою:

nsenter --help

Ключові відмінності між docker exec і nsenter

| Функція | docker exec | nsenter |
|--------------------|-------------------|------------------|
| Використання | Відлагодження на рівні додатка | Відлагодження на рівні системи |
| Охоплення | Виконання команд у shell контейнера | Безпосередній доступ до просторів імен Linux |
| Простота використання | Вбудовано в Docker CLI | Потрібен PID та окреме встановлення |
| Гнучкість | Обмежено середовищем контейнера | Повна видимість просторів імен контейнера |

Коли вибирати nsenter

nsenter є незамінним для:

• Відлагодження мережевої підключеності або маршрутизації в контейнері.
• Усунення проблем зі спільними монтуваннями в багатоконтейнерних налаштуваннях.
• Аналізу процесів між контейнерами.
• Розслідування складних проблем, пов'язаних з ядром або cgroup.

В поєднанні з docker exec для відлагодження на рівні додатка, nsenter надає низькорівневий доступ, необхідний для усунення навіть найскладніших проблем з контейнерами.

Частина 3: Освоєння фреймворків для логування

Ефективне відлагодження починається з надійних логів. В контейнеризованих середовищах логування є як рятівним канатом, так і потенційним вузьким місцем. На відміну від традиційних систем, контейнери є тимчасовими та ізольованими, що робить централізовані та доступні логи критично важливими для виявлення проблем. Незалежно від того, чи слідкуєте ви за помилками додатка, проблемами з продуктивністю або аномаліями інфраструктури, надійна система логування гарантує, що ви ніколи не залишитесь в темряві.

Розуміння стандартного логування Docker

За замовчуванням Docker використовує драйвер логування json-file. Логи, згенеровані процесами контейнерів, записуються як об’єкти JSON на хост-машині, зберігаючись локально у /var/lib/docker/containers//-json.log. Така конфігурація підходить для невеликих середовищ, але швидко стає незручним у великих виробничих середовищах з десятками чи сотнями контейнерів.

Щоб переглянути логи для запущеного контейнера, використовуйте команду docker logs.
Наприклад, щоб переглянути логи з контейнера з назвою my-app-container, запустіть:

docker logs my-app-container

Додавши прапорець -f, ви будете стежити за логами в реальному часі, як за допомогою tail -f:

docker logs -f my-app-container

Docker також надає можливість обмежити розмір і кількість файлів журналів, щоб уникнути витрат простору на диску. Ці налаштування можна конфігурувати на рівні демонів або контейнерів за допомогою параметрів, таких як --log-opt max-size і --log-opt max-file.

Просунуте логування: Перехід на користувацький драйвер

Для масштабованості та операційної ефективності більшість команд врешті-решт переходять з драйвера json-file на зовнішні драйвери логування. Docker підтримує різні драйвери логування, такі як syslog, journald, fluentd і awslogs, і це лише кілька з них. Ці драйвери дозволяють вам перенаправляти логи до централізованих систем для аналізу та довготривалого зберігання.

Щоб запустити контейнер, використовуючи драйвер логування syslog, вкажіть драйвер і параметри при запуску контейнера:

docker run --log-driver=syslog \  
 --log  
 my-app-image

Цей приклад відправляє логи на віддалений сервер syslog через UDP. Налаштуйте драйвер і параметри відповідно до вашої інфраструктури. Наприклад:

• Використовуйте fluentd для середовищ, що залежать від стеку ELK.
• Використовуйте awslogs для інтеграції з AWS CloudWatch.
• Використовуйте gcp для Google Cloud Logging.

Щоб забезпечити єдність між контейнерами, розгляньте можливість налаштування драйвера логування на рівні демонів Docker, редагуючи файл daemon.json:

{  
 "log-driver": "syslog",  
 "log-opts": {  
 "syslog-address": "udp://192.168.1.100:514"  
 }  
}

Перезапустіть демон Docker, щоб зміни набрали чинності:

sudo systemctl restart docker

Вибір правильного системи логування

Вибір системи логування залежить від ваших операційних вимог та масштабу. Ось кілька поширених фреймворків:

• ELK/EFK Stack (Elasticsearch, Logstash/Fluentd, Kibana): Ідеально підходить для масштабованих, настроюваних каналів логування. Fluentd особливо популярний для логування контейнерів завдяки своєму драйверу для Docker та підтримці структурованих даних.
• AWS CloudWatch Logs: Безперебійно інтегрується з інфраструктурою на базі AWS. Використовуйте для централізованого управління логами, моніторингу та оповіщень.
• Promtail/Loki/Grafana: Сучасний, легкий стек для агрегації та візуалізації логів. Loki інтегрується безпосередньо з Grafana для спрощених дашбордів.
• Datadog Logging: Чудово підходить для поєднання логів, метрик і трас в одному вигляді. Ідеально підходить для розподілених середовищ.

Реалізація централізованого логування для контейнерів

Для централізації логів з кількох контейнерів використовуйте драйвер логування, що сумісний з вашою обраною системою. Наприклад, щоб перенаправляти логи до Fluentd:

Запустіть контейнер Fluentd:

Розгорніть Fluentd з необхідними плагінами для вживання логів:

docker run -d --name=fluentd \  
 -v $(pwd)/fluentd.conf:/fluentd/etc/fluentd.conf \  
 fluent/fluentd

Запустіть контейнер додатка з Fluentd логуванням:

Використовуйте драйвер логування fluentd:

docker run --log-driver=fluentd \  
 --log-opt tag="my-app" \  
 my-app-image

Fluentd маршрутизує логи на основі конфігурації в fluentd.conf, дозволяючи створювати власні канали для обробки та зберігання.

Візуалізація логів: Використовуйте інструменти, такі як Kibana або Grafana для агрегації, аналізу та візуалізації логів.

Найкращі практики для логування в Docker середовищах

1. Встановіть політики обертання логів:
Логи можуть рости неконтрольовано, споживаючи місце на диску хоста. Використовуйте параметри, такі як max-size та max-file, щоб обмежити розмір файлів і зберігати тільки найновіші логи.

docker run --log-opt max-size=10m --log-opt max-file=3 my-app-image

Ця конфігурація зберігає три файли журналу по 10 МБ для кожного контейнера.

2. Тегуйте логи для полегшеного фільтрування:
При використанні централізованих систем, тегування логів допомагає відрізняти контейнери або сервіси.
Наприклад:

docker run --log-driver=syslog \  
 --log-opt tag="app-name/{{.Name}}" \  
 my-app-image

Шаблон {{.Name}} додає до тегів логів ім'я контейнера.

3. Шифрування чутливих логів:
Для логів, що передаються через публічні мережі, обов’язково забезпечте шифрування. Використовуйте такі протоколи, як TLS, з драйверами, такими як Fluentd або syslog.

4. Моніторинг та оповіщення за логами:
Налаштуйте оповіщення для критичних шаблонів логів, таких як збої додатків або аномалії в безпеці. Інструменти, як Datadog або Prometheus, можуть ініціювати сповіщення на основі вмісту логів.

Логування в багатоконтейнерних середовищах

У багатоконтейнерних налаштуваннях, таких як Kubernetes, логування стає складнішим через розподілену природу застосунків. Ось стратегії для спрощення логування в таких середовищах:

• Логування за допомогою Sidecar: Використовуйте контейнер для логування поряд з кожним контейнером додатку для збору та пересилання логів.
• Збір логів через Daemonset: В Kubernetes розгорніть колектори логів, такі як Fluentd або Filebeat, як DaemonSets для збору логів з усіх вузлів.
• Структуроване логування: Логуйте в форматах JSON або ключ-значення для спрощення парсингу та індексації.

Комбінування логування з іншими інструментами

Добре спроектоване логування доповнює інші інструменти, як docker exec і nsenter. Наприклад:

• Використовуйте docker logs для миттєвих висновків під час відлагодження додатка.
• Коли виникають більш глибокі проблеми, як відсутність монтувань або збої мережі, скористайтесь nsenter для системної діагностики, одночасно переглядаючи логи для контексту.

Частина 4: Комбінування інструментів для реальних сценаріїв

Справжня сила docker exec, nsenter та фреймворків логування проявляється, коли вони поєднуються для відлагодження складних проблем з контейнерами. Кожен інструмент має свої переваги, і разом вони створюють комплексний набір інструментів для вирішення реальних проблем без порушення роботи продакшн-систем. Давайте розглянемо кілька сценаріїв, щоб побачити, як ці інструменти працюють у гармонії.

Сценарій 1: Відлагодження контейнера з неправильним додатком

Ситуація:
Веб-додаток, що працює в контейнері, відповідає повільно, і користувачі повідомляють про періодичні тайм-аут. Логи мінімальні, і корінь проблеми неясний.

Крок 1: Перевірка логів додатка
Почніть з перевірки логів контейнера, використовуючи інструменти логування Docker. Це швидко виявить проблеми, такі як неправильні налаштування або помилки додатка:

docker logs -f my-app-container

Якщо логи показують помилки з’єднання з базою даних, наступний крок може включати перевірку конфігурації додатка або підключеності.

Крок 2: Перевірка конфігурації за допомогою docker exec
Якщо логи вказують на неправильні налаштування, використовуйте docker exec для перевірки конфігураційних файлів додатка або середовища:

docker exec -it my-app-container cat /etc/myapp/config.yaml

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

docker exec -it my-app-container vi /etc/myapp/config.yaml

Перезапустіть додаток всередині контейнера, щоб застосувати зміни:

docker exec my-app-container service myapp restart

Крок 3: Відлагодження мережі за допомогою nsenter
Якщо логи вказують на проблеми з підключенням до мережі, заглибтеся в мережевий простір імен контейнера за допомогою nsenter:

1. Знайдіть PID контейнера:

docker inspect --format '{{ .State.Pid }}' my-app-container

Використовуйте nsenter, щоб увійти в його мережевий простір імен:

nsenter --target  --net

Перевірте підключення до бази даних:

ping database.local  
curl http://database.local:5432

Якщо підключення не вдається, проблема може бути пов’язана з DNS або некоректними налаштуваннями мережі. Перегляньте /etc/resolv.conf або таблиці маршрутизації в межах простору імен для підказок.

Сценарій 2: Діагностика проблеми з місцем на диску

Ситуація:
Критичний контейнер припиняє роботу, а логи вказують на вичерпання місця на диску.
Вам потрібно визначити причину і вирішити її без перезапуску контейнера.

Крок 1: Перевірка використання диска за допомогою docker exec
Почніть з перевірки файлової системи контейнера:

docker exec my-container df -h

Якщо директорія, наприклад, /var/log, займає надмірно багато місця, знайдіть конкретні файли:

docker exec my-container du -sh /var/log/*

Крок 2: Доступ до точок монтування за допомогою nsenter
Якщо проблема пов’язана з томом, то docker exec може не показувати повну картину. Використовуйте nsenter для перевірки простору імен монтування контейнера:

Отримайте PID:

docker inspect --format '{{ .State.Pid }}' my-container

Ввійдіть у простір імен монтування:

nsenter --target  --mount

Перевірте монтування:

mount | grep data

Можливо, ви виявите, що том не змонтований коректно, або що спільний том заповнюється через логи або тимчасові файли іншого контейнера.

Крок 3: Перенаправлення логів для запобігання майбутнім проблемам
Щоб запобігти подібним проблемам, переналаштуйте контейнер, щоб використовувати драйвер логування з ротацією:

docker run --log-driver=json-file --log-opt max-size=10m --log-opt max-file=3 my-container

Сценарій 3: Відлагодження проблеми з розподіленими просторами імен

Ситуація:
Два контейнера в спільному просторі імен PID не співпрацюють, як очікувалося. Процеси, запущені в одному контейнері, здається, заважають іншому.

Крок 1: Перевірка за допомогою nsenter
Використовуйте nsenter, щоб увійти в спільний простір імен PID і перевірити працюючі процеси:

Знайдіть PID одного з контейнерів:

docker inspect --format '{{ .State.Pid }}' container-1

Ввійдіть у простір імен:

nsenter --target  --pid

Перегляньте процеси:

ps aux

Це дозволить побачити всі процеси у спільному просторі імен, включаючи процеси з інших контейнерів. Знайдіть будь-які процеси, які не повинні працювати.

Крок 2: Усунення конфліктів за допомогою docker exec
Якщо якийсь процес спричиняє проблеми, використовуйте docker exec, щоб вбити або перезапустити його:

docker exec container-1 kill 

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

Сценарій 4: Налаштування централізованого логування для легшого відлагодження

Ситуація:
Ви хочете покращити видимість у багатоконтейнерному додатку, централізуючи логи в одну систему, наприклад, Fluentd або Elasticsearch.

Крок 1: Розгортання агрегатора логів
Запустіть Fluentd як контейнер для збору та обробки логів:

docker run -d --name=fluentd \  
 -v $(pwd)/fluentd.conf:/fluentd/etc/fluentd.conf \  
 fluent/fluentd

Крок 2: Налаштування контейнерів для використання Fluentd
Оновіть контейнери додатка, щоб використовувати драйвер логування fluentd:

docker run --log-driver=fluentd \  
 --log-opt tag="my-app" \  
 my-app-container

Тепер логи перенаправляються через Fluentd і можуть бути візуалізовані в інструментах, таких як Kibana або Grafana.

Крок 3: Перевірка за допомогою docker logs
Під час тестування використовуйте docker logs, щоб переконатися, що логи додатка правильно пересилаються:

docker logs -f my-app-container

Практичні висновки

Комбінування docker exec, nsenter та фреймворків логування створює потужний, універсальний набір інструментів для управління контейнерами. docker exec чудово підходить для відлагодження на рівні додатка, в той час як nsenter дає низькорівневий доступ до простору імен Linux. Фреймворки логування, у свою чергу, забезпечують, щоб важлива інформація не губилася в хаосі розподілених систем.

Використовуючи ці інструменти разом, ви можете швидко діагностувати та вирішувати проблеми, покращувати спостережуваність і підтримувати надійне та високопродуктивне середовище контейнеризації. Будь то інцидент в продакшн-середовищі чи проактивне обслуговування, цей набір інструментів дозволить вам ефективно вирішувати будь-які проблеми з контейнерами.

Підсумок

У цьому посібнику ми розглянули практичну та потужну комбінацію інструментів docker exec, nsenter і надійних фреймворків логування для вирішення проблем з контейнерами на професійному рівні.
Ми побачили, як:

• docker exec допомагає швидко відлагоджувати на рівні додатка та здійснювати взаємодії в реальному часі всередині працюючих контейнерів.
• nsenter дозволяє отримати глибший доступ на рівні системи, входячи в простори імен Linux для відлагодження мережі, процесів, точок монтування та іншого.
• Добре налаштовані фреймворки логування забезпечують захоплення всіх критичних даних, централізацію та готовність до аналізу й моніторингу.

Застосовуючи ці інструменти разом, ви можете відлагоджувати живі системи, вирішувати складні проблеми інфраструктури та запобігати майбутнім неполадкам завдяки кращій видимості та контролю. Ці техніки є необхідними для будь-якого, хто управляє сучасними контейнеризованими середовищами в масштабах.

Як почати 🙂

1. Експериментуйте з сценаріями: Практикуйте те, що ви вивчили, у тестовому середовищі. Відтворюйте типові задачі з відлагодження, такі як перевірка точок монтування, усунення проблем з мережею та налаштування логування.
2. Автоматизуйте, де це можливо: Пишіть скрипти для спрощення повторюваних завдань, таких як отримання PID контейнера для nsenter або застосування сталих налаштувань для логування.
3. Посилюйте налаштування логування: Якщо ваші логи ще не централізовані, почніть досліджувати інструменти, такі як Fluentd, ELK або Loki, для контролю над спостережуваністю.
4. Поділіться з вашою командою: Навчіть інших ефективно використовувати ці інструменти, щоб вся команда могла оперативно реагувати на інциденти.

Якщо у вас є питання або ви хочете поділитися, як ви використовували docker exec, nsenter або фреймворки логування, залишайте коментарі нижче. Давайте зробимо це місце таким, де ми допомагаємо одне одному вирішувати проблеми швидше і розумніше. Адже нічого не перевершить навчання від того, хто вже пройшов цей шлях! 🚀

Отже, який ваш улюблений трюк для відлагодження? Поділіться! 💡

Дізнайтесь більше

[

13 способів оптимізувати побудову Docker-образів

Зменшіть розмір образу, час побудови та інше за допомогою цих технік.

overcast.blog

](/13-ways-to-optimize-docker-builds-ba1151b256f3?source=post_page-----78a2a58a2f04--------------------------------)

[

13 трюків Docker, які ви не знали

Docker став незамінним інструментом у процесах розробки, тестування та розгортання сучасних додатків…

overcast.blog

](/13-docker-tricks-you-didnt-know-47775a4f678f?source=post_page-----78a2a58a2f04--------------------------------)

[

13 оптимізацій витрат Docker, про які вам варто знати

Зі збільшенням масштабів вашого розгортання Docker зростає і потреба в стратегічному управлінні витратами. Можливість…

overcast.blog

](/13-docker-cost-optimizations-you-should-know-1f78c0accb45?source=post_page-----78a2a58a2f04--------------------------------)

[

13 оптимізацій продуктивності Docker, які вам варто знати

Оптимізація продуктивності Docker є критично важливою для підтримки ефективних і масштабованих контейнеризованих додатків. Як…

overcast.blog

](/13-docker-performance-optimization-you-should-know-57d3e5359d87?source=post_page-----78a2a58a2f04--------------------------------)

Перекладено з: Using nsenter, docker exec, and Logging Frameworks