Noodles使用指南

前言

本文旨在对项目的前因后果进行梳理，并且对其中的一些概念进行讲解，我也会说一些我具体的思考过程，方便大家理解的同时也是我个人的一个总结，接下来我们就开始吧。

Noodles到底想解决什么问题？

客观来讲，如果你没有对应的需求，那么将很难理解这个项目到底要干什么，我尽量举一些真实的例子，来帮助大家理解。

关于我

这个项目是根据我个人的需求做的，那么我先来介绍一下我个人的情况。

我大概是从21年开始玩各种硬件的，和很多人一样，一开始从硬路由魔改系统（K2P）入门，慢慢到工控软路由（4415U），然后买硬件搭建自己的第一台Nas(Unraid)，第二台Nas(Unraid)，第一台Windows Server服务器。过程中也使用过Esxi，搭建过Openstack，了解过PVE，FreeNas(现在叫TrueNas)。回顾过去的几年时间，我把大部分个人时间都花在这上面，有时候一折腾就是好几天的时间。

问题来源

随着服务器的升级，性能的提升带来了虚拟化潜力的大幅提升，我目前的两台服务器价格是软路由的数倍，但所能承载的虚拟机&容器数量却是软路由的几十倍。而虚拟机容器数量的暴增也带来了管理上的困难。比如：

1. 容器数量爆炸，现在任何应用都可以做成镜像，容器没有分类和快速搜索，容易遗忘和误操作。
2. 虚拟化宿主关系繁杂混乱，物理机可以创建虚拟机，容器。虚拟机同样可以，一层套一层的虚拟化带来了很多潜在的问题。比如删除了一个虚拟机，结果是删除了一个虚拟机加很多容器。
3. 物理服务器管理页面不统一，Unraid拥有非常完备的管理页面，那WindowsServer呢？难道每次都RDP登录到桌面去点点点吗，not graceful.
4. 没有统一的掉线提醒，服务挂了用户第一时间不知道，只有到下次使用的时候才发现不能用了，极度影响使用体验
5. 已有的解决方案与实际解决之间的鸿沟。K8S？Openstack？那些离我们太遥远了。

Noodles的目的就是解决上述这些问题

总之

站在用户角度讲，用户并不想真正的“运维”服务器，用户只想享受服务器带来的服务（既要也要，就是这么矫情），DIY过程的确实可以带来一定乐趣，但越来越多的“运维”，对于用户来说就不是乐趣而是负担了。

使用指南

项目结构

整个项目分为三个工程，分别是前端，后端，探测器

• 前端：由Vue3和Vuexy组成的操作界面
• 后端：由Java和SpringBoot等框架编写的后端逻辑
• 探测器：由Java和SpringBoot等框架编写的物理机信息探测器

使用流程

1. 首先你需要准备好MySQL数据库，Redis数据库，RabbitMQ消息队列
2. 在你的物理机环境中安装JDK/JRE
3. 拉取Noodles-Frontend前端代码
4. 拉取Noodles后端代码
5. 分别按照Readme进行配置和部署
6. 拉取Noodles-Detector代码，并进行配置
7. 将Maven打过的Jar包安装到对应的物理机环境中
8. 将Noodles平台中录入对应的实例信息
9. 开始使用

名词解释

实例

• 所有物理机，虚拟机，容器，都可以统称为实例

服务

• 一组物理机，虚拟机，容器的编组。

举个例子：一个PT下载服务，包括一个Transmission容器，一个Qbittorrent容器，一个IYUU-PLUS容器，一个实例可以为多个服务提供支撑。