Translate

вівторок, 25 грудня 2012 р.

Nginx as reverse proxy for Apache

Усім відомо, що Apache є стандартом де-факто для веб-серверів. Розробники деяких CMS взагалі рекомендують користуватись саме Apache, і для налаштування їх під інший веб-сервер іноді необхідно попотіти. Але також ні для кого не є секретом, що Apache - важкий і ресурсоємкий сервер і на великих проектах від себе показує, м'яко кажучи, не дуже.
Тож одним із самих швидких варіантів оптимізації буде використання веб-серверу Nginx, як фронтенду до Apache. Тобто Nginx буде обробляти всю статику (запити на картинки, джаваскрипти, css і тд), а у випадку якщо відбудеться запит на php-скрипт чи щось таке (динамічний контент) - запит буде відправлено на обробку нашому "жирному" другу Apache-у.
Як показує практика такий варіант значно (!) економить ресурси серверу, адже запущених дочірніх процесів apache буде менше, з левовою часткою запитів буде справлятись Nginx.
Перейдемо до конфігурації.

1) Встановлюємо Apache (чи щось інше що буде у вас бекендом) та nginx з усіма запропонованими залежностями.

2) Конфігуруємо Nginx, щоб він слухав стандартний 80-порт і віддавав всю статику напряму, якщо буде запрошено динамічний контент  - запит буде відсилано Apache-y.

cat /etc/nginx/nginx.conf

# Використовуємо користувача від якого працює сервер Apache
user www-data;
# Кількість дочірніх процесів, обирають за к-тю ядер CPU
worker_processes 4;
worker_rlimit_nofile 8192;

# Місцезнаходження логу помилок і pid-файлу
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
  worker_connections 1024;
  use epoll;
  accept_mutex off;
}

http {
  server_names_hash_bucket_size 64;
  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  access_log /var/log/nginx/access.log;
  sendfile on;
  tcp_nopush on;
  keepalive_timeout 65;

  # Опції reverse proxy
  proxy_redirect off;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  # Опції gzip компресії.
  gzip on;
  gzip_http_version 1.0;
  gzip_comp_level 6;
  gzip_min_length 0;
  gzip_buffers 16 8k;
  gzip_proxied any;
  gzip_types text/plain text/css text/xml text/javascript application/xml application/xml+rss application/javascript application/json;
  gzip_disable "MSIE [1-6]\.";
  gzip_vary on;

  # Включення додаткових конфігураційних файлів
  include /etc/nginx/sites-enabled/*.conf;
}

пʼятниця, 21 грудня 2012 р.

Syslog-ng для централізованого збирання логів


Рано чи пізно постає питання про збирання логів всієї купи серверів, що у вас, у одному місці. І причин, щоб саме так зробити, є декілька: по-перше, так зручно, по-друге, - так безпечніше, адже логи будуть зберігатись в декількох місцях (як мінімум в двох). Коротше кажучи, якщо ви вже читаєте цю статтю - то ви маєте знати навіщо це вам.

Перейдемо до суті. Налаштування проводилось на двох тестових віртуальних машинах:

centos1 - 192.168.1.23
centos2 
- 192.168.1.24

Тому на кожну із них встановлюємо syslog-ng. В CentOS це робиться наступним чином:

# yum install syslog-ng

Нехай centos1 буде головним syslog-ng сервером, що буде слухати 514-й порт, приймати всі логи і розкладати куди-треба. Centos2 буде відправником логів на перший сервер.

Конфігураційний файл syslog-ng на centos2, тобто відправника логів:

#Опис джерела всього потоку логів, що власне нас цікавить.
source s_all {
  internal();
  unix-stream("/dev/log");
  file("/proc/kmsg" program_override("kernel: "));
  file("/var/log/dmesg");
};

#Описуємо які саме файли потрібно буде відсилати. Перед відсиланням до 
#кожної рядка логу буде додано назву демона, який його відіслав 
#(за допомогою опції 'program_override').
source mysqld_log { file("/var/log/mysqld.log" program_override("mysqld")); };
source httpd_log { file("/var/log/httpd/error_log" program_override("httpd")); };

#Описуємо місце/сервер куди будуть відправлятись файли
destination remote { udp("192.168.1.23" port(514)); };

#Найголовніша частина: куди саме і які будуть відсилатись логи.
log { source(s_all); destination(remote); };
log { source(mysqld_log); destination(remote);};
log { source(httpd_log); destination(remote);};

Конфігураційний файл syslog-ng на centos1, тобто сервера, що ці логи прийматиме:

# Описуємо джерело логів - сервер мережі.Тобто логи, котрі прийшли на порт syslog-ng.
source s_udp { udp(ip(0.0.0.0)); };

# Описуємо фільтри. Параметр match означає, що обирати з усього потоку повідомлень 
# лише рядки з указаним значенням
filter mysqld { match("mysqld" value("MESSAGE")); };
filter httpd { match("httpd" value("PROGRAM")); };

# Місце куди будуть зберігатись логи.
destination df_remote { file("/var/log/remote/$HOST.other.log"); };
destination mysqld_log { file("/var/log/remote/$YEAR.$MONTH.$DAY/mysqld.log" owner("root") group("root") perm(0640) dir_perm(0750) dir_group("root"));};
destination httpd_log { file("/var/log/remote/$HOST.apache.log"); };

# Власне сам процес логування - це комбінація всіх вищезазначених параметрів.
log { source(s_udp); destination(df_remote); };
log { source(s_udp); filter(mysqld); destination(mysqld_log); };
log { source(s_udp); filter(httpd); destination(httpd_log); };

Тобто, коротше кажучи все відбувається так:

1) Хост centos2 відправляє логи (всі системні логи+mysqld логи+apache логи) на centos1. Перед відправкою логи httpd помічаються значенням, що стоїть у параметрі program_override. Тобто кожен запис логу mysqld.log помітиться словом mysqld, відповідно httpd.log - словом httpd.

2) Логи, відіслані сервером centos2 приходять на centos1 і починають сортуватись. Всі логи загальні підуть в /var/log/remote/$HOST.other.log,а логи httpd та mysqld за допомогою директиви match будуть сортуватись в окремі папки.

Ну власне все, всі питання або зауваження пишіть в коментарі.

Посилання:
https://wiki.archlinux.org/index.php/Syslog-ng

неділя, 16 грудня 2012 р.

Налаштування MySQL-реплікації типу Master - Master (Slave)

Власне налаштування  реплікації серверів баз даних - дуже важлива складова будь-якого High Load проекту. Надіюсь, що ця невеличка замітка допоможе комусь в освоєні даної теми,  або ж принаймні нагадає мені певні деталі з часом.  :)



Тож до справи!
Для початку опишимо певні деталі. Будемо вважати, що сервера мають такі айпі:

centos1 - 192.168.1.23
centos2 - 192.168.1.24

Редагуємо /etc/my.cnf сервера centos1. Додаємо до вже існуючих параметрів такі:

[mysqld]
# Номер сервера, що реплікується. У кожного має бути унікальний id.
server-id = 1

# Конфігурація сервера, як майстра. Указуємо, де будуть зберігатись бінлоги. 
# Бінлог - це список SQL-запитів (окрім SELECT та SHOW запитів ), що були виконані на сервері задля подальшої їх передачі на слейв.
log-bin = /var/lib/mysql/mysql-bin

# Конфігурація сервера, як слейва. Relay-log - лог дій, котрі були виконані на слейві за ініціативи майстра.
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
#База, що буде реплікуватись.
replicate-do-db = dbwordpress

Для сервера centos2 необхідно прописати ідентичні параметри, окрім значення 'server-id' (змініть цифру наприклад на 2).
Рестартуємо mysql на кожному сервері.

понеділок, 9 липня 2012 р.

Веб-сервер за 5 секунд

Для швидкого підняття сервера задля роздачі файлів  найшвидким способом буде використання модуля SimpleHTTPServer для Python.
Все дуже просто:
1) Заходимо на потрібний хост:

ssh username@host -p port

2) Переходимо в директорію яку хочемо розшарити:

cd /path/to/dir

3) Виконуємо:

python -m SimpleHTTPServer

Сервер буде розміщуватись на 8000 порту. Дуже зручно задля швидкого розшарення великих файлів.


Знаю, для подібних цілей можна також використовувати netcat.

понеділок, 30 квітня 2012 р.

Встановлення програм на Playbook, використовуючи BB SDK

      Купивши планшет, одразу ж захотілось на нього щось встановити...Проте платити за програми, якими, можливо, і користуватись надалі не будеш, - не дуже хороша ідея. Ідеальний варіант: оцінив програму - купив, якщо ціна на неї в межах здорового глузду...

      Тож гугління на початку привело до DDPBInstaller-а та PB-Installer-a . Проте вони працюють лише в Windows-середовищі і зрозуміло, це не може виступати в якості нашої історії успіху.
До того ж додам, що вони досить таки помітно туплять при встановленні програм.

     Тож качаємо Blackberry SDK і встановлюємо:

cd ~/bbndk-2.0.1/
./bbndk.sh


*я роблю припущення що дистрибутив програми було завантажено у вашу домашню директорію.
     Додам скріншоти, щоб не здатись зовсім нудним.



Далі ще простіше. Переходимо в директорію:

cd ~/bbndk-2.0.0/host/linux/x86/usr/bin

І радісно виконуємо скрипт blackberry-deploy

./blackberry-deploy -password ваш_пароль -installApp -package /шлях/до/бар/файлу/example.bar -device айпі_планшету

Зрозуміло, що перед цим планшет потрібно перевести в development mode.

Ну ось наприклад як це буде виглядати в житті:


Просто ж підключити девайс можна виконавши команду:

mount -t cifs -o username=vasya.pupkin, password=qwe, rw //ip-playbook/media /media/playbook

Підключається планшет як Samba-сервер.

Додаткова інфа:


неділя, 4 березня 2012 р.

Blackberry Playbook. Чи варто купувати?


Так вже сталося, що ціна в 200 $ вплинула на моє рішення купити планшет. Після моїх роздумів був обраний Blackberry Playbook, не останню роль зіграв при цьому його розмір. Плюс я не зміг спокійно дивитися на його багатозадачність :)
Швиденько пробіжусь по його технічних характеристиках і якості виготовлення.
Отже, наш корпоративний друг ховає в собі:
- 7 " екран з розширенням 1024x600, зрозуміло, що сенсорний.
- Двох ядерний процесор ARM Cortex A9 (1 ГГц)
- Оперативну пам'ять 1 ГБ ( одразу після завантаження, ОС вже споживає половину )
- 16, 32 чи 64 Гб постійної пам’яті
- Роз'єми microUSB, microHDMI. Останній, як виявилось дуже навіть потрібний.
- Дві камери: фронтальна (3Мп) та тилова (5Мп). Автофокусу немає, проте вміє знімати відео високої якості, що навіть не соромно потім комусь його показати.
- Батарею Li-Pol (5300 мАг). Тримає заряд до біса довго. (біля 7 годин відносно активного використання)
Одним словом, потужності йому більше ніж досить. Йдемо далі.
Виглядає девайс так: