17 октября 2013 г.

Генератор последовательных адресов

Вот, чтобы не забыть, скрипт написанный мною на питоне для генерации последовательных IPv4 адресов из указанного блока.

Сразу прошу прощения за отсутствие обработчиков исключений, - писался для себя и подразумевает осмотрительное использование. Собственно весь интерес - ф-ция yield (https://wiki.python.org/moin/Generators)
Вот пример вывода:

Надеюсь будет полезным не только мне. :)

3 октября 2013 г.

Использование deploy keys на GITHUB

В конце-концов добрались ручки до написания статейки по использованию сабжа в процессе автоматизированного развертывания проекта (как часть процесса CI). Итак, - дано: 
  1. Имеется репозиторий на GITHUB (публичный или приватный) 
  2. есть система CI (TeamCity, Jenkins/Hudson, scripts, или ещё что-то) работающая на каком-либо linux сервере. 
Все, вроде бы стандартно, при начальном деплое проекта делаем git clone репозитория, на запрос имени пользователя вводим свою учетку на github (или, вы же продвинутый?, авторизовались по ключам предварительно загруженным на странице аккаунта github), но это совершенно не подходит для организации автоматизированного деплоймента. Основная причина и очень часта проблема: разработчики все делают от имени своего аккаунта на VCS системах в том числе и интегрируют свои ключи в процесс CI. Не трудно догадаться что произойдет, когда разработчик по той или иной причине покинет команду, - он в праве изменить свои ключи, или вовсе их удалить и "медный тазик" быстро накрывает весь процесс деплоймента. 

Как избежать? ответ в сабже. GITHUB, в частности, поддерживает внедрение deploy-keys в сам репозиторий (Repository->Settings->Deploy Keys) что напрочь убирает вероятность сломать систему автодеплоймента. Теперь процесс по шагам: 
  1. На машине где проводится автодеплой генерируем ssh ключи (к примеру: ssh-keygen -t dsa -b 1024 -f ) от имени того пользователя который будет вызывать git pull . Советую генерировать dsa/1024 ключи для большей секурности. В случае если деплоится много проектов сразу на одну машину, рекомендую добавлять к имени файла-ключа ещё и имя репозитория в который он будет внедрен - так вы никогда не запутаетесь где именно какой ключ. 
  2. Внедряем публичную часть созданного ключа в GITHUB (собственно копируем и вставляем в Repository->Settings->Deploy Keys, дав ключу вменяемое название, - к примеру имя CI системы и хоста на котором она работает) 
  3. Обязательно необходимо сообщить ssh клиенту как общаться с GITHUB по ssh (по умолчанию необходимо использовать имя пользователя git, а не имя локального пользователя). Для этого необходимо внести соответствующие правки в /home/<deploy-user-name>/.ssh/config: где <reponame>.github.com - фейковое имя хоста для использования в ssh ссылке на ориджен в GITHUB, id_dsa. - приватная часть ключа сгенерированного выше. 
  4. Теперь немного магии (которая, конечно не магия вовсе - просто не совсем очевидный момент). В большинстве случаев для клонирования репозитория используется http ссылка на репозиторий на GITHUB, которая для нашего случая совсем не подходит. Надо либо сразу делать клонирование по ssh ссылке, либо заменить уже присутствующую http ссылку на ориджен (git remote rm <http:origin> затем git remote add <ssh:origin>). Не забываем менять в ssh ссылке имя хоста на <reponame>.github.com (создан выше как алиас для github.com но с другими учетными данными) 
Собственно вот и все. После этих процедур вы будете иметь возможность независимо от аккаунтов разработчиков деплоить проекты.