Від ідеї до продакшну: що насправді чекає розробника після деплою пет-проекту в хмару

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Здавалося б, що може бути простішим після завершення розробки: купити домен, підняти віртуалку у хмарі — і проєкт готовий підкорювати світ. Багато ІТ-компаній розглядають наявність власних проєктів як вагомий «плюс» на співбесіді, що підштовхує розробників створювати щось своє заради портфоліо. Але про те, з якими реаліями та викликами стикається новачок ДО і ПІСЛЯ запуску, пишуть напрочуд мало.

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

Пошук хмари: де розгорнути проєкт і не збанкрутувати

Звісно, великі компанії мають штат DevOps-інженерів, які вирішують інфраструктурні завдання без проблем. Але як бути розробнику-одинаку, коли твій проєкт написаний на Java та MySQL?

Пошук оптимального й бюджетного рішення перетворився на окремий квест.

1. AWS: досвід із кредитними 300$

Першим я вирішив «обкатати» AWS, скориставшись стартовим кредитом. Функціонал платформи вражає, все продумано до мікродеталей, та й запуск пройшов відносно легко. Але виявилися нюанси:

• Віртуальна машина (EC2) та база даних (RDS) оплачуються окремо.
• Налаштування вимагає досвіду, адже ціна залежить від кожної дрібниці.
• Найголовніший біль — найдешевші інстанси регулярно «злітали» під навантаженням.

Після кількох годин пошуку стабільності «чарівною пігулкою» став перехід на дорожчі версії ВМ та потужнішу БД із загальним цінником приблизно у 30$ на місяць. Про використання балансувальників навантаження чи складних оптимізаторів тоді й мова не йшла. Як наслідок — мої 300$ кредиту випарувалися за 3 місяці. Висновок: за все «класне» в AWS треба платити чималі гроші, що зовсім не практично для пет-проєкту.

2. Heroku: мій непідходящий стек

Наступною спробою стала міграція на Heroku. Результат теж виявився невдалим: платформа працює виключно з PostgreSQL. Переписувати й переналаштовувати проєкт із MySQL заради цього виявилося абсолютно невиправдано з погляду витрачених ресурсів та сил.

3. DigitalOcean: компроміс знайдено

Зрозумівши, що «халяви» немає, для фінального тесту життєздатності проєкту я обрав DigitalOcean.

Вивчивши варіанти економії, знайшов чудове рішення: взяти одну віртуальну машину і розгорнути все необхідне (Java-сервер, Nginx та MySQL) на одному диску всього за 4$ (без податків).

Звісно, найдешевше залізо виявилося занадто слабким для масивної бази даних. Виходом став перехід на трохи потужнішу ВМ за 6$ на місяць (замість того, щоб платити окремі 15$ за керовану базу даних). Цього бюджету виявилося цілком достатньо для повноцінної роботи проєкту.

Етап «ПІСЛЯ»: коли починається найцікавіше

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

1. Безпека SSH та відкритий порт 22

Мій перший гіркий досвід — налаштування доступу до бази даних із програми dbForge Studio через SSH із входом за звичайним паролем. Це непомітно залишило відкритим 22-й порт.

Головне застереження: ніколи не давайте прямий дозвіл на вхід під суперкористувачем (PermitRootLogin yes), адже це полегшує завдання зловмисникам на 50%. Єдине надійне рішення для продакшну — суворе використання SSH-ключів.

2. Ботоферми на реєстраціях та захист форм

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

limit_req_zone $binary_remote_addr zone=demo_limit:10m rate=1r/s;

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

Що допомогло? Елегантний та простий прийом — honeypot (приховані поля) у формах входу.

• У форму додається приховане поле: <input name="website_url_check">
• У CSS воно маскується через position: absolute; left: −9999px; (люди його не бачать, а боти заповнюють за звичкою).
• У Java-контролері спрацьовує перевірка: @RequestParam(value = «website_url_check», required = false).

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

Замість висновків

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

Поділіться в коментарях своїм досвідом: з якими несподіванками ви стикалися під час першого деплою власних пет-проєктів? Чи варто взагалі морочитися з хмарами, чи простіше весь код залишити на GitHub?