Я решил поиграть с последним предложением AWS «OpsWorks» и посмотреть, справились ли они со всеми нами без работы. Ну, вроде.
OpsWorks это интересно. В основном это шеф-повар с интеграцией в EC2. Непосредственными «недостатками» для некоторых является то, что есть только два поддерживаемых дистрибутива: Ubuntu 12.04 LTS и Amazon Linux. Это также невероятно грубо по краям.
Это легко зарегистрироваться, и это добавляет сервис к консоли управления AWS.
Первое, что нужно сделать, это добавить стек.
Дополнительные параметры скрывают возможность использования пользовательских поваренных книг шеф-повара и большого количества пользовательских JSON для шеф-повара:
Стек формируется из слоев, которые представляют сервисы.
Я собираюсь создать простое приложение Rails для моего первого слоя:
Это параметры шаблона по умолчанию для слоев:
Вот что вы увидите, если выберете MySQL Database Layer:
Следующим шагом является настройка и экземпляр ваших слоев.
Самое неприятное, что нет возможности использовать экземпляры Micro для ваших экземпляров. Какой тип побеждает возможность использовать OpsWorks в пакете бесплатного использования.
Я выбрал экземпляр на основе времени, и вы получите вот эту вещь:
Это немного смутило меня, потому что, если вы попытаетесь загрузить его сейчас, вы застрянете в цикле загрузки, он будет загружаться, запускаться и завершаться до бесконечности.
Это потому, что эта серая полоса кликабельна, поэтому вы можете установить желаемое время, когда она будет доступна.
Теперь мы можем определить приложение для развертывания:
Я создал новый git-репозиторий и использовал там `rails new shortbread-beastie ‘.
https://github.com/tomoconnor/shortbread-beastie
Существует несколько различных вариантов развертывания: Git, SVN, S3 bundle и HTTP bundle, а также «Other» — я понятия не имею, что другое делает или для чего используется, если только нет возможности указать где-нибудь сценарий развертывания.
Вернемся к представлению Instances, и это довольно блестяще.
Следующим шагом является создание Deployment, когда у вас есть работающий экземпляр:
Это, однако, где проблемы начинаются. Для развертывания вам нужен работающий экземпляр.
Итак, я установил некоторое время для доступности экземпляра и нажал на запуск. Тогда это не удалось.
Я прекратил это, но оно не умерло. Это просто загрузил еще один.
Самое раздражающее. Я не могу прекратить его, потому что он идет «загрузить, остановить, прекратить» — и затем повторяется. Я могу удалить приложение, но могу ли я удалить экземпляр? Видимо нет, потому что это не остановлено. Это навсегда загрузка.
Могу ли я удалить слой? Нет.
Я также не могу удалить стек.
Итак, у меня есть сломанная конфигурация OpsWorks Stack, Instance и Layer. Просто используя значения по умолчанию. Они не шутили, когда сказали, что это Бета. Интересно, что все поваренные книги шеф-поваров с открытым исходным кодом на Github: https://github.com/aws/opsworks-cookbooks
Эта небольшая часть чудес скрыта под настройкой Layer для уровня Rails Server. Эти определения Chef Cookbook являются ссылками GitHub
Вы также можете настроить его для добавления других пакетов ОС, монтирования томов EBS и так далее.
И установите группы безопасности, если они отличаются от исходных значений по умолчанию.
Я создал запрос на поддержку на форумах AWS, и менее чем через час на него обратился инженер AWS. Я не могу ждать, чтобы увидеть, что они находят. https://forums.aws.amazon.com/thread.jspa?threadID=117185&tstart=0
Часть 2
Я планировал сделать еще один шаг с нуля, как только команда AWS очистит разбитый экземпляр. После того, как я заметил, что они уничтожили экземпляры из моей учетной записи OpsWorks. Я не был полностью уверен, что привело к тому, что первый сломался таким катастрофическим образом, но я просто построил еще один из настроек по умолчанию. Вот как это развернулось.
Время новой инстанции!
Ну, этот бит сработал, мы должны попробовать его, действительно
Процесс настройки занял около 10 минут, прежде чем потерпел неудачу, хотя и немного менее катастрофично, чем в прошлый раз.
Interestingly, this time it had failed, it was at least running. I had a quick look for the log files generated, but got this message:
However! After I ssh’d in, I had a look in the usual places for something log-worthy.
/var/log/cloud-init.log /var/log/aws/opsworks/ installer.log opsworks-agent.log user-data.log
None of which contained any errors. I had a look through /var/log/secure to see what it was doing, and found the location of the chef files/JSON/logfiles, and found this:
/var/lib/aws/opsworks/chef/2013-02-19-16-00-48-01.log
Which contained the following interesting nuggets
[Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: ---- Begin output of grep '/^StrictHostKeyChecking no$/' /home/deploy/.ssh/config ---- [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: STDOUT: [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: STDERR: [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: ---- End output of grep '/^StrictHostKeyChecking no$/' /home/deploy/.ssh/config ---- [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: Ran grep '/^StrictHostKeyChecking no$/' /home/deploy/.ssh/config returned 1 [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: Executing echo 'StrictHostKeyChecking no' > /home/deploy/.ssh/config [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: ---- Begin output of echo 'StrictHostKeyChecking no' > /home/deploy/.ssh/config ---- [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: STDOUT: [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: STDERR: [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: ---- End output of echo 'StrictHostKeyChecking no' > /home/deploy/.ssh/config ---- [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: Ran echo 'StrictHostKeyChecking no' > /home/deploy/.ssh/config returned 0 [Tue, 19 Feb 2013 16:09:08 +0000] INFO: Ran execute[echo 'StrictHostKeyChecking no' > /home/deploy/.ssh/config] successfully [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: Processing template[/home/deploy/.ssh/id_dsa] on cupcake.localdomain [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: Skipping template[/home/deploy/.ssh/id_dsa] due to not_if [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: Processing directory[/srv/www/shortbread_beastie/shared/cached-copy] on cupcake.localdomain [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: Processing ruby_block[change HOME to /home/deploy for source checkout] on cupcake.localdomain [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: Processing deploy[/srv/www/shortbread_beastie] on cupcake.localdomain [Tue, 19 Feb 2013 16:09:08 +0000] INFO: deploying branch: HEAD [Tue, 19 Feb 2013 16:09:08 +0000] INFO: ensuring proper ownership [Tue, 19 Feb 2013 16:09:08 +0000] INFO: updating the cached checkout Tue, 19 Feb 2013 16:09:08 +0000] INFO: Cloning repo git@github.com:tomoconnor/shortbread-beastie.git to /srv/www/shortbread_beastie/shar ed/cached-copy [Tue, 19 Feb 2013 16:09:08 +0000] DEBUG: Executing git clone --depth 5 git@github.com:tomoconnor/shortbread-beastie.git /srv/www/shortbre ad_beastie/shared/cached-copy [Tue, 19 Feb 2013 16:09:09 +0000] DEBUG: ---- Begin output of git clone --depth 5 git@github.com:tomoconnor/shortbread-beastie.git /srv/w ww/shortbread_beastie/shared/cached-copy ---- [Tue, 19 Feb 2013 16:09:09 +0000] DEBUG: STDOUT: Cloning into /srv/www/shortbread_beastie/shared/cached-copy... [Tue, 19 Feb 2013 16:09:09 +0000] DEBUG: STDERR: Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts. Permission denied (publickey). fatal: The remote end hung up unexpectedly [Tue, 19 Feb 2013 16:09:09 +0000] DEBUG: ---- End output of git clone --depth 5 git@github.com:tomoconnor/shortbread-beastie.git /srv/www/shortbread_beastie/shared/cached-copy ---- [Tue, 19 Feb 2013 16:09:09 +0000] DEBUG: Ran git clone --depth 5 git@github.com:tomoconnor/shortbread-beastie.git /srv/www/shortbread_beastie/shared/cached-copy returned 128 [Tue, 19 Feb 2013 16:09:09 +0000] ERROR: deploy[/srv/www/shortbread_beastie] (/opt/aws/opsworks/releases/20130218135253_103/cookbooks/deploy/definitions/opsworks_deploy.rb:60:in `from_file') had an error: git clone --depth 5 git@github.com:tomoconnor/shortbread-beastie.git /srv/www/shortbread_beastie/shared/cached-copy returned 128, expected 0 ---- Begin output of git clone --depth 5 git@github.com:tomoconnor/shortbread-beastie.git /srv/www/shortbread_beastie/shared/cached-copy ---- STDOUT: Cloning into /srv/www/shortbread_beastie/shared/cached-copy...STDERR: Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts. Permission denied (publickey). fatal: The remote end hung up unexpectedly
Could it be? Has the github deploy ssh key problem hit the almighty AWS too? Looks like it. A good question however, is why on earth does the precursor,
execute[echo 'StrictHostKeyChecking no' > /home/deploy/.ssh/config]
which was completed sucessfully, not prevent this from happening?
So, I changed the app git repository from a git@github SSH style one to a git://github.com/tomoconnor/shortbread-beastie.git, which shouldn’t need to add a SSH key to the known_hosts file. In 10 — 15 minutes, it should have re-run setup, and all that, and we should have either a working instance, or another failure.
Bugger me. It worked.
Here’s a screengrab of it running in chrome live on the EC2 cloud. I actually killed it off a few minutes ago, as it’s costing me money.
Looks so far like the big bugs concern the SSH Host Key acceptance thing that I found, and the fact that if you disturb the running EC2 instances from the EC2 control panel (which I accidentally did), then the OpsWorks side loses touch with the EC2 side, and the whole thing goes into that boot-stop-terminate-boot loop.