Архив категорий Интересное с HabraHabr

Автор:human

Заработок на своем сайта — статья с habrahabr

Как заработать максимум на своем сайте. 22 способа и 240+ ссылок

Эта статья родилась из личного опыта. Я искал самые эффективные способы монетизации своего сайта и в какой-то момент понял, что тема очень обширная и требует подробного исследования. А его результаты могут быть интересны не мне одному.

Рассматриваются способы, наиболее актуальные для России и СНГ и не требующие участия разработчиков или требующие в минимальной степени.

Статья ввиду большого объема писалась не один месяц, поэтому не серчайте сильно, если где-то встретите неточности (в расценках, форматах). Просто напишите об этом в комментариях.

1. Контекстная реклама (Google AdSense)

Самый очевидный способ, о котором думают в первую очередь. На страницы сайта устанавливается рекламный код и каждому посетителю сайта выводятся индивидуально подобранные под него объявления. Оплата за клик. Стоимость клика можно увеличить. Google и Yandex по этому поводу дают слишком общие рекомендации («Делайте качественные сайты»), поэтому ориентироваться приходится на наблюдения владельцев сайтов:

— Выбрать самую доходную тематику: банки (кредиты, ипотека), страхование, юридические услуги, форекс, фондовый рынок, авиабилеты, хостинг, медицина.
— Нарастить посещаемость и авторитетность (PR, тИЦ) сайта, подобрать (если только запускаете сайт) домен с большим возрастом и уже имеющимися показателями тИЦ и PR.
— Использовать все форматы объявлений (медиа, текст, графика).
— Менять время от времени оформление объявлений.
— Использовать фильтр против рекламодателей с дешевыми кликами (можно найти готовый).
— Держать на аккаунте AdSense/РСЯ только качественные сайты. По наблюдениям некоторых вебмастеров некачественные проекты могут тянуть среднюю цену клика вниз для всех сайтов на аккаунте.
— Не перегружать сайт объявлениями (4-5 блоков на страницу, не больше).
— Использовать самые популярные у рекламодателей форматы объявлений. Google самыми эффективными называет форматы 336×280, 300×250, 728×90, 300×600 и большой мобильный баннер 320×100. Многие владельцы сайтов это подтверждают, но далеко не все.

Сколько можно заработать на контекстной рекламе? Зависит от общего количества трафика, его качества и тематики площадки. Владелец BigPicture.ru в январе 2015 года приводил цифры: при трафике 80-100 тыс. уников в сутки сайт за зарабатывает 150-220 тыс. рублей с РСЯ. В среднем 5,5 рублей за клик, CTR 0,16%. Правда, реклама «Яндекса» размещается на BigPicture в качестве заглушек, когда нет медийной рекламы.

В том же интервью приводилась оценка, что «вряд ли во всей сети РСЯ наберется хотя бы 500 сайтов, зарабатывающих 1000 баксов в месяц».

Все сети контекстной рекламы отличаются жесткой модерацией: не принимают адалт, шок-контент, торренты, казино, другие сайты сомнительной тематики, а также ресурсы с неуникальным контентом.

Сети контекстной рекламы:

Google AdSense. При приеме сайта не предъявляют требований к посещаемости сайта, но качество сайта и тематика имеют значения. Цена клика бывает от $0,01 до нескольких десятков долларов. Минимальная сумма на вывод — $100.

Рекламная сеть Яндекса. Условия приема жестче: посещаемость должна быть 500+ уников в сутки в течение месяца. Цена за клик бывает от 0,3 до 2500 руб. Деньги можно выводить на банковский счет или «Яндекс.Деньги». Минимальная сумма вывода — 1000 руб.

Begun. Порог входа по посещаемости варьируется в зависимости от тематики. Минимальный — 100+ уников в сутки. Рекламодателей в «Бегуне» ощутимо меньше, чем в РСЯ и AdSense. Цена клика начинается от 0,1 руб. Минимальная сумма на вывод — 1200 руб. Но с выплатами есть проблемы: вебмастера жалуются, что Begun давно не платит.

Or.ru. Принимают сайты с посещаемостью от 50 хостов в сутки. На бесплатных хостингах — от 100. Доля аудитории из поисковых система — не менее 30%, из них российских — не менее 50%. Платят от 0,35 руб. за переход.

Прочие сети контекстной рекламы:

B2BContext
Contema
Fialet
SocialMart

2. Баннерные сети

Баннерные сети можно условно разделить «белые» и «серые». В «белых» более жесткая модерация, нет адалта и шок-контента, а среди рекламных форматов не встретишь кликандер (при клике на любое место сайта открывается реклама), попандер (всплывающее поверх сайта окно с рекламой), vk message (баннер, имитирующий сообщение ВКонтакте).

Для оценки возможных доходов многие баннерные сети делают на своих сайтах калькуляторы или топы вебмастеров. Но это не самый надежный способ. Гораздо лучше зайти на биржу сайтов Telderi, открыть несколько лотов и посмотреть выручку конкретных сайтов от рекламных сетей.

Soloway. Одна из крупнейших рекламных сетей, уступает только Yandex, Google и Mail.ru. Принимают сайты с посещаемостью 1000+ уников в сутки. Для сотрудничества необходимо юрлицо или ИП. Форматы: 240×400, 300×250, топлайн (текст в шапке), rich-media. Платят 20-168 руб. за 1000 показов.

Wizard Banners. Принимают любые сайты. Форматы: rich-media, топлайн, catfish (баннер во всю ширину страницы, прилепленный снизу), adspot (прямоугольный баннер, закрепленный в углу экрана), vk message, кликандер. Платят 5-220 руб. за 1000 показов.

Advmaker. Принимают трафик из России и стран Европы, Америки, Канады, Латинской Америки, Азии. Суточная посещаемость должна быть 500+ хостов в день, из них по закладкам менее 50% от общей аудитории. Форматы: 300х250, 240х400, 600х200, 468х60, 728х90, 160х600 (флэш, прелоадер, слайд), кликандер, видеореклама, брендирование, мобильный редирект и мобильный фуллскрин 300×250. Платят 13-130 руб. за 1000 показов.

TeaserMedia. Принимают сайты с посещаемостью 100+ уников в сутки, поискового трафика не менее 30%. Форматы: тизерный блок (от 50×50 до 250×250), попап, фуллскрин, рекламный блок, выводимый поверх изображений (подходит для монетизации сайтов с обоями, фотохостингов). Платят от 0,25 руб. за клик.

DuMedia. Подразделение партнерки Admitad. Форматы: 300х300, 400х350, 200х200, 500х250, 728х90, 240х400, 120х600, 160х600, 300х600, 300х250, кликандер, layer ad (баннер возникает при входе на сайт, который содержит код layer поверх содержания просматриваемой страницы на прозрачном слое, при перемещении следует за пользователем), слайдер (240х400, 300х250). Платят 7-100 руб. за 1000 показов.

Advertur. RTB-система от Soloway, которая позволяет зарабатывать с помощью размещения рекламы от самых Google, Begun, AdRiver и других рекламных систем. Сайт должен быть на платном хостинге, аудитория — от 250 уников в течение месяца. Форматы: 728×90, 240×400, 300×250, 468×60, 160×600. Платят 3-30 руб. за 1000 показов, по отзывам — ближе к нижней границе.

TBN. Форматы: топлайн (текста в шапке), слайдер, vk message (баннер, замаскированный под сообщение ВКонтакте), боттомлайн (текст в футере). Платят 0,2-0,8 руб. за переход.

Promo-reklama. Принимают сайты, генерирующие от 300 просмотров рекламы в день. Форматы: 468х60, 240х400, 300×250, 728×90, 160×600, текстовая реклама, кликандер. Платят 5-35 руб. за 1000 показов.

Popunder. Крупная рекламная сеть с противоречивыми отзывами. Засветилась в сомнительной истории. Форматы: попандер, кликандер, vk message, уголок, слайдер, топлайн, топтекст, боттомлайн, боттомтекст, диалоговый баннер, видео VAST, фуллскрин. Платят от 40-170 руб. за 1000 переходов.

ForexContext. Рекламная сеть для сайтов форекс-тематики (одной из самых дорогих). Форматы: тизерзумы (тизеры с изображением, увеличивающимся при наведении мыши) и баннеры размеров 160×600, 120×600, 200×300, 240×400, 990×90, 728×90, 468×90, 468×60. Цены можно выставить самому — за клики или за показы. В среднем цена клика от 10-15 руб. Минимальная выплата — 500 руб.

MobiAds. Рекламная сеть под мобильный трафик. Принимают сайты с посещаемостью 300+ мобильных уников в сутки при требуемом соотношении трафика (Россия + Украина — 50-70%, Узбекистан — не более 10%), сайт должен состоять не менее чем из 10 страниц. Форматы: 100×100, 300×250, 300×50, 468×60, 640×100, текстовые объявления. Платят от 0,5 руб. за клик.

Octobird. Рекламная сеть под мобильный трафик. Принимают сайты с посещаемостью 500+ хостов и соотношением трафика РФ + Украина + Казахстан + Беларусь + Армения + Болгария + Молдова + Румыния — от 50%, Узбекистан — не более 15%. Не берут одностраничники, сайты моложе месяца, сайты с кликандером. Форматы: 216×36, 640×100, 300×50, 300×250, 468×60. Платят от 0,4 руб. за клик.

WapStart. Рекламная сеть под мобильный трафик. Требований к посещаемости нет. Форматы: графические, текстовые, текстово-графические, межстраничные, rich-media, видео. Платят от 0,5 руб. за клик.

GinAds. Относительно новая (2014) и небольшая рекламная сеть. Принимаются любые сайты, разрешен адалт. Форматы: топлайн, боттомлайн, слайдер, vk message, фуллскрин, видео VAST. Платят от 0,8 (Россия) и 0,2 (другие страны) руб. за переход.

Rotaban. Биржа баннерной рекламы. Владельцы сайтов сами устанавливают цены, а рекламодатели сами подбирают площадки для показа. Форматов много: 336×280, 250×250, 240×400, 468×60, 234×60, 120×90, 88×31, 120×240, 125×125, 120×600, 300x600x 300×250, 80×150, 728×90, 160×600, 80×15. Цены гуляют от 0,03 до нескольких тысяч рублей за 1000 показов.

AdEasy. Биржа баннерной рекламы для качественных сайтов с посещаемостью от 5000 уников сутки. Форматов море: 88×31, 120×90, 120×60, 120×600, 120×240, 125×125, 160×600, 180×150, 200×200, 234×90, 234×60, 240×200, 240×400, 250×250, 300×600, 300×250, 300×100, 300×50, 300×1050, 320×50, 336×280, 450×75, 468×60, 600×100, 728×90, 970×90, 970×250. Кроме того, есть конструктор для создания оригинальных типоразмеров. Цены на баннеры выставляешь сам, биржа берет 15%. На некоторых сайтах цены превышают 1000 руб. за 1000 показов.

Homrus. Принимают сайты с поисковым трафиком от 50 уников в сутки. Общий трафик с поиска — не менее 50%. Форматы: попандер, кликандер, контекстная реклама, тизеры, растяжка, попапы, vk message, плавающий блок. Платят $1,2-25 за 1000 переходов.

Прочие баннерные сети

AdForce
Adsentiz
AdvClicks
Advego
Contema
LibertyTraffic
LimonAds — рекламная сеть для развлекательных сайтов (видео, музыка, игры, книги).
Link.ru
LinkAds
MeCash
MediaNaft
Paradocs
Professional Link
Realtraf
SmartAdv — рекламная сеть под автомобильный трафик
Smart BN
Traforet
Traf-zona — прероллы и видеовитрины
uTarget
Whisla
Регионы Direct
Украинская баннерная сеть
12Traffic — много рекламных форматов для монетизации видео.
2under

3. Тизерные сети

Самый популярный формат медийной рекламы в Рунете. В сущности, тизерные сети — это тоже баннерная реклама, но обычно их выделяют в отдельную категорию. Отличительные признаки тизерных сетей — квадратный формат и баннеры из категории «Эту игру обожают все парни! Восторг зашкаливает!» (голая девушка на баннере) и «Девчонки, бросила КУРИТЬ за 2 дня! Не ожидала такого эффекта, нужно всего лишь…» (шок-картинка с жуткого вида женщиной).

В тизерках модерация мягче, чем в рекламных системах Mail.ru, Yandex, Google, поэтому туда идут с рекламой способов быстрого обогащения, быстрого похудения, быстрого набора мышц, увеличения члена. А в качестве рекламных площадок, как правило, принимают адалт, торрент-трекеры и другие сайты из «серой» зоны. Использование некоторых тизерок отрицательно сказывается на позициях сайта в поисковой выдаче.

Самые популярные тизерки — Marketgid, DirectAdvert, Kadam, TeaserNet.

MarketGid. Принимают сайты с посещаемостью 500+ уников. Адалт запрещен. Форматы: информер 728×90, новостной информер, попандер, новостной попандер, медиа-информер. Платят от $0,01 за клик. Минимальная сумма вывода — $20.

DirectAdvert. Тизерка с наиболее качественной и приличной рекламой. Адалт запрещен. Принимают сайты с посещаемостью 100+ уников в сутки. Форматы: 300х300, 240×400, 120×400, 300×250, 728×90, полоса-оверлей. Платят от 0,2 руб. за клик. Минимальный размер вывода — 100 руб. По многим отзывам, баннеры DirectAdvert не сказываются отрицательно на позициях сайта в поисковой выдаче.

Kadam. Очень большие возможности таргетинга — редкость среди тизерок. Принимают сайты на коммерческих хостингах с посещаемостью 500+ уников в сутки в течение месяца и долей поискового трафика не менее 50%. Адалт разрешен. Форматы: тизеры, баннеры (очень много размеров), vk message, кликандер, контекст. Платят от 1 руб. за клик.

TeaserNet. Принимают сайты на коммерческих хостингах с посещаемостью 50+ уников в сутки. Адалт разрешен. Форматы: тизерный блок, флэш-видео, кликандер, флэш-слайдер, тизеры, встроенные в видео, мобильный горизонтальный баннер, мобильный фуллскрин. Платят от 0,1 руб. за клик.

Ladycash. Тизерка с женским трафиком, аффилированная с CPA-партнеркой Actionpay. Принимают сайты с посещаемостью 50+ уников в сутки (на бесплатном хостинге — 300), долей женской аудитории более 60% и большим процентом поискового трафика. Работают только по модели CPA, рекламировать можно только офферы Actionpay. Адалт и шок-реклама запрещены. Формат: тизеры размером до 250×250. Платят от 0,4 руб. за клик.

Gnezdo. Еще одна тизерка с женским трафиком. Реклама Gnezdo крутится на многих крупных сайтах: lady.mail.ru, woman.ru, passion.ru, cosmo.ru. Принимают сайты с посещаемостью 300+ уников в сутки. Адалт запрещен. Платят от 1,2 руб. (новостное «Гнездо») и от 2 руб. (товарное «Гнездо») за клик.

. Товарная рекламная сеть. Объявления выглядят качественно и содержат изображения товара, описание, ссылку, цену. Принимают сайты на платных хостингах с посещаемостью 500+ уников в сутки. Запрещены адалт, тематика заработка в сети, сайты для детей. Формат — 200×200. Платят от $0,02 за клик.

AdLabs Medianet. Принимают сайты на платных хостингах с посещаемостью 100+ уников в сутки. Запрещены адалт, дорвеи. Форматы: тизерный блок, тизерный попандер, реклама в видеороликах и flash-плеерах. Платят 0,4-1,5 руб. за клик.

Visitweb. Хорошая тизерка для тех, кого не смущают адалт и шок-контент. Есть даже автоматический генератор CTRистых баннеров. Принимают сайты с посещаемостью 500+ уников в сутки. Форматы: простой блок тизеров, плавающий блок (остающийся на экране при скролле), кликандер, lite blind, mobile blind, vk message, слайдер, прямая ссылка. Платят от 0,3 руб. за клик.

Bodyclick. Принимают сайты на русском или украинском языках. Сайт должен быть на платном хостинге, если на бесплатном, то минимальная посещаемость — 500+ уников в день. Адалт разрешен. Трафик с поисковых систем — не менее 100+ уников в день стабильно в течении недели. Форматы: тизеры, флэш-баннеры, слайдеры, контекст, кликандер, vk message. Платят от 0,5 руб. за клик.

RedClick. Принимают сайты с посещаемостью 50+ уников в сутки. Разрешена эротика (но не порно). Формат 200×200. Платит от от 0,3 руб. за клик.

DriveNetwork. Тизерка от создателей DirectAdvert. Принимают русскоязычные сайты авто- и мототематики (необязательно весь сайт, но хотя бы один раздел должен быть этому посвящен) с посещаемостью 100+ уников в сутки. Для рекламодателей цены начинаются от 2 руб. за клик, а вот вебмастеру в зависимости от качества трафика и активности пользователей может доставаться и менее 0,5.

Pusk. Украинская тизерка. Принимают русскоязычные и украиноязычные сайты с посещаемостью 5000+ уников в день. Адалт запрещен. Формат 200×200. Платят от 1 руб. за клик.

Прочие тизерки

Adhub
Admatic
AdProfy
Adsyst
AdvertLink
AdXXX
BannerBook
BeautyTeaser
Boolads
CashProm
CPATeaser
eTarg
GameADnet — для игровых сайтов

GigaMega

Hermes — кто бы мог подумать, что есть специализированные тизерные сети для эзотерических и духовных ресурсов?
Fairypays
Forex Magazine
MediaTarget
MediaVenus
NovostiMira
Oblivochki
Pay-Click.ru
RedTram
SelectorNews
Smi2
TeaserLand
TeaserLady
TizerGet.Net
TizerStock
Tovarro
TrafMag
TrekLuck
Twinzo
Webteaser
Zoomclick

4. CPA

CPA — это реклама с оплатой за действия: регистрацию на сайте, вход в игру, оплаченный заказ и т.п. Модель не новая, но в Рунете большую популярность набрала в последние несколько лет. CPA можно использовать, если у вас есть хорошо таргетированная аудитория и вы будете целенаправленно еще обрабатывать. Например, если у вас сайт с промо-кодами интернет-магазинов. Или сайт с обзорами мобильных телефонов и приложений. Или игровой сайт. В общем, на CPA можно заработать серьезные деньги, но придется поработать. Это не рекламные сети, которые работают по схеме «поставил и забыл».

При регистрации в CPA-партнерках формально существует фильтр: нужно показать свой опыт заработка на интернет-рекламе. Но на практике его легко обойти: можно найти на форумах (Maultalk, Webmasters, kote.ws) чужие скрины и показать их саппорту при регистрации.

В России действует несколько десятков CPA-партнерок. Самые крупные — Admitad, AD1, CitiAds и Actionpay.

Admitad. Одна из крупнейших партнерок, созданная бывшим вебмастером. Порядка 600 офферов и самый широкий инструментарий среди всех партнерок. Стараются фокусироваться на интернет-магазинах, но есть очень много и игровых офферов. Основатель Admitad Александр Бахманн очень активен на форуме и в социальных сетях и порой подсказывает толковые вещи.


Статистика по моему аккаунту в Admitad

Ad1. CPA с удобным интерфейсом и быстрым саппортом, но не самым большим выбором офферов (200+).

Cityads. Крупная партнерка с большим числом офферов, но неудобным и местами просто странным интерфейсом. Есть некоторые уникальные инструменты, недоступные в других партнерках.

Actionpay. Около 400 офферов. Интерфейс средний, отвечают долго. К новичкам партнерка не слишком дружелюбна: многие офферы требуют «стажа», на контакт менеджеры идут не слишком охотно.

Everad. Товарная партнерка с высокими выплатами и веселым пабликом.

MobiOffers. Партнерка с мобильными офферами. Ориентирована на Россию, выплаты не самые большие, зато все офферы доступны сразу.

HighCPI и Tapgerine. Две похожие партнерки. Обе сфокусированы на мобильных офферах, обе сделаны на одном и том же движке (HasOffers), обе глобальные (офферы для многих стран). Менеджеры хорошо идут на контакт. Выплаты за 1 инсталл достигают $4-8.

UniLead. Крупная партнерка с игровыми офферами.

«Где Слон?». Партнерка с большим числом товарных офферов. Сотрудничают с нескольким десятками российских и зарубежных интернет-магазинов.

MixMarket. Одна из старейших партнерок (создана AdLabs). Много офферов, в том числе эксклюзивных, но признаков жизни мало.

AdvertStar. Партнерка второго эшелона. Встречаются хорошие эксклюзивные офферы.

APIShops и Biggon. Товарные партнерки с возможностью автоматической генерации лендингов.

Прочие CPA

ActionAds
AdInfo
Adspay
AdSup — мобильные офферы
Advertise.ru
Adwad
Afrek
BizNip — продажа инфопродуктов
CloBucks
CPAgetti
CPAUA
CTR.ru
DoubleTrade
Edu-profit — под студенческий трафик США
Elon
EveryAds — мобильные офферы
Eviton — товарные офферы
Exelo
Gemwork
Himba
HotPartner
KMA
inetRek
Leadgid
Leadpays
Leadshunter
Lead-R
Leads3
Leads Partner
Lead.su — банковские офферы
Leadtrade
M1-shop
Mastertarget — финансовые офферы
MobCPA
Offertop
OXCPA
Петр I — CPA по продаже обучающих курсов
RocketProfit
QX Plus
SalesDoubler
shakes.pro
Thor-CPA
Tradeleads
TradeTracker
Trust Partners — товары почтой
7offers

5. Реферальные программы

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

Однако на практике лишь небольшое число реферальных программ дает отдачу, стоящую усилий. Самыми выгодными являются партнерские программы дилинговых центров. Их клиенты вносят на счет большие суммы, отсюда и большие отчисления рефоводам. Но $10 000 в месяц, как обещают по ссылке, заработает, конечно, далеко не каждый.

Говорят, что хорошую отдачу дают также партнерки казино, но я их не пробовал.

6. Прямая продажа рекламы

Прямые продажи рекламы могут позволить себе популярные сайты или авторитетные блоги. А для всех остальных есть смысл объяснить, зачем к этому стремиться: при использовании рекламных сетей вы можете заработать несколько десятков, максимум несколько сотен рублей за 1000 показов. А при прямых продажах доход может превышать 1000 руб. за 1000 показов. Такие ценники встречаются даже на игровых сайтах типа Playground.ru, где велика доля школьной аудитории.

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

7. Другие рекламные системы

Topadvert. Рекламная система, позволяющая зарабатывать на рекламе от интернет-магазинов. Показывает не традиционные баннеры, а текстовые и текстово-графические блоки с товарами, контекстно связанными со страницами вашего сайта. Например, в обзоре смартфонов можно разместить рекламный блок со ссылками на магазины смартфонов и средними ценами. Платят в среднем 2,5 руб. за переход.

RTBSystems. Система управления рекламой, которая автоматически подбирает самую выгодную рекламную сеть (MarketGid, AdLabs, DirectAdvert и др.) и показывает именно ее рекламу. Принимают сайты с посещаемостью 500+ уников в сутки. Адалт запрещен, но легкая эротика проскакивает. Формат — тизеры размером от 500х330. Минимальная цена за клик — $0,02, средняя — $0,05-0,07.

Viboom. Сервис для монетизации сайтов и групп в социальных сетях. Рекламодатели (в основном крупные бренды) предлагают свои видео, а вебмастера размещают их на своих площадках и получают деньги за каждый просмотр. Принимают русскоязычные сайты с посещаемостью 1000+ уников в сутки для сайтов и паблики с 15 000+ подписчиками. Платит 0,75-2 руб. за просмотр. Один из роликов, который раскручивался с помощью Viboom:

Keyprofit. Рекламная система, предлагающая сразу несколько способов монетизации: за счет размещения ссылок (см. главу «Заработок на коротких ссылках»), рекламных статей и рекламных блоков (Яндекс, Google, тизерок). От владельца сайта требуется лишь установить код Keyprofit на свой сайт. Примерный доход можно рассчитать с помощью калькулятора на главной странице.

8. Реклама в email-рассылках

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

9. Монетизация файлового трафика

Способ, которым часто пользуются игровые и файловые сайты. Заменяете ссылки на файлы у вас на сайте на партнерские, после чего при запуске скачанного файла пользователю предлагается установка дополнительных компонентов. Довольно прибыльный способ (в среднем платят 2,5-3 руб. за инсталл), но плохо сказывается на репутации. Используйте на свой страх и риск:
Adfile
BTMagnat
Install Bundle
InstallCube
InstallMonster
Installfile
Installs.pro
Loadpays
Perinstallcash
ProfiTraf
Roboinstall
ShareFlare
SkyIncom
Turboinstall
Webasm

10. Заработок на продаже ссылок

Очень старый способ, существующий уже много лет. Как зарабатывать на ссылках можно узнать на профильных форумах, здесь же перечислю только биржи. Имейте в виду, что за продажу ссылок поисковые системы могут пессимизировать.
Sape
MainLink
Trustlink
Gogetlinks
Miralinks
Webartex
Rodinalinkov
Rotapost
Getgoodlinks
GoGetTop
Blogocash
Ingots
Cmse

11. Продажа информации об аудитории

Зарабатывать на аудитории можно не только показывая ей рекламу, но и сдавая ее в аренду другим рекламодателям. Поможет в этом биржа ретаргетинга «Таргет+». Добавляете на свой сайт код биржи, с его помощью собираются профили ВКонтакте посетителей сайта и за деньги продаются рекламодателям, заинтересованным в аудитории вашего проекта. Цену назначаете сами.
(UPD: похоже, что разработчики перестали поддерживать сервис).

12. Paywall

Если у вас контентный сайт или сайт с ценной информацией (например, финансовой, юридической), то можно закрыть часть контента paywall. Особенно актуально это для небольших нишевых сайтов, у которых недостаточно аудитории, чтобы зарабатывать на рекламе, но сама аудитория достаточно преданная, чтобы платить за контент (пример — «Спутник и погром»).

Сервисы paywall:
Piano (бывший Tinypass)
Pigeon
Mediapass
Paywall
Subscription DNA
MemberGate
Cointent
eSuite
Recurly
Subscription Genius

13. Контент-локеры

Локеры схожи с paywall, но их применение шире: можно залочить сайт, страницу, файл, ссылку, музыкальный трек на SoundCloud. Для доступа к искомому контенту пользователь должен скачать какой-нибудь файл или программу. Если пользователь из региона, на который оффер не распространяется, то попросят отправить платное SMS.
MGCash
SkyIncome

14. Заработок на просмотрах картинок

Этот способ вы наверняка видели на торрент-трекерах. Заливаешь на хостинг партнерки картинки, получаешь коды, размещаешь у себя. При просмотре картинок они открываются на отдельной странице с рекламой. Платят 220-230 руб. за 1000 уникальных просмотров.
Piccash
Image2You
Pic2You
ImageCash

15. Заработок на коротких ссылках

Способ заключается в сокращении ссылок и размещении в тех местах, где по ним будут много кликать. При переходе по ссылкам появляется промежуточное окно с рекламой. Заработать можно 50-200 руб. за 1000 уникальных переходов
Coinurl

Ity.im
AdFoc.us
p.pw
Link-Money

RLU
Q32.link
Shorte.st
99link
Coroche

16. Заработок на опросах и капчах

Заработать можно даже на капчах, которые будут вводить ваши пользователи. Допустим, у вас есть контент, на котором вы хотели бы заработать. Но вы знаете, что платить будут мало. В таком случае можно использовать MoneyCaptcha. Пользователь пытается получить доступ к контенту, ему выдается капча, он ее вводит, получает доступ, а вам капают деньги. 1,1-1,5 руб. за каждую решенную капчу от пользователя из России. Крохоборство, конечно, но кому-то может пригодиться.

17. Заработок на размещении статей

Если у вас есть популярный контентный сайт, то можно заработать на размещении платных статей. С рекламодателями можно работать напрямую или добавить через биржу Blogun. Обычно такие публикации размещаются с пометкой «на правах рекламы». Но многие размещают рекламные публикации и под видом обычного контента. К примеру, у Lifehacker.ru это стоит 88 800 руб. (при прямой договоренности наверняка дешевле — в прошлом году прямое размещение стоило 60 000 руб.).

18. Заработок на онлайн-консультантах

На многих сайтах сразу бросается в глаза яркая форма чата для онлайн-консультаций. Это тоже один из способов монетизации. Задача консультанта — заболтать пользователя и превратить его в клиента для юридических фирм, банков, риэлторов. Примером такой партнерки служит Leadia. Я сам ее не тестировал, но на сайте обещают заработок в разы выше, чем от контекстной рекламы, и многие отзывы на форумах и аукционы на Telderi (там можно увидеть доходы реальных сайтов) это подтверждают.

19. Заработок на размещении игр

В чем суть: встраиваете на свой сайт флэш-игры, люди в них играют, смотрят встроенную рекламу, а вам капают деньги. Сайты флэш-игр, бывает, имеют посещаемость в Рунете до 100 000 в сутки (см. игровой топ Liveinternet). Платят в среднем 20 руб. за 1000 показов.
Livegames.ru
WebTomat

20. Продажа долей

Заработать на своем сайте можно путем продажи доли в нем через краудинвестинговые площадки. Большинство этих площадок и предлагаемых на них проекты, на мой взгляд, доверия не вызывают, но способ такой есть, имейте в виду, может кому пригодится.
ShareInStock
Itinvest
Simex

21. Инфобизнес

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

В качестве площадки для продажи лучше всего использовать Skladchik. Сколько можно заработать на полезном контенте? Вот пара примеров:

Мануал по заработку на Youtube от 16-летнего парня — 300 тыс. руб.
Бесплатный целевой трафик на автомате — 650 тыс. руб.

22. Попрошайничество

А еще можно напрямую попросить денег у пользователей. Этот способ используют сайт «Спутник и погром» (кроме подписки, там можно еще и пожертвовать денег) и игровой видеоблогер Антон Логвинов. Существенную сумму можно собрать только при наличии серьезного авторитета. Логвинов, для примера, работает игровым журналистом уже 15 лет, за это время он собрал большую и преданную аудиторию. Некоторые его поклонники жертвуют ему десятки тысяч рублей.

Для сбора пожертвований можно использовать встраиваемую форму «Яндекс.денег».


Сколько собрал Логвинов с помощью краудфандинга

Автор:human

Администрирование → Масштабируемая конфигурация nginx

Игорь Сысоев

Игорь Сысоев ( isysoev )

Меня зовут Игорь Сысоев, я автор nginx и сооснователь одноименной компании.

Мы продолжаем разработку open source. С момента основания компании темпы разработки существенно увеличились, поскольку над продуктом работает множество людей. В рамках open source мы оказываем платную поддержку.

Я буду говорить о масштабируемой конфигурации nginx, но это не о том, как обслужить с помощью nginx сотни тысяч одновременных соединений, потому что nginx для этого настраивать не надо. Нужно выставить адекватное число рабочих процессов или поставить его в режим «авто», поставить worker_connections в 100 000 соединений, после этого заниматься настройкой ядра — это гораздо более глобальная задача, чем просто настройка nginx. Поэтому я буду рассказывать о другой масштабируемости — о масштабируемости конфигурации nginx, т.е. о том, как обеспечить рост конфигурации от сотни строчек до нескольких тысяч и при этом тратить минимальное (желательно константное) время на сопровождение этой конфигурации.

Почему, собственно, возникла такая тема? Около 15 лет назад я начал работать в Рамблере и администрировал сервера, в частности, apache. А у apache есть такая неприятная особенность, которая хорошо иллюстрируется следующими двумя конфигурациями:

Здесь два location’а и они идут в разном порядке. Один и тот же запрос, в зависимости от того, какая конфигурация используется, будет обработан разными файлами — либо php-файлом, либо html-файлом. То есть при работе с конфигурацией apache порядок имеет значение. И отменить это нельзя — apache при обработке запросов проходит по всем location’ам, пытается найти те, которые совпадают каким-то образом с этим запросом, и собирает конфигурацию из всех этих location’ов. Он сливает ее и, в конце концов, использует результирующую.

Это удобно, если у вас маленькая конфигурация — так можно сделать ее еще меньше. Но по мере роста вы сталкиваетесь со следующими проблемами. Например, при добавлении нового location’а в конце все работает, но после вам нужно поменять конфигурацию в середине или выкинуть неактуальный location из середины. Вам нужно просмотреть всю конфигурацию после этих location’ов, чтобы убедиться в том, что все продолжает работать как раньше. Таким образом, конфигурация превращается в карточный домик — вытащив одну карту, мы можем порушить всю конструкцию.

В apache чтобы добавить аду в конфигурацию есть еще несколько секций, которые работают точно так же, они обрабатываются в разном порядке, но из них всех собирается одна результирующая конфигурация. Все это делается в runtime, т.е. если у вас много модулей, то в каждом модуле будет происходить слияние конфигураций (это частично объясняет, почему nginx в некоторых тестах быстрее apache — потому что nginx в runtime конфигурации не сливает). Часть этих секций и большинство директив можно разместить в .htaccess файлах, которые раскиданы по всему сайту, а для того чтобы сделать жизнь вашу и ваших коллег еще «интересней», эти файлы можно переименовать, и ищите эту конфигурацию…

А «вишенкой на торте» являются RewriteRules, которые позволяют сделать конфигурацию похожей на sendfile. Немногие оценили юмор, т.к., к счастью, большинство уже не знают, что это такое.

RewriteRules — вообще кошмар. Очень много администраторов приходят не столько с бэкграундом apache, сколько с бэкграундом администрирования apache на разделяемом хостинге, т.е. когда единственным средством администрирования был .htaccess. И в нем они делают очень замысловатые RewriteRules, которые очень тяжело понимать и в силу синтаксиса, и в силу логики.

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

В отличие от apache, вне зависимости от порядка location’ов запрос будет обработан одинаково, т.к. nginx ищет максимально возможное совпадение с префиксным location’ом, не заданным регулярным выражением, и после этого выбирает этот location. Используется конфигурация выбранного location’а, а все остальные location’ы игнорируются. Такой подход позволяет писать конфигурации с сотней location’ов и не думать о том, как это будет влиять на все остальное, т.е. получаем своего рода контейнеры. Вы изолируете обработку в одном небольшом месте.

Рассмотрим, как nginx выбирает конфигурацию, которую он будет использовать при обработке запроса. Первым делом ищется подходящий подзапрос сервера. Выбор осуществляется на основе сначала адреса и порта, а затем всех привязанных к данным адресу и порту имен серверов.

Если вы хотите, допустим, разместить сервер на нескольких адресах, написать там много имен серверов, и хотите, чтобы все эти имена серверов работали на всех адресах, то вам нужно адреса продублировать на всех именах. После того, как выбран сервер, внутри сервера ищется подходящий location. Сначала проверяются все префиксные location’ы, ищется максимальное совпадение, потом проверяется, существуют ли location’ы, заданные регулярными выражениями. Поскольку для регулярных выражений мы не можем определить максимальное совпадение, то выбирается location, у которого регулярное выражение совпало самым первым. После этого используются имена конфигурации этого location’а. Если не совпало ни одно регулярное выражение, то используется конфигурация, которая была найдена до этого, с максимально совпадающим префиксом.

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

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

Когда я рассказывал о порядке обработки конфигурации, это был первоначальный дизайн. Потом появилась возможность описывать location’ы внутри location’а, т.е. инклюзивные location’ы, и порядок немного адаптировался. Т.е. сначала ищется максимально совпадающий префиксный location, потом внутри него ищется максимально совпадающий префиксный location. Такой вот рекурсивный поиск продолжается, пока мы не дойдем до location’а, в котором ничего уже нет.

После этого мы начинаем проверять location’ы с регулярными выражениями в обратном порядке, т.е. мы вошли в самый вложенный location, смотрим, есть ли там регулярное выражение. Если нет, то спускаемся на уровень ниже и т.д. Опять же, первый совпавший location с регулярным выражением «побеждает». Такой подход позволяет сделать такую обработку:

У нас тут есть два location’а с регулярными выражениями, но для запроса /admin/index.php будет выбран вложенный первый location, а не второй.

Кроме того, вторую часть поиска регулярных выражений можно запретить, если пометить location символом ^~:

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

Очень часто люди пытаются сделать конфигурацию меньше, т.е. они выносят какую-то общую часть конфигурации и просто перенаправляют туда запросы. Вот, например, очень плохой способ перекинуть все в обработку php:

В nginx есть другие методы выделения общих частей конфигурации. Прежде всего, это наследование конфигурации с предыдущего уровня. Например, здесь мы можем написать на уровне http включить sendfile для всех серверов и всех location’ов:

Эта конфигурация наследуется во все вложенные сервера и location’ы. Если нам нужно где-то отменить sendfile, потому что, допустим, файловая система его не поддерживает или по каким-то другим причинам, то мы можем его выключить в конкретном location’е или в конкретном сервере.

Или, например, для сервера мы можем написать общий root, где нужно его переопределить.

Этот подход отличается от apache тем, что мы знаем конкретные места, где нужно искать общие части, которые могут повлиять на наш location.

Единственное, что нельзя делать разделяемым, — например, на уровне http нельзя описывать location’ы. Это было сделано сознательно. В apache это можно делать, но доставляет немало проблем при использовании.

Лично я предпочитаю описывать location’ы явно прямо в конфигурации. Если вам не хочется этого делать, то вы можете его инклудить через внешний файл.

Теперь я хотел бы поговорить о том, почему люди хотят писать меньше, т.е. почему они шарят разделяемые конфигурации. Они полагают, что потратят меньше сил. На самом деле, люди хотят не столько меньше писать, сколько меньше тратить времени. Но о будущем они не думают, зато считают, что, если они сейчас напишут меньше, то так же будет и дальше…

Правильный подход — использование copy-paste. То есть, внутри location’а должны быть все необходимые директивы для его обработки.

Обычный аргумент под любителей DRY (Don’t Repeat Youself) заключается в том, что если надо будет что-нибудь исправить, то это можно исправить в одном месте и все будет прекрасно.

На самом деле, современные редакторы имеют функциональность find-replace. Если вам нужно, например, исправить имя/порт бэкенда или поменять root, заголовок, передаваемый бэкенду, и т.п., вы можете спокойно это сделать с помощью find.

Для того чтобы понять, нужно ли вам в данном месте поменять какой-то параметр, достаточно пары секунд. Например, у вас 100 location’ов, вы на каждый location потратите по 2 сек., итого 200 сек. ~ 3 мин. Это немного. А вот когда в будущем вам придется развязать какой-то location от общей части, то это будет уже гораздо сложнее. Вам нужно будет понять, что менять, как это будет влиять на другие location’ы и т.д. Поэтому, что касается конфигурации nginx, нужно использовать copy-paste.

Вообще говоря, администраторы не любят тратить много времени на свои конфигурации. Я и сам такой. У администратора может быть 2-3 любимых продукта, он может с ними возиться очень много, при этом существует десяток других продуктов, на которые времени тратить не хочется. Например, у меня на персональном сайте есть почта, это Exim, Dovecat. Их я не люблю администрировать. Я просто хочу, чтобы они работали, а если надо что-то добавить, чтобы это заняло не больше пары минут. Мне просто лень изучать конфигурацию, и, думаю, большинство администраторов nginx — они такие же, администрировать ngnix хотят как можно меньше, им важно, чтобы он работал. Если вы такой администратор, то используйте copy-paste.

Примеры того, как можно коротенькие немасштабируемые конфигурации превратить в то, что надо:

Тут человек думает, что написал регулярное выражение, всего мало, все хорошо. На самом деле, т.к. тут есть регулярное выражение, это плохо — оно может влиять на все остальное. Поэтому лично я делаю вот так:

Если у вас этот root общий для всех location’ов или, по крайней мере, используется в большинстве из них, то это можно сделать даже так:

Это, вообще, легальная конфигурация, т.е. совершенно пустая конфигурация location’ов.

Второй способ избежать copy-paste — это вот такой пример:

Администраторы, которые раньше работали с apache, думают, что admin/index.php должен запрашивать авторизацию. В nginx это не работает, т.к. index.php обрабатывается в одном location’е, а location/admin совершенно другой. Но можно сделать вложенную конфигурацию и тогда index.php естественно запросит авторизацию.

Часто бывает нужно использовать регулярные выражения для того, чтобы «выкусывать» какие-то части из URL и использовать их при обработке. Вот это плохой способ:

Правильно — это использовать вложенные location’ы, таким образом, мы изолируем регулярные выражения от конфигурации всего остального сайта, т.е. дальше этого location/img/, который помещается на экран, управление не уйдет:

Еще одно место, где можно в nginx достаточно безопасно использовать регулярные выражения, это map’ы, т.е. формировать переменные на основе каких-то других переменных с помощью регулярных выражений и т.д.:

Я ничего не сказал об использовании Rewrites, потому что их не надо использовать вообще. Если вы не можете их не использовать, то используйте их на стороне бэкенда.

Evil — тоже не рекомендуемая конструкция в nginx, потому что, как работает внутри Evil, знает человек 10 в мире, и вы вряд ли входите в их число.

Вот такая конфигурация, когда у нас два if (true):

Ожидается, что у нас будут выключены gzip и etag. На самом деле отработает только последний if.

Есть одно безопасное использование if — это когда вы используете его для возврата ответа клиенту. Можете использовать rewrite в этом месте, но я его не люблю, я использую return (он позволяет добавить код и т.д.):

Резюмируем:

  • использовать желательно только префиксные location’ы;
  • избегайте регулярных выражений, если же регулярные выражения все-таки нужны в конфигурации, то их лучше изолировать;
  • используйте map’ы;
  • не слушайте людей, которые говорят, что DRY — это всеобщая парадигма. Это хорошо, когда вам нравится продукт, или вы программируете продукт. Если же вам просто нужно облегчить свою администраторскую жизнь, то copy-paste — это для вас. Ваш друг — это редактор с хорошим find-replace;
  • не используйте rewrites;
  • используйте if только для возврата какого-то ответа клиенту.

Вопрос из зала: Если я использую rewrites http на https, его где лучше использовать — в nginx или на бэкенде?

Ответ: Его использовать в nginx. Идеально это так — вы делаете два сервера. Один сервер у вас plane text’ы и он делает только rewrites. В этом месте будет буквально несколько директив — server listen на порту, server name, если нужен, и return в 301 или 302 на https с дублированием request URI. Там даже rewrite не нужен, используйте return.

Если вы хотите что-то более сложное сделать, то где-то можно вставить if. Допустим, часть location’ов у вас отрабатывают в plane text’е, опишите их с помощью регулярных выражений в map’е, например, а все остальное можно редиректить на https. Или, наоборот, вставить внутри каждого location’а по одному if, который будет редиректить на https.

Вопрос из зала: Спасибо за nginx. У меня несколько шутливый вопрос. Вы не планируете добавить ключик запуска или ключик компиляции, который не даст использовать директиву include, не даст использовать if, регулярные выражения в location’ах?

Ответ: Нет, вряд ли. Мы обычно добавляем какие-то директивы, улучшаем их и потом делаем их deprecated. Они какое-то время выводят warning в логе, прежде чем пропасть полностью, но они работают в каком-то режиме. Мы вряд ли будем делать то, что вы сказали, мы лучше напишем хороший User Guide, возможно, по материалам этого выступления.

Вопрос из зала: Обычное желание, которое возникает при использовании if, это потому что его можно использовать в сервере и в location’е, а map использовать нельзя. Почему так получилось?

Ответ: Все переменные в nginx вычисляются on the map, т.е. если map описываем на уровне http, это не означает того, что при обработке запроса эта переменная будет вычисляться обязательно. Map нужен для того, чтобы отмаппить что-то в одно, а потом что-то одно — в другое, а результирующую переменную вы можете использовать в if или внутри какого-то выражения, проксировать куда-то и т.п. Map — это просто как бы декларация… Может быть, их имеет смысл переместить на сервер для того, чтобы сделать их локальными для сервера, если у вас одна и та же переменная. Там просто было сложнее программировать, поэтому они были вынесены на глобальный сервер. В nginx нет переменных, которые были бы локальными внутри сервера.

С точки зрения performance никаких проблем нет, это просто неудобство. Надо будет сделать, допустим, три сервера и три map’а, а у переменной будет префикс «сервер такой-то»… Вы можете их, в принципе, описывать перед сервером, т.е. эти map’ы — одна будет перед первым сервером, потом перед вторым… По конфигу не надо будет скакать вверх-вниз, они будут ближе к серверу.

Вопрос из зала: Я плохо знаком с логикой работы return’ов. Расскажите, пожалуйста, где стоит использовать return’ы вместо rewrite’ов, какие-то use case’ы конкретные?

Ответ: Вообще, rewrite заменяется на такую конструкцию: location с регулярным выражением, в котором можно сделать какие-то captures — захваты, выделения, и на директиву return. Т.е. один rewrite — его левая часть в location’е, а правая часть — это то, что будет в return’е после кода ответа. Return предлагает возможность возврата разного кода ответа, а в rewrite для возврата клиенту есть только 301, 302. Return может вернуть 404 с каким-то телом, может — 200, 500, может вернуть redirect. А в его теле можно использовать переменную, что-то написать. Если это 301, 302, то это не тело, это уже URL, на который нужно сделать redirect. В общем, у return’а богаче функциональность.

Вопрос из зала: У меня прикладной вопрос. Nginx можно использовать как почтовый прокси. Можно ли дать SMTP-доступ в почтовый клиент, отправить письмо через этот почтовый клиент, и nginx’ом перехватить данные и отправить на скрипт, минуя почтовый веб-сервер? Сейчас мы эту задачу реализуем, используя postfix — он перехватывает письмо и дальше кидает на скрипт, где происходит обработка.

Ответ: Я сомневаюсь, что это можно сделать посредством nginx. Я могу описать кратко функциональность, которая есть в SMTP Proxy в nginx. Он умеет делать следующее — к нему соединяется SMTP-клиент, показывает какую-то аутентификацию, nginx идет во внешний скрипт, проверяет имя-пароль, а потом говорит, пускать клиента на какие-то сервера (и передает, на какие конкретно), либо не пускать. Это все, что он умеет делать. Если решено куда-то пускать, то nginx по SMTP соединяется с этим сервером и передает ему. Ложится ли это в Ваш сценарий, я не могу сказать. Вряд ли.

SMTP Proxy с авторизацией появился, потому что в Рамблере для клиентов почты есть специальный сервер, через который эти клиенты отправляли почту. И оказалось что около 90% соединений — это не клиенты Рамблера, а спам и вирусы. Чтобы не нагружать postfix’ы, не поднимать лишние процессы, перед этим поставили nginx, который проверяет, предоставляет ли этот клиент свои аутентификационные данные. Собственно, для этого это и было сделано — просто, чтобы отбивать «мусорных» клиентов.

Вопрос из зала: Вы сегодня упомянули про контейнеры, это, конечно, многообещающий подход, но он подразумевает изменяющуюся топологию и динамическую конфигурацию. Сейчас это пока приводит к тому, что люди строят некие внешние «костыли», которые периодически реагируют на события изменения топологии, генерят через какой-нибудь шаблон актуальный конфиг nginx’а, подсовывают его и пинают, чтобы пересчитал конфиг. Интересно — у компании есть какие-то планы по развитию в сторону контейнеризации, т.е. в сторону обеспечения более удобных и естественных средств для этого тренда?

Ответ: Смотря, что Вы подразумеваете под контейнерами в данном случае. Я, когда говорил про контейнеры, сравнивал, я говорил, что эти location’ы выглядят изолированно друг от друга.

Вопрос: Мы вернулись обратно к docker’у, к возможности запуска бэкендов где-то в контейнерах, который динамически исполняется на разных хостах, и нужно, грубо говоря, добавить в балансировку новый хост…

Ответ: У нас в NGINX+ одна из частей Advansed Load Balansing, как раз, подразумевает, что вы можете динамически добавлять сервера в апстрим. Получается, вам не нужно делать reload конфига nginx’а, а все это делается на лету — для этого есть API.

Еще туда включены активные хелсчеки. Когда обычный open source nginx соединяется с бэкендом, если бэкенд не отвечает, то к нему nginx некоторое время не обращается, т.е. своеобразный хелсчек тоже здесь есть, но страдают клиенты. Если у вас 50 клиентов одновременно пошло на один бэкенд, а он лежит или по таймауту отвалится через 5-10 сек., то клиенты это увидят, и только после этого их перебросят на другой апстрим. В NGINX+ у нас есть проактивное тестирование бэкендов, т.е. бэкенды сами тестируются, и клиенты на упавшие бэкенды просто не отправляются.

Вопрос: И, раз есть активный хелсчек, то, может, уже и запилили тогда красивую JSON-образную страничку статуса, которую можно отпарсить?

Ответ: Да, у нас есть мониторинг, он доступен, в том числе, и через JSON, а также он есть в виде красивого html’а.

Оригинал https://habrahabr.ru/company/oleg-bunin/blog/313666/

Автор:human

Образы и контейнеры Docker в картинках из песочницы

docker container

Перевод поста Visualizing Docker Containers and Images, от новичка к новичкам, автор на простых примерах объясняет базовые сущности и процессы в использовании docker.

Если вы не знаете, что такое Docker или не понимаете, как он соотносится с виртуальными машинами или с инструментами configuration management, то этот пост может показаться немного сложным.

Пост предназначен для тех, кто пытается освоить docker cli, понять, чем отличается контейнер и образ. В частности, будет объяснена разница между просто контейнером и запущенным контейнером.

В процессе освоения нужно представить себе некоторые лежащие в основе детали, например, слои файловой системы UnionFS. В течение последней пары недель я изучал технологию, я новичок в мире docker, и командная строка docker показалась мне довольно сложной для освоения.

По-моему, понимание того, как технология работает изнутри — лучший способ быстро освоить новый инструмент и правильно его использовать. Часто новая технология разрабатывает новые модели абстракций и привносит новые термины и метафоры, которые могут быть как будто бы понятны в начале, но без четкого понимания затрудняют последующее использование инструмента.

Хорошим примером является Git. Я не мог понять Git, пока не понял его базовую модель, включая trees, blobs, commits, tags, tree-ish и прочее. Я думаю, что люди, не понимающие внутренности Git, не могут мастерски использовать этот инструмент.

Определение образа (Image)

Визуализация образа представлена ниже в двух видах. Образ можно определить как «сущность» или «общий вид» (union view) стека слоев только для чтения.

docker_image

Слева мы видим стек слоев для чтения. Они показаны только для понимания внутреннего устройства, они доступны вне запущенного контейнера на хост-системе. Важно то, что они доступны только для чтения (иммутабельны), а все изменения происходят в верхнем слое стека. Каждый слой может иметь одного родителя, родитель тоже имеет родителя и т.д. Слой верхнего уровня может быть использован как UnionFS (AUFS в моем случае с docker) и представлен в виде единой read-only файловой системы, в которой отражены все слои. Мы видим эту «сущность» образа на рисунке справа.

Если вы захотите посмотреть на эти слои в первозданном виде, вы можете найти их в файловой системе на хост-машине. Они не видны напрямую из запущенного контейнера. На моей хост-машине я могу найти образы в /var/lib/docker/aufs.

Определение контейнера (Container)

Контейнер можно назвать «сущностью» стека слоев с верхним слоем для записи.

docker_container

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

Контейнер определяет лишь слой для записи наверху образа (стека слоев для чтения). Он не запущен.

Определение запущенного контейнера

Запущенный контейнер — это «общий вид» контейнера для чтения-записи и его изолированного пространства процессов. Ниже изображен контейнер в своем пространстве процессов.

docker_container_running

Изоляция файловой системы обеспечивается технологиями уровня ядра, cgroups, namespaces и другие, позволяют докеру быть такой перспективной технологией. Процессы в пространстве контейнера могут изменять, удалять или создавать файлы, которые сохраняются в верхнем слое для записи. Смотрите изображение:

docker_touch_file

Чтобы проверить это, выполните команду на хост-машине:

Вы можете найти новый файл в слое для записи на хост-машине, даже если контейнер не запущен.

Определение слоя образа (Image layer)

Наконец, мы определим слой образа. Изображение ниже представляет слой образа и дает нам понять, что слой — это не просто изменения в файловой системе.

docker_layer

Метаданные — дополнительная информация о слое, которая позволяет докеру сохранять информацию во время выполнения и во время сборки. Оба вида слоев (для чтения и для записи) содержат метаданные.

docker_container_metadata

Кроме того, как мы уже упоминали раньше, каждый слой содержит указатель на родителя, используя id (на изображении родительские слои внизу). Если слой не указывает на родительский слой, значит он наверху стека.

docker_image_metadata

Расположение метаданных

На данный момент (я понимаю, что разработчики docker могут позже сменить реализацию), метаданные слоев образов (для чтения) находятся в файле с именем «json» в папке /var/lib/docker/graph/id_слоя:

где «e809f156dc985…» — урезанный id слоя.

Свяжем все вместе

Теперь, давайте посмотрим на команды, иллюстрированные понятными картинками.

docker create <image-id>

До:
docker create input

После:
docker create output

Команда ‘docker create’ добавляет слой для записи наверх стека слоев, найденного по <image-id>. Команда не запускает контейнер.

docker create

docker start <container-id>

До:
docker create output

После:
docker start output

Команда ‘docker start’ создает пространство процессов вокруг слоев контейнера. Может быть только одно пространство процессов на один контейнер.

docker run <image-id>

До:
docker run input

После:
docker run output

Один из первых вопросов, который задают люди (я тоже задавал): «В чем разница между ‘docker start’ и ‘docker run’?» Одна из первоначальных целей этого поста — объяснить эту тонкость.

docker run

Как мы видим, команда ‘docker run’ находит образ, создает контейнер поверх него и запускает контейнер. Это сделано для удобства и скрывает детали двух команд.

Продолжая сравнение с освоением Git, я скажу, что ‘docker run’ очень похожа на ‘git pull’. Так же, как и ‘git pull’ (который объединяет ‘git fetch’ и ‘git merge’), команда ‘docker run’ объединяет две команды, которые могут использоваться и независимо. Это удобно, но поначалу может ввести в заблуждение.

docker ps

docker ps

Команда ‘docker ps’ выводит список запущенных контейнеров на вашей хост-машине. Важно понимать, что в этот список входят только запущенные контейнеры, не запущенные контейнеры скрыты. Чтобы посмотреть список всех контейнеров, нужно использовать следующую команду.

docker ps -a

docker ps -a

Команда ‘docker ps -a’, где ‘a’ — сокращение от ‘all’ выводит список всех контейнеров, независимо от их состояния.

docker images

image

Команда ‘docker images’ выводит список образов верхнего уровня (top-level images). Фактически, ничего особенного не отличает образ от слоя для чтения. Только те образы, которые имеют присоединенные контейнеры или те, что были получены с помощью pull, считаются образами верхнего уровня. Это различие нужно для удобства, так как за каждым образом верхнего уровня может быть множество слоев.

docker images -a

docker images -a

Команда ‘docker images -a’ выводит все образы на хост-машине. Это фактически список всех слоев для чтения в системе. Если вы хотите увидеть все слои одного образа, воспользуйтесь командой ‘docker history’.

docker stop <container-id>

До:
docker stop input

После:
docker stop output

Команда ‘docker stop’ посылает сигнал SIGTERM запущенному контейнеру, что мягко останавливает все процессы в пространстве процессов контейнера. В результате мы получаем не запущенный контейнер.

docker kill <container-id>

До:
docker kill input

После:
docker kill output

Команда ‘docker kill’ посылает сигнал SIGKILL, что немедленно завершает все процессы в текущем контейнере. Это почти то же самое, что нажать Ctrl+\ в терминале.

docker pause <container-id>

До:
docker pause input

После:
docker pause output

В отличие от ‘docker stop’ и ‘docker kill’, которые посылают настоящие UNIX сигналы процессам контейнера, команда ‘docker pause’ используют специальную возможность cgroups для заморозки запущенного пространства процессов. Подробности можно прочитать здесь, если вкратце, отправки сигнала Ctrl+Z (SIGTSTP) не достаточно, чтобы заморозить все процессы в пространстве контейнера.

docker rm <container-id>

До:
docker rm input

После:
docker rm output

Команда ‘docker rm’ удаляет слой для записи, который определяет контейнер на хост-системе. Должна быть запущена на остановленном контейнерах. Удаляет файлы.

docker rmi <image-id>

До:
docker rmi input

После:
docker rmi output

Команда ‘docker rmi’ удаляет слой для чтения, который определяет «сущность» образа. Она удаляет образ с хост-системы, но образ все еще может быть получен из репозитория через ‘docker pull’. Вы можете использовать ‘docker rmi’ только для слоев верхнего уровня (или образов), для удаления промежуточных слоев нужно использовать ‘docker rmi -f’.

docker commit <container-id>

До:
docker commit running container или docker commit container

После:
docker commited layer

Команда ‘docker commit’ берет верхний уровень контейнера, тот, что для записи и превращает его в слой для чтения. Это фактически превращает контейнер (вне зависимости от того, запущен ли он) в неизменяемый образ.

docker commit

docker build

До:
Dockerfile dockerfile и docker image

После:
docker image
Со многими другими слоями.

Команда ‘docker build’ интересна тем, что запускает целый ряд команд:
docker build

На изображении выше мы видим, как команда build использует значение инструкции FROM из файла Dockerfile как базовый образ после чего:

1) запускает контейнер (create и start)
2) изменяет слой для записи
3) делает commit
На каждой итерации создается новый слой. При исполнении ‘docker build’ может создаваться множество слоев.

docker exec <running-container-id>

До:
docker running container

После:
docker exec

Команда ‘docker exec’ применяется к запущенному контейнеру, запускает новый процесс внутри пространства процессов контейнера.

docker inspect <container-id> | <image-id>

До:
docker inspect container или docker inspect image

После:
metadata

Команда ‘docker inspect’ получает метаданные верхнего слоя контейнера или образа.

docker save <image-id>

До:
docker save input

После:
docker save output

Команда ‘docker save’ создает один файл, который может быть использован для импорта образа на другую хост-систему. В отличие от команды ‘export’, она сохраняет все слои и их метаданные. Может быть применена только к образам.

docker export <container-id>

До:
docker export input

После:
docker export output

Команда ‘docker export’ создает tar архив с содержимым файлов контейнера, в результате получается папка, пригодная для использования вне docker. Команда убирает слои и их метаданные. Может быть применена только для контейнеров.

docker history <image-id>

До:
docker history input

После:
docker history output

Команда ‘docker history’ принимает <image-id> и рекурсивно выводит список всех слоев-родителей образа (которые тоже могут быть образами)

Итог

Я надеюсь, вам понравилась эта визуализация контейнеров и образов. Есть много других команд (pull, search, restart, attach и другие), которые могут или не могут быть объяснены моими сравнениями.

Автор:human

Про Git на пальцах (для переходящих с SVN)

Год назад мы с командой решили перейти с SVN на Git. Зачем это было надо — писать не буду, т.к. на эту тему уже и так много написано. А хочу я описать типичные алгоритмы работы, понятные человеку, который долгое время пользовался SVN. Ниже — памятка, написанная для команды год назад, чтобы легче было мигрировать. Надеюсь, кому-нибудь пригодится.

Немного об устройстве Git (упрощённо).

Git — распределённая VCS. Это значит, что мы работаем не с одним репозитарием на сервере, а каждый имеет у себя локальную копию репозитария. Соответственно, такие операции, как checkout и commit производятся с локальным репозитарием. Друг с другом же (или с тем, что на сервере) репозитарии синхронизируются специально предназначенными командами pull (fetch) и push.

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

Важное преимущество Git’а — внятная работа с ветками и удобный механизм слияний (merge). В SVN мы, как правило, работали с одной веткой trunk (в git ветка, с которой мы работаем по умолчанию, называется master). Эта же ветка заливалась на продакшн. Главное неудобство здесь — то, что если мы производим какие-то изменения, или разрабатываем новый функционал, мы вынуждены либо сидеть и не коммитить до тех пор, пока задача не будет доделана до конца, либо (если нам нужна помощь коллеги), закоммитить недоделанный функционал, как есть, сделав таким образом trunk непригодным к заливке на продакшн. Особенно это неприятно, если новый функционал делается не один день, а в это время возникает необходимость что-нибудь срочно починить в рабочей системе.

Надо отметить, что в SVN, конечно, есть ветки, но сделаны они, видимо, для другого, и поэтому плохо приспособлены для того, чтобы их сливать в trunk. В git операция merge сделана изящно и удобно, что позволяет нам существенно изменить workflow на более оптимальный.
Ещё одно отличие git в том, что он хранит не изменения, а текущее состояние проекта в каждый момент времени.

О главном.

  1. master — это та ветка, которая всегда, в любой (!) момент должна быть готова к деплою на продакшн.
  2. Поэтому мы никогда не делаем новые фичи и багфиксы сразу в master, используем для этого ветки.
  3. Полезно будет изучить статьи 1 2 3 4 и, возможно, даже Git book. В статье №2 oleganza  сформулировал очень важный принцип: одна фича — одна ветка. Один багфикс (если предполагается длиннее двух коммитов) — одна ветка. Один эксперимент — одна ветка. Одна фича внутри эксперимента — ветка от ветки.
  4. Всегда пишем вразумительные комментарии к коммитам.
  5. После того, как фича (багфикс) написаны, оттестированы и готовы к продакшну, мержим ветку в master.

Когда мы можем коммитить прямо в master? Только тогда, когда мы точно уверены в том, что наше мелкое изменение однозначно решит проблему и не создаст новых. Когда уверены, что не понадобится потом делать bugfix для bugfix’а. При этом, изменения должны быть минимальными.

Поэтому, хорошим правилом будет, всё же, создание отдельной ветки (за исключением совсем уж простых случаев).

Настройка.

$ git config —global user.name «First Last»
$ git config —global user.email «email@example.com»
$ git config —global color.diff «auto»
$ git config —global color.status «auto»
$ git config —global color.branch «auto»

Дополнительно можно настроить shell-alias’ы, как описано в статье №2.

Cтандартный workflow.

Шаг 1. Начало работы — клонирование репозитария.

Предполагается, что у вас уже есть и настроен gitosis, на котором лежит проект.

git clone gitosis@git.yourserver.com:yourproject.git — этот шаг делается один раз.

Результатом будет папка yourproject с проектом у вас на жёстком диске. Команда clone делает следующие вещи: клонирует удалённый репозитарий в новую папку (yourproject в данном случае), создаёт в локальном репозитарии remote-tracking ветки для всех веток удалённого репозитария, создаёт локальную копию активной в данный момент удалённой ветки и делает из неё checkout.

Шаг 2а. Написание нового кода или багфикс.

1. git branch — смотрим, какие ветки у нас есть в данный момент в репозитарии. Сразу после клонирования у вас будет видна только одна, активная в данный момент в удалённом репозитарии, ветка (в нашем случае это по умолчанию master, т.к. удалённый репозитарий находится на сервере и в нём ветки никто не переключает). Если в репозитарии есть другие ветки, их можно увидеть, добавив ключ -a (активная ветка обозначена звёздочкой):

$ git branch -a
* master
origin/HEAD
origin/master
origin/feature

2. Допустим, мы хотим заимплементить фичу feature. Создаём локально новую ветку с помощью команды branch. Командой checkout можно переключаться между ветками:

$ git branch feature
$ git checkout feature
Switched to branch "feature"

Или, что тоже самое, только короче:

$ git checkout -b feature
Switched to a new branch "feature"

3. В git есть такое понятие как индекс. Например, команда commit добавляет в репозитарий только те файлы, которые есть в данный момент в индексе. Поэтому, во время работы не забываем добавлять (git add ) или удалять (git rm ) файлы в/из индекса репозитария. Обратите внимание, что, в отличие от SVN, если вы изменили файл, его заново нужно добавить в индекс командой git add.

Например:

$ git add file1 file2
$ $ git commit -m "adding file1 & file2"
Created initial commit 8985f44: adding file1 & file2
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 file1
create mode 100644 file2

Здесь есть полезности: команда git add . добавляет все untracked файлы в индекс (рекурсивно), а ключ -a у команды commit позволяет автоматически добавить все модифицированные (но не новые!) файлы.

Текущее состояние индекса можно посмотреть командой git status:

$ git status
# On branch feature
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: file1
# new file: file2
#

Коммиты в репозитарии смотрятся командой git log.

4. Если мы хотим разрабатывать новый функционал совместно, нам нужно опубликовать нашу ветку на сервере, чтобы другие могли с ней работать. Вот как это делается (перед этим необходимо закоммитить все изменения в данной ветке):

$ git push origin feature:refs/heads/feature
Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 273 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitosis@git.yourserver.com:yourproject.git
* [new branch] feature -> feature

(в новых версиях git можно просто git push origin feature:feature)

Команда push отправляет изменения в удалённый репозитарий (origin) из локальной ветки feature в удалённую ветку featurе, предварительно создав её там (refs/heads/feature нужно как раз для создания ветки). В дальнейшем можно будет использовать git push origin feature (по умолчанию git push публикует изменения из всех веток).

Но при таком способе публикации, не устанавливается связь между локальной версией ветки и опубликованной. Т.е. если кто-то закоммитит изменения в эту удаленную ветку и вы сделаете git pull, то будет ошибка:

$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
From gitosis@git.yourproject.com:yourproject
d23a39c..b0a86e0 feature -> origin/feature
You asked me to pull without telling me which branch you
want to merge with, and 'branch.feature.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.

If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:

branch.feature.remote = <nickname>
branch.feature.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>

See git-config(1) for details.

Т.е. гит не знает с какой ветки ему мерджить. Поэтому можно либо каждый раз указывать это руками:

git pull origin feature

Либо прописать в конфиге:

git config branch.feature.remote origin
git config branch.feature.merge refs/heads/feature

Кроме того можно воспользоваться скриптиком от William Morgan и делать git publish-branch feature вместо всего остального.

Шаг 2б. Как присоединиться к работе над веткой.

Предполагается, что вы уже склонировали себе репозитарий.
Главное здесь — правильно подключить удалённую ветку. Сделать это можно с помощью ключа —track команды git checkout. Команда, приведённая ниже, создаёт локальную ветку feature и подключает её к удалённой ветке origin/feature, после чего переключается в эту ветку.

$ git checkout --track -b feature origin/feature
Branch feature set up to track remote branch refs/remotes/origin/feature.
Switched to a new branch "feature"

Это важно на данном этапе, поскольку просто команда pull смержит удалённую ветку к нам в master, а это не то, что нам нужно.

Далее можно работать аналогично описанному в шаге 2а, синхронизируя репозитарий в каждой из веток командами git pull и git push.

Шаг 2в. Как переключиться в другую ветку, когда в текущей есть изменения и коммитить их рано.

Иногда возникает необходимость срочно переключиться в другую ветку, например для багфикса. Но на полноценный коммит в этой ветке еще не хватает. Для этого существует команда git stash:

$ git status
# On branch feature
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: somefile
#
$ git stash
Saved working directory and index state "WIP on feature: b0a86e0... blabla"
HEAD is now at b0a86e0 blabla
(To restore them type "git stash apply")
$ git status
# On branch feature
nothing to commit (working directory clean)

Теперь можно смело переключаться в другую ветку и работать там.

По возвращению в эту ветку, необходимо сделать git stash apply:

$ git stash apply
# On branch feature
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: somefile
#

Шаг 3. merge и rebase.

Использовать какую-либо из этих команд вам понадобится в 2-х случаях:

  1. Вы хотите подлить свежие изменения из master к себе в ветку;
  2. Вы хотите слить свою ветку в master.

Общее правило такое: если мы работаем с веткой самостоятельно и не планируем публиковать её на сервере — то выгоднее использовать rebase. Если же мы публикуем ветку командой push, то использовать rebase НЕЛЬЗЯ, иначе мы автоматически инвалидируем работу коллег. Разница между merge и rebase хорошо показана на иллюстрациях в Git book: merge и rebase. Вкратце: rebase запоминает коммиты из ветки в виде патчей, «перематывает» текущую ветку (как будто и не было никакого branch) и применяет патчи, оформляя их в виде коммитов. В отличие от rebase, merge делает слияние двух веток в одну.

Примеры:

Подливаем изменения из master в рабочую ветку feature, ветку feature нигде не публикуем, работаем с ней только локально:

$ git checkout feature
Switched to branch "feature"
$ git rebase master
First, rewinding head to replay your work on top of it...
HEAD is now at 89f6a20 file2
Applying feature1

Сливаем изменения из рабочей ветки feature в master, ветка feature нигде не публиковалась, никто из коллег с ней не работал:

$ git checkout master
Switched to branch "master"
$ git rebase feature
First, rewinding head to replay your work on top of it...
HEAD is now at 9bfac0a feature1
Applying file2

Подливаем изменения из master в рабочую ветку feature, ветка feature опубликована на удалённом репозитарии, с ней также работают коллеги:

$ git checkout feature
Switched to branch "feature"
$ git merge master
Merge made by recursive.
file2 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file2

Сливаем изменения из рабочей ветки feature в master, ветка feature публиковалась на удалённом репозитарии для совместной работы:

$ git checkout master
Switched to branch "master"
$ git merge feature
Merge made by recursive.
feature1 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 feature1

Шаг 4. Удаление ветки.

После того, как мы закончили работать с веткой и слили изменения в master (или в другую ветку), можно удалить ветку.

Для удаления локальной ветки:

$ git branch -d feature
Deleted branch feature.

Для удаления remote tracking ветки:

$ git push origin :feature
- [deleted] feature

Вот, вроде, и всё. Этого должно быть достаточно в первое время при миграции с SVN на Git.

Отдельное спасибо хабраюзеру mironov_anton  за всяческие дополнения и улучшения данного текста.

Источник — https://habrahabr.ru/post/68341/

Яндекс.Метрика