Достоинства:

• Ускоряется загрузка сайта за счёт того, что контент располагается на ближайших серверах CDN.
• Уменьшается нагрузка на сайт, так как не приходится раздавать множество изображений и других файлов, движок WordPress генерирует только страницу, а всё остальное подтягивается из CDN. Это снижает требования к хостингу.
• Уменьшается трафик, ведь большинство трафика создают изображения. Это также приводит к экономии.

Стоимость сервиса очень демократичная. На текущий момент у блога 300 уникальных посетителей в день и 600 RSS-подписчиков с fullfeed. И за это я плачу порядка $2-$3 в месяц:

Три месяца я держал свой блог на ноутбуке MacBook, стоящем на кухне – он плавно перемещался под потолком с кухонного шкафа на холодильник и обратно. Процесс установки блога на Mac OS X я детально описал в статьях: “Часть 1, MySQL“, “Часть 2, Apache” и “Часть 3, кеширование“.

Но в последние недели я стал замечать, что по какой-то непонятной для меня причины подсеть моего домашнего провайдера становится недоступной на переходе Telia – Level3. Если бы это был одинарный случай, то я бы не беспокоился. Но две недели подряд – это уже перебор.

В итоге я принял решение перейти на внешний хостинг.

К хостингу, особенно местечковому, у меня отношение сугубо отрицательное. Хостинг-провайдеры зарабатывают деньги. И разместить 200 клиентов на сервере, который может нормально обслужить всего 100 клиентов – это нормальная ситуация. И начинаются войны – клиенты требуют от провайдера сервиса, а провайдер обвиняет клиентов в создании излишней нагрузки и заставляет переходить на другой тариф. Всё это сопровождается непродуманностью технических возможностей – даже WordPress проблематично запустить из-за искусственно заниженных ограничений по памяти. В итоге shared-хостингом и VPS недовольны все. Поэтому местных хостинг-провайдеров я даже не рассматривал.

Самый правильный вариант – это выделенный сервер. Но прямой прибыли мои проекты не приносят, и платить $100-$200 никакого желания у меня нет.

Пересматривая заметки в Google Reader, я наткнулся на сравнительный анализ сервисов VPS Amazon, Rackspace, Linode и ещё двух компаний. Linode по большинству параметров опередил, и я решил попробовать.

Linode предлагает Xen-хостинг. Я взял минимальный пакет Linode 360 с 360 MB RAM.

Конечно, перенос блога об Apple с Mac OS X на Linux не совсем кошерно, и я не оправдываю часть названия “The Apple”. Зато “Geek”‘овость не страдает. Мне ещё с времени экспериментов с Amazon нравится Ubuntu, поэтому я создал VPS на Ubuntu 9.10 в Лондонском датацентре:

Процесс установки и переноса прошёл практически гладко, я даже не заметил ограничения по памяти. Мне показалось, что сайт стал работать немного медленнее, но это можно списать на территориальную удалённость площадки. Сейчас всяческие локальные сети обмена трафиком вроде UA-IX, MSK-IX уже кажутся рудиментом, и я предпочитаю держать ресурсы подальше от родины, тем более, что цена вопроса – какие-то смешные 50 ms RTT.

Да и стоимость меня очень даже устраивает. Кстати, @myfreeweb порекомендовал сервис (dv) компании Media Temple. Но я хочу пока побыть на Linode, тем более, что за месяц я уже заплатил.

Кроме всего прочего у Linode есть клиент под iPhone:

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

See you,
Serdyukov Oleg

Изображение из заголовка я взял с AllThingsDistributed.

Для любого сайта важны контент, скорость и дизайн. Без качественного контента не будет посетителей, плохая скорость их рано или поздно отпугнёт, плохой дизайн тоже не придаст особой любви даже при хорошем контенте (но это на последнем месте, так как многие посетители читают обновления только через RSS). Контент и дизайн – вещи творческие, а вот скорость технологична, её можно обеспечить за счёт применения некоторых рекомендаций и настройки софта. Самое качественное и полное руководство – это документ Yahoo “Best Practices for Speeding Up Your Web Site“. Если его выполнить, то можно добиться значительного ускорения работы своего сайта.

Для аудита есть плагин Firefox YSlow, разработанный Yahoo. Он работает совместно с FireBug. В этой части я не буду останавливаться на нём, расскажу в отдельной части.

Один из важных пунктов в оптимизации – это “Use a Content Delivery Network”. Все Content Delivery Network служат для быстрой и надёжной географически распределённой доставки статического контента. Вот как раз об этом и поговорим.

У Amazon есть свой CDN – CloudFront. Описание и практические принципы работы расписаны в Getting Started Guide, я не буду их здесь дублировать, а покажу, как практически разместить свои данные в CloudFront.

Предупреждение: услуга Amazon CloudFront платная, тарифы есть на сайте Amazon.

Для начала активируем сервис, для чего идём на страницу CloudFront:

Sign Up For Amazon CloudFront. Будет запрошен логин/пароль:

Можно ознакомиться с ценами и проверить биллинговые данные, после чего нажать “Complete Sign Up”:

Сервис активирован:

Работать с CloudFront можно через AWS Management Console:

Но гораздо проще – через бесплатную утилиту Cyberduck. Я собирался привычно рассказывать о работе с системой через консоль, но в процессе создания S3 Bucket с удивлением увидел, что Cyberduck прекрасно работает не только с S3, но и с CloudFront. Желающих же продолжить с консолью я направляю на Getting Started Guide, там всё прекрасно описано.

Предварительно находим и где-нибудь сохраняем AWS Access Key ID и Secret Access Key – они нам понадобятся немного позже. За ними идём на AWS, Your Account, Security Credentials:

Запускаем программу:

Создаём учётную запись S3:

Secondary click и Connect, либо просто Enter для подключения:

В поле Username вводим AWS Access Key ID, в поле Password – Secret Access Key:

Зашли в S3:

Создаю новый каталог (bucket). Имя должно быть уникально для всей системы:

Вот информация по bucket’у (Cmd+I):

В Cyberduck есть возможность сразу разместить данные в CloudFront. Для этого выставляем права:

Включаем CloudFront Distribution и логирование

Заходим в каталог и перетаскиваем туда нужный файл image.jpg:

Смотрим информацию по файлу, запоминаем URL (http://d2ggdqlo6oay4b.cloudfront.net/image.jpg):

Всё, через минут 5 можно обращаться к файлу по указанному адресу.

Обратите внимание, что в свойствах S3 регион указан “US Standard”. Его можно поменять в настройках программы, но до создания bucket’а:

Логи по обращению к файлам в CloudFront находятся в каталоге logs в нашем Bucket’е:

Всё, данные размещены, URL получен, и его можно использовать у себя на сайте. Ждите следующую часть – я расскажу о потрясающем плагине W3 Total Cache для WordPress, с ним я ускорил время загрузки страницы с 220 ms до 34 ms – согласитесь, это очень хороший результат.

Кстати, сейчас вы можете оценить работу и этого плагина, и Amazon CloudFront – они у меня активны. Один побочный эффект – пришлось отключить плагин адаптации сайта под iPhone, но я занимаюсь восстановлением его работы.

Для быстрой работы блог нужно всячески кешировать. Я использую комбинацию из нескольких способов – кеширование на уровне WordPress WP Super Cache, на уровне PHP – eAccelerator, Memcached и заодно кеширование запросов MySQL. По крайней мере хуже не становится, а улучшение производительности налицо.

Один из полезнейших плагинов WordPress – это WP Super Cache. Он из категории “must have”. Настройки:

Есть некоторые проблемы с WPTouch, поэтому нужно отключить кеширование для мобильных устройств:

Список для копирования:

bot
ia_archive
slurp
crawl
spider
iphone
ipod
android
dream
cupcake
webos
incognito
webmate
opera
mini
blackberry9530
blackberry9500

Memcached. Я его раньше не использовал, но всегда хотел. Особой эффективности для небольшой нагрузки я не заметил, но он по крайней мере работает. Процесс установки:

$ sudo port install memcached
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.memcached.plist
$ sudo port install php5-memcache

И перезапускаем apache.

Статус демона memcached можно посмотреть таким образом:

$ echo stats | nc 127.0.0.1 11211

Для того, чтобы Memcached использовался в WordPress, ставим плагин WP Memcached Manager. Настройки:

Статус работы:

EAccelerator. Нужен. Однозначно. Теория – на сайте разработчиков. Процесс установки и настройки:

$ sudo port install php5-eaccelerator
$ sudo vim /opt/local/var/db/php5/eaccelerator.ini

eaccelerator.shm_size="16"
eaccelerator.cache_dir="/tmp/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter="*.php"
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

И перезагружаем apache.

Включаем кеширование запросов в MySQL:

$ sudo vim /etc/my.cnf
query_cache_type = 1
query_cache_size = 26214400

И перезагружаем MySQL.

Статус работы:

$ mysql mysql
SHOW STATUS LIKE 'Qcache%';
SHOW STATUS LIKE 'Questions%';

И в завершение тестируем быстродействие сайта:

$ ab -n 1000 -c 1 http://theapplegeek.ru

Но и это ещё не всё. Продолжим оптимизацию уже на nginx, одно из направлений – выставление Expire для определённых типов файлов, а также компресирование ответов. Продолжение следует.

Для простоты следующим шагом в качестве web-сервера я запущу apache. Его большое преимущество в том, что php очень просто ставится, как модуль, и не требуется дополнительных ухищрений. Поэтому я запущу сайт именно под apache, а уже после этого переделаю всё под nginx, который мне нравится больше.

В Mac OS X есть штатный apache, его можно запустить в System Preferences/Sharing/Web Sharing:

Это полноценный Apache/2.2.13, но для наших целей он не подходит – PHP в портах требует установленного apache, причём из портов. Ухищряться можно было бы, но особого желания у меня делать это не было. Поэтому я спокойно смиряюсь с мыслью, что в системе будет стоять Apache родной и Apache из портов.

Установка Apache2 проста:

$ sudo port install apache2

Запуск (пока его запускать не нужно):

$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

Остановка:

$ sudo launchctl unload -w /Library/LaunchDaemons/org.macports.apache2.plist

Я привык управлять apache через apachectl, и не собираюсь изменять своим привычкам. Но apachectl от штатного Apache находится в /usr/sbin/apachectl:

$ which apachectl
/usr/sbin/apachectl

Apachectl же свежеустановленного порта лежит в /opt/local/apache22/bin/apachectl, для простоты делаем симлинк в каталог, находящийся первее в путях, чем /usr/sbin:

$ sudo ln -s /opt/local/apache22/bin/apachectl /opt/local/bin/

Теперь очередь за PHP, ставим полный набор, который нужен для WordPress (некоторые модули не нужны, но я их использую все). В процессе установки читаем сообщения:

$ sudo port install php5-web
To customize php, copy
/opt/local/etc/php5/php.ini-development (if this is a development server) or
/opt/local/etc/php5/php.ini-production (if this is a production server) to
/opt/local/etc/php5/php.ini and then make changes.

$ sudo port install php5-mysql
To use mysqlnd with a local MySQL server, edit /opt/local/etc/php5/php.ini and set
mysql.default_socket, mysqli.default_socket and pdo_mysql.default_socket
to /opt/local/var/run/mysql5/mysqld.sock

Дальше полезных сообщений не будет:

$ sudo port install php5-mbstring
$ sudo port install php5-mcrypt
$ sudo port install php5-zip
$ sudo port install php5-gd
$ sudo port install php5-eaccelerator
$ sudo port install php5-openssl
$ sudo port install php5-sockets
$ sudo port install libssh2

Для eaccelerator создаю нужный каталог:

$ sudo mkdir /tmp/eaccelerator/
$ sudo chown www:www /tmp/eaccelerator/

Беру php.ini-production и делаю в нём базовые правки (тюнинг PHP-тема отдельная)

$ sudo cp /opt/local/etc/php5/php.ini-production \
	/opt/local/etc/php5/php.ini
$ sudo vim /opt/local/etc/php5/php.ini
date.timezone = Europe/Kiev
error_log = /var/log/php_errors.log
mysql.default_socket = /opt/local/var/run/mysql5/mysqld.sock

Не забываю создать файл для логов, иначе они могут не писаться

$ sudo touch /var/log/php_errors.log
$ sudo chown www:www /var/log/php_errors.log

Для интересующихся модули PHP поставились в каталог:

$ ls -al /opt/local/lib/php/extensions/no-debug-non-zts-20090626/
-rwxr-xr-x   2 root  admin    71880 Jan  9 22:29 eaccelerator.so
-rwxr-xr-x   2 root  admin   338560 Jan  9 22:32 gd.so
-rwxr-xr-x   2 root  admin  2031040 Jan  9 22:27 mbstring.so
-rwxr-xr-x   2 root  admin    38384 Jan  9 22:29 mcrypt.so
-rwxr-xr-x   2 root  admin    46648 Jan  9 22:26 mysql.so
-rwxr-xr-x   2 root  admin   111672 Jan  9 22:26 mysqli.so
-rwxr-xr-x   2 root  admin   117480 Jan 10 21:41 openssl.so
-rwxr-xr-x   2 root  admin    30496 Jan  9 22:26 pdo_mysql.so
-rwxr-xr-x   2 root  admin    45016 Jan 10 21:47 sockets.so
-rwxr-xr-x   2 root  admin    81680 Jan  9 22:29 zip.so

Теперь приступаем к конфигурированию Apache. Я отключаю ненужные мне модули, убираю все комментарии и вычищаю мусор. Рассказывать об этом не буду подробно, могу сказать, что и в “дефолтовом” состоянии Apache работает хорошо, главное сделать несколько коррекций, которые я приведу ниже:

$ sudo vim /opt/local/apache2/conf/httpd.conf

В конце секции загрузки модулей добавляем:

LoadModule php5_module modules/libphp5.so

Меняем строку

DirectoryIndex index.html

на

DirectoryIndex index.html index.php

Раскомментариваем включаемые файлы

Include conf/extra/httpd-mpm.conf
Include conf/extra/httpd-vhosts.conf
Include conf/extra/httpd-default.conf

Добавляем конфиг для php (файл установился, я удивился, почему сам модуль не активировался в LoadModule):

Include conf/extra/mod_php.conf

httpd-mpm.conf можем не править, там всё в порядке.

В httpd-default.conf нужно подправить параметры, которые я выделил жирным. Если на сервер будет большое количество коннектов, и, например, база данных будет не справляться, то стоит выключить KeepAlive и размышлять о кешировании.

$ sudo vim /opt/local/apache2/conf/extra/httpd-default.conf
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
UseCanonicalName Off
AccessFileName .htaccess
ServerTokens Prod
ServerSignature Off
HostnameLookups Off

В httpd-vhosts.conf описываются виртуальные хосты. Я это делаю так:

$ sudo vim /opt/local/apache2/conf/extra/httpd-vhosts.conf
NameVirtualHost *:80
<VirtualHost *:80>
    ServerAdmin webmaster@theapplegeek.ru
    ServerName theapplegeek.ru
    ErrorLog "logs/theapplegeek.ru-error_log"
    CustomLog "logs/theapplegeek.ru-access_log" common
    DocumentRoot "/Users/ctrld/Sites/theapplegeek/public_html"
    <Directory "/Users/ctrld/Sites/theapplegeek/public_html">
        Options FollowSymLinks -Indexes
        AllowOverride All
        Order allow,deny
        Allow from all
     </Directory>

    <Location "/wp-content/uploads">
        php_admin_flag engine off
        AddType text/plain .html .htm .shtml
    </Location>
</VirtualHost>

<VirtualHost *:80>
    ServerName          www.theapplegeek.ru
    RedirectPermanent   /   "http://theapplegeek.ru/"
</VirtualHost>

Обратите внимание на запрет php для /wp-content/uploads. Также вы видите, что основное имя хоста у меня без www – этот рудимент меня удивлял ещё лет семь назад. Но так как есть некоторые посетители, пытающиеся вводить www, то переучивать их можно только с помощью Permanent Redirect на основной домен.

Всё, Apache сконфигурирован. Конечно же, путь /Users/ctrld/Sites/theapplegeek/public_html должен существовать. Делаем тестовый файл для проверки php:

$ vim /Users/ctrld/Sites/theapplegeek/public_html/info.php
<?php
    phpinfo();
?>

Проверим конфигурацию apache:

$ sudo /opt/local/apache2/bin/apachectl configtest
Syntax OK

Если всё в порядке, то запускаем его (в первый раз – через launchctl load -w, чтобы он смог стартовать после перезапуска системы):

$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

А в дальнейшем можем использовать apachectl:

$ sudo apachectl start
$ sudo apachectl stop
$ sudo apachectl restart
$ sudo apachectl graceful

Последняя команда (graceful) позволяет рестартовать apache без обрыва соединений, что вежливо по отношению к посетителям.

Можно убедиться, что apache запущен:

$ ps ax | grep htt
37877   ??  Ss     0:00.10 /opt/local/apache2/bin/httpd -k start
37878   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start
37879   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start
37880   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start
37881   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start
37882   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start

Теперь небольшой “хинт”. Я описал виртуальный хост реального сайта theapplegeek.ru. Но я ещё ничего не переносил и контента там нет. Для того, чтобы оттестировать сайт и исправить ошибки, я направляю запросы на новое место, модифицируя /etc/hosts на том компьютере, с которого я тестирую сайт, но другие посетители будут ходить до переключения в DNS на старое место.

$ sudo vim /etc/hosts
94.45.55.146	theapplegeek.ru
94.45.55.146	www.theapplegeek.ru

Всё, подготовительные работы сделаны, можно проверять. Открываю в браузере URL http://theapplegeek.ru/info.php с тестовым скриптом PHP. Всё работает. Благодать. Если же есть какие-то проблемы, то нужно смотреть логи:

$ tail -f /opt/local/apache2/logs/theapplegeek.ru-error_log
$ tail -f /opt/local/apache2/logs/theapplegeek.ru-access_log
$ tail -f /opt/local/apache2/logs/error_log
$ tail -f /var/log/php_errors.log

Установка WordPress не отличается от установки на любом Unix, его можно поставить по отличной инструкции на русском языке. Но если нужно, то напишите в комментариях, и я в отдельной части рассмотрю этот процесс.

Домашняя сеть у меня подключена через TimeCapsule, и проброс обращений извне к web-серверу, находящемся на адресе 192.168.98.2, я сделал через Port Mapping:

Внешний адрес я обычно смотрю через сервис WhatIsMyIP (94.45.55.146). Как только я перенёс сайт и проверил его работу, я зашёл в панель управления моими DNS-зонами и переключил записи со старого места на новое:

И затем начал следить за логами и корректировать проблемы, которые я пропустил. На помощь приходит в том числе такая конструкция, позволяющая искать 404/etc:

$ tail -1000 /opt/local/apache2/logs/theapplegeek.ru-access_log \
	| awk '$9 != 200 && $9 != 304 {print $9, $7}' | sort | uniq -c

Вуаля.

Через несколько часов убираем из /etc/hosts добавленные ранее записи.

Следующим шагом я сконфигурирую nginx с использованием fastcgi для обработки PHP. Ещё (это больше памятка самому себе) нужно будет включить ежедневную ротацию логов. И сделать тюнинг PHP и сетевых параметров Mac OS X.

Недавно я подключился к провайдеру Интернет по Ethernet, да ещё с постоянным IP-адресом. Сервер, на котором у меня расположен сайт, периодически ведёт себя очень странно, я думаю, что вы могли это заметить. Иногда сервер перестаёт отвечать, я подозреваю вываливание в Kernel Panic (на сервере стоит FreeBSD 6.3). Подозреваю аппаратную проблему, но заменить сервер я пока не могу, а обновить систему до 8.0, или установить Linux можно, но непросто, так как я использую для сайтов jail’ы. В итоге я решил временно перенести сайты на MacBook, который у меня используется в виде сервера.

Подъём сервера для хостинга WordPress состоит из нескольких этапов, и я рассмотрю их в серии статей. В этой части я опишу установку MySQL, затем – настройку web-сервера на базе nginx с использованием PHP в виде Fastcgi (можно было бы использовать и Apache, но мне нужен легковесный и быстрый web-сервер, хорошо работающий под большой нагрузкой). Итак, приступим.

Поставить MySQL под Mac OS X можно несколькими методами. Самый неинтересный для меня – это MAMP (готовое решение, включающее MySQL, Apache, PHP с полным набором модулей). Объяснять почему мне это не нравится не буду, и так понятно.

Второй – из бинарного пакета с сайта MySQL (выбираем версию MySQL 5.1—Generally Available (GA) release for production use). Вот более короткий линк к нужному пакету, я ставлю из package format, Mac OS X 10.5 (x86_64), весь процесс описан в документации. Во многих случаях этот способ предпочтительный, так как MySQL здесь собран гарантированно нормально. Но есть некоторая сложность в обновлении – я предполагаю, что автообновлений нет, и придётся устанавливать новые версии вручную.

Третий метод, привычный для большинства системных администраторов Unix – это использование пакетного менеджера MacPorts, мне он нравится из-за предсказуемости обновлений, да и в любом случае мне понадобятся порты для дальнейших шагов по запуску сайта.

Есть, конечно же, и четвёртый метод, заключающийся в компиляции MySQL из исходных текстов с накладыванием различных патчей, оптимизирующих работу MySQL, но я не любитель стиля Gentoo, и мне важнее предсказуемость работы системы и простота обновлений, чем выигрыш производительности на 15%.

Сначала нужно поставить XCode, в котором находятся средства разработки под Unix, необходимые для компиляции MySQL и других пакетов. Это просто, объяснять не буду.

Потом – MacPorts. Списывается пакет последней версии под нужную версию Mac OS X, в моём случае MacPorts-1.8.2-10.6-SnowLeopard.dmg, и устанавливается. Сразу же обновим дерево портов:

$ . ~/.profile
$ sudo port selfupdate

Ставим MySQL Server (на MacBook 2.2 GHz пакет поставился за 22 минуты):

$ sudo port install mysql5-server

При установке выдалось сообщение о том, как установить файлы базы данных и как запустить mysql. Выполняем:

$ sudo -u _mysql mysql_install_db5
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

Проверим, что MySQL запустился:

$ ps ax | grep mysql | grep -v grep
 2050   ??  Ss     0:00.00 /opt/local/bin/daemondo --label=mysql5 --start-cmd /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper restart ; --pid=none
 2060   ??  S      0:00.02 /bin/sh /opt/local/lib/mysql5/bin/mysqld_safe --datadir=/opt/local/var/db/mysql5 --pid-file=/opt/local/var/db/mysql5/ceiling-cat.local.pid
 2110   ??  S      0:00.07 /opt/local/libexec/mysqld --basedir=/opt/local --datadir=/opt/local/var/db/mysql5 --user=_mysql --log-error=/opt/local/var/db/mysql5/ceiling-cat.local.err --pid-file=/opt/local/var/db/mysql5/ceiling-cat.local.pid

Я привык к именам программ вида mysqladmin и mysql, а в каталоге /opt/local/bin описаны симлинки вида mysqladmin5/mysql5. Можно сделать нужные симлинки, но я сделаю универсальнее, прописав путь к нужным утилитам без суффикса “5″. Путь после модификации должен быть таков:

$ vim ~/.profile
export PATH=/opt/local/lib/mysql5/bin:/opt/local/bin:/opt/local/sbin:$PATH

Перечитываем путь с помощью “source”:

$ . ~/.profile
$ echo $PATH
/opt/local/lib/mysql5/bin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

Теперь можем привычно запускать утилиты MySQL

$ which mysql
/opt/local/lib/mysql5/bin/mysql

Проверить, запустился ли MySQL, можно и так:

$ mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.1.42 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Сразу же устанавливаем пароль root (этот пароль я сразу же после написания статьи изменю):

$ mysqladmin -u root password 'fc97a2060ec0775ed3b6aa011ee27e88'

Для того, чтобы не вводить пароль каждый раз, прописываем его в конфиг-файле:

$ touch ~/.my.cnf
$ chmod 600 ~/.my.cnf
$ vim ~/.my.cnf
[mysql]
user    =   root
pass    =   fc97a2060ec0775ed3b6aa011ee27e88

Обязательно нужно или поменять пароль для доступа через сеть, или удалить записи для хостов “hostname.local” и 127.0.0.1. Когда мне понадобится, я создам нужных пользователей, поэтому буду удалять.

$ mysql mysql
mysql> select Host, User, Password from user where user = 'root';
+-------------------+------+-------------------------------------------+
| Host              | User | Password                                  |
+-------------------+------+-------------------------------------------+
| localhost         | root | *769F25A82BD5CC256FA4D47499CE6026D89D72E6 |
| ceiling-cat.local | root |                                           |
| 127.0.0.1         | root |                                           |
+-------------------+------+-------------------------------------------+
mysql> delete from user where User = "root" and Host = "127.0.0.1";
Query OK, 1 row affected (0.00 sec)

mysql> delete from user where User = "root" and Host = "ceiling-cat.local";
Query OK, 1 row affected (0.00 sec)

mysql> select Host, User, Password from user where user = 'root';
+-----------+------+-------------------------------------------+
| Host      | User | Password                                  |
+-----------+------+-------------------------------------------+
| localhost | root | *769F25A82BD5CC256FA4D47499CE6026D89D72E6 |
+-----------+------+-------------------------------------------+

Можно было бы на этом и закончить, но лучше донастроить MySQL через конфиг-файл /etc/my.cnf. По крайней мере нужно выставить использование по умолчанию UTF8, включить INNODB, ограничить количество коннектов, и включить slow_query_log.

Примеры конфиг-файлов поставляются вместе с MySQL:

$ ls -al /opt/local/share/mysql5/mysql/my*cnf
-rw-r--r--  2 root  admin   4851 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-huge.cnf
-rw-r--r--  2 root  admin  20232 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-innodb-heavy-4G.cnf
-rw-r--r--  2 root  admin   4825 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-large.cnf
-rw-r--r--  2 root  admin   4836 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-medium.cnf
-rw-r--r--  2 root  admin   2474 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-small.cnf

Меня устраивает конфигурация medium:

$ head -5 /opt/local/share/mysql5/mysql/my-medium.cnf
# Example MySQL config file for medium systems.
#
# This is for a system with little memory (32M - 64M) where MySQL plays
# an important part, or systems up to 128M where MySQL is used together with
# other programs (such as a web server)

Копирую её в /etc/my.cnf:

$ sudo cp /opt/local/share/mysql5/mysql/my-medium.cnf /etc/my.cnf

Корректирую конфиг (если интересно, то одна из первых версий доступна для списывания):

• Отключаю возможность доступа по сети: skip-networking
• Выставляю везде default-character-set=utf8
• Для mysqld включаю character-set-server = utf8 и default-character-set = utf8
• Ограничиваю количество сессий max_connections=50
• thread_cache_size = 16
• query_cache_size = 32M
• Включаю секцию innodb
• Выставляю логгирование (slow_query_log = 1, slow_query_log_file = /var/log/mysql-slow.log, log-error = /var/log/mysql.log)

Создаю нужные файлы логов, иначе они не воспримутся:

$ sudo touch /var/log/mysql-slow.log
$ sudo chown _mysql:_mysql /var/log/mysql-slow.log
$ sudo touch /var/log/mysql.log
$ sudo chown _mysql:_mysql /var/log/mysql.log

Перезагружаем сервер MySQL (-w отключает disable, т.е. MySQL загрузится при рестарте системы)

$ sudo launchctl unload -w /Library/LaunchDaemons/org.macports.mysql5.plist
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

Нужно посмотреть лог на предмет ошибок или проблем:

$ tail -100 /var/log/mysql.log

Очень важно сделать базовый аудит конфигурации MySQL, для этого я использую два скрипта. Первый – mysqltuner.pl:

$ curl http://mysqltuner.com/mysqltuner.pl -o mysqltuner.pl
$ chmod +x mysqltuner.pl
$ ./mysqltuner.pl

Второй – mysql-tuning-primer:

$ curl http://launchpadlibrarian.net/36004840/tuning-primer.sh -o tuning-primer.sh
$ chmod +x tuning-primer.sh
$ ./tuning-primer.sh

Особых проблем скрипты не выявили. Если бы нашли, то нужно было бы подправить /etc/my.cnf и перезапустить MySQL.

Настройка закончена, осталось перезапустить Mac OS X для проверки, подымется ли MySQL после рестарта. У меня он поднялся.

Если вы хотите углубить свои знания по MySQL, то рекомендую ознакомиться с сайтом MySQL Performance Blog (этот сайт ведут специалисты широкоизвестной в узких кругах фирмы Percona).

Использование GUI для работы с базой данных

Я не разработчик, и мне хватает командно-строковой утилиты mysql. Но если вам нужен GUI, то можно будет или поставить phpMyAdmin (он будет доступен через web), или же утилиту под Mac OS X Sequel Pro (она бесплатная, приветствуются пожертвования).

Sequel Pro мне нравится тем, что он позволяет соединяться через туннель SSH, и на хосте с MySQL достаточно открыть сетевой доступ через 127.0.0.1. Для того, чтобы это сделать, нужно в /etc/my.cnf закомментировать опцию “skip-networking” (конечно же, после этого нужно перезагрузить MySQL) и открыть доступ пользователю (например, root):

$ mysql mysql
mysql> GRANT ALL ON *.* TO root@127.0.0.1 IDENTIFIED BY 'fc97a2060ec0775ed3b6aa011ee27e88';
mysql> FLUSH PRIVILEGES;

Настройка туннелирования:

Интерфейс программы:

Проверка производительности MySQL

Для того, чтобы знать, какую нагрузку выдержит MySQL, можно применить бенчмаркинг sql-bench (это необязательно, раздел можно пропустить). К сожалению, в портах его я не нашёл, поэтому сделаю не совсем правильно, но действенно – поставлю бинарный package с сайта MySQL (это второй описанный метод), но не буду запускать сам MySQL.

Списываю package Mac OS X 10.5 (x86_64) и устанавливаю его (только mysql-…..pkg, ни в коем случае не prefpane и не StartupItems). Система поставилась в /usr/local/mysql (это симлинк на каталог с установленной версией типа mysql-5.1.42-osx10.5-x86_64).

SQL-Bench использует Perl, для соединения с MySQL нужен DBD::mysql, поставим его (в ответ на предложение сконфигурировать CPAN нажимаем Enter или пишем “yes”):

$ sudo perl -MCPAN -eshell
Would you like me to configure as much as possible automatically? [yes] yes
cpan[1]> install DBD::mysql
...
 CAPTTOFU/DBD-mysql-4.013.tar.gz
 /usr/bin/make install  -- OK
cpan[2]> quit

Запускаем бенчмаркинг. Сразу предупреждаю, что процесс длительный, у меня он занял 16 минут:

$ cd /usr/local/mysql/sql-bench/
$ sudo ./run-all-tests --server=mysql --user=root -pass=fc97a2060ec0775ed3b6aa011ee27e88 --log

Смотрим на результат, размышляем.

На этом заканчиваем, в следующей части приступим к настройке web-сервера.

Замена паролей

При необходимости меняем пароль (как я и обещал, я это сделал – лучше три лишние команды, чем потеря данных):

$ mysql mysql
mysql> GRANT ALL ON *.* TO root@127.0.0.1 IDENTIFIED BY 'verysecretpassword';
mysql> GRANT ALL ON *.* TO root@localhost IDENTIFIED BY 'verysecretpassword';
mysql> FLUSH PRIVILEGES;

В первой части статьи я описал создание учётной записи на Amazon Web Services. Сейчас же приступим к реальной работе. Весь процесс работы отлично описан в официальном документе
“Amazon Elastic Compute Cloud. Getting Started Guide“, очень рекомендую с ним ознакомиться.

Создавал в последний раз сервера три дня назад. Сегодня же, уставившись на консоль, почувствовал себя как себя как герой рассказа “Цветы для Элджернона“… Ладно, прорвёмся.

Создание сертификата X.509

Заходим на “Amazon Web Services“, “Your Account”, “Security Credentials”.

Если вы зашли сюда через некоторое время после последнего входа, то система попросит аутентифицироваться:

Переходим на X.509 и создаём сертификат:

Сохраняем файлы с приватным и публичным ключами в надёжное место (это Downloads ;-):

Созданный сертификат уже есть в системе:

Из надёжного места нужно скопировать сертификат в каталог ~/.ec2 – этот каталог используется утилитами AWS EC2.

$ cd ~
$ mkdir .ec2
$ mv ~/Downloads/{cert*pem,pk*pem} ~/.ec2
$ chmod 700 .ec2
$ chmod 600 .ec2/*pem
$ ls -al ~/.ec2
drwx------   4 ctrld  staff   136 Nov 13 15:24 .
drwxr-xr-x+ 43 ctrld  staff  1462 Nov 13 15:24 ..
-rw-------@  1 ctrld  staff   916 Nov 13 15:18 cert-R3A4BRDL7YPWEYAQKUF2GK2HWYPBIWDM.pem
-rw-------@  1 ctrld  staff   922 Nov 13 15:18 pk-R3A4BRDL7YPWEYAQKUF2GK2HWYPBIWDM.pem

Установка утилит для работы EC2

В руководстве пользователя можно найти, где находятся утилиты для EC2. Если лень смотреть, то они доступны по адресу “Amazon EC2 API Tools“:

Архив ec2-api-tools.zip я распаковал в Documents/AWS, и сделал симлинк на случай обновления:

$ cd ~/Documents/AWS/
$ ln -s ec2-api-tools-1.3-42584 ec2-api-tools

Настройка окружения в shell

Для работы с EC2 нужно настроить переменные окружения. Вот фрагмент моего ~/.profile (спасибо @andy_shev за конструкцию ‘$(/usr/libexec/java_home)’, я обычно пользовался ‘`command`’, но так гораздо удобнее):

export JAVA_HOME=$(/usr/libexec/java_home)
export EC2_HOME=/Users/ctrld/Documents/AWS/ec2-api-tools
export PATH=$PATH:$EC2_HOME/bin

export EC2_PRIVATE_KEY=~/.ec2/pk-R3A4BRDL7YPWEYAQKUF2GK2HWYPBIWDM.pem
export EC2_CERT=~/.ec2/cert-R3A4BRDL7YPWEYAQKUF2GK2HWYPBIWDM.pem

export EC2_URL=https://eu-west-1.ec2.amazonaws.com

Для того, чтобы переменные окружения установились, можно или создать новую сессию в Terminal.app, а старую закрыть, или же воспользоваться “source”:

$ . ~/.profile

Обратите внимание на последнюю строку в фрагменте .profile. Я использую регион EU-WEST (второй вариант ориентирован на USA – US-EAST, меня он не интересует). Получить список доступных регионов можно так:

$ ec2-describe-regions
REGION	eu-west-1	eu-west-1.ec2.amazonaws.com
REGION	us-east-1	us-east-1.ec2.amazonaws.com

Конечно же, в переменных $EC2_PRIVATE_KEY и $EC2_CERT нужно указать ваши сертификаты X.509 – мои вам не пригодятся, и путь тоже стоит поменять на ваш (то, что нужно поменять, выделено жирным).

Создание ключа для доступа по SSH

Процесс можно посмотреть в “User guide“.

Создаём ключи для доступа по SSH. Это можно сделать в браузере через AWS Management Console, я же предпочитаю консоль. Лучше при работе с EC2 перейти сразу в каталог ~/.ec2 – это упрощает некоторые операции.

$ ec2-add-keypair gsg-keypair
KEYPAIR	gsg-keypair	7d:b5:85:0c:7d:5d:fd:bf:b4:8c:3e:d6:b5:bd:7f:08:71:d2:c1:9d
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEArTGhs3XCfhkxpfos8Wd8F3HXCGd/aVK5boOafptNVcTeP6afDyY7V9CoExK4
...
cnidqNgk7bFPkKGR6mMB9l8AZelzMJljLCKBiDstj3uEW9C0t13nAo0mdgMZsJSF75ja
-----END RSA PRIVATE KEY-----

Записываем ключ (включая строки “—-BEGIN…” и “—–END…”) в файл ~/.ec2/id_rsa-gsg-keypair:

$ cd ~/.ec2
$ cat id_rsa-gsg-keypair
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEArTGhs3XCfhkxpfos8Wd8F3HXCGd/aVK5boOafptNVcTeP6afDyY7V9CoExK4
...
cnidqNgk7bFPkKGR6mMB9l8AZelzMJljLCKBiDstj3uEW9C0t13nAo0mdgMZsJSF75ja
-----END RSA PRIVATE KEY-----
$ chmod 600 id_rsa-gsg-keypair

Разрешение сетевого доступа

Политика безопасности “default” запрещает какой-либо доступ к Instance. Для того, чтобы получить доступ к сервисам на сервере, нужно открыть по крайней мере http (для всех) и ssh (для хоста, с которого будет производиться доступ). К сожалению, у меня динамический адрес, и я для во время написания статьи открою ssh для всех адресов (а потом закрою).

$ ec2-authorize default -p 80
GROUP		default
PERMISSION		default	ALLOWS	tcp	80	80	FROM	CIDR	0.0.0.0/0

$ ec2-authorize default -p 22
GROUP		default
PERMISSION		default	ALLOWS	tcp	22	22	FROM	CIDR	0.0.0.0/0

Запуск Instance

Я буду работать с Ubuntu 9.04 Server 32 bit. 32 bit – ограничение Small Instance, так бы я использовал 64 bit. 9.04 по причине LTS (Long Term Support). Ну а Ubuntu – из-за того, что xfs работает нормально под EC2.

Образы серверов в терминах Amazon – это AMI (Amazon Machine Images). На основании AMI запускается Instance. Грубо говоря AMI – это образ на диске, а Instance – это операционная система, запущенная из этого образа. При остановке Instance все изменения теряются, поэтому нужно брать готовые AMI, запускать на их основании Instance, ставить нужные пакеты, настраивать их, а затем создавать свой AMI, и уже дальше стартовать с него. Для долгосрочного хранения данных используется “Elastic Block Storage“. AMI доступны по AMI ID.

AMI Ubuntu 9.04 описан на сайте Amazon: “Ubuntu 9.04 Jaunty Server“. Создатель – Alestic.com. Эти образы можно посмотреть на сайте. Обратите внимание, что нужно смотреть свой регион (Europe):

Итак, AMI ID Ubuntu 9.04 Jaunty server 32 bit – ami-605b7014. Для гарантии существования проверяю:

$ cd ~/.ec2
$ ec2-describe-images ami-605b7014
IMAGE	ami-605b7014	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20091011.manifest.xml	063491364108	available	public		i386	machine	aki-02486376	ari-fa4d668e

Можно также находить AMI так:

$ ec2-describe-images --all | grep -i 9.04
IMAGE	ami-98032bec	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20081222.manifest.xml	063491364108	available	public		i386	machine	aki-7e0d250a	ari-7d0d2509
IMAGE	ami-22103856	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20090215.manifest.xml	063491364108	available	public		i386	machine	aki-7e0d250a	ari-7d0d2509
IMAGE	ami-f6e1c982	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20090313.manifest.xml	063491364108	available	public		i386	machine	aki-7e0d250a	ari-7d0d2509
IMAGE	ami-dcfcd4a8	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20090329.manifest.xml	063491364108	available	public		i386	machine	aki-7e0d250a	ari-7d0d2509
IMAGE	ami-36cde542	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20090418.manifest.xml	063491364108	available	public		i386	machine	aki-7e0d250a	ari-7d0d2509
IMAGE	ami-48cfe73c	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20090423.manifest.xml	063491364108	available	public		i386	machine	aki-7e0d250a	ari-7d0d2509
IMAGE	ami-0db89079	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20090614.manifest.xml	063491364108	available	public		i386	machine	aki-7e0d250a	ari-7d0d2509
IMAGE	ami-6686ae12	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20090804.manifest.xml	063491364108	available	public		i386	machine	aki-7e0d250a	ari-7d0d2509
IMAGE	ami-605b7014	alestic-32-eu-west-1/ubuntu-9.04-jaunty-base-20091011.manifest.xml	063491364108	available	public		i386	machine	aki-02486376	ari-fa4d668e

Запускаем Instance на базе нужного AMI с использованием ранее созданного ключа id_rsa-gsg-keypair:

$ ec2-run-instances ami-605b7014 -k gsg-keypair
RESERVATION	r-02ab4575	042588059738	default
INSTANCE	i-e803f59f	ami-605b7014			pending	gsg-keypair	0		m1.small	2009-11-13T14:47:46+0000	eu-west-1a	aki-02486376	ari-fa4d668e		monitoring-disabled

Обратить внимание нужно на параметры:

• i-e803f59f – Instance ID, идентификатор запущенного сервера
• pending – ожидает запуска, обычно нужно около 15-60 секунд на запуск
• m1.small – тип Instance, small
• eu-west-1a – регион, также есть eu-west-1b. Важно обращать внимание при создании Elastic Block Store, но об этом в следующей части

Проверить статус запуска можно командой (Instance ID нужно подставить из предыдущей команды):

$ ec2-describe-instances i-e803f59f
RESERVATION	r-02ab4575	042588059738	default
INSTANCE	i-e803f59f	ami-605b7014	ec2-79-125-56-187.eu-west-1.compute.amazonaws.com	ip-10-227-53-194.eu-west-1.compute.internal	running	gsg-keypair	0		m1.small	2009-11-13T14:47:46+0000	eu-west-1a	aki-02486376	ari-fa4d668e		monitoring-disabled	79.125.56.187	10.227.53.194

• ec2-79-125-56-187.eu-west-1.compute.amazonaws.com – внешний адрес Instance, доступный через Интернет. Назначить постоянный адрес можно через “Elastic IP“, об этом тоже поговорим в другой части
• running – сервер запущен
• 79.125.56.187 – внешний адрес
• 10.227.53.194 – внутренний адрес, который транслируется во внешний для выхода в Интернет

Процесс загрузки виден в консольном выводе (да, это Xen)

$ ec2-get-console-output i-e803f59f
Linux version 2.6.21.7-2.fc8xen-ec2-v1.0 (root@domU-12-31-39-06-50-93) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #2 SMP Tue Sep 1 10:04:29 EDT 2009
...
CPU 0 irqstacks, hard=c136c000 soft=c134c000
Xen reported: 2666.762 MHz processor.
...
ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----
/etc/ssh/ssh_host_key.pub: No such file or directory
ec2: 2048 b2:14:33:14:79:14:b8:94:5d:35:78:c8:a2:6c:93:2c /etc/ssh/ssh_host_rsa_key.pub (RSA)
ec2: 1024 d9:e9:9d:33:d6:25:42:6d:08:e9:ff:0f:a5:e7:09:af /etc/ssh/ssh_host_dsa_key.pub (DSA)
ec2: -----END SSH HOST KEY FINGERPRINTS-----

Instance запущен, доступ по ssh мы открыли ранее, теперь можно зайти на сервер (ставим свой внешний адрес). Аутентификация – по публичному ключу RSA. В Amazon повёрнуты на безопасности, поэтому они даже рекомендуют отслеживать возможность атаки “man-on-the-middle” путём проверки fingerprints при входе по ssh. Поэтому стоит сравнить RSA-fingerprint, который мы видели в выводе ec2-get-console-output с тем, который отобразится при попытке входа, и только если они совпадают, то входить, написав “yes”:

$ ssh -i id_rsa-gsg-keypair root@ec2-79-125-56-187.eu-west-1.compute.amazonaws.com
The authenticity of host 'ec2-79-125-56-187.eu-west-1.compute.amazonaws.com (79.125.56.187)' can't be established.
RSA key fingerprint is b2:14:33:14:79:14:b8:94:5d:35:78:c8:a2:6c:93:2c.
Are you sure you want to continue connecting (yes/no)? yes

Вуаля, мы зашли в сервер:

Linux ip-10-227-53-194 2.6.21.7-2.fc8xen-ec2-v1.0 #2 SMP Tue Sep 1 10:04:29 EDT 2009 i686
...
Amazon EC2 Ubuntu 9.04 jaunty AMI built by Eric Hammond
http://alestic.com  http://ec2ubuntu-group.notlong.com

root@ip-10-227-53-194:~# 

Дальше нужно установить и настроить софт, после чего сделать свой AMI. Об этом – в следующей части статьи. Пока можно поиграться с сервером, помня, что ни одна настройка не сохранится после останова.

Остановка Instance

Оплата в AWS почасовая, что мобилизирует. Когда закончите развлечения с этим Instance, то, чтобы не опустошать кошелёк, нужно остановить Instance. Запустить ранее остановленный Instance нельзя.

Остановить можно или из самого Instance привычным “shutdown -h now” (-h очень важно, если его не указать, то сервер перейдёт в Single User Mode и деньги будут сниматься). Или же выйти из сервера и остановить его командой ec2-terminate-instances.

Получаем список запущенных Instance (кстати, стоит то же самое проверить и при “shutdown -h now”):

$ ec2-describe-instances
RESERVATION	r-02ab4575	042588059738	default
INSTANCE	i-e803f59f	ami-605b7014	ec2-79-125-56-187.eu-west-1.compute.amazonaws.com	ip-10-227-53-194.eu-west-1.compute.internal	running	gsg-keypair	0		m1.small	2009-11-13T14:47:46+0000	eu-west-1a	aki-02486376	ari-fa4d668e		monitoring-disabled	79.125.56.187	10.227.53.194

Останавливаем Instance (конечно же, подставляем свой instance id)

$ ec2-terminate-instances i-e803f59f
INSTANCE	i-e803f59f	running	shutting-down

Через секунд 20 проверям, остановился ли Instance:

$ ec2-describe-instances
RESERVATION	r-02ab4575	042588059738	default
INSTANCE	i-e803f59f	ami-605b7014			terminated	gsg-keypair	0		m1.small	2009-11-13T14:47:46+0000		aki-02486376	ari-fa4d668e		monitoring-disabled

Terminated – всё в порядке.

Кстати, для получения краткой справки по команде EC2 можно использовать ключ “-h”:

$ ec2-terminate-instances -h
  SYNOPSIS
     ec2kill ([ec2-terminate-instances])
     ec2kill [GENERAL OPTIONS] INSTANCE [INSTANCE [...]]
  GENERAL NOTES
     Any command option/parameter may be passed a value of '-' to indicate
     that values for that option should be read from stdin.
  DESCRIPTION
     Terminate selected running instances.
     The INSTANCE parameter is an instance ID to terminate.

  GENERAL OPTIONS

     -K, --private-key KEY
          Specify KEY as the private key to use. Defaults to the value of the
          EC2_PRIVATE_KEY environment variable (if set). Overrides the default.
	...

Деньги

Выставленные платежи можно посмотреть на странице Amazon Web Services в “Your Account”/”Account Activity”:

Но нужно дождаться завершения полного часа, у меня все сервисы по нулям:

По моей второй учётной записи, в которой я делал похожие эксперименты, статистика такая:

Итог

В этой части мы запустили свой Instance. Операционную систему можно выбирать на свой вкус, есть даже Windows, я видел Server2003r2-i386 и Server2003r2-x86_64. Mac OS X, конечно же, нет.

Как вы видите, AWS не настолько тривиален, как хотелось бы, но для нормального IT-спеца вполне подъёмен.

To be continued…

Данная тема не совсем об Apple, но меня она интересует давно, и процесс работы очень сильно завязан на работу в shell в нашей любимой Mac OS X в частности и в любом нормальном Unix в общем. Распространяться о модной теме облачных вычислений я особо не буду, здесь всё и так понятно. Я долго подходил к Amazon Web Services (AWS), но наконец-то смог более-менее разобраться с ним.

Как вы заметили, любая статья на моём сайте не абстрактное теоретизирование, а результат решения какой-либо проблемы или вопроса, который меня заинтересовал. Вот и разборки с AWS родились из того, что я решил проработать возможность переноса сайта и нескольких других задач на новый сервер. Разделяемый хостинг недолюбливаю давно, столкнувшись с реалиями локальных хостеров, считающих, что load average от 15 на хостинговом сервере – это нормальная ситуация в расчёте на то, что “пипл всё схавает”. VPS не нравится почти по той же причине, плюс некоторые проблемы с актуальностью операционных систем (не знаю, как сейчас, но лет 5 назад версии OS в VPS очень отставали). Арендовать выделенный сервер достаточно дорого – минимальная конфигурация, которая устраивает меня, стоит от $100 в месяц (тариф “Профи” у Воли – 799 грн), причём я бы добавил ещё 2 GB памяти (+ 98 грн в месяц).

И вот, читая Release Notes Ubuntu 9.10, я вспомнил о том, что давно хотел повозиться с AWS, а именно с Amazon Elastic Compute Cloud (Amazon EC2). Характеристики Standard Small Instance (1.7 GB of memory, 1 EC2 Compute Unit – 1 virtual core with 1 EC2 Compute Unit, 160 GB of instance storage, 32-bit platform) со скрипом, но устраивали, а возможность динамически менять производительность с использованием технологии Auto Scaling меня очень привлекла. Технология облачных вычислений очень интересная, и есть несколько идей по поводу их практического применения, в итоге я решил если не перейти на AWS, так хотя бы плотно с ним поработать. Стоимость решения примерно должна стоить в районе $80 в месяц – небольшая экономия по сравнению с выделенным сервером, но повозиться интересно.

Хочу сразу предупредить – я запускал сервера всего на час-два, поэтому суммарную стоимость для реального сайта я сказать пока не могу. Кроме позитивных отзывов есть и мнение, что AWS избыточно дорога, и в долгосрочной перспективе лучше иметь выделенные сервера (например, об этом говорил @umputun, ссылаясь на опыт своего знакомого). Также есть огромное неудобство EC2 – без использования дополнительных техник данные при перезагрузке Instance теряются. Но лучше о технологии судить на основании своего, а не чужого опыта, тем более, что эксперименты будут стоить долларов 10.

Я разобью статью на несколько частей. В первой расскажу о создании учётной записи, во второй – о создании серверов, а в третьей – об Amazon Elastic Block Store.

Никаких особенностей при создании учётной записи AWS нет, но для полноты картины покажу весь процесс. Я использовал обычную карту Master Card, без проблем принимаются карты, эмитированные локальными банками – ограничения “USA only” в сервисе нет.

Создание пользователя:

Выбираем активацию Amazon Elastic Compute Cloud (EC2):

Вводим информацию по карте (не знаю, какую сумму заблокирует для проверки, так как для используемой мной карты нет информации по транзакциям):

Дальше начинается самое интересное – в отличие от привычной проверки email необходимо проверить номер телефона – иначе система не активирует запись. Код страны выбирается из выпадающего списка, в текстовом поле нужно ввести данные без этого префикса:

Генерируется PIN-код, IVR Amazon через несколько секунд перезванивает (номер звонящего скрывается) и робот просит ввести PIN или медленно его продиктовать

При успешной верификации обновляется статус:

Активацию нужно завершить:

Затем войти в EC2:

Подписка завершена, можно посмотреть информацию по “Security Credentials”:

Здесь показывается Access Key ID, а для отображения секретного ключа нужно нажать Show

Для доступа к AWS нужно сгенерировать сертификат X.509 (это сделаем в следующей части)

Также нужно со страницы AWS активировать Amazon Simple Storage Service (Amazon S3):

Всё, нужные сервисы активированы. В почтовом ящике лежат три письма от Amazon, они особо не нужны. Главное, что нужно запомнить – информация по учётной записи находится в меню Account на главной странице AWS:

To be continued…

Кстати, мне порекомендовали две фирмы, дающие Mac mini в аренду для хостинга: iWeb (ссылка от @gothy) и macminicolo.net (ссылка от @lvader).

А пока попытаюсь понаслаждаться картинами Mac mini в качестве серверов.