Развертывание веб-приложения PHP включает в себя либо загрузку файлов на сервер через FTP, либо фиксацию и отправку в главную ветку репозитория Git . В этом нет ничего сложного. Развертывание приложения Rails легко в соответствии с официальной документацией Rails. Как бы я ни любил официальные документы, они неправильно поняли эту часть. Развертывание приложения Rails может быть огромной головной болью, не в последнюю очередь потому, что вариантов так много.
В конце концов, это сводится к двум вещам: вы можете либо развернуться в облачной службе, где за большинством сложных вещей заботятся о вас, либо для большего контроля вы можете развернуть на виртуальном частном сервере (VPS). Мы рассмотрим оба варианта в этой серии.
Развертывание в облаке
Мы выберем Heroku в качестве нашего облачного варианта, поскольку он очень популярен для развертывания приложений Rack и Rails. Вы развертываете в Heroku, отправляя изменения в пульт Git, которые Heroku предоставляет вам при первом создании приложения в их службе.
Это должно показаться знакомым для PHP-кодеров, переходящих на ruby, особенно если вы использовали облачную платформу, например, phpfog .
Чтобы запустить приложение Rails на Heroku, необходимо выполнить несколько шагов:
- Разработайте свое приложение (дох!)
- Зарегистрируйтесь в Heroku, если вы еще этого не сделали
- Инициализировать Git для вашего проекта
- Создать приложение Heroku
- Добавьте пульт Git для Heroku (например, у вас может быть удаленное хранилище Github)
- Вставьте ваше приложение в Heroku
- Перенос базы данных (если вы ее используете)
Выбор базы данных
Heroku не поддерживает Sqlite, поэтому, если ваше приложение использует его, Heroku будет жаловаться. Heroku использует отличный Postgresql . Во время первоначального развертывания вашего приложения вы можете запустить миграцию, чтобы заполнить базу данных Heroku Postgresql. Если вы перешли на разработку с использованием Rails из PHP, вы привыкнете к MySQL. В этом случае вам нечего бояться Postgresql. В последнее время он приобрел популярность среди разработчиков Rails, поэтому к нему стоит привыкнуть.
Если вы все еще рассматриваете возможность использования Sqlite, эта статья о центре разработки Heroku должна помочь вам в этом.
Начать …
Итак, ваше приложение находится в точке, где оно может быть отправлено в Heroku. Превращение его в приложение Heroku — это всего лишь случай попадания в командную строку / терминал. Измените каталог на свой проект и убедитесь, что вы зафиксировали все свои последние изменения. Тогда просто сделайте:
heroku create Следующее, что произойдет, — Heroku ответит, сообщив, что ваше приложение создано. Весьма вероятно, что у него будет странное имя (например, infinite-escarpment-4759), но мы можем это изменить в ближайшее время. Вам также скажут, что ваш удаленный URL Git для Heroku. Хорошая вещь в этом заключается в том, что вы можете отправить свои изменения, например, в Github, а затем, когда вы будете готовы к развертыванию, вы можете перейти в свою ветку Heroku.
Изменение имени приложения
Предполагая, что вы хотите, чтобы это приложение имело реальную цель, а не только для тестирования, вы захотите использовать для него разумное имя. Вернемся к командной строке:
heroku apps:rename new_name_here
Приятно то, что ваш пульт Git будет автоматически обновляться. Если вы используете веб-сайт Heroku для переименования своего приложения, вам необходимо удалить старый пульт Heroku и добавить новый:
git remote rm heroku git remote add heroku git@heroku.com:newname.git
Если у вас есть доменное имя, которое вы хотите использовать для своего приложения, вернитесь в командную строку и выполните:
heroku domains:add www.mydomain.com
Далее мы развернем.
Развертывание приложения
Все, что вам нужно сделать, это:
git push heroku master
Вы увидите, как Heroku проходит через целый ряд процессов, включая rake assets:precompile Когда он закончится, вы увидите что-то вроде: http://yourapp.herokuapp.com deployed to Heroku Большой! Ох, подожди минутку, хотя …
База данных
Вы также можете развернуть свои миграции. Вернемся к командной строке:
heroku run rake db:migrate
Вы можете увидеть предупреждение об устаревании плагинов вендора / плагинов. Вы можете спокойно игнорировать предупреждение, если знаете, что ничего не сделали с плагинами.
Это все люди …
В самом деле. Вот и все, ваше приложение должно быть запущено. Единственная проблема с Heroku: бесплатная версия — отличный сервис. Однако, если вам нужно добавить больше ресурсов, это может стать довольно дорогим. Не говори, что я тебя не предупреждал …
Развертывание на виртуальном частном сервере (VPS)
Другой вариант — купить себе VPS и развернуть на нем свое приложение. Тот, который я использую здесь, называется Linode . Первое, на что я должен обратить внимание, это то, что если настройка серверов вам не подходит, выберите Heroku.
Когда вы регистрируетесь в Linode, вы можете выбрать (Linux) серверную операционную систему. У них есть Ubuntu, Fedora, OpenSUSE и т. Д., Поэтому ваш любимый, вероятно, будет поддерживаться. Также возможно создать и разрушить, если вы ошибетесь. На самом деле, это поощряется на Линоде. Так что, если вы Linux n00b, есть много помощи и поддержки.
Когда ваш сервер настроен, это необработанная базовая установка сервера. Это означает, что для запуска и запуска Rails-приложения вам сначала потребуется выполнить некоторую установку. О, и если вам интересно, нет, нет графического интерфейса. Это командная строка полностью.
Стек производства
У вас есть варианты здесь. В итоге я выбрал Nginx для веб-сервера, PostgreSQL для базы данных и rbenv для управления версиями Ruby. Вы также можете легко выбрать Apache , Phusion Passenger и MySQL . Я сделал этот выбор, потому что уже работал с Phusion Passenger и RVM и хотел попробовать другие варианты.
После настройки Linode войдите в систему через SSH. Ваша панель управления Linode содержит всю информацию, необходимую для этого:
ssh root@176.xxx.xxx.xxx
Вы должны запустить обновление дистрибутива и установить все, что требуется в первую очередь. Затем установите компоненты производственного стека. Если вы используете Ubuntu, установите опцию свойств программного обеспечения, чтобы упростить добавление новых репозиториев в apt:
apt-get -y install curl git-core python-software-properties
Затем вы можете добавить стабильную ветку для Nginx:
add-apt-repository ppa:nginx/stable
Независимо от вашего дистрибутива вам необходимо установить:
- Nginx или Apache
- MySQL или PostgreSQL
- Также установите node.js, пока вы находитесь там, чтобы у вас был способ выполнить Javascript.
- Вам также нужно будет установить Git и Curl.
Установить Ruby через rbenv проще, если вы используете скрипт установщика:
curl -L https://raw.github.com/fesplugas/rbenv-installer/master/bin/rbenv-installer | bash
Вам будет предложено скопировать некоторые строки в ваш файл .bashrc, поэтому убедитесь, что вы это делаете. То, где вы их копируете, тоже немного глупо. Строки должны идти выше этой строки в вашем файле .bashrc:
# If not running interactively, don't do anything [ -z "$PS1" ] && return
Это сделано для того, чтобы rbenv работал с развертываниями Capistrano, о которых мы вскоре поговорим. Вам необходимо перезагрузить файл .bashrc сейчас: ~/.bashrc На этом этапе команда rbenv будет доступна в командной строке и может использоваться для установки некоторых важных зависимостей для Ruby. Например, для Ubuntu 12.04 вы можете сделать:
rbenv bootstrap-ubuntu-12-04
Затем подождите некоторое время, пока установлены зависимости. Как только это будет сделано, вы можете установить Ruby:
rbenv install 1.9.3-p125
А затем установите его как стандартный Ruby:
rbenv global 1.9.3-p125
Наконец, установите гем компоновщика, чтобы у нас был необходимый доступ к исполняемому файлу комплекта:
gem install bundler --no-ri --no-rdoc
Используйте команду rbenv rehash, чтобы получить изменения:
rbenv rehash
Готовим приложение
Предполагая, что вы будете управлять своим исходным кодом через Github, было бы неплохо добавить к нему ssh-соединение с нашего сервера. Пока вы вошли в систему, выполните: ssh git@github.com Это гарантирует, что при развертывании через Capistrano у нас не должно быть никаких «неизвестных» ошибок.
Идея состоит в том, что прежде чем мы развернем через Capistrano, мы можем проверить, что все передано Github.
Теперь вы можете развиваться и переходить на github как обычно; ваш сервер Linode почти готов к приему развернутого приложения. Во-первых, нам нужно настроить Единорога и Капистрано .
Единорог и Капистрано
Unicorn — это HTTP-сервер, который прекрасно работает с Nginx для запуска приложений Rack. Capistrano — это один из многих способов развертывания приложения Rails полуавтоматическим способом.
Нам нужно будет добавить их обоих в наш gemfile:
gem 'unicorn' gem 'capistrano'
Вернувшись в командную строку, в каталоге приложения выполните команду capify Это создаст Capfile и файл config / deploy.rb , оба из которых необходимо будет отредактировать.
Начиная с capfile, мы используем конвейер ресурсов, поэтому будем раскомментировать соответственно:
load 'deploy' # Uncomment if you are using Rails' asset pipeline load 'deploy/assets' Dir['vendor/gems/*/recipes/*.rb','vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) } load 'config/deploy' # remove this line to skip loading any of the default tasks
Затем мы можем вставить в наш рецепт Capistrano:
| require «bundler/capistrano» | |
| server «176.xx.xx.xx», :web, :app, :db, primary: true | |
| set :application, «your app» | |
| set :user, «your user» | |
| set :deploy_to, «/home/#{user}/apps/#{application}« | |
| set :deploy_via, :remote_cache | |
| set :use_sudo, false | |
| set :scm, «git» | |
| set :repository, «git@github.com:your_github/#{application}.git» | |
| set :branch, «master» | |
| default_run_options[:pty] = true | |
| ssh_options[:forward_agent] = true | |
| after «deploy», «deploy:cleanup» # keep only the last 5 releases | |
| namespace :deploy do | |
| %w[start stop restart].each do |command| | |
| desc «#{command} unicorn server» | |
| task command, roles: :app, except: {no_release: true} do | |
| run «/etc/init.d/unicorn_#{application} #{command}« | |
| end | |
| end | |
| task :setup_config, roles: :app do | |
| sudo «ln -nfs #{current_path}/config/nginx.conf /etc/nginx/sites-enabled/#{application}« | |
| sudo «ln -nfs #{current_path}/config/unicorn_init.sh /etc/init.d/unicorn_#{application}« | |
| run «mkdir -p #{shared_path}/config» | |
| put File.read(«config/database.example.yml»), «#{shared_path}/config/database.yml» | |
| puts «Now edit the config files in #{shared_path}.» | |
| end | |
| after «deploy:setup», «deploy:setup_config» | |
| task :symlink_config, roles: :app do | |
| run «ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml» | |
| end | |
| after «deploy:finalize_update», «deploy:symlink_config» | |
| desc «Make sure local git is in sync with remote.» | |
| task :check_revision, roles: :web do | |
| unless `git rev-parse HEAD` == `git rev-parse origin/master` | |
| puts «WARNING: HEAD is not the same as origin/master» | |
| puts «Run `git push` to sync changes.» | |
| exit | |
| end | |
| end | |
| before «deploy», «deploy:check_revision» | |
| end |
by Это выходит за рамки этой статьи, чтобы просмотреть файл подробно. Однако вы можете видеть, что есть раздел для настройки ролей для веб-приложения и базы данных, а также каталог, в котором будет развернуто приложение.
Наши учетные данные Github включены, и есть раздел, чтобы убедиться, что все локальные изменения были зафиксированы до запуска развертывания.
Нам также нужно добавить файл конфигурации для Nginx в: config/nginx.conf
| upstream unicorn { | |
| server unix:/tmp/unicorn.your_user.sock fail_timeout=0; | |
| } | |
| server { | |
| listen 80 default deferred; | |
| # server_name example.com; | |
| root /home/andy/apps/you/current/public; | |
| location ^~ /assets/ { | |
| gzip_static on; | |
| expires max; | |
| add_header Cache-Control public; | |
| } | |
| try_files $uri/index.html $uri @unicorn; | |
| location @unicorn { | |
| proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; | |
| proxy_set_header Host $http_host; | |
| proxy_redirect off; | |
| proxy_pass http://unicorn; | |
| } | |
| error_page 500 502 503 504 /500.html; | |
| client_max_body_size 4G; | |
| keepalive_timeout 10; | |
| } |
Это стандартный файл конфигурации для Nginx, который сопоставляется с местоположением вашего приложения. Вы можете найти примеры конфигурационных файлов nginx здесь .
Вам также необходимо добавить файл конфигурации для настройки Unicorn:
| root = «/home/you/apps/appname/current» | |
| working_directory root | |
| pid «#{root}/tmp/pids/unicorn.pid» | |
| stderr_path «#{root}/log/unicorn.log» | |
| stdout_path «#{root}/log/unicorn.log» | |
| listen «/tmp/unicorn.your_user_name.sock» | |
| worker_processes 2 | |
| timeout 30 |
Вы можете увидеть образец файла здесь , но файл в основном устанавливает пути и количество рабочих процессов. Этот файл также находится в каталоге конфигурации вашего приложения.
Последний файл конфигурации, который нам нужно добавить в наше приложение, это скрипт оболочки для запуска Unicorn:
| #!/bin/sh | |
| set -e | |
| # Feel free to change any of the following variables for your app: | |
| TIMEOUT=${TIMEOUT-60} | |
| APP_ROOT=/home/you/apps/app_name/current | |
| PID=$APP_ROOT/tmp/pids/unicorn.pid | |
| CMD=«cd $APP_ROOT; bundle exec unicorn -D -c $APP_ROOT/config/unicorn.rb -E production« | |
| AS_USER=andy | |
| set -u | |
| OLD_PIN=«$PID.oldbin« | |
| sig () { | |
| test -s «$PID« && kill —$1 `cat $PID` | |
| } | |
| oldsig () { | |
| test -s $OLD_PIN && kill —$1 `cat $OLD_PIN` | |
| } | |
| run () { | |
| if [ «$(id -un)« = «$AS_USER« ]; then | |
| eval $1 | |
| else | |
| su -c «$1« — $AS_USER | |
| fi | |
| } | |
| case «$1« in | |
| start) | |
| sig 0 && echo >&2 «Already running« && exit 0 | |
| run «$CMD« | |
| ;; | |
| stop) | |
| sig QUIT && exit 0 | |
| echo >&2 «Not running« | |
| ;; | |
| force-stop) | |
| sig TERM && exit 0 | |
| echo >&2 «Not running« | |
| ;; | |
| restart|reload) | |
| sig HUP && echo reloaded OK && exit 0 | |
| echo >&2 «Couldn’t reload, starting ‘$CMD‘ instead« | |
| run «$CMD« | |
| ;; | |
| upgrade) | |
| if sig USR2 && sleep 2 && sig 0 && oldsig QUIT | |
| then | |
| n=$TIMEOUT | |
| while test -s $OLD_PIN && test $n -ge 0 | |
| do | |
| printf ‘.‘ && sleep 1 && n=$(( $n — 1 )) | |
| done | |
| echo | |
| if test $n -lt 0 && test -s $OLD_PIN | |
| then | |
| echo >&2 «$OLD_PIN still exists after $TIMEOUT seconds« | |
| exit 1 | |
| fi | |
| exit 0 | |
| fi | |
| echo >&2 «Couldn’t upgrade, starting ‘$CMD‘ instead« | |
| run «$CMD« | |
| ;; | |
| reopen-logs) | |
| sig USR1 | |
| ;; | |
| *) | |
| echo >&2 «Usage: $0 <start|stop|restart|upgrade|force-stop|reopen-logs>« | |
| exit 1 | |
| ;; | |
| esac |
Опять же, это идет в каталоге конфигурации вашего приложения. Это довольно общий скрипт с переменными, которые нужно будет корректировать в верхней части файла. Этот скрипт также необходимо пометить как исполняемый.
Рекомендуется настроить другого пользователя на VPS, чтобы учетные данные пользователя использовались, а не root, для пользователя, который отображается в различных файлах конфигурации.
Вы также должны зафиксировать файлы конфигурации в вашем Git-репозитории.
Запуск развертывания
Теперь вы можете запустить: cap deploy:setup Команда войдет на сервер, используя настроенную вами учетную запись. Он также создаст различные каталоги, указанные в ваших конфигурационных файлах.
Теперь вы сможете запустить: cap deploy:cold Опция «cold» означает, что миграция базы данных также будет выполняться. В этот момент вы можете увидеть ошибки, но в результате вы получите информацию о том, где проблема, чтобы ее можно было устранить.
Исправление сайта Nginx по умолчанию
Когда вы посещаете IP-адрес вашего сервера, вы все равно увидите страницу Nginx по умолчанию. Войдите на свой сервер через SSH и удалите символическую ссылку:
sudo rm /etc/nginx/sites-enabled/default
Затем перезапустите Nginx (это для Ubuntu, документация вашего дистрибутива поможет вам в этом):
sudo service nginx restart
Еще кое-что…
Выполните следующую команду, чтобы Unicorn запускался правильно при перезапуске сервера:
sudo update-rc.d unicorn_appname defaults
Теперь вы сможете перейти на свой сайт и увидеть, как работает ваше приложение.
В заключение…
Самый быстрый и самый безболезненный способ развертывания приложения Rails — через Heroku, в этом нет никаких сомнений. Однако это может дорого обойтись, и у вас нет конечного контроля над вашим приложением. Всего за 20 долларов в месяц вы можете иметь полнофункциональный виртуальный частный сервер для настройки по-своему и с максимальным контролем над развертываемыми приложениями. Это гораздо более сложный процесс.