Comments 69
/etc/init.d/ssh restart
Всё же лучше использовать systemctl/service. Systemd же.
-A INPUT -m state --state NEW -p tcp -m multiport --dport 355 -j ACCEPT
не понятно, зачем нужен multiport, если открывается только один порт.
Вообще ни одна строка тут бы не сэкономилась при использовании докера.
С этой логикой можно сказать — используй meteor up и он поставит всё за тебя. Но только разница в производительности будет катастрофической.
Каждый выбирает инструменты для своих задач.
Минимальная просадка от использования докера — 5-10%.
От использования nginx для статики, честно говоря, я не считал. Имеено в плане отправке файлов они используют один и тот же модуль (sendfile) и скорость именно отдачи схожа, но Nginx обладает значительно меньшем оверхедом, и потребляет намного меньше памяти и CPU, что вполне ощущается по графикам нагрузки.
Минимальная просадка от использования докера — 5-10%.
Как вы считаете, из-за чего происходит эта просадка?
В идеальном случае контейнеризация работает, по сути, через алиасы к хост-машине, и тут просадка не ощущается почти совсем, если не считать использования методов которых на хост-машине нет (подходящим примером будут jail'ы c линуксом внутри, да ещё и какой-нибудь хитрой сборки).
А вот когда дело касается сетевых интерфейсов всё становится веселее, т.к. контейнер обладает своим сетевым интерфейсом, через которой и происходит общение, и, в итоге, в добавок мы получаем ещё и излишнее сетевое общение в пределах машины.
Я мог ошибиться в ряде мест, но по тем замерам, которые я делал, что-то такое и выходит. При большом количестве запросов (без перманентного соединения) всё становится ещё хуже.
Докер не уменьшает объём конфигурирования в целом, более того, частенько требует более объёмного конфигурирования. Другое дело, что это конфигурирование by design делается автоматическим и легко воспроизводимым
Реально это жутко бесит, когда говорят — да у нас тут докер, ща всё развернём за пол часа, и ты, как спец, тратишь целый день рабочий, думая что что-то не понял, что сам дибил. Зовёшь потом местного спеца и с ним ещё два сраный дня настраиваешь работоспособность. Это фан.
Само собой это проблема не докера, и он хорош в плане переиспользования. Но многие забывают его поддерживать.
Ну, я о ситуации, когда разработчик приложения если не сам пишет докерфайлы и скрипты/конфиги оркестрации, то, хотя бы, постоянно ими пользуется.
А так, да, если кто-то придёт на текущие проекты без меня, то увидев там файлы докера может опрометчиво решить, что нужно разворачивать проект с их помощью, а они уже несколько месяцев (с первого релиза) не обновляются, поскольку поддерживать две версии сценариев разработки (для дев и тест окружений — докер, для приемочного и продакшена — башскрипты и ручная правка конфигов) ресурсов не хватает.
Подскажите — в чём преимущество такого подхода? Docker прекрасен (удобен? полезен? даже не знаю как точнее выразиться) именно тем, что он даёт 99% идентичности среды, что вообще незаменимо при Continuous Delivery.
Я имею ввиду, что Docker даёт одно и то же окружение (образ), которое вы и гоняете на dev/qa/etc/prod. В чём смысл на дев использвовать одно — а на проде другое? Или вы просто не хотите Docker в продакшене вообще, и он у вас чисто как утилита тестирования?
Упоминание про ручное редактирование конфигов правда смутило ещё больше…
Собственно используем докер, чтобы максимально приблизить среды разработки и тестирования к производственным, без необходимости поднимать десятки виртуалок на рабочих местах разработчиков и прочих. Грубо, как более легковесную замену виртуалбоксу и вагранту. Докер (с докер-композ особенно) гораздо удобнее для локальной эмуляции прод окружений сложных систем, состоящих из десятков сервисов, шлюзов и клиентов, чем виртуалки, пускай и дает не 99% идентичности системного окружения, как дали бы виртуалки, а 90%. Да и эти 10% на практике выливаются в "на проде работает, а в докере — нет", что гораздо лучше чем наоборот :)
Не то, что мы не хотим, а отдел разработки не может преодолеть инертность отдела эксплуатации. Да и сам я как техруководитель разработки не готов настаивать на переносе в продакшен стейтфулл сервисов типа СУБД и файловых хранилищ. В теории хочу всё на докер перевести, но на практике просто не могу оценить риски потери данных и простоев. На "голом железе" всё более-менее предсказуемо и обкатано годами, а вот что может случиться с многослойной ФС и как её восстанавливать я просто не знаю, а случись что, эксплуатация ко мне прибежит.
Я далеко не мега-гуру Докера, но мне кажется в вопросе сохранности данных вы можете не переживать. Мы, например, просто данные монтируем к виртуальным машинам с Docker Host как внешние диски (на Azure) и/или шары NFS (AWS EFS) — со своей ФС, бекапированием и т.д. — ничего нестандартного. Ну а далее — через volumes к сервисам.
Как итог — ничего не экономит, а только удорожает.
Репозиторий артефактов сборки имеется (gitlab ci), супервизор штатный (systemd). Изоляция по портам требует дополнительного слоя маршрутизации на хосте в лучшем случае (например в http), а то и вручную перенастраивать клиентов. Изоляция по файловой системе тоже создаёт проблемы, когда нужно шарить файлы между процессами.
Поиск что же поставить в ту или иную опцию. Документация далеко не всегда даёт исчерпывающий ответ.
Последний тег отражает моё ощущение :-)
Ну и так же выпало, что обращался к проф. сисадмину, он 2 недели тянул, а по итогу было почти ничего из запрошенного. Пришлось бросать все планы и сидеть разбираться во всём самому.
Пожалуйста, дайте обратный отклик — что не так?
Мне видится что вышла отличная статья, для тех кто разрабатывает на метеоре и переходит к этапу развёртывания.
Спасибо.
Возможно по нынешним временам многие считают что ручное развертывание плохая практика. Если не "модными" инструментами, то хотя бы баш-скриптом, или, на худой конец, полным логом команд консоли с чем-то типа sed вместо визуального редактирования в vim и т. п..
Но чисто «готовый скрипт» будет бесполезен из-за кучи специфики.
В таком формате есть возможность понять что и зачем делается.
Я, вроде, ещё постарался разъяснить большую часть опций — что, зачем, почему и так далее.
Автоматизация же и начинается именно с того, что первый раз надо как-то пройти этот весь путь :-)
Ну и запускать чужие скрипты без разбора — такая себе идея.
Но спасибо за пояснение, пока это выглядит разумнее всего.
По грамотному так вообще пароль отключаем и используем ключ.
А ещё лучше через iptables разрешаем подключение на ssh только со своего ip.
При балансировке без ip_hash
, на сколько я понимаю, могут быть проблемы с веб-сокетами, так как соединение устанавливается в несколько запросов. Я с socket.io сталкивался с этой проблемой, но разницы в том, что лежит поверх ws, ddp или socket.io, в данном случае наверное нет. Вот тут есть немного информации.
В моём случае, так же, переключение не пренципиально, т.к. состояния не хранятся (точнее хранятся только в БД).
По хорошему, приклеенные к конкретным нодам соединения/сессии для балансировщика должен выступать в качестве рекомендации, не более, а балансировщик с нодами должны обеспечивать прозрачное для клиента переключение ноды, как в целях фэйловера, так и собственно балансировки.
Вполне вероятно, что-то я упустил
По разделу iptables могу посоветовать включить SYNPROXY.
Вещь простая и полезная, не позволяет атакам типа SYN-FLOOD доходить до уровня приложения, что достаточно важно для конфигураций типа вашей.
По моим наблюдениям этого не делают абсолютное большинство сисадминов.
Ниже пример, как исходная точка.
#!/bin/sh
DEV="eth0"
PORTS="80,443"
# SYNPROXY works on untracked conntracks
# it will create the appropiate conntrack proxied TCP conn
# NOTICE: table "raw"
/sbin/iptables -t raw -I PREROUTING -i $DEV -p tcp -m tcp --syn -m multiport --dports $PORTS -j CT --notrack
# Catching state
# UNTRACKED == SYN packets
# INVALID == ACK from 3WHS
/sbin/iptables -I INPUT 1 -i $DEV -p tcp -m tcp -m multiport --dports $PORTS -m conntrack --ctstate INVALID,UNTRACKED \
-j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
# Drop rest of state INVALID
# This will e.g. catch SYN-ACK packet attacks
/sbin/iptables -I INPUT 2 -i $DEV -p tcp -m tcp -m multiport --dports $PORTS -m conntrack --ctstate INVALID -j DROP
# More strict conntrack handling to get unknown ACKs (from 3WHS) to be
# marked as INVALID state (else a conntrack is just created)
#
/sbin/sysctl -w net/netfilter/nf_conntrack_tcp_loose=0
# Enable timestamping, because SYN cookies uses TCP options field
/sbin/sysctl -w net/ipv4/tcp_timestamps=1
# Adjusting maximum number of connection tracking entries possible
#
# Conntrack element size 288 bytes found in /proc/slabinfo
# "nf_conntrack" <objsize> = 288
#
# 288 * 2000000 / 10^6 = 576.0 MB
/sbin/sysctl -w net/netfilter/nf_conntrack_max=2000000
# IMPORTANT: Also adjust hash bucket size for conntracks
# net/netfilter/nf_conntrack_buckets writeable
# via /sys/module/nf_conntrack/parameters/hashsize
#
# Hash entry 8 bytes pointer (uses struct hlist_nulls_head)
# 8 * 2000000 / 10^6 = 16 MB
echo 2000000 > /sys/module/nf_conntrack/parameters/hashsize
# Hint: Monitor nf_conntrack usage searched, found, new, etc.:
# lnstat -c -1 -f nf_conntrack
Ссылки на тему:
Можно посмотреть слайды доклада DDoS protection Using Netfilter/iptables (автор Jesper Dangaard Brouer)
На Хабре была статья, основанная на этом докладе.
будет не лишним, да, пожалуйста.
Пишите дальше про почту и прочее. Весь негатив в топку.
Так вот он, какой, продакшен рептилоидов...
Я думаю, автор и так понимает, что держать мастер монги на tmpfs — затея с последствиями.
Поэтому просто прошу рассказать, большой ли выигрыш по скорости у вас получился от такой схемы?
Вроде бы монга и так неплохо справляется с кешированием в оперативке.
Я думаю, автор и так понимает, что держать мастер монги на tmpfs — затея с последствиями.
Более того, об этом даже в статье поясняется. :-)
Пока мало данных что бы полноценно оценить прирост, но в плане стабильности времени запросов стало лучше. Даже топовые SSD диски иногда давали спайки задержки (у всех провайдеров, как на виртуальных так и на физических), что рандомно давала задержку ответа — мне это дико не нравилось. Сейчас спайков нет от слова совсем.
Установка node.js в статье:
sudo apt-get install nodejs
sudo apt-get install npm
sudo npm install -g n
sudo n 4.8.1
То есть вы сначала ставите старую ноду из репозитория, чтобы через нее установить установщик новых версий node.js и, наконец, установить новую версию node.js.
Почему бы просто не последовать официальной документации, и не поставить ноду сразу из их репозитория?
В случае если следовать официальной, поставилась бы именно 4.8.2 и мне всё равно пришлось бы ровно так же откатываться назад.
Можно тут сказать что — ну это же минорная версия, тип, в чём проблема? Проблема в том, что я предпочитаю использовать официально совместимые версии, а не сидеть разбираться что же там обновили такое, повиляет ли оно на моё приложение или нет?
В общем, думаю, позицию пояснил.
На ветку 4.x сейчас выходят только исправления дырок в безопасности.
Так что обновление повлияет на ваш проект только положительно.
Спасло то что были бекапы и грамотная система откатов.
Теперь каждое обновление — в строго контролируемых условиях. Как минимум чтение всех чейнджлогов и мануальной проверки связанных частей. Это всё занимает время. Подобные траты времени (как и обновления) в большинстве случаев просто не оправданны.
Я реально не вижу абсолютно никакого смысла пытаться спорить по данному вопросу. Тут есть несколько вариантов:
а) Вы проверяете все обновляемые компоненты системы, т.е. затрачиваете какую-то часть времени именно на актуализацию, которая, в большинстве случае не даёт ничего.
б) Вы слепо верите, что минорная версия не поломает в вашем конкретному случае ничего (верить будете ровно пока не погорите на этом)
в) Кто-то отдельный занимается чисто поддержкой и обновлением пакетов в вашей компании и это экономически оправдано
г) Ваш вариант
Во-первых, открываем чейнджлог и читаем: исправили утечку памяти, обновили зависимость. В общем, вы не только усложняете процесс установки, но еще и сознательно отказываетесь от багфиксов, которые сделают работу приложения стабильнее.
И во-вторых, обновления системы вы тоже не ставите, а то "как бы чего не вышло"?
Для всех пакетов в списке ниже уже есть обновления.
Угадайте что произойдет когда я сделаю meteor update?
Проект станет не рабочим. Ломается миллион мест.
Что должно мотивировать меня обновить эти пакеты здесь и сейчас?
Вообще-то, мы здесь говорим не про meteor update, а про системный apt-get update.
У вас apt-get update никогда ничего не ломал? Вам повезло.
И все же, я оцениваю шансы на поломку от apt-get update намного меньше, чем от того, что сервер сложится от известной уязвимости, которая уже закрыта, но вы не обновили софт вовремя.
Кроме того, если регулярно обновляться, то будет намного проще найти вызвавший проблемы пакет, чем ждать, пока накопится куча изменений, в которых сложно разобраться.
А насколько меньше в процентах? Вот с месяц назад пришло с реп Ubuntu 16.04 обновление системное, закрыли какую-то уязвимость безопасности в DNS, а у нас стали появляться ошибки резолвинга в логах php, причём исключительно из под php-fpm, и баг не 100%, а плавающий, где-то один запрос на сотню, что уменьшило конверсию в 3 раза, а смок-тесты не выявили — число запросов оказалось недостаточно большим.
Ставить на продакшен обновления лишь потому, что они вышли — не самая хорошая практика. А уж без чтения ченжлогов — просто опасно. Хотя оно бы нас не спасло.
Мы здесь node.js обсуждаем, а вы приводите пример с PHP. Ничего не могу сказать, потому что не занимаюсь эксплуатацией php.
А с node.js работаю довольно давно и ни разу не сталкивался с проблемами при обновлении в пределах одной мажорной версии. А уж тем более, с LTS версией, патчи в которую попадают только после релиза и обкатки в более новых версиях.
Чего стоит, например, собственная внезапная интерпритация стандартов в одной из библиотек, когда они решили все http заголовки к одному виду приводить и изменили это в миноргой версии.
в одной из библиотек
Речь идет о самом node.js а не библиотеках в npm.
С npm-модулями конечно же нужно фиксировать версию. Для этого даже есть немало решений: npm-shrinkwrap, yarn.lock.
Node.js же развивается с обратно-совместимыми изменениями и обновления в рамках одной версии, например 4.x.x ставить не только можно, но и нужно.
1. Ваш бекап — это не бекап. Он вас не спасет от случайных drop|delete. И никак он вам не поможет откатить базу. Это просто еще одна реплика. У вас нет бекапа.
2. Монгу на рам диск? есть же специальный storage — memory. Тогда монга сама будет знать как использовать память и какого размера использовать буфферы.
3. Реплика сет на 4 ноды? это вот так выглядит
— В субботу терям бекап сервер — и откладываем его ремонт до понедельника( ну все ж работает и еще 3 есть)
— В воскресенье у нас что-то скушало рам (или умер один из дисков, или любая другая причина) — упал еще один процесс монги. Осталось два, но они оба в SECONDARY.
4. Задайте приоритеты у нод. А то у вас однажды при падении мастера все проголосуют за бекап. Который как я понял не особо сильный сервер.
1) Начнём с того, откуда возьмуться случайные drop/delete на мастер-монге? :-) Ниоткуда. Туда руками никто не лазит, а приложение такого не делает. Далее реплика на моём сервере располагается на ZFS, с которой делаются снимки 2 раза в день, которые ещё в добавок льются иногда на внешний диск и регулярно в Glaicer. Если интереснее подробнее — смотрите предыдущую статью про инфраструктуру.
2) Отлично. Вы ей пользовались? Нет. А почему? Потому что она стоит 15 000$ в год. Но вы этого не знали, само собой, и просто указали будто бы я решил по приколу сделать что-то странное. Мне важна была запись без спайков и я её получил. ВСЁ реализованно безопасно.
3) 3+1 будет сказать корректнее, т.к. бекап скрытый и на него нет переключение он не голосует. Я вообще работаю круглосуточно 7 дней в неделю уже 2 года :-) С чего мне откладывать? У нас миллиард мониторингов, добавим сотрудников, назначим ответственных — оповещения будут отправляться, может и отдохнуть удастся. А вообще в предыдущем сетапе у меня монга не падала НИ РАЗУ за год.
4) Не понимаю как вы вообще всё смотрели :-) Ну серьёзно. Все приоритеты указаны при инициализации реплики.
1. Про ZFS, снапшоты и предидущую статью у вас ни слова в статье. Откуда берутся delete? Конечно из кода. От необдуманных действий пользователей до неидеального кода. Не стоит называть реплику бекапом. Читатель статьи может подумать, что этого будет достаточно и без снапшотов
2. Вы меня не поняли. Я не про Atlas). Я про In-Memory Storage Engine
3. Это очень хорошо что вы можите сами все поднять. Но падает все — процессы, ядро, память, винты, сетевые карты. Про добавим сотрудников — даже смешно. Добавить админа вы не смогли(У вас же они есть, но почему-то делаете все вы)
4. вот тут я пропустил. Извиняюсь
2.) In-memory storage доступен ТОЛЬКО в enterprice версии. Поверьте, я всем этим интересовался, созванивался и обсуждал условия. Всё что мне сказали — 15 000$ в год за 1 (один) сервер. По другому in-memory не поюзать. Всё.
3) Про отказоустойчивость см. предыдущую статью про инфраструктуру (там всё заменялось как раз). Задачи получить отказоустойчивость в рамках данной статьи не было в принципе — была задача настроить MVP имея 1 сервер. Админов у нас нет, потому что на постоянку не нужен, а по фрилансу фиг найдёшь надёжного + ещё организовать это всё безопасно не просто.
Данный бекап защищает не от ошибок приложения, а от потери сервера.
Защита от потери основного сервера путём практически мгновенного переключения на уже готовый резервный сервер без потерь данных или с минимальными потерями на настоящий момент — одна из основных задачи именно репликации. Задача же бэкапа — восстановить сервер состоянием из прошлого.
Ну т.е. реплику, которая отстатёт на час. Это бекап?
А на сутки. Бекап?
Разница настройки — 1 строка (прокомментирована в настройках).
Запуск любого количества реплик с задержкой не представляет проблем.
Реплика с задержкой :)
Реплики осуществляются потоково, бэкап — снэпшотами. Восстановление из бэкапа операция идемпотентная — восстанавливать из одного бэкапа можно сколько угодно раз с одним и тем же результатом. С репликой же (работающей) мы каждый раз имеем разные результаты, синхронные с мастером или отстающие на случайную или детерминированную величину, но разные.
W: Репозиторий «http://ppa.launchpad.net/chris-lea/node.js/ubuntu xenial Release» не содержит файла Release.
E: Не удалось получить http://ppa.launchpad.net/chris-lea/node.js/ubuntu/dis… 404 Not Found
E: Некоторые индексные файлы не скачались. Они были проигнорированы или вместо них были использованы старые версии.
MeteorJS, Nginx, mongodb, iptables… продакшен