Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Кешинг пакетов для Composer

Anna | 31.05.2014 | нет комментариев
Используя теперешний подход к разработке планов начинаешь пользоваться прелестями администратора пакетов, в случаe с разработкой на PHP это Composer. В данной статье мы коротко разглядим Composer и дальше речь пойдёт о настройке локального кеша пакетов. 

Данное изложение ни в коем случае не претендует на полноту, а лишь даёт короткое представление о данном инструменте.

Изложение Composer и пример с Silex.

Возьмём изложения из официальной документации:
Composer — является инструментом для управления зависимостями в PHP. Разрешает объявлять зависимые библиотеки нужные для плана, и установить их в ваш план. Composer работает в связке с Packagist.
Packagist — хранилище Composer пакетов. Разрешает вам находить надобные пакеты, а Composer узнавать откуда взять исходники пакетов.В прочем Composer не лимитирован Packagist хранилищем и абсолютно разрешает настроить зависимые пакеты из svn, git, pear. Пакеты обязаны содержать верно настроенный конфигурационный файл (composer.json). Правда и это не непременно, если конфигурационный файл отсутствует в необходимом вам пакете, то вам самим придётся его прописать теснее в конфигурационном файле зависимостей вашего плана. Пример

Конфигурация зависимостей плана происходит через Json конфигурационный файл (composer.json). Суть сводится к нахождению надобного пакета на Packagist, добавления соответствующей записи в composer.json и запуска Compoсer, тот, что сам скачает и настроит пакет (настроит по мере прописанных действий разработчиком пакета). Пример.

Посмотрим пример минимальной установки фреймворка Silex на (debian/ubuntu):

mkdir /path/to/your/webroot/silex; cd /path/to/your/webroot/silex
sudo apt-get install git,php5,curl; curl -sS https://getcomposer.org/installer | php

Этой командой вы скачаете Composer в формате PHP archive — composer.phar. Дальше создаём наименьший composer.json:

echo '{"require": {"silex/silex": "~1.1"} }' > composer.json
php composer.phar install

Дальше создаём web/index.php:

<?php
// web/index.php
require_once __DIR__.'/../vendor/autoload.php';

$app = new SilexApplication();
// definitions
$app->run();

Всё, фреймворк Silex готов, установку и запуск веб сервера опустим, в интернете полно готовых изложений.

Задача с администратором пакетов заключается в том, что слишком Зачастую доводится устанавливать одни и те же пакеты. Всякая новая установка плана, это обращение к packagist.org для нахождения источников зависимостей вашего пакета, зависимостей зависимостей и т.д. и последующее скачивание нужных пакетов. честности ради стоит подметить, что у Composer есть встроенный кеш, но он хранится под ~/.composer/cache, и соответственно личный для всякого пользователя, не говоря теснее об отдельных средах для разработчиков, тестеров, QA, продакшн. И всюду скачиваются одни и те же пакеты.

Множество пакетов находятся на гитхабе, откуда скачиваются довольно стремительно чтоб не заворачиваться на локальные кеш. Но когда github в следующий раз недоступен/тормозит из-за DDos, да ещё и размер зависимостей достигает сотен мегабайт — это становится задачей. Github недостижим — работа стоит. Я предлагаю и в данный момент использую утилиту Satis.

Satis — статическое хранилище Composer пакетов, ультра-легкая, статическая версии Packagist, может быть использована для размещения приватных пакетов вашей компании, либо своих собственных.

Как видно из официального изложения — основной целью Satis является вероятность подключения приватных пакетов. Но так же Satis, имеет вероятность скачивать пакеты из того же Packagist, беречь скаченные пакеты в zip либо tar, а также р!silex/silex-1.0.1.0′.
Dumping ‘silex/silex-1.0.9999999.9999999-dev’.
Dumping ‘silex/silex-1.1.0.0′.
Dumping ‘silex/silex-1.1.1.0′.
Dumping ‘silex/silex-9999999-dev’.
Dumping ‘symfony/debug-2.3.0.0′.
Dumping ‘symfony/debug-2.3.1.0′.
Dumping ‘symfony/debug-2.3.2.0′.
Dumping ‘symfony/debug-2.3.3.0′.
Dumping ‘symfony/debug-2.3.4.0′.
Dumping ‘symfony/debug-2.3.5.0′.
Dumping ‘symfony/debug-2.3.6.0′.
Dumping ‘symfony/debug-2.3.9999999.9999999-dev’.
Dumping ‘symfony/debug-2.4.0.0-beta1′.
Dumping ‘symfony/debug-9999999-dev’.
Dumping ‘symfony/event-dispatcher-2.1.0.0′.
Dumping ‘symfony/event-dispatcher-2.1.1.0′.
Dumping ‘symfony/event-dispatcher-2.1.10.0′.
Dumping ‘symfony/event-dispatcher-2.1.11.0′.
Dumping ‘symfony/event-dispatcher-2.1.12.0′.
Dumping ‘symfony/event-dispatcher-2.1.13.0′.
Dumping ‘symfony/event-dispatcher-2.1.2.0′.
Dumping ‘symfony/event-dispatcher-2.1.3.0′.
Dumping ‘symfony/event-dispatcher-2.1.4.0′.
Dumping ‘symfony/event-dispatcher-2.1.5.0′.
Dumping ‘symfony/event-dispatcher-2.1.6.0′.
Dumping ‘symfony/event-dispatcher-2.1.7.0′.
Dumping ‘symfony/event-dispatcher-2.1.8.0′.
Dumping ‘symfony/event-dispatcher-2.1.9.0′.
Dumping ‘symfony/event-dispatcher-2.1.9999999.9999999-dev’.
Dumping ‘symfony/event-dispatcher-2.2.0.0′.
Dumping ‘symfony/event-dispatcher-2.2.1.0′.
Dumping ‘symfony/event-dispatcher-2.2.2.0′.
Dumping ‘symfony/event-dispatcher-2.2.3.0′.
Dumping ‘symfony/event-dispatcher-2.2.4.0′.
Dumping ‘symfony/event-dispatcher-2.2.5.0′.
Dumping ‘symfony/event-dispatcher-2.2.6.0′.
Dumping ‘symfony/event-dispatcher-2.2.7.0′.
Dumping ‘symfony/event-dispatcher-2.2.8.0′.
Dumping ‘symfony/event-dispatcher-2.2.9.0′.
Dumping ‘symfony/event-dispatcher-2.2.9999999.9999999-dev’.
Dumping ‘symfony/event-dispatcher-2.3.0.0′.
Dumping ‘symfony/event-dispatcher-2.3.1.0′.
Dumping ‘symfony/event-dispatcher-2.3.2.0′.
Dumping ‘symfony/event-dispatcher-2.3.3.0′.
Dumping ‘symfony/event-dispatcher-2.3.4.0′.
Dumping ‘symfony/event-dispatcher-2.3.5.0′.
Dumping ‘symfony/event-dispatcher-2.3.6.0′.
Dumping ‘symfony/event-dispatcher-2.3.9999999.9999999-dev’.
Dumping ‘symfony/event-dispatcher-2.4.0.0-beta1′.
Dumping ‘symfony/event-dispatcher-9999999-dev’.
Dumping ‘symfony/http-foundation-2.1.0.0′.
Dumping ‘symfony/http-foundation-2.1.1.0′.
Dumping ‘symfony/http-foundation-2.1.10.0′.
Dumping ‘symfony/http-foundation-2.1.11.0′.
Dumping ‘symfony/http-foundation-2.1.12.0′.
Dumping ‘symfony/http-foundation-2.1.13.0′.
Dumping ‘symfony/http-foundation-2.1.2.0′.
Dumping ‘symfony/http-foundation-2.1.3.0′.
Dumping ‘symfony/http-foundation-2.1.4.0′.
Dumping ‘symfony/http-foundation-2.1.5.0′.
Dumping ‘symfony/http-foundation-2.1.6.0′.
Dumping ‘symfony/http-foundation-2.1.7.0′.
Dumping ‘symfony/http-foundation-2.1.8.0′.
Dumping ‘symfony/http-foundation-2.1.9.0′.

Сейчас необходимо подправить конфиг пакетов в плане тот, что будет применять наш Satis кеш, вновь же воспользуемся примером Silex:

cd /path/to/your/webroot/silex
echo '{"repositories": [{ "type": "composer", "url": "http://packagist.example.com" },{ "packagist": false } ], "require": {"silex/silex": "~1.1"}}' > composer.json

Отформатированная версия composer.json

{
   "repositories":[
      {
         "type":"composer",
         "url":"http://packagist.example.com"
      },
      {
         "packagist":false
      }
   ],
   "require":{
      "silex/silex":"~1.1"
   }
}

 

  • repositories: список хранилищ пакетов;
  • { «type»: «composer», «url»: «packagist.example.com» }: линк на наше, только что, сделанное Satis хранилище с типом composer.
  • { «packagist»: false }: по умолчанию, если пакет не будет обнаружен в списке указанных хранилищах, Composer полезет искать паркеты на Packagist. Это отлично и удобно. Но, если мы позволим такое поведение, то мы не можем быть уверены, что подлинно все пакеты есть у нас на локальном хранилище. Добавлю своё слежение: если у вас много зависимостей, то Composer ест много памяти, некоторые рапортуют размеры в 3Гб… что печалит. Так вот, схожую обстановку отслеживали и мы, до тех пор пока не оставили лишь одно хранилище. То есть, либо packagist.org либо своё Satis;
  • require: список зависимостей;
  • {«silex/silex»: “~1.1″}: пока нам необходим только Silex;

Сейчас, чтоб удостовериться в работоспособности нашей конструкции, нам необходимо очистить кеш Composer, напротив Composer возьмёт пакет из своего кеша:
cd /path/to/your/webroot/silex; rm compsoer.lock; rm -fr vendor; rm -fr ~/.composer/cache composer install 

Всё. Если настройки положительные, сейчас Composer будет брать пакеты из нашего локального кеша (http://packagist.example.com).

Минус предложенного решения в том, что кешируемые пакеты доводится прописывать в конфигурационном файле Satis (satis.json) руками, то есть Satis не будет трудиться как прокси с авто-кешингом, что на мой взор, является упущением. Так же необходимо настроить крон скрипт тот, что будет дёргать Satis build для обновления дев-пакетов и скачивания новых версий пакетов:
0 */12 * * * cd /path/to/your/webroot/satis/; php bin/satis build satis.json ./web/

P.S. неточности и ошибки умоляю в личку.
P.S.S. другие решения кешинга Composer пакетов, предлагаю обсудить в коментариях.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB