基于树莓派搭建轻量化的私有DveOps系统
前言：
关键字：Raspberry Pi、FileBrowser、Gitea、Jenkins、Nginx、Registry、SSHWifty、V2Ray；
已经很久没写文章了，主要是工作实在是太忙了，回到家就只想睡了；另一方面是懒，搭建并写这些东西实在是太花时间了！！！其实这一个新年，博主很早就休假了，于是博主计划是写点什么的，不过这假期，博主实在是放飞了自我，足足打了一个假期的游戏……当然，期间其实并不是什么也没做的；假期间拿到了一间已倒闭的创业公司[政策原因]的棋牌源码，本想搭起来给朋友私人玩玩的。花了几天时间看部署文档，没搭起来，有几方面原因：一、部署文档实在是写得太烂了，TXT文本还乱，据说是开发兼职运维/架构写的文档；二、代码是两年前的，很多软件源、依赖什么的，都过时了，要搭建起来，要查很多资料；三、这其实是主要的原因，朋友说，微信上有免费的……；于是吧，这花了几天时间；
当然，其实游戏服务器能不能搭建起来对读者来说没什么影响，因为游戏服务器即使搭建起来了，我也不会特别写一篇博文的。实际上呢，自从树莓派8G版出来后，博主一直是想升级一下自己的私有服务器的；为了能尽量利用树莓派8G的性能，博主希望在上面跑更多的服务，于是吧，DevOps系统，应该是最好的选择了。之后，就是DveOps系统的搭配了，博主是试过GitLab、Harbor这类系统的，后来发现，这些东西实在是太重量级了，运行了一堆服务，私人使用，不实际还浪费资源[其实也只是多一点电而已]……于是，博主在找一些轻量化的代替。找是找到了很久了，单独部署还好，但要把它们整合在一起，实在是麻烦啊，各有各的部署要求；搭建时确定了一种部署方案，结果却发现和后面的服务的部署要求产生了冲突，于是，又再一次的修改整合方……
废话博主是很喜欢说的，现在说完了，这个DevOps系统有什么？见上面的关键字。这套系统，博主提供的模板，是以局域网内使用的为示例的，当然，这是可以用于公网的！！！博主怎么可能会花时间搭建一套只能在局域网内使用的系统。之所以以局域网为示例，这也是无奈啊，要公网使用，还需要很多其它知识或修改，还需要一些配套硬件[例如花生壳的内网穿透，还要买它的HTTPS服务]，总而言之，就是变数太多了，很难写成模板。不过话说回来，其实本来是可以很简单的，如果不是运营商封80、443端口，所以，你懂的……这说吧，如果不是80、443，如果不是花生壳只有一个固定的域名，两者中只要有其中之一不被限制，这个模板可以更好更简单，读者也可以很方便的暴露至公网使用了。无奈，环境就是如此，接受吧……读者是可以修改博主提供的压缩包中的配置，配合花生壳及其HTTPS服务，实现公网访问的[主要为修改NGINX配置]~当然，如果你不是像博主这种强迫症，非要使用80和443，你完全可以使用路由器的端口映射功能+动态域名功能实现公网访问~~
最后，博主其实还想加入VSFTPD和RSYNC容器的，不过又要写DOCKERFILE啊，没时间了，就这样吧~
更新！！！
2021年03月03日，已更新至V2.01版本，下载地址见百度网盘连接！！！
另注：本篇博文是按V1.00版本写的，所以……你很大机会会对不上V2.01的内容；
V2.01相对V1.00增加了以下内容：
1、增加了"vsftpd_home"容器；
2、增加了"rsyncd_home"容器；
3、优化了目录结构，现在镜像构建文件与挂载至容器内使用的文件不会是同一份文件；
4、修正了"docker-compose.yaml"中的"TZ"变量定义的错误写法；
5、修正或增加了有关NGINX的配置文件，现在的文件中提供了公网使用的一些写法示例；
6、修正了DOCKER容器与系统时间不统一的问题；
7、优化了说明文件，增加了目录结构说明文件；
[2022.05.01]失效说明
V2版本中的关于JENKINS的插件下载加速已失效！！！请自行更新代码！！！
一、硬件与软件环境
本教程在以下环境下搭建测试通过！
注1：本套轻量化的DevOps系统依赖于DOCKER与DOCKER-COMPOSE，请自行搭建对应环境或见本博客的其它博文中部署方法；
注2：一定要阅读所提供的压缩包中的"readme"！！！"readme"中的初始化命令是以"root"用户执行的，如果你是默认的"pi"用户，请在命令前加"sudo"；
注3：提供的部署压缩包是树莓派专用的，即CPU是ARM架构。X86架构使用需要替换掉当中一些二进制文件[例如：gitea文件]，可能需要修改DOCKERFILE，可能需要更换DOCKER镜像；
注4：直接复制博文中的代码请注意不可见字符问题，见其它博文中的说明[红色字体]；
下载地址：百度网盘[ https://pan.baidu.com/s/1__x8Z5EVjkjR95eUdA3pWQ ] ｜ 提取码：wuxu
-
硬 件 ：Raspberry Pi 4B -- 8GB版
-
操作系统 ：Raspbian Buster Lite
-
依 赖 ：docker + docker-compose
-
测试日期：2021年02月22日
二、系统目录结构解释
从百度网盘下载树莓派专用的轻量化系统的压缩包，解压后，读者将得到以下的目录结构；另外再次补充提醒，记得阅读当中的"readme"，解决问题的方法很多时候会在此文件提到：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
$ tree -L 3 homeserver/ homeserver/ ├── docker-compose.yaml # 容器编排文件 ├── Documents # FileBrowser的储存目录[原计划用于与VSFTPD共享数据] ├── filebrowser_home # FileBrowser │ └── server_conf # 镜像构建目录/配置目录 │ ├── Dockerfile # Dockerfile │ ├── filebrowser # 二进制执行文件[ARM][可更新] │ └── filebrowser.json # 配置文件[既用镜像构建，也用于启动时替换容器中的配置] │ ├── gitea_home # Gitea │ └── server_conf # 镜像构建目录 │ ├── Dockerfile # Dockerfile │ ├── gitea # 二进制执行文件[ARM][可更新] │ └── root # 镜像构建的必要文件[可更新][详见GitHub相关项目] │ ├── jenkins_home # Jenkins │ └── jenkins_data # 数据保存目录[权限要求"1000:1000"] │ ├── nginx_home # Nginx[同时也保存着私有镜像仓库的前端文件] │ ├── html # 私有镜像仓库的前端文件[可更新][详见GitHub相关项目] │ │ └── ... │ ├── logs # 日志保存目录 │ ├── nginx_conf # Nginx配置目录 │ │ ├── conf.d # Nginx所有子配置文件[域名定义在此目录中] │ │ ├── nginx.conf # Nginx全局配置文件 │ │ └── ssl # Nginx证书目录 │ └── server_conf # 镜像构建目录 │ ├── dist # 构建用的私有镜像仓库的前端文件[可更新][详见GitHub相关项目][同"html"目录中的内容] │ ├── Dockerfile # Dockerfile │ └── entrypoint # 镜像构建的必要文件[可更新][详见GitHub相关项目][作了部分修改] │ ├── registry_home # Registry[私有镜像仓库的后端] │ └── server_conf # 配置目录 │ ├── config.yml # 配置文件[启动时替换容器中的配置] │ └── htpasswd # 私有镜像仓库的认证配置文件 │ ├── sshwifty_home # SSHWifty │ └── server_conf # 配置目录 │ ├── private_key # 保存使用SSH公钥验证连接时，所使用的私钥[基于预设连接使用] │ └── sshwifty.conf.json # 配置文件[启动时替换容器中的配置] │ └── v2ray_home └── server_conf # 镜像构建目录 ├── config.json # 配置文件[启动时替换容器中的配置] ├── Dockerfile # Dockerfile └── v2ray # V2Ray的相关文件[ARM] |
三、部署与访问
以下假设你的树莓派已安装了"docker"与"docker-compose"；示例：1、从百度网盘下载"homeserver.zip"压缩包并解压；2、用你的方法，将"homeserver"目录上传至树莓派的"/opt/"目录下[实际上可以是任意目录]，执行以下命令；
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# 以下命令在"root"身份下执行，非"root"用户名，如"pi"，请在命令前加"sudo"！ # 进入"/opt/homeserver"目录，在该目录你应见"docker-compose.yaml"文件 cd /opt/homeserver # 权限修正 chown -R 0:0 /opt/homeserver find ./ -type d | xargs chmod 755 find ./ -type f | xargs chmod 644 find ./gitea_home/server_conf/root/etc/s6 -type f | xargs chmod 755 find ./gitea_home/server_conf/root/usr -type f | xargs chmod 755 chown -R 1000:1000 ./jenkins_home/jenkins_data # DevOps系统启动 docker-compose up -d # DevOps系统状态检查[所有容器应处于"UP"状态] docker-compose ps |
在所有容器正常启动后["UP"状态]，即表明DevOps系统部署成功！！！之后，就是使用模板中已经定义好虚假域名"home.domain.local"访问各容器的WEB服务了，以下以WINDOS操作系统为示例。以下假定你所部署的树莓派的IP地址为：192.168.10.10！
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# HOSTS文件域名解释设定 # 由于是使用虚构的域名"home.domain.local"，所以访问的客户机需要修改"hosts"文件！ # [WINDOWS] -- [ c:\windows\system32\drivers\etc\hosts ] # 可以直接运行以下命令打开此文件: # notepad c:\windows\system32\drivers\etc\hosts # 新建一行加入以下配置： 192.168.10.10 home.domain.local # [LINUX] -- [ /etc/hosts ] # 可以直接运行以下命令打开此文件: # vi /etc/hosts # 新建一行加入以下配置： 192.168.10.10 home.domain.local |
在完成"hosts"文件的域名解释定义后，即可通过"home.domain.local"访问树莓派上各容器所对应的WEB服务。DevOps系统的NGINX配置中，默认为所有的HTTP请求均重定向为HTTPS请求，由于所使用的HTTPS证书为自建证书，所以浏览器会提示证书不受信任，解决方法有两个：1、将证书添加至信任；2、无视提示直接访问；
压缩包中所提供的自建证书为泛域名证书，即"*.domain.local"，读者完全可以修改NGINX的配置文件，改成你所喜欢的域名，例如"devops.domain.local"，但记得作好对应"hosts"文件的域名解释；另外，自建的泛域名证书的有效期为100年，有生之年应该不会过期[博主希望能见到过期的那一天]……
WINDOWS的"hosts"文件的域名解释已经在前一步完成了，现在，我们可以在WINDOWN的浏览器中，使用域名"home.domain.local"访问我们的服务了，以下为NGINX中对各服务的访问地址定义：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
FileBrowser # 类似百度网盘的文件服务 # # 访问地址：home.domain.local/file # 默认用户：admin # 默认密码：admin Gitea # 类似GITHUB的服务 # # 访问地址：home.domain.local/git # 初始化地址：home.domain.local/git/install Jenkins # 非常流行的CI/CD工具 # # 访问地址：home.domain.local/jenkins # 初始访问口令：[用以下命令在服务器上获取] # $ docker exec jenkins_home cat /var/jenkins_home/secrets/initialAdminPassword SSHWifty # 一个WEBSHELL，当你手上没有XSHELL时，这可以临时使用 # 暴露于公网，意味着在任何有电脑的地方均可以访问你的服务器，甚至可以用手机 # 当你手上没有XSHELL时的临时代替品 # # 访问地址：home.domain.local/sshwifty # 默认密码：Adminroot888 Registry # 私有Docker镜像仓库 # # 访问地址：home.domain.local # 默认用户：adminroot # 默认密码：Adminroot888 V2Ray # 网络改变生活，世界触手可及工具，请使用你自己的配置 # # 访问地址：无 非WEB服务 |
以上为本套DevOps系统的基本访问方法，而这也仅仅是基本的访问，实际上，要使这些服务真正的生效，或要正常的使用，还可能需要一些额外的配置，相信博主，博主是测试过的，的确可用，但有些功能的使用，还需要你在WEB配置界面或客户端上做一些额外的配置才能正常使用；
四、服务配置
在可以对各WEB服务进行基本访问后，读者就可以进行自定义的配置了，多参考一些网上的配置教程；另外，请多读"readme"文件，各服务的一些使用方法或配置方法的要点，博主均记录在"readme"文件中。此部分内容博主不知道有没有时间更新了，如遇到问题，也可留言，虽然博主不知道什么时候才会看到，不过一定会回复，但可能是一两个月，因为真的没时间看这个博客……另外博客并不是这个云主机的主要用途……
以下为待更新[极可能不更新，博主觉"readme"中的内容其实已经足够了]，另外，每个服务的配置，其实都可以写一篇博文了，而博主可以在这篇博文中说明的，也仅仅只是一些要点……
FileBrowser配置/使用/更新：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# [配置] # 在 FileBrowser 中，新建/上传文件的权限默认被设定为"755"，这是FileBrowser的默认设定； # 对任何文件设定权限为"755"，这是非常不合理的！！！ # # 解决方法： # 1、以管理员用户登录 # 2、设置：[ 在Shell中执行 ]配置项设定为 --> bash -c # [ After Upload ]配置项设定为 --> chmod 644 $FILE # 3、重启生效：$ docker restart filebrowser_home # [更新] # 更新Filebrowser的方法有以下 # # 1、从GITHUB下载最新的二进制执行文件，修改"docker-compose.yaml"，利用挂载的方法， # 替换"filebrowser"文件； # 2、从GITHUB下载最新的二进制执行文件，替换掉"filebrowser_home/server_conf/filebrowser"中的"filebrowser"， # 执行"$ docker-composer up -d --build"重新构建镜像并运行系统； # 3、修改并调整"docker-compose.yaml"中的内容，直接利用项目作者的镜像； |
Gitea配置/使用/更新：
|
1 |
# 待更新 |
Jenkins配置/使用/更新：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
# [首次使用] # 首次部署，Jenkins会生成一随机口令，需要使用此口令以继续对Jenkins进行配置； # 请使用以下命令获取首次访问口令； # # $ docker exec jenkins_home cat /var/jenkins_home/secrets/initialAdminPassword # [插件下载加速] # 插件下载加速已默认生效了，使用的是清华的Jenkins仓库，首次部署你可以放心的安装官方所推荐的插件了； # 生效原理见： # 1、NGINX配置文件："nginx_home/nginx_conf/conf.d/jenkins_nginx.conf"； # 2、"docker-compose.yaml"文件中的"26-28"行及"111-112"行； # [插件下载地址] # 官方默认：" https://updates.jenkins.io/update-center.json " # 清华加速：" https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json " # # 博主对比过两份文件，完全一样的； # 如果之后你对插件下载地址更新为"清华加速"的地址， # 你唯一可再获得的好处是下载"update-center.json"这份文件会快一点； # [注意] # 因为插件下载加速配置的原因，系统中的JENKINS服务只适合国内使用，谨记！！！！ |
SSHWifty配置/使用/更新：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
# [说明] # 一个非常不错的WEBSHELL；但一定要谨慎使用，请至官方项目中了解其原理后再暴露至公网使用； # 不清楚原理暴露至公网使用可能产生以下影响： # 1、完全丢失服务器所有权[认证弱密码+基于完全的服务器预设值配置] # 2、成为网络攻击的代理跳板[认证弱密码+允许自由连接SSH/TELNET配置][无认证+允许自由连接SSH/TELNET配置] # [暴力破解] # SSHWifty的基本认证方式不能防止暴力破解，在暴力破解成功后，在可使用状态下的最安全配置方式下， # 你至少会丢失服务的IP/域名地址+端口信息；目前最安全的方式为： # [ 强认证密码 + 仅预设配置可连接至目标服务器 + 预设值仅包含{"Host": "www.example.com:22"}配置 ] # [认证密码]｜[使用]｜[配置] # 文件"sshwifty_home/server_conf/sshwifty.conf.json"为主要配置文件 # 配置均通过此文件实现； # # 认证密码设定见"sshwifty_home/server_conf/sshwifty.conf.json"中的"{"SharedKey": "Adminroot888"}"配置项 # [私钥目录] # 目录"sshwifty_home/server_conf/private_key/"用于保存服务器私钥[使用密钥链接SSH服务的预设配置使用] # [HTTPS] # 基于部分浏览器的安全机制，在浏览器的默认安全配置下，SSHWifty必须使用HTTPS访问，已通过NGINX配置解决； # [更新] # 1、直接利用项目作者的镜像； # 2、自己写DOCKERFILE，利用项目源码重新构建二进制可执行文件； |
Registry配置/使用/更新：
|
1 |
# 待更新 |
V2RAY配置/使用/更新：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
# [说明]： # V2RAY的服务器，你懂的，入面的默认配置文件无任何实际意义， # 请使用你的配置文件替换它[/v2ray_home/server_conf/confing.json] # 容器暴露的端口实际没任何意义，应以你的配置文件为准以修改使用； # 设计理念为： # "1080"用于SOCKS代理 # "2080"用于HTTP代理 # [配置] # 配置文件"v2ray_home/server_conf/config.json"将会在系统运行时挂载至目录内； # 你可替换此文件以使用你自己的配置； # [更新] # 更新方法有以下 # # 1、从GITHUB下载最新的程序文件，修改"docker-compose.yaml"，利用挂载的方法， # 替换"v2ray"目录的内容[容器内V2RAY的目录路径为"/usr/bin/v2ray/"]； # 2、从GITHUB下载最新的程序，替换掉"v2ray_home/server_conf/v2ray/"目录中的所有内容， # 执行"$ docker-composer up -d --build"重新构建镜像并运行系统； # 3、修改并调整"docker-compose.yaml"中的内容，直接利用项目作者的镜像； |
五、公网访问
本套DevOps系统，只需要稍作修改便可用于公网访问，当然，前提是知道怎么修改[废话]！修改的要点是NGINX的配置与"docker-compose.yaml"，原因是与域名有关，当然，NGINX的公私钥也是需要考虑的范围；
本套DevOps系统设计时，是以单域名/固定域名[例如：home.domain.local]，并配合"域名+子路径"的方式以区分各个WEB服务的，这么设计的原因是：用于配合动态域名解释功能，以保证服务能在公网访问，这是博主做了各种测试最后确定的可行方案。对于拥有固定公网IP，并已经备案了80、443服务的个人或公司，实际有比直接使用本套系统更好的配置方案，比方说，使用"gitea.domaim.local"的域名去访问Gitea服务，使用"file.domain.local"去访问FileBrowser服务；如此设置能更简单融合各种服务并便于管理；
将本套DevOps系统应用于公网，大概有以下两个思路：
一、不使用80、443端口：这是最简单的方法，只需要在路由器上配置"端口映射"+配置"动态域名解释"即可；唯一而且明显的缺点是，在公网访问各个WEB服务，均要特别的手动指定端口号；
二、使用80、443端口：这情况下，路由器上的"端口映射"与"动态域名解释"功能已经没有任何意义了，你需要购买一些额外的硬件，例如花生棒之类的内网穿透硬件，同时还需要购买其对应的HTTPS服务，还要依据实际情况修改NGINX的配置与"docker-compose.yaml"，这显然就比上一种方法复杂多了。好处很明显，访问各WEB服务不再需要特别的指定端口了，在公网看上去，就和访问任何普通的网站一样。另外补充一个此方法的重要缺点，就是内网穿透硬件都有流量与带宽限制，例如博主的花生棒，每月的访问流量被限制在2GB，带宽被限制在1M，这意味着，即使你有FileBrowser，但你想传什么大文件？？？
花生棒？？？
这里说一下这个东西，我们如果购买花生棒，那就是要使用他的内网穿透功能了，那么明白它的能实现80、443访问的原理，那将有助于你调整NGINX的配置；以下为数据流向，看了下面，你就知道为什么花生棒这个东西有流量与带宽限制了；
80端口：WEB浏览器[HTTP协议] --> 花生棒服务器[HTTP协议] --> 花生棒[HTTP协议] --> DevOps系统
443端口：WEB浏览器[HTTPS协议] --> 花生棒服务器[将HTTPS协议转换为HTTP协议] --> 花生棒[HTTP协议] --> DevOps系统
对于花生棒协议的转换，这只是博客从测试结果中总结的猜测，并不一定是实际情况；关于公网访问，就写这么多了~~~
六、GITHUB项目
以下部分使用到的GitHub项目，读者可自行至项目中获取使用方法：
|
1 2 3 4 5 |
# GITHUB项目 # FileBrowser https://github.com/filebrowser/filebrowser # Gitea https://github.com/go-gitea/gitea # SSHWifty https://github.com/nirui/sshwifty # V2RAY https://github.com/v2fly/v2ray-core |
结、后记
在写这个系统的目录结构时，发现了一点问题，博客主在设计这套系统时，目录的功能用途设计有点问题，具体为名称"server_conf"这一个目录，原来的设想是把配置类文件与构建必要文件统一放进此目录中的，实际也是这样做的；但是，在写目录结构文档时，发现这一做法引起了混乱，具体表现为，当系统部署完成后，要对容器进行具体配置时，配置文件的位置不统一[这同时影响了"docker-compose.yaml"中的设定]，配置文件文件有时在"server_conf"中，有时却不在；另外，在"Dockerfile"构建镜像时，有时又会用到对应的配置文件，这导致了各种混乱，也使"server_conf"目录的作用表现混乱；更好的做法应该是把"server_conf"分为两个目录[例如"svr_conf"与"build"]，分别入容器运行状态的配置文件与镜像构建时所有使用的文件，这样设计的话，当在系统运行状态时，可以非常方便的在统一的"srv_conf"中寻找对应的配置文件。
但无论如何，博主不想再重写了，主要是不想再重写这一篇博文；也许博主会再发一套V2版本的压缩包实现上述说明，但重写博文，就算了……《完》
基于树莓派搭建轻量化的私有DveOps系统：等您坐沙发呢！