1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Деплой 4game

Discussion in 'Архив новостей' started by vitmedved, Aug 23, 2013.

Thread Status:
Not open for further replies.
  1. vitmedved

    vitmedved Почетный пользователь

    Joined:
    29.07.13
    Messages:
    1,333
    Likes Received:
    2,204
    добрый день, господа.
    сегодня 23.08.2013 в 12:00 будет осуществляться деплой фогейма ориентировочным сроком на 10 минут. возможны проблемы с заходом на сервера тех, кто будет пытаться заходить в игру в этот период.
    благодарим за внимание.
     
  2. sfeed

    sfeed User

    Joined:
    20.07.10
    Messages:
    519
    Likes Received:
    37
    будете обновлять оборудование? на игровом процессе в дальнейшем скажется как либо ? и можно ли узнать на сколько повыситься характеристики нового оборудования ?
     
  3. ISoto

    ISoto User

    Joined:
    24.06.11
    Messages:
    1,544
    Likes Received:
    74
    интересно. а можно конкретизировать что вы делать будете?
     
  4. sfeed

    sfeed User

    Joined:
    20.07.10
    Messages:
    519
    Likes Received:
    37
    деплой - развертывание.
     
  5. Феня.

    Феня. User

    Joined:
    12.05.13
    Messages:
    1,511
    Likes Received:
    607
    как все сразу стало ясно и понятно:d
     
  6. MC_KOMAR

    MC_KOMAR User

    Joined:
    23.02.11
    Messages:
    148
    Likes Received:
    23
    Code:
    всем привет. сегодня я хотел бы ещё раз поговорить о замечательном deploy-ере capistrano.
    напомню, что capistrano — это open source-ный инструмент для выполнения скриптов на нескольких серверах, который в основном используется для web приложений. он позволяет автоматизировать процесс развертывания новой версии на одном или нескольких web серверах и включает поддержку таких задач, как например изменение базы данных.
    capistrano написан на ruby и является «модулем» (или компонентном, не знаю как лучше) фреймворка ruby on rails.
    данный топик по большей части является переводом туториала со страницы проекта на github-е с некоторыми дополнениями, изменениями и сокращениями специфичными для php (или для «не ror»). здесь не будут рассматриваться вопросы работы с несколькими серверами и базой данных, это всего лишь небольшое пособие для начинающих.
    итак, допустим на нашем локальном компьютере в паке /path/deploy/from находится приложение написанное на языке php. у этого приложения есть git репозиторий находящийся по адресу example.net/project.git с актуальным кодом. также у нас есть хостинг по адресу example.com с ssh доступом и папкой /path/deploy/to куда мы собираемся залить наши файлы. мы не хотим постоянно возиться с ftp клиентом и решили потратить несколько часов для того, чтобы разобраться в деплойере capistrano. давайте приступим.
    
    установка
    
    начнем с установки. открываем консоль и вводим:
    
        $ sudo apt-get install ruby rubygems
        $ sudo gem install capistrano
    
    
    поскольку в ror файлы конфигурации находятся в папке config, capistrano предполагает что у нас она есть. если её нет, то необходимо её создать:
    
        $ mkdir /path/deploy/from/config
    
    
    если директория в которой вы создаете каталог config, также является корневой директорией сервера, то не забудьте положить в неё файл .htaccess для apache, который запретит просмотр файлов этого каталога, или в конфигурации других web серверов запретить доступ к этому каталогу.
    
    капификация
    
    первое что мы должны сделать после установки capistrano это «capify-нуть» наше приложение. «капификация» — это процесс конфигурации capistrano для развертывания приложения. он достаточно прост: убедитесь что вы находитесь в корневой директории вашего проекта
    и введите
    
      $ cd /path/deploy/from
      $ capify .
    
    
    эта команда создаст два файла:
    capfile — главный файл который нужен capistrano. подобно тому, как «make» использует «makefile», а «rake» — «rakefile», capistrano по умолчанию ищет и загружает «capfile». изначально генерируемый capfile очень прост: все что он делает — загружает «config/deploy.rb»...
    config/deploy.rb — файл в котором содержатся «настройки» приложения.
    вообще говоря нам нужно оставить capfile в покое и вплотную заняться файлом config/deploy.rb. изначально он будет выглядеть следующим образом:
    
        set :application, "set your application name here"
        set :repository,  "set your repository location here"
    
        set :scm, :subversion
        # or: `accurev`, `bzr`, `vcs`, `darcs`, `git`, `mercurial`, `perforce`, `subversion` or `none`
    
        role :web, "your web-server here"                          # your http server, apache/etc
        role :app, "your app-server here"                          # this may be the same as your `web` server
        role :db,  "your primary db-server here", :primary => true # this is where rails migrations will run
        role :db,  "your slave db-server here"
    
        # if you are using passenger mod_rails uncomment this:
        # if you're still using the script/reapear helper you will need
        # these [url]http://github.com/rails/irs_process_scripts[/url]
    
        # namespace :deploy do
        #   task :start do ; end
        #   task :stop do ; end
        #   task :restart, :roles => :app, :except => { :no_release => true } do
        #     run "#{try_sudo} touch #{file.join(current_path,'tmp','restart.txt')}"
        #   end
        # end
    
    
    нас данный конфиг не устраивает, поэтому мы его перепишем.
    
    конфигурация
    
    для начала приложению нужно дать имя. назовем его «my php application»:
    
        set :application, "my php application"
    
    
    затем необходимо указать репозиторий, где находится наш код. к этому репозиторию должен быть доступ как с вашей локальной машины, так и с хостинга, где вы хотите развернуть проект. задаем наш репозиторий:
    
        set :repository, "ssh://git@example.net/project.git"
    
    
    в случае, если url для доступа к репозиторию с локальной машины и с сервера различаются (например снаружи ssh имеет другой порт), нужно указать оба адреса:
    
        set :repository, "ssh://git@example.com:22100/project.git"
        set :local_repository, "ssh://git@example:project.git"
    
    
    поскольку мы используем систему контроля версий отличную от subversion, которая назначена по-умолчанию, необходимо ввести следующую строку:
    
        set :scm, :git
    
    
    теперь нужно указать capistrano в какую папку на сервере мы хотим развернуть проект. чтобы понять что это значит, нужно рассмотреть структуру директорий которую использует capistrano для развертывания приложений.
    
    структура директорий capistrano
    
    проект успешно развернутый с capistrano будет иметь структуру похожую на приведенную ниже ( где [deploy_to] — это каталог куда мы хотим развернуть проект):
    
        [deploy_to]
        [deploy_to]/releases
        [deploy_to]/releases/20080819001122
        [deploy_to]/releases/...
        [deploy_to]/shared
        [deploy_to]/shared/log
        [deploy_to]/shared/pids
        [deploy_to]/shared/system
        [deploy_to]/current -> [deploy_to]/releases/20100819001122
    
    
    каждый раз когда вы будете разворачивать проект в папке «releases» будет создаваться новая директория, в которую будет копироваться его последняя версия. после этого символическая ссылка «current» обновиться и будет указывать на новую директорию. если структура вашего приложения похожа на структуру приложения в ror или другого приложения, где корневая директория проекта и web директория отличаются, необходимо убедиться, что сервер настроен именно на эту директорию (в ror это [deploy_to]/current/public).
    
    вернемся к конфигурации
    
    итак нам нужно указать куда на сервере мы хотим развернуть приложение. по умочанию это папка "/u/apps/#{application}" (где #{application} это имя которое мы указали выше в переменной ":application"). поскольку наша директория отличается от директории по умолчанию, укажем её явно:
    
        set :deploy_to "/path/deploy/to"
    
    
    теперь нужно указать где находятся наши сервера. вообще говоря capistrano по умолчанию использует три роли для развертывания rails приложений: web, app и db. подробное описание этих ролей можно найти в оригинальной статье. поскольку у нас только один сервер и функциональность ролей нам не нужна, можно использовать следующий синтаксис:
    
        server "example.com"
    
    
    дополнительные настройки
    
    теперь посмотрим на некоторые дополнительные переменные, которые могут вам пригодиться.
    
        set :user, "foo"
    
        указывает имя пользователя для ssh или ftp доступа, если вы подключаетесь к серверу под именем отличным от имени под которым вы залогинены на ваш локальный компьютер.
    
        set :password, "password"
    
        устанавливает пароль для подключения к серверу. не рекомендуется.
    
        set :scm_username, "foo"
    
        указывает имя пользователя, для доступа к репозиторию, если вы подключаетесь к нему под именем отличным от имени под которым вы залогинены на локальном компьютере. не все vcs поддерживают этот параметр. если ваша система контроля версий не поддерживает, то необходимо указать это имя в параметре ":repository" так как это сделано выше.
    
        set :use_sudo, false
    
        назначено по умолчанию. если вы хотите дать capistrano sudo доступ для выполнения каких-либо операций, поставьте true
    
        set :via, "scp"
    
        устанавливает протокол, по которому будут копироваться данные.
    
        set :branch, "master"
    
        указывает ветку проекта из которой будет браться код.
    
        set :deploy_via, :remote_cache
    
        сохраняет кэш последней версии на сервере и при новом deploy-е скачивает только обновления. наверняка вы захотите установить этот параметр.
    
    
    команды capistrano
    
    после того, как мы написали свой рецепт, можно задать capistrano несколько вопросов:
    
        $ cap -h
    
        выведет список возможных опций.
    
        $ cap -h
    
        выведет список всех опций с подробным описанием каждой из них.
    
        $ cap -t
    
        выведет список всех task-ов (или задач) с кратким описанием каждого из них.
    
        $ cap -e deploy:web_disable
    
        покажет подробную информацию о конкретной задаче.
    
    
    setup
    
    попробуем воспользоваться капистрано для взаимодействия с сервером. для начала нам нужно создать базовую структуру дерикторий:
    
        $ cap deploy:setup
    
    
    при запуске этой команды капистрано подключится к серверу и выполнит серию команд «mkdir». заранее убедитесь, что у вас все в порядке с правами доступа на директорию в которую вы разворачиваете проект.
    
    проверка зависимостей
    
    теперь, когда у нас есть каркас, мы можем спросить у капистрано, есть ли у нас все, что нужно для продолжения разворачивания проекта:
    
        $ cap deploy:check
    
    
    капистрано проверит локальный и удаленный сервера на наличие необходимых вещей. если чего-то не хватает, вы получите сообщение об ошибке, например, что у вас нет прав на какую-либо операцию, что на сервере не установлен git и т.п.
    
    отправка кода на сервер
    
    сейчас мы не будем выполнять полноценный деплой, а попробуем просто залить код на сервер, чтобы убедиться что на этом этапе у нас все в порядке:
    
        $ cap deploy:update
    
    
    эта команда скачивает код из репозитория на сервер и обновляет симлинк «current».
    
    deploy
    
    наконец мы подобрались непосредственно к деплою. в действительности команда deploy всего лишь обертка, над несколькими другими командами, которая просто выполняет их последовательно. как это происходит можно посмотреть на следующей схеме:
    image
    
    поскольку команды deploy:update и deploy:finalize_update специфичны для приложений написаных на ruby on rails, нам нужно переопределить их. помимо этих двух команд рекомендую переопределить команды deploy:start и deploy:stop, поскольку они тоже заточены для ror и в случае их запуска могут привести к ошибке (на самом деле есть и другие специфичные команды, но мы переопределяем только самые основные):
    
      namespace :deploy do
        task :start do
        end
        task :stop do
        end
        task :restart do
        end
        task :finalize_update do
        end
      end
    
    
    в принципе, теперь команда deploy ничем не отличается от команды deploy:update, но вы можете изменить это, прописав специфичные для вашего приложения действия в необходимых task-ах .
    теперь деплойер готов к работе. для тех, кому описанных возможностей не достаточно, рекомендую ознакомиться с разделом dsl documentation на страничке wiki проекта и внимательно почитать вывод команды «cap -e» для каждого стандартного task-а. прочитав их вы без труда сможете писать конструкции например такого вида:
    
      after "deploy", "deploy:cleanup"
    
    
    если добавить такую строку в рецепт, то после каждого деплоя автоматически будет выполняться чистка директории /path/deploy/to/releases (по умолчанию удаляются все релизы, кроме 5 последних).
    
    multistage
    
    у себя в разработке мы также используем расширение capistrano-ext, которое позволяет делать так называемый multistage. предположим у вас есть тестовый и рабочий сервера. вы можете написать отдельный конфиг для каждого из них и выполнять deploy только для нужного сервера.
    для установки расширения в командной строке наберите:
    
        $ gem install capistrano-ext
    
    
    далее в папке /path/deploy/from/config/ создаем новый каталог
    
        $ mkdir /path/deploy/from/config/deploy
    
    
    и помещаем в него свои рецепты: например production.rb и staging.rb. всё что нам нужно для конфигурации — это написать в файл /path/deploy/from/config/deploy.rb две строки:
    
        set :stages, %w(staging production)
        require 'capistrano/ext/multistage'
    
    
    теперь вы можете выполнять деплой с помощью команд «cap production deploy» и «cap staging deploy». если вам нужен ещё один конфиг, просто положите его в каталог deploy и добавьте его имя в переменную :stages:
    
        set :stages, %w(staging production develop)
    
    
    если вы попробуете просто выполнить команду «cap deploy», capistrano предупредит, что необходимо указать рецепт по которому нужно выполнять деплой и прервет работу. для того, чтобы использовать какой-либо рецепт по-умочанию, можно определить переменную «default_stage»:
    
        set :stages, %w(staging production develop)
        set :default_stage, "develop"
        require 'capistrano/ext/multistage'
    
    
    теперь команда «cap deploy» будет эквивалентна команде «cap develop deploy»
    на этом всё, спасибо за внимание.
    
    p.s.: назвать публикацию переводом язык не повернулся, потому что здесь меньше половины туториала. много чего взято из других статей и из личного опыта.
     
    Last edited by a moderator: Aug 23, 2013
  7. Sheff2008

    Sheff2008

    Joined:
    06.03.10
    Messages:
    1,570
    Likes Received:
    102
    -=nikitko=- - отредактируй сообщение своё.

    ты бы хоть в скрытый текст вставлял или в код. зачем это выкладывать вообще? ссылить на гугл можно кому интересно сами инфу найдут.

    код - [ code] [/code]
    скрытый текст - [ spoiler][/spoiler]

    для не знающих. (пробелы в первых скобках убрать)
     
    Last edited by a moderator: Aug 23, 2013
  8. MC_KOMAR

    MC_KOMAR User

    Joined:
    23.02.11
    Messages:
    148
    Likes Received:
    23
    чтобы не задавали еще +100500 вопросов.
     
  9. Sheff2008

    Sheff2008

    Joined:
    06.03.10
    Messages:
    1,570
    Likes Received:
    102
    не обязательно писать как это происходит. можно было выложить инфу про деплой. а не описывать как задеплойдить. =)
     
  10. MC_KOMAR

    MC_KOMAR User

    Joined:
    23.02.11
    Messages:
    148
    Likes Received:
    23
    вдруг кому то интересно прочитать о сложности данного процесса:)
     
  11. Sheff2008

    Sheff2008

    Joined:
    06.03.10
    Messages:
    1,570
    Likes Received:
    102
    а вдруг не вдруг. ))))
     
  12. ISoto

    ISoto User

    Joined:
    24.06.11
    Messages:
    1,544
    Likes Received:
    74
    я тоже люблю гугл транслейтор=)
    интересно же из-за чего конкретно потом могут быть проблемы с заходом в 4гейм, чтобы описывать их в саппорте=)
     
  13. Sheff2008

    Sheff2008

    Joined:
    06.03.10
    Messages:
    1,570
    Likes Received:
    102
    во всём виноват деплой. =) хах. прям так и писать в сапп...
     
  14. sfeed

    sfeed User

    Joined:
    20.07.10
    Messages:
    519
    Likes Received:
    37
    по сути модное словечко означает развертывание чего либо ... либо установка ...
    но вот чего установили в р2 не понятно )
     
  15. ISoto

    ISoto User

    Joined:
    24.06.11
    Messages:
    1,544
    Likes Received:
    74
    зачем?=) напишешь что после деплоя у тебя не работает 4гейм - тебе ответят, что проблема у тебя - а вот туточки то и понадобиться вся инфа - спасение утопающего - дело рук самого утопающего=)
     
  16. BOSSISCHE

    BOSSISCHE User

    Joined:
    08.02.10
    Messages:
    1,001
    Likes Received:
    93
    у меня не работала игра когда была обнова... все время выкидывало.. и форум не помог с шибками..
    сап помог ) правдо ждал ответа 15 дней ) зато все помог и играю свободно без лаг и .т.д. )
     
Thread Status:
Not open for further replies.