Instagram filter used: Aden
Автор: Nik Kolesnikov
Немножко разъём сломался. Но ничего страшного -замена всегда найдётся. #comandante #сервис
18+ Я ошибался / I was wrong
Теоретический минимум *nix-based-систем
Предлагаю рассмотреть три юниорских степени познания дзена управлением шайтан-машиной ака *nix-сервак на примере всеми любимой ubuntu.
1-й юниорский
Начнем с самых азов — забудьте про GUI, только консоль, только хардкор ^_^!
Несколько красивых консолей в xmonad для повышения мотивации.
Наше приключение начинаем с того, что надо добраться до консоли (в случае SSH-подключения мы там будем сразу). Кстати, если вы windows user, вам поможет волшебная программка putty.
Если же вы уже в линуксе и вы его поставили, верю, что сможете найти там консоль и как в нее попасть. Если же нет, вот мануал на примере ubuntu с самыми популярными DWM. Там же найдете описание базовых команд консоли. Рассмотрим сей список поподробнее и немного сгруппируем.
Давайте посмотрим на структуру файловой системы.
Да, не пугайтесь, привычных C: и D: тут нету, всё идет от корня (/).
/ | Корневая директория, содержащая всю файловую иерархию. |
/bin/ | Основные системные утилиты, необходимые и в однопользовательском режиме, и при обычной работе всем пользователям (cat, ls, cp). |
/boot/ | Загрузочные файлы (в том числе, файлы загрузчика, ядро и т. д.). Часто выносится в отдельный раздел. |
/dev/ | Основные файлы устройств системы (например, физические устройства: sata-винчестеры /dev/sda, видеокамеры или TV-тюнеры /dev/video или псевдоустройства, например, «черные дыры» /dev/null, /dev/zero). |
/etc/ | Общесистемные конфигурационные файлы и файлы конфигурации установленных программ (имя происходит от et cetera). |
/home/ | Содержит домашние директории пользователей, которые, в свою очередь, содержат персональные настройки и данные пользователя. Часто размещается на отдельном разделе. |
/lib/ | Основные библиотеки, необходимые для работы программ из /bin/ и /sbin/. |
/media/ | Точки монтирования для сменных носителей (CD-ROM, DVD-ROM, flash-диски). |
/opt/ | Дополнительное ПО. |
/proc/ | Виртуальная файловая система, представляющая состояние ядра операционной системы и запущенных процессов в виде каталогов файлов. |
/root/ | Домашняя директория пользователя root. |
/sbin/ | Основные системные программы для администрирования и настройки системы, например, init, iptables, ifconfig. |
/tmp/ | Временные файлы (см. также /var/tmp). |
/usr/ | Вторичная иерархия для данных пользователя; содержит большинство пользовательских приложений и утилит, используемых в многопользовательском режиме. Может быть смонтирована по сети только для чтения и быть общей для нескольких машин. |
/var/ | Изменяемые файлы: файлы регистрации (log-файлы), временные почтовые файлы, файлы спулеров. |
/var/cache/ | Данные кэша приложений. Сюда скачиваются пакеты перед установкой в систему, здесь же они какое-то время хранятся. |
/var/lib/ | Информация о состоянии. Постоянные данные, изменяемые программами в процессе работы (базы данных, метаданные пакетного менеджера и т. п.). |
/var/log/ | Различные файлы регистрации (log-файлы). |
/var/www/ | Директория веб-сервера Apache, всё, что находится внутри, транслируется им в интернет (конфигурация по умолчанию) |
Теперь мы узнали, как выглядит файловая система *nix.
Потом рекомендую узнать, как перемещаться в пространстве (cd — www.linfo.org/cd.html), создавать файлы (touch — www.linfo.org/touch.html) редактировать и удалять тоже (понять шутку про sudo rm -rf / — настойчиво рекомендую загуглить тем, кто не в курсе), познакомиться, как работает консольный текстовый редактор (например, Nano) — да-да, не надо пугать новичков Vim и Emacs. Еще есть симпатичный вариант mcedit.
Nano
MCEdit
Чип и Дейл спешат на помощь! В любой непонятной ситуации вводите man %commandName%, и восхитительная утилита man в *nix-системах вам расскажет как работает та или иная команда (программа) в bash.
Если вы потерялись в файловой системе, поможет команда pwd.
Теперь давайте обозначим еще некоторые особенности этого семейства OS.
*nix-системы отличаются регистрозависимостью т. е. file.txt и File.txt — разные файлы. И директории /uploads и /Uploads — тоже разные директории.
Еще несколько важных отличий:
- Разные слеши Win — Backslash “\”; *nix — Slash “/”
- Символы переноса строки Win — “\r\n — CRLF”; *nix — “\n — CR”; mac — “\r — LF” статья по теме: en.wikipedia.org/wiki/Newline
В PHP-разработке для ликвидации этих проблем кроссплатформености рекомендуется использовать PHP_EOL для новой строки в консоли и DIRECTORY_SEPARATOR для правильных слешей.
В контексте обсуждения файловой системы и фич linux давайте рассмотрим интересную фичу — симлинки (symlinks). Если объяснить по-простому — это ярлыки, как в всем известной windows, только тут ярлык может быть и на другой сервер, и на директорию, и на файл. Отличие от ярлыков в windows в том, что тут ярлыки используют не только на рабочем столе, а во всей файловой системе. По поводу этого есть хорошая статья на вики en.wikipedia.org/wiki/Symbolic_link и немного синтаксиса с вики debian вдогонку: wiki.debian.org/SymLink.
Почему многие developer-ы любят *nix-системы? Да потому что они стандартизированы системой стандарта POSIX, что их все роднит и помогает спокойно мигрировать из одной стандартизированной OS в другую (и разработчику, и юзеру. Тема раскрыта тут: en.wikipedia.org/wiki/POSIX.
Продолжаем знакомство.
Основное отличие *nix-систем — их многопользовательский подход. Из этого следует логический вывод: если есть много пользователей, надо разграничивать их сферы влияния. Один из основных инструментов для этого — права к файлам и директориям.
Обозначения прав идут в буквенном или цифровом формате.
Увидеть права мы можем через команды ls –l или ls –la, а поменять — через chmod.
Нашел потрясающую картинку, которая объясняет всю суть происходящего.
Добавлю, что в жизни веб-разработчика всегда нужно помнить о правах в linux, поскольку имеет место обыденная ситуация: разрабатывали под windows, задеплоили и внезапно (!) ничего не работает. В целом ничего страшного в них нету, но keep in mind.
P. S. Советую хорошо разобраться в этом моменте, поскольку ставить 777 на весь проект тоже не очень секьюрно.
Для пользователей системы существует режим стандартных правил для создаваемых ими файлов — umask. От него зависит, с какими правами будут создаваться файлы этого пользователя по умолчанию.
Почитать здесь: ru.wikipedia.org/wiki/Umask.
Я вскользь упомянул о наличии пользователей и групп в *nix-системах, но еще есть административный пользователь — root.
Root-юзер помогает вам делать многое: инсталлить софт, маунтить (https://help.ubuntu.com/community/Mount) разделы, разруливать права на файлы и папки где вашего обычного юзера не хватает, и т. п.
Для этого есть волшебная команда sudo. Более подробно предлагаю ознакомиться здесь: help.ubuntu.ru/wiki/.
Под рутом надо быть очень аккуратными. Особенно на лайв-серверах. Особенно удаляя что-то через консоль.
Раз уж мы вспомнили о лайв-серверах, у них бывает такое свойство — заканчивается память.
Сначала проверяем, что у нас с ОЗУ, для этого подойдет top/htop.
Давайте также вспомним замечательную тулзу — ps. Она выводит отчет о работающих процессах. Удобна еще и несколькими триками:
- Удобно пользоваться конвейером и утилитой less для пролистывания выводимой информации с помощью кнопок «вверх» и «вниз», например, ps aux | less.
- С помощью утилиты grep удобно искать и выводить только нужные процессы, например, ps aux | grep node.
Для проверки, сколько свободного места у нас на харде, есть команды: df -h и df –k.
Если проблема в ОЗУ, смотрим, что у нас потребляет больше, чем надо, и делаем kill, или же, если это нужные процессы, — думаем дальше :).
Если же заканчиваются ресурсы харда и нечего удалить, на помощь приходят архиваторы. Основной архиватор в мире linux — tar. Вот небольшой гайд по сабжу, которого в повседневной жизни вам должно хватить с головой: help.ubuntu.ru/wiki/tar.
Стоит добавить, что в консоли есть варианты работы с несколькими программами одновременно — утилита GNU Screen: help.ubuntu.ru/wiki/screen.
В целом на этом можно и закончить первую степень посвящения, но обрадую немного тех, кто очень боится консоли: есть консольный 2-панельный классический файловый менеджер — Midnight commander.
Продолжим рубрикой «Что делать не надо» :).
- Не знаешь, зачем оно и как работает — не удаляй!
- Увидел файл или папку, которые начинаются с точечки — тем более не удаляй ^_^!
Это dotfiles — спрятанные файлы, просто по ls их не видно, можно увидеть через ls –la. Зачастую это системные файлы или файлы программ (иногда — настройки). И тут тоже вики хорошо раскрывает тему: en.wikipedia.org/wiki/Hidden_file_and_hidden_directory.
2-й юниорский
Первый юниорский нам поможет сделать что-то, но для повседневных задач web-developer’а этого мало, так что давайте пойдем дальше осваивать уровень, которого нам хватит для резолва ежедневных задач.
Первое, о чём надо упомянуть на этом уровне — пакетный менеджер aptitude (разбираем на примере ubuntu, да и в целом debian-based systems).
С его помощью можем устанавливать и удалять программы в й системе, подробнее рекомендую почитать, как говорится, на сайте производителя: help.ubuntu.ru/wiki/apt.
Следующая повседневная задача — установка lamp (linux apache php mysql)-сервера.
Вы не поверите, но после установки сервера на Windows в Ubuntu это делать просто и приятно, буквально в несколько команд: help.ubuntu.com/community/ApacheMySQLPHP
Конечно же, нам пригодятся Virtual Hosts. Файл хостов находится по адресу /etc/hosts, а хосты надо редактировать под рутом.
Пришло время упомянуть базовые команды Apache.
Включаем модули в apache, в том числе, модуль PHP (если ставим руками) — a2enmod %moduleName%.
Рестарт сервера — sudo service apache2 restart.
Вернемся к хостам. В apache, да и в nginx система хостов не очень сложная, но, как показывает практика, лучше рассказать, чтобы не видеть потом огромные и ужасные httpd.conf/nginx.conf.
Хосты, которые настроены и существуют (но не факт, что включены!) лежат отдельными файликами в папке /etc/apache2/sites-available. А хосты, которые используются и активны в данный момент, лежат симлинками в папке /etc/apache2/sites-enabled.
In real life выглядит все так: мы создаем файл конфига для нового хоста в sites-available, потом командой a2ensite %hostName% apache создает симлинк в папке sites-enabled, тем самым активируя хост. Обратная процедура — a2dissite.
Когда вы делаете это руками или просто пишете в файл основнового конфига, где-то плачет один котик, ну, или собачка — кому кого больше жаль :).
Ещё распространенная задача — поднять https. Хороший мануал здесь:
help.ubuntu.ru/wiki/apache_%D0%B8_https.
Картинка, обьясняющая суть того, зачем нам https.
Если вас всё ещё терзает вопрос зачем эта вся секьюрность, советую почитать на тему секьюрности для разработчиков хороший мануал: www.owasp.org/index.php/PHP_Security_Cheat_Sheet — тут на примере PHP, но многое актуально для всех Web разработчиков.
Также при работе с lamp старайтесь закрывать использование exec (выполнение команд в консоли OS через php) www.php.net/manual/ru/function.exec.php.
На уровне php это потенциальный пробел в вашей защите.
Добавлю часто встречающуюся задачу — закрытие сервера для незалогиненных пользователей методами веб-сервера, как на этом скрине.
Сделать так очень просто через htpasswd, вот пример: doc.norang.ca/apache-basic-auth.html.
Пришло время упомянуть о базах данных. В нашем юниорском забеге будем рассматривать MySql. В целом по вопросам Database Administration написано очень много книг и очень многое появляется с опытом, но некоторые базовые вещи просто необходимы.
how to mysql server restart?
Первое — конфиг живет по адресу /etc/mysql/my.cnf, заходить в гости, как обычно, под рутом.
Перезапустить «моську» можно командой sudo service mysql restart.
Если вы что-то не то сделали с правами своего рута или просто потеряли пароль рута от mysql, сбросить его и задать новый можно командой sudo dpkg-reconfigure mysql-server-5.5 (или 5.6), в общем, подставите нужную версию :).
Перейдем к следующему животрепещущему вопросу в жизни веб-девелопера:
Хоббит SQL-дампы — туда и обратно на dedicated servers
Для бекапа базы в sql-файл используется прекрасная команда mysqldump со следующим синтаксисом:
mysqldump —opt -u [uname] -p[pass] [dbname] > [backupfile.sql]
[uname] Имя юзера
[pass] Пароль (Будьте внимательны между параметром p и паролем нет пробела)
[dbname] Название нашей базы
[backupfile.sql] Как мы называем файл дампа (можно так же указать путь к нему если вы не в той папке где хотите создать его)
[–opt] Дополнительные опции
Пример: mysqldump -u root -p Tutorials > tut_backup.sql
- add-drop-table — добавляет в дамп DROP TABLE перед CREATE TABLE.
- no-data — дампит только таблицы без контента.
- add-locks — добавляет LOCK TABLES и UNLOCK TABLES в дамп.
А если база большая и VPN-коннект не самый быстрый, можно сразу сжать в архив наш дамп следующей командой:
mysqldump -u [uname] -p[pass] [dbname] | gzip -9 > [backupfile.sql.gz]
Теперь давайте разберем накатку базы (условие: базы не существует, накатка с нуля).
Основной синтаксис будет такой:
mysql -u [uname] -p[pass] [db_to_restore] < [backupfile.sql]
Следуя нашему примеру, получаем что-то в духе:
mysql -u root -p Tutorials < tut_backup.sql
А если мы таки запаковались в архив, будет так:
gunzip < [backupfile.sql.gz] | mysql -u [uname] -p[pass] [dbname]
Если накатываем базу не с нуля, а она уже создана, есть другая команда:
mysqlimport -u [uname] -p[pass] [dbname] [backupfile.sql]
С архивом по аналогии.
Эту прекрасную шпаргалку по дампам взял отсюда: webcheatsheet.com/sql/mysql_backup_restore.php на good data centre
Следующий важный момент в MySQL — права Grants. «Моська» у нас многопользовательская, если есть много пользователей, значит, права свои у них будут — life is cruel :). Советую о них почитать. Самая распространенная задача — открыть юзеру вход не с локалхоста Она решается следующим образом:
Удаляем строку bind-address 127.0.0.1 из главного конфига.
Потом выполняем следующие команды:
~# mysql -u root mysql -p
mysql> GRANT ALL PRIVILEGES ON database.* TO username@»%» IDENTIFIED BY ‘password’ WITH GRANT OPTION;
mysql> exit;
~# mysqladmin -u root -p flush-privileges
Здесь database — база данных, к которой назначаем права пользователю username с паролем password, а % указывает на то, что пользователь может прийти не только с локалхоста, а откуда угодно.
Эти команды на респекте собрал отсюда: saradmin.ru/?p=792.
Node JS мы также можем установить в две команды “sudo apt-get install nodejs” “sudo apt-get install npm”.
Node-проекты заводить обычно легко, что-то в духе node server.js
Хочу поделиться интересной тулзой nodemon — она дает нам намного больше возможностей в области девелопмента на nodeJS, т. к. следит за изменениями в файлах проекта и перезапускает сервер автоматически:
nodemon.io/
Далее рекомендую ознакомиться с работой в консоли самых популярных в мире web development VCS — git и svn. Мануалов по ним очень много разных и хороших, думаю, подберете на свой вкус ;).
По теме VCS может понадобится мануал по генерации SSH-ключей для Git: help.github.com/articles/generating-ssh-keys.
Поделюсь интересным триком: если вам нужен live-вывод изменяющихся файлов в консоль (зачастую логи) — используйте команду tail –f, например, (tail -f /var/log/apache2/error.log).
3-й юниорский
Вот мы и подобрались к 3-му юниорскому! Довольно неплохой уровень, после которого уже идет хардкор, но тут еще ничего страшного тоже нет, всё достаточно интересно и весело.
Начинается опыт реального подъема серверов с фулстеком (lamp + ftp(s) + ssh) по ситуации, с прикруткой CI-систем, также интересен опыт подъёма хостинг-систем типа Virtualmin / WebMin.
В реальной эксплуатации не рекомендуется оставлять чистый ftp-сервер, лучше использовать SFTP (ftp over ssh) для секьюрности.
Интересен опыт с nginx вместо apache — отличный мануал можно найти тут: help.ubuntu.ru/wiki/nginx-phpfpm.
Также дополню хорошей онлайн-тулзой которая трансформирует rewrite-правила из apache в формат nginx: winginx.com/ru/htaccess.
Еще на этом уровне не нужно бояться BASH-скриптинга и знать, что такое sed и grep. Основы рекомендую почитать тут:
help.ubuntu.com/community/Beginners/BashScripting
Хороший левел — знание vim или emacs. Очень холиварная тема, но не упомянуть нельзя.
Если временами вы очень скучаете по некоторым программам из windows, или у вас есть специфичный софт, который все-таки нужен и аналог никак не можете найти (что же такое страшное вам нужно?!), есть wine — wine is not an emulator.
IE В Ubuntu («работает» еще веселее, чем в нативной среде обитания).
Это действительно не эмулятор windows, а набор библиотек, чтобы заводить виндовые програмы под никсами. Есть база данных, какие программы и даже игры поддерживает wine — appdb.winehq.org/.
Давайте затронем сетевую тему, первым в гостем нашей студии станет netstat (network statistics), встречайте! Тулза поможет нам посмотреть статистику сетевой активности, открытые порты, наши сетевые интерфейсы и т. д.
Базовая информация:
en.wikipedia.org/wiki/Netstat
Примеры использования: putty.org.ru/articles/netstat-linux-examples.html.
Спасибо, netstat.
Следующий наш гость — Iptables, встречайте!
IPtables — стандартный интерфейс управления работой брандмауэра.
Базовая информация: en.wikipedia.org/wiki/Iptables
Спасибо, Iptables!
И в заключение сетевой темы давайте позовем нашего хедлайнера — nmap. Поприветсвуем гостя nmap!
Очень известная утилита в области сетевой безопасности, видеть ее мы могли в десятках фильмов ;).
Базовая информация: en.wikipedia.org/wiki/Nmap#Bibliography.
Примеры использования: habrahabr.ru/post/88064/.
Спасибо nmap за столь увлекательную историю и счастливое детство.
Предлагаю перейти на немного advanced level MySQL-тюнинга — PIMP MY DB.
В живых проектах очень важно держать MySQL в боевом состоянии, настроенным на максимальную стабильность и производительность, в противном случае получаем очень неприятный bottleneck.
DB Tuning можно условно разделить на две части:
Оптимизация структуры базы данных (нормализация/денормализация, foreign keys, indexes и т. д.).
Оптимизация настроек сервера DB.
Про оптимизацию структуры базы данных написано немало гайдов и мануалов, и серебряной пули тут не существует. Всегда смотрим на конкретный проект и индивидуальные проблемы. Explain в помощь :).
Советую почитать:
ruhighload.com/post/ ruhighload.com/index.php/2009/07/28/ habrahabr.ru/post/108418/
В вопросе тюнинга и оптимизации настроек DB очень преуспела компания Percona — MySQL-форк. Рекомендую познакомиться с ними поближе.
Из базового набора для тюнинга у них есть тулкит и визард настройки вашего сервера.
www.percona.com/software/percona-toolkit
tools.percona.com/wizard
Также известная тулза — mysqltuner (http://mysqltuner.com/).
Для тестирования нагрузки на MySQL есть интересная тулза sysbench. Почитать про нее можно тут: ruhighload.com/index.php/2010/03/05/sysbench-testiruem-proizvoditelnost-mysql/.
Добавим в наше приключение немного стильных, модных и молодежных технологий — CI.
Wiki: Непрерывная интеграция (англ. Continuous Integration) — практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.
На практике это очень удобный софт, позволяющий собирать билды, прогонять все виды тестов, делать минификацию js/css, следить за качеством кода, деплоить, итп.
Самые популярные — Jenkins, Travis, TeamCity.
en.wikipedia.org/wiki/Jenkins_(software)
en.wikipedia.org/wiki/Travis_CI
ru.wikipedia.org/wiki/TeamCity
P. S. Клевая тулза Guake —выезжающая консолько в стиле quake.
Цельнотянуто с Хабра
Удобное удаленное управление консолью linux из-под Windows
Итак, друзья, некоторое подмножество нас (людей) так или иначе испытавает необходимость удаленного управления компьютером (как правило, сервера) на linux (способ может сработать и в BSD, и в Mac OS X, но я не пробовал) при помощи ssh. Другое подмножество использует Windows в качестве ОС на основной рабочей машине. К пересечению этих подмножеств обращена моя статья.
UPD:У меня часто спрашивают, зачем же всё, описанное в статье, надо.
Всё просто:
1. Сохранение подключения при обрыве связи. Этот пункт для меня самый важный и сыграл решающую роль в том, чтобы взяться за настройку такой системы. Дело в том, что я живу в общежитии с очень-очень нестабильным интернетом, и обрывы связи у меня (в плохие дни) могут происходить поминутно. А putty требует последовательности действий, чтобы переподключиться каждый раз
2. Сохранение сессии. Зачастую, единственной задачей при подключении к серверу стоит: зайти в одну и ту же директорию и написать git pull. Чтобы каждый раз не вспоминать путь к этой директории, нужно сохранение сессии
3. Терминал поддерживает вкладки. Самое главное, что данный терминал можно использовать также и для cmd, и для PS, и для git bash консоли. Поэтому, не придется держать несколько разных терминалов открытыми.
4. Плюсы tmux: многооконность в одной сессии и split
Не спорю, часть из этого можно решить другими средствами
Как же получить комфортный remote access к bash из-под Windows?
Рецепт успеха будет включать несколько пунктов:
- Терминал — ConEmu code.google.com/p/conemu-maximus5;
- Менеджер сессий — tmux tmux.sourceforge.net;
- Коннектор между клиентом и сервером — mosh mosh.mit.edu;
- Запуск *nix приложений под windows — cygwin www.cygwin.com;
Так же для проведения всех манипуляций нам также понадобится подобный набор софта:
- Putty или другой ssh клиент;
- Удаленный сервер (я использую ubuntu на aws, хотя это не имеет существенного значения).
Что мы получим в итоге?
В итоге мы получим терминал с возможностью доступа к удаленной консоли. При обрыве соединения (обрыве интернета, смене ip-адреса, изменении маршрутизации, неустойчивом соединении, засыпании ноутбука etc) не придется переподключаться, а при переподключении не будет теряться контекст работы.
Теперь поехали подробно.
Конфигурация
Настраивать нашу систему мы будем поэтапно, начнем с удаленного сервера. Подключаемся к нему по ssh и ставим…
tmux
Tmux — менеджер сессий, как говорится, screen на стероидах. К моему дистрибутиву tmux уже шел в комплекте, а если нет, то ставим его:
sudo apt-get install tmux
Или же собираем из исходников:
git clone git://git.code.sf.net/p/tmux/tmux-code tmux
cd tmux
sh autogen.sh
./configure && make
В конфиг, который находится в ~/.tmux.conf, добавляем следующее:
new-session
set-window-option -g mode-mouse on
set -g history-limit 25000
В первой строчке значится, что при попытке подключения, если нет активной сессии, создаётся новая. Вторая строчка включает поддержку мыши, а третья задаёт размер истории.
mosh
Mosh в нашей связке — это система, которая обеспечивает бесперебойность соединения. При обрыве соединения программа ждет, пока connectivity восстановится и продолжает работу с места остановки. Так же помогает и при медленном/нестабильном соединении.
Устанавливаем из исходников, чтобы получить версию, которая поддерживает все нужные фичи:
git clone https://github.com/keithw/mosh.git
cd mosh/
sudo apt-get build-dep mosh
./autogen.sh && ./configure && make
sudo make install
Специальная конфигурация не требуется.
Cygwin
Теперь переходим к клиентской части.
Cygwin — альтернативная реализация linux api, которая позволяет использовать linux утилиты из-под windows. Ставится с официального сайта (https://cygwin.com/install.html). У меня стоит версия x86_64. Скачиваем, ставим.
При выборе пакетов (помимо основных) нужно отметить mosh и ssh:
Конфигурация не требуется.
ConEmu
Последний пункт — ConEmu. Замечательный терминал под windows. Поддерживает кучу возможностей, таких как:
- вкладки и split-scren’ы;
- работа с консольными приложениями, использующими консольное API;
- гибкая настройка и управление;
- работа с цветами;
- … и многое другое, подробно про этот терминал можно почитать в статье разработчика.
ConEmu ставится с официального сайта. Скачиваем, ставим (или распаковываем), запускаем. При первом запуске оставляем галочки стоять на местах. Открываем настройки по Win+Alt+P. Нас интересует пункт Tasks.
Вот как выглядит задача запуска cygwin:
Создайте такой пункт у себя, при этом, вам, возможно, придется заменить путь на ваш путь установки:
C:\cool\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -
Сохраняем, закрываем настройки, выбираем наш cygwin в выпадающем меню рядом с плюсиком в правом верхнем углу.
Теперь нам нужно добиться подключения по ssh к нашему серверу.
У меня команда выглядит так:
ssh -i key2014.pem -p 22
key2014.pem — мой ssh приватный ключ доступа к инстансу в aws. Возможно, его стоит скопировать с диска windows (который монтируется в /cygdrive) в корневую папку.
Следующий этап — подключение через Mosh:
mosh <username>@<hostname> --ssh=\"ssh -i key2014.pem -p 22\" -p 55505 -- tmux a
55505 — UDP порт, который я предварительно открыл для входящих соединений в правилах безопасности в админке aws. Теперь все соединения будут вестись только через него (помимо начального установления связи — оно идёт через 22 порт).
tmux a — команда, которая выполняется при подключении к серверу (attach к работающей сессии tmux).
Проверяем. Работает? Великолепно! Последняя задача — создать новый Task в ConEmu.
Конкретно:
C:\cool\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico /bin/bash -l -c "mosh <username>@<hostname> --ssh=\"ssh -i key2014.pem -p 22\" -p 55505 -- tmux a"
Думаю, всё понятно. Обратите внимание на слеши перед кавычками. Они отличают степень вложенности кавычек.
Ну вот, пожалуй и всё. Теперь, когда мы хотим подключиться к серверу, запускаем ConEmu, тыкаем по стрелочке рядом с плюсиком и выбираем наш Task.
Дополнение
Еще одно упрощение, которое я использую — я добавил все необходимые мне Task’и для вызова напрямую из Totcmd:
Обычная cmd:
Подключение к aws:
P. S.
Предлагаю всем, дочитавшим эту статью, высказывать предложения, что еще такого можно включить в эту схему. Спасибо за внимание.
P. P. S.
Данная статья является компиляцией других статей, взятых из разных мест и собственных наработок.
Linux Mint 17 и DLNA
Linux Mint — отличная домашняя ОС. Богатый выбор графических сред на любой вкус, простая и понятная даже новичку установка, сразу после установки имеем основной набор необходимого софта, удобный менеджер приложений, основные мультимедийные кодеки. В общем, отличная система для перехода и ознакомления с Linux.
Но возникает проблема для тех, у кого нет дома NAS или чего-то подобного, а смотреть контент с ПК на других устройствах, поддерживающих DLNA хочется. Под Linux существует множество различных DLNA-серверов, но оптимальным, все же, является MiniDLNA. И тому есть несколько причин. Во-первых, это типичный Unix-way: этот сервер является именно DLNA-сервером, а не комбайном с кучей свистелок, при этом контент без проблем воспринимается на любом устройстве. Даже телевизоры Samsung со своим AllShare прекрасно подключаются к нему. Также можно отметить и замечательную скорость работы и нетребовательность к ресурсам этого сервера.
И все бы было хорошо, но вот в с помощью команды
sudo apt-get install minidlna
установить его не получится — нет его в репозитарии.
Существуют разные варианты устранения этого недоразумения, но самый правильный путь — установка из исходников.
Чтобы не отвратить возможных новоиспеченных линуксоидов с этого пути и, возможно, помочь кому-то, напишу как обойти подводные камни, ибо информации много, но в начале пути людям нужно попроще.
Подготовка
Если будете выполнять команды в консоли, запущенной с правами root, команду sudo писать не нужно.
Для начала нужно установить необходимые библиотеки:
Обновляемся:
sudo apt-get update
И устанавливаем сами библиотеки:
sudo apt-get install libavcodec-dev libavformat-dev libavutil-dev libflac-dev libvorbis-dev libogg-dev libid3tag0-dev libexif-dev libjpeg-dev libsqlite3-dev
Самая свежая версия MiniDLNA на данный момент — 1.1.3, ее можно скачать здесь, либо загрузить из консоли:
wget --trust-server-names http://sourceforge.net/projects/minidlna/files/latest/download
ключ перед адресом нужен, чтобы сохранилось оригинальное имя, с выхдом новой версии имя файла будет отличатся. После этого архив нужно распаковать:
tar -xf minidlna-1.1.3.tar.gz
Теперь перейдем в распакованную папку с исходниками
cd minidlna-1.1.3
Если вы хотите, чтобы на устройстве отображались сразу папки с файлами, нужно немного подправить код:
sudo cp upnpsoap.c upnpsoap.c.old
и откроем в редакторе
sudo nano upnpsoap.c
поиском (F6), ищем процедуру:
"BrowseContentDirectory"static void
BrowseContentDirectory(struct upnphttp * h, const char * action)
{
В начале процедуры выполняется разбор SOAP/XML-запроса, затем его обработка и возврат результата. Разбор запроса завершается формированием отладочного сообщения:
DPRINTF(E_DEBUG, L_HTTP, "Browsing ContentDirectory:\n"
" * ObjectID: %s\n"
" * Count: %d\n"
" * StartingIndex: %d\n"
" * BrowseFlag: %s\n"
" * Filter: %s\n"
" * SortCriteria: %s\n",
ObjectID, RequestedCount, StartingIndex,
BrowseFlag, Filter, SortCriteria);
Далее реализован выбор корневого контейнера в зависимости от конфигурационного параметра root_container:
// Если запрошен корневой контейнер
if( strcmp(ObjectID, "0") == 0 )
{
// Выставляем флаг корневого контейнера
args.flags |= FLAG_ROOT_CONTAINER;
// Если в конфиге задан корневой контейнер
if( runtime_vars.root_container )
{
// Если клиентом является аудио плейер и в конфиге задан обзор папок
// Отправляем его в папку с музыкой
if( (args.flags & FLAG_AUDIO_ONLY) && (strcmp(runtime_vars.root_container, BROWSEDIR_ID) == 0) )
ObjectID = MUSIC_DIR_ID;
else // Иначе выставляем контейнер, заданный в конфиге
ObjectID = runtime_vars.root_container;
}
else // Если контейнер в конфиге не задан
{
// Если клиентом является аудио плейер
// Отправляем его в папку с музыкой
if( args.flags & FLAG_AUDIO_ONLY )
ObjectID = MUSIC_ID;
}
}
Сразу после этого блока и перед блоком с запросами к БД добавляем код перенаправления папок для видео, музыки и изображений:
//Redirect video to folder
if( strcmp(ObjectID, VIDEO_ID) == 0 )
{
ObjectID = VIDEO_DIR_ID;
}
//Redirect music to folder
if( strcmp(ObjectID, MUSIC_ID) == 0 )
{
ObjectID = MUSIC_DIR_ID;
}
//Redirect images to folder
if( strcmp(ObjectID, IMAGE_ID) == 0 )
{
ObjectID = IMAGE_DIR_ID;
}
В итоге правленный фрагмент должен выглядеть следующим образом:
if( strcmp(ObjectID, "0") == 0 )
{
args.flags |= FLAG_ROOT_CONTAINER;
if( runtime_vars.root_container )
{
if( (args.flags & FLAG_AUDIO_ONLY) && (strcmp(runtime_vars.root_containe$
ObjectID = MUSIC_DIR_ID;
else
ObjectID = runtime_vars.root_container;
}
else
{
if( args.flags & FLAG_AUDIO_ONLY )
ObjectID = MUSIC_ID;
}
}
//Redirect video to folder
if( strcmp(ObjectID, VIDEO_ID) == 0 )
{
ObjectID = VIDEO_DIR_ID;
}
//Redirect music to folder
if( strcmp(ObjectID, MUSIC_ID) == 0 )
{
ObjectID = MUSIC_DIR_ID;
}
//Redirect images to folder
if( strcmp(ObjectID, IMAGE_ID) == 0 )
{
ObjectID = IMAGE_DIR_ID;
}
if( strcmp(BrowseFlag+6, "Metadata") == 0 )
{
args.requested = 1;
sql = sqlite3_mprintf("SELECT %s, " COLUMNS
"from OBJECTS o left join DETAILS d on (d.ID = o.DETAIL_ID$
" where OBJECT_ID = '%q';",
(args.flags & FLAG_ROOT_CONTAINER) ? "0, -1" : "o.OBJECT_I$
ObjectID);
ret = sqlite3_exec(db, sql, callback, (void *) &args, &zErrMsg);
totalMatches = args.returned;
}
Чтобы упростить процедуру последующего обновления, сохраним патч с внесенными изменениями:
diff -u upnpsoap.c.old upnpsoap.c > ../minidlna-folders.patch
Теперь вместо редактирования файла, достаточно применить патч:
cd ~/src/minidlna/minidlna-НоваяВерсия
patch < ../minidlna-folders.patch
Теперь можно переходить к конфигурированию.
Если вам это не нужно, переходите сразу к конфигурированию:
./configure
И компилируем:
make
Установка
1) Для тех, кто в дальнейшем захочет обновить версию, предыдущую можно удалить (конфигурационные файлы при этом сохраняются), если этого не сделать, то в случае, если в новой версии состав установочных файлов изменится, в /usr/local могут остаться старые файлы, при первой установке — переходим сразу к пункту 2.
Для удаления заходим в папку с предыдущей установкой и выполняем команду:
sudo apt-get remove minidlna
2) Запускаем установку (в комментариях предложили более правильный путь, чем make install):
sudo checkinstall -D
Ключ -D указывает, что должен быть создан Debian-пакет
3)Если мы производим первоначальную установку, нужно создать init-скрипт:
sudo nano /etc/init.d/minidlna
, если мы обновляем версию, больше ничего делать не нужно, при первоначальной установке у нас откроется пустой файл, в который нужно внести следующий код:
#!/bin/sh
#
# MiniDLNA initscript
#
# Based on the mediatomb debian package.
# Original authors: Tor Krill <tor@excito.com>
# Leonhard Wimmer <leo@mediatomb.cc>
# Andres Mejia <mcitadel@gmail.com>
#
# Modified by: Benoit Knecht <benoit.knecht@fsfe.org>
#
### BEGIN INIT INFO
# Provides: minidlna
# Required-Start: $network $local_fs $remote_fs
# Required-Stop:: $network $local_fs $remote_fs
# Should-Start: $all
# Should-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start minidlna at boot time
# Description: Manage the minidlna daemon, a DLNA/UPnP-AV media server.
### END INIT INFO
unset USER
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="DLNA/UPnP-AV media server"
NAME=minidlnad
DAEMON=/usr/local/sbin/minidlnad
PIDDIR=/run/$NAME
PIDFILE=$PIDDIR/$NAME.pid
SCRIPTNAME=/etc/init.d/minidlna
DEFAULT=/etc/default/minidlna
# Exit if the package is not installed
[ -x $DAEMON ] || exit 0
# Read configuration variable file if it is present
[ -r $DEFAULT ] && . $DEFAULT
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
# Do not start the daemon if NO_START is enabled in DEFAULT
if [ "$START_DAEMON" != "yes" ] && [ "$1" != "stop" ]; then
log_warning_msg "$NAME: Not starting $DESC."
log_warning_msg "$NAME: Disabled in $DEFAULT."
exit 0
fi
# Set the default configuration file
if [ -z $CONFIGFILE ]; then
CONFIGFILE=/etc/minidlna.conf
fi
# Set the default log file
if [ -z $LOGFILE ]; then
LOGFILE=/var/log/minidlna.log
fi
# Run as `minidlna' if USER is not specified or is `root'
if [ -z $USER ]; then
USER=minidlna
fi
# If no group is specified, use USER
if [ -z $GROUP ]; then
GROUP=$USER
fi
DAEMON_ARGS="-f $CONFIGFILE -P $PIDFILE $DAEMON_OPTS"
#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
touch $LOGFILE && chown $USER:$GROUP $LOGFILE || return 2
if [ ! -d $PIDDIR ]; then
mkdir $PIDDIR || return 2
fi
chown $USER:$GROUP $PIDDIR || return 2
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--chuid $USER:$GROUP --exec $DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--chuid $USER:$GROUP --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -rf $PIDDIR
return "$RETVAL"
}
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC " "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" && exit 0 || exit $?
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
if [ "$1" = "force-reload" ]; then
# Rescan the collection
DAEMON_ARGS="$DAEMON_ARGS -R"
fi
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
exit 3
;;
esac
:
, сохранить комбинацией клавиш Ctrl+O и выйти из редактора — Ctrl+X.
4) После этого даем права на запуск скрипта:
sudo chmod 755 /etc/init.d/minidlna
5) И активируем запуск init-скрипта:
sudo update-rc.d minidlna defaults
6) Так как по умолчанию служба запускается под пользователем minidlna, нам нужно создать соответствующую учетную запись:
sudo adduser --system --home /var/lib/minidlna --group --gecos "MiniDLNA server" minidlna
7) Правим файл конфигурации сервера:
sudo nano /etc/minidlna.conf
В нем нам нужно следующее содержимое (здесь подправлен интервал, с которым сервер себя анонсирует, так как не все телевизоры опрашивают сервер, также вам надо прописать путь к папке с медиа, к примеру так: «media_dir=V,/mnt/sdb6/Video/Alex/» в соответствующем разделе файла):
# Порт сервера
port=8200
# Привязка к сетевому интерфейсу
# Можно задать несколько интерфейсов
# в формате network_interface=eth0,eth1
#network_interface=eth0
# Имя пользователя или UID, под которым будет работать служба
# Добавлен в версии 1.1.0
# В Debian задается в параметрах init-скрипта
#user=jmaggard
# Путь к папке с медиа-файлами
# Для сканирования нескольких папок, укажите несколько параметров media_dir
# Чтобы сканировать файлы определенного типа, укажите соответствующий префикс:
# A - аудио: media_dir=A,/home/jmaggard/Music
# V - видео: media_dir=V,/home/jmaggard/Videos
# P - изображения: media_dir=P,/home/jmaggard/Pictures
# Начиная с версии 1.1.0, можно задать несколько типов:
# PV - изображения и видео: media_dir=AV,/var/lib/minidlna/digital_camera
#
# При изменении параметра, потребуется повторное сканирование файлов.
# Необходимо выполнить команду "service minidlna force-reload" от имени root.
# Начиная с версии 1.1.0, при изменении параметра, сканирование выполняется автоматически.
media_dir=/var/lib/minidlna
# Имя DLNA-сервера, отображаемое клиентом
# По умолчанию: "$HOSTNAME:$USER"
#friendly_name=
# Путь к папке для хранения базы данных и кэша обложек альбомов
db_dir=/var/lib/minidlna
# Путь к папке с лог-файлами
log_dir=/var/log
# Уровень детальности лога
# В формате log_level=источник1,источник2=значение1,источник3,источник4=значение2 ...
# Доступные источники: "general", "artwork", "database", "inotify", "scanner", "metadata", "http", "ssdp", "tivo"
# Возможные значения: "off", "fatal", "error", "warn", "info" or "debug"
#log_level=general,artwork,database,inotify,scanner,metadata,info,ssdp,tivo=warn
# Перечень имен файлов-обложек альбомов, разделитель: "/"
album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg
# Автообнаружение новых файлов
# Включено по умолчанию
inotify=yes
# Поддержка устройств TiVo
#enable_tivo=no
# Строго следовать DLNA-стандарту
# Использовать серверное масштабирование для очень больших JPEG-изображений
# Что может снизить скорость их обработки.
#strict_dlna=no
# Адрес веб-страницы устройства
# По умолчанию IP-адрес и заданный порт сервера
#presentation_url=http://www.mylan/index.php
# Интервал отправки SSDP-уведомлений, в секундах
notify_interval=30
# Серийный номер и номер модели DLNA-сервера, сообщаемый клиенту
serial=12345678
model_number=1
# Путь к сокету MiniSSDPd, если установлен
# Требуется для обеспечения работы нескольких DLNA/UPnP служб на одном сервере
#minissdpdsocket=/run/minissdpd.sock
# Контейнер, используемый в качестве корневой папки для клиентов
# * "." - стандартный контейнер
# * "B" - "Обзор папки"
# * "M" - "Музыка"
# * "V" - "Видео"
# * "P" - "Изображения"
# Если задано "B" и клиент представится как аудиоплеер, в качестве корня будет использована папка "Music/Folders"
#root_container=.
# Всегда использовать заданный критерий сортировки, вместо значения, запрошенного клиентом
#force_sort_criteria=+upnp:class,+upnp:originalTrackNumber,+dc:title
# Максимальное число одновременных подключений
# Учтите: многие клиенты открывают несколько подключений одновременно
#max_connections=50
8)Затем проверяем параметры init-скрипта /etc/default/minidlna:
sudo nano /etc/default/minidlna
Обычно корректировка не требуется. Если файл отсутствует, при первичной установке из исходников, копируем листинг:
# Запускать демон, если задано "yes"
START_DAEMON="yes"
# Путь к файлу конфигурации
#CONFIGFILE="/etc/minidlna.conf"
# Путь к лог-файлу
#LOGFILE="/var/log/minidlna.log"
# Запуск от имени заданного пользователя и группы
# По умолчанию: minidlna
#USER="minidlna"
#GROUP="minidlna"
# Дополнительные ключи запуска
DAEMON_OPTS=""
Обычно после этого не требуется дополнительных настроек, но если есть проблемы с доступом к медиа (или хотите перестраховаться), можно настроить права доступа:
sudo -u minidlna ls -l папка
Если папка недоступна, задаем права доступа:
sudo chmod -R 755 папка
Вышестоящие папки также должны быть доступны на чтение всем пользователям. Проверяем доступность на чтение каждой папки, указанной в пути. Для вышестоящих папок используем chmod без ключа -R, если не требуется сброс разрешений для всех дочерних файлов и папок.
В качестве альтернативы смене разрешений, можно запустить MiniDLNA от имени пользователя или группы-владельца файлов. Для этого необходимо задать параметры USER и GROUP в /etc/default/minidlna, и сменить владельца папки /var/lib/minidlna командой:
sudo chown -R пользователь:группа /var/lib/minidlna
Запуск сервера
Запускаем:
sudo service minidlna force-reload
Проверяем, работает ли служба, также смотрим параметры запуска:
ps ax | grep minidlna
Проверяем, слушается ли порт:
sudo ss -4lnp | grep minidlna
Проверяем лог:
cat /var/log/minidlna.log
В случае успешного старта, лог должен быть примерно следующим:
Gothician gothician # cat /var/log/minidlna.log
[2014/07/27 10:05:31] minidlna.c:1014: warn: Starting MiniDLNA version 1.1.3.
[2014/07/27 10:05:31] minidlna.c:355: warn: Creating new database at /var/lib/minidlna/files.db
[2014/07/27 10:05:31] minidlna.c:1053: warn: HTTP listening on port 8200
[2014/07/27 10:05:31] scanner.c:706: warn: Scanning /var/lib/minidlna
[2014/07/27 10:05:31] scanner.c:793: warn: Scanning /var/lib/minidlna finished (0 files)!
[2014/07/27 10:05:31] playlist.c:125: warn: Parsing playlists...
[2014/07/27 10:05:31] playlist.c:259: warn: Finished parsing playlists.
[2014/08/03 09:25:35] minidlna.c:1053: warn: HTTP listening on port 8200
Если видим: «WARNING: Inotify max_user_watches [8192] is low.», необходимо увеличить число дескрипторов слежения inotify до 100 000. Для этого в файл /etc/sysctl.conf добавим строки:
#MiniDLNA warning fix
fs.inotify.max_user_watches = 100000
Вручную редактором:
sudo nano /etc/sysctl.conf
Или копипастом команды:
sudo sh -c 'printf "\n\n#MiniDLNA warning fix\nfs.inotify.max_user_watches = 100000\n" >> /etc/sysctl.conf && cat /etc/sysctl.conf'
Изменение параметра вступит в силу после перезагрузки системы.
Открываем в браузере адрес.сервера:8200, видим количество файлов в библиотеке, начиная с версии 1.1.2, также отображается список подключенных клиентов.
Настройка DLNA/UPnP-AV сервера завершена.
При появлении ошибок в каталоге, необходимо выполнить повторное сканирование файлов.
При использовании приведенного выше init-скрипта, для запуска сканирования медиа-библиотеки используем команду:
sudo service minidlna force-reload
Служба при этом будет перезапущена, подключенные клиенты будут отключены.
Для сканирования медиа-библиотеки при каждом старте системы можно задать ключ запуска: “-R” в параметре DAEMON_OPTS в файле /etc/default/minidlna. Сканирование большой медиа-библиотеки существенно нагружает диск, что может замедлить загрузку системы.
Полное формирование каталога может занять несколько минут. Сканирование папок выполняется в порядке их объявления в конфиге. Файлы из небольших папок, объявленных в конфиге выше, появятся в каталоге в самом начале процесса сканирования. Крупные папки с редко воспроизводимым контентом имеет смысл размещать в конфиге последними.
По материалам http://itadept.ru/, wiki.archlinux.org.
Проекты на WordPress: советы по оптимизации
Сегодня WordPress является одной из самых популярных CMS. Задуманная изначально как движок для блогов, сегодня она используется для самых разных типов сайтов, в частности, для новостных порталов и интернет-СМИ. На Wordpress работают корпоративные веб-сайты, образовательные и развлекательные порталы.
Во всех примерах используется Ubuntu 12.04.
Настраиваем СУБД
Выбор СУБД
Как известно, для работы WordPress необходима СУБД MySQL. В последнее время широкое распространение получили альтернативные реализации (форки) этой СУБД, наиболее популярными из которых являются Percona Server и MariaDB. Во многих инструкциях по установке, опубликованных в Интернете, рекомендуется использовать MariaDB.
Мы же рекомендуем использовать Percona Server, так как этот форк по сравнению со стандартным MySQL является более производительным и стабильным. Кроме того, Percona обладает более широкими возможностями для сбора системной статистики.
Чтобы установить Percona на сервер, нужно сначала импортировать ключи:
$ apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
Затем нужно добавить в файл /etc/apt/sources.list следующие репозитории:
deb http://repo.percona.com/apt precise main deb-src http://repo.percona.com/apt precise main
И выполнить команду:
$ sudo apt-get update
После этого можно устанавливать percona-server при помощи стандартного менеджера пакетов:
$ sudo apt-get install percona-server-server percona-server-client
Выбираем движок: MyISAM или InnoDB?
Самыми популярными движками в MySQL-базах являются MyISAM и InnoDB. Если движок выбран неправильно, то возникают проблемы с производительностью и консистентностью.
Рассмотрим особенности этих движков более подробно.
MyISAM показывает хорошие результаты на выборках SELECT, что во многом обусловлено отсутствием поддержки транзакций и внешних ключей. Однако при модификации и добавлении записей вся таблица на время блокируется, что при большой загрузке может стать причиной серьезных задержек.
Несомненными преимуществами этого движка являются также полнотекстовый поиск и компрессия. Формат данных в MyISAM — кроссплатформенный, что позволяет без проблем переносить данные с одного сервера на другой путем простого копирования бинарных файлов (таблиц) баз данных.
InnoDB используется в современных версиях MySQL как движок по умолчанию.
В отличии от MyISAM InnoDB поддерживает транзакции и внешние ключи. В Percona Server используется собственный движок — XtraDB, полностью совместимый с InnoDB. Данные в InnoDB/XtraDB кэшируются. Когда большая часть данных считывается из кэша, производительность InnoDB/XtraDB в разы выше, чем у MyISAM.
Статей, посвященных сравнению MyISAM с InnoDB/XtraDB, а также MySQL c его форками, опубликовано немало (см., в частности, тест производительности здесь). Мы не будем вдаваться в теоретические подробности и ограничимся практическим советом: MyISAM нужно выбирать только в случаях, когда нужен полнотекстовый поиск. Со всеми остальными задачами прекрасно справятся InnoDB/XtraDB. Кстати, в MySQL/Percona Server 5.6+ полнотекстовый поиск для InnoDB уже поддерживается.
Оптимизация конфигурации СУБД
По мере развития сайта количество данных в БД будет расти, и возникнет необходимость изменений настроек базы данных. Чтобы обеспечить оптимальную работу сайта, желательно регулярно проверять, насколько оптимально настроена действующая конфигурация MySQL. Такую проверку проще всего осуществлять с помощью специальных скриптов, самым известным и популярным из которых является mysqltuner.pl. Его можно скачать при помощи следующих команд:
$ wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl $ chmod +x ./mysqltuner.pl $ ./mysqltuner.pl
Этот скрипт собирает статистику MySQL и выдает рекомендации по улучшению существующих настроек.
Настраиваем веб-сервер
Параметры Apache
Настройки apache хранятся в файле /etc/apache2/apache2.conf
В конфигурационном файле Apache имеется такой параметр, как max_clients — максимальное количество процессов, запускаемых для параллельной обработки клиентских запросов. На первый взгляд может показаться, что для этого параметра нужно устанавливать максимальное значение. В реальной практике, однако, все бывает по-другому.
Допустим, один процесс Apache может потребить 20 Мб оперативной памяти. Если для параметра max_clients выставлено значение 200, то при пиковой нагрузке под все процессы потребуется 200×20 Мб = 4Гб памяти — и это только под Apache! В результате нехватки памяти даже самые простые запросы будут выполняться крайне медленно. И программное обеспечение на сервере может перестать работать.
Поэтому слишком большое значение параметра max_clients выставлять не желательно. Если количество запросов превысит установленное значение, то все эти запросы будут поставлены в очередь и обработаны, как только освободятся занятые процессы.
В целях повышения производительности рекомендуется также отключить keepalive-соединения, исправив соответствующую строку в конфигурационном файле:
KeepAlive off
Backend+Frontend = Apache +Nginx
Любой более или менее высоконагруженный веб-проект должен иметь многоуровневую архитектуру (об этом мы уже писали). Для большинства проектов на базе WordPress вполне подойдет двухуровневая архитектура Backend — Frontend. Мы рекомендуем использовать следующую связку: в качестве бэкенда Apache, в качестве фронтенда — Nginx.
Впрочем, возможен и другой вариант — php-fpm в качестве бэкенда, а в качестве фронтенда — все тот же Nginx (см. инструкции по настройке, например, здесь и здесь). Во многих публикациях утверждается, что связка php-fpm+Nginx работает быстрее или потребляет намного меньше памяти. С этими утверждением, однако, вряд ли можно однозначно согласиться.
К тестам, опубликованным в Интернете, нужно относиться со здоровой долей скептицизма: нередко php-fpm+Nginx показывает лучшие результаты лишь потому, что Apache не был настроен должным образом (см., например, отчет о тестировании и его критический разбор; см. также любопытную дискуссию здесь). На основании собственного опыта можем сказать, что для большинства проектов на Wordpress комбинация Apache+Nginx вполне подойдет. Выбор решения должен основываться не только и столько на приросте производительности, сколько на специфке решаемых задач и соображениях технологического удобства. А Apache, на наш взгляд, отличается большей гибкостью конфигурирования. Он может использоваться и как отдельный веб-сервер, и как бэкенд для Nginx, и как фронтенд для php-fpm.
Общая схема работы выглядит так: Nginx принимает запросы от пользователей, которые затем либо передает Apache, либо обрабатывает самостоятельно. Apache будут передаваться запросы, связанные с обработкой динамического контента — например, php-скриптов. Nginx самостоятельно обрабатывает запросы на отдачу статики — например, графики, JS, CSS, текстовых файлов, XML-файлов.
Apache обработав запрос и передав содержимое Nginx, отключается и переходе к обработке других запросов. Благодаря этому работа существенно ускоряется (что немаловажно, например, при медленном интернет-подключении).
Кроме того, раздачу динамических запросов можно ускорить с помощью сервера Memcached (см., например, инструкцию по установке и настройке здесь).
Обеспечиваем безопасность
Для расширения функциональности WordPress используются многочисленные плагины. В этих плагинах постоянно обнаруживаются различные уязвимости, и из-за этого некоторые системные администраторы относятся к ней несколько предвзято. Сайты на базе WordPress действительно часто становятся мишенью для атак, но со временем разработчики совершенствуют плагины, устраняя существующие бреши безопасности. Ниже мы дадим еще несколько советов по настройке WordPress, с помощью которых можно сделать сайт менее уязвимым.
Защититесь от вредоносных программ и уязвимостей в скриптах на сервере, на котором установлен WordPress. Мы рекомендуем использовать сканер ClamAV+Maldet. С инструкцией по установке и настройке AV можно ознакомиться здесь. Для поиска уязвимостей можно также воспользоваться программой WPScan.
Измените префикс таблиц в базе данных. По умолчанию в базе данных WordPress установлен префикс «wp_». Это упрощает использование уязвимостей с MySQL-инъекцией: если известно имя таблицы, в нее гораздо проще вставить вредоносный код, изменить в ней информацию или вообще удалить. В новых версиях WordPress появилась возможность выбора префикса при установке.
Если вы используете раннюю версию WordPress, то изменить префикс можно с помощью специализированных плагинов. Наиболее известным и популярным является Prefix Changer. Следует, однако, учесть, что многие из этих плагинов не всегда работают корректно, поэтому перед их использованием рекомендуется сохранить резервную копию базы данных.
Переместите файл wp-config.php. В файле wp-config.php хранятся важные параметры настройки WordPress, которую желательно защитить от несанкционированного доступа. По умолчанию этот файл сохраняется в корневом каталоге, но его можно переместить на каталог выше. Не обнаружив файла wp-config.php в корневом каталоге, WordPress будет искать его автоматически.
Получите SSL-сертификат и включите SSL-шифрование. Для этого в файл wp-config нужно добавить следующие строки:
/* Enable SSL Encryption */ define(‘FORCE_SSL_LOGIN’, true); define(‘FORCE_SSL_ADMIN’, true);
Удалите информацию о версии WordPress. Если злоумышленник узнает, что вы используете устаревшую версию WordPress, то он может воспользоваться имеющимися уязвимостями и взломать ваш сайт. Поэтому информацию о версии лучше удалить.
Во-первых, нужно удалить файл: ваш_сайт/readme.html, из которого можно без труда узнать, какую версию WordPress вы используете.
Об используемой версии можно также узнать из файла header.php, который находится в папке с темой. Он содержит следующую строку:
<meta name="generator" content="WordPress " />
Можно удалить всю эту строку целиком. Если в файле header.php вашей темы оформления нет такой строки, то, скорее всего она вставляется автоматически WordPress’ом при вызове функции wp_head(). В таком случае удалить информацию о версии из секцииможно, добавив в файл functions.php следующий код:
remove_action(’wp_head’, ’wp_generator’); function selectel_remove_version() { return ’’; } add_filter(’the_generator’, ’selectel_remove_version’);
Измените ключи безопасности. В упомянутом выше файле wp-config.php есть раздел с ключами безопасности. Выглядит он так:
define(’AUTH_KEY’, ’’); define(’SECURE_AUTH_KEY’, ’’); define(’LOGGED_IN_KEY’, ’’); define(’NONCE_KEY’, ’’);
Ключи используются для хэширования паролей. Очень часто на этот раздел не обращают внимания даже опытные пользователи. Между тем изменить ключи безопасности довольно просто: достаточно зайти на страницу https://api.wordpress.org/secret-key/1.1 и скопировать сгенерированные ключи в файл wp-config.php. Эту процедуру достаточно осуществить всего один раз во время первичной настройки сайта.
Ограничьте доступ к папкам wp-content и wp-includes. Из соображений безопасности рекомендуется закрыть доступ к содержимому папок wp-content и wp-includes. Нужно закрыть доступ к любым файлам, кроме графики, JS и СSS. Для этого нужно в каждой папке создать файл .htaccess и поместить в него такой код:
Order Allow,Deny Deny from all Allow from all
Создайте пустой файл wp-content/plugins/index.html. Благодаря этому станет недоступной информация о том, какие плагины вы используете. В плагинах WordPress могут содержаться уязвимости, и этим могут воспользоваться злоумышленники.
Чтобы сделать листинг недоступным, можно также добавить в файл .htaccess, хранящийся в папке с плагинами, следующую строку:
Options -Indexes
Ограничьте доступ к папке wp-admin.
Чтобы ограничить доступ, нужно в этой папке создать файл .htaccess и поместить в него следующий код:
AuthUserFile /dev/null AuthGroupFile /dev/null AuthName «Access Control» AuthType Basic order deny,allow deny from all # указываем, например. IP-адрес домашнего компьютера allow from # здесь указываем адрес один или несколько IP-адресов, с которых мы будем писать в блог на работе allow from allow from
Ограничивать доступ определенным набором IP-адресов не всегда удобно. Можно настроить доступ к папке wp-admin только по паролю. Для этого нужно создать файл .htauth:
$ htpasswd -c /home/yourdirectory/.htauth
И поместить его на один уровень выше директории /public_html/
Затем нужно создать в папке wp-admin файл .htaccess и поместить в него следующий код:
AuthName «Admins Only» AuthUserFile /home/yourdirectory/.htauth AuthGroupFile /dev/null AuthType basic require user <имя пользователя>
Заключение
Настройка даже такой простой и интуитивно понятной CMS, как WordPress — дело довольно непростое и содержащее большое количество нюансов, на которые не всегда обращают внимание даже опытные пользователи.
Тянуто с Хабра
Просто Славянск
Просто Славянск
Не вставайте у меня на пути — я строю мир
Здравствуйте. Я — русский. Так сложилось исторически.
Я оккупировал Сибирь.Теперь там добывают нефть, газ, алюминий и еще кучу всего полезного. Теперь там города, в которых стоят многоэтажные дома, детские сады, горячая вода и больницы.
Теперь там нельзя продавать женщин за вязанку соболиных шкурок, как это было до оккупации.
Я оккупировал Прибалтику. Построил там заводы, электростанции и школы на месте смешных хуторов. Русская Прибалтика делала высококлассную радиотехнику и автомобили, славилась духАми и бальзамами. Меня попросили оттуда уйти.
Теперь на месте знаменитого завода VEF и других заводов развалины. Помните, как от Калининграда до Сахалина рассекали дороги прибалтийские микроавтобусы РАФ? Так теперь от этого завода остались только заброшенные цеха. У Прибалтики теперь НЕТ своей промышленности. А часть трудоспособного населения чистит евроунитазы во второсортных отелях в хвалёном ЕС.
Я оккупировал Среднюю Азию. Построил там каналы, заводы, космодромы, больницы и стадионы. Там строили космические ракеты и самолеты, нефтегазовое и химическое оборудование, добывали медь, нефть и золото, выращивали пшеницу и хлопок для всей страны. Меня попросили оттуда уйти.
Теперь там добывают американские кредиты и выращивают коноплю, а половина трудоспособного
населения уехала работать на стройках бывших оккупантов.
Я оккупировал Украину. И там Я тоже построил заводы и электростанции, мосты и фабрики, шахты и университеты. Украина делала самолетные двигатели, корабли, танки, автомобили. Меня попросили оттуда уйти.
Теперь там производят “майданы” в товарных количествах. А больше там ни хера не производят, но уверены в том, что Европа их ждет с распростертыми объятиями…
И знаете что? Меня достало извиняться за то, что Я оккупант. Да, Я ОККУПАНТ. По праву рождения.
Устройство автомата Калашникова, я знаю лучше, чем устройство соски для молока. Я агрессор и кровожадный урод. Бойтесь… Это Я сжег Москву, чтобы не отдать ее Наполеону Бонапарту, но как кончил Бонапарт?…
Это Я сидел в окопе у Волоколамска, и горел в танке под Курском, понимая, что немцев удержать
невероятно трудно, но по другому просто никак. Где сегодня те немцы, где их Гитлер?…
Я оккупант, но в демократической Европе об этом не знали, поэтому именно ко мне домой ,
на мою землю, приходили все, кому не лень. Турки, англичане, поляки, немцы, французы.
Земли им хватило на всех — по 2,5 метра на каждого. Американцы, правда , приходить опасаются.
Наверное, они всё же слегка меня боятся. Они надеются на свои ракеты, майданы, смешного
Тягнибока, гражданина Германии КлЯчко, и разных других своих друзей и соратников.
Но и для них у нас земли много — хватит на всех, с избытком. Кстати, кто-нибудь знает, что за национальность такая “американец”?…
Я был, есть и буду русским оккупантом.
Мне чужого не надо, но свое я никогда не отдам. Мне не нужна ваша лицемерная свобода от того,
чтобы быть человеком, мне не нужна гнилая демократия капитализма, мне чужды двуличные
понятия и все то, что вы называете западными ценностями — извращения, пороки, обман и
бесконечная жадность… У меня другие интересы. Русскому оккупанту больше интересны космос, образование, медицина, наука и развитие творческих способностей человека. Русскому оккупанту нравится созидать.
И не вставайте у меня на пути — я строю мир.Я люблю мир, но воевать я умею лучше всех… Не будите Лихо, мои хорошие евро-американские друзья, пока оно тихо.. Ну, это просто так у нас говорится…
Краткий обзор контейнеров
Open source решения на базе Linux для создания виртуальных окружений
Встречайте героев сегодняшнего рассказа!
Поименно:
- KVM
- Xen
- Linux VServer
- OpenVZ
- LXC (Linux Containers)
Таблица: сравнение имеющихся технологий для реализации виртуальных окружений в Linux
Хотелось бы отметить, что Oracle VirtualBox был не включен в таблицу осознанно, так как не является полностью открытым, а в статье мы рассматриваем только открытые технологии.
Данная таблица позволяет легко сделать выводы, что готовых для промышленного использования технологий на сегодняшний день всего три: KVM, Xen и OpenVZ. Также очень активными темпами развивается технология LXC и по этой причине мы просто обязаны ее рассмотреть. Все четыре технологии в свою очередь реализуют два подхода к изоляции — полная виртуализация и контейнеризация, о них мы и поговорим.
Полная виртуализация
Давайте отойдем от сугубо теоретических описаний и посмотрим наглядную схему на примере KVM.
Как Вы видите, у нас имеется три уровня:
- Аппаратное обеспечение (Disk, NIC, CPU, Memory на изображении — система хранения, сетевые устройства, процессор и память)
- Linux ядро (совершенно любое, из любого более-менее современного дистрибутива, но рекомендуется 2.6.32 и выше; для определенности назовем его HWN, HardWare Node)
- Виртуальные машины (клиентские ОС), работающие как обычные процессы в Linux системе рядом с обычными Linux демонами
Все взаимодействие здесь довольно прозрачно — базовое ядро Linux (HWN) взаимодействует с железом (процессор, память, ввод-вывод), и в свою очередь обеспечивает возможность работы процессов, в которых и крутятся с помощью специального модуля ядра полноценные ядра Linux, FreeBSD или даже Windows. Стоит обратить внимание, что это не совсем обычные процессы, работа виртуальных машин обеспечивается посредством модуля ядра (KVM) осуществляющего трансляцию системных вызовов из клиентской операционной системы к HWN. Данное описание работы нельзя считать полностью корректным, но оно полностью передает смысл данного подхода.Самое важное на что стоит обратить внимание, что трансляция из вызовов клиентской ОС в вызовы HWN осуществляется с помощью специальной технологии процессора (AMD-V, Intel VT).
Недостатки данного типа изоляции сводятся к дополнительным задержкам в работе дисковой подсистемы, сетевой подсистемы, памяти, процессора из-за использования дополнительного аппаратно-программного слоя абстракции между реальным железом и виртуальной средой. Силами различных технологий и подходов (например, программный virtio, аппаратный VT-d) эти задержки сводятся к минимуму, но устранить их полностью не удастся никогда (разве что виртуализацию встроят в железо) по причине того, что это дополнительный слой абстракции, за который нужно платить.
Затраты на реализацию полной виртуализации
Согласно недавним исследованиям IBM оверхед (это разница между производительностью приложения внутри виртуального окружения и того же приложения работающего без использования виртуализации вообще) технологии KVM при вводе-выводе составляет около 15% при тестировании на SUSE Linux Enterprise Server 11 Service Pack 3.
Также есть очень интересное тестирование, представленное в Journal of Physics: Conference 219 (2010), в котором озвучиваются цифры: 3-4% оверхед для процессора, и 20-30% для дискового ввода-вывода.
В это же время в презентации RedHat за 2013й год озвучивается цифра в 12% (то есть 88% производительности конфигурации работающей без виртуализации).
Разумеется, эти тесты проведены в разных конфигурациях ПО, для разных паттернов нагрузки, для разного оборудования и я даже допускаю, что часть из них проведены некорректно, но суть их сводится к одному — накладные расходы (оверхед) при использовании как KVM, так и Xen достигают 5-15% в зависимости от типа используемого по и конфигурации системы. Согласитесь, немало?
Контейнеризация
Поступим аналогично, воспользуемся иллюстрацией.
Сразу хочется оговорится, что все сказанное ниже справедливо как для OpenVZ, так и для LXC. Эти технологии очень и очень похожи и являются крайне близкими родственниками (эту тему я постараюсь раскрыть в следующей своей публикации).
Хоть и изображение нарисовано в немного ином стиле, сразу же бросается в глаза ключевое отличие — ядро используется лишь одно и никаких виртуальных машин (VM) нет в помине! Но как же оно работает? На низком уровне все происходит аналогично — Linux ядро HWN взаимодействует с аппаратным обеспечение и выполняет все запросы, касающиеся обращения к аппаратной части, из виртуальных окружений. Но как же виртуальные окружения отделены друг от друга? Они отделены с помощью встроенных в Linux ядро механизмов!
В первую очередь это видоизмененный аналог chroot (видоизменения касаются в первую очередь защиты, чтобы не было возможности вырваться из chroot’нутого окружения в корневую файловую систему), который всем нам хорошо знаком, он позволяет создать изолированные друг от друга иерархии внутри одной файловой системы. Но chroot не позволяет, например, запустить свой собственный init процесс (pid 1, так как на HWN уже существует init процесс с данными PID), а это обязательное требование, если мы хотим иметь полностью изолированную клиентскую ОС внутри контейнера. Для этого используется механизм PID namespaces, который внутри каждого chroot окружения создает полностью независимую от HWN систему идентификаторов процессов, где мы можем иметь свой собственный процесс с PID 1 даже если на самом сервере уже запущен init процесс. В общем случае, мы можем создать сотни и даже тысячи отдельных контейнеров, никак не связанных друг с другом.
Как же при этом ограничивается память, нагрузка на процессор и жесткий диск? Они ограничиваются также посредством механизма cgroups, который, к слову, также используется и для точь-в-точь тех же самых целей в технологии KVM.
Затраты на реализацию контейнеризации
Как мы обсуждали ранее, любая технология изоляции имеет оверхед, хотим мы этого или не хотим. Но в случае контейнеризации этот оверхед ничтожно мал (0.1-1%) за счет того, что используются очень простые преобразования, который зачастую можно объяснить буквально на пальцах. Например, изоляция PID процессов и пространств сокетов осуществляется посредством добавления дополнительного 4-х байтного идентификатора, обозначающего, к какому контейнеру принадлежит процесс. С памятью все немного сложнее и происходит ее определенная потеря (из-за особенностей выделения памяти), но на скорость выделения и работы с памятью это почти не влияет. С дисковой системой и подсистемой ввода вывода ситуация аналогична. В цифрах оценки оверхеда для OpenVZ приводятся в работах — инженеров HP и исследователей из Университета Бразилии для HPC и они находятся в районе 0.1-1% в зависимости от типа нагрузки и методики тестирования.
Контейнеризация против виртуализации
Вот мы и подошли к теме заявленной в самом начале! Мы обсудили оверхед технологий полной виртуализации и технологий контейнеризации, теперь самое время сравнить их напрямую между собой. Обращаю внимание, что в некоторых тестах вместо OpenVZ используется его коммерческая версия PCS, это имеет минимальное влияние на тесты, так как ядро используемое как в открытой, так и коммерческой ОС полностью идентично.
В сети довольно мало качественно проведенных тестов с участием всех трех игроков и почти все они проведены компанией Parallels, которая в свою очередь разработчик OpenVZ. Если приводить такие тесты без возможности их проверки и повторения — могут возникнуть вопросы о предвзятости.
Я довольно долго думал как этого добиться и мне в руки попался чудесный документ, в котором KVM, XEN и OpenVZ/PCS тестируются на основе тестовой методологии разработанной компанией Intel — vConsolidate, а также стандартизированного LAMP теста, что позволяет проверить все результаты в домашних условиях и убедиться в их истинности.
Так как данный тест сугубо в попугаях, я не стал приводить его промежуточных графиков и вывел итоговые результаты. Как можно видеть — преимущество OpenVZ на лицо. Разумеется, компания Intel учла многое в своем тесте, но все же очень сложно интерпретировать эти цифры.
Поэтому предлагаю более понятный LAMP тест, из того же документа от Parallels, он тестирует производительность LAMP приложения в зависимости от числа запущенных виртуальных окружений:
Тут все намного понятнее и четко виден почти 2-х кратный прирост в суммарном числе транзакций выполняемых LAMP приложением! Чего же еще можно пожелать? 🙂
Разумеется, можно было охватить еще больше тестов, но, к сожалению, мы итак сильно вышли за рамки типовой Хабра-статьи, поэтому милости прошу вот сюда.
Надеюсь, я смог Вас убедить в том, что решения на базе контейнеризации позволяют выжать из железа почти всю возможную его мощность
Контейнеризация — это будущее облаков!
В данной статье мы попробовали доказать, что эффективность использования аппаратных ресурсов при использовании контейнеризации вместо полной виртуализации позволяет экономить до 10% (мы берем среднюю оценку) всех вычислительных ресурсов сервера. Довольно сложно судить в процентах, намного проще представить, что у Вас было 100 серверов и они решали некую задачу с использованием полной виртуализации, то внедрив контейнеризацию можно освободить почти 10 полноценных серверов, которые потребляют много электричества, занимают место (которое стоит очень дорого в случае современных ЦОД), стоят сами по себе много денег, а также требуют персонала для их обслуживания.
Как же уйти от абстрактных «дорого» к реальным цифрам? Наиболее весомую экономию нам дает экономия на электричестве. Затраты на электричество, по данным Intel, составляют почти 10% всех операционных затрат на эксплуатацию Дата Центров. Которые в свою очередь, по данным Агентства Защиты Окружающей среды, US EPA, потребляют суммарно почти 1.5% всего электричества вырабатываемого в США. Таким образом, мы не просто экономим средства компаний, но и вносим значительный вклад в сохранение экологии за счет меньшего потребления электричества и более эффективного его использования!
Также стоит отметить, что самые крупные системы вычислений в мире — собственные облака Google, Yandex, Heroku и многих-многих других построены именно с использование технологии LXC, что еще раз доказывает преимущество контейнеризации в облачных вычислениях и показывает на примере реальных компаний.
Кроме того, обе озвученные технологии контейнеризации — OpenVZ и LXC имеют свободные лицензии и крайне активно развиваются и LXC (пусть, частично) есть на почти любом Linux сервере установленном в последние год-полтора. Открытые лицензии и активное сообщество разработчиков — залог успеха технологии в ближайшем будущем.
Цельнотянуто с Хабра