Сергей Рогожкин

Если Ваш отец считает, что в 50 он уже старик и ни на что не годен, ну что же, пусть ищет место сторожа.
Если же нет - почему Вы упоминаете возраст? Создается впечатление, что Вы считаете его неполноценным.

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

В итоге мы обратились вот к этому парню: skype: rustam1092 - Рустам (автор вот этой статьи lon10.net/post/otpravka-soobschenii-telegram-messe...), он за 1 т.р. установил нам на сервер Telegram и сделал тестовый php файлик который может слать сообщения. Также мы купили для этого симку которая была использована чтобы проверочные коды телеграма приходили. Еще не тестили как работает но в принципе должно, сервак отправляет сообщения и может в том числе слать картинки и какое то содержимое.

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

Как он видет с клиентом?
Какой % юзекров он охватывает (поддержка) ?
Как быть с теми у кого он отключен, не доступен, и вообще нету поддержки ?
Какие проблемы могут возникнуть при работе с ним ?

- не понимаю до конца вопроса, но клиенты видят нормально
- его нет только у пользователей IE < 9, опционально не отключается в браузере
- проблемы могут быть, если не зарулить его грамотно в nginx как часть url (а не как некоторые просто вешают отдельным портом). И еще конечно же при работе в сетях мобильных операторов, это надо отдельно тестировать.

wiki.nginx.org/HttpCoreModule#limit_rate
wiki.nginx.org/HttpLimitZoneModule#limit_conn

nginx.org/ru/docs/http/ngx_http_limit_req_module.html

1. Собака не имеет никакого отношения к include. Это не один оператор, а два совершенно разных оператора.
   
2. Увидев @ в коде ты можешь почти со стопроцентной уверенностью сказать, что его писал неграмотный пользователь, и пользоваться этим кодом не стоит.
   
3. Увидев в коде @include ты можешь смело считать его автора абсолютным лохом и нубом, а сам код надо выкидывать немедленно. Потому что @include глушит не только саму ошибку включения файла, но и все ошибки в этом файле - то есть, поступает стократ хуже. Это значит, что если автор допускает такие косяки в коде, то и все остальное у него тоже ад кромешный.
   
4. Самое главное. Ошибки надо не подавлять. Ошибки надо исправлять. Но опять же, делать это с умом. Начинающие программисты считают сообщения об ошибках своими личными врагами, и борются с ними всеми доступными средствами - с помощью @, error_reporting(0) и др. Получив линейкой по рукам и запомнив на всю жизнь, что так делать не надо, ониначинают с не меньшим рвением писать всякие проверки - лишь бы не допустить, не дай бог, ненавистного сообщения об ошибке. Например:
   
   

if (file_exists($inc))
{
    include $inc;
} else {
    echo "Файл не найден";
}

Так вот, это - еще хуже. Для начала, часть ошибок этот код все равно не отловит. Но это даже не самое главное. Главное - что вот это вот "Файл не найден" не имеет ни малейшего смысла. Пользователю оно ничего не скажет. А программист о нем не узнает. А если и узнает, то ничего не поймет! Какой файл? Где не найден? По какой причине? Системное сообщение об ошибке содержит массу бесценной информации помогающей идентифицировать ошибку, сообщая нам где она произошла, какой файл не найден, по какой причине не найден. Выдавать вместо этого огрызок "файл не найден" - это мазохизм.

И вот тут мы должны произвести натуральную революцию в неокрепшем детском мозгу: сообщение об ошибке не твой враг, а твой друг! И надо добиваться его появления всеми возможными способами! В том числе и выпиливанием бессмысленных проверок. Проверку можно ставить только если у нас есть сценарий обработки ошибки: к примеру, вместо этого файла мы можем заинклюдить какой-то другой, дефолтный. Тогда да - проверка имеет смысл. Но если это самый обычный инклюд, который всегда должен быть на своем месте, то его отсутствие обязано вызывать ошибку! Чтобы она была сразу показана на дев сервере и тут же исправлена. Чтобы она была записана в лог на продакшене и тут же исправлена.

Ошибки не надо подавлять. Ошибки не надо прятать. Ошибки надо исправлять.

Добавлю ответ на свой же вопрос.

Прошло достаточно времени и я успел посмотреть и попробовать множество инструментов связанных с Docker.

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

Приложение для администрирование развёрнуто на 1-м сервере, на нём есть Docker Registry , Jenkins и ещё пару веб страниц с разной информацией. Всё это обернул в Nginx , работает здорово. Само приложение тоже использует Docker , но обновлять его нужно руками (ssh and etc).

Сайт ( который на самом деле состоит из бизнес логики , DAL , Postgresql , Rest API , web-frontend , web-backend и ещё пару уровней абстракции :) ) использует содержит около 10 Dockerfile.

Внутри приложения использую инструменты сборки (grunt для nodejs) и собираю приложение во время сборки образа (docker build) , либо после запуска контейнера для продолжительной разработки с помощью FIG.

После правки кода, заливаю всё в git репозиторий, Jenkins собирает образы (docker build) и отправляет в Docker Registry, после чего сообщает серверам (сейчас он 1), что нужно обновить образы (docker pull) , и перезапустить контейнеры. Там где нужно сохранить данные , использую data containers , их я не перезапуска и не трогая.
Со временем хочу сохранять состояние data containers (docker commit) и заливать их на Docker registry (docker push) для бэкапа некоторых данных.

Сервер собирает и перезапускает обновлённые контейнеры с помощью самописных bash скриптов (они не сложные ), т.к. родные для Docker инструменты для этих целей ещё в стадии разработки (Docker swarm , Docker machine , Docker compose) , а стороние решения скорее всего умрут после выхода этих инструментов.

Через Environment variables говорю контейнеру в каком он режими работает (local/test/live), но нужно это только для минификаций и уровня логгирования. В этих настройках - чем меньше различия,тем лучше.

Всё это загнал в vagrant , отлично работает ,но требует хорошое железо для разработки.

В планах:
- научиться тегировать образы, что бы можно было откатить все сервера до рабочего состояния в случае багов.
- добавить процесс автоматического тестирования и оценки качества в Jenkins (для docker приложений нужно поднимать ещё jenkins slave )
- прикрутить ansible для деплоя и прочих удобностей для администрирования. Связать его с Jenkins

Итог:
-Однин раз написал, везде использую.
- Автоматизация до уровня commit = staging deploy
- Разделение административных инструментов и сервисов от бизнес приложения.
- Независимые компоненты ,которые можно легко заменить, слабая связаность.
ну и минусы:
- одному тяжело уследить за таким зоопарком )) Был бы администратор/DevOps , было бы зачительно быстрее всё.