Власний хостинг почався як простий спосіб для мене отримати більше контролю над програмним забезпеченням і даними, які я використовую щодня. Але після багатьох років рекламування власних послуг я зрозумів, що змусити щось працювати часто найпростіше. Справжня проблема полягає в тому, щоб з часом жити з такими налаштуваннями. Деякі рішення, які спочатку здавалися цілком розумними, виявилися непотрібною роботою. Інші навчили мене речам, яких я не зрозумів, читаючи посібник із налаштування. Озираючись назад, цей досвід змінив мій підхід до хостингу сьогодні. Це помилки, які призвели до цієї зміни, і тих помилок, яких я б уникнув, якби почав все спочатку.
Уникав усього лише тому, що міг
Я перестав збирати окремі програми, такі як Pokémon
Моєю першою помилкою було те, що я вважав хостинг, розміщений на власному хостингу, клопотом, щоб побачити, яку частину свого цифрового життя я можу перенести на свій сервер. Якби я міг знайти альтернативу службі з відкритим кодом, якою я користувався, я б із задоволенням спробував її. Незабаром у мене з’явилися контейнери для речей, якими я майже не користувався, тому що я міг ними керувати.
Цей підхід виглядав вражаюче на папері, але він надмірно ускладнив моє налаштування. Кожна нова служба додавала ще один інтерфейс для вивчення та іншу програму, яку слід використовувати. Деякі інструменти вирішували проблеми, яких у мене насправді не було, а інші були просто веселими експериментами, про які я забув через кілька тижнів.
Нарешті я подолав запитання: “Чи можу я організувати це сам?” і почав запитувати: “Чи потрібно мені самому це проводити?” Ця невелика зміна допомогла мені створити набагато меншу установку, яку я використовую замість того, щоб зберігати купу проектів просто заради цього.
Надання послуг безпосередньо в Інтернеті
Я навчився закривати двері
Я також зрозумів на нелегкому шляху, що те, що окрема служба доступна з будь-якого місця, не означає, що вона має бути безпосередньо підключена до Інтернету. Спочатку я відкривав порти щоразу, коли мені потрібен був віддалений доступ, і не дуже думав про те, до чого я можу отримати доступ.
Такий підхід зробив речі зручнішими, але доставив мені більше речей для занепокоєння. Кожна розкрита служба ставала ще однією потенційною точкою входу, особливо коли я запускав панелі керування та панелі адміністратора, які ніколи не були загальнодоступними.
Нарешті я змінив спосіб керування віддаленим доступом. Я зберігаю більшість своїх служб за зворотним проксі-сервером із HTTPS і використовую приватні методи доступу для всього, що не має бути публічним. Я також припинив розкривати інтерфейси керування, тому що це був найшвидший спосіб дістатися до них. Тепер я свідомо налаштовую доступ до Інтернету, а не те, що я вмикаю за замовчуванням.
Резервне копіювання необов’язкове
Мої дані потребували безпеки
Деякий час я вважав резервну копію чимось, що встановлю пізніше. Якщо служба працювала нормально і всі мої файли були на сервері, я припускав, що все під контролем. Коли мені довелося мати справу з втраченими або пошкодженими даними, я зрозумів, як невелика проблема може перетворитися на більшу проблему.
Тепер резервне копіювання є частиною налаштування будь-якої служби, яка зберігає важливі дані. Я створюю резервні копії файлів, баз даних і даних програм, які важко або неможливо замінити. Я також зберігаю резервні копії в кількох місцях замість того, щоб повністю покладатися на одну машину, на якій працюють мої служби.
Найважливіше те, що я автоматизую процес резервного копіювання. Я не хочу запам’ятовувати резервну копію кожні кілька днів. Налаштування самостійного керування дають мені змогу контролювати свої дані, але цей контроль корисний лише тоді, коли у мене є надійний спосіб повернути їх.
Я перестав гнатися за кожним новим оновленням
Я ставився до кожного доступного оновлення як до того, що потрібно негайно встановити. Щоразу, коли я відкривав інформаційну панель Docker і бачив список нових версій зображень, я оновлював кілька служб одночасно. Це був хороший спосіб підтримувати порядок, але часто створював проблеми, яких я не очікував.
Оновлення можуть змінити спосіб роботи програми, видалити параметри або створити проблеми сумісності з іншими компонентами. Коли кілька служб оновлюються разом, стає набагато складніше зрозуміти, що спричинило проблему.
Тепер я вибираю повільніший підхід. Для служб, на які я покладаюся щодня, я перевіряю примітки до випуску перед оновленням і уникаю внесення кількох серйозних змін одночасно. Я також даю новим версіям деякий час, перш ніж зайти, особливо якщо в додатку є історія критичних змін. Важливо підтримувати все в актуальному стані, але я більше не плутаю «актуальне» з «необхідним».
Документи обов’язкові
Мені потрібні кращі нотатки в майбутньому
Раніше я вносив невеликі зміни до своїх налаштувань, не записуючи їх, тому що був упевнений, що пам’ятаю, що зробив. Це працювало, поки мені не довелося вирішити проблему через кілька місяців. Я дивився на файл збірки або конфігурацію, і я не знаю, чому є певний параметр або що станеться, якщо я його видалю.
Тепер я задокументую зміни, які не є очевидними. Я занотую спеціальні конфігурації, порти, шляхи до папок, змінні середовища та будь-які незвичайні дії, необхідні для запуску служби. Я також упорядковую свої файли збірки замість того, щоб залишати важливу конфігурацію розкиданою по різних папках.
Це мене не раз рятувало при відновленні або зміні служби. Мені не потрібно покладатися на пам’ять чи переказувати старі повідомлення на форумі, щоб зрозуміти, що я зробив. Самостійний хостинг уже містить достатньо рішень. Я не хочу, щоб мої забуті рішення стали ще однією проблемою.
“Я пам’ятаю, як я це влаштував” – це міф.
Хостинг стає кращим, коли ви його спрощуєте
Після багатьох років роботи з власними службами я зрозумів, що самостійне розміщення не є найбільш вражаючим налаштуванням. Йдеться про створення чогось, що надійно працює без моєї постійної уваги. Помилки, яких я зробив, навчили мене думати не лише про початкові налаштування, а й розглядати довгострокові зусилля. Тепер я менше зосереджуюсь на досвіді, а більше на створенні середовища, в якому мені комфортно жити.
