4 апреля 2014 г.

SaltStack: управление произвольным количеством файлов конфигураций

Переплываем на Хабр ) Кросспощу свою статью оттуда:
SaltStack: управление произвольным количеством файлов конфигураций

22 ноября 2013 г.

Знакомтесь - SALTStack

Этот пост будет первым из цикла по статей по использованию SALTStack

Итак, начнем!
Что такое SALTStack? (www.saltstack.com) Кроме всего прочего в этой системе можно выделить такие ключевые возможности:
  • Управление конфигурациями сервисов на нескольких серверах одновременно
  • Удаленный запуск команд на нескольких серверах одновременно
  • Получение информации о окружении в режиме реального времени.
  • Возможность взаимодействия с SQL/NoSQL базами данных для получения или сохранения конфигураций, результатов выполнения и прочей информации
  • Простота настройки и эксплуатации
  • Поддержка основных серверных платформ (Linux/Windows)
  • Написана на языке Python, который идеально для этого подходит.
Ок, скажете Вы, а что тут принципиально нового по сравнению с Puppet, CFEngine и прочими подобными системами? Да, эти системы выполняют примерно одинаковую функцию, а именно - управляют конфигурациями сотен сервисов на разных физических серверах или облачных конфигурациях. Но у SALT'а есть много отличий, а именно:
  • Скорость выполнения задач просто мгновенная, - в асинхронном режиме команду выполняют сотни клиентов одновременно.
  • Возможность запускать команды удаленно.
  • Обновление конфигураций по команде с сервера, а не автоматически клиентами.
  • Современность - поддержка облачных платформ наряду с обычными серверами.
  • Огромный community с тысячами рецептов.
Советую для лучшего понимания, начать с обучающего курса
http://docs.saltstack.com/topics/tutorials/walkthrough.html

21 ноября 2013 г.

Тонкости "итилизации" нашего IT

Это первая статья из будущего цикла по внедрению ITSM.

Ну вот и началось!... После успешного завершения курсов ITIL v3 Founation в головах коллег (да чего греха таить, - и в моей тоже) зародились мысли о том самом светлом и безоблачном идеальном IT отделе в своей любимой компании. Тут тебе и правильно оформленный и документированный сервис-ориентированный подход с формализованными процессами, и Service Desk с умными операторами первой линии умеющими пользоваться корпоративной базой знаний, и сама база знаний с описанными инцидентами/проблемами и вариантами их решений, и инцидент менеджмент построенный грамотно, и постоянные улучшения работают, и, естественно, премии за малое к-во выходов за рамки SLA по сервисам в процессе их функционирования, и ... Ну просто загляденье не правда-ли?
Но в процессе внедрения (о, нет, - слишком громко, - пока только в процессе сбора информации для внедрения) сталкиваемся с суровой пост-совковой бизнес машиной, которая как асфальтоукладчик нивелирует все Ваши потуги поднять IT отдел на качественно новый уровень. Я умышленно не буду говорить о крупных игроках рынка, - у них есть возможность нанять думающих в правильном направлении топ менеджеров, которые понимают, что без внедрения ITSM понимать и управлять IT отделом будет очень сложно, - сейчас о том бизнесе который уже вышел из этапа стартапа и, в процессе роста, испытывает острую необходимость оптимизировать рабочие процессы сам того ещё не понимая. :)
Основные проблемы с которыми придется столкнуться:
  • Бестолковый топ менеджмент. К сожалению в нашей стране при создании бизнеса мало кто из его создателей задумывается о том, как им правильно потом управлять. И действительно, - купил, привез, перепродал, - зачем много думать. "BP, ROI, CRM, ERP, и .т.д. этого мы не знаем, - это какие-то там люди в бизнес школах изучают, а нам и без этого все понятно"
  • Закостенелость компаний. Хорошо управляемая, динамично развивающаяся компания может менять что-либо в своей организации/деятельности/отношениях и т.д. очень быстро и без особенных потерь ресурсов и времени. А отличным показателем является возможность изменить что-либо даже без видимых выгод для компании, - просто чтобы не превратится в болото. Для таких компаний внедрения ITSM - не проблема. Надо поменять бизнес процессы, - пожалуйста, но только если это впоследствии приведет к видимым выгодам. Для закостенелых, не умеющих меняться компаний, процесс внедрения ITSM просто невыполним.
  • Отсутствие корпоративной базы знаний. Наше отношение к знаниям - просто отвратительно! Мы ничего не формализуем, а ведь формализация бизнес процессов дает тысячи выгод: не надо постоянно обучать новых людей отнимая время работающих, -человек сам может изучить описанные БП в которых будет участвовать пользуясь базой знаний. Не страшно потерять ключевого специалиста, - ведь все, что он делал для компании хорошо описано им самим же. Внедрение новых процессов и аудит текущих будет требовать значительно меньше времени.
  • В общем объеме - низкий уровень знаний персонала. "Тематические тренинги, курсы, семинары, сертификации для персонала? Нет не слышал! Ты на работу должен уже прийти со всем готовеньким!". Или: кум директора занимает руководящую должность в IT? Ну и что, что у него филологическое образование? :) Знакомо, - не так-ли? Особенно это относится к крупным государственным компаниям, да и бизнес таким частенько грешит.
Я привел лишь малую часть тех проблем которые необходимо решить, или хотя бы начать решать перед внедрение ITMS в компании. Ну а если это покажется вам не решаемым, - ну тогда скорее всего вам и не надо ничего внедрять.

... продолжение следует...

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 но с другими учетными данными) 
Собственно вот и все. После этих процедур вы будете иметь возможность независимо от аккаунтов разработчиков деплоить проекты.

11 июля 2013 г.

Удаление записи из известных хостов SSH

Не секрет, что администраторам linux систем часто приходится с одного и того же компьютера (рабочей/домашней машинки, к примеру) ходить по ssh на разные хосты. Не стану рассказывать зачем есть папка .ssh в хомяке, собственно как и файлы known_hosts и authorized_keys - нормальному админу грех этого не знать :) Но часто бывает проблема (даже не проблема, - так неудобство) когда уже внесенный в known_hosts публичный ключ некоего хоста становится инвалидным (толи хост-машину поменяли, толи DNS запись или IP адрес перенесли). В таком случае Вы получаете сообщение вида: Естественно нужно понимать, что произошедшее - действительно легитимное изменение фингерпринта хоста, а не хакерская атака. И вот Вам нужно просто снести изменившуюся запись для того, чтобы при следующей попытке зайти на хост снова прошел обмен ключами. Почти всегда это делается руками, но есть простая команда для автоматизации процеса. (у меня cat ~/.ssh/known_hosts | wc -l показывает 98! и копаться в них выискивая нужный ключ - прото долго) вот, что может Вам помочь.

29 июня 2013 г.

Быстрый консольный способ оценить скорость сетевого соединия в Linux

Предположим есть 2 хоста между которыми необходимо проверить скорость передачи данных. Такая задача возникает в случае необходимости периодически передавать между ними данные для понимания временнЫх издержек при передаче (это, к примеру, могут быть данные репликации MySQL для высоко нагруженной записями БД). Как оценить скорость, если под рукой только консоль? Очень просто, впрочем как и большинство таких задач в linux, просто не совсем очевидно :) Итак для тестов нам понадобятся утилиты nc и dd. На первом хосте (цель для передачи данных) запускаем: Запустили nc в listen mode на порту 12345 На втором хосте (передатчик данных )запускаем: В результате - получаете скорость передачи данных (от вывода dd)

5 марта 2013 г.

NGINX. Редирект статики для серверов разработки

Дошли, наконец-то руки описать один прелестный прием в сервере nginx. И себе - чтобы не забыть, и Вам, чтобы пользовали.
Итак: имеем production сервер с веб порталом и несколько development серверов, используем git для создания распределенных сред разработки (с последующим мержингом веток разных разработчиков и деплоем на production сервер). Рассмотрим подробнее один из серверов разработчиков (любой, в данном случае), а именно как сделать некоторые полезности при разработке веб портала. Так вот: есть клон git репозитория с файлами скриптов (и прочего стаффа веб приложения) с которым все ясно - программист пишет, комитит, апдейтит и пр. Но вот вопрос как быть с тестами написанного? Самым простым и действенным решением есть развернуть на сервере разработчика весь сайт, который тот разрабатывает и тестируй себе на здоровье! Но вот вопрос со статикой сайта (картинки, css, js, и т.д.) остается открытым - делать 5-20 копий статики накладно, ведь может занимать много места на диске. Потому, используя nginx можно брать статику прямо с production сервера. Нагрузки на него много мы не сделаем, а вот хлама на development серверах будет порядком поменьше, да и проблемы с синхронизацие будут отброшены за ненадобностью.
Собственно вот рецепт: (приведу часть рабочего конфига nginx с пояснениями)
Вообще-то - никакой магии - просто средствами nginx проверяется наличие локально запрошенного файла и, в случае его отсутствия, - редирект на основной сайт.
Вот так вот.

19 ноября 2012 г.

Глупости админиские. На прицеле - 5й национальный канал Украины

Ну не смог удержаться и написать сей пост. (Оным ознаменую ряд статей о том как много у нас горе-админов)
Суть сегодняшнего поста: приходик ко мне бедный пользователь и говорит, что старательно отправляет почту на имя одного адресата в домене @5.ua  (по этическим соображениям не буду указывать кого именно), а ему письма то не доходят вовсе, то доходят но с каким-то искаженным содержимым, то в спам попадают, то ещё какие-то грабли с ним происходят.
Ну у бедного пользователя стоит Chrome и через него он логинится в Google Apps Mail и отправляет письмо в 3 строки (не HTML, нет вложенных файлов, - вообще - просто 3 строки по русски!), а письмо не доходит.
Ок - копаем: Феерично, не правда ли? Разбираем криворукость по частям:
0. Ну, видно, что почта переехала на Google Apps Mail - похвально!...
1. Не особенная проблема, но смотрится странно - MX priority 0 - можно, но лучше не делать. Во всех мануалах стоит начальное priority = 10, ну да ладно...
2. pri=45 mail.5.ua - вот тут начинается магия, - хост вообще не отвечает на SMTP запросы, тоесть, судя по доменному имени там был почтовик, но либо времненно умер (на мемент выявления проблемы), либо умер уже давно, но из DNS не убрали.
3. pri=50 h7.prohosting.com.ua - видимо SMTP хостера, где лежит сайт. Самое удивительное, что он принимает почту для домена @5.ua хотя она и переехала на гугл!!!
и что мы там видим?  Бедолага, который выгребает почту с GMAIL совершенно позабыл про то, что его почта частично поступает ещё и на SMTP сервер провайдера, о чем говорит сообщение о переполненности ящика! Отсюда вытекают его жалобы на, то что он чего-то не получает...

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

16 ноября 2012 г.

FALLBACK сервис для WEB портала - спасаемся от проблем!

В этом посте я постараюсь описать одну из техник применяемых мною в повседневной работе при администрировании web серверов. Быть может кому-либо будет полезным такой метод.
Итак, дано:
  • есть web портал (php scripts/mysql databases/static files)
  • необходимость минимального простоя в случае сбоев
  • надобность иметь резервные копии содержимого портала
Вроде бы и так все понятно - резервные попии делаются по расписанию (день, месяц, год, ...), правильно (инкрементный бэкап, сбросы на ленту/DVD,...)- данные не потеряются! Чего ещё надо?
А вот вам ситуация, при чем далеко не гипотетическая: Ваш замечательный сайт http://www.mysupersite.com уже в первой десятке поисковой выдачи, народ валит к Вам на ресурс, реклама дает прибыль, - вобщем ляпота! Вы заглядывая в аналитикс не можете нарадоваться, и все у Вас правильно, и резервные попии и девелопмент сервер для программистов есть и вооще, - все как должно быть. Но тут, внезапно, сайт не отвечает, доступа к серверу нету, а саппорт хостера сообщает, что у них потоп/перегрев/вырубилась хост машина VPS/пропали каналы связи (нужное подчеркнуть) или в сервере сгорели винчестера (сразу 4 в RAID10 :) ) или ещё 100 причин по которым конечные пользователи портала его не видят. Кошмар! Надо что-то срочно сделать, - резервные копии есть, - разворачиваем новый сервак и понеслась...
Знакомо? Многим - наверняка да. Сколько времени потратили? от 1-го ... 2-х часов до нескольких суток (если физически вышли из строя комплектующие сервера, а нового нету).

Как я спасаюсь от этого? все просто - fallback web server! Идея была позаимствована (и немного модифицирована) из практик использованя fallback MTA (вторичный почтовый сервер который занимается отложенной отправкой писем электронной почты).

В общих чертах шаги которые надо проделать таковы:
  1. Заводим второй сервер (физический, если Вы хотите в случае аварии на основном в полном объеме поднять сервис или VPS в случае если необходимо просто "перебится" пока восстанавливается основной сервер) желательно, конечно же не на одной хост площадке, дабы и резервный сервер не накрылся "медным тазом" при проблемах у хостера.
  2. Делаем первичну полную синхронизацию сервисов (ставим такие же версии php/mysql/apache и т.д.), файлов (переносим конфигурации сервисов, статику сайта, скрипты сайта, user uploads и т.д.), баз данных (дампим/ресторим) - в общем делаем почти полностью зеркало сайта - отличатся они будут только адресами.
  3. Включаем master-slave репликацию для MySQL (в моем случае. подробнее: http://dev.mysql.com/doc/refman/5.0/en/replication.html) или подобные техники в любом другом любимом Вами сервере баз данных. Важно, чтобы в результате данные в базах в любой момент времени были синхронны.
  4. Пишем простецкие скрипты на bash с использованием rsync (подробнее: http://rsync.samba.org/) для синхронизации файлов на fallback сервер. Но, не забудьте грамотно выстроить процедуру синхронизации, так как  для очень большего количества файлов в проекте эта процедура может занять много времени, - стоит синхронизировать сайт частями в разное время (редко изменяющиеся скрипты сайта - раз в сутки ночью, файлы пользователей - раз в 1-2 часа.). Подскажу, сразу волшебную опцию для rsync: --bwlimit=<N> Kb/S - без неё вы просто "уложите" основной сайт при синхронизации данных!
Я умышленно не привожу готовых скриптов, примеров конфигураций и пр., для того, чтобы отсеять "linux эникейщиков" молодых администраторов не очень любящих думать своей головой.

После всего Вы получите сервер готовый в любой момент заненить вышедший из строя боевой. Как это сделать? Либо в мануальном режиме (заменить DNS/поменять IP на сервере если можно), либо в полуавтоматическом режиме (watchdog скрипт для мониторинговой системы), либо в полностью автоматическом (Keepalived/Heartbeat и прочие техники)

Каковы ещё выгоды от наличия такого сервера? Из очевидных:
  • Возможность делать резервные копии с fallback сервера не нагружая при этом основной боевой, что очень критично при дампах баз, которые могут блокировать таблицы
  • Быстрое восстановление работоспособности портала в случае серьёзных проблем на основном сервере.
  • Возможность проводить тестирование новых сервисов портала в боевых условиях (с оглядкой на проблемы с репликацией баз данных, подробнее: http://dev.mysql.com/doc/refman/5.0/en/replication-features.html)
  • Возможность при запредельной нагрузке на основной сервер, перераспределить нагрузку на fallback сервер. (я планирую написать отдельную статью про это)
К одной из неочевидных выгод (выявлены при экплуатации танных техник) относится выявление следов взлома основного сайта по синхронизированным файлам, которые взломщик использовал в ходе проникновения и потом удалил на основном сервере.

В любом случае - резервные копии  никогда не мешали! Удачи, - берегите сервера.