Як реалізувати незмінну схему сервера, не втрачаючи можливості робити посмертні справи?

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

Популярним аспектом реалізації цієї дисципліни є видалення методів віддаленого доступу до сервера після його запуску (наприклад, видалення доступу до SSH). Видалення віддаленого доступу - це простий спосіб переконатися, що конфігурація сервера відповідає конфігурації, підготовленій автоматизацією розгортання.

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

Як реалізувати незмінну схему сервера, не втрачаючи можливості робити посмертні справи?

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

Один із способів зберегти своєрідне посмертне - це централізація журналів. Існує безліч методів для досягнення цього, стек ELK, Splunk, syslog ...

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

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

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

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

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

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

Крім цього, як @Tensibai сказав, що краще зробити належну настройку реєстрації та моніторингу, тож у будь-який час вам доведеться робити посмертний доступ, для цього є достатньо даних.