Денис Ильиных

1) Переустановите сервер;
2) Разрешите доступ к серверу по ssh только по ключу.

Как найти бекдор на сервере Линукс?

100 %-го варика нет. Можно конечно еще один точно такой сервер создать. Взять с него список файлов (вместе с его хешем) и сравнить со списком зараженного. Но оно того не стоит, лучше переустановите.

Как вариант:

SELECT m.id_sms, u.name as id_sender, m.message, m.id_recipient
FROM messages m
LEFT JOIN users u ON m.id_sender = u.id
ORDER BY m.id_sms DESC
LIMIT 100

Вообще - зависит от CMS.
Но есть универсальные варианты.
Например, заглянуть в супер-глобальный массив $_SERVER
echo '<pre>'; print_r($_SERVER); echo '</pre>';

И обратить внимание на нечто вроде $_SERVER['REQUEST_URI']

$command = '/start 123456 dsad';
$regex = '/(\/start\s)(\d+)/';
if(preg_match($regex, $command, $match)) {
    $num = $match[2];
    echo $num; // 123456
}

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

Давайте разберемся с инструментами и их предназначением, которые Вы используете:

• Комманда docker - это консольный интерфейс (CLI) для работы с Docker
  
• docker build создает по заданному Dockerfile образ контейнера
  
• docker tag присваивает указанному образу указанный тег (опция -t для build делает то же самое)
  
• docker pull скачивает указанный образ из удаленного регистра на текущую машину
  
• docker push заливает указанный образ в удаленный регистр
  
• docker run запускает новый контейнер из указанного образа
  
• docker ps выводит список текущих "бегущих" контейнеров
  

Команда docker не жонглирует файлами, она жонглирует образами и контейнерами, а они от нас абстрагированы Docker'ом, как что-то эфемерное. То есть выполняя комманду docker pull Вы не скачиваете образ в ту папку, где выполняете команду, и уж точно не скачиваете какие-либо файлы. Все что Вы делаете этой командой - это скачиваете образ в локальное хранилище Docker'а, дабы Docker daemon мог запустить контейнер на основании этого образа.

Команда docker-compose - это уже совсем другая команда. Все что она делает - это читает указанный YAML-манифест и выполняет соответствующие команды Docker. Это всего лишь позволяет декларативно указывать желаемые сценарии при работе с Docker в удобном формате. Но ни команда docker, ни docker-compose, не предоставляют ничего для того, чтобы транспортировать/обновлять версии Ваших манифестов где-то там. Docker, опять таки, жонглирует образами и контейнерами, не более.

У Вас в манифесте указана директива build:. Таким образом docker-compose пытается сначала собрать контейнер, вместо того, чтобы просто запустить его из образа.

Касательно совета docker-compose.yml под каждый env, все правильно советовали. Именно так это и задумывалось. Вы в манифесте указываете отнюдь не разные окружения (development, production), а набор контейнеров, которые должны бежать в одной связке одной логической единицей (концепция POD'ов). Ничего не запрещает делать и так, как сделали Вы, но это сродни использованию дуршлага в роли миски для еды: сегодня Вы нормально из него наворачиваете пельмени, а завтра супчик в нем уже куда-то не туда утекает.

Воркфлоу в Вашем случае можно организовать следующим образом:

1. На dev-машине у Вас один docker-compose.yml, согласно которому контейнер перед запуском собирается из сорцов.
   
2. Когда у Вас готова новая версия приложения, Вы его собираете через docker build, присваиваете ему номер версии через docker tag и отправляете в удаленный регистр образов через docker push.
   
3. На prod-машине у Вас отдельный docker-compose.ymlв котором указано запускать конкретную версию образа (и никаких build). Новая версия приложения - меняем тег образа в манифесте и перезапускаем контейнеры. При выполнении docker-compose образ автоматически скачается перед запуском, если его нет локально. Если же Вы обновили образ конкретной версии, которая уже была скачана ранее, то да, нужно выполнить docker pull перед стартом, дабы скачать новый образ.
   

Дополнительный совет:
Сборку образа и его заливку в удаленный регистр часто удобно автоматизировать с помощь Makefile'ов.

очему так мало сайтов в рунете используют данные фреймворки?

потому что это сайты. Потому что поисковики должны индексировать контент. Потому что это рунет. Потому что 90% разработчиков не достаточно квалифицированы что бы эффективно делать Single page Application-ы. Потому что 80% рунета сделано на wordpress/joomla/dle/etc. Ну как-то так.

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

Для всего этого есть решение - серверсайд пререндеринг. Делают его обычно либо при помощи сторонних решений в клауде (что обходится обычному блогеру/интернет магазинчику не дешево или тупо много рисков), которые так же не всегда безболезненно юзаются, так и на сервере средствами node.js. Причем популярность этот подход начал набирать в 2013-ом году с появлением react и концепцией виртуального дома (использовали и раньше, тот же твиттер). Причем в том же react это все еще не самая тривиальная задача сделать все так что бы небыло боли. Пока лидером в плане безболезненной реализации является Angular2, которому помогает dependency injection и километры абстракций. Но только он еще не вышел даже в релиз (хотя все уже фигачат на бете). Ну и опять же на "шаред хостинге" это не взлетит (с оговорками опять же, я встречал те где это можно провернуть без боли).

С каждым же годом количество SPA увеличивается. Со временем большая часть людей перейдут на похожие подходы. Опять же есть еще здравый смысл. Например пилить лэндинг на всяких там реактах или ангулярах или vue - это оверхэд. Тут и ванильного джаваскрипта хватит.

SELECT status, COUNT(id) FROM table GROUP BY status;

М.б. подойдет Jackson?

git submodules.

habrahabr.ru/post/60860
git-scm.com/book/ru/v1/%D0%98%D0%BD%D1%81%D1%82%D1...