Всем известно, что с помощью ssh можно делать перенаправление портов (создавать туннели). Еще из мануала по ssh вы могли узнать, что OpenSSH умеет динамически открывать порты для удаленного перенаправления и выполнять строго определенные команды. Также всем известно, что для Ansible (не считая Tower) нет такого понятия как сервер и клиент (в смысле ansible-server/ansible-agent) — есть сценарий (playbook) который можно выполнить как локально, так и удаленно через ssh-соединение. Еще есть Ansible-pull, это скрипт который проверяет git-репозиторий с вашими плейбуками и при наличии изменений запускает плейбук для применения обновлений. Там где нельзя пушить в большинстве случаев можно использовать pull, но бывают исключения.

В статье я попробую рассказать о том как можно использовать динамическое выделение портов для ssh-туннелей в реализации подобия функции provisioning-callback для бедных на любом сервере с OpenSSH и Ansible, и как я до этого дошел.

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

Компания, в которой я сейчас работаю, уже около года использует HipChat Server для внутренних коммуникаций в команде разработчиков и админов. Причем, это именно self-hosted виртуальная машина на KVM с qcow2 образом диска. И вот, недавно возникла необходимость перевозить внутренние сервисы на AWS, я стал искать пути. Вариантов на самом деле было немного:
— Конвертация qcow2 > raw > ami.
— Официальный подход — экспорт чатов, пользователей, комнат и файлов (без паролей, интеграций и ключей апи).
— третий вариант, который опишу ниже.

Как работают системные администраторы, что используют в своем повседневном труде, какие утилиты облегчают нам жизнь?
Мы постараемся вкратце ответить на эти вопросы и описать, как устроена наша работа.

Итак, что в принципе, должен делать (уметь делать) системный администратор:
Устанавливать/обновлять/удалять ПО
Настройку ПО
Планировать работы
Документировать
Мониторить состояние ИТ-систем
Диагностировать и поддерживать ИТ-системы
Резервное копирование/архивацию ПО и данных

Для всего этого есть немало различного ПО, постараемся описать все самое необходимое.

Средства для резервного копирования информации можно разделить на несколько категорий:
— Для домашнего/офисного применения (резервирование важных документов, фотографий и пр. на NAS либо в облако);
— Для средних и крупных (offline) предприятий (резервирование важных документов, отчетности, баз данных и пр. как на серверах так и на рабочих станциях сотрудников);
— Для малых веб-проектов (резервирование файлов и баз данных с хостинговой площадки либо VPS/VDS на удаленный хост (или наоборот));
— Для крупных веб-проектов с распределенной архитектурой (почти то же самое, что и на offline-предприятиях только с учетом работы в глобальной сети, а не локальной, и как правило с использование open source средств).

С программными продуктами для дома и офиса все достаточно просто есть масса решений как открытых так и проприетарных, от cmd/bash скриптов до решений известных производителей ПО.
В enterprise секторе все достаточно скучно есть масса программных продуктов которые давно и успешно работают на многих предприятиях, в крупных банках и пр, рекламировать никого не будем. Многие из этих продуктов хорошо упростили жизнь системных администраторов, за достаточно «скромные деньги» по меркам некоторых предприятий.
В данной статье более подробно рассмотрим open source решения для резервного копирования веб-проектов разного масштаба, а также проведем тест на скорость резервирования файлов.
Статья будет полезна веб-мастерам, небольшим веб-студиям, ну и возможно даже бывалый админ найдет здесь что-то полезное.

Назрела необходимость замены медленного rdiff-backup на более шустрое решение для инкрементальных бекапов на удаленый сервер. Сперва рассматривался Rsnapshot, но причине того, что он не умеет без костылей делать бекапы именно на удаленные серверы от него отказались. Прочие аналоги нам также не подошли по тем или иным причинам. Искать что-то готовое на просторах github и допиливать под себя мы не захотели, поэтому было решено написать новый скрипт с нуля своими силами. Главная цель сделать решение для инкрементального бекапа на удаленный сервер схожее с rdiff, но с использованием жестких ссылок rsync.

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

Технологии виртуализации в настоящее время становятся одним из ключевых компонентов современной ИТ-инфраструктуры крупных предприятий (организаций). Сейчас уже сложно представить построение нового серверного узла компании без использования технологии виртуализации. Определяющими факторами такой популярности, несмотря на некоторые недостатки, можно назвать экономию денег и времени, а также высокий уровень безопасности и обеспечение непрерывности бизнес-процессов.

В данной статье приведен анализ современной технологии виртуализации, ее преимуществ и недостатков. Также рассмотрены современные системы виртуализации и подходы к созданию виртуальных сред.

Бывают случаи, когда нужно менять архитектуру системы на ходу. Возможно вы нашли узкое место в своем проекте или решили, что при текущем темпе роста в скором времени могут возникнуть сложности с масштабированием или отказоустойчивостью. Как раз для таких случаев существует Tungsten Replicator.
Tungsten Replicator — это бесплатное с открытым исходным кодом, приложение написанное на Java, расширяющее функционал репликации СУБД MySQL. Возможности Tungsten широки, это и мульти-мастер репликация, параллельная репликация, гетерогенная репликация данных между MySQL и Oracle, PostgreSQL, MongoDB. В данной статье будет рассматриваться гетерогенная репликация мастера MySQL с подчиненным сервером MongoDB, в качестве ОС будет выступать CentOS 6.5.

На тему систем централизованного управления конфигурациями на Хабре написано немало статей и, в частности, про Chef есть несколько хороших статей. Однако, количество релизов Chef растет, и я решил немного освежить его описание для читателей Хабра. Статья предназначена как для новичков, так и для тех, кто уже знакомился с системой, но по какой-то причине отложил изучение и хочет все-таки продолжить. А продолжать стоит! Поскольку, Chef полезен и для администрирования нескольких VPS, и для управления большим парком серверов. Особенно, если вам часто приходится заниматься настройкой серверов с нуля, подключением дополнительных нод в кластер и т.д.

Наша компания обслуживает множество крупных интернет порталов различной тематики. Специфика подобных проектов подразумевает возникновение различных трудностей при росте аудитории, а значит и росте нагрузки на серверы. Один из наших клиентов активно продвигает свой видео-портал, и, как результат, нагрузка неминуемо стала расти, причем большими темпами. В какой-то момент обойтись двумя серверами стало уже невозможно и было принято решение добавить еще два. Затем еще два… в итоге серверов стало 12. Однако, нагрузка продолжает расти и одним только горизонтальным масштабированием ограничиваться нельзя. Настало время задуматься о более глубокой оптимизации.

Мы в компании Centos-admin следим за появлением новых технологий, тестируем их и, конечно же, внедряем. Почти на всех серверах мы используем контейнерную виртуализацию OpenVZ. В целях расширения набора инструментов, применяемых в работе, мы решили изучить и протестировать нативную виртуализацию Linux LXC.
Под катом вы найдете небольшой обзор технологии и краткий мануал по использованию LXC в Debian Wheezy и наши выводы.