首页 文章 精选 留言 我的

精选列表

搜索[私有网络],共10000篇文章
优秀的个人博客,低调大师

轻松玩转AI绘图,可私有化部署的Stable Diffusion

引言 Stable Diffusion 是一个开源的深度学习模型,主要利用文本描述生成高质量的图像,还可以图生图、模型合并、模型训练等。Stable Diffusion 的操作界面如下图所示: 如何生图 下面介绍一下小鹿喝水的生图过程,生成图的时候分为提示词和负面提示词,输入提示词的时候要明确描述,尽量具体描述你想要的场景、对象、风格和颜色。例如,不仅仅说“小鹿喝水”,而是说“一条小溪,旁边是茂密的树,小溪旁有小鹿在喝水”,负面提示词是反方向的例如:无建筑物、无人物、无桥梁、无围栏,而过于模糊的描述可能导致结果不符合预期。 Stable Diffusion的核心优势 优势 对于AI绘画类的应用现在有很多,那么Stable Diffusion的核心优势是什么? 与其他许多AI绘画工具相比,Stable Diffusion 是完全开源的,这意味着任何人都可以免费使用、修改和分发它,可自己训练模型。有多种风格绘画,并且在 civitai(国外) 和 哩布哩布 AI (国内)有很多种风格的模型,动漫游戏、建筑空间设计、二次元、3D立体、Logo图标等等。。。 之前看到一篇文章说,付费是自动档,Stable Diffusion 相当于手动档。 那么 Stable Diffusion 在众多AI绘画类应用中脱颖而出,主要得益于以下几个核心优势: 与其他许多AI绘画工具相比,Stable Diffusion是完全开源的,这意味着任何人都可以免费使用,并且可以在原有的基础上去开发让用户去注册。 Stable Diffusion支持高度的自定义,用户可以调整模型参数以生成符合特定风格或需求的图像。有能力的用户甚至可以对训练模型。 Stable Diffusion能够生成高分辨率、视觉上令人印象深刻的图像。它利用先进的深度学习技术,能够根据文本描述生成细腻、复杂的图像。 Stable Diffusion特别擅长根据文本提示生成图像,可以用简单的描述来创造出自己想要的图。 Stable Diffusion在艺术创作、娱乐产业、广告、教育、以及自己搞副业很多领域都有涉及。 使用场景 可以通过某音、某手和某书发布一些作品,AI绘画这个东西在自媒体上目前还不是很普遍,流量也是蛮不错的。想在在这些平台上变现,关键在于持续地产生高质量、吸引人的内容,要积极与粉丝互动,建立粉丝群体。 分享一个我一直在做的事,通过GPT帮我生成文案在(某音)做图文的视频,通过文案来生成图片,多张图片组合成一个视频,流量的高低主要还是来源图片的质量。 在某音还有很多图片工具(我用的是蓝猫壁纸),这种图片工具是让粉丝去这里下载图片,下载之前必须要先看广告,可以把生成的高质量头像、壁纸、logo放入工具里面,来赚取广告收益。 还可以: 有流量之后可以做定制,根据客户的需求来定制独一无二的画作,对于宝妈们定制宝宝头像之类。 在线下可以做AI绘画摆摊,需要笔记本电脑和打印机就可以支撑起来一个摊位,比如在大学城或者夜市人流量比较多的地方。 可以根据图生图的能力来画肖像画,再通过售卖的方式进行变现。 安装部署 前提条件 需要安装 Rainbond,Rainbond 是一个不需要懂 Kubernetes 的云原生应用管理平台,部署应用不需要复杂的配置。 部署 Stable Diffusion 机器配置不少于CPU:8核,内存:16GB。 步骤 进入 Rainbond 平台管理,侧边栏选择项目团队,创建你的第一个团队。 点击进入团队后 - 新建应用 - 外部应用市场 - 选择开源应用商店 - 搜索 Stable-diffusion。 可以选择应用版本安装 Stable-diffusion 应用。 创建成功之后在应用视图的拓扑图中可以看到 Stable-diffusion 应用。 点击左侧网关 - 点击当前组件网关 - 编辑 - 开启 WebSocket支持。 进入组件等待初始化文件 - 查看日志(解压过程较慢请稍等)。 看到此日志代表启动成功可以访问。 点击右上角的访问按钮就可以访问 Stable-diffusion 了。 Stable-diffusion 界面,在制作这个应用的时候还加入了中文语言包。 到这里就已经完成安装了,可以尝试去生成想要的图了。 关注我后续还会发布一篇文章告诉大家怎么上传多个模型以及提示词的详细使用教程。

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

AREX 如何支持 Dubbo 自定义私有协议的录制回放

背景 AREX 是一款开源的基于真实请求与数据的自动化回归测试平台,利用 Java Agent 技术与比对技术,通过流量录制回放能力实现快速有效的回归测试。 Dubbo 是一款高性能的分布式服务框架,它基于 RPC 的服务调用和服务治理,具有透明化的远程调用、负载均衡、服务注册与发现、高度可扩展性、服务治理等特点。 目前 AREX 支持录制使用 Dubbo2x、Dubbo3x 协议的接口请求,并且在基于 Dubbo3x 版本开发的调度服务(Schedule Service)中支持回放使用这两种原生版本 Dubbo 协议的用例。但是对于用户自定义扩展的 Dubbo协议、序列化方式,甚至是基于 Dubbo 做的很多个性化改造(如dubbox),目前都不支持。 例如社区某用户与我们反馈,其公司使用的 Dubbo 协议是基于 Dubbox 做的改造,对于协议的包结构和序列化反序列化方式都做了改造,几乎可以理解为是一种全新的协议,这种特定类型的 Dubbo 协议无法使用 AREX 进行录制和回放操作。为了解决该问题,我们在主分支上 fork 出来了一个定制化版本,实现了对该协议的录制回放,但这种做法仅适用于该特定协议,缺乏普适性。 考虑到今后可能会有很多社区用户出现类似的问题,我们需要一种通用的方案,让用户可以自行二次开发以对各种自定义的 Dubbo 协议进行适配。本文将具体实现思路和细节进行了记录,希望对其他用户在今后的使用中提供参考。 方案 为方便理解,首先来介绍一下 AREX 各服务组件的工作流程。 在使用 AREX 流量录制功能时,AREX Java Agent 会记录生产环境中 Java 应用的数据流量和请求信息,并将这些信息发送给 AREX 数据存取服务(Storage Service),由数据存取服务导入 Mongodb 数据库中进行存储。当需要进行回放测试时,AREX 调度服务(Schedule Service)将会根据用户的配置和需求,通过数据存取服务从数据库中提取被测应用的录制数据(请求),然后向目标验证服务发送接口请求。同时,Java Agent 会将录制的外部依赖(外部请求/DB)的响应返回给被测应用,目标服务处理完成请求逻辑后返回响应报文。随后调度服务会将录制的响应报文与回放的响应报文进行比对,验证系统逻辑正确性,并将比对结果推送给分析服务(Report Service),由其生成回放报告,供测试人员检查。 问题的难点在于,由于调度服务是通过泛化调用来实现回放的,因此当某服务的 Dubbo 版本、协议、序列化方式与服务提供方(Provider)不一致时,就会出现各种问题导致调用失败。 AREX 希望能够尽可能地减少对用户服务的干扰,因此不希望关心用户服务的 Dubbo 配置。为了解决 Dubbo 版本、协议、序列化方式不一致的问题,可以考虑将回放请求的发送交给用户服务自己来实现,让用户服务自己去进行适配。 带着这个思路,我们考虑使用 Java SPI (Service Provider Interface,服务提供者接口)来解决问题。Java SPI 是 Java 中一种标准的服务发现机制。它可以帮助开发者在不修改代码的情况下扩展和替换程序中的组件。 用户只需要实现调度服务定义的回放接口,然后使用与录制时同样的框架来进行回放操作。在回放时,调度服务会通过 Java SPI 机制动态载入用户实现的接口。这样可以让用户服务自己去适配 Dubbo 版本、协议、序列化方式。对于原生的 Dubbo 协议,AREX 实现了它的扩展,并以缺省的方式加载了进来。 代码分析 SPI 定义 Invoker public interface ReplayExtensionInvoker { /** * check caseType by InvokerConstants#XXXCaseType. */ boolean isSupported(String caseType); ReplayInvokeResult invoke(ReplayInvocation invocation); default int order() { return 1; } } 这里参考了 Dubbo 源码里 Invoker 的写法,定义了一个名为 ReplayExtensionInvoker 的接口,该接口定义了两个方法:isSupported 和 invoke,分别用于检查所支持的 caseType 类型和执行回放操作。invoke 方法的参数 Invocation 是一个打包好的请求,其中包含了请求的各种信息,如方法名、参数值等等。invoke 方法的返回值是一个 InvokeResult 对象,其中包含了回放的结果信息。接口中还定义了一个默认方法 order,用于指定实现类的执行顺序。 isSupported() caseType 表示回放用例的协议类型,可以使用 InvokerConstant 类中预定义的 XXXCaseType 常量来表示。用户需要通过实现 ReplayExtensionInvoker 接口的 isSupported 方法,将自己实现的回放扩展与指定的 caseType 进行绑定(匹配)。这样,当 AREX 进行回放操作时,会自动根据回放用例中的协议类型,匹配对应的回放扩展,从而实现对应协议类型的回放功能。 order() 同一 caseType 可能会实现多个扩展,这里通过指定顺序来优先加载,降序排列。 Invocation public interface ReplayInvocation { /** * eg: dubbo:127.0.0.1:20880 * protocol + host + port */ String getUrl(); Map<String, Object> getAttributes(); ReplayExtensionInvoker getInvoker(); void put(String key, Object value); /** * Get specified class item from attributes. * key: refer to InvokerConstants. */ <T> T get(String key, Class<T> clazz); /** * Get object item from attributes. * key: refer to InvokerConstants. */ Object get(String key); } Invocation 被定义为一个接口,用户需要实现这个接口中的一些方法,以便在回放过程中获取请求参数。 getUrl() 返回请求的协议、主机和端口号,参考了其他协议,如 gRPC、Triple、Rest 等,Url 都是不必可少的。希望能够支持今后对于其他协议的扩展,将 Url 单独作为一个参数,由 协议名+ IP 地址+端口号组合成。例如:dubbo:127.0.0.1:20880。 getAttributes() 调度服务将请求的其他参数统一打包在一个键值对类型为 的 Map 对象里,其中 String 类型的 key 需要和 InvokerConstants 中约定的名称保持一致。在实现回放扩展时,用户可以通过调用 getAttributes() 方法获取这个 Map 对象,然后根据键的名称从 InvokerConstant 中获取对应的参数值,以便进行回放过程中的处理。 Result public class ReplayInvokeResult { /** * invoke result. */ private Object result; private Map<String, String> responseProperties; /** * if invoke failed. */ privdate String errorMsg; /** * if invoke failed. */ private Exception exception; } ReplayInvokeResult 类表示请求调用的结果,它包含以下字段: result:请求调用的结果,存储在一个 Object 类型的变量中。 responseProperties:一些需要 provider 传递的隐式参数,存储在一个 Map。 类型的变量中。 errorMsg:如果请求调用失败,则存储错误信息的字符串。 exception:如果请求调用失败,则存储异常信息的对象。 扩展的加载 在扩展的加载过程中,首先通过获取当前类的 ClassLoader 来获得一个 URLClassLoader 对象,然后通过反射的方式调用其 addURL() 方法来加载扩展实现类。 loadJar() 方法接受一个 jarPath 参数,表示扩展实现类所在的 jar 包路径,然后通过判断当前 JDK 版本和获取 ClassLoader 等方式,得到一个 URLClassLoader 对象和 addURL() 方法的引用。接着,判断当前 ClassLoader 是否为 URLClassLoader 类型,如果是,则通过反射调用 addURL() 方法来加载 jar 包,并把 jar 包中的类添加到 ClassLoader 中,以便在程序运行时可以动态地调用扩展实现类的方法。如果加载失败,则输出错误信息。 public void loadJar(String jarPath) { try { int javaVersion = getJavaVersion(); ClassLoader classLoader = this.getClassLoader(); File jarFile = new File(jarPath); if (!jarFile.exists()) { LOGGER.error("JarFile doesn't exist! path:{}", jarPath); } Method addURL = Class.forName("java.net.URLClassLoader").getDeclaredMethod("addURL", URL.class); addURL.setAccessible(true); if (classLoader instanceof URLClassLoader) { addURL.invoke(classLoader, jarFile.toURI().toURL()); } } catch (Exception e) { LOGGER.error("loadJar failed, jarPath:{}, message:{}", jarPath, e.getMessage()); } } 如何使用 步骤一:开发 SPI 1. 添加 pom 依赖 开发 SPI 扩展,首先需要在项目的 pom.xml 文件中添加 arex-schedule-extension 依赖。 <dependency> <groupId>com.arextest</groupId> <artifactId>arex-schedule-extension</artifactId> </dependency> 2. 实现 SPI 实现 SPI 扩展,需要实现 com.arextest.schedule.extension.invoker.ReplayExtensionInvoker。 需要注意的是,在 provider 中,通过 Dubbo 隐式参数 attachments 中的 Arex-Record-Id 来判断当前流量是否为回放流量,并将生成的 Arex-Record-Id 也通过 attachments 传递回来。 因此,在实现 ReplayExtensionInvoker 接口时,需要从 ReplayInvocation#attributes 属性中获取 Arex-Record-Id,并将其添加到 attachments 中;同时,将 attachments 中的 Arex-Record-Id 添加到 ReplayInvokeResult#responseProperties 属性中,以便在回放流量中正确地使用这些参数。 以下是一个默认 dubboInvoker 的例子可以参考: package com.arextest.dubboInvoker; import com.arextest.schedule.extension.invoker.InvokerConstants; import com.arextest.schedule.extension.invoker.ReplayExtensionInvoker; import com.arextest.schedule.extension.invoker.ReplayInvocation; import com.arextest.schedule.extension.model.ReplayInvokeResult; import org.apache.dubbo.config.ApplicationConfig; import org.apache.dubbo.config.ReferenceConfig; import org.apache.dubbo.rpc.RpcContext; import org.apache.dubbo.rpc.service.GenericService; import java.util.List; import java.util.Map; public class DefaultDubboInvoker implements ReplayExtensionInvoker { [@Override](https://my.oschina.net/u/1162528) public boolean isSupported(String caseType) { return InvokerConstants.DUBBO_CASE_TYPE.equalsIgnoreCase(caseType); } [@Override](https://my.oschina.net/u/1162528) public ReplayInvokeResult invoke(ReplayInvocation replayInvocation) { ReplayInvokeResult replayInvokeResult = new ReplayInvokeResult(); try { RpcContext.getServiceContext().setAttachments(replayInvocation.get(InvokerConstants.HEADERS, Map.class)); ReferenceConfig<GenericService> reference = new ReferenceConfig<>(); reference.setApplication(new ApplicationConfig("defaultDubboInvoker")); reference.setUrl(replayInvocation.getUrl()); reference.setInterface(replayInvocation.get(InvokerConstants.INTERFACE_NAME, String.class)); reference.setGeneric(true); GenericService genericService = reference.get(); if (genericService == null) { return replayInvokeResult; } Object result = genericService.$invoke(replayInvocation.get(InvokerConstants.METHOD_NAME, String.class), (String[]) replayInvocation.get(InvokerConstants.PARAMETER_TYPES, List.class).toArray(new String[0]), (replayInvocation.get(InvokerConstants.PARAMETERS, List.class)).toArray()); replayInvokeResult.setResult(result); replayInvokeResult.setResponseProperties(RpcContext.getServerContext().getAttachments()); } catch (Exception e) { replayInvokeResult.setException(e); replayInvokeResult.setErrorMsg(e.getMessage()); } return replayInvokeResult; } } 3. 创建 SPI 扩展文件 在项目的 resources/META-INF/services 目录下创建一个文本文件,文件名为 com.arextest.schedule.extension.invoker.ReplayExtensionInvoker。文件内容为扩展实现类的全限定名,即实现了 ReplayExtensionInvoker 接口的类的 Reference。 4. 打 jar 包 将实现的 SPI 扩展打包成一个 jar 包,注意需要包含所有相关的依赖。 步骤二:导入 AREX 项目 1. jar 包映射 Docker 镜像 首先需要将 jar 包映射到 Docker 镜像中,这可以通过修改 docker-compose.yml 文件来实现,将本地目录映射到 Docker 镜像,并将 jar 包添加到本机中对应的目录下。 2. 修改调度服务启动参数 接着,要修改调度服务(Schedule Service)的启动参数,同样是通过修改 docker-compose.yml 文件来实现。将以下启动参数添加到 Schedule 的启动参数中。 -Dreplay.sender.extension.jarPath=/usr/local/tomcat/custom-dubbo/xxx.jar 其中 xxx.jar 是上一步打包的 jar 包的名称, /usr/local/tomcat/custom-dubbo/ 是在 Docker 镜像中的 jar 包存放路径。这个启动参数的作用是告诉 AREX 在哪里可以找到 SPI 扩展的 jar 包。 展望 未来还有三个方面可以进行改进: jar 包的加载模式 目前,用户需要手动管理配置 jar 包路径,并且需要手动修改 docker-compose.yml 文件,这样操作上略微有些繁琐。未来希望能够做到在 AREX 平台上进行相关参数配置,上传 jar 包等操作。 参数约定 目前参数的管理是在代码中以 hardcode 的方式实现的,新的接入方需要提前约定好,再更新 SPI 这个包。未来希望做到在 AREX 平台上进行参数配置,这样新的接入方可以通过简单的配置实现自己的需求。 其他协议的支持 目前 invoker 框架可以直接支持 Dubbo 协议的各种个性化扩展。如果有用户需要接入其他的协议,例如 gRPC、Triple、Rest 等,也可以提出 [issue] (https://github.com/arextest/arex/issues), 在社区中进行讨论,以便扩展 invoker 框架的适用范围。 AREX 文档:http://arextest.com/zh-Hans/docs/intro/ AREX 官网:http://arextest.com/ AREX GitHub:https://github.com/arextest AREX 官方 QQ 交流群:656108079

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

微软私有云分享(R2)11-应答文件浅析

如何自行编写应答文件 应答文件解决了系统管理员所面临的不同的苛刻用户对系统架构的不同需求。在不使用应答文件的前提下,管理员可能需要为每一种不同的系统架构和配置去手动安装和调试。而使用应答文件,则依然可以保持高度自动化的运维趋势,同时所创建的不同的应答文件在未来还可以重复利用。 自行编写应答文件有一定难度,但学习起来并不困难,对于初学者来说,主要难点是以下部分: "应答文件能够实现什么?"应答文件在系统自动部署中,基本可以做到任何操作,因此考虑问题的角度可以从能够实现什么转变为不能实现什么会比较好。 "如何快速获悉所需要修改的配置,应该查找具体哪个条目?"如果希望更快速的去编写应答文件,首先需要英文有一定阅读能力,以及对常见的Windows设置项的英文单词掌握。在希望设置相关选项时,一般需要搜索的关键词都是设置项的英文名。如防火墙、远程桌面、证书、IE、Mediaplayer等等。 "获取需要调整的条目后,如何获取具体的属性配置写法?"此项同样需要对英文有一定的阅读能力。对于属性的每一个细节,只需在任意一个条目或属性上点击键盘的"F1"即可,如图所示。帮助文件会列出条目或属性的可选参数、所能支持的操作系统,关联的关键字,在线查询等。信息非常完善,唯一的缺点是这份帮助文件没有中文版。 通过帮助文件获取支持 应答文件的兼容性 应答文件是一种xml格式的文本文件,其并非对所有操作系统都能做到完整支持你。无法做到完整支持的原因主要有三点: 32位、64位操作系统差异。 老版本系统的功能在新版本中被更换或删除。 新版本的功能在老版本中未出现。 一般而言,为Windows Server 2012 R2编写的应答文件,多数条目是可以在Windows Server 2008 R2 下重复利用。在正式将应答文件于不同的操作系统之前,需要使用Windows系统映像管理器对应答文件进行验证,如图所示。依次点击"工具栏"→"验证应答文件"即可,当右下角的"验证"处没有错误提示时,即表示该应答文件可以应用于目标操作系统。 当应答文件存在兼容性问题而依然强制部署时,则系统的安装进程会卡在验证失败的环节,导致自动化安装无法继续。 创建的应答文件必须验证 使用应答文件 使用应答文件有两种典型方式: 由SCVMM、WDS、MDT等工具调用 由命令行直接在Sysprep阶段加载。在运行Sysprep时,使用类似" sysprep.exe/unattend:answerfile"的格式运行即可。其中answerfile为提前生成的xml格式的应答文件。 以SCVMM2012 R2调用应答文件为例。 第1步,在"库"窗格点击"导入物理资源",在弹出的"导入库资源"对话框中,点击"添加资源",定位至应答文件所在的磁盘,并选择该文件进行上传,如图所示。 上传应答文件至库服务器 第2步,上传结束后,手动刷新库服务器信息,(默认情况下库服务器一小时刷新一次,当时上传的信息可能不会即刻被发现。)打开任意一个虚拟机模板或来宾OS配置文件,于"脚本"→"应答文件"下,通过"浏览"在库服务器上指定所上传的应答脚本。如选择错误,可以点击"清除"以重新进行选择,如图所示。 本文转自 九叔 51CTO博客,原文链接:http://blog.51cto.com/jiushu/1412434,如需转载请自行联系原作者

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

docker学习笔记(二)——本地私有仓库Registry的搭建与验证

Registry的部署 获取registry镜像 1 #dockerpullregistry:2.1.1 启动registry容器 1 2 3 4 5 6 7 8 9 #dockerrun-d-v/opt/registry:/var/lib/registry-p5000:5000--restart=always--nameregistryregistry:2.1.1 查看进程 #dockerps CONTAINERIDIMAGECOMMANDCREATEDSTATUSPORTSNAMES ac291ed888feregistry:2.1.1 "/bin/registry/et..." 27minutesagoUp27minutes0.0.0.0:5000->5000 /tcp registry 验证服务是否正常 #curlhttp://127.0.0.1:5000/v2/ {} 上传镜像 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 查看本地已有镜像 #dockerimages REPOSITORYTAGIMAGEIDCREATEDSIZE nginxv2570d531c994a4hoursago107MB nginxlatestb8efb18f159b3weeksago107MB centos6.80cd976dc0a9811monthsago195MB registry2.1.152bb991b482e22monthsago220MB 创建dockertag镜像 #dockertagnginx:v2127.0.0.1:5000/nginx:v2 即用ningx:v2创建127.0.0.1:5000 /nginx :v2的镜像 #dockerimages REPOSITORYTAGIMAGEIDCREATEDSIZE 127.0.0.1:5000 /nginx v2570d531c994a4hoursago107MB nginxv2570d531c994a4hoursago107MB nginxlatestb8efb18f159b3weeksago107MB centos6.80cd976dc0a9811monthsago195MB registry2.1.152bb991b482e22monthsago220MB push镜像到本地仓库 #dockerpush127.0.0.1:5000/nginx:v2 Thepushreferstoarepository[127.0.0.1:5000 /nginx ] 04a8761254c7:Pushed af5bd3938f60:Pushed 29f11c413898:Pushed eb78099fbf7f:Pushed v2:digest:sha256:9586184eb142f8c66decfd4fd7b3a2b54abfcb0f0a25541e69ba3725c61ba8b3size:8522 查看是否已经上传 #curlhttp://192.168.12.109:5000/v2/_catalog { "repositories" :[ "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 先删除已经有的镜像 [root@DockServeropt] #dockerimages REPOSITORYTAGIMAGEIDCREATEDSIZE 127.0.0.1:5000 /nginx v2570d531c994a4hoursago107MB nginxv2570d531c994a4hoursago107MB nginxlatestb8efb18f159b3weeksago107MB centos6.80cd976dc0a9811monthsago195MB registry2.1.152bb991b482e22monthsago220MB [root@DockServeropt] #dockerrmi-f570d531c994a Untagged:127.0.0.1:5000 /nginx :v2 Untagged:127.0.0.1:5000 /nginx @sha256:9586184eb142f8c66decfd4fd7b3a2b54abfcb0f0a25541e69ba3725c61ba8b3 Untagged:nginx:v2 Deleted:sha256:570d531c994a495b7cba536ac12f9d640141cbbaecd9ae8a114816681a8ca750 Deleted:sha256:f4a3f9102faadf3e941a05724ffe69e3aa3dc1fee5de3762c374ee337a27d60b [root@DockServeropt] #dockerimages REPOSITORYTAGIMAGEIDCREATEDSIZE nginxlatestb8efb18f159b3weeksago107MB centos6.80cd976dc0a9811monthsago195MB registry2.1.152bb991b482e22monthsago220MB 确定已经删除后,我们下载 [root@DockServeropt] #dockerpull127.0.0.1:5000/nginx:v2 v2:Pullingfromnginx 94ed0c431eb5:Alreadyexists 9406c100a1c3:Alreadyexists aa74daafd50c:Alreadyexists 79afb5d63c06:Pullcomplete Digest:sha256:9586184eb142f8c66decfd4fd7b3a2b54abfcb0f0a25541e69ba3725c61ba8b3 Status:Downloadednewerimage for 127.0.0.1:5000 /nginx :v2 [root@DockServeropt] #dockerimages REPOSITORYTAGIMAGEIDCREATEDSIZE 127.0.0.1:5000 /nginx v2d296335af0a94hoursago107MB nginxlatestb8efb18f159b3weeksago107MB centos6.80cd976dc0a9811monthsago195MB registry2.1.152bb991b482e22monthsago220MB 可以看到已经本地仓库 可以成功上传 下载镜像了 本文转自 jackjiaxiong 51CTO博客,原文链接:http://blog.51cto.com/xiangcun168/1957392

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

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文件系统,支持十年生命周期更新。

用户登录
用户注册