Комментарии

Отличная статья. Что то похожее со списком вариантов монетизации собирал и для себя. Кое что открыл для себя новое. Спасибо.

Спасибо, в общем становится немного яснее. Так понимаю, в том примере что в статье (без каких-то дополнительных телодвижений), будет 3 варианта статики для nginx, 3 разных лога…, каждый в своем контейнере.
Было бы конечно очень интересно почитать про то, как практически это хозяйство организовать хотя бы на примере простого LAMP.
Получается, если выносить данные за пределы контейнера, получаем одну точку отказа, теряется весь смысл затеянного.

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

> Где вся эта парадигма контейнеров предусматривает хранение файлов?

В контейнерах.

Если вам одного инстанса мало, то вам нужна распределенная БД. А это уже совсем другой зверь и как правило не mysql.

К сожалению, исключительно вручную, Kubernetes это система управления контейнерами и работает она только с ними.
В последних релизах добавили возможность отдавать через kube-proxy статику, но, как я понял, её нужно раскладывать по серверам так же — вручную.

Поисковики борются за уникальность контента в сети, и борьба эта, должен сказать, ведется довольно жестко. Сайты-копии полностью или частично повторяющие контент «склеиваются», и в результате в поисковой выдаче мы видим только один из сайтов. С точки зрения борьбы с пиратством – довольно правильное решение, но и вебмастеру надо держать ухо востро.

Изначально приобретая домен и подключая к нему сайт, мы уже имеем два зеркала: domen.ru и www.domen.ru. Собственно, ничего страшного, но когда страницы нашего сайта начинают отрастать ссылочной массой, мы не можем контролировать — какой именно адрес указан в ссылке. В результате получаем, что примерно половина ссылок ведет на domen.ru, а половина на www.domen.ru. Яндекс, считая эти два адреса дублями, склеивает их в один – половину ссылок мы просто теряем!

Чтобы избежать данной проблемы, необходимо указать главное зеркало сайта – желаемый урл, который и будет виден в результатах выдачи. Сделать это можно несколькими способами: записать соответствующее правило директиве host в robots.txt, или настроить серверный редирект (лучше сразу 301, 302 предпочтительнее если необходимо «подклеить» неуникальные страницы на одном сайте) со страниц одного сайта на другой. Первый способ практичнее и предпочтительнее, если мы имеем дело с одним доменом и необходимо избавиться от www (или, наоборот, оставить только адрес с ними). Но, когда мы переносим сайт на новый домен, то придется использовать именно редирект, причем, чтобы не потерять позиции в выдаче, его придется настраивать для каждой страницы. Дело весьма хлопотное и трудоемкое, особенно при переезде больших проектов.

Чтобы помочь роботу быстрее произвести переиндексацию на главное зеркало при его смене в Яндекс Вебмастере имеется опция: Настройка индексирования → Главное зеркало. Где можно указать предпочтительное имя, вот только это не панацея и редирект использовать все равно придется.

Поисковики борются за уникальность контента в сети, и борьба эта, должен сказать, ведется довольно жестко. Сайты-копии полностью или частично повторяющие контент «склеиваются», и в результате в поисковой выдаче мы видим только один из сайтов. С точки зрения борьбы с пиратством – довольно правильное решение, но и вебмастеру надо держать ухо востро.

Изначально приобретая домен и подключая к нему сайт, мы уже имеем два зеркала: domen.ru и www.domen.ru. Собственно, ничего страшного, но когда страницы нашего сайта начинают отрастать ссылочной массой, мы не можем контролировать — какой именно адрес указан в ссылке. В результате получаем, что примерно половина ссылок ведет на domen.ru, а половина на www.domen.ru. Яндекс, считая эти два адреса дублями, склеивает их в один – половину ссылок мы просто теряем!

Чтобы избежать данной проблемы, необходимо указать главное зеркало сайта – желаемый урл, который и будет виден в результатах выдачи. Сделать это можно несколькими способами: записать соответствующее правило директиве host в robots.txt, или настроить серверный редирект (лучше сразу 301, 302 предпочтительнее если необходимо «подклеить» неуникальные страницы на одном сайте) со страниц одного сайта на другой. Первый способ практичнее и предпочтительнее, если мы имеем дело с одним доменом и необходимо избавиться от www (или, наоборот, оставить только адрес с ними). Но, когда мы переносим сайт на новый домен, то придется использовать именно редирект, причем, чтобы не потерять позиции в выдаче, его придется настраивать для каждой страницы. Дело весьма хлопотное и трудоемкое, особенно при переезде больших проектов.

Чтобы помочь роботу быстрее произвести переиндексацию на главное зеркало при его смене в Яндекс Вебмастере имеется опция: Настройка индексирования → Главное зеркало. Где можно указать предпочтительное имя, вот только это не панацея и редирект использовать все равно придется.

Последнее время сам пришёл к таким выводам, (спустя 8 лет работы). Согласен практически со всем сказанным выше. Очень много мифов, которые навязали крупные игроки и монополисты в сфере интернет.

Вот о бритве Оккама в ICANN, похоже, не слыхали, здесь вы правы :)

Придумали в Штатах, да. Слабо верится, что они даже представить не могли, что когда-нибудь оно разрастётся, или, например, объединится с другими сетями. Допустим. Но когда раздавали региональные зоны, зачем сделали межнациональную мешанину, не понятно. Впрочем, учитывая подход в целом…

Потом, для чего жителю Крыма, или любого другого региона, orange.mobi? — чтобы оттуда перейти на orange.crimea.ua, как это обычно делается. А почему бы сразу не выдавать последнее поиском? Или сразу не вбивать orange.crimea.ua? Зачем плодить сущности?

Если вносить .train и т.п., так можно весь словарь внести. Я как раз не считаю это необходимым. Мне, как пользователю, проще набрать s7.ru, чем выбирать между s7.com, s7.biz, s7.info и s7.aero

В целом система работает, да. Но я и не говорил, что она не работает.

IANA придумала. А то, что изначально домены только для Штатов — так, не поверите, Internet и DNS вообще в США были придуманы. Так уж исторически сложилось.

Выделение тематических доменов полезно хотя бы потому, что по домену orange.mobi можно сразу понять, что это — международный оператор мобильной связи Orange, а orange.crimea.ua — его крымское представительство.

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

Вообще, конечно, система немного неоднозначная, но она есть и она работает.

Меня всегда эта область «радовала». Кто это всё выдумывает? Кто придумал тест-драйв доменов? Кто придумал «зоны только для США»? В которые можно (должно?) все остальные тематические зоны зачислить — во-первых, чтобы всякие из третьего мира не мучались с выбором, а во-вторых, вне США мира нет, это всем известно. Кто придумал разделение коммерческое / некоммерческое? Для каких таких нужд? И что, работает? А если начал получать на некоммерческом денег — отдавай домен? Какой смысл выноса .travel или .aero? Чтобы пользователь мог перебором просмотреть все сайты в этой зоне, не отвлекаясь на другие? Почему тогда нет .train, .doglovers, .etc? Чем, вообще, .travel не .biz?…

Не проще ли было разделить доменные зоны только по региональному признаку? Имеешь представительство в другом регионе — регистрируешь соответствующий домен. Язык там свой.
Хочешь зайти на какой-нибудь Abcdef Xyz Ltd., но не знаешь, в каком оно регионе — пользуешь поисковик. Всё равно доменное имя не угадаешь. И т.п.

Из всех тематических доменов можно оставить разве что .name

Высказался :)
p.s. статья хорошая

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

Что такое GitHub и чем он отличается от Git

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

Здесь можно найти кучу open-source-проектов на разных языках и поучаствовать в них, разместить своё портфолио с примерами кода, чтобы приложить ссылку к резюме, подглядывать в открытых проектах интересные архитектурные решения, смотреть, как опытные разработчики пишут код, и скачивать огромное количество полезных в разработке и бесплатных инструментов для разработки. Кстати, некоторые умельцы умудряются собирать в GitHub целые библиотеки — книг и статей, а не программистские либы :)

И да, если вы недовольны какими-то фичами в любимой открытой программе и она выложена на GitHub, вы всегда можете прийти и поругаться в комментариях к проекту :) А лучше всего — оформить issue (мы расскажем, что это) и самостоятельно пофиксить проблему на радость всем пользователям. Не забывайте и благодарить авторов классных открытых проектов — донатами и просто тёплыми словами. Им будет очень приятно.

Придя практически в любую IT-компанию, вы столкнётесь с тем, что код где-то хранится — и в подавляющем большинстве случаев этим «где-то» будет именно GitHub. У GitHub есть довольно известный конкурент — GitLab, он тоже основан на Git, но это разные платформы разных компаний, хотя их функциональность очень похожа.

А ещё не стоит путать GitHub и Git. GitHub — лишь одна из реализаций системы контроля версий Git (только взгляните на полный список Git-клиентов с графическим интерфейсом), в которую добавлено много удобных инструментов и возможностей (те же комментарии, issues, гиперссылки, форматированный текст и тому подобное). Помните, GitHub можно использовать и без знания Git (обратное тоже верно).

Ну как, звучит круто? Тогда приступайте к нашему гайду о том, как пользоваться GitHub, чтобы во всём разобраться и вообще понять, нужен ли он вам прямо сейчас.

Придя практически в любую IT-компанию, вы столкнётесь с тем, что код где-то хранится — и в подавляющем большинстве случаев этим «где-то» будет именно GitHub. У GitHub есть довольно известный конкурент — GitLab, он тоже основан на Git, но это разные платформы разных компаний, хотя их функциональность очень похожа.

А ещё не стоит путать GitHub и Git. GitHub — лишь одна из реализаций системы контроля версий Git (только взгляните на полный список Git-клиентов с графическим интерфейсом), в которую добавлено много удобных инструментов и возможностей (те же комментарии, issues, гиперссылки, форматированный текст и тому подобное). Помните, GitHub можно использовать и без знания Git (обратное тоже верно).

GitHub это потрясающий инструмент и сервис, настоящая жемчужина в сегодняшнем наборе инструментов разработчика.

Мой опыт подтверждает ваши слова относительно того, что Swarm — это просто абстракция, которая, на сколько это возможно, стирает границы между разными машинами. Пока что у меня на нём работает тестовый кластер, который изначально был запланирован только для внутрикорпоративнх экспериментов, так что высоких требований по uptime у него нет, так что Swarm отлично подошёл как простой способ управления всем хозяйством с одной машины.
Вообще, Docker + Swarm вытеснили весь головняк с CFEngine, который хоть и решал проблемы, но всегда происходили какие-то накладки в конфигах, вылавливание которых порой занимало больше времени чем хотелось, так что в этом смысле мне нравится эта связка для текущих задач.

Я рассматривал Docker Swarm когда выбирал систему управления контейнерами. Выбор между Kubernetes и Docker Swarm сводится к необходимому функционалу. Это связано с тем, что изначальные задачи у них различаются.

Docker Swarm — способ использовать несколько машин как единую виртуальную среду для запуска контейнеров.

Kubernetes же позволяет не только запустить несколько машин, но и занимается балансировкой нагрузки, контролем запущенности и обновлением контейнеров (есть функция rolling-update позволяющая без простоя обновить pod'ы внутри RC).

Морочиться стоит в случае если:

Есть необходимость регулярного безпростойного деплоя
Необходимо обеспечить высокую отказоустойчивость
Необходимо обеспечить горизонтальную масштабируемость и балансировку не прибегая к «зоопарку» ПО
Вы не боитесь использовать в продакшне ПО находящееся в стадии альфа стадии разработки

Возможно я ошибаюсь на счёт Swarm, буду благодарен за дополнительную информацию по опыту работы с ним.

Я нырнул в мир Docker буквально пару месяцев назад и это просто потрясающе! Кроме того, что я построил проект, который благодаря Docker стал модульным, безопасным и прекрасным, я наконец смог переехать на Arch Linux благодаря тому, что теперь я и у себя на ноуте могу с минимальными накладными расходами (виртуалка с Linux на Linux мне не нравилась совсем, а с chroot много мороки) иметь окружение идентичное с боевыми серверами.

Тема управления кластеров с Docker контейнерами сейчас особенно популярна, лично я остановился на Docker Swarm. Преимущества:

официально поддерживается Docker
прост в настройке и использовании

К недостаткам Docker Swarm я бы отнёс:

возможно, слишком прост для построения изолированных инфраструктур
возможно, команде Docker лучше было бы фокусироваться на самом Docker, а не распылять усилия и заходить на территорию kerbernetes/fleet/mesos/…

Лично мне Docker Swarm нравится и пока что я им доволен как никогда. А какие у вас мысли по этому поводу? Стоит ли морочиться с Kubernetes для кластера из 10 машин?

Здравствуйте! Сделали сайт для клининговой компании в веб-студии DST по нужным параметрам и требованиям. Мы занимаеся уборкой как дял физических, так и юридических лиц. Сделали корпоративный сайт с описанием для каждой услуги. Выполнено все в оговоренные сроки, все изменения внесены. Благодарим за работу!