首页 文章 精选 留言 我的

精选列表

搜索[分库分表],共10000篇文章
优秀的个人博客,低调大师

应用新安全组 - 每天5分钟玩转 OpenStack(116)

Neutron 默认的安全组规则会禁止掉所有从外面访问 instance 的流量。 本节我们会修改安全组的配置,允许 ping 和 ssh instance。有两种方法可以达到这个目的: 1. 修改 “default” 安全组。 2. 为 cirros-vm1 添加新的安全组。 这里我们采用第二种方法。 在安全组列表页面点击按钮。 为安全组命名并点击 “Create Security Group”。 新的安全组 “allow ping & ssh” 创建成功。 点击按钮,查看 “allow ping & ssh” 的规则。 系统默认定义了两条规则,运行所有的外出流量。 为清晰起见,可以点击按钮删除这两条规则。 点击按钮,添加允许 ping 的规则。 “Rule” 选择 “All ICMP”,“Direction” 选择 “Ingress”,然后点击 “Add” 按钮。 同样的方式添加 ssh 规则。 在列表中查看添加成功的规则。 接下来设置 cirros-vm1,使用新的安全组。 进入 instance 列表页面,点击 cirros-vm1 下拉操作列表中的 “Edit Security Groups” 可以看到 cirros-vm1 当前使用的安全组为 “default”,可选安全组为 “allow ping & ssh”。 点击安全组 “allow ping & ssh” 后面的 “+” 按钮。 点击 “Save” 保存。 iptables 会立即更新,下面通过 vimdiff 查看 iptables 前后的变化。 “allow ping & ssh” 安全组引入了下面两条 iptables 规则。 作用是运行 ingress 的 ssh 和 ping 流量。 -A neutron-linuxbri-i8bca5b86-2 -p tcp -m tcp --dport 22 -j RETURN -A neutron-linuxbri-i8bca5b86-2 -p icmp -j RETURN 测试一下,现在能够 ping 和 ssh cirros-vm1 了。 小结 安全组有以下特性: 1. 通过宿主机上 iptables 规则控制进出 instance 的流量。 2. 安全组作用在 instance 的 port 上。 3. 安全组的规则都是 allow,不能定义 deny 的规则。 4. instance 可应用多个安全组叠加使用这些安全组中的规则。 安全组学习完了,下节我们讨论 Neutron 的另一个安全机制 -- 虚拟防火墙。

优秀的个人博客,低调大师

部署 instance 到 VXLAN - 每天5分钟玩转 OpenStack(112)

上一节我们创建了 vxlan 100_net,今天将部署 instance 并分析网络的连通性。 launch 新的 instance “cirros-vm1”,网络选择 vxlan100。 cirros-vm1 分配到的 IP 为 172.16.100.3。 cirros-vm1 被 schedule 到控制节点,对应的 tap 设备为 tap099caa87-cd,并且连接到 bridge brq1762d312-d4。 当前 vxlan100 的结构如下: 继续用同样的方式 launch instance cirros-vm2,分配到的 IP 为 172.16.100.4。 cirros-vm2 被 schedule 到计算节点,对应的 tap 设备为 tap457cc048-aa,并且连接到 bridge brq1762d312-d4。 因为计算节点上没有 hdcp 服务,所以没有相应的 tap 设备。 另外,bridge 的名称与控制节点上一致,都是 brq1762d312-d4,表明是同一个 network。 当前 vxlan100 的结构如下: cirros-vm1(172.16.100.3) 与 cirros-vm2(172.16.100.4) 位于不同节点,通过 vxlan100 相连,下面执行 PING 验证连通性。 在 cirros-vm1 控制台中执行 ping 172.16.100.4 如我们预料,ping 成功。 对于多 vxlan 之间的 routing 以及 floating ip,实现方式与 vlan 非常类似,这里不再赘述,请参看前面 vlan 相关章节。 下节我们讨论提高 VXLAN 工作效率的机制 - L2 Population。

优秀的个人博客,低调大师

VXLAN 概念(Part II)- 每天5分钟玩转 OpenStack(109)

上一节我们介绍了 VXLAN 的封装格式以及 VTEP。今天我们将通过例子讨论 VXLAN 封装和转发包的过程,以及 Linux 对 VXLAN 的原生支持。 VXLAN 包转发流程 VXLAN 在 VTEP 间建立隧道,通过 Layer 3 网络传输封装后的 Layer 2 数据。下面的例子演示了数据如何在 VXLAN 上传输: 图中 Host-A 和 Host-B 位于 VNI 10 的 VXLAN,通过 VTEP-1 和 VTEP-2 之间建立的 VXLAN 隧道通信。数据传输过程如下: Host-A 向 Host-B 发送数据时,Host-B 的 MAC 和 IP 作为数据包的目标 MAC 和 IP,Host-A 的 MAC 作为数据包的源 MAC 和 IP,然后通过 VTEP-1 将数据发送出去。 VTEP-1 从自己维护的映射表中找到 MAC-B 对应的 VTEP-2,然后执行 VXLAN 封装,加上 VXLAN 头,UDP 头,以及外层 IP 和 MAC 头。此时的外层 IP 头,目标地址为 VTEP-2 的 IP,源地址为 VTEP-1 的 IP。同时由于下一跳是 Router-1,所以外层 MAC 头中目标地址为 Router-1 的 MAC。 数据包从 VTEP-1 发送出去后,外部网络的路由器会依据外层 IP 头进行包路由,最后到达与 VTEP-2 连接的路由器 Router-2。 Router-2 将数据包发送给 VTEP-2。VTEP-2 负责解封数据包,依次去掉外层 MAC 头,外层 IP 头,UDP 头 和 VXLAN 头。 VTEP-2 依据目标 MAC 地址将数据包发送给 Host-B。 上面的流程我们看到 VTEP 是 VXLAN 的最核心组件,负责数据的封装和解封。 隧道也是建立在 VTEP 之间的,VTEP 负责数据的传送。 Linux 对 VXLAN 的支持 VTEP 可以由专有硬件来实现,也可以使用纯软件实现。 目前比较成熟的 VTEP 软件实现包括: 带 VXLAN 内核模块的 Linux Open vSwitch 我们先来看 Linux 如何支持 VXLAN,Open vSwitch 方式将在后面章节讨论。 实现方式: Linux vxlan 创建一个 UDP Socket,默认在 8472 端口监听。 Linux vxlan 在 UDP socket 上接收到 vxlan 包后,解包,然后根据其中的 vxlan ID 将它转给某个 vxlan interface,然后再通过它所连接的 linux bridge 转给虚机。 Linux vxlan 在收到虚机发来的数据包后,将其封装为多播 UDP 包,从网卡发出。 到这里,相信大家对 VXLAN 的原理已经有了大致的了解。 下节我们将学习如何在 Neutron 中配置和实施 VXLAN。

优秀的个人博客,低调大师

Neutron Vlan Network 原理- 每天5分钟玩转 OpenStack(92)

前面我们陆续学习了 Neutron local network,flat network 和 DHCP 服务,从本节将开始讨论 vlan network。 vlan network 是带 tag 的网络,是实际应用最广泛的网络类型。下图是 vlan100 网络的示例。 1. 三个 instance 通过 TAP 设备连接到名为 “brqXXXX” linux bridge。 2. 在物理网卡 eth1 上创建了 eth1.100 的 vlan interface,eth1.100 连接到 brqXXXX。 3. instance 通过 eth1.100 发送到 eth1 的数据包就会打上 vlan100 的 tag。 如果再创建一个 network vlan101,eth1 上会相应的创建 vlan interface eth1.101,并且连接的新的 lingux bridge “brqYYYY”。 每个 vlan network 有自己的 bridge,从而也就实现了基于 vlan 的隔离。 这里有一点要 特别提醒: 因为物理网卡 eth1 上面可以走多个 vlan 的数据,那么物理交换机上与 eth1 相连的的 port 要设置成 trunk 模式,而不是 access 模式。 下一节讨论如何在 Neutron 中配置 vlan 网络。

优秀的个人博客,低调大师

Neutron 物理部署方案 - 每天5分钟玩转 OpenStack(68)

前面我们讨论了 Neutron 的架构,本节讨论 Neutron 的物理部署方案:不同节点部署不同的 Neutron 服务组件。 方案1:控制节点 + 计算节点 在这个部署方案中,OpenStack 由控制节点和计算节点组成。 控制节点部署的服务包括:neutron server, core plugin 的 agent 和 service plugin 的 agent。 计算节点部署 core plugin 的agent,负责提供二层网络功能。 这里有两点需要说明: 1. core plugin 和 service plugin 已经集成到 neutron server,不需要运行独立的 plugin 服务。 2. 控制节点和计算节点都需要部署 core plugin 的 agent,因为通过该 agent 控制节点与计算节点才能建立二层连接。 3. 可以部署多个控制节点和计算节点。 方案2:控制节点 + 网络节点 + 计算节点 在这个部署方案中,OpenStack 由控制节点,网络节点和计算节点组成。 控制节点部署 neutron server 服务。 网络节点部署的服务包括:core plugin 的 agent 和 service plugin 的 agent。 计算节点部署 core plugin 的agent,负责提供二层网络功能。 这个方案的要点是将所有的 agent 从控制节点分离出来,部署到独立的网络节点上。 控制节点只负责通过 neutron server 响应 API 请求。 由独立的网络节点实现数据的交换,路由以及 load balance等高级网络服务。 可以通过增加网络节点承担更大的负载。 可以部署多个控制节点、网络节点和计算节点。 该方案特别适合规模较大的 OpenStack 环境。 以上就是 Neutron 两种典型的部署方案,下一节我们开始讨论 Neutron 的各个服务组件。将首先学习 Neutron Server 。

优秀的个人博客,低调大师

准备 LVM Volume Provider - 每天5分钟玩转 OpenStack(49)

Cinder 真正负责 Volume 管理的组件是 volume provider。 Cinder 支持多种 volume provider,LVM 是默认的 volume provider。Devstack 安装之后,/etc/cinder/cinder 已经配置好了 LVM,如下图所示: 上面的配置定义了名为“lvmdriver-1”的 volume provider,也称作 back-end。其 driver 是 LVM,LVM 的 volume group 名为“stack-volumes-lvmdriver-1”。 Devstack 安装时并没有自动创建 volume group,所以需要我们手工创建。 如下步骤演示了在 /dev/sdb 上创建 VG “stack-volumes-lvmdriver-1”: 首先创建 physical volume /dev/sdbLinux 的 lvm 默认配置不允许在 /dev/sdb 上创建 PV,需要将 sdb 添加到 /etc/lvm.conf 的 filter 中。 然后创建 VG stack-volumes-lvmdriver-1 打开 Web GUI,可以看到 OpenStack 已经创建了 Volume Type “lvmdriver-1” 其 Extra Specs volume_backend_name 为 lvmdriver-1 后面各小节都将以 LVM 为 volume provider 详细讨论 volume 的各种操作。

优秀的个人博客,低调大师

Migrate Instance 操作详解 - 每天5分钟玩转 OpenStack(40)

Migrate 操作的作用是将 instance 从当前的计算节点迁移到其他节点上。 Migrate 不要求源和目标节点必须共享存储,当然共享存储也是可以的。 Migrate 前必须满足一个条件:计算节点间需要配置 nova 用户无密码访问。 下面是 Migrate instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-scheduler 执行调度 nova-scheduler 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤。 向 nova-api 发送请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(nova-api)发送请求:“帮我迁移这个 Instance” Migrate 操作是特权操作,只能在 Admin 的 instance 菜单中执行 查看日志 /opt/stack/logs/n-api.log nova-api 发送消息 nova-api 向 Messaging(RabbitMQ)发送了一条消息:“迁移这个 Instance” 查看源代码 /opt/stack/nova/nova/compute/api.py,方法是 resize。 没错,是 resize 而非 migrate。这是由于 migrate 实际上是通过 resize 操作实现的,至于为什么要这样设计,我们会在下一节 resize 中详细分析。 nova-scheduler 执行调度 nova-scheduler 收到消息后,会为 instance 选择合适的目标计算节点。 查看日志 /opt/stack/logs/n-sch.log 可以看到,因为 devstack-compute1 的权值比 devstack-controller 大,最终选择 devstack-compute1 作为目标节点。 看到上面的日志,大家发现什么问题没有? 在分析这段日志的时候,我发现 scheduler 选出来的计算节点有可能是当前节点源节点! 因为 scheduler 并没在初始的时候将源节点剔除掉,而是与其他节点放在一起做 filter,按照这个逻辑,只要源节点的权值足够大,是有可能成为目标节点的。 那紧接着的问题是:如果源节点和目标节点是同一个,migrate 操作会怎样进行呢? 实验得知,nova-compute 在做 migrate 的时候会检查目标节点,如果发现目标节点与源节点相同,会抛出 UnableToMigrateToSelf 异常。Nova-compute 失败之后,scheduler 会重新调度,由于有 RetryFilter,会将之前选择的源节点过滤掉,这样就能选到不同的计算节点了。 关于 RetryFilter,大家还有印象吗?如果生疏了可以看前面章节。 好,言归正传。在上面的操作中 sheduler 选择的目标节点是 devstack-compute1,意味着 instance 将从 devstack-controller 迁移到 devstack-compute1。 nova-scheduler 发送消息 nova-scheduler 发送消息,通知计算节点可以迁移 instance 了。 源代码在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行,方法为 select_destinations nova-compute 执行操作 nova-compute 会在源计算节点和目标计算节点上分别执行操作。 源计算节点 devstack-controller 迁移操作在源节点上首先会关闭 instance,然后将 instance 的镜像文件传到目标节点上。 日志在 /opt/stack/logs/n-cpu.log,具体步骤如下: 开始 migrate 在目标节点上创建 instance 的目录 nova-compute 首先会尝试通过 ssh 在目标节点上的 instance 目录里 touch 一个临时文件,日志如下 如果 touch 失败,说明目标节点上还没有该 instance 的目录,也就是说,源节点和目标节点没有共享存储。那么接下来就要在目标节点上创建 instance 的目录,日志如下 关闭 instance 将 instance 的镜像文件通过 scp 传到目标节点上 目标计算节点 devstack-compute1 在目标节点上启动 instance,过程与 launch instance 非常类似。 会经过如下几个步骤: 1. 为 instance 准备 CPU、内存和磁盘资源 2. 创建 instance 镜像文件 3. 创建 instance 的 XML 定义文件 4. 创建虚拟网络并启动 instance 日志记录在 /opt/stack/logs/n-cpu.log,分析留给大家练习。 Confirm 这时,instance 会处于 “Confirm or Revert Resize/Migrate”状态,需要用户确认或者回退当前的迁移操作,实际上给了用户一个反悔的机会。 当我们按下 Confirm 按钮后,会发生如下事情: nova-api 接收到 confirm 的消息 源计算节点删除 instance 的目录,并在 Hypervisor 上删除 instance。 目标计算节点不需要做任何事情 Revert 如果执行的是 Revert 操作会发生什么事情呢? nova-api 接收到 revert 的消息 在目标计算节点上关闭 instance,删除 instance 的目录,并在 Hypervisor 上删除 instance。 源计算节点上启动 instance 因为之前迁移的时候只是在源节点上关闭了该 instance,revert 操作只需重新启动 instance。 以上是 Migrate 操作的完整流程,这里有一点需要特别注意: 迁移过程中源和目标节点之前需要使用 ssh 和 scp,为了使操作顺利进行,必须要保证 nova-compute 进程的启动用户(通常是 nova,也可能是 root,可以通过 ps 命令确认)能够在计算节点之间无密码访问。否则 nova-compute 会等待密码输入,但后台服务是无法输入密码的,迁移操作会一直卡在那里。以上是 Migrate 操作的详细分析,下一节我们讨论 Resize。

优秀的个人博客,低调大师

Unshelve Instance 操作详解 - 每天5分钟玩转 OpenStack(39)

上一节我们 shelve instance 到 Glance,本节讨论如何通过 unshelve 操作恢复该 instance。 因为 Glance 中保存了 instance 的 image,unshelve 的过程其实就是通过该 image launch 一个新的 instance,nova-scheduler 也会调度合适的计算节点来创建该 instance。 instance unshelve 后可能运行在与 shelve 之前不同的计算节点上,但 instance 的其他属性(比如 flavor,IP 等)不会改变。 下面是 Unshelve instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-scheduler 执行调度 nova-scheduler 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤。 向 nova-api 发送请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(nova-api)发送请求:“帮我 Unshelve 这个 Instance” 查看日志 /opt/stack/logs/n-api.log nova-api 发送消息 nova-api 向 Messaging(RabbitMQ)发送了一条消息:“unshelve 这个 Instance” 查看源代码 /opt/stack/nova/nova/compute/api.py,方法是 unshelve。 nova-scheduler 执行调度 nova-scheduler 收到消息后,会为 instance 选择合适的计算节点。 查看日志 /opt/stack/logs/n-sch.log 经过筛选,最终 devstack-controller 被选中 launch instance。 nova-scheduler 发送消息 nova-scheduler 发送消息,告诉被选中的计算节点可以 launch instance 了 源代码在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行,方法为 select_destinations nova-compute 执行操作 nova-compute 执行 unshelve 的过程与 launch instance 非常类似。 一样会经过如下几个步骤: 1. 为 instance 准备 CPU、内存和磁盘资源 2. 创建 instance 镜像文件 3. 创建 instance 的 XML 定义文件 4. 创建虚拟网络并启动 instance 日志记录在 /opt/stack/logs/n-cpu.log,分析留给大家练习。 以上就是 Unshelve 操作的分析,下一节我们讨论 Migrate 操作。

优秀的个人博客,低调大师

Shelve Instance 操作详解 - 每天5分钟玩转 OpenStack(38)

Instance 被 Suspend 后虽然处于 Shut Down 状态,但 Hypervisor 依然在宿主机上为其预留了资源,以便在以后能够成功 Resume。 如果希望释放这些预留资源,可以使用 Shelve 操作。 Shelve 会将 instance 作为 image 保存到 Glance 中,然后在宿主机上删除该 instance。 下面是 shelve instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤。 向 nova-api 发送请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向API(nova-api)发送请求:“帮我 shelve 这个 Instance” 查看日志 /opt/stack/logs/n-api.log nova-api 发送消息 nova-api 向 Messaging(RabbitMQ)发送了一条消息:“shelve 这个 Instance” 查看源代码 /opt/stack/nova/nova/compute/api.py,方法是 shelve。 nova-compute 执行操作 查看日志 /opt/stack/logs/n-cpu.log 首先,关闭 instance 然后对 instance 执行 snapshot 操作 成功后,snapshot 生成的 image 会保存在 Glance 上,命名为 <instance name>-shelved 最后删除 instance 在宿主机上的资源 暂停操作成功执行后,instance 的状态变为 Shelved Offloaded,电源状态是 Shut Down 以上就是 Shelve 操作的分析,下一节我们讨论 Unshelve 操作。

优秀的个人博客,低调大师

Rebuild Instance 操作详解 - 每天5分钟玩转 OpenStack(37)

上一节我们讨论了 snapshot,snapshot 的一个重要作用是对 instance 做备份。 如果 instance 损坏了,可以通过 snapshot 恢复,这个恢复的操作就是 Rebuild。 Rebuild 会用 snapshot 替换 instance 当前的镜像文件,同时保持 instance 的其他诸如网络,资源分配属性不变。 下面是 rebuild instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤。 向 nova-api 发送请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(nova-api)发送请求:“Rebuild 这个 Instance” 选择用于恢复的 image 查看日志/opt/stack/logs/n-api.log nova-api 发送消息 nova-api 向 Messaging(RabbitMQ)发送了一条消息:“Rebuild 这个 Instance” 源代码在 /opt/stack/nova/nova/compute/api.py,方法是 rebuild。 nova-compute 执行操作 查看日志 /opt/stack/logs/n-cpu.log 关闭 instance 下载新的 image,并准备 instance 的镜像文件 启动 instance Rebuild 后,GUI 显示 instance 已经使用新的 image 以上就是 Rebuild 操作的分析,下一节我们讨论 Shelve 操作。

优秀的个人博客,低调大师

Snapshot Instance 操作详解 - 每天5分钟玩转 OpenStack(36)

本节我们通过日志详细讨论 instance 的 snapshot 操作。 有时候操作系统损坏得很严重,通过 Rescue 操作无法修复,那么我们就得考虑通过备份恢复了。当然前提是我们之前对instance做过备份。 Nova 备份的操作叫 Snapshot,其工作原理是对 instance 的镜像文件(系统盘)进行全量备份,生成一个类型为 snapshot 的 image,然后将其保存到 Glance 上。 从备份恢复的操作叫 Rebuild,将在下一节重点讨论。 下面是 snapshot instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤。 向nova-api发送请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(nova-api)发送请求:“对这个 Instance 做个快照” 查看日志 /opt/stack/logs/n-api.log nova-api 发送消息 nova-api 向 Messaging(RabbitMQ)发送了一条消息:“对这个 Instance 做快照” 源代码在 /opt/stack/nova/nova/compute/api.py,方法是 snapshot。 nova-compute 执行操作 查看日志 /opt/stack/logs/n-cpu.log 暂停 instance 对 instance 的镜像文件做快照 恢复 instance 将快照上传到 Glance Snapshot 成功保存在 Glance 中 instance 备份成功,下节我们讨论如何通过 snapshot 恢复。

优秀的个人博客,低调大师

Terminate Instance 操作详解 - 每天5分钟玩转 OpenStack(33)

本节通过日志详细分析 Nova Terminate 操作。 Terminate 操作就是删除 instance,下面是 terminate instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤。 向 nova-api 发送请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(nova-api)发送请求:“帮我删除这个 Instance” 查看日志 /opt/stack/logs/n-api.log nova-api 发送消息 nova-api 向 Messaging(RabbitMQ)发送了一条消息:“删除这个 Instance” 源代码在 /opt/stack/nova/nova/compute/api.py,方法是 _do_force_delete。 nova-compute 执行操作 查看日志 /opt/stack/logs/n-cpu.log 关闭 instance 删除 instance 的镜像文件 释放虚拟网络等其他资源 以上就是 terminate 的详细分析,下一节我们继续分析 Pause/Resume 操作。

优秀的个人博客,低调大师

Start Instance 操作详解 - 每天5分钟玩转 OpenStack(31)

本节通过日志文件详细分析 instance start 操作。 下面是 start instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤。 向 nova-api 发送请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向API(nova-api)发送请求:“帮我启动这个 Instance” 查看日志 /opt/stack/logs/n-api.log nova-api 发送消息 nova-api 向 Messaging(RabbitMQ)发送了一条消息:“启动这个 Instance” 查看源代码 /opt/stack/nova/nova/compute/api.py 的 2002 行,方法是 start。 self.compute_rpcapi.start_instance() 的作用就是向 RabbitMQ 上 nova-compute 的消息队列里发送一条 start instance 的消息。 nova-compute 执行操作 查看日志 /opt/stack/logs/n-cpu.log 开始启动 准备虚拟网卡 准备 instance 的 XML 文件 准备 instance 镜像文件 成功启动 Start 操作的分析就得这里,下节继续讨论其他 nova 操作。

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册