先上链接:https://github.com/zencodex/composer-mirror
ZComposer 镜像诞生于 2017 年 3 月份,至今已不间断稳定运行 2 年多了。如何保证Composer 镜像的稳定性,是面临的最大难题,所以简单聊一些开发和解决问题的思路,希望能对你有一点启发。如果你觉得有些收获,请点下鼠标,在 github 上给我 1 个 star(支持下),谢谢。
安全性,不对原有的 json,zip 做修改,否则会引起 hash 变化,重新计算 hash 没问题(之前第三方有这么做的),这样带来的问题是,无法对包的安全性做校验,假如有恶意黑镜像,对数据做了修改,就无法判断了。所以 ZComposer 的镜像,所有的包都是和 packagist.org 官方一致的,可以比对 hash ,没有任何修改。
稳定性,因为不间断的采集数据,上传数据,中间有一个环节出现差错,就可以导致有问题,所以务必对采集完的包,通过 hash 值做完整性检查。有时候第三方的 API 策略,或者 CDN 线路都可能导致出现问题。所以做镜像最大的难点,是稳定性的保障。
推荐运行主机配置:
$ apt install beanstalkd $ cd composer-mirror $ composer install
通常根据自己部署的实际环境,修改参数。详细配置说明详见 config.default.php
cp config.default.php config.php,修改 config.php 中的如下参
cp config.default.php config.php
/** * distdir 用于存储 zip 包 */ 'distdir' => __DIR__ . '/dist/', /** * 指向 mirrorUrl 对应的 web 实际目录 */ 'cachedir' => __DIR__ . '/cache/', /** * packagistUrl:官方采集源 */ 'packagistUrl' => 'https://packagist.org', /** * 镜像包发布站点, packages.json 入口根域名 */ 'mirrorUrl' => 'https://packagist.laravel-china.org', /** * .json 中 dist 分发 zip 包的CDN域名 */ 'distUrl' => 'https://dl.laravel-china.org/',
sudo vim /etc/supervisor/supervisord.conf,添加如下配置信息:
sudo vim /etc/supervisor/supervisord.conf
[program:crawler] command=php ./bin/console app:crawler directory=/home/zencodex/composer-mirror/ ;部署代码的位置,自行替换 autostart=true autorestart=true redirect_stderr = true ; 把 stderr 重定向到 stdout,默认 false stdout_logfile_maxbytes = 10MB ; stdout 日志文件大小,默认 50MB stdout_logfile_backups = 5 ; stdout 日志文件备份数 stdout_logfile = /tmp/composer_crawler_stdout.log [program:composer_daemon] command=php ./bin/console app:daemon directory=/home/zencodex/composer-mirror/ ;部署代码的位置,自行替换 autostart=true autorestart=true redirect_stderr = true ; 把 stderr 重定向到 stdout,默认 false stdout_logfile_maxbytes = 10MB ; stdout 日志文件大小,默认 50MB stdout_logfile_backups = 5 ; stdout 日志文件备份数 stdout_logfile = /tmp/composer_daemon_stdout.log
# sudo crontab -e # 根据自己环境代码的位置,替换 /home/zencodex/composer-mirror # getcomposer 是获取最新的 composer,上传到 CDN 云存储 0 */2 * * * /usr/bin/php /home/zencodex/composer-mirror/bin/console app:clear --expired=json 0 1 * * * /usr/bin/php /home/zencodex/composer-mirror/getcomposer.php
# 执行抓取任务 $ php ./bin/console app:crawler # 后台多进程模型同步又拍云 $ php ./bin/console app:daemon # 清理过期垃圾文件 $ php ./bin/console app:clear --expired=json # 扫描并校验所有json和zip文件的hash256 $ php ./bin/console app:scan
如果使用非又拍云的其他平台,需要注意以下代码,需要自行实现
ZenCodex\Support\Flysystem\Adapter\UpyunAdapter
代码详情见 src/Commands/PatchCommand.php
src/Commands/PatchCommand.php
/* |-------------------------------------------------------------------------- | linux ext4 支持的最大子目录数有上限,大约 64000 ~ 65000,目前包的数量已经超过上限 |-------------------------------------------------------------------------- | | 有三种解决方法,前2种基本不现实。所以自己通过尝试,找到了3 (软连接不计数的方案) | | 1. 更换没有子文件夹数量限制的文件系统,比如 xfs | 2. 或者更改相关代码,重新编译 ext4 内核 | 3. 切割大的文件夹,分散不同字母开头的文件。在主文件夹里面使用软连接,软连接并不计数 | */
评论删除后,数据将无法恢复
Composer 中国全量镜像开源了,一起让 PHP 社区更繁荣
先上链接:https://github.com/zencodex/composer-mirror
ZComposer 镜像诞生于 2017 年 3 月份,至今已不间断稳定运行 2 年多了。如何保证Composer 镜像的稳定性,是面临的最大难题,所以简单聊一些开发和解决问题的思路,希望能对你有一点启发。如果你觉得有些收获,请点下鼠标,在 github 上给我 1 个 star(支持下),谢谢。
安全性,不对原有的 json,zip 做修改,否则会引起 hash 变化,重新计算 hash 没问题(之前第三方有这么做的),这样带来的问题是,无法对包的安全性做校验,假如有恶意黑镜像,对数据做了修改,就无法判断了。所以 ZComposer 的镜像,所有的包都是和 packagist.org 官方一致的,可以比对 hash ,没有任何修改。
稳定性,因为不间断的采集数据,上传数据,中间有一个环节出现差错,就可以导致有问题,所以务必对采集完的包,通过 hash 值做完整性检查。有时候第三方的 API 策略,或者 CDN 线路都可能导致出现问题。所以做镜像最大的难点,是稳定性的保障。
ZComposer 镜像的安装部署
推荐运行主机配置:
修改配置参数
cp config.default.php config.php
,修改 config.php 中的如下参supervisor 配置
sudo vim /etc/supervisor/supervisord.conf
,添加如下配置信息:crontab 定时任务
常用命令
For Developers
ZenCodex\Support\Flysystem\Adapter\UpyunAdapter
封装 getClientHandler。注意最大子目录数的坑
代码详情见
src/Commands/PatchCommand.php