Как стать автором
Обновить

Комментарии 69

/etc/init.d/ssh restart

Всё же лучше использовать systemctl/service. Systemd же.

-A INPUT -m state --state NEW -p tcp -m multiport --dport 355 -j ACCEPT

не понятно, зачем нужен multiport, если открывается только один порт.
Дело в том, что лично у меня там было несколько портов :-)
А так хорошее замечание, да, спасибо.
НЛО прилетело и опубликовало эту надпись здесь

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

Спасибо за интересную статью — у вас классный стиль изложения. Хотя, можно легко уменьшить в несколько раз, если использовать docker.
Если ты хочешь решить проблему с помощью Docker, то теперь у тебя две проблемы :-)
Вообще ни одна строка тут бы не сэкономилась при использовании докера.
С этой логикой можно сказать — используй meteor up и он поставит всё за тебя. Но только разница в производительности будет катастрофической.
Неплохо бы подкрепить нагрузочными тестами. А то все как-то через mup деплоят.
Это почти бесполезная тема, т.к. всё индивидуально.
Каждый выбирает инструменты для своих задач.
Минимальная просадка от использования докера — 5-10%.
От использования nginx для статики, честно говоря, я не считал. Имеено в плане отправке файлов они используют один и тот же модуль (sendfile) и скорость именно отдачи схожа, но Nginx обладает значительно меньшем оверхедом, и потребляет намного меньше памяти и CPU, что вполне ощущается по графикам нагрузки.
Минимальная просадка от использования докера — 5-10%.

Как вы считаете, из-за чего происходит эта просадка?
Так понимаю, что вопрос, на самом деле, провокационный.
В идеальном случае контейнеризация работает, по сути, через алиасы к хост-машине, и тут просадка не ощущается почти совсем, если не считать использования методов которых на хост-машине нет (подходящим примером будут jail'ы c линуксом внутри, да ещё и какой-нибудь хитрой сборки).
А вот когда дело касается сетевых интерфейсов всё становится веселее, т.к. контейнер обладает своим сетевым интерфейсом, через которой и происходит общение, и, в итоге, в добавок мы получаем ещё и излишнее сетевое общение в пределах машины.
Я мог ошибиться в ряде мест, но по тем замерам, которые я делал, что-то такое и выходит. При большом количестве запросов (без перманентного соединения) всё становится ещё хуже.
Мне правда интересно, как это воспроизвести. Если речь об одной машинке, то сетевые интерфейсы на линукс машинке это обычный бридж и несколько правил в iptables. При желании можно использовать host network, тогда вообще ни каких отличий не будет.
Почитаем на пальцах? SSH не нужен. Образ monogdb и конфиг один вместо трех — разницу задаем через переменные окружения и volume. Трюки с симлинками и пользователями убираем — версионность образов «изкаропки». pm2 так же исключается — у докера свой супервизор. Итого 2/3 статьи можно просто было не писать. Сценарии в виде Dockerfile, docker-compose вы бы могли выложить на github и дать возможность читателям на 100% воспроизвести решение, с точностью до приложения meteor.
Одно из метеор-решению хостю в докерах. Mup (или mupx, уже не помню) настроил, и на продакшене только git pull и mup deploy для обновления. Для постоянной разработки неудобно до невозможности, но как-то работает. Бэкаплю докер вместе с монгой, тут у меня сомнения как это делать правильно, сделал через какой-то npm-пакет docker-backup что ли… еще и руками в нём пути правил… свои заморочки тоже есть.
Сейчас до нагрузок дойдете и поймете цену этого удобства :-)
Вообще после этого случая я докеры как раз не люблю. Предпочитаю pm2 для node.js. Конкретно этот деплой внутрикорпоративный, нагрузок там не будет…

Докер не уменьшает объём конфигурирования в целом, более того, частенько требует более объёмного конфигурирования. Другое дело, что это конфигурирование 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 недели тянул, а по итогу было почти ничего из запрошенного. Пришлось бросать все планы и сидеть разбираться во всём самому.
Я ожидал что тема не популярная. Ну т.е. там ну 10 рейтинга… но отрицательный.
Пожалуйста, дайте обратный отклик — что не так?
Мне видится что вышла отличная статья, для тех кто разрабатывает на метеоре и переходит к этапу развёртывания.
Спасибо.
Лично мне полезно, я в избранное добавлю. Половину и так знал, другую половину как-то делал иначе (или вообще не делал) — но пост как шпаргалка очень нужен.

Возможно по нынешним временам многие считают что ручное развертывание плохая практика. Если не "модными" инструментами, то хотя бы баш-скриптом, или, на худой конец, полным логом команд консоли с чем-то типа sed вместо визуального редактирования в vim и т. п..

Само собой повторяться это ручками более не будет — я подготавливаю всю автоматизацию в bamboo.
Но чисто «готовый скрипт» будет бесполезен из-за кучи специфики.
В таком формате есть возможность понять что и зачем делается.
Я, вроде, ещё постарался разъяснить большую часть опций — что, зачем, почему и так далее.

Автоматизация же и начинается именно с того, что первый раз надо как-то пройти этот весь путь :-)
Ну и запускать чужие скрипты без разбора — такая себе идея.

Но спасибо за пояснение, пока это выглядит разумнее всего.
Отличная статья. Большое спасибо вам. Очень было бы интересно почитать про настройку почтовых сервисов и т.п.
А это нормально устанавливать SSH порт на значение из диапазона так называемых «well-known ports» (0-1023)?
Я на разных серверах проверял, 99% сканов (и подбора ssh пароля) именно SSH идёт на 22 порт. Если мы банально перенесли, то уже вышло значительно лучше. Я советую ставить рандомное значение туда. Поставьте 9358, например :-)
По грамотному так вообще пароль отключаем и используем ключ.
А ещё лучше через iptables разрешаем подключение на ssh только со своего ip.
Вполне нормально. Можно использовать любой порт, главное чтобы с другими не пересекался.

PS. Но, если очень хочется, то можно повесить и на один порт через мультиплексор, например sslh

При балансировке без ip_hash, на сколько я понимаю, могут быть проблемы с веб-сокетами, так как соединение устанавливается в несколько запросов. Я с socket.io сталкивался с этой проблемой, но разницы в том, что лежит поверх ws, ddp или socket.io, в данном случае наверное нет. Вот тут есть немного информации.

Nginx не настолько глуп :-) Соединение устанавливается без каких либо проблем и всё работает достаточно шустро.
В моём случае, так же, переключение не пренципиально, т.к. состояния не хранятся (точнее хранятся только в БД).

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

Вполне вероятно, что-то я упустил

По разделу iptables могу посоветовать включить SYNPROXY.
Вещь простая и полезная, не позволяет атакам типа SYN-FLOOD доходить до уровня приложения, что достаточно важно для конфигураций типа вашей.

По моим наблюдениям этого не делают абсолютное большинство сисадминов.

Ниже пример, как исходная точка.
iptables+synproxy.sh
#!/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)
На Хабре была статья, основанная на этом докладе.
Ну я бы еще добавил ipset с множеством пациентов, забаненных по IP — может пригодиться при DDoS-ах ограниченного масштаба.
«Если понравится подход/формат — выложу настройку почтовой системы, мониторинга инфраструктуры, CI через Bamboo и ещё ряд используемых у нас вещей.»
будет не лишним, да, пожалуйста.

Так вот он, какой, продакшен рептилоидов...


Я думаю, автор и так понимает, что держать мастер монги на 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.1, которая является последней поддерживаемой, а не 4.8.2
В случае если следовать официальной, поставилась бы именно 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. вот тут я пропустил. Извиняюсь
1. Данный бекап защищает не от ошибок приложения, а от потери сервера. Вопрос бекапирования это, блин, вообще отдельная огроменная статья. Задачу что у нас полетят диски в том или ином виде мы решим. Про ZFS и прочее читателю знать не надо, что бы совсем крыша не поехала :-) Когда человек решит заняться бекапами — он и будет изучать тему по бекапам.

2.) In-memory storage доступен ТОЛЬКО в enterprice версии. Поверьте, я всем этим интересовался, созванивался и обсуждал условия. Всё что мне сказали — 15 000$ в год за 1 (один) сервер. По другому in-memory не поюзать. Всё.

3) Про отказоустойчивость см. предыдущую статью про инфраструктуру (там всё заменялось как раз). Задачи получить отказоустойчивость в рамках данной статьи не было в принципе — была задача настроить MVP имея 1 сервер. Админов у нас нет, потому что на постоянку не нужен, а по фрилансу фиг найдёшь надёжного + ещё организовать это всё безопасно не просто.
Данный бекап защищает не от ошибок приложения, а от потери сервера.

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

Окей, как назовём реплику с задержкой? ;-)
Ну т.е. реплику, которая отстатёт на час. Это бекап?
А на сутки. Бекап?
Разница настройки — 1 строка (прокомментирована в настройках).
Запуск любого количества реплик с задержкой не представляет проблем.

Реплика с задержкой :)


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

Ок :-) Как писал ранее для такого у меня снимнки делаются. Но в целом вы правы.
Хотя, мне видится, что несколько реплик с хорошо подобраными задержками дадут результат лучше (хотябы по времени восстановления).
Спасибо за статью! Разрабатываю на метеоре уже достаточно долгое время, но темы развертывания приложения касаюсь только сейчас. До данной статьи думал что реально запускать приложение только через mup с помощью Docker. Но ваша статья доказывает иное. Используя mup, у меня возникла проблема с нужным репозиторием, а именно ppa.launchpad. При mup setup консоль выдает данную ошибку (Использую свое железо (Ubuntu Server 16.04.1 LTS)):

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: Некоторые индексные файлы не скачались. Они были проигнорированы или вместо них были использованы старые версии.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории