Fox Mulder (fox_mulder_cp) wrote,
Fox Mulder
fox_mulder_cp

Про основную работу и проект, над которым я работаю.

Многие из моих друзей и знакомых знают, что последние несколько лет моя работа неразрывно связана с хостингом сайтов, почты и регистрацией доменных имён, а путь от инженера технической поддержки (одного из известных и больших украинских операторов) хостинга до хостмастера состоит из нуля промежуточных пунктов.
Итак, что мы имеем на обычном захудалом хостинге?

Ок, кратко для справки и без подробностей - когда в СНГ пошел к подьему рынок "хочу быстро сайт в интернете запилить, чтобы быть крутым, а то компания как лох, без сайта", хостеры и регистраторы стали плодиться как грибы, результат - рынок регистраций доменов, хостинга и реселлинга крупных ЦОДов вроде OVH/Hetzner адово перегружен.
И насколько я могу судить, не очень то и прибылен, если вы не огромный оператор со своими ЦОДами.

Так вот, на обычном хостинге у нас обычно пару вариантов. Далее следует немного печали из моего собственного опыта:
Вариант 1 - Apache + MySQL + PHP для обслуживания сайтов, ftp для загрузки, почтовый сервер вроде Postfix/Exim с каким-то из пятёрки популярных более менее симпатичной веб интерфейсом, пара днс серверов и, если повезёт, клиент EPP для регистрации доменных имён через кого-то из крупных регистраторов. и иногда какая-то админка (иногда с дизайном а-ля розовые слоники).

Вариант повеселее, но и печальней - У нас более менее нормальный сервер, куплена CPanel/Plesk или стоит какая-нить VestaCP/Ispconfig/IspManager - у которых с одной стороны всё получше чем у предыдущего
вариантва, так как комьюнити у Plesk/CPanel/Vesta получше и побольше, есть платная поддержка,

Отсюда вытекает большой минус, который я вижу - вендор-лок, исправление багов с вариантом "Да, этот баг есть, но исправлен в новой версии $панели, покупайте новую версию", но все помнят инцидент с ftp сервером у Plesk, когда исправления на критический баг было выпущено через несколько месяцев?
Или же закрытие тикетов автором с комментариями класса "что-то лениво"/"так себе баг", через полгода после открытия тикета.

Один раз я укрощал сервер с LoadAverage ~1000 сидя в холле кинотеатра через Edge розданный с телефона жены. :) адски совпала по времени спам рассылка с четырёх проломанных клиентских аккаунтов + DoS на сайт.


Теперь причины, приведшие меня к написанию своего реешения:
1. меня АДСКИ бесит, что всё, что касается конкретного клиента - почта, днс, сайты, и базы данных... Правильно, живут на одном сервере. В случае DoS атаки на одного клиента/сервис - правильно, в 90% вариантов - сервер становится в позу, даже с лимитами, к сожалению.
2. время исправления багов может зависеть и отличаться что у платных, что бесплатных панелей - SQL Injection я уже на горячую фиксил, даже не зная PHP :(
3. Один проксирующий Nginx на хост я понять могу, но перезагружать Apache, когда на хосте несколько тысяч сайтов, и когда два десятка пользователей решило что-то изменить в настройках своих виртуалок одновременно - это уже большое количество времени.
4. Количество говнокода в паре панелек, что я видел, иногда зашкаливает. Чего стоит только свой крон сервис, который дергается из штатного системного крона, но в котором НЕТ проверок на живость базы данных и одновременную загрузку нескольких инстансов себя же. В общем, нужные проверки в код этого "планировщика" я
попросил впилить знакомого.
5. Функционал зачастую "фичаст", но АДОВО перегружен и пугает клиентов "А можно выключить лишнее?"

===================================================
А теперь что я использовал при старте написания своего решения по управлению хостингом приложений и идеи, которые лежат в его основе:

0. Linux как сервер для платформы
1. PostgreSQL как хранилище данных проекта.
2. Ruby on Rails как веб приложение.
3. Resque + Redis для выполнения длительных задач.
4. Ansible как часть системы управления.
5. Nginx как кеширующий прокси сервер.
6. PowerDNS + PG как NS сервер и рекурсор, на котором хранятся внешние и внутренние dns зоны.
7. LXC и Docker как системы управления виртуальными машинами и контейнерами.

Главная идея хостинга в том, что он хостит приложения, а не сайты, так как WordPress или Joomla - это частный случай, на самом деле, технически есть возможность и страниц заглушек/редиректов (например https://blog.sites.mulder.kiev.ua/) и статических сайтов, вроде того, что с февраля живёт у меня на основном сайте http://mulder.kiev.ua/, и планируется активное использование git, например забрать на сервер образ приложения откуда-то с клиентского сервера.


По умолчанию идёт образ Apache+PHP, и все контейнеры имеют собственный сервер приложений и PHP с полностью независимыми настройками, свой внутренний IP адрес контейнера, по которому через внутреннюю зону DNS ходит проксирующий сервер, со своими лимитами процессов, памяти, процессора, сети и iops'ов

Это всё планируется как кластер серверов приложений, где по OSPF с внутренними сетями все ноды могут достучаться перекрёстно до контейнера на "чужом" узле. Единственный затык - выбрать кластерную файловую систему master-master.

Естественно, кроме самого хостинга приложений, планируется управление DNS, почтой, базами данных, и регистрациями доменных имён, а так же биллинг и API к этому всему.




Это первый и самый сложный этап, поскольку это первый боевой проект на Rails :)
Tags: docker, it, rubyonrails, работа, разработка
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 3 comments