В первой части статьи я описал создание учётной записи на 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`’, но так гораздо удобнее):
Для того, чтобы переменные окружения установились, можно или создать новую сессию в 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 – это упрощает некоторые операции.
Политика безопасности “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-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 можно использовать ключ “-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-спеца вполне подъёмен.
В данном случае учитывается время работы машины? То есть запустил, к примеру убунту, она крутиться, пусть даже ничего не делает, а время идет. Так?
Или же учитывается время затрат ресурсов? То есть, если задействован процессор, грубо говоря, то идет учет времени.
http://high-sale.ru ctrld
Именно поэтому я и отказался от Amazon – счётчик включается со стартом машины, заканчивается с её остановом. А процессорная мощность зависит от типа Instance, и от типа Instance зависит стоимость за час работы машины.
В общем я перешёл на VPS https://www.linode.com/, а если понадобится большая мощность, то возьму в аренду сервер на http://www.hetzner.de/
http://www.juev.ru Juev
Очень жаль. Сделали бы расчет по мере использования ресурсов, клиентов больше было бы. А так выходит, что его для хостинга использовать не выгодно. Для расчетов куда не шло.
Спасибо за рекомендации!
http://www.juev.ru Juev
Кстати, не скромный вопрос, какой тариф на linode используете? И какая примерно посещаемость? Используете ли PHP eaccelerator или APC??
http://high-sale.ru ctrld
Я взял самый дешёвый тариф – 512 MB RAM, его вполне хватает. Для кеширования, как и Вы, использую W3 Total Cache + memcached (от CloudFront отказался).
Посещаемость: 450 уникальных посетителей в сутки + 800 RSS.
Ресурсов хватает :-)
http://www.juev.ru Juev
Спасибо большое!
http://www.juev.ru Juev
Кстати, я пока еще не решил, на чем остановиться на линоде или медиатемпле. Если есть реферальная ссылка от линода, давайте, если остановлюсь на нем, зарегистрируюсь по ссылке.
И еще вопрос, на линоде оплата ежемесячно или сразу за год?
http://high-sale.ru ctrld
О, а я об этом даже не задумывался :-) Нашёл такую возможность. Вот моя реферальная ссылка Linode (вдруг пригодится): http://www.linode.com/?r=dc1dd219d560a964281d777ad34a62af288a1de8
Оплата ежемесячная, но можно заплатить за 12 months (10% discount) и за 24 months (15% discount). Setup Fee вроде нет, я не помню такого.
http://www.juev.ru Juev
Спасибо! Теперь осталось решить, что выбрать. Линоду или медиатемпле. =)
У медиатемпле думаю, что выбрать gs (по стоимости тоже выходит, что и линоде) или ve (новая услуга у них)…
http://high-sale.ru ctrld
ve построен на базе Virtuozzo. Это “лёгкая” виртуализация, при которой библиотеки разделяются между разными виртуальными машинами (наподобие jail в FreeBSD). Российская разработка, Parallels (ex SWSoft): http://www.parallels.com/ru/products/pvc45/
Когда я с ней работал, то был нюанс – устанавливались только специальным образом подготовленные пакеты (тогда не было проблем с обновлением, портированием и т.п.). Или из исходников.
gs, насколько я понял, это традиционный web-хостинг.
Если бы я выбирал из двух и не смотрел бы на цену, то остановился бы на ve.
Но dv лучше. Это уже полноценная виртуальная машина. Цена хуже, чем Linode ($50 против $20 за подобную конфигурацию).
http://www.juev.ru Juev
Спасибо за разъяснения!!
Встало более менее на свои места. Правда gs не совсем обычный хостинг, это можно сказать продвинутый хостинг. Судя по всему с расширенными ресурсами.
Значит остается только Линода и gs…