左直拳的马桶_日用桶

发觉里面的地址设为114.114.114.114。114我有点印象，估计是中国电信的。网上文章说改为8.8.8.8。据说114用于国内，8888（发发发发）用于国外。但我两个都不用，我改为180.76.76.76，这个是百度的公共DNS服务器。近期在一台centos7的服务器上部署系统，拉取docker镜像时总是超时，如图所示。网上有教程说，可以修改操纵系统的dns地址，试了一下，果然搞定。忽如一夜春风来，两行白鹭上西天。

但是微服务不是这么玩的，十月革命一声炮响，送来了nacos。所有的微服务都在nacos上注册，由nacos记录微服务的IP信息，当有请求时，nacos将请求分配至对应的微服务。这一切，对上层应用都是透明的，我们无须关心微服务的物理地址和处理烦琐的跳转，只要所有微服务都注册于同一个nacos，且用同一个命名空间，不管微服务安装在哪台服务器，网络相通的情况下，就能访问到想要的微服务。nacos除了用作配置中心，即可以将配置信息由配置文件转移到nacos上，更便于修改和维护外，更重要的，是用作微服务的注册中心。

这个非常重要。所谓的备份，首先是指把nacos的配置全部导出来，异机保存，下载到本地。同时不要删除现有的docker容器，可以将其停止，这样不影响新创建的容器使用现有的端口。不过，容器名不能重复。比如现有容器名为nacos，那么新创建的容器可以叫ncos230。

我一直直接使用docker命令来创建容器，没有怎么用过docker-compose。也不知道docker-compose和docker有什么区别，docker-compose有什么好处。现在我约略认为，docker-compose是一个简化docker命令的工具，或者说，它是能将docker各种繁琐的命令集成到配置文件的工具，所谓compose也者，就是组合的意思吧。

客户组织安全测试，我们系统测出了好几个高危问题，其中大部分是关于nacos的。原先的nacos版本太低了，是1.3的。现在（2024.01）已经是2.3了，应该装个新的。我们使用docker安装nacos，原本很简单的，只有一个小小的问题，就是服务器的CPU是arm64架构的。现在一般政府项目都是这样，国产化，信创，CPU必定是arm架构。因此，nacos也需要下载支持arm64的镜像。还有一个问题是，服务器不在互联网上，怎么下载？思路：1）在能上网的服务器上下载支持arm64的镜像。

采用docker部署kafka、zookeeper，一般的做法是创建一个docker网络，然后kafka、zookeeper都使用这个网络。问题是，我部署到生产环境的时候，这种做法被禁止了。原因是添加了这个docker网络以后，服务器就无法访问了。该服务器是通过互联网访问的。我也不知道为啥就会搞到他们网络崩溃，总之就是不允许。那怎么办？经摸索，证明可以采用两个docker容器共享其中一个容器的网络配置的做法。众所周知，docker容器各自独立，相互区隔，自成一个世界。同一个网络，就是为了能够互相访问。

今天将一个项目中的部分子系统部署，部署到虚拟机的docker里运行，结果外部无法访问。查看nacos，显示服务已经成功注册。后来发现，该服务的IP地址外部无法访问：估计172.17.0.0是docker自身的网段，在上面跑的程序，注册到nacos，直接就用到了docker里的地址。因为对于应用程序来说，docker是容器，就是一个操作系统。解决办法是，在虚拟机的宿主机上添加对该地址的路由。我的虚拟机装在windows下，即在windows里添加路由。

利用nacos作为配置中心，好处不言而喻，配置外置了，与程序解耦，并且nacos还提供了友好的管理界面。spring boot的卖点之一，就是与之前的spring相比，所谓约定重于配置，配置文件大大简化。现在使用nacos这种外置配置中心，是更加向前了一步。具体应用步骤：1、pom.xml中引入nacos支持包2、pom.xml中指向nacos3、配置文件中使用nacos配置项如此，即可使用nacos中的配置，修改啥的都很方便，根本不用远程服务器。

上次说道，我目前在做的一个项目，用的是基于一个叫open-cloud的微服务框架。该框架基于SpringCloud，认证使用oAuth2。见。虽然这个框架是几年前出来的，目前已经没有维护了，但对于我来说，仍然是学习的对象。

最近做的项目，包含多个业务子系统。系统结构前后端分离，前端VUE3，后端采用微服务框架，open-cloud（云服务开放平台）。

差点就放弃了。搞这些东西没有什么意义。有个java项目，需要开启ffmpeg拉流，然后想将这个程序部署在docker。不料颇多波折。幸而最后成功，差点就放弃了。记录如下。一、基本情况1、我们写了个视频拉流控制程序，依赖JDK1.8。运行过程中，需要启动操作系统的ffmpeg进行拉流。2、部署环境是统信欧拉版（UOS Euler） + docker。统信欧拉版是基于华为的OpenEuler（其前身是华为的服务器操作系统EulerOs)，是将OpenEuler的内核 + 统信的桌面操作模块DDE。“统

小小总结一、思路1、将docker容器中的指定文件夹挂载到宿主机上，更新jar包只需上传到宿主机指定路径，方便更新2、利用bash文件运行jar包，并构建该bash的镜像，代替构建直接运行jar包的镜像，利于镜像与jar包解耦。例如，app-1.0.0.jar 升级到 app-2.0.0.jar，只须更改bash文件的内容，而无须构建新的镜像。二、准备工作1、创建存放docker配置文件、jar包的文件夹在宿主机上，创建文件夹：/home/admin/app，用于存放bash文件和jar包。然

对于跑在docker里的nginx来说，docker就是一个虚拟机。它访问的，默认是docker里的路径。

自己动手，丰衣足食。看上去很琐碎繁杂，其实动手部署一次就好。现在计算机软件开发，发展出新花样。其中有前后端分离，和微服务。其实这2样东东，对软件产品本身并没有什么帮助，软件产品中应用了这些架构，并不会比没有应用它们的产品更优秀。甚至，还会有一些反作用。比如，前后端分离，数据只能通过请求获取，服务器处理并直接输出这种模式就没有了（websocket除外）。异步操作在数据量大的情况下体验比较好，如果只有一丁点数据，其实直接输出效果更佳。与前后端分离相伴生的单页面应用，加大了编码的复杂性，需要考虑以往WEB开

一、什么是单体架构功能集中、代码和数据中心化、一个发布包、部署后运行在同一进程的应用程序，称之为单体架构应用，也叫单块架构应用。前一篇文章说到三层架构，虽然系统分成3层，但最终运行，忽略负载均衡、水平扩展的情况下，仍然是同一台机器同一进程。我估计，我们当前开发的信息系统，除了微服务架构，其他都是单体架构。SOA，由多个单体架构程序组成；微服务的每个服务，粒度往往更小。微服务架构中的服务，是指一个单体系统拆分出来的一个个模块，依附于容器进行独立运行，每个模块不算一个完整的系统，叫组件可能更合适一些。SO

基本上，每个系统都有日志输出这一功能。不管采用什么成熟框架，或者自己开发吧，大多是保存到数据库，或者输出到文件，然后对这些数据进行分析、展示。这种思路，主体还是各人自扫门前雪，每个系统自己负责日志的输出、存储、应用。现在微服务时代，日志也可以独立划分出去，对外提供服务。比如下面介绍的这个logstash。logstash，从名字看，是日志存储器之意。实际上，我觉得它叫日志收集器更合适。它提供多种方式对应用程序进行日志收集，比如日志文件，http，tcp；然后收集到的日志，可以存储到数据库里，比如ES(

微服务架构现阶段甚嚣尘上。啥是微服务？微服务与SOA微服务框架

题目信息量很大，蕴含了以下信息：1、当前开发环境是WIN72、docker容器在Linux虚拟机中3、在WIN7里将直接将spring boot项目发布到该远程docker4、发布工具是maven据说docker最好部署在Linux。部署在windows也可以的，但要求操作系统是WIN10或以上。我机器老旧，只有WIN7，并且用Linux逼格比较高，就索性创建了一个Linux的虚拟机...

利用docker挂载redis，我有个疑问，redis产生的数据持久化的话，会存放在哪里?我刚使用docker没几天，这个问题的答案目前仍然不甚了了；也不清楚docker挂载redis的时候，是否要映射宿主目录到容器内，因为不映射，也不影响redis的数据持久化。先记下来。docker其实内部是有文件结构的。我们可以查看一下：docker psdocker exec -it 实例名 /bi...

题目不算长，但待做的工作却有许多，大致有：1、在vmware中安装linux虚拟机2、linux中安装docker3、docker中安装redis4、设置redis可供外部访问5、宿主机访问虚拟机的redis6、局域网其他机器访问宿主机中的虚拟机的redis详细说明一、在wmware中安装linux虚拟机宿主机操作系统WIN7，虚拟机软件vmware10。安装centos7。过程...

docker中可以轻易部署多个redis实例，这多少可以体现出docker的优点。部署多个实例，关键在于端口的问题。docker可以让每个redis实例的端口都是6379，然后映射到宿主机不同的端口，供外部访问。而本机里面，通过docker，还是可以直接访问每个实例。docker嘛，容器也，它就是管这些个实例的。命令如下：sudo docker run --name redis006 -p ...