Англійська для розробників Podman

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

Ключовий словник

** Без фонової служби ** — архітектура Podman, де кожен контейнер виконується як безпосередній дочірній процес команди, яка його запустила, без довготривалого фонового фонового процесу, який координує контейнери. “Оскільки Podman не має фонової служби, вбивство батьківської оболонки у цьому скрипту фактично вбиває контейнер — з Docker, фонова служба продовжувала б його роботу незалежно.”

** Контейнер без права адміністратора ** — контейнер, який виконується повністю у просторі імен користувача без привілеїв, не вимагаючи привілеїв адміністратора на вузлі, зменшуючи радіус атаки, якщо контейнер буде порушено. “Ми мігрували CI-запуски до контейнерів без кореня, щоб контейнер не передавав атакуючому кореневий доступ до вузла — це було головним чинником безпеки.”

Pod (в Podman) — група одного або декількох контейнерів, які спільно використовують мережевий простір імен і можуть керуватися як єдиний об’єкт, моделюється безпосередньо на концепції pod Kubernetes. “Замість того, щоб вручну встановити спільну мережу між цими двома контейнерами, помістіть їх у один і той же під Podman — саме для цього і призначені піди.”

** Призначення простору імен користувача ** — механізм, який відповідає внутрішньому UID контейнера (зазвичай root, UID 0) для неприватизованого UID на вузлі, що робить контейнери без root безпечними. “Помилка дозволів, оскільки файл був записаний за UID контейнера, який не збігається з користувачем вашого вузла — перевірте відповідність суб- UID.”

Quadlet — інтеграція systemd для Podman, яка надає вам змогу визначати контейнери, підсистеми і томи як власні файли одиниць systemd, таким чином, керування ними здійснюється за допомогою стандартних команд systemctl. “Замість скрипту оболонки з командою podman run і завдання cron для перезапуску, визначте це як блок Quadlet, щоб systemd правильно керував його життєвим циклом.”

** Підписання зображень ** — криптографічне підписування зображень контейнерів, щоб користувачі могли перевірити походження і цілісність перед їх завантаженням і запуском, це практика безпеки, яку Podman підтримує за допомогою skopeo і файлів правил. “Перед тим, як прив’ язати сторонні штампи до кластера, давайте встановимо перевірку підписування штампів у політиці прив’ язки замість довіри лише реєстру.”

Звичайні фрази

• «Чи працює цей контейнер без кореня, або йому все ще потрібен корінь на хості?»
• Чи повинні ці два контейнери бути згруповані в під, а не керуватися окремо?»
• Чи є це проблемою відображення UID, або справжньою проблемою дозволів всередині контейнера?»
• Чи можемо ми керувати цим з Quadlet unit замість shell script і cron job?
• Чи перевіряємо ми підписи зображень перед витягуванням, або довіряємо реєстру неявним чином?»

Приклади висловлювань

Перегляд запиту на звантаження: “Цей скрипт розгортання припускає, що фонова служба завжди запущена для перезапуску контейнера після аварії — оскільки ми працюємо на Podman, визначимо блок Quadlet і дамо systemd обробляти перезапуски замість цього.”

Пояснення рішення про проектування: “Ми вибрали контейнери без кореня для агентів збирання спеціально, щоб компрометований скрипт збирання не міг отримати корінь на вузлі - додаткова складність відображення UID була вартою цього обмеження безпеки.”

Опис вади: “Контейнер міг записувати до свого власного тома, але процес вузла не міг прочитати файли після цього — це було відображення простору імен користувача, а не помилка з правами доступу у програмі.”

Професійні поради

• Виразно скажіть “daemonless”, коли пояснюєте, чому життєвий цикл контейнера Podman відрізняється від Docker — це єдина найважливіша архітектурна відмінність, яку варто назвати.
• Під час зневадження проблем з правами доступу до файлів з контейнерами, запитайте “чи це проблема з відображенням UID?” перед тим, як припустити помилку на рівні програми — це дуже поширена проблема, характерна для безкореневий операційних систем.
• Використовуйте “pod” так, як це робить Kubernetes (спільна група контейнерів) при обговоренні Podman — терміни навмисно вирівняні.
• Розрізняйте « rootless » (не потрібні привілеї root на вузлі) від « root у контейнері » (внутрішній користувач контейнера, який все ще є лише відображеним UID вузла без привілеїв) — їх об’ єднання є поширеним нерозумінням.

Практичні вправи

1. Поясніть двома реченнями, чому відсутність фонової служби у Podman змінює спосіб розробки стратегії перезапуску при аварії.
2. Напишіть одне речення з поясненням, чому контейнер без кореня зменшує ризики безпеки.
3. Опишете вашими словами, що таке одиниця Quadlet і чому ви віддаєте перевагу використанню цієї одиниці замість необробленої команди podman run у скрипту.

Навигація по лінії — практичний підхід

Оскільки розробники стають більш знайомими з такими термінами, як «rootless», «pod» і «daemonless» в контексті технологій контейнеризації, таких як Podman, ефективне спілкування стає надзвичайно важливим. Часто ці обговорення не обмежуються статичною документацією; вони відбуваються динамічно в переглядах коду, каналах Slack і описах запитів на витягування. Критична вміння - це розуміння * як * розробники формують зворотній зв’язок, а не тільки самі технічні деталі. Це виходить за рамки простого розуміння визначення «незмінного» або «державного», а також розуміння нюансів, пов’язаних з очікуваннями змін і співпраці.

Розглянемо цей сценарій: Сара надсилає запит на звантаження, щоб додати журналювання до основного компонента програми, заснованої на Podman. Під час перегляду коду, Девід залишає коментар, в якому йдеться: «Це добре, але чи можемо ми додати більше контексту до повідомлень журналу? Поки що це лише « [компонент] - [подія] ». Це ускладнює зневадження, коли ми не знаємо * чому * подія сталася. “Це не критика самого коду; це запит на пояснення і поліпшення документації - поширений шаблон у спільній розробці. Аналогічно, уявіть, що ви отримуєте повідомлення Slack: «Гей, команда, щойно зіткнулася з проблемою з налаштуванням мережі Podman. Чи хтось має досвід з перетинанням контейнерів? “Фраза є відкритою, шукає спільні знання, а не рекомендативне рішення.

Ефективне спілкування також поширюється на опис * роздумів * за рішеннями. Замість того, щоб сказати « Давайте використаємо цей новий штамп », розробник може пояснити: « Ми повинні використовувати цей оптимізований базовий штамп, щоб зменшити розмір нашої програми і поліпшити час запуску — відповідно до наших цілей швидкодії ». Або, під час документування зміни у налаштуванні Podman, вони можуть сформулювати: « Ця модифікація дозволяє нам ізольувати контейнер бази даних, підвищити безпеку і запобігти випадковим перешкодам з іншими службами у піді »

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

Ось проста команда Podman, яка показує, як перевірити параметри мережі контейнера:

podman net inspect my-container --format json

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