Как вы управляете своими блоками EC2 Linux?

У меня есть несколько образов EC2 Linux, которые выполняют ночные задания для одного из моих проектов. Время от времени мне нужно будет входить, вносить некоторые изменения в код, настраивать некоторые вещи и повторно связывать изображение.

Мой набор инструментов для этих операций крайне редок (SSH в коробке, редактируйте файлы в VIM, удаленные файлы WGET, которые мне нужны), и я подозреваю, что есть гораздо лучший способ сделать это. Мне любопытно услышать, что делают другие люди в моем положении.

• Используете ли вы какую-либо форму оконной системы и эквивалент удаленного рабочего стола для доступа к блоку, или это все из командной строки? Управление коробками EC2 для Windows тривиально, так как вы можете просто подключиться к удаленному рабочему столу и передавать файлы по сети. Есть ли эквивалент в этом в мире Linux?

• Вы вносите изменения в конфигурацию / скриптовые настройки прямо на машине? Или у вас есть что-то настроенное на вашем локальном ящике для удаленного редактирования этих файлов? Или вы просто редактируете их удаленно, а затем переносите их при каждом сохранении?

• Как вы перемещаете файлы назад и вперед между EC2 и вашей локальной средой? FTP? Какой-то Mapped Drive через VPN?

Мне действительно нужно получить некоторые лучшие практики для администрирования этих ящиков. Любые предложения, чтобы снять часть боли будет приветствоваться!

РЕДАКТИРОВАТЬ: Очевидно, я не был ясно выше, так как первые два ответа вращались вокруг управления и настройки экземпляров EC2. Я просто хочу узнать, как сделать удаленный рабочий стол работающим сервером Linux, чтобы перемещать файлы и редактировать их было менее болезненно.

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

• Ruby (мой любимый язык сценариев / инструментов)
• Git (контроль версий)
• Повар Opscode (написанный на Ruby) (1)
• Capistrano (специальное массовое обслуживание)
• Инструменты Amazon EC2 API для поддержки экземпляров и изображений.
• Драгоценный камень AWS от RightCale (привязки Ruby для EC2)

(1) - Раскрытие, я работаю на Opscode. Другие инструменты заполняют это пространство, как «Кукольный» в «Редуктивной лаборатории»

Я связываю AMI, когда у меня есть узел, построенный так, как мне нужно для конкретной функции. Например, если я собираю сервер приложений Rails, я установлю все необходимые пакеты, чтобы сэкономить время на сборку.

Когда все остальное терпит неудачу, я вхожу в системы с SSH. Я много лет занимался ручным системным администрированием, это старая шляпа.

Используете ли вы какую-либо форму оконной системы и эквивалент удаленного рабочего стола для доступа к блоку, или это все из командной строки?

Я не устанавливаю никакой графический интерфейс на серверах, если пакет не имеет зависимости, а один автоматически устанавливается.

Есть ли эквивалент в этом в мире Linux? (передача файлов)

Я обычно делаю два типа передачи файлов / обслуживания файлов.

• Установка пакета
• Конфигурационные файлы

Для пакетов, встроенных в платформу, я использую стандартный инструмент управления пакетами, такой как APT или YUM. Для исходных установок (thing.tar.gz) я обычно скачиваю через wget.

Файлы конфигурации обычно представляют собой шаблоны ERB, управляемые Chef.

Я использую SSH и SCP / SFTP для передачи файлов вручную.

Вы вносите изменения в конфигурацию / скриптовые настройки прямо на машине? Или у вас есть что-то настроенное на вашем локальном ящике для удаленного редактирования этих файлов? Или вы просто редактируете их удаленно, а затем переносите их при каждом сохранении?

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

• Извлеките из основного репозитория Git для других изменений.
• Редактировать файл (ы) локально (например, обновить файл конфигурации).
• Подтвердите изменение, нажмите, чтобы освоить.
• На сервере Chef (авторизованном через SSH) извлеките последние внесенные мною изменения.
• Разверните конфигурацию в соответствующем месте на сервере Chef (для этого я использую Rake).
• Клиенты Chef работают с интервалом, поэтому они будут получать изменения каждые 30 минут. Если мне что-то нужно немедленно, я запускаю chef-client вручную.
• Проверьте изменение!

Как вы перемещаете файлы назад и вперед между EC2 и вашей локальной средой? FTP? Какой-то Mapped Drive через VPN?

Есть несколько мест, где могут храниться файлы, которые я использую на узлах EC2.

• Шеф-сервер. Шаблоны конфигурации в основном, небольшие пакеты тоже.
• GitHub. Мы храним наш код (проекты с открытым исходным кодом) на GitHub. Узлы EC2 могут легко добраться до этого (например, для проверки последней версии чего-либо).
• Amazon S3 ведра. Некоторые вещи хранятся в ведре.

Я много работаю в EC2, в основном тестирую среды и изменения. Благодаря моим инструментам и рабочему процессу, я трачу больше времени на работу над тем, что мне действительно нужно, и меньше на работу с отдельными файлами и на размышления о конкретных конфигурациях.

Все наше программное обеспечение развернуто через RPM. Каждый тип экземпляра EC2 описывается файлом кикстарта (в котором перечислены RPM для установки ...). Настройка кикстарта означает, что работающий компьютер каждого типа экземпляра может быть собран с нуля примерно за 10 минут.

Затем у нас есть программа, которая вызывает anaconda (установщик Red Hat) для создания файла кикстарта, установки системы в каталог, затем связывания каталога и передачи его на S3 в качестве образа машины Amazon. Это все один шаг, поэтому я просто набираю:

kickstart2ami webserver.ks

Поскольку машина может быть полностью перестроена, загружена и запущена примерно за 40 минут, проще создавать новые образы машин, чем выполнять sysadmin на реальных (одноразовых) экземплярах EC2. Таким образом, на экземплярах EC2 фактически не выполняется sysadmin.

Мне нравится NX для удаленного доступа к графическому интерфейсу. Очень хорошо задокументировано тоже.

Я использую nautilus для управления файлами и ssh для команд. Он подключается прямо к вашей системе, как если бы вы были физически в центре обработки данных. Если вы делаете это из окна Windows, то такой тип подключения не будет работать, поскольку VFS в Windows ограничены.

Я думаю, вам не нужен удаленный рабочий стол для этих задач.

Как уже упоминалось, вы можете использовать SFTP для передачи файлов между ящиками. Используйте WinSCP-клиент для подключения через sftp, который вы также можете использовать для редактирования файлов на вашем компьютере с Windows (двойным щелчком по ним), как если бы он находился на вашем локальном компьютере. Вы также можете использовать его для удаленного копирования / перемещения файлов.

Вы также можете использовать Midnight Commander (mc) в консоли ssh, чтобы ускорить файловые операции. Для установки используйте команду yum install mcили apt-get install mc. После этого вы можете запустить его, набрав mcв терминале. Он также имеет встроенный просмотрщик и редактор, который более прост, чем vim.

Если вы действительно хотите иметь графический интерфейс пользователя - которого у нас обычно нет на серверах - вам нужно установить среду X и подключиться к ней с помощью VNC. В таких случаях мы подключаемся к VNC-серверу через ssh-туннель, что повышает его безопасность.

В ответ на ваш вопрос о настройке удаленного рабочего стола с X, если вы используете Debian, прочитайте это . Это не самый лучший документ по настройке. Он устанавливает слишком много пакетов, но у него есть правильная идея. Вам действительно нужен только фиктивный видеодрайвер для X, а затем VNC запускает рабочий стол X.

Если вы используете Ubuntu: мы рассматриваем использование ландшафта для этого, это коммерческий продукт команды Ubuntu (канонический), и он будет интегрирован с командами ec2.

Вы можете попробовать что-то вроде capistrano, но если этого не достаточно для того, что вам нужно, то кажется, что вы являетесь кандидатом на какое-то управление конфигурацией.
Puppet, reductivelabs.com/products/puppet/, действительно выделяется в этой области, но может быть немного излишним для вас, если у вас нет планов стать больше, и тогда это стоит тяжелой работы.
Если вы используете один из дистрибутивов Debian / Ubuntu, то я бы выбрал Slack Roles.
Это модная оболочка для скриптов rsync и и shell. У этого очень мало начального обучения, и он хорошо работает, однако, когда вы растете, он может стать немного сложным.