The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск сервера приложений NGINX Unit 1.6

16.11.2018 08:23

Представлен выпуск сервера приложений NGINX Unit 1.6, в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования (Python, PHP, Perl, Ruby, Go и JavaScript/Node.js). Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Код написан на языке Си и распространяется под лицензией Apache 2.0. С особенностями NGINX Unit можно познакомиться в анонсе первого выпуска.

Основное внимание при подготовке новой версии было сосредоточено на улучшении работы модуля поддержки платформы Node.js и обеспечении его совместимости с различными приложениями. Сборочная команда "make install" теперь устанавливает модуль к Node.js, если он отмечен для сборки. В скрипт "configure" также добавлена опция "--local" для локальной установки модуля Node.js.

  1. Главная ссылка к новости (http://mailman.nginx.org/piper...)
  2. OpenNews: Обновление nginx 1.14.1 и 1.15.6 с устранением трёх уязвимостей
  3. OpenNews: Релиз njs 0.2.5, интерпретатора JavaScript от NGINX
  4. OpenNews: Выпуск сервера приложений NGINX Unit 1.5 с поддержкой Node.js
  5. OpenNews: Первый стабильный релиз сервера приложений NGINX Unit
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49619-nginx
Ключевые слова: nginx, unit
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, max (??), 08:44, 16/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Господа,

    Кто использовал? СтОит, не стОит? Поделитесь пожалуйста впечатлениями. )

     
     
  • 2.2, Eduard (??), 09:03, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Сейчас в kubernetes приходится делать nginx sidecar в pod, чтобы проксировать в uwsgi приложение.
    С nginx unit все упрощается - nginx + uwsgi заменяется на nginx unit.

    Однозначно стоит.

     
     
  • 3.28, Аноним (28), 20:12, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Во-первых, у приложения интерфейс не uwsgi, а WSGI. usgi — это одна из реализаций wsgi application server-а и одноименный бинарный протокол, придуманный авторами uswgi.
    Во-вторых, большинство wsgi app-серверов (включая uwsgi) умеют отвечать по http.
     
  • 3.31, Аноним (31), 21:41, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >С nginx unit все упрощается - nginx + uwsgi заменяется на nginx unit.

    Вообще-то uwsgi может выступать в качестве веб-сервера. По сему в связке nginx + uwsgi, nginx лишний.

     
     
  • 4.33, Аноним (33), 22:04, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Оу, у нас иксперды в треде
     
     
  • 5.43, Аноним (43), 02:19, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Подселять по энжиниксу к каждому экземпляру uwsgi действительно излине. Большую часть того, что бэкендеры обычно хотят от творения Сысоева, успешно можно сделать средствами uwsgi (рерайты, редиректы, работа с заголовками итд). Остальное уже спокойно делается на тех энжиниксах, которые балансируют нагрузку между бэкендами (тем более, что у любителя энжиникса в сайдкарах по определению кубернетес и, скорее всего, используются ингрессы с энжиниксом)
     
  • 3.66, user455 (?), 16:57, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а пайтоновские фреймворки сами как веб сервер не умеют запускаться?

    зачем там нужен нгинкс в каждом контейнере?

    нгинкс логично ставить на балансер, а там аппликейшн саппорт как-то и не нужен. разве нет?

     
  • 2.3, Аноним (3), 09:07, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • –9 +/
    Так посмотри на список поддерживаемых языков/платформ:

    > Python, PHP, Perl, Ruby, Go и JavaScript/Node.js

    Пихон, пых, устаревший перл, нескучный руби, го-секта и вспомнити лефтпад.

    Я бы дождался поддержки Java для начала. С ее появлением уже может пойти речь о чем-то взрослом, серьезном.

     
     
  • 3.4, ыы (?), 09:12, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +13 +/
    > Python, PHP, Perl, Ruby, Go и JavaScript/Node.js

    Мэйнстрим,  суперпопулярный, стабильная классика, популярный с отдельных кругах, активно развиваемый суперкорпорацией, суперпопулярный среди молодежи.

    Да кому она нужна ваша дырявая и сдыхающая жаба?

     
     
  • 4.5, Аноним (3), 09:56, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А вот и любители смузи-динамических языков подъехали. Ну как там, электрон оперативку жрет?
     
  • 4.9, Аноним (9), 12:42, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Под Явой весь корпоративный сектор, более того, на Яву меняют, тихо но уверенно, всё, что написано на Коболе, а это вся фин.индустрия мира. Но в шалашах по клепанию всяких свистоперделок для вебни об этом не в курсе, у них там полный смузи электрон по самые гланды.
     
     
  • 5.10, Аноним (10), 12:50, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На яве пишут бизнес-логику, а сам бэкенд на других языках. Тот же paypal сменил бэкенд на Node.js. Не надо здесь диванной аналитики, т.к. на опеннете есть люди, которые в этой сфере работают. Не позорься.
     
     
  • 6.11, Аноним (9), 13:26, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дя-дя, букенд там у него на других языках. Вся ява там крутится на серверах приложений, которые в шкафах от оракела или ибма исполняются, а не на "других языках".
     
     
  • 7.12, Аноним (9), 13:31, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И в качестве букенда стоят rdbms-ы. И никаких "других языков" типа C++ и, тем более, всяких смузи-электронов, там нет и в помине.
     
  • 6.13, ананим.orig (?), 13:39, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > На яве пишут бизнес-логику, а сам бэкенд на других языках. Тот же paypal сменил бэкенд на Node.js. Не надо здесь диванной аналитики, т.к. на опеннете есть люди, которые в этой сфере работают. Не позорься

    #s/бэкенд/фронтэд/

     
     
  • 7.14, Аноним (10), 13:53, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не, фронтенд там nginx обычно (я не про браузер-сайд).
     
     
  • 8.15, powershell (ok), 14:05, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прошу заметить, что в обсуждаемых архитектурах может быть несколько пар фронтенд... текст свёрнут, показать
     
  • 5.24, Аноним (24), 18:04, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты хорошо яву с коболом сравнил. Звиняй, для реального мира навозная яма в которой копошатся банкиры и финансисты со своими коболами, жавами, 1C и оракалами совершенно побоку, тем более как ориентир для выбора технологий. Это не взрослость, это просто узкоспецифичная вонючая навозная яма. Реальный мир выбирает работающие технологии, а не ынтерпрайзную маркетинговую лапшу.
     
     
  • 6.29, Аноним (9), 21:24, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Реальный мир выбирает работающие технологии

    Чуть-чуть не проговорился про docker, вот смешно было бы, в контексте разговора про "работающие технологии".

     
  • 6.30, Аноним (9), 21:27, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Эти "работающие технологии" меняются раз в пять лет. А Кобол с Явой как были так и остаются. Более того, именно они прокручивают самые ответственные системы мира этого. Но смузиедам с докером и электроном головного мозга этог не понять, не доросли.
     
     
  • 7.39, ананим.orig (?), 23:06, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > они прокручивают самые ответственные системы мира этого.

    Не поэтому ли ли он в опе? :D

     
     
  • 8.42, Аноним (9), 00:11, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    По всем аспектам, прежде всего по количеству бабла, которое крутится в индустрии... текст свёрнут, показать
     
  • 8.50, Ку (?), 15:59, 18/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Тут нужно просто понимать инфантильную подростковую психологию, не более Вопрос... текст свёрнут, показать
     
  • 3.16, Valentin V. Bartenev (?), 14:13, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Поддержка Java активно разрабатывается:
    https://github.com/mar0x/unit/tree/java/src/java

    Уже даже можно начинать пробовать и оставлять отзывы. Приложения на Spring (Boot) будут работать из коробки: https://github.com/nginx/unit/issues/31#issuecomment-435018408

    Скоро инструкцию туда положим.

     
     
  • 4.18, Аноним (18), 15:02, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Спасибо, это хорошая новость.

    А можно поинтересоваться, почему начали именно с языков семейства "пыхоплеяда"? Я тут помнится выражал мнение, что вы начали с самых тормознутых языков, -- тушить, так сказать, пожары, устроенные пыхерами. А в Java-экосистеме и без юнита все хорошо (но с юнитом станет лучше благодаря выносу работы с протоколом на уровень ниже). Но хотелось бы услышать с первых уст.

     
     
  • 5.21, Аноним (21), 16:00, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что там, где повсеместно используется ява, быстро внедрять nginx unit все равно не начнут в силу консерватизма.
     
  • 5.22, KonstantinB (ok), 16:26, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я не знаю, но могу предположить.
    Интеграция того же php элементарна - пишется свой sapi-модуль и готово.
    А вот интегрировать с jvm их протокол на основе shared memory - это задача на порядок сложнее.
     
  • 5.23, Valentin V. Bartenev (?), 17:43, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это семейство языков имеет простой API для веб-приложений и легко интегрируется. Написать обертку очень просто, речь идет о считанных днях разработки. Над Java работа идет уже несколько месяцев и где-то столько же ещё впереди.

    Кроме того, практически вся Java - это различный энтерпрайз и вход туда требует гораздо больше начальных усилий. И то, что по-русски называется "минимально жизнеспособный продукт" - также требует больше усилий, чем, например, личный бложик на вордпрессе запускать.

     
  • 5.34, vitalif (ok), 22:27, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чего там хорошо в этой яве? До сих пор на аппсерверах все сидят, и что-то кажется мне, что никуда и не слезут уже никогда...
     
     
  • 6.51, Ку (?), 16:22, 18/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Субъективные понятия "хороший" и "плохой" применимы только к конкретной ситуации.
    Язык это всего лишь инструмент. Если он тебе не нравится, не выбирай его, выбирай то, что нравится.

    Кому какое дело какими кистями и красками пользуется художник?
    Ты когда нибудь слышал, чтобы кто-нибудь говорил что-то подобное: "Это картина не красивая, потому что художник использовал не ту кисть"?

     
  • 2.19, jOKer (ok), 15:12, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, как по мне так он не очень нужен. В Docker Swarm Node/Kubernetes для проксирования апи, ИМХО, куда лучше работает traefik (из коробки интеграция со всеми популярными kv-хранилищами и каталогами service discovery), а для раздачи статики - проще использовать чистый nginx на выделенных серверах  - его все админы знают, да и вообще старый конь борозды не испортит. Где тут место сабжа, лично я не очень понимаю.
     
     
  • 3.20, Аноним (9), 15:35, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Эта Docker Swarm глючная до невозможности, как и всё, что относится к этим всем "новомодным". А nginx-стабильнейшая и жутко производительная софтина (особенно на фоне всего этого новомодного шлака). Если сабж будет таким же как и сам nginx-будем непременно юзать его, вместо всех этих "новомодных"
     
     
  • 4.40, Аноним (10), 23:10, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    1. nginx всего на 5 лет старше ноды, они почти ровесники.
    2. nginx не всегда выигрывает по производительность у той же ноды.
     

  • 1.17, InuYasha (?), 14:25, 16/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Приложением льда ко лбу им надо заниматься.
    А программы пишут на C/C++.
     
     
  • 2.27, НяшМяш (ok), 20:02, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Так и новость про то, что вышла новая версия _программы_ для запуска _приложений_.
     

  • 1.32, Аноним (31), 22:03, 16/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Вот объясните мне плиз, люди добрые. В докладе (https://www.youtube.com/watch?v=GK6xAOVRTcg) сказано, что nginx взаимодействует с unit через разделяемую память минуя сетевой стек. А в документации сказано, что обращаться нужно к unit нужно через сокет, типа:

    upstream php_upstream {
        server 127.0.0.1:8090;
    }

    Это как понимать? Принцип обращения через разделяемую память еще не реализован?

     
     
  • 2.36, Valentin V. Bartenev (?), 22:33, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Речь идет о взаимодействии между процессом роутера, который асинхронно принимает и обрабатывает клиентские соединения и процессами приложений. Всё это части Unit'а и об nginx речи не идет.

    В документации в разделе "Integration with NGINX" рассказано о том, как можно запроксировать Unit, при желании. Но по мере обрастания возможностями, необходимости в этом будет всё меньше и меньше.

     
     
  • 3.37, Аноним (31), 22:45, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Валентин, спасибо как за ответ, так и за интересный доклад.

    Все же остается не понятным то, чем Unit отличается от любого другого сервера приложений в разрезе цепочки взаимодействия от запускаемого приложения до nginx. Тот же uWSGI так же используется разделяемую память между мастер процессом и воркерами.

     
     
  • 4.38, Valentin V. Bartenev (?), 23:03, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Валентин, спасибо как за ответ, так и за интересный доклад.
    > Все же остается не понятным то, чем Unit отличается от любого другого
    > сервера приложений в разрезе цепочки взаимодействия от запускаемого приложения до nginx.
    > Тот же uWSGI так же используется разделяемую память между мастер процессом
    > и воркерами.

    Насколько я знаю, разделяемая память там другим целям служит, а master процесс, также как и в nginx, не занимается обработкой запросов. В Unit-е есть свой такой мастер-процесс для порождения новых процессов, открытия слушающих сокетов и лог-файлов.

    Основное отличие в том, что Unit с самого начала проектируется чтобы смотреть наружу, в интернет, а не прятаться за реверсивным прокси. Там уже, условно говоря, есть свой, встроенный nginx - процесс роутера. Поэтому он прекрасно держит нагрузку в то время, когда uwsgi сливается: https://itnext.io/performance-comparison-between-nginx-unit-and-uwsgi-python3-

     
     
  • 5.41, Valentin V. Bartenev (?), 23:38, 16/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Сама внутренняя архитектура у Unit'а такова, что ему concurrency абсолютно до лампочки, 10 клиентов к нему придут с запросами или миллион - он будет продолжать обрабатывать запросы не снижая эффективности.

    Вот даже глядя на график в статье по ссылке, не трудно представить себе такую ситуацию: стоит у вас один или несколько проксирующих nginx-ов, раздают трафик на несколько uwsgi. Всё хорошо, все стабильно, каждый uwsgi-сервер обрабатывает по нескольку тысяч запросов в секунду не захлебываясь. А тут черная пятница, распродажи, маркетологи запустили очень успешную рекламную кампанию и на ваши сервера прибежали клиенты в количествах больших, чем вы предполагали. Всех этих клиентов nginx благополучно запроксировал на uwsgi и тот начал от такой конкурентности загибаться. Вместо тысяч запросов в секунду, производительность каждого сервера упала до десятков. Сайт практически лежит, вы добавляете новые сервера, а они продолжают загибаться. Менеджмент пьет валокордин и подсчитывает убытки.

    Теперь же другая картина и у вас не uwsgi, а Unit. Навалило клиентов, а каждый сервер с Unit'ом, как молотил 10 тыс запросов в секунду в пике так и продолжает. Видя в мониторинге, что количество запросов в секунду уперлось в потолок ваших мощностей, вы добавляете ещё несколько серверов с Unit'ом и те успешно берут на себя избыток нагрузки. Клиенты практически даже не замечают каких-то лагов.

     
     
  • 6.44, _ (??), 04:25, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И тут в палату входят санитары \ И тут ты просыпаешься

    :-)

     
  • 6.45, ыы (?), 09:16, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > как молотил 10 тыс запросов в секунду в пике так и продолжает

    То есть остальные он просто дропает?
    Орригинальное решение.

     
     
  • 7.47, Valentin V. Bartenev (?), 15:50, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего не дропается. Просто плавно растут задержки, запросы ждут в очереди.
     
  • 6.54, Ку (?), 01:02, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Валентин, отличный рассказ.

    Ниже я вам задал вопрос про условия проведения тестов, на которые вы дали ссылку.
    У меня закрались сомнения, что тесты проводились в максимально производильной конфигурации.
    Ответьте, пожалуйста.
    Спасибо.

     
  • 5.46, ыы (?), 09:28, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >https://itnext.io/performance-comparison-between-nginx-unit-and-uwsgi-python3-

    Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках?

     
     
  • 6.48, Valentin V. Bartenev (?), 15:58, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках?

    По горизонтальной оси - количество установленных соединений, которое использовалось для одновременной отправки запросов, а по вертикальной количество запросов в секунду, которое при этом сервер обрабатывал.

    Там есть графики для 10 тысяч запросов и для 100 тысяч.

    Соответственно в самой левой части графика все 10 или 100 тысяч запросов отправлялись последовательно по одному соединению и сервер обрабатывал их с указанной скоростью. В самой правой части графика запросы отправлялись одновременно по 500 соединениям.

     
     
  • 7.49, Аноним (31), 16:59, 17/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Валентин, спасибо за столь детальное объяснение. Теперь все понятно. Жать что пока что мало документации о внутреннем устройстве Unit и о технологических подходах который применялись при создании его.
     
  • 7.52, Ку (?), 00:14, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно ли я понимаю, что при тесте взаимодействие Nginx с uWSGI сервером было:

    1) через стандартный сокет, не через unix сокет?
    2) через HTTP протокол, а не бинарный "uwsgi".

    Ведь отсюда вытекает, что тестирование uWSGI было проведено в самой непроипроизводительной конфигурации. И тогда, возможно, мы бы не увидели на графике такого "разгрома".

    Если эти 2 условия не были соблюдены, то врятли этим тесты можно воспринимать всерьез.

     
     
  • 8.53, Ку (?), 00:48, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот нагуглил https www digitalocean com community tutorials how-to-serve-djan... текст свёрнут, показать
     
     
  • 9.56, Valentin V. Bartenev (?), 05:21, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Отмечу несколько моментов 1 Ни я, ни кто-либо из моих коллег не имеет к с... большой текст свёрнут, показать
     
     
  • 10.57, Ку (?), 11:18, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за ответ Я не говорил, что статья по ссылке к вам как-то относится Из ... текст свёрнут, показать
     
     
  • 11.60, Valentin V. Bartenev (?), 15:27, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если вам действительно интересны грамотные тесты TCP vs Unix domain socket... текст свёрнут, показать
     
  • 11.62, angra (ok), 02:15, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Адекватному программисту ясно, что это сильно зависит от данных Если данные сос... текст свёрнут, показать
     
     
  • 12.63, Ку (?), 11:00, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот копипаста от разрабов uWSGi Why not simply use HTTP as the protocol A good... текст свёрнут, показать
     
     
  • 13.65, Valentin V. Bartenev (?), 13:24, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    1 Поскольку длины полей в uwsgi не выровнены, то их все равно приходится читать... текст свёрнут, показать
     
  • 10.58, Ку (?), 11:49, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Также в тестах, насколько я понял, нет uSWGI c Go А то я скорее вижу там как в ... текст свёрнут, показать
     
  • 10.59, Ку (?), 12:03, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Итого нужны тесты 1 Unit Go vs Unix Socket binary uswgi Go 2 Unit Pyt... текст свёрнут, показать
     
     
  • 11.61, Valentin V. Bartenev (?), 15:29, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Уточните, а кто должен общаться с uWSGI по его binary протоколу Клиенты этого... текст свёрнут, показать
     
     
  • 12.64, Ку (?), 11:02, 20/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно, что Nginx ... текст свёрнут, показать
     
  • 8.55, Valentin V. Bartenev (?), 04:36, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В данной статье nginx вообще нет ... текст свёрнут, показать
     

  • 1.35, vitalif (ok), 22:28, 16/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Все-таки мне кажется, что не будет это востребовано. Толстосерверы не в моде
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру