Какой рейтинг вас больше интересует?
|
Главная / Главные темы / Тэг «deployment»
[Перевод] PHP и realpath_cache 2015-09-15 16:20:02
От переводчика: разбираясь на днях с ошибкой, возникшей после деплоя сервиса, натолкнулся ...
+ развернуть текст сохранённая копия
От переводчика: разбираясь на днях с ошибкой, возникшей после деплоя сервиса, натолкнулся на эту замечательную статью про механизм кэширования файловых статусов в PHP. Предлагаю сообществу перевод.
Слышали ли вы про PHP-функции realpath_cache_get() и realpath_cache_size() ? А может быть про параметры realpath_cache_size и realpath_cache_ttl в php.ini?
Кэш realpath — довольно важный механизм PHP, который нужно иметь в виду. Особенно, когда приходится работать с символическими ссылками, например, при деплое проекта. Настройка кэширования realpath может значительно влиять на быстродействие сервера и нагрузку на дисковую подсистемы сервера. Этот параметр был введен в версии 5.1, когда начали появляться первые PHP-фреймворки.
Далее мы разберемся, как все это работает под капотом, и как с этим жить. Под катом много ссылок на исходники.
Читать дальше →
Тэги: apc, cache, deployment, opcache, php, symfony
[recovery mode] Мысли о развёртывании веб-приложений на тестовом сервере 2015-09-09 05:10:33
Предисловие
Нижеследующий текст − результат практического опыта и ...
+ развернуть текст сохранённая копия
Предисловие
Нижеследующий текст − результат практического опыта и самообразовательных порывов человека, не имеющего систематического образования ни в одной из областей, о которых он (то есть я) берётся рассуждать. Поэтому заумные рассуждения здесь будут перемежаться банальностями. Бейте меня за первые и игнорируйте вторые. Для кого-то и они могут стать откровением.
Я постараюсь описать идеальные варианты настройки тестового веб-севера, хотя понимаю, какой бардак на них обычно творится. Буду ориентироваться на ситуацию, когда деплоить приходится часто, то есть на сервере живёт проект в стадии активной разработки либо несколько проектов на разных стадиях. Проектами занимаются разные разработчики или команды, поэтому проекты нужно изолировать друг от друга. Но сервер внутренний, поэтому такая степень изоляции и автоматизации процессов администрирования, как на серверах под сдачу в аренду, не нужна.
Основной упор я буду делать на применение разных версий Python в качестве языка поддерживаемых веб-приложений. Хотя многие вещи наверняка будут справедливы и для других языков, например, Ruby или Perl.
Читать дальше →
Тэги: apache, deployment, linux, python, web, wsgi, администрирование, веб-разработка, развёртывание, сервер, серверное, тестовый
[Из песочницы] Ansible и Rails — гибкая замена Capistrano с сохранением знакомого комфорта 2015-09-07 15:09:38
... cap production deploy превратится в ... ansible-playbook deploy.yml -i inventory ...
+ развернуть текст сохранённая копия
Capistrano — любимый многими rails-разработчиками инструмент, с помощью которого можно быстро и без заморочек автоматизировать развертывание вашего приложения. Capistrano — стандарт де-факто для системы развертывания RoR, must-know технология для любого уважающего себя рубиста, тот инструмент, которому в своё время завидовали разработчики на python и PHP.
Несмотря на комфорт, от которого не хочется отказываться, чем более сложные задачи мне приходилось решать, тем чаще Capistrano показывал себя к ним не приспособленным.
Я отметил следующие недостатки:
- Известные проблемы со скоростью. Вследствие своей универсальности, Capistrano деплоит медленно, выполняя лишние проверки и вызовы, которые вы не всегда можете контролировать.
- Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов.
- Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.
- Плагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.
- Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.
Многие ruby-разработчики перешли на Mina или решают свои проблемы с помощью ещё более сложных систем управления конфигурациями вроде Chef и Puppet. Все они имеют свои особенности и недостатки и в разной степени решают описанные выше проблемы. Мне же удалось их решить их с помощью Ansible, не растеряв преимуществ Capistrano, к которым я привык.
Ansible это инструмент для управления конфигурациями и в его задачи входит не только описанное в этой статье выполнение удаленных команд на серверах для развертывания и управления отдельным приложением, но и автоматизация серверного администрирования посредством хранимых серверных конфигураций (ролей на языке Ansible). А значит Ansible (как впрочем и Chef и Puppet) позволяет гораздо больше, чем Capistrano и в конечном счете они все не идут с ним ни в какое сравнение. Однако, задача этой статьи дать rails-разработчикам отправную точку для миграции и разъяснить на этом примере основы Ansible. В конце этой статьи, волшебная команда cap production deploy превратится в ansible-playbook deploy.yml -i inventory/production
Кому интересно как — прошу под кат.
Читать дальше →
Тэги: ansible, capistrano, configuration, deploy, deployment, management, passenger, rails, ruby, sidekiq, tools, веб-разработка
Самый простой deploy приложения на Ruby on Rails 2014-12-16 19:28:54
... я написал пост Deploy приложения на RoR ...
+ развернуть текст сохранённая копия
Полгода назад я написал пост Deploy приложения на RoR 4 с помощью Capistrano 3. Прошло время, я получил много положительных отзывов, но были и отрицательные. Из них можно было понять следующее:
- Инструкция слишком сложная для новичка
- Очень много всего приходится делать «руками»
Я подумал и написал gem 'capistrano3-ubuntu-server-config', который полностью настраивает Ваш «чистый» Ubuntu сервер. Всё, что Вам нужно сделать руками — создать нового пользователя и дать ему права visudo (причем давать ему права на passwordless sudo ему не надо). Он может:
- Настроить SSH (Добавить настройки 'PermitRootLogin no', 'UseDNS no', 'AllowUsers username')
- Создать и настроить swap (размер запрашивается)
- Сделать
sudo apt-get update и
sudo apt-get upgrade
- Установить из исходников и настроить как чистый Nginx, так и с модулем Pagespeed
- Установить PostgreSQL из репозитория, затем создать суперпользователя БД (имя пользователя и пароль запрашиваются)
- Установить из исходников и настроить Redis
- Установить RVM с последней версией Ruby и gem'ами Rails, Bundler
- Скопировать Ваш приватный ssh ключ (например для доступа к приватному git репозиторию) с локальной машины на сервер и добавить его в ~/.ssh/config
- Установить imagemagick из репозитория (Необходим для Paperclip, постоянно его забываю ставить)
- Установить любые дополнительные пакеты из репозитория (Запрашивает какие именно)
Можно запустить конфигурационный wizard, который узнает, что именно из вышеперечисленного необходимо сделать и заранее спросит все настройки, чтобы можно было потом пойти попить кофе, а можно запустить отдельные таски. Данный gem будет полезен не только Rails разработчикам, а всем, кто использует Capistrano для деплоя.
Эта статья раскроет следующие темы:
- Использование gem'a capistrano3-ubuntu-server-config
- Использование gem'а capistrano3-git-push
- Моя текущая миниатюрная конфигурация Capistrano
Узнать как задеплоить Ваше приложение за 5 минут активного времени
Тэги: capistrano, deploy, deployment, linux, nginx, rails, ruby, unicorn, веб-разработка, настройка
Быстрая настройка Grunt для комфортной разработки 2014-12-04 18:48:05
+ развернуть текст сохранённая копия
Во время разработки нашего сервиса bitcalm.com, нам потребовалось организовать автоматическую сборку проекта. Перед нами стояла цель улучшить производительность frontend-части нашего приложения, а также оптимизировать процессы разработки и развертывания на сервере.
Основными задачами, которые требовалось решить, стали:
- Объединение и минификация скриптов
- Объединение и минификация стилей
- Сжатие png-изображений
- Создание спрайтов из всех изображений (с возможностью удобного использования и с поддержкой двух видов спрайтов для девайсов с разным PPI)
- Построение разных версий html-документов для разработки и для продакшна
Первые три пункта выглядят достаточно тривиальными, поэтому я постараюсь заострить внимание на работе со спрайтами и на обработке html.
Читать дальше →
Тэги: bitcalm, css, css-sprites, deployment, grunt, gruntjs, html, javascript, web-разработка, блог, веб-разработка, компании
Главная / Главные темы / Тэг «deployment»
|
Взлеты Топ 5
Падения Топ 5
|