Is your DNS round-robin setup really round?

round-robin

Just test!

Take this simple script and test on your own, with python 2 or 3.

Options:

usage: dns_round_robin_test.py [-h] [-c COUNT] [-d DELAY] name

positional arguments:
 name                  DNS name to test

optional arguments:
 -h, --help            show this help message and exit
 -c COUNT, --count COUNT
                       set total count of resolves
 -d DELAY, --delay DELAY
                       set delay between resolves in 1/100s of second

Sample run command:

$ ./dns_round_robin_test.py google.com -c 20

Sample output:

================ google.com ================ 20/20
 188.43.66.170 [                ||||| 25.0%] 5
 188.43.66.187 [                ||||| 25.0%] 5
 188.43.66.174 [           |||||||||| 50.0%] 10

Комментариев нет »20.12.2015 17:15:06 | English, Делаю | , , , ,

Поставить сервер непрерывной интеграции Jenkins на Ubuntu

Дано:

Ubuntu 12.04 LTS (серверная или настольная редакция).

Надо:*

Установить сервер непрерывной интеграции Jenkins.

Решение:

Всё очень просто (см. http://pkg.jenkins-ci.org/debian/):

  1. Добавляем ключ репозитория Jenkins:
    wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
  2. Добавляем сам репозиторий:
    echo "deb http://pkg.jenkins-ci.org/debian binary/" | sudo tee /etc/apt/sources.list.d/jenkins.list
  3. Обновляем информацию о доступности пакетов программ с учетом нового репозитория:
    sudo apt-get update
  4. Устанавливаем нужное:
    sudo apt-get install jenkins jenkins-cli ant openjdk-6-jdk

Сразу после установки у вас будет доступен сервер Jenkins по адресу http://localhost:8080/ .

Замечания:

Дополнительно установлен интерфейс командной строки для управления Jenkins. Его опции доступны по адресу http://localhost:8080/cli .

Пакеты ant и openjdk-6-jdk нужны для непосредственной работы заданий тестирования и сборки, самому Jenkins они не требуются.

Для начала работы желательно сходить в Центр управления плагинами и обновлениями: http://localhost:8080/pluginManager/ .

 

* Да, я тут лукавлю, ибо цель не в самом сервере НИ, а в том, что он умеет делать, но не всё сразу 😉

Комментариев нет »09.08.2012 10:55:21 | Ubuntu, Делаю | , ,

2 сервера на Python

Интересные открытия ждут новичков при исследовании функциональности Python интерпретатора и состава библиотек.

SMTP сервер для разработчика

Команда:

python -m smtpd -c DebuggingServer -n

Что делает:

Выводит всё, что приходит по стандартному smtp протоколу на стандартный вывод. Можете перенаправить в файл, можете смотреть так, в терминале. По умолчанию ожидает соединения на порт 8025 (стандартный 25 порт использовать без повышения привилегий нельзя). Для дополнительных опций и возможностей смотрите документацию.

Веб сервер для статики или передачи файлов

Бывает так, что надо посмотреть что-то по http протоколу, т.к. политики браузера не разрешают это через file://. А бывает, что надо что-то большое передать по сети коллеге, что выкладывать на друпбоксы долго, а расшаривать папки муторно (или запрещено файерволами).

Команда:

python -m SimpleHTTPServer

Что делает:

Даёт доступ по http ко всем файлам в текущем каталоге. index.html работает, список файлов при его отсутствии выдаёт. По умолчанию использует 8000 порт (стандартный 80 порт использовать без повышения привилегий нельзя). На стандартный вывод пишутся логи запросов, что также удобно. Для дополнительных опций и возможностей смотрите документацию.

Комментариев нет »04.05.2012 16:14:17 | Изобретаю | , ,

Забыть md5

Интересно, но я до сих пор считал, что md5 хеш в текстовом представлении (32 символа) для идентификации объектов — весьма не плохо. И коллизии маловероятны. Тем не менее, если не нужно привязываться к контенту объектов (как в git, к примеру, который, к слову, использует более длинный sha1), то можно поискать что-то более интересное и короткое.

Например, почитав статью Размещение, можно заключить, что у md5 при длине 32 символа возможно 16^32 вариантов. Это отлично! Однако не всегда нужно, поэтому могу предложить более простую реализацию: используя все символы английского алфавита и цифры можно получить достаточное количество вариантов ключей, надо лишь подобрать нужную длину для вашей задачи. При 5 (пяти, всего пяти!) знаках — это уже почти миллиард вариантов.

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

Регистрационный код по электронной почте, верификационный код какой-либо купонной системы, ссылка на информационный UGC элемент… Тут есть выигрыш при использовании более короткого кода. Хотя бы от того, что сам код становится менее страшным для человека (психологический момент использования сервиса) или ссылки в коде страницы станут короче (в случае UGC) — страница меньше и быстрее.

Это всё копейки. Но по копейкам набегают миллионы 😉

/*
 * Пример генерации кода на PHP
 */
function makeCode() {
  $a = '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; // 62 символа
  $l = strlen($a) - 1;
  $c = $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] .
  $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)]; // 10 знаков
  return $c; // число возможных размещений: 62^10 = 8,392993659*10^17
}

PS: На коллизии не забывайте проверять!

комментария 2 »29.03.2012 13:00:25 | Изобретаю | ,

Грабельки deployment при наличии opcode кэша

Привет, PHP разработчик, администратор или релиз-менеджер! Наткнулся на интересное, спешу поделиться.

Дано:

Проект на PHP, одновременно работающий в режиме разработки («DEV», из SVN), а также боевом режиме («LIVE»), в который переводится ветка DEV после отлова багов. Сервер примечателен только тем, что PHP запускается через php-fpm и там включено opcode кэширование. У меня нижеследующее проявилось и при XCache и при APC.

Надо:

Перевести отлаженный проект из режима разработки в режим работы.

Решаем:

Итак, имеем примерно такую структуру проекта (ненужное вырезано):

.../dev/
       /app/
           /index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
       conf.php       : <?php $me = 'dev';
.../live/
       /app/
           /index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
       conf.php       : <?php $me = 'live';

Два виртуальных хоста в web сервере берут данные из …/dev/ и …/live/, где лежит соответствующий код. Всё работает, opcode кэш ускорят работу, все счастливы. Запрос на …/dev/app/index.php возвращает «dev», на …/live/app/index.php — «live».

Но вот пришла пора выложить код из DEV в LIVE как можно более быстро и без глюков. Понятно, что вариантов море, один из пришедших в голову был таков: для deployment использовать 2 команды переименования каталогов. Это на самом деле весьма «дешево»: операционная система сделает очень мало работы в очень короткое время, сбои крайне маловероятны:

mv .../live/app .../bak && mv .../dev/app .../live

И вот в очень короткое время мы переместили код. Всё хорошо? Нет! Запрос на …/live/app/index.php возвращает «dev», сайт работает с тестовыми данными разработчика! 🙁

Расследование:

Собственно, поиск причины был не сильно долгим. Мы переместили ветку файловой системы, идентификаторы файлов («inode») внутри ветки не поменялись и op-кэш наивно думает, что ничего не поменялось, т.к. он идентифицирует код по идентификатору файла. Ну и в итоге в окружении LIVE лежит файл, который запускается интерпретатором PHP со включенным файлом конфигурации на момент попадания в кэш — это был файл из DEV ветки. Вот так.

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

Что делать?

Один из вариантов, и как мне кажется правильный — это запустить два экземпляра php-fpm обработчика. Отдельно для DEV и LIVE окружений. Или полностью исключить некоторые файлы из кэширования.

Комментариев нет »10.02.2012 12:38:48 | Делаю | , ,