本文基于的应用场景是作者个人维护十数台可用性要求不是很高的非生产环i8境服务器（个人博客，团队git服务器等）。

那么这样的应用场景要求选用的系统尽量满足一下特性：

• 免费/开源/便宜
• 快速
• 轻量
• 可扩展性强

目前作者接触到的服务器监控系统大概有那么几个，全部都基于开源软件。传统老牌监控系统Zabbix和Nagios、基于Prometheus的监控系统解决方案和基于InfluxDB的解决方案。对比了这些方案后，作者选出了一种最适合的系统，只想看结论的同学请直接翻到文末。

Zabbix 和 Nagios

Zabbix

Zabbix 作为老牌的企业级服务器监控系统，功能非常强大。
官方介绍有许多功能，包括：

• 几乎所有协议和数据结构的数据来源（包括SNMP, IPMI等基础设施管理协议）
• 极其丰富的配置项
• 丰富的API控制
• 完全的用户权限和认证系统，提供PAM支持
• 一站式的解决方案，可提供图表绘制、日志审查、报警等所有可能用到的健康度监控工具
• 自动发现设备和数据来源
• 自动化维护和检查
• 可自定义的前端样式

功能强大的同时也相应的会带来重量级的问题，官方文档给出的要求是100个监控项的数量级至少需要128MB内存和256M硬盘来安装，实际使用中一般需要1GB内存和100G左右的硬盘来保证比较良好的可用性。
不过这样的问题仅仅是对于小规模应用场景来说的，真正企业级的应用中zabbix还是属于相当轻量的，也是当之无愧的首选。
Zabbix虽然提供了高度的可定制性和多到令人厌烦的配置选项，但是作为一站式方案的系统，系统耦合度很高，不利于大型、实力强的企业做二次开发和组件替换。
我个人在一年多前使用过一会zabbix，安装并不困难，甚至比Mysql的安装配置都简单，但是完成后监控配置十分负复杂，对于两位数的机器没有必要如此细致的配置。Zabbix适用于中型企业专门雇有2-3人运维团队的场景，对于个人非专职而言全套系统一一配置下来还是显得过于繁杂。
当然，Zabbix仍然不失为一个优秀的监控系统。

Nagios

Nagios相比于Zabbix似乎更为的重量级，至少需要1GB的内存和8GB的硬盘来完成一次完整的安装。
与Zabbix提供的一体式解决方案不同，Nagios的系统更加组件化，提供给大型企业更大的自定义空间，组件间耦合度较Zabbix低。
我自己未安装使用过Nagios，因此不作过多评价。

总体而言，Zabbix和Nagios都是企业级的监控方案，主要面对企业用户开发，也适用于企业的应用场景。但是其部署和配置的过程十分烦琐，不符合我们“快速”的宗旨，所以不是特别合适。

第三方监控服务

第三方提供的监控服务从简单到复杂，从免费到收费，几乎应有尽有，只要你肯出钱，没有找不到的解决方案。如果你比较不愿意自己动手搭建，或者不愿意雇佣专职运维，这样的外包服务在公司规模较小的情况下还是很常见的。
当然，这很难满足我们“免费/便宜”原则，可扩展性相比于前文的两个企业解决方案更差。所以第三方的监控服务更适用于希望能够直接外包运维的非互联网甚至非技术型企业。

基于Prometheus

基于Prometheus的监控系统架构一般如下

或是这个简化版

Prometheus本身是一个时序数据库套件，提供了监控系统中的数据收集服务端和数据库的角色（也就是上图中的Prometheus Server部分），官方还提供了报警管理的模块（上图中Alert Manager)，因此我们还额外需要数据展示和数据收集的客户端（上图中Prometheus Target和Data Visualization）。

这一额外的部分有很多的选择。对于Target 可以有各种Exporter 在官方页面有列举。甚至任何支持metric格式输出的数据收集端，比如nNetdata、statsd等。数据可视化我们一般会选择Grafana，当然其它如Grafite等只要支持PromQL查询的都可以。

此套解决方案我不久前部署过，它的优点很多，包括了全部开源，模块化，可扩展性强，可以docker部署，部署非常简单。它也较为的轻量，完全部署仅需30M左右的内存。当然硬盘占用是跟随着数据量的增大而增大的，无数据情况下大约占用200-300M的硬盘空间。

基于InfluxDB

TICK栈

TICK是InfluxData官方主推的监控技术栈。
Telegraf+InfluxDB+Chronograf+Kapacitor，将整套系统拆分成为四个模块，模块化特征明显。因此任意支持InfluxDB读写的数据收集或者监控模块都可以使用。
TICK当然也可以使用docker-compose管理，无论是部署还是迁移都很方便。
Telegraf提供了近百种不同的系统健康信息收集，若是还不够用也可以自己写插件，具有非常强大的可扩展性。
Chronograf集成了Kapacitor的管理功能、InfluxDB的直接查询和Dashboard数据展示功能。不仅如此，前端设计也非常养眼。
同样地，TICK栈也拥有与Prometheus媲美的优势——轻量、可扩展性强等等。下面我们就会讲到使用Grafana扩展数据可视化的功能。

TICGK栈

虽然官方开发的Chronograf已经拥有精美的图表可以显示，但是论数据可视化，Grafana是难以逾越的强大开源方案。因此我们在TICK中加入Grafana，成为TICGK栈，这样一来几乎所有的优点都被涵盖了。虽然五个容器会带来磁盘和内存占用增大的影响，但是对比于异常强大的功能和简单易用的界面，这个技术栈完全适合作者的应用场景。也许在高并发和大数据量的场景下TICGK栈表现会下降，但是作为个人使用，担心并发无疑是杞人忧天。

毫无疑问，最后作者选择部署的就是TICGK栈，使用docker-compose管理（就几个容器没必要k8s吧）。目前状况良好，总体内存占用60M左右，设置了5s的时间粒度，15天周期后预计的硬盘使用是4GB，还是可以接受的。存在一个现象就是5s的粒度会带来Telegraf内存占用问题，开了很多Buffer，但是事实上Buffer什么的并不真正影响啊。

看完作者的选型，你有什么想法呢？欢迎在评论区交流。
才疏学浅，若有错漏，也恳请指正。

敬请期待下一篇——服务器性能监控（二）

对于生产环境下php响应缓慢的问题，一般我们可以把分析流程拆分为如下几步操作：

1.分析开发环境下执行是否会慢；

如果是代码问题，在开发环境下就能检测出来；

2.分析测试机器执行是否会慢；

如果是数据库或者第三方扩展问题，在测试阶段就能检查出来。

3.从生产环境下线一台机器，分析代码执行慢的原因；

如果是机器的问题，在这一步才能检查出来。

1，2，3步骤都需要去分析代码，看哪部分执行时间长。如果迫不得已在生产环境下调试代码，不但要耗费大量时间还可能导致用户流失。

大多时候我们会使用第三方的分析工具xhprof来快速发现问题。‌‌xhprof是由facebook开发的一款非侵入式php性能分析框架。但是官方已经不在维护，也没有跟进php7，只能在php5上运行，tideways则是一直由商业公司在xhprof停止维护后fork出的版本，开源在Github上（托管服务需付费，自行搭建免费），支持PHP7。‌‌显而易见，tideways是我们的选择。

tideways扩展能把每条请求生成详细的执行日志，通过对日志做简单的分析就能看到程序哪部分耗时最长，这里可以使用xhprof的UI程序（xhprof生成的日志和tideways生成的日志格式通用），交互虽然不大友好但是够用了。‌‌当然，也可按照本文介绍使用xhgui来进行可视化的分析。

先决条件

本文部署所用环境为Ubuntu 18.04 LTS，其它环境请自行研究类似的配置。

安装Tideways

由于部署环境php采用编译安装，故Tideways也采用编译安装。‌‌如果采用apt安装，也可以直接使用apt安装php-tideways。‌‌还可以使用pecl安装，具体方法不详细讲了。

‌git clone https://github.com/tideways/php-xhprof-extension
cd php-xhprof-extension phpize ./configure make make install //sudo make install if not root

配置php.ini，加入

extension=tideways_xhprof.so tideways.auto_prepend_library=0 //optional 

注意最好加上后面那行，因为如果不加，tideways会调试所有经过php-fpm的请求，包括xhgui的请求，而这些请求不是我们想看的。

安装xhgui

其实xhgui就是一个网站程序，建过站的同学都知道大概怎么回事，只不过数据库换用了mongodb而已。

安装mongodb

因为xhgui需要储存由tideways传入的信息，所以需要安装mongodb。‌‌另有人维护了一个mysql版本的xhgui，如果不喜欢mongodb可以换用。‌‌部署环境使用了oneinstack安装lnmp栈，所以也使用oneinstack安装mongodb

wget http://mirrors.linuxeye.com/oneinstack.tar.gz tar zxf oneinstack.tar.gz
cd oneinstack ./install.sh // sudo install.sh if not root 

按照提示交互式安装mongodb就行了。‌‌如果你不想这么麻烦或者非生产环境部署，也可以直接使用apt安装：apt install mongodb

如果没有在php中加入mongodb扩展，则需继续安装mongodb扩展。

git clone https://github.com/mongodb/mongo-php-driver.git
cd mongo-php-driver
git submodule update --init phpize ./configure make make install // add sudo if not root >‌

同样地，在php.ini中添加extension=mongodb.so

官方基于性能建议我们为mongodb添加索引

$ mongo "use xhprof";
db.results.ensureIndex( { 'meta.SERVER.REQUEST_TIME' : -1 } ) >
db.results.ensureIndex( { 'profile.main().wt' : -1 } ) >
db.results.ensureIndex( { 'profile.main().mu' : -1 } ) >
db.results.ensureIndex( { 'profile.main().cpu' : -1 } ) >
db.results.ensureIndex( { 'meta.url' : 1 } ) >
db.results.ensureIndex( { 'meta.simple_url' : 1 } )

至此mongodb算是安装完毕。‌‌注意生产环境安装还需要为mongodb配置访问权限，此处不详细讨论了。

下载xhgui

‌ git clone https://github.com/perftools/xhgui

代码下载完以后上传到网站目录，具体操作因环境而异，若不熟悉请先熟悉lnmp架构。‌‌上传完后执行

‌ php /wwwroot/install.php

配置Nginx

假设我们需要调试的网站位于dev.fqdn‌‌而xhgui位于xhgui.fqdn

则需要在dev.fqdn配置文件的location段加入

‌fastcgi_param PHP_VALUE "auto_prepend_file=/wwwroot of xhfui.fqdn/xhgui/external/header.php"; 

此配置的作用是在dev.fqdn下的每个php经过fastcgi的时候自动在开头加入这个xhgui/external/header.php‌‌而这个文件的作用是运行你的代码前调用tideways开启调试‌‌你的代码运行完毕后结束调试并把结果传入mongodb等待查看。

xhgui.fqdn配置则是正常php网站的配置，不赘述了。‌‌注意需有这一行

‌                              location / {     try_files $uri $uri/ /index.php?$args; }

配置tideways

tideways的配置文件位于/config/config.php‌‌安装时这个文件不存在，故需要把默认配置复制到这个文件

‌                              cp <wwwroot>/config/config.default.php <wwwroot>/config/config.php

除了mongodb链接配置（一般无需调整）‌‌主要关注这一个回调函数

‌                              // In config/config.php return array(     // Other config     'profiler.enable' => function() {         return rand(1, 100) === 42;     } );

• ‌

默认配置的此函数仅仅做了节流，截取1%的流量进行分析。这是基于生产环境的性能考虑，如果我们仅仅是在开发环境中使用，就不需要管这么多了。‌‌例如

‌                              // In config/config.php return array(     // Other config     'profiler.enable' => function() {         return true;     } );

• ‌

这个配置就会把所有流量全部截取分析。‌‌令人哭笑不得的是，这所有流量包括了xhgui.fqdn的流量，这显然不是我们想要分析的。‌‌还有的时候我们也不想看到dev.fqdn中管理界面的流量，这就需要一些进阶配置了。‌‌例如

‌                              'profiler.enable' => function() {         $url = $_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];         if (strpos($url, 'dev.fqdn/admin') === 0) {             return false;         } elseif (strpos($url, 'dev.kucloud.win') === 0) {             return true;         }         return false;     },

• ‌

这样一来就只会看到我们希望分析的请求了。

参考：‌‌

phperzh‌‌

Xhgui

Readme

最近把博客从RFCHost家的洛杉矶GIA CN2小鸡上搬到tsukaeru的日本IIJ线路的VPS上，价格相差无几，但tsukaeru家的适合建站，所以我就把博客搬过来了

GIA CN2虽然线路很好，但是配置实在有点低(估计主要跨Wa11上网用)。tsu家这台IO非常不错，接近bwg家的1Gbps
,还给免费50G备份空间，2H1G 50G SSD。原来那台是1H512M 10G SSD ,装完lnmp就60%占用了！最近tsu促销，果断搬迁博客。
以下是搬迁过程中遇到的问题和解决方案

Access denied & No input file found

这个是老问题了，网上也有很多地方有解释，官方安装教程也有。
就是那个cgi.fix_pathinfo
把php.ini文件中的cgi.fix_pathinfo=0改成cgi.fix_pathinfo=1就行了
php.ini文件在哪里？
对于oneinstack安装的php，在/usr/local/php/etc/php.ihi
对于ubuntu系统自带的php在/etc/php/fpm/php.ini
实在找不到可以放大招：phpinfo();
在命令行使用交互模式(php -a)输入phpinfo();仔细找一找php.ini的位置
什么？输出太多不想找？
那只好系统帮我找一找了

echo 'phpinfo();' > 1.php
php 1.php | grep 'php.ini'

当然你也可以暴力一些

find php.ini /

首页正常二级页面全部404

这是typecho伪静态的问题，需要向nginx配置文件http->server的内部添加

if (!-e $request_filename) {
      rewrite ^(.*)$ /index.php$1 last;
}

fastcgi_params配置

nginx给出的默认配置文件在http->server->location块使用

fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
include        fastcgi_params;

但是Oneinstack的处理是将SCRIPT_FILENAME加入fastcgi_params中，我个人认为这种做法更清晰明了，推荐这样的做法。

目录权限

我每次安装typecho都是直接clone项目在复制的(反正最近的commit都是修bug)，有时会有权限问题
根目录下

var
usr/themes
usr/uploads
usr/plugins

这些目录最好都
chown -R www:www

缓存插件TpCache

Github项目
这个插件应该是比较完善的，据作者readme,原生评论测试过可以更新缓存。第三方评论就更加没所谓啦。

启用之前要先在服务器安装好Memcached、memcache或Redis，据说Memcached在键值较大时性能较优，本博客就选择的是Memcached。
当然一键包啦，安装和php扩展一并搞定。
哦对了，推荐一键包Oneinstack
直接下载Oneinstack不含源码版
个人认为比军哥的lnmp.org的要好(而且开源)

Comment2Mail

这是常规啦
只是为什么总是发件人Root root@localhost
我明明配置的是Sendgrid的smtp发信啊
难道源码有问题？
有谁知道吗？

数据迁移

typecho自带的导出导入已经基本够用了
但是之前曾经用过iviews插件，修改过数据库结构(也不告诉我……)到了导入的时候出错了(typecho也真是奇怪，导出不检查数据库结构，导入检查)
不想改动数据库，干脆在原来那里删了那张views表
嗯
所以还是我的NewMaterial主题好，用自定义字段统计，不乱改数据库。

暂时想到的就这些吧
其他的服务器安全加固等等就不写在这里了

最近写模板又遇到问题了，同样的代码在测试机上正常工作，换到线上又出错了，后来一看，是php7的锅……

php7+中isset()函数在判断类成员是否设置时的行为与php5.6有所不同。 我们先来看看php的官方git commit message

PHP 7 has fixed a bug with __isset which affects both the native isset and empty methods. This causes specific issues 
with checking isset or empty on relations in Eloquent. In PHP 7 checking if a property exists on an unloaded relation, 
for example isset($this->relation->id) is always returning false because unlike PHP 5.6, PHP 7 is now checking the offset of each attribute before chaining to the next one. In PHP 5.6 it would eager load the relation 
without checking the offset. This change brings back the intended behavior of the core Eloquent model __isset method 
for PHP 7 so it works like it did in PHP 5.6.

For reference, please check the following link, specifically Nikita Popov's comment (core PHP dev) - https://bugs.php.net/bug.php?id=69659

假设我们有如下php代码

<?php

class Post
{
    protected $attributes = ['foo' => 'bar'];

    public function __get($key)
    {
        if (isset($this->attributes[$key])) {
            return $this->attributes[$key];
        }
    }
}

$post = new Post();
echo isset($post->foo);  // false

我们会发现无论如何isset总是返回false
因为变量foo不是类Post的成员
也就是说，PHP7开始，isset执行前不会先执行->
也就是__get()函数

当然也可使用魔术方法__isset解决此问题

<?PHP
class Post
{
    protected $attributes = ['foo' => 'bar'];

    public function __get($key)
    {
        if (isset($this->attributes[$key])) {
            return $this->attributes[$key];
        }
    }

    public function __isset($key)
    {
        if (isset($this->attributes[$key])) {
            return true;
        }

        return false;
    }
}

$post = new Post();
echo isset($post->foo);   //true

此时我们可以看到isset()返回了true
因为我们对类Post执行isset()时调用了我们定义的__isset()函数，而__isset()函数中的isset()是可以访问foo的，故此处返回true

当遇到isset($widget->fields->$var)
这样的写法时
php5.6 和以前会先执行$widget->fields->$var
php7则会在每次调用前执行isset
于是typecho常用的判断自定义字段是否为空的代码
isset($widget->fields->$var)
总是返回false
网上大多数判断typecho自定义字段是否设置的教程都直接使用isset函数，当然会在php7的线上环境下出问题啊。
从兼容性角度考虑，建议还是写

if ($widget->fields->$var !== NULL){
    //code...
}

比较保险。

原理

主要利用的是Github的公钥公开地址‌‌比如我的是Github keys‌‌形如https://githib.com/{username}.keys

使用

每次只要执行curl https://…. >> .ssh/authorized_keys‌‌就可以快速搞定了

还要注意权限问题，如果原本就有.ssh/authorzied_keys就没什么问题‌‌若是新创建的要.ssh 700‌‌.ssh/authorized_keys 600‌‌ssh对公钥读写还是有安全要求的。

居然有大佬写了个脚本？SSHKEY_Installer

一阵无语……

这个脚本有一个好，顺便帮忙关了密码登录。搞定了.ssh目录下的权限问题。

无论是Systemd和Supervisord都可以用于控制进程，实现进程的分组管理和崩溃自动重启，下面我们看看他们都是怎么实现的。

进程控制

无论 Supervisord 还是 Systemd，都采用 ini 作为配置文件的格式。跟 Supervisord 不同的是，Systemd 每个程序都要单独开一个 unit 文件。
Supervisord 可以同时启动/停止配置文件中所以的进程（或者某个进程组配置中的进程）。
也就是说，Supervisord 使用“进程组”这个概念来控制多个进程
Systemd 则用用依赖来实现这一点。

我们来看一个简单的Systemd配置文件，实现了进程组管理

; group.target
[Unit]
Description=Application
Wants=prog1.service prog2.service

; prog1.service
[Unit]
Description=prog1
PartOf=group.target

[Service]
ExecStart=/usr/bin/prog1
Restart=on-failure

; prog2.service
[Unit]
Description=prog2
PartOf=group.target

[Service]
ExecStart=/usr/bin/prog2
Restart=on-failure

systemctl start group.target ，prog1 和 prog2 也会启动。systemctl restart group.target，prog1 和 prog2 也会跟着重启

相比起来Supervisord的管理方式就要明了一些了

[program:prog1]
command=python /home/user/myapp/prog1.py

[program:prog2]
command=python /home/user/myapp/prog2.py

[group:prog]
programs=prog1,prog2

supervisorctl start prog:*可以启动prog组下的所有进程

如果要更改 supervisord 的配置文件，supervisord 需要运行 supervisorctl reread 才会生效。
而 systemd 则需要 systemctl daemon-reload。这方面两者差不多
不过 supervisord 有一个优点。如果你不知道哪些程序的配置改变了，简单地执行 supervisorctl update，所有涉及的进程都会被重启。
而 systemd 貌似做不到这一点。

systemd 可以指定 stop 操作时可以选择的命令（ExecStop=）。另外它还提供了 ExecReload=，可以自定义调用 systemctl reload xxx 重新读取程序配置文件时的操作。
supervisord 不支持 reload 指定进程。同时对于 stop 操作，它只允许你选择要发送哪种信号…

supervisord 的 stopwaitsecs 可以控制 stop 操作后等待程序退出的耐心（以秒衡量）。待给定的耐心都消耗完毕后，supervisord 才会痛下杀手，发送 SIGKILL。
systemd 对应的配置项是 TimeoutStopSec=。systemd 会给多一次机会，在下最后通牒之前，会先发送 SIGTERM，过另一个 TimeoutStopSec 之后才发送 SIGKILL。

对比

systemd 和 supervisord 各有长短，不存在哪一方绝对的碾压。
systemd 跟 Linux 紧密结合，主流的发行版几乎全部使用systemd，所需的依赖少，其提供的保障自然比 supervisord 更可靠。然而在强大的能力背后，也有配置复杂、不易上手等问题。
systemd使用C语言编写，启动速度要快于supervisor，因此底层和对可用性有较高要求的情景，systemd还是更加适应的。
supervisord 偏于应用层，却因此有独特的用武之地。
举个例子，许多人会往 docker 打包里面封入一份 supervisord，让它来做 PID 1，以此稍微增强下健壮性。
supervisord还有XMLRPC接口，使得它和上层应用更容易结合，无论是否是Python应用。

换 systemd 做同样的事，就像用园艺剪刀裁纸，即使能够顺利完成，也难免事倍功半。毕竟这样的方式跟 systemd 的设计是背道而驰的。

至于健壮性的对比，我没有做过实验不知道，但两者都是经过多年检验过的项目，健壮性对于小型服务来说都是足够好的了。

[萌咖][1]有个域名,托管在dns.he.net,有500多个A记录要删除.
但是他官网不提供多选的功能.
所以花了点时间写了一个工具,支持批量删除记录.

特点:

支持删除操作.
支持适配sub,进行删除.
支持添加记录.
更多待续…
用法:

下载地址:

wget --no-check-certificate -qO 'he.sh' 'https://moeclub.org/attachment/LinuxShell/he.sh' && chmod a+x he.sh

使用:

• 可用参数

bash he.sh -u [用户名] -p [密码] -del/-add -sub -d [域名] -n [子域] -r [记录] -t [记录类型]

• 添加一个记录

bash he.sh -u [用户名] -p [密码] -add -d [域名] -n [子域] -r [记录] -t [记录类型]

• 删除一个记录

bash he.sh -u [用户名] -p [密码] -del -d [域名] -n [子域]

• 删除一批以某些字符开头的记录

bash he.sh -u [用户名] -p [密码] -del -sub -d [域名] -n [子域]

解释:

www.moeclub.org
子域: www
域名: moeclub.org

全文转载自[萌咖][1]
[1]: https://moeclub.org

Daocloud目前免费提供两个docker容器供大家免费使用，有没有想过用它们来干些什么？
Daocloud目前提供2个docker容器共免费使用，所以就可以自己做一个小小的私有云啦！要是你想要更多的空间或是更快的响应速度和带宽，可以购买更多容器集群，14元rmb一个容器每月。

为什么要选择私有云

有人可能会问，既然百度、360、微云都已经做的可以了，速度不算太慢，存储空间甚至大的恐怖，那为什么还要使用私有云啊？
使用公有云有几个弊端：

• 个人隐私难以保证。百度等云盘有“秒传”功能，实际上就是在上传前先检测在服务器上是否有相同的文件，然后把这个文件转到你的盘里。可是这样一来，你的数据毫无隐私可言了。国外的云盘一般都会保证不查看用户数据，但可惜都被墙了
• 数据安全难以保证。有没有发现你分享的文件可能过几个月甚至几天就失效啦？由于相关法律和规定删除了文件？国内的网盘都有这样的问题
• 对纯浏览器用户不友好。“高速下载请先安装百度云管家”“下载请用客户端登录”，怎么就不能直接下载呢？
• 捆绑的广告多。“试用加速包”“开通会员”，还有各种广告泛滥，怎么这么烦人啊

这就是为什么我们需要私有云，私有云克服了几乎以上所有缺点：

• 个人隐私保证。
• 数据掌握在自己手里。
• 无需客户端直接上传下载。
• 绝对干净无广告。
• 免费自带离线下载功能。
• 在线打开文件。
• 多用户管理。

当然私有云也有缺点：

• 免费空间少，多空间需付费。
• 响应相对慢。
• 需要一些技术知识

当然相信看到这里的都是技术客，就不需要担心技术问题了

注册帐号

注册这种事情就不说了，相信大家都懂

新建服务MySQL

添加一个新的集成服务MySQL，Daocloud提供的两个容器其中一个就用在这里，可以获得128MB内存，2GB存储的MySQL服务，这时记住服务的内网IP地址、数据库名、用户名和密码。
如果喜欢postgreSQL可以换为postgreSQL，步骤基本相同

新建镜像Owncloud

在daocloud的镜像仓库里找到owncloud的镜像直接布署，或者如果你想要离线下载功能的话，可以找别人的owncloud-with-osdownload镜像布署，版本选最新的

绑定服务

镜像布署完毕后选择绑定服务，绑定之前创建的MySQL

配置owncloud

通过Daocloud给的访问地址访问owncloud，会看到owncloud的配置界面，这时设置管理员帐号和密码，数据库选择MySQL/MariaDB（布署了postgreSQL的选择postgreSQL）输入刚才记下的服务IP、数据库名、用户名和密码，等待owncloud配置好数据库就可以啦，刷新页面就可以看到自己的owncloud私有云了

这个私有云很安全稳定

鉴于Daocloud的免费服务很不稳定，owncloud镜像每隔几天就要重新启动一次，也就是说每隔几天就要重新配置数据库，虽然数据不会丢失，但是总要配置很烦，所以还是建议大家想要稳定私有云的同志购买付费服务。或者购买vps