Docker Compose

Docker-compose.yml这个文件怎么用? 容器之间访问,使用一个内网名称,外网的不好用? links: - "mysql:mysqldb" 这个是网站点击报错之后可以直接看错误,但是外网应该注释,外网应该看404? environment: #- ASPNETCORE_ENVIRONMENT=Staging 还有docker容器和服务器直接传输数据 docker cp ? 来源： oschina 链接： https://my.oschina.net/u/4417309/blog/4278124

在《 ASP.NET Core中Ocelot的使用：API网关的应用 》一文中，我介绍了如何在ASP.NET Core中使用Ocelot实现API网关。在介绍的过程中，引出了一个问题，就是服务之间相互调用的代码能不能别写死（hard code）在代码里，至少也得通过配置文件来指定吧？说的没错，很好的建议，只不过我也提到过，写在配置文件中也不是一个很好的实践。设想一下，假如我们有几十个微服务，各个微服务之间都有可能会有相互调用的情况，那么我们就需要维护大量的与微服务的地址、端口相关的配置信息，这样非常容易出错，如果是通过微服务的环境变量进行设置，那就更糟糕了，一大堆的环境变量设置，会使得应用程序的部署变得非常麻烦而且容易出错。另一个原因是，在云端部署的微服务，本身就具有伸缩的能力，服务的地址和端口很有可能是不固定的，所以，将这些信息保存在配置文件或者环境变量中是不合理的。因此，本文会介绍Spring Cloud Netflix Eureka服务的使用，通过服务注册与发现（Register and Discovery）机制，配合Ocelot的动态路由来解决这个问题。 这是一件有趣的事情：我们打算实现微服务，于是，将我们的业务拆分成两个微服务，然后发现微服务之间有相互调用的关系，客户端也需要同时使用多个微服务来展示处理结果，因此

分布式 ID 在庞大复杂的分布式系统中，通常需要对海量数据进行唯一标识，随着数据日渐增长，对数据分库分表以后需要有一个唯一 ID 来标识一条数据，而数据库的自增 ID 显然不能满足需求，此时就需要有一个能够生成全局唯一 ID 的系统，需要满足以下条件： 全局唯一性：最基本的要求就是不能出现重复的 ID。 递增：保证下一个 ID 一定大于上一个 ID。 信息安全：如果 ID 是连续的，用户就可以按照顺序进行恶意爬取数据，所以 ID 生成无规则。 上述的 2 和 3 点需求是互斥的，无法使用同一个方案满足。 解决方案 数据库生成 以 MySQL 为例，利用给字段设置 auto_increment_increment 和 auto_increment_offset 来实现 ID 自增。每次业务可以使用下列 SQL 进行读写得到 ID： begin; REPLACE INTO Tickets64 (stub) VALUES ('a'); SELECT LAST_INSERT_ID(); commit; 优点：使用非常简单，ID 单调递增。 缺点：非常依赖数据库，当数据库异常时则整个系统不可用。 UUID 优点：本地生成，没有网络消耗，性能高。 缺点：过长不易于存储；造成信息不安全，基于 MAC 地址生成可能会造成 MAC 地址泄露。 Snowflake Snowflake （雪花算法）是由

题图摄于旧金山渔人码头 本文系Harbor社区用户经验分享文章，首发于公众号：运维及时雨，授权转发。 作者简介： 杜秋，云计算运维工程师，目前主要从事Kubernetes技术栈的CI/CD运维，多年一线运维工作，参与平台搭建、平台迁移、企业从自建IDC到上云、自动化建设等运维核心项目。 说明：本文离线安装，后端挂载阿里云的OSS作为images存储，以后再也不怕磁盘爆满了。 Harbor 离线版本：harbor-offline-installer-v2.0.0.tgz Harbor 2.0版本相比之前的1.x更新的不少功能： 启用Trivy作为默认漏洞扫描器，简化了Trivy扫描器的配置。 启用了Harbor组件之间的TLS，使组件内的流量更安全。 Webhook的增强功能，包括支持与Slack的交互、可选择的事件列表、多终端、新事件等。 增强机器人账户，允许用户为每个机器人设置单独的过期时间。 重构错误处理框架，以便更好地排除故障。 在用户界面中查看未标记的镜像，并将其从GC和标记保留工作中包含/排除。 选择性地从镜像中删除标签，而不删除镜像摘要或其他相关标签。 默认是https,因为notary必须在https协议下，如果不需要配置notary可以设置http。 操作系统版本： [root@192-168-0-110 ~]# cat /etc/system-release

文章内容输出来源：拉勾教育Java高薪训练营 集群规划 计划在3台虚拟机安装hadoop、hbase、hive，192.168.3.24,192.168.3.7,192.168.3.8 hosts配置 /etc/hosts 192.168.3.24 centos1 192.168.3.7 centos2 192.168.3.8 centos3 环境变量 首先需要安装jdk，并配置环境变量。 export JAVA_HOME=/opt/soft/jdk1.8.0_45 export PATH=$PATH:$JAVA_HOME/bin:/opt/soft/apache-hive-2.3.6-bin/bin:/opt/soft/hadoop-2.9.2/bin hadoop环境 安装hadoop 配置文件，在/opt/soft/hadoop-2.9.2/etc/hadoop目录下，三台机子要修改成一样 core-site.xml <configuration> <property> <name>hadoop.tmp.dir</name> <value>file:/usr/local/hadoop/tmp</value> <description>Abase for other temporary directories.</description> </property>

通过 上文 所述案例，我们已经选择了最优回归算法来预测学生的综合成绩，并且完成了基于训练数据集的预测模型训练。从实现上，训练好的模型被保存成一个ZIP文件，以便在其它项目中直接调用以完成机器学习的实践场景。在本文中，我将介绍如何在ASP.NET Core中使用这个ZIP文件，以提供用于学生成绩预测的RESTful API。 将模型文件保存到Azure Blob Storage中 我们已经得到了经过ML.NET训练好的模型数据文件，也就是一个ZIP文件，在开发的RESTful API中，需要读入这个文件以便实现预测功能。于是，ZIP文件保存在何处就成为了我们首要解决的问题。在开发环境，我们可以将ZIP文件保存在ASP.NET Core的运行目录中，可是，开发好的RESTful API最终还是要部署到生产环境，这种部署有可能是单节点的，也有可能是位于负载均衡服务器后端的多节点部署，而且模型文件也会随着训练数据集的增加或变化进行增量式更新，因此，依赖于部署环境的本地文件系统并不是一个好的做法。因此，我选择将模型文件保存在 Azure Blob Storage 中。 注意：为了防止在开发调试阶段过多使用Azure Blob Storage的流量，我们可以在ASP.NET Core的应用程序中实现两套模型数据供应器：一套从本地文件系统读入模型，用于开发环境，另一套从Azure Blob

1，三个必用软件 （1）PUTTY：PuTTY 是⾃由的跨平台 Telnet/SSH 客户端，同时在 Win32 和 Unix 系统下模拟 xterm 终端 （2） Filezilla：通过 SFTP 协议进⾏本地和服务器的⽂件传输和管理。 （3）VS Code：说可视化的 Visual Studio Code，可以更⾼效的进⾏代码编辑和管理。 2.部署Web IDE代码环境 1，更换ECS镜像 2，安装Docker环境 首先，登录你的服务器，然后输入curl -sSL https://get.daocloud.io/docker |sh 。然后输入curl -L https://get.daocloud.io/docker/compose/releases/download/1.25.4/docker compose- uname -s - uname -m > /usr/local/bin/docker-compose chmod +x /usr/local/bin/docker-compose（安装 Docker-Compose 环境，其中 1.25.3 可以根据 最新版本 修改） 部署coder-server 1.创建项⽬⽂件夹： mkdir -p /home/coder/project 2.在 Docker 中运⾏： docker run -it -p 80:8080 -

在《 容器化单页面应用中RESTful API的访问 》一文中，我介绍了一个在容器化环境中单页面应用访问后端服务的完整案例。这里我将继续使用这个案例，介绍一下容器化单页面应用部署的另一个场景：将Nginx的职责独立出来。 注：这里单页面应用是值一个包含前端页面、后端服务以及后台数据库的一个完整应用系统，这样符合微服务模式对于服务的定义。不过为了介绍简单，文章案例不使用后台数据库，而是将数据“写死”在后端服务中。 继续回顾一下上篇文章中的案例，我们有两个服务：前端单页面应用（client），以及后端基于ASP.NET Core Web API的RESTful服务（service），案例代码地址是：https://github.com/daxnet/name-list。在这个案例中，前端单页面应用运行在Nginx容器中，这里的Nginx同时还承担了反向代理的角色，用以将前端页面发出的RESTful API请求正确地转发到ASP.NET Core Web API上。 如果整个系统只有这一个单页面应用，那么这么做是简单且合理的；但如果一个系统包含多个单页面应用，或者说一个系统包含一个前端页面与多个后台服务，那么，将Nginx反向代理的职责加到这个前端页面的容器上，明显是不合理的。为什么不合理？因为一个系统有可能不仅仅有基于Web的UI，而且还有可能会有移动客户端

docker容器配置hosts 可以通过下面两种方法把hosts配置到docker容器上 一、启动容器的时候加上“--add-host”把hosts配置上 # docker run --add-host=www.baidu.com:127.0.0.1 xxx -it /bin/bash 上面的容器启动之后，会把 “www.baidu.com 127.0.0.1” 这个配置写到容器的 /etc/hosts中 进入到容器中验证下 # docker ps -a # docker exec xxxx -it /bin/bash #xxx是上面执行后的容器id，CONTAINER ID # cat /etc/hosts 二、通过 docker-compose.yaml 文件启动 通过 extra_hosts 将hosts配置到容器中 php72: container_name: "php72" hostname: "php72" image: "xxxx" extra_hosts: - "www.baidu.com:127.0.0.1" - "www.google.com:127.0.0.1" volumes: - xxx:xxx 来源： oschina 链接： https://my.oschina.net/u/4364241/blog/4285323

博文大纲： 一、docker-compose命令对象与格式 二、命令选项 三、命令使用说明 1、build——构建（重新构建）项目中的服务容器 2、config——检测compose文件的错误 3、up——启动服务 4、down——停止容器 5、images——列出项目中所包含的镜像 6、logs——查看服务容器的日志 7、kill——发送 SIGKILL 信号来强制停止服务容器 8、port——查看某个容器端口所映射的公共端口 9、ps——列出项目中目前的所有容器 10、restart——重启项目中的服务 11、rm——删除所有停止状态的服务容器 12、run——在指定服务上运行一个命令 13、scale——设置指定服务运行的容器个数 14、stop——停止处于运行状态的容器 15、start——启动被stop的服务容器 16、top——查看各个服务容器内运行的进程 17、pause——暂停一个服务容器 18、unpause——恢复处于暂停状态中的服务 docker-compose术语： 服务（service）：一个应用容器，实际上可以运行多个相同镜像的实例。 项目（project）：由一组关联的应用容器组成的一个完整业务单元。 一个项目可以由多个服务（容器）关联而成，Compose面向项目进行管理。 一、命令对象与格式 对于Compose来说，大部分命令的对象既可以是项目本身