Я пытаюсь настроить среду разработки Linux, чтобы я мог безопасно вносить изменения в свой веб-сайт, не нарушая работоспособность сайта.
На Линоде находится мой действующий сайт. Простым решением было бы разместить мой сервер разработки на Linode, но я хочу избежать удвоения затрат на хостинг.
Самый дешевый способ, который я вижу, - использовать Vagrant на моей рабочей станции Windows для размещения моей среды разработки.
После того, как я попытаюсь восстановить резервную копию в Vagrant и перезагрузить виртуальную машину, я больше не могу использовать ssh на хосте Vagrant.
Вероятно, это потому, что, восстанавливая резервную копию, я перезаписываю какую-то особую конфигурацию Vagrant, но я не уверен, как этого избежать.
Как заставить этот подход работать? Если мой подход в корне неверен, можете ли вы предложить альтернативу?
На Linode я использовал эти команды для создания сжатой копии всей файловой системы, игнорируя при этом вещи, которые не должны быть включены в резервную копию:
$ sudo rsync -ahvz --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/backup/*} /* /backup/2
$ sudo tar -czf /backup/2.gz /backup/2
Файл резервной копии называется 2.gz потому что это вторая резервная копия. Первая резервная копия называется 1.gz.
Я использую WinSCP для копирования файла резервной копии на свою рабочую станцию Windows.
Мне нужен Vagrant box, соответствующий моей операционной системе Linode (Ubuntu 12.04.3 LTS, ядро 3.9.3). Я выбрал подходящий шкаф из vagrantbox.es:
Ubuntu Server Precise 12.04.3 amd64
Ядро готово для Docker (Docker не входит в комплект)
На своей рабочей станции я выполнил следующие команды, чтобы добавить ящик, инициализировать и загрузить экземпляр:
$ vagrant box add ubuntu-precise http://nitron-vagrant.s3-website-us-east-1.amazonaws.com/vagrant_ubuntu_12.04.3_amd64_virtualbox.box
$ mkdir linode-test
$ cd linode-test
$ vagrant init ubuntu-precise
$ vagrant up
Теперь Vagrant запускает машину с SSH на порту 2222.
Версия операционной системы такая же. Версия ядра - 3.8.0. Звучит достаточно близко.
С WinSCP скопировал файл резервной копии 2.gz к /home/vagrant/2.gz на коробке Vagrant.
С помощью PuTTY я подключился через ssh к моему новому ящику Vagrant:
В коробке переместите резервную копию в корень файловой системы.
$ sudo mv 2.gz /
Распакуйте архив в корень файловой системы:
$ sudo tar -xvpz -f 2.gz -C / --strip-components=2
(Я обнаружил, что мне нужно использовать компоненты полосы, потому что все файлы в архиве имеют префикс backup/2/. Я исправлю это для следующего бэкапа.)
После завершения команды tar я выхожу из коробки.
Когда я пытаюсь войти снова, это больше не позволяет мне войти в систему как бродяга с паролем.
Это позволяет мне войти в систему как iain, мой пользователь на Live Linode, с паролем. Это меня удивило, потому что я отключил аутентификацию по паролю на своем живом Linode. Я решил, что мне нужно перезапустить службу ssh, чтобы изменения вступили в силу.
Вместо перезапуска только ssh я решил перезапустить всю систему.
Теперь я даже не могу попасть на экран входа в систему. PuTTY сообщает, что "соединение отклонено", когда я пытаюсь подключиться.
Что пошло не так?
Причина, по которой вы больше не можете войти в систему как бродяга, заключается в том, что вы создали резервную копию / etc, который содержит тень. Поскольку теневой файл из linode не содержит записи для бродячего пользователя, он не позволит вам войти в систему с этими учетными данными. Вы можете войти в систему, используя своего пользователя linode, потому что учетные данные находятся в файле / etc / shadow, но демон ssh использовал настройки по умолчанию, которые разрешают аутентификацию по паролю для всех. Если все в порядке, вы можете просто перезагрузить службу ssh, чтобы получить новую конфигурацию (ту из резервной копии, которая отключает аутентификацию по паролю).
Однако во время восстановления должно быть что-то пошло не так. Из предоставленной информации я могу только делать предположения относительно того, что, и я бы хотел избежать этого. Однако, если вы откроете окно управления виртуальным ящиком с выключенным бродячим ящиком, вы сможете запустить виртуальную машину в обычном режиме. Это позволит вам увидеть любые ошибки, представленные в консоли. Если ошибок нет, это, по крайней мере, позволит вам войти в систему с помощью консоли (в отличие от SSH). Вы можете использовать свою обычную учетную запись, чтобы получить доступ и посмотреть, что не так. Что-то в / var / log укажет вам правильное направление (скорее всего, / var / log / syslog).
После небольшой настройки вы, вероятно, получите свой подход в основном к работе, но я предлагаю совершенно другой подход.
Чтобы синхронизировать общую конфигурацию рабочего сервера и сервера разработки, либо используйте марионетку для развертывания, либо просто будьте очень осторожны. Для синхронизации вашего веб-кода и загруженных файлов rsync подходит, определите, что вы хотите включить, и ограничьте его. Только приложение, а не вся система. Вместо использования rsync вы можете использовать git или другую систему контроля версий. Зарегистрируйте изменения от разработчика, а затем проверьте их вживую. Где-то в будущем вы можете автоматизировать это с помощью системы непрерывного развертывания.
Возможно, вам также понадобится способ синхронизации содержимого базы данных. Не рассчитывайте просто на копирование файлов, в которых mysql хранит свои данные, если только вы не готовы отключить движки базы данных на обоих концах, пока вы это делаете, или у вас есть какой-то механизм моментальных снимков на уровне файловой системы (например, используя LVM).
Возможно, вы захотите объединить синхронизацию обновлений данных от live до dev с вашей системой резервного копирования. т.е. взять резервные копии живых и восстановить их на dev. Это хорошо, потому что вы постоянно проверяете свои резервные копии, но если вы выполняете резервное копирование ежедневно, восстановление вчерашней резервной копии иногда может оказаться неудобно устаревшим.
Может быть, это перебор. Хотя, наверное, кажется, что это немного больше, чем на самом деле сейчас. По крайней мере, понимайте модель как нечто, к чему нужно двигаться со временем.