We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
自从使用了 Docker,已经很少在服务器上装应用了,基本都是起个容器跑应用,在使用 Docker 容器的过程中,很多容器的配置文件需要管理,使用过程中不少人对命令行及配置文件不熟悉,而且配置文件管理起来也太麻烦。 一直想找一个 web 前端来管理配置文件,看来看去还是回到了 openwrt 的 LuCI,而且 LuCI 上有很多 app 可以移(chao)植(xi),所以一口气将 LuCI 装入容器,配合 luci-lib-docker 以进行 Docker 容器的配置文件管理。
早期 luci 是支持独立于 openwrt 运行的,不过近年了与 openwrt 的耦合度越来越高,特别是 ubus 相关的 api,由于我们移植 LuCI 的目的就是用于配置文件管理,所以就用不到 ubus,移植 LuCI 最关键的就是剥离 ubus。 过程就不缀诉了,移植过程中恰逢 LuCI 大版本从18.06 升级至 19.07,两个版本天差地别,19.07 明显前端化,使用 javascript 编写插件。硬着头皮将 18.06 移植完成之后,又顺路移植了 19.07,所有源码都在 https://github.com/lisaac/luci-in-docker
docker run -d \ --name luci \ --restart unless-stopped \ -p 80:80 \ -p 7682:7682 \ -e TZ=Asia/Shanghai \ -v $HOME/pods/luci:/external \ -v /var/run/docker.sock:/var/run/docker.sock \ lisaac/luci:latest
稍等启动之后,就可以使用浏览器访问 80 端口打开 LuCI 了,在 LuCI 容器中,已经内置了 luci-app-dockerman, 可以用来管理 Docker,再也不需要难用的 portainer 了。
从 LuCI 容器的启动命令可以看到映射了/external目录,/external/cfg.d 目录是用来存放将来的配置文件的,而/external目录也是用来存放插件的,所以只要保存好这个目录,就能保存所有配置信息。
/external
/external/cfg.d
没错,一个容器只提供一种服务,这是政治问题!!这很 Linux!! 所以,强烈不建议在 LuCI 容器中运行其他服务,别忘了我们的初衷是把 LuCI 拿过来管理其他容器的配置文件的,接下来管理各个容器配置文件是由各个插件完成的。 所以,如果你想要使用 LuCI 管理一个服务,你需要一个容器和一个插件。
LuCI 插件有别于 Openwrt 的安装包,不直接兼容 Openwrt 的 ipk,插件是一个目录,目录结构如下:
|-luci-app-podclash # 插件名,会忽略以 _ 开头的目录,方便调试,插件结构如下: |-Makefile # 判定有效插件目录标志,并不按照Makefile执行 |-root # 插件所需的 root 目录 |-luasrc # 插件所需的 lua 文件目录 |-htdocs # 插件所需的 html 文件目录 |-po # 插件所需的 po 文件目录 |-depends.lst # 插件所需要 alpine 依赖列表文件, 依赖用空格隔开, 只用来存放 alpine 依赖 |-preinst # 插件所需的初始化脚本(合并前) |-postinst # 插件所需的初始化脚本(合并后), 若没有此脚本, 会尝试执行 /root/etc/uci-defaults/ 下的插件初始化脚本
可以看出 LuCI 插件与 ipk 解压后 data 目录中的内容相似,在 LuCI 菜单中 「系统--插件」 中可以对 LuCI 插件进行管理,新增插件只需要填入 LuCI 插件的仓库地址即可。
由于现在 LuCI 19.07+ 大量使用 js,此前的 luci-lib-docker 是 lua 后端库,在使用 js 访问的时候挺麻烦。 于是就有了 luci-socket-forwarder,目前已经集成在 luci-in-docker 中,可以使用Docker 原生 api 的方式请求,例如:
luci-socket-forwarder
luci-in-docker
GET http://host/socket/containers/json headers:{ socket_path: "/var/run/docker.sock" cookie: "sysauth=xxxxxxxxxxxxxxxxxxxx" }
最后,欢迎加入tg群一起讨论:https://t.me/joinchat/G5mqjhrlU9S8TMkXeBmj0w
The text was updated successfully, but these errors were encountered:
No branches or pull requests
缘起
自从使用了 Docker,已经很少在服务器上装应用了,基本都是起个容器跑应用,在使用 Docker 容器的过程中,很多容器的配置文件需要管理,使用过程中不少人对命令行及配置文件不熟悉,而且配置文件管理起来也太麻烦。
一直想找一个 web 前端来管理配置文件,看来看去还是回到了 openwrt 的 LuCI,而且 LuCI 上有很多 app 可以移(chao)植(xi),所以一口气将 LuCI 装入容器,配合 luci-lib-docker 以进行 Docker 容器的配置文件管理。
LuCI in Docker
早期 luci 是支持独立于 openwrt 运行的,不过近年了与 openwrt 的耦合度越来越高,特别是 ubus 相关的 api,由于我们移植 LuCI 的目的就是用于配置文件管理,所以就用不到 ubus,移植 LuCI 最关键的就是剥离 ubus。
过程就不缀诉了,移植过程中恰逢 LuCI 大版本从18.06 升级至 19.07,两个版本天差地别,19.07 明显前端化,使用 javascript 编写插件。硬着头皮将 18.06 移植完成之后,又顺路移植了 19.07,所有源码都在 https://github.com/lisaac/luci-in-docker
首先你需要有 Docker 环境,目前 luci-in-docker 只还支持 x86/arm64 两种架构,安装方法:
稍等启动之后,就可以使用浏览器访问 80 端口打开 LuCI 了,在 LuCI 容器中,已经内置了 luci-app-dockerman, 可以用来管理 Docker,再也不需要难用的 portainer 了。
从 LuCI 容器的启动命令可以看到映射了
/external
目录,/external/cfg.d
目录是用来存放将来的配置文件的,而/external
目录也是用来存放插件的,所以只要保存好这个目录,就能保存所有配置信息。One Container One Service
没错,一个容器只提供一种服务,这是政治问题!!这很 Linux!!
所以,强烈不建议在 LuCI 容器中运行其他服务,别忘了我们的初衷是把 LuCI 拿过来管理其他容器的配置文件的,接下来管理各个容器配置文件是由各个插件完成的。
所以,如果你想要使用 LuCI 管理一个服务,你需要一个容器和一个插件。
LuCI 插件
LuCI 插件有别于 Openwrt 的安装包,不直接兼容 Openwrt 的 ipk,插件是一个目录,目录结构如下:
/external
目录中的插件,合并到 LuCI 中可以看出 LuCI 插件与 ipk 解压后 data 目录中的内容相似,在 LuCI 菜单中 「系统--插件」 中可以对 LuCI 插件进行管理,新增插件只需要填入 LuCI 插件的仓库地址即可。
Docker API(For Developer)
由于现在 LuCI 19.07+ 大量使用 js,此前的 luci-lib-docker 是 lua 后端库,在使用 js 访问的时候挺麻烦。
于是就有了
luci-socket-forwarder
,目前已经集成在luci-in-docker
中,可以使用Docker 原生 api 的方式请求,例如:最后,欢迎加入tg群一起讨论:https://t.me/joinchat/G5mqjhrlU9S8TMkXeBmj0w
The text was updated successfully, but these errors were encountered: