Docker + Consul. Начало

Современные технологии развиваются стремительно, каждый год, а то и реже мы узнаем об очередном прорыве в мире IT и вот, уже н е молодой, но подающий большие надежды проект Docker ворвался в нашу жизнь.

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

Для начала работы нам потребуется дистрибутив Centos7-minimal.
Далее переходим к установке и настройке Docker. Внимание, инструкция работает только для Docker версии 1.12 и выше (это на будущее :)!

Как в Linux найти и рекурсивно заменить строку во всех файлах?

Допустим нам требуется заменить email: root@mail.domain.ru на sf@nagg.ru во всех файлах в каталоге /home/www.
Наиболее оптимальным вариантом выглядит следующая конструкция:

find /home/www -type f -print0 | xargs -0 sed -i 's/root@mail\.domain\.ru/sf@nagg.ru/g'

В данной конструкции используется print0, ниже выдержка из man find:

-print0 (GNU find only) tells find to use the null character (\0)
instead of whitespace as the output delimiter between pathnames found.
This is a safer option if you files can contain blanks or other special character.
It is recommended to use the -print0 argument to find if you use -exec command or xargs
(the -0 argument is needed in xargs.).

После выполнения, мы можем проверить что root@mail.domain.ru более нигде не прописан (файлов в выводе не должно быть):

grep -rl 'root@mail.domain.ru' /home/www/

Supervisord – как запустить PHP воркер?

Довольно часто встречаются ситуации, когда необходимо запускать PHP воркеры, слушающие определенный порт. В случае падения скрипта или перезагрузки бэенда, а иногда и сервера, воркер приходится запускать руками, что совсем неудобно и не совсем правильно.
Рекомендую пользоваться популярной утилитой: Supervisord, которая позволяет организовать работу фоновых PHP процессов. Рассмотрим настройку на практике.

Установка Supervisord на CentOS:

yum install supervisor -y
chkconfig supervisord on

Настройка Supervisord:

В файле конфигурации (/etc/supervisord.conf), можно не вносить никакие правки, обычно настроек по-умолчанию достаточно.
Создаем наш конфигурационный файл в подключенной директории: /etc/supervisord.d/

/etc/supervisord.d/php-queue-worker.ini
[program:worker]
command=/usr/bin/php /srv/www/application/push-server.php
numprocs=1
directory=/srv/www/application/
stdout_logfile=/var/log/supervisor/push-server.log
autostart=true
autorestart=true
user=apache
stopsignal=KILL

OpenVZ: полезные команды для работы с контейнерами

Решил собрать все в одном месте, потому что часто что-то начинаешь искать и не находишь :)
В продолжение статьи OpenVZ: полезные команды на заметку пишу дополнения!

Установить для контейнера c CTID 10 512МБ ОЗУ и 1G SWAP:

vzctl set 10 --ram 512M --swap 1G --save

Установить для контейнера с CTID 10 2 ядра CPU:

vzctl set 10 --cpus 1 --save

Скрипт проброса портов: OpenVZ + iptables

Один из механизмов автоматизации, когда на твоем сервере очень много OpenVZ-контейнеров с серыми IP, чаще всего им требуется не только доступ к интернет, но и проброс портов, чтобы извне заходить в сами контейнеры по SSH / FTP или любому другому протоколу, не важно. Конечно, как вариант, подходит ручная правка /etc/sysconfig/iptables и reload сервиса, но это не очень удобно и все-таки допускает «человеческий фактор», в данному случае скрипты автоматизации помогают нам.
Недавно наткнулся на интересную реализацию скрипта iptables, который смотрит запущенные контейнеры OpenVZ и автоматически пробрасывает порты на каждый контейнер, это очень удобно!

Рассмотрим его работу на примере, допустим у нас есть 3 контейнера OpenVZ:

# vzlist
      CTID      NPROC STATUS    IP_ADDR         HOSTNAME
        20         11 running   10.11.0.20      test1
        21         11 running   10.11.0.21      test2
        22         11 running   10.11.0.22      test3

Далее нам надо проверить, что у нас включен NAT на физической машине, так выглядит ситуация когда все в порядке:

# iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 19 packets, 1451 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 12 packets, 947 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Git push fails: RPC failed; result=22, HTTP code = 411

If you attempt to push a large set of changes to a Git repository with HTTP or HTTPS, you may get an error message such as error: RPC failed; result=22, HTTP code = 411. This is caused by a Git configuration default which limits certain HTTP operations to 1 megabyte.
To change this limit run within your local repository

git config http.postBuffer *bytes*

where bytes is the maximum number of bytes permitted. For exmaple, set 500MB:

git config http.postBuffer 524288000

If you are using gitlab, you may need to change your nginx config too (/etc/nginx/sites-available/gitlab). More info: https://github.com/gitlabhq/gitlabhq/issues/3099

Мониторинг репликации Postgresql

Встроенная репликация в PostgreSQL 9 реализована благодаря журналу опережающей записи (WAL — Write-Ahead Log) с помощью пересылки XLOG-ов с главного сервера на подчиненный. При настроенной репликации на мастере и слейве запускаются дополнительные процессы: «postgres: wal sender process» и «postgres: wal receiver process», соответственно.
Судить о времени отставания slave-сервера от master-сервера можно сопоставляя текущие позиции записей журнала WAL: текущей на мастере и принятой/примененной на слейве. Их можно получить используя pg_current_xlog_location и pg_last_xlog_receive_location/pg_last_xlog_replay_location, соответственно.

Для работы скрипта необходимо будет установить bc

yum install bc

Настройка SSL для сайта и получение оценки A+

В предыдущих статьях я рассказывал как настроить SSL для Вашего сайта. В настоящее время появились сервисы которые предоставляют SSL-сертификат бесплатно на один год и даже такие6 которые автоматически его продлевают :) Это очень уобно, но об этом обязательно поговорим позже. В данном примере я опишу ситуацию, когда бесплатный сертификат уже получен, но при тестах выдает невысокую оценку (B).

В данном примере используется веб-сервер Nginx, сами сертификаты хранятся в каталоге /etc/nginx/ssl
Переходим в каталог /etc/nginx/ssl и генерируем ключ ключ Деффи-Хеллмана:

cd /etc/nginx/ssl
openssl dhparam -out dhparams.pem 2048; chmod 600 dhparams.pem

Редактируем файл конфигурации nginx, отвечающий за работу Вашего сайта. Важно отметить, что версия Nginx должна быть выше 1.3, иначе OCSP не включится и мы получим оценку (A-).

Утечки памяти в Sphinx

Возникла ситуация, когда sphinx потреблял большое количество памяти и от этого падал. Всё дело в параметре max_matches. Более подробно ниже:

‘max_matches’ – integer (per-query max matches value)

Maximum amount of matches that the daemon keeps in RAM for each index and can return to the client. Default is 1000.

Introduced in order to control and limit RAM usage, max_matches setting defines how much matches will be kept in RAM while searching each index. Every match found will still be processed; but only best N of them will be kept in memory and return to the client in the end. Assume that the index contains 2,000,000 matches for the query. You rarely (if ever) need to retrieve all of them. Rather, you need to scan all of them, but only choose «best» at most, say, 500 by some criteria (ie. sorted by relevance, or price, or anything else), and display those 500 matches to the end user in pages of 20 to 100 matches. And tracking only the best 500 matches is much more RAM and CPU efficient than keeping all 2,000,000 matches, sorting them, and then discarding everything but the first 20 needed to display the search results page. max_matches controls N in that «best N» amount.

This parameter noticeably affects per-query RAM and CPU usage. Values of 1,000 to 10,000 are generally fine, but higher limits must be used with care. Recklessly raising max_matches to 1,000,000 means that searchd will have to allocate and initialize 1-million-entry matches buffer for every query. That will obviously increase per-query RAM usage, and in some cases can also noticeably impact performance.

Скрипт сканирования портов для Linux

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

Для работы скрипта требуется установленная утилита nmap.
Назначение: Данный скрипт сканирует TCP и UDP порты на хостах из списка.

Теперь перейдем к самому скрипту и описанию его работы!