Переберіть VPN-пристрій на Raspberry Pi, не копіюючи його ключ

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

Кроки нижче — це порядок роботи, а не рекомендація інструмента. Підійде будь-яка система конфігурації, здатна їх виразити.

Спочатку перелічіть чотири види входів

Базовий образ і його пакети визначають операційну систему, архітектуру та джерело оновлень, а збирач образів допомагає лише якщо названий ним інструмент досі підтримується для вашого випуску. Оголошена конфігурація — це частина, яку перевіряє людина: мережеві ролі, налаштування служб і дії життєвого циклу, потрібні кожній службі. Постійні дані застосунку — усе, що служба не може відтворити, а їхнє розташування й спосіб резервного копіювання належать цьому застосунку, а не образу. Ідентичності пристроїв і секрети — четвертий вхід, і саме про них забувають, клонуючи робочу картку.

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

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

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

Перевірка проста: якщо репозиторій завтра витече, що отримає зловмисник? Шаблони й нотатки про топологію переживуть. Робоча ідентичність — ні.

Нехай автоматизація володіє тим, що може перезапустити

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

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

Відновлюйте дані та ідентичність свідомо

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

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

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

Завантажувальний образ — один вхід із чотирьох, і його найлегше відтворити.