目前 Linux 发行版都集成 SystemCtl 做系统管理, 现在如果要把二进制应用写入成系统应用基本上绕不开.
Systemctl 的服务基本可以分为以下类别:
service: 常规服务
timer: 定时器
mount: 挂载点
device: 设备
socket: 套接字
这里先从基础的自定义 service 编写服务开始:
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451 ...
日常使用自动化脚本的时候常常会出现这种问题: 如果创建专用系统账户如果执行系统服务命令要么需要 sudo 输入密码, 要么就是无法使用命令
像是这种情况在日常当中也是十分常见, 好处也是很明显直接低配权限防止被入侵的时候完全掌控服务器:
123456# 如果想以非 root 用户重启 nginx, 以下命令是无法生效# 如果你的用户组正好是 sudo 组, 则会提示你必须手动输入用户密码确认启动systemctl restart nginx# sudo 组则是需要通过以下方式sudo systemctl restart nginx
但是在自动化运维的时候就很麻烦了, 引入不可能调用这些命令还要让你手动输入密码, 毕竟都自动化了肯定不能这样操作
所以这里就衍生出 visudo 和 NOPASSWD 概念, 通过配置可以让指定用户或用户组执行 sudo 命令时无需输入密码:
12# 进入 sudo 配置菜单, 注意调用的默认编辑其是 nano 而非 vi/vimsudo visudo
这里内部每一行就是定义权限:
12345678910username ALL=(ALL) NOPAS ...
Cockpit 是开源的 Linux 服务器图形化管理工具, 专为简化服务器运维工作设计, 适合中小规模环境搭建使用.
一般用于常规 nas 或者 10 台服务器管理规模这类日常服务器运维
基本上主流的 Linux 都集成在包管理之中, 直接运行以下命令就可以安装:
12345# debian 系sudo apt install cockpit# redhat 系sudo yum install cockpit
默认启动的服务端口为 9090
cockpit 并不是 EXSI 和 PVE 这种专门虚拟化管理那种专业化的虚拟化平台, 仅仅是作为界面化运维管理;同时也不具有底层系统级别的管理能力, 且不具有大规模服务集群的能力.
不过如果只是想单独简单管理几台容器化服务, 利用 cockpit 反而更加轻量而无须对系统整个重新构建.
cockpit-machines 只能间接管理 KVM 虚拟机, 仅支持基本的启停|创建, 没有快照|克隆|高可用方案
如果是小规模(5台)服务器范围且不需要快照备份功能, 只需要对应 cockpit 就足以满足.
系统级别虚拟化带来的问题就是 ...
在项目正式部署上限的过程当中, 有时候需要用到项目 打包 -> 测试 -> 出包 流程,这个流程一般是重复且复杂的, 所以就衍生 高效、可靠、可追溯的开发与交付体验 为目标的 流水线 部署流程.
目前 Jenkins 自动化构建流程基本支持前后端项目和容器化处理
推荐采用单独的设备来部署 Jenkins, 因为打包中心可能涉及到修改和暴露很多东西, 所以最好做环境方面隔离.
安装部署推荐直接 Jenkins官网 去下载 LTS 版本,虽然我是坚定的 apt 一键安装部署推崇者, 但是基于目前的国内网络原因更新下载速度及其离谱(有时候要更新一整晚);所以最后不得不直接采用安装包来部署, 还能避免污染 apt 源更新(除非国内以后有镜像部署来加速).
不过这里还提供下 APT 部署流程:
12345678910111213# 安装源证书sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key# 写入镜像源 echo ...
这里的Linux打包其实总共分以下几类, 更多是方便内网一键部署的情况:
Debian(.deb) 系列包系统: dpkg -i xxx.deb(安装)|dpkg -r xxx(卸载)
RedHat(.rpm) 系列包系统: rpm -ivh xxx.rpm(安装)|rpm -e xxx.rpm(卸载)
Docker 直接编写 Dockerfile 和 docker-compose 部署
一般来说如果是打包有分为 命令行 和 桌面应用, 这里主要是用于部署服务端所以采用命令行操作
这里需要先采用 debian 打包方式说明, 适用于 Debian|Ubuntu 系列的虚拟环境, 其他因为不常用所以后续再补充.
deb打包实际上需要按照以下命令来做打包:
12345# 按照文件夹规则放置到其中dpkg -b 文件夹名称 安装包名称# 比如以下方式打包, fusion-gateway 是当前目录下的子目录dpkg -b fusion-gateway fusion-gateway_1.0_amd64.deb
按照以下流程测试打包名为 fusion-gateway 的应用, 该应用基 ...
如果 Chrome 浏览器版本比较新就可以直接让其安装到桌面上作为应用来处理:
无论手机还是桌面浏览器都能将网页安装到桌面从而变成 APP 来使用.
这里实现的方法其实十分简单, 只需要在 html 页面上追加 manifest 声明网页元数据:
123<head> <link rel="manifest" href="manifest.json"></head>
这里的 manifest.json 就是声明 PWA 的 JSON 格式配置文件, 实际上就是相当于调用本地浏览器的 Web 应用入口,也就是 轻应用 的概念的由来, 无须复杂的桌面|移动端开发来构建的应用.
manifest.json 配置是所有浏览器通用的, 这里提供 Mozilla的官方说明: Mozilla Manifest
配置的样例如下:
lines1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950 ...
这里主要采用 MariaDB 作为主要数据库选择, 且内部系统采用 Debian 系的服务器来利用 Apt 进行源安装.
不涉及所有手动编译, 手动编译很多人直接都不写系统脚本让系统托管, 所以尽量能用官方源托管就利用官方源, 当然如果能够自己手动配置本地源更好.
重要: 如果完全不懂系统脚本编写, 切忌不要抄网上所有自己手动编译的教程, 直接 touch 后台托管危害是十分大的.
源安装命令
一般 Linux 发行版都内置了 MariaDB 的系统源仓库, 如果没有的需要配置仓库文件( 这个问题基本集中在 RHEL 系的服务器 ).
这里可以参考官方文档配置: 官方文档
这里直接配置 Debian11 的源( MariaDB 10.7 ):
123sudo apt-get install -y software-properties-common dirmngr apt-transport-httpssudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc&#x ...
自签证书内网穿透这里是基于内网的自签名证书对外开放服务功能, 主要流程:
Linux 定时自动 生成自签证书生成放置于 Nginx 特定目录, 建议每日|每月自动更新证书数据
在生成证书的同时挂载自签证书提供对外服务, 所有服务都必须经由自签证书访问
在生成证书的同时写入到公钥和证书数据到 Redis 之中保存
对外挂起单独 Web 服务提供登录服务用于统一登录授权
用户登录认证之后服务器返回 地址+端口+证书+公钥进行 从而保存到本地挂起 Web 通过自签证书访问服务
用户从登录多个返回授权服务列表可以直接访问到内部自签名服务
具体的请求时序图如下:
这种访问方式可以在外网防止中间人窃取访问数据, 从而保证内部服务的安全可靠性;这里采用 Python|Bash 脚本处理都行,另外还需要知道怎么 构建自签名证书.
上面的构建自签证书需要手动输入必要的信息, 这里采用连贯命令直接单行全部编写( 先测试脚本: /etc/nginx/auto.cer.sh ):
12345678910111213141516171819202122232425262728293031323334353 ...
Nginx 常用来负载均衡, 用来多个服务端反向代理内部服务器组从而获取到内部网络资源对外提供服务,后续还有些静态资源就需要考虑多地缓存而不走直接后端流量.
常见比如网状反向服务架构, 多个对外服务Nginx同时转发到内网单机情况; 需要缓存内网资源到外部访问服务器本地, 后续资源不走内部服务器.
假设目前内网机已经部署好对外静态资源服务端, 这时候则需要在可以被对外访问得服务器上安装配置 Nginx:
12# 安装好 NGINX 服务sudo apt install -y nginx
之后这里就是假设需求: 目前需要 .mp4|.mkv|.avi|.wmv 这些视频文件十分庞大且占用流量十分多,所以在对外服务器上需要将内网服务器的资源缓存, 并且后续超时时间设定为 6 个月才重新更新缓存.
这里编写配置来处理这方面设置即可:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263http { ...
虽然 Git 已经满足代码版本托管, 但是对于美术/策划等工作来说没必要搞什么代码托管或者版本管理, 只需要不断推送就行了.
这里基于 debian 系统安装
12345# 安装 subversion 软件sudo apt install -y subversion# 之后创建版本库sudo mkdir /svn && cd /svn
生成版本库这里多版本库首先定义好子版本库, 以后不断扩展不同版本库:
12345678910111213# 创建子版本库 code sudo mkdir -p /svn/code && cd /svn/code# 生成版本库sudo svnadmin create /svn/code# 没问题就含有以下文件目录:# conf# db# format# hooks# locks# README.txt
这里主要修改配置文件 conf:
conf/authz: 权限控制
conf/passwd: 账号密码文件
conf/svnserve.conf: 服务器配置文件
首先修改账号密码文件( conf/pas ...
