Чи правильно Docker підходить для мого використання?

У моїй компанії є продана нами система, яка в основному складається з міні-комп’ютера "Smartbox", на якому працює Ubuntu 12.04. Це поле запускає додаток Django плюс ряд різних процесів для запуску, пов'язаних з ним. Не багато іншого. У нас тисячі цих ящиків на полі. Ми управляємо залежностями пакунків, реєстрацією процесів тощо за допомогою дебютного пакету з різним ступенем успіху.

Нам потрібен спосіб ефективно та надійно висувати оновлення для наших користувачів на місцях. Нам також потрібно щось, що, коли ми оновлюємо ОС (ми якнайшвидше для оновлення Ubuntu, як ви можете сказати), ми можемо відчувати себе відносно захищеними щодо наших пакетів "просто працюючих".

Я мало знаю про Докера, але коли я вперше почув про нашу проблему (я новий прокат), Докер був моєю першою думкою. Але чим більше я подумав про це, я відчув, що, можливо, це не так, оскільки ці поля є нашими, ми контролюємо ОС на ньому, що є значною частиною ціннісної пропозиції Докера, або я так розумію. Тож якщо ми ЗНАЄМО, що наші коробки завжди будуть Ubuntu, і в основному ми просто маємо додаток Django плюс деякі процеси для запуску, чи Docker краще, ніж пакет дебюту?

TL; DR: Пакети Docker vs deb для розподіленого пристрою, який завжди буде працювати з Ubuntu, тому незалежність платформи не така вже й важлива.

Я не на 100% впевнений, що розумію з питання, але це здається, що рішенням Докера було б перейти від встановлення (фізичного?) Пристрою з ОС та вашим додатком, до встановлення пристрою з ОС і Доккер на ньому, запустивши єдиний контейнер із вашим додатком у ньому. Це не унеможливлює оновлення ОС на хості, і це додає шар складності (і більше оновлень, з якими можна боротися, оскільки тепер вам доведеться тримати Docker і ОС виправленими), не маючи очевидних переваг що стосується конкретних сфер, зазначених у питанні.

Однак якщо ви говорите про перехід від віртуального пристрою до контейнера Docker, це може потенційно згладити речі, але це також додасть Docker як залежність від вашого продукту; ви вимикаєте всіх, хто не використовує Docker і не хоче додавати його в свій стек лише для використання вашого продукту. Ви можете продовжувати підтримувати тих, хто не / не використовуватиме Docker, продовжуючи надсилати (тепер "застарілий") віртуальний пристрій, як і раніше, але тепер ви просто подвоїли робоче навантаження, оскільки у вас є два дистрибутиви для підтримки замість один.

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

Перш за все, ви отримуєте повторюваність. Ви можете створити Dockerfile, налагоджувати в контейнері на своїй машині розробника, запускати тести на сервері безперервної інтеграції, а потім у своєму кінцевому продукті, і ви знаєте, що він буде вести себе однаково у всіх цих середовищах. Не забуваючи про залежність, яку розробник встановив на їх машині. Крім того, ваші розробники не повинні використовувати Ubuntu за своїм столом. Важливо, щоб нас раділи користувачі Arch Linux :-)

По-друге, для вашого сценарію оновлення ви можете мати декілька версій, підтягнутих до машини відразу. Якщо ви деякий docker pull myapp:2.0час 1.0працює, ви можете поміняти місцями 2.0надзвичайно швидко. Зазвичай це займе набагато швидше, ніж повне оновлення ОС. Якщо ви використовуєте оркестратор з декількома екземплярами мікросервісів, ви навіть можете робити постійні оновлення, які взагалі не переривають службу.

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

Головний недолік - вам потрібна хост-операція і якась оркестрація. Є багато варіантів для цього, але не варто недооцінювати обсяг роботи, необхідного для його оцінки, поставити її на місце та підтримати її.

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

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

Перше питання, яке ви повинні задати (ви сказали, що ви новачок) - це те, як зараз обробляються оновлення ОС та додатків? Чи працює поточна методологія для вас (вашої компанії)? Що добре працює? Що можна покращити? Чи можете ви провести аудит фізичної конфігурації на своїх цільових машинах у цьому полі, щоб переконатися, що вони мають правильні патчі ОС, додаток та чи були несанкціоновані зміни.

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

Незважаючи на те, що Docker та упаковочні системи Debian по- справжньому вирішують дві дуже різні проблеми :

• Система упаковки Debian створена для встановлення програмного забезпечення на хості та оновлення його максимально просто. Він здатний обробляти складні схеми залежності та обмежень між компонентами програмного забезпечення, наприклад, "програмне забезпечення X версії A вимагає програмного забезпечення Y з версією B або встановленої новішої версії" або "програмне забезпечення X ніколи не повинно встановлюватися з програмним забезпеченням версії Z".

• Система Docker розроблена для легкого опису та розгортання сервісів, особливо мікро-сервісів, можливо, на кількох хостах - наприклад, рой Докер або кластер Kubernetes.

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

Зважаючи на це, мені здається, що ви дійсно шукаєте - це реалізувати незмінний шаблон сервера. Нещодавній розвиток хмарних технологій дозволив оновити програмне забезпечення не за допомогою класичної системи оновлення програмного забезпечення із системи програмного пакету (наприклад, системи упаковки Debian), а просто просто замінивши повний сервер відразу. (Деякі люди робили це до цієї розробки, маючи три ОС на сервері, два використовували по черзі для запуску пристрою та міні-ОС, призначені для заміни пристрою. Хоча це не надто складно, це, здається, завжди залишалося ніша.) Ця методика може зацікавити вас, тому що якщо ви використовуєте для оновлення програмного забезпечення на своєму сервері за допомогою менеджера пакунків, остаточний стан сервера залежить від "історії оновлення" сервера - особливо якщо помилки трапляються в процес оновлення. Ця неоднорідність погана,

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

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

Зараз існують різні варіанти впровадження незмінного шаблону сервера, два популярні варіанти - використовувати зображення Докера, зображення або використовувати "зображення головного екземпляра" від вашого постачальника хмар (вони називаються AMI в AWS і просто власні зображення в Google Compute Engine) . Ваш випадок використання забороняє використання хмарних методів, тому я вважаю зображення Докера єдиним прийнятним вибором. (Для завершення, безумовно, можна використовувати інші підходи, наприклад, використовуючи Virtual Box або подібне рішення для віртуалізації, як альтернативу Docker.)

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

Тепер, щоб розглянути конкретну проблему, яку ви описали, припустимо, що реалізація незмінного шаблону сервера за допомогою Docker - це насправді те, що ви хочете. Оскільки система Docker і система упаковки Debian є взаємодоповнюючими, а не взаємовиключними (див. Вступ), ми все ще повинні вирішити питання, чи варто ви підготувати пакет Debian для свого програмного забезпечення.

Доречність використання пакету Debian для встановлення вашого програмного забезпечення (у зображенні Docker або на хості) полягає у складності проблеми з версією, яку ви повинні вирішити. Якщо ви одночасно запускаєте декілька версій свого програмного забезпечення, періодично потрібно знизити їх кількість і мати складні вимоги до версії, які потрібно ретельно документувати, тому що пакет Debian є обов'язковим обов’язком. В іншому випадку цей крок можна пропустити - але оскільки ви вже доклали зусиль для виготовлення та розгортання цих пакунків, немає жодної реальної цінності в тому, щоб викинути свою роботу. Тому я б запропонував продовжувати виробляти ваші пакети Debian.

Я думаю, що це може бути хорошим варіантом (необхідні подальші тести)

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

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

Навіть ви можете надати користувачам можливість вибрати, яку версію з доступних вони хочуть використовувати (якщо ви хочете надати таку можливість).

Це буде як "" лише оновити один пакет "", говорити лише про отримання нової версії контейнера, набагато краще, ніж робота з пакетами debian;)

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

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