•  unsoreh-light

На контейнерах

Використання контейнерів, що і чому

Що таке контейнери

[Контейнери] - це ім'я, надане обмеженим середовищам, що стало можливим завдяки набору підсистем у Linux, наприклад [cgroups ] та [namespaces ]. Хоча на сторінці вікі використовується це слово віртуалізація Думаю, слово ізоляція є більш доречним, оскільки віртуалізація означає, що між ними існує рівень перекладу, тоді як те, що роблять cгрупи та простори імен,-це розділяти та контекстуалізувати процеси.

Зазвичай групи C визначають політику розподілу ресурсівRAM таCPU , а простори імен керують такими контекстами, як точки монтування, мережами та користувачами. [Apparmor] натомість надає спосіб обмежити можливості для середовищ контейнерів в цілому, тоді як apparmor без контейнерів, як написано у Вікіпедії, базується на програмах.

Такі інструменти, як плоский пакет та пожежний в'язницявикористовувати контейнери для обмеження поверхні доступу до користувацьких додатків. Контейнери [Windows] реалізують еквівалентні системи, а також пропонують підтримку контейнерів Linux через [WSL].

Але чому?

Забагато?

Коли я почав будувати сосна , Я трохи експериментував з доставкою власних зображень контейнерів, розповсюджених з випусків github. Основний сценарій (trees ) команди були

Usage: trees APP [FLAGS]...
'APP'               Install apps through ostree deltas checkouts.
    -b, --base      base image (alp,trub...)
    -n, --name      same as APP (etcd,hhvm...)
    -f, --force     clear before install
    -d, --delete    clear checkout and prune ostree repo
ck, check           make sure the apps repo is mounted
co, checkout        builds the trees of links for the specified APP
    -t 	            optional path where to build the tree

Це було схоже на flatpak, оскільки я доставляв статичну дельту ostree на основі основного зображення сосни та [перевіряв] новий rootfs на основі програми, а потім запускав екземпляр контейнера поверх нього. OpenVZ мав багато проблем до версії 7 з запуском контейнера (оскільки ви знаєте ... ви запускали a вкладені container на контейнерній основі [VPS], а ядро ​​було форкомv2.6 (!))...це було величезний марна трата часу.

Коли?

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

Незважаючи на те, що контейнери - це функція, яка вам може знадобитися більшість разів, оркестровка - це не так. Я думаю слабо націлена рекламні кампанії приваблюють ненавмисне цільової аудиторії для такого програмного забезпечення, що змушує вірити, що воно може бути корисним їм , не підкреслюючи передумови, що ви справді потрібно багато масштабувати (!), щоб виправдати складність вартості таких налаштувань. Кількість зручний інструментарій побудований навколо k8s для полегшення процесу завантаження кластера k8s має бути достатнім доказом ...

Висновки

Інструменти оркестрування в кінцевому підсумку переповнюють місце для рішень по управлінню декількома хост -машинами, коли користувачі не можуть визначити різницю між серверами для домашніх тварин та худобою. У багатьох випадках таке програмне забезпечення, як ansible, pyinfra або навіть cssh або аш це все, що колись потрібно.

Теги дописів: