Docker

互联网技术发展速度之快是所有从业者甚至非从业者都能感受到的。尤记得在世纪之交时，那时候互联网刚刚在中国开始向民用普及，不说支撑大规模的网站访问量的相关技术，就连 Linux、负载均衡甚至都没有被普遍使用。而在二十年之后，云计算已经大行其道，当今的技术人员已经言必称虚拟化、容器和 Serverless，就连刚刚准备入行互联网运维行业的新人们都已经从最初觉得考个 Linux 认证就够了到开始问询 Kubernetes 培训哪家强了。 从一届届 LC3、DockerCon 到 KubeCon，蓬勃发展的云计算与容器化似乎已经称霸了互联网领域。这次我带队参加了 6 月 24 ~ 26 日的 KubeCon 大会，对此感受尤为深刻。事实上，这次在上海举办的 KubeCon 2019 距离上次在同一地点举办的同一会议才仅仅过去半年，但是我们依旧在这次大会上看到了层出不穷的大量新技术、新动态。 云与容器的结合，引爆了这一切。作为容器领域的资深专家，让我们来看看王旭是如何看待容器和云原生领域当前的发展态势的，以及作为这个领域的一家初创技术企业的创始人，他是如何投身到这个领域的，开源又在其间起到了什么作用。 创立于 2015 年的 runV 项目已于 2017 年和另外一个来自英特尔的 Clear 容器项目合并为 Kata 容器项目，并由 OpenStack 基金会（OSF）进行管理，它与来自谷歌的 gVisor 项目并称为目前两大安全容器技术。 开源与初创要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。临近 2015 年，Docker 逐渐被业界主流所接受，互联网技术已经有一个比较明显的发展趋势：第一是云，第二是容器。而云加上容器一定会产生隔离性的需求，这应该说是王旭和他的联合创始人赵鹏做安全容器最早的一个思路：要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。这就是 runV 这个项目想法的起源。 runV 发布的同一个星期，英特尔Clear 容器也发布了。2016 年 8 月份，在西雅图的 LinuxCon 上，王旭和 Clear 团队见面交流，双方在一些细节上面展开合作。在 2017 年 9 月份一个会议上，英特尔软件副总裁、开源技术中心总经理 Imad Sousou 提出项目合并，然后放到基金会里管理。当时大家都觉得这是很好的一个思路。 对于 runV 和 Clear 来说，避免了重复开发以及花费精力在如何说明两者的不同上，同时合并之后可以共同推动发展一个社区，一起去寻找更多的用户。同时，两者合并还有更多的意义。 ...

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。Kubernetes v1.16 发布周期开始随着前段时间 Kubernetes v1.15 的发布，v1.16 的发布周期开始了。本次的发布周期一如往常，本月底增强功能冻结，下月底代码冻结，9 月初完善文档，计划在 9 月中发布 v1.16 版本。 其实按这个节奏看得话，大家如果需要维护生产中的 Kubernetes 集群的话，还是尽快测试验证并完成升级，以免所用版本 EOL，带来一些其他的问题。 Knative Serving v0.7.x 发布本周 Knative Serving 发布了 v0.7.1 版本，Knative 近期的开发还是比较活跃的。 需要注意的是若使用 v0.7.x 版本中新增的 serving.knative.dev/v1beta1 API 的话，则需要 Kubernetes v1.14 版本以上。具体原因请参考 #4533 Non-root 容器：在这个版本中所有发布的容器均以非 root 用户运行，这使得我们可以使用更严格的 PSP。 当然此版本中也包含一些破坏性变更，比如 status 字段废弃。 关于此版本更多的细节请参考 ReleaseNote Debian 10 buster 正式发布Debian 10 正式发布了，其实按一般的角度来看，Linux 的一个发行版发布不会出现在 K8S 生态周报中的。 但这里有个需要注意的点，对于使用此版本部署 Kubernetes 时，需要注意一下。此版本中使用的 systemd 版本是 241.5 而这个版本中有个对于使用 Kubernetes 而言值得注意的点。 ...

2019年7月8日，Rainbond发布5.1.5版本，本次版本更新带来了全新的应用市场交付Pipeline体验，并对源码类服务的运行机制、ServiceMesh架构、服务管理等方面做了大量优化。 Rainbond：支撑企业应用的开发、架构、交付和运维的全流程，通过“无侵入”架构无缝衔接各类企业应用，底层资源可以对接和管理IaaS、虚拟机和物理服务器。发布版本：5.1.5版本更新：推荐更新范围：应用市场、源码构建、ServiceMesh架构、日志收集下面为大家带来详细的版本解读： Rainbond应用市场体验升级 Rainbond应用市场一直以来都是Rainbond的重点方向，有用户会问，Helm社区目前越来越成熟，应用越来越多，你们为什么不遗余力做自己的应用市场。不可否认，Helm应用规范已经得到了Kubernetes社区用户的认可，越来越多的开源应用企业在贡献Helm应用。但是，用过的人都知道，Helm应用规范是技术性要求很高的应用打包方式，要制作一个优秀的Helm应用，其难度甚至远远超出Kubernetes原生规范。Rainbond项目的目标是让广大用户无需学习Kubernetes技术（甚至无需学习容器技术）即可将自己的应用在云上开发、交付和运维。Rainbond应用市场的目标就是让所有开发者能够低门槛的，一键完成从代码到应用完整交付。 本次升级我们带来如下功能： 支持直接从云端安装应用到本地。 过去的版本中我们不得不先完成从云端同步到本地市场，再选择安装应用安装，过程略微繁琐且隐含较深，现在你可以直接查看到云端应用并直接安装。云端应用市场直接安装应用发布私有的应用到云端应用市场，交付给你想要交付的Rainbond用户。 应用市场为每个应用中的所有介质资源进行加密授权，发布的私有应用只有你授权的用户可以下载安装，跨云交付将非常简单。发布社区公开应用。 Rainbond应用流通将携带发布人的信息，你可以将你的企业应用上云推广了。除此之外，Helm应用那么多如何让Rainbond用户可以直接安装也是我们必须要解决的问题。我们正在进行的是将Helm应用转化为Rainbond应用存放于Rainbond应用市场中供用户直接安装使用。这个进程请关注：https://market.goodrain.com/h... ServiceMesh架构支持入站网络治理 本次版本继续对ServiceMesh架构进行优化，数据面板层面envoy版本升级到v1.9.0版本。控制面板层面增加了入站方向的网络治理支持，包括基于连接数、并发请求数等条件的连接熔断功能，同时引入了基于第三方限流服务的全局限流功能。优化了XDS控制器，有效比对资源的实际变化，有效降低推送到envoy的更新事件频率。 ServiceMesh透明化架构植入 Rainbond用户只需要开通相应的插件即可将业务服务与ServiceMesh架构相结合。 新增综合网络治理插件，支持入站网络治理 其他功能优化 源码构建的服务版本介质由slug包更改为容器镜像，源码类服务的运行将不再依赖于分布式文件系统，运行环境支持版本化控制。服务构建任务是一个消耗管理节点资源的动作，批量的服务构建如果不受限制将导致管理节点的资源耗尽。此次更新带来了构建任务的并发限制，最大并行任务数取决于当前管理节点的CPU核数。未能执行的任务将在消息系统中等待。优化了服务访问策略自动以环境变量形式注入服务的策略，便于服务能够获取当前服务的访问策略，对于部分Web类服务非常有用。更改了服务插件与应用运行时的通信地址，由过去Docker0网桥网卡地址更改为节点IP地址，如此移除了过去版本对Docker0网桥网卡IP地址的依赖。避免了如下异常情况出现：性能分析数据无法获取, 服务发现工作异常服务容器的标准输出和错误输出日志收集方式由之前的node服务从docker进程获取更改为node服务从宿主机日志文件获取，减小docker进程的压力，同时减小了日志呈现给用户的延迟时间。优化了grctl service get命令，便于用户之间查看服务的容器运行状态。BUG修复 修复自定义服务访问域名访问数据被忽略的BUG。修复服务连接信息前端未显示分页模块导致显示不全的BUG。修复服务构建版本、已删除服务持久化数据自动清理未正常工作的BUG，新版本中默认开启清理。应用备份时更改备份策略为只备份服务当前运行的构建版本，减小备份数据，提供备份成功率。修复了应用市场安装应用第一次未构建成功，后续无法继续构建的BUG。修复了服务环境变量与连接信息转移未生效的BUG。修复了应用升级时，新增的服务包含插件无法直接完成插件挂载的BUG。修复了节点更改节点属性后元数据不自动更改的BUG。修复了NodeJS语言类型设置Runtime版本失败无法编译的BUG。版本安装 当前版本为5.1系列最新版本，从发布之日起安装的5.1版本系列平台即时最新的5.1.5版本，安装参考：Rainbond集群安装 版本升级 升级要求和注意事项 V5.1.5版本支持从V5.1.2-V5.1.4版本升级，如果你还未升级到V5.1.2版本，参考V5.1.x版本升级文档，先升级至V5.1.2版本：grctl version, 例如版本显示如下：Rainbond grctl v5.1.4-release-1b49703-2019-05-19-10升级过程会重启管理服务，因此只有单管理节点的集群会短暂影响控制台操作，请选择合理的升级时间段 。下载 5.1.5 更新包 离线包镜像大小约650MB，需要保证当前集群磁盘可用空间至少不低于2G # Rainbond 组件升级包wget https://pkg.rainbond.com/offline/5.1/rainbond.images.2019-07-07-5.1.5.tgz -O /grdata/services/offline/rainbond.images.upgrade.5.1.5.tgz# 升级脚本包wget https://pkg.rainbond.com/offline/5.1/rainbond-ansible.upgrade.5.1.5.tgz -O /grdata/services/offline/rainbond-ansible.upgrade.5.1.5.tgz解压安装脚本,执行升级脚本 rm -rf /tmp/rainbond-ansiblerm -rf /grdata/services/offline/upgradetar xf /grdata/services/offline/rainbond-ansible.upgrade.5.1.5.tgz -C /tmp/cd /tmp/rainbond-ansible/scripts/upgrade/bash ./upgrade.sh升级完成验证 执行 grctl cluster确定所有服务和节点运行正常grctl version 确认版本已升级到5.1.5，运行组件镜像版本为 v5.1.5-release升级如有问题，请至社区反馈。

Kubernetes 简称 k8s，是 google 在 2014 年发布的一个开源项目。 Kubernetes 解决了哪些问题？ 真实的生产环境应用会包含多个容器，而这些容器还很可能会跨越多个服务器主机部署。Kubernetes 提供了为那些工作负载大规模部署容器的编排与管理能力。Kubernetes 编排让你能够构建多容器的应用服务，在集群上调度或伸缩这些容器，以及管理它们随时间变化的健康状态。 kubernetes 基础kubernetes 优化kubernetes 实战Kubernetes 基础概念很多，第一次接触容易看晕，如果是新手，建议直接看实战部分，先跑起来再说。 kubernetes 基础k8s 中有几个重要概念。 概念介绍cluster一个 k8s 集群master集群中的一台机器，是集群的核心，负责整个集群的管理和控制node集群中的一台机器，是集群中的工作负载节点podk8s 最小调度单位，每个 pod 包含一个或多个容器label一个 key = value 键值对，可以附加到各种资源对象上，方便其他资源进行匹配controllerk8s 通过 controller 来管理 podservice对外提供统一的服务，自动将请求分发到正确的 pod 处namespace将 cluster 逻辑上划分成多个虚拟 cluster，每个 cluster 就是一个 namespaceClusterCluster 代表一个 k8s 集群，是计算、存储和网络资源的集合，k8s 利用这些资源运行各种基于容器的应用。 Master 节点Master 是 cluster 的大脑，运行着的服务包括 kube-apiserver、kube-scheduler、kube-controller-manager、etcd 和 pod 网络。 kube-apiserver apiserver 是 k8s cluster 的前端接口，提供 restful api。各种客户端工具以及 k8s 其他组件可以通过它管理 cluster 中的各种资源。kube-scheduler ...

在详细介绍这篇文章的内容前，需要说明下笔者写这篇文章的意图：笔者在现有的开发中，前后端联调的方式为Docker镜像对接，数据库使用MySQL镜像，开发环境为远程服务器，因此，笔者迫切需要一种能将远程服务器端的MySQL镜像中的数据库进行可视化。 如何使用MySQL镜像？ 利用docker search mysql命令可以搜索关于MySQL的Docker镜像，利用docker pull mysql:5.7.26命令可以拉取MySQL的版本号为5.7.26的Docker镜像。本文以该镜像作为MySQL的演示镜像。 拉取MySQL5.7.26镜像后，利用docker images | grep mysql可以查看拉取的MySQL镜像的信息，如下： $ docker images | grep mysqlmysql 5.7.26 a1aa4f76fab9 3 weeks ago 373MB 接着启动该镜像，启动的命令如下： docker run -p 3307:3306 -e MYSQL_ROOT_PASSWORD=jclian91 -v $HOME/mysql_data:/var/lib/mysql --name jclian91-mysql -d mysql:5.7.26参数解释如下： -p: 表示端口映射，将宿主的3307端口映射到容器的3306端口；-e: 表示传入的环境变量参数，这里设置MySQL的root账户的密码为jclian91;-v: 表示数据卷的挂载，这里将宿主的HOME目录下的mysql_data挂载到容器的/var/lib/mysql目录；name表示容器的名称；-d: 表示容器在后台启动；mysql:5.7.26表示启动的镜像。 利用docker ps可以查看这个运行的docker镜像，如下: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESfdb9e8d40ffb mysql:5.7.26 "docker-entrypoint.s…" 3 seconds ago Up 2 seconds 33060/tcp, 0.0.0.0:3307->3306/tcp jclian91-mysql 利用命令docker exec -it fdb9e8d40ffb bash可以进入该容器内部进行操作，其中fdb9e8d40ffb为该容器的ID号。进入该容器后，输入命令mysql -u root -p，再输入密码jclian91，即可进行MySQL操作了。笔者在MySQL中，创建了test数据库，同时创建了EMPLOYEE表，如下： ...

docker从入门到实战-实战篇前言本文是我通过三个星期业余时间学习后而写的文章，对docker的了解还处于入门阶段。希望本文能帮忙一些想学习docker的朋友快速入门。练习及实战代码都在github仓库中。如果我的文章能帮助到你的话，可以给我的docker项目点个赞哦 docker实战本次实战案例是todolist。技术栈为vue、node、mysql。具体代码见项目目录todolist,下面就不一一贴代码了。就讲下重点。 下面我就顺着依赖关系来讲，所以先从mysql开始讲起 构建mysql执行：docker run --name mymysql -d -p 3308:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql --name 给mysql容器设置匿名-d表示后台运行-p表示将容器的3306端口的映射到本地的3308端口，如果不设置的话，本地是无法访问该MySQL服务的。-e MYSQL_ROOT_PASSWORD 设置root的账号密码。mysql 后面不指定版本话，默认会latest版本在执行该语句之前，假如你之前没有pull过mysql镜像。docker在本地找不到你要的镜像就会帮你从docker仓库拉取mysql:latest镜像。 这个时候容器就启动成功了。 尝试下用navicat连接下试试 鼠标放入黄色小三角出现如下报错。 2013 - Lost connection to MySQL server at 'reading initial communication packet', system error: 0 "Internal error/check (Not system error)"这是因为mysql8以上，都会使用新的验证方式。 不妨查下信息: select host,user,plugin,authentication_string from mysql.user; mysql> select host,user,plugin,authentication_string from mysql.user;+-----------+------------------+-----------------------+------------------------------------------------------------------------+| host | user | plugin | authentication_string |+-----------+------------------+-----------------------+------------------------------------------------------------------------+| % | root | caching_sha2_password | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 || localhost | mysql.infoschema | caching_sha2_password | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED || localhost | mysql.session | caching_sha2_password | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED || localhost | mysql.sys | caching_sha2_password | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED |)7k44VulAglQJgGpvgSG.ylA/rdbkqWjiqQJiq3DGsug5HIy3 |ord | $A$005$0pU+sGm[on+-----------+------------------+-----------------------+------------------------------------------------------------------------+plugin一栏可看到都是caching_sha2_password。 ...

docker从入门到实战-基础篇docker基础前言本文是我通过三个星期业余时间学习后而写的文章，对docker的了解还处于入门阶段。希望本文能帮忙一些想学习docker的朋友快速入门。练习及实战代码都在github仓库中。如果我的文章能帮助到你的话，可以给我的docker项目点个赞哦 介绍docker是一个开源的应用容器引擎，开发者可以打包自己的应用到容器里面，然后迁移到其他机器的docker应用中，可以实现快速部署。如果出现的故障，可以通过镜像，快速恢复服务。 举个例子，公司一般都会有多套环境，那么如何保持多套的运行环境一致，这个时候就可以用到docker。且当要求增加一套环境的时候，你无需在一个新服务器上一个个环境安装、配置。只需要运行下docker。同时官方还提供了Docker Hub，拥有大量的高质量的官方镜像。你可以将自己的镜像上传上去。有点类似于github。 安装官方提供了安装教程，挺详细的。官方安装教程 docker起步第一步：执行下docker -v确认下是否成功安装了docker 如果成功安装了，命令行将会输出入docker的版本号。如下：Docker version 18.09.2, build 6247962 docker的整个生命周期大致可分为： 镜像容器仓库这里以ubuntu镜像为例，介绍下镜像 在下载ubuntu镜像之前运行下docker images(查看镜像命令)查看下本地的镜像。如果你还没下载过镜像的话，当然会出现空。这里贴下我本地的镜像 ➜ study-docker git:(master) ✗ docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEtodolist_static latest de5e325037e9 2 hours ago 1.05GBtodolist_nodejs latest 53efd80e03e1 2 hours ago 898MBubuntu 18.04 7698f282e524 4 weeks ago 69.9MBmysql latest 990386cbd5c0 5 weeks ago 443MBnode 8 a5c31320f223 6 weeks ago 895MBmysql 5.6 73829d7b6139 6 weeks ago 256MB使用拉取镜像命令docker pull 拉取ubuntu镜像：docker pull ubuntu。当你不指定版本时，默认拉取latest版本。 ...

前言本次博文依然是对 multi-spa-webpack-cli 的扩充和完善。 集成 mongoose。集成 Docker 开发环境。multi-spa-webpack-cli 已经发布到 npm，只要在 node 环境下安装即可。 npm install multi-spa-webpack-cli -g使用步骤如下: # 1. 初始化项目multi-spa-webpack-cli init spa-project# 2. 进入文件目录cd spa-project# 未使用 Docker# 3. 打包不变的部分npm run build:dll# 4. 启动项目（手动打开浏览器：localhost:8090）npm start# 5. 启动 MongoDBmongod# 6. 启动服务cd servernpm installnpm start# 使用 Docker（需安装docker）# 3. 启动项目（手动打开浏览器：0.0.0.0:8090）npm run docker:dev从上面的步骤可以看出，Docker 只需要 3 步就可以启动项目了。 mongoosemongoose 是在 node.js 环境下对 MongoDB 进行便捷操作的对象模型工具。在没开始之前，要先安装 MongoDB。安装 MongoDB 的过程中，可能有些小麻烦，尤其是公司的电脑（谁也不知道电脑里配置了什么东西）。安装过程可参照 【官网：安装MongoDB】 还要知道 MongoDB 的一些概念。 SQL术语/概念MongoDB术语/概念解释/说明databasedatabase数据库tablecollection数据库表/集合rowdocument数据记录行/文档columnfield数据字段/域indexindex索引tablejoins表连接,MongoDB不支持primary keyprimary key主键,MongoDB自动将_id字段设置为主键数据库服务和客户端： SQLMongoDBMysqld/Oraclemongodmysql/sqlplusmongomongoose 相关概念看看官网就好了【mongoose 中文文档】 ...

以下是阅读 《每天5分钟玩转Docker容器技术》的笔记： Dockerfile 中每一个指令都会创建一个镜像层，上层是依赖于下层的。无论什么时候，只要某一层发生变化，其上面所有层的缓存都会失效。docker build -t target_image_name . 命令结尾的 . 指明 build context 为当前目录。 Docker 默认会从 build context 中查找 Docker 文件。 我们也可以通过 -f 参数指定 Dockerfile的位置当容器启动时，一个新的可写层被加载到镜像的顶部。 这一层通常被称作“容器层”，“容器层”之下的都叫“镜像层”。所有对容器的改动 - 无论添加、删除、还是修改文件都只会发生在容器层中。Docker 容器就是 Docker 镜像的运行实例。只有容器层是可写的，容器层下面的所有镜像层都是只读的。下面我们深入讨论容器层的细节。 镜像层数量可能会很多，所有镜像层会联合在一起组成一个统一的文件系统。如果不同层中有一个相同路径的文件，比如 /a，上层的 /a 会覆盖下层的 /a，也就是说用户只能访问到上层中的文件 /a。在容器层中，用户看到的是一个叠加之后的文件系统。 添加文件 在容器中创建文件时，新文件被添加到容器层中。读取文件 在容器中读取某个文件时，Docker 会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后打开并读入内存。修改文件 在容器中修改已存在的文件时，Docker 会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后修改之。删除文件 在容器中删除文件时，Docker 也是从上往下依次在镜像层中查找此文件。找到后，会在容器层中记录下此删除操作。只有当需要修改时才复制一份数据，这种特性被称作 Copy-on-Write。可见，容器层保存的是镜像变化的部分，不会对镜像本身进行任何修改。 这样就解释了我们前面提出的问题：容器层记录对镜像的修改，所有镜像层都是只读的，不会被容器修改，所以镜像可以被多个容器共享。 ############################################################### Docker 容器Docker 容器就是 Docker 镜像的运行实例。 用户可以通过 CLI（docker）或是 API 启动、停止、移动或删除容器。可以这么认为，对于应用软件，镜像是软件生命周期的构建和打包阶段，而容器则是启动和运行阶段。 docker run ：创建一个新的容器并运行一个命令. docker run [OPTIONS] IMAGE [COMMAND] [ARG...] e.g. 实例: ...

rTorrent是一个非常简洁、优秀、非常轻量的BT客户端，它使用ncurses库以C++编写，将 rTorrent 用在安装有 GNU Screen 和 Secure Shell 的低端系统上作为远程的 BT 客户端是非常理想的。 一般来说，安装rTorrent以及ruTorrent比较麻烦，因为还得额外安装Web 服务器并配置，今天我来教大家一个快速安装rTorrent的方法，让我们来忘记复杂的命令行安装过程吧，使用URLOS点点鼠标就能搞定！ 首先我们需要在Linux系统安装URLOS，URLOS是一款基于Docker容器技术打包和运行应用的容器云管理面板，可管理主机和网站。我们可以通过下面这条语句进行安装： curl -LO www.urlos.com/iu && sh iuURLOS的安装和基本使用方法就不再赘述了，具体可以到URLOS官网查看，我们直接开始安装rTorrent。 在应用市场搜索“rTorrent”点击安装按钮基本上我们只配置一下前3项就可以了详细的配置请看图吧基本信息网站，尽量使用一个可访问的域名吧，如果不想使用域名，可以在URLOS系统设置里面修改一下，使用ip访问也可以。设置rtorrent，根据自己的需要进行设置吧设置好前三个内容，点击提交即可，等部署完成之后，在地址栏中输入域名进行访问OK~访问正常，rTorrent安装成功！现在让我们尽情的使用BT下载吧 URLOS安装rTorrent简直太快太方便了，非常适合懒得折腾的小伙伴，推荐大家使用！

利用verdaccio创建npm私有库文章说明本文记录在语雀中，可以查看 利用verdaccio创建npm私有库。

作者| 张磊，阿里云容器平台高级技术专家，CNCF Ambassador （CNCF 官方大使），Kubernetes 项目资深成员与维护者，曾就职于 Hyper、微软研究院（MSR），现在负责 Kubernetes 技术及上下游相关工作。 2019年，全世界的开发人员都开始习惯用容器测试自己的软件，用容器做线上发布，开始对容器化的软件构建和交付流程习以为常。全世界的架构师们都在对“云原生”侃侃而谈，描绘多云时代的应用治理方式，不经意间就把 “sidecar” 这种容器组织方式当做了默认选项。在“云”已经成为了大众基础设施的今天，我们已经习惯了把“容器“当做现代软件基础设施的基本依赖。这就像我们每天打开 Eclipse 编写 Java 代码一样自然。 但往回倒数两年， 整个容器生态都还在围着 Docker 公司争得不可开交，看起来完全没有定数。当时的国内很多公有云厂商，甚至都没有正式的 Kubernetes 服务。在那个时候，要依托容器技术在云上托管完整的软件生命周期，可以说是相当前沿的探索。谁能想到短短两年之后，容器这个站在巨人肩膀上的设计，就真的成为技术人员日常工作的一部分呢？ 伴随着容器技术普及到“千家万户”，我们在这两年期间所经历的，是现代软件交付形式的一次重要变革。 源起：属于 Jails 们的时代虚拟化容器技术（virtualized container）的历史，其实可以一直追溯上世纪 70 年代末。时间回到 1979 年，贝尔实验室（ Bell Laboratories 正在为 Unix V7 （Version 7 Unix）操作系统的发布进行最后的开发和测试工作。 Ken Thompson(sitting) and Dennis Ritchie at PDP-11 ©wikipedia 在那个时候，Unix 操作系统还是贝尔实验室的内部项目，而运行 Unix 的机器则是长得像音响一样的、名叫 PDP 系列的巨型盒子。在那个“软件危机（The Software Crisis）”横行的末期，开发和维护 Unix 这样一套操作系统项目，即使对贝尔实验室来说也绝非易事。更何况，那里的程序员们还得一边开发 Unix ，一边开发 C 语言本身呢。 而在 Unix V7 的开发过程中，系统级别软件构建（Build）和测试（Test）的效率其实是其中一个最为棘手的难题。这里的原因也容易理解：当一个系统软件编译和安装完成后，整个测试环境其实就被“污染”了。如果要进行下一次构建、安装和测试，就必须重新搭建和配置整改测试环境。在有云计算能力的今天，我们或许可以通过虚拟机等方法来完整的复现一个集群。但在那个一块 64K 的内存条要卖 419 美元的年代，“快速销毁和重建基础设施”的想法还是有点“科幻”了。 ...

1.节点规划：2种方式：1主+多从，多对主从，第二种分担主节点、容易扩容缩减。 容器名称 容器IP地址 映射端口号 服务运行模式Redis-master1 172.1.50.11 6391->6379,16391->6379 masterRedis-master2 172.1.50.12 6392->6379,16392->6379 masterRedis-master3 172.1.50.13 6393->6379,16393->6379 masterredis-slave1 172.1.30.11 6394->6379,16394->6379 Slaveredis-slave2 172.1.30.12 6395->6379,16395->6379 Slaveredis-slave3 172.1.30.13 6396->6379,16396->6379 Slave添加10000+ 的“bus-port”端口，可以查看官方redis.conf的说明： # * cluster-announce-ip# * cluster-announce-port# * cluster-announce-bus-port # 解释在上述段落下方，多余端口用于集群的自动检测。官方参考文档。 a.创建自定义网络这里为了方便，把redis加入之前的mybridge网络，方便php、lua的调用。高可用时通过主机网络访问，所以主从都要对主机开放端口。如上。 2.初步创建集群a.制作容器创建脚本简化名称：clmx 主服务器clsx 从服务器 docker stop clm1 clm2 clm3 cls1 cls2 cls3docker rm clm1 clm2 clm3 cls1 cls2 cls3docker run --name clm1 \ -p 6391:6379 -p 16391:16379 \ --restart=always \ --network=mybridge --ip=172.1.50.11 \ -v /root/tmp/dk/cluster_redis/6391/data:/data \ -v /root/tmp/dk/cluster_redis/6391:/etc/redis \ -d cffycls/redis5:1.7 docker run --name clm2 \ -p 6392:6379 -p 16392:16379 \ --restart=always \ --network=mybridge --ip=172.1.50.12 \ -v /root/tmp/dk/cluster_redis/6392/data:/data \ -v /root/tmp/dk/cluster_redis/6392:/etc/redis \ -d cffycls/redis5:1.7 docker run --name clm3 \ -p 6393:6379 -p 16393:16379 \ --restart=always \ --network=mybridge --ip=172.1.50.13 \ -v /root/tmp/dk/cluster_redis/6393/data:/data \ -v /root/tmp/dk/cluster_redis/6393:/etc/redis \ -d cffycls/redis5:1.7 docker run --name cls1 \ -p 6394:6379 -p 16394:16379 \ --restart=always \ --network=mybridge --ip=172.1.30.11 \ -v /root/tmp/dk/cluster_redis/6394/data:/data \ -v /root/tmp/dk/cluster_redis/6394:/etc/redis \ -d cffycls/redis5:1.7 docker run --name cls2 \ -p 6395:6379 -p 16395:16379 \ --restart=always \ --network=mybridge --ip=172.1.30.12 \ -v /root/tmp/dk/cluster_redis/6395/data:/data \ -v /root/tmp/dk/cluster_redis/6395:/etc/redis \ -d cffycls/redis5:1.7 docker run --name cls3 \ -p 6396:6379 -p 16396:16379 \ --restart=always \ --network=mybridge --ip=172.1.30.13 \ -v /root/tmp/dk/cluster_redis/6396/data:/data \ -v /root/tmp/dk/cluster_redis/6396:/etc/redis \ -d cffycls/redis5:1.7 b.测试配置文件，建立集群在之前主从配置基础上，搜索修改 ...

项目的自动化部署在大公司或独角兽中用得比较多，相比来进行手动部署项目来说会更加高效。那么本文结合之前学习的docker知识点以及nginx来简单实现VueJs项目的自动部署，当然针对其他项目也类似。运行环境首先需要在服务器上进行docker、nginx、node等的安装。便于进行后续的操作。通过docker拉取nginx镜像，命令docker pull nginx通过vue-cli初始化一个项目可以通过vue init webpack 项目名称初始化一个项目，这里假设项目名称是docker-vue，然后在该项目的根目录新建一个Dockerfile文件，大致内容如下: FROM nginx:latest#把当前打包工程的html复制到虚拟地址COPY dist/ /usr/share/nginx/html/#使用自定义nginx.conf配置端口和监听RUN rm /etc/nginx/conf.d/default.confADD default.conf /etc/nginx/conf.d/RUN /bin/bash -c 'echo init ok!!!'并新建一个default.conf文件，内容如下： server {项目中定义的端口号listen 8080;server_name localhost;#charset koi8-r;#access_log /var/log/nginx/log/host.access.log main;location / { root /usr/share/nginx/html; index index.html index.htm;}#error_page 404 /404.html;# redirect server error pages to the static page /50x.html#error_page 500 502 503 504 /50x.html;location = /50x.html { root html;}}自此，基本工作已完成，接下来就是对于daocloud.io的基本配置操作了 daocloud.io基本配置操作若无账号，可以先进行注册daocloud.io。接下来的操作分为： 创建项目集群管理创建镜像仓库创建项目这里需要添加项目名称，设置代码源(可以是github、gitlab)等，然后选择你所需要构建的项目，我这里选择了我自己的github仓库docker-vue，然后点击开始创建就行。 集群管理集群管理的主要目的是为了链接远程服务器，并通过命令进行daocloud.io镜像的创建。选择新建主机 由于我自己是购买了阿里云服务器了，系统是ubuntu的，所以就选择了这样的配置，然后在服务器上运行： curl -sSL https://get.daocloud.io/daomonit/install.sh | sh -s e2fa03ebead51076411388c26dff2257dae89768 来构建一个docker镜像，如： ...

网易云信IM私有化部分用到Docker技术，今天我们就深入浅出来聊聊Docker。 Docker是什么?Docker是一个工具，能把应用打包部署于container里，这里可以把container看做是一个简易版的 Linux 环境和运行在其中的应用程序，每个container运行一个application。它诞生于 2013 年初，最初是 dotCloud公司内部的一个业余项目，创始人是Solomon Hykes。Docker自开源后受到广泛的关注和讨论，Redhat已经在其 RHEL6.5 中明确支持Docker；Google也在其PaaS产品中广泛应用。Docker项目的目标是实现轻量级的操作系统虚拟化解决方案。 现在Docker已经从一个工具转化成平台，小生态圈。 Docker的优势有哪些？ 以前企业部署软件会购买真正的服务器，这种模式的资源利用率很低。后来出现了云端的虚拟服务器，比如AWS，提高了一定的资源利用率，但是不同阶段的应用环境可能不同。 Docker对这些有很大的优化，比如： 1. Docker 容器可以实现秒级启动 2. 容器除了运行其中应用外，基本不消耗额外的系统资源，使得应用的性能很高，系统的开销很小。传统虚拟机方式运行10个不同的应用就要起10个虚拟机，而Docker只需要启动10个隔离的应用即可。 下图是传统虚拟化方式和Docker的不同。Docker本质上是一种虚拟化的技术，不是虚拟机。Docker是在操作系统层面上实现虚拟化，直接复用本地主机的操作系统，而传统方式则是在硬件层面实现。在传统模式下，Guest OS会占用大量空间，而且不同的应用会需要不同的虚拟机。在Docker中只有一个OS，各种application运行在一个OS上。 *Hypervisor是一种虚拟化的技术具体来说，Docker的优势包括： Faster developer onboardingNo vendor lockinEliminate environment inconsistenciesShip applications fasterScale quicklyEasily remediate issuesPlay with Docker container下载安装完Docker后，可以尝试使用以下命令来运行一个聊天软件。docker run -d -p 3000:3000 unclebarney/chit-chat这个命令的含义是启动Docker容器。-d表示在后台启动。-p表示做端口的映射，把容器里的3000端口映射到宿主机上的3000。使用的镜像为unclebarney/chit-chat。 这个命令有两部分操作：1.从Dockerhub（所有镜像存储的地方）下载此镜像，大概5到30秒（取决于带宽）2.根据镜像启动container，并运行node server Docker imageDocker image（镜像）是container的基础。所有container都是从image构建的。 Docker 运行容器前需要本地存在对应的镜像，如果镜像不存在本地，Docker 会从镜像仓库下载（默认是 Docker Hub 公共注册服务器中的仓库）。Docker每个运行的实例由最上层的container和下面的多层镜像构成。Docker使用Union FS（union filesystem）将这些不同镜像整合在一起。通常Union FS有两个用途, 一方面可以实现不借助LVM、RAID将多个disk挂到同一个目录下；另一个更常用的就是将一个只读的分支和一个可写的分支联合在一起，Live CD正是基于此方法可以允许在镜像不变的基础上允许用户在其上进行一些写操作。 镜像的每一层都有以下这些信息：1.这一层的meta data，以JSON的形式存储2.image filessystem changeset3.image ID，比如：74fe38d11401镜像有两种构建方式：1.启动一个最基础的容器，在里面运行一些命令，像git一样把这些命令commit，形成自己的镜像。2.引用一个base image，再加上一些需要的指令。这些指令存在一个文件中，叫Dockerfile。以下是Dockerfile的例子，是刚才提到的聊天软件的镜像的生成方式。# 引用mhart/alpine-node这个镜像 # Dockerfile中第一个命令必须是FROM命令 FROM mhart/alpine-node:base # 将Dockerfile所在文件夹中的内容添加到Docker镜像中 # 第一个点指的是Dockerfile所在的目录 # 第二个点指的是Docker镜像中的当前目录 ADD . . # 为这个镜像暴露3000端口 EXPOSE 3000 # 运行node命令。值得注意的是在构建镜像的时候这个命令不会执行 # 而是在真正基于这个镜像启动了容器时才会执行这个命令 CMD [“node”, “index.js”] ...

据相关调研机构报告数据显示，目前应用容器市场规模将从2016年的 7.62亿美元增⻓到2020年的27亿美元。 显而易⻅，引入容器所展现的巨大灵活性有效推动了其采用速率，使企业日益依赖该技术，与此同时容器技术也逐渐成⻓为虚拟机的实力替代品。对此，调研机构Forrester公司曾指出，58%的开发商计划在未来一年内使用容器或正在计划使用容器。 总结一句，使用容器可以帮助企业提高效率、降低成本，甚至在安全性方面有更可靠的保障， 这些易于打包以及轻量级的组件可以与同一虚拟机中的其他组件一起运行。 此外容器的大力采用也让开发者通过创建虚拟“沙箱”来更快、更好地工作，从而完成编写、管理和操作软件代码，可以在不影响服务器或虚拟机(VM)上运行其他应用程序和系统的情况下就可完成此操作。 基于此，CSDN云计算特别策划了容器服务盘点系列文章，欲以CSDN中立技术社区专业、客观的角度，探讨当前云服务商眼中的“容器服务”并为开发者选择合适的容器服务提供部分可参考的建议，以帮助其实现容器技术的创新应用等。 为此我们采访了数家提供容器服务的云服务厂商，而本期程序员硬核评测则特别邀请到腾讯云容器产品总监邹辉，详尽分享针对容器发展的真知灼见以及明星产品企业级容器云服务平台TKE的方方面面。 腾讯云容器产品总监 邹辉新技术的关注与实践，不是一朝一夕 据阿晶了解，腾讯云投身容器技术的时间挺早，而TKE可谓是其容器服务的明星产品，经常被概括为“基于原生 Kubernetes 来提供以容器为核心、高度可扩展的高性能容器管理平台”。 具体来说，TKE可以做到无缝衔接腾讯云在计算、网络、存储、以及安全方面的诸多能力，还高效扩展了 网络、GPU虚拟化、特定CRD资源 等 Kubernetes 插件。不但在有效部署、资源调度、服务发现、动态伸缩上面助力完整功能；还提高了大规模容器集群下业务管理的便捷性。未来，腾讯云容器产品总监邹辉也强调，作为腾讯云在容器产品中最核心的部分，TKE的功能层深度优化以及周边生态的演进将成为团队至关重要的事情。 谈及TKE，我们会不自觉想到腾讯云原生应用编排平台的创新实践，除了涵盖容器服务层面之外，众所周知的开发运维平台、Service mesh、无服务套件以及基于以上产品的大数据、人工智能解决方案等统统包含其中。据了解，目前该平台在腾讯内部已经成功承载了数以亿计的容器，并支撑众多海量业务平稳运行以及迭代升级，同时还成功赋能互联网、电商、政务、能源等多领域、多方向。 对此邹辉总结道：“其实腾讯很早之前就关注了云原生以及容器技术的发展，这注定是未来很有代表性以及前景的技术方向之一，所以我们对此的投入力度很大。” 确实！据阿晶了解，无论是产品还是社区运营，腾讯云对其都是关注颇多。从产品层面出发，腾讯云在容器、微服务以及无服务器领域都有专业的研发团队来进行技术以及业务的支撑，相关产品的推出更是层出不穷。 “相比于其他云厂商，腾讯内部在很早之前就已经研究与容器相关的技术与服务，其中很多成功的业务，例如游戏、微信、广告等都选择运行在容器技术上，可以说容器技术正在支撑着数十亿计的用户”他说。 如果从技术角度着眼，腾讯内部的容器建设也经历了从青涩到成熟的发展路径，这个过程中无论是在容器的功能还是稳定性，抑或是资源利用率上都有了逐渐深入的探讨与研究。未来选择将这些经过实践历练的技术以及经验搬运到云上，并加以开放给外部更多的企业或者个人开发者使用，或许才是腾讯云容器的关键优势所在。 除了产品与技术，在社区领域方面，腾讯云选择在这两年努力拥抱开源的技术趋向，将内部更多、更好的架构与经验、甚至是代码开放给更多用户，并同时加大对云计算社区的投入。 “腾讯内部的容器发展经历了多个阶段，从最早以前的使用Cgroup来进行资源隔离并提升资源利用率,到后面使用docker容器并且基于yarn自研了一套调度框架，Kubernetes技术出现后腾讯内部的容器平台又逐渐切换到Kubernetes技术栈，开始全面拥抱云原生技术。随着容器技术的演进，腾讯内部在开源这里的意识也在发生变化，在开源社区的投入非常大。我们一方面积极参与到开源社区中去，一方面也会逐渐把腾讯内部一些好的实践及技术推广到社区，给更多的人和企业带来价值。”他补充道。 就目前的市场观察，亲测容器技术已成功迈入成熟期的发展阶段。其中以Kubernetes为代表，版本更新越来越快、功能越发完善且生态也越来越健全。此外我们看到很多监控、微服务以及更上层的部署，还包括很多AI、大数据框架都围绕K8S进行了很多深层次的功能演进。如今整个容器技术已经被广泛接受，很多企业级用户都在准备并实践很多容器方面的技术，各大云厂商也把容器技术作为下一个云市场技术爆发的重要机会点；在社区方面，以K8S为代表的云社区也正逐渐成长为目前业界最红火的技术社区之一。谈及在此背景下腾讯云关注的技术点，邹辉表示，当下备受关注的Severless技术应该可以让容器的发展更进一步，有效帮助企业在微服务的道路上获得更好更强的能力。此外轻量虚拟化技术的出现能够让容器表现的更加稳定与安全，在多租户混合部署的环境下真正释放容器的价值。 容器领域的种种，我们有所应对 尽管容器技术风生水起，但实际在企业落地的过程中依旧存在很多问题。值得注意的一点，目前业界很多容器技术都以开源的方式提供给用户，但在实际操作中将开源技术使用起来是一回事儿，用的好又是另外一回事儿。 “特别针对一些中小企业，不单单是K8S技术本身存在一定的门槛，更大的困难在于要将应用非常好的构建在K8S上，既能享受到K8S带来的便利，也能保证应用的可靠性，这里面需要考量的点很多，需要更多的技术保障和实践的积累。在很多客户使用容器过程中，往往因为Pod资源设置的不合理，OOM后触发内核与K8S相关组件，最终引发节点Notready，更严重的是如果集群资源预留不够，可能会产生雪崩式效应。所以如何提前发现、规避、自动恢复这些问题是用户在使用K8S过程中，所需要重点考虑的”他提出。 同样对于中大型用户来说，怎样将企业中较为传统的复杂架构牵引至以K8S为代表的容器服务上是十分值得探究的。主要还是因为在这个过程中，大企业为了达成容器化迁移，必然会为了适配原有习惯或者功能在K8S基础上进行新功能的拓展，例如磁盘隔离、网络隔离、容器IP保持不变等，需要把传统复杂的架构迁移到容器中。 所以在此基础之上，邹辉提出腾讯云在容器领域，会增加更加丰富的基础产品形态。除了目前对外提供的标准K8S服务之外，也会使用轻量虚拟化+virtual kubelet技术，对外提供K8S原生接口这样的Serverless K8S集群，做到在这个弹性集群中用户使用K8S只需要关注容器资源即可，最大程度减少对底层资源的关注。同时腾讯云容器服务，也会将腾讯内部一些好的实践，如TAPP应用管理（用于让kubernetes服务及pod管理更加精细化、发布过程更加可控）、GPU虚拟化等技术对外输出。 除此之外，当然还有很重要的一方面就是容器在使用场景方面的扩展，例如：TKE结合istio为用户提供网格服务；TKE产品与大数据、AI行业相结合，打造以K8S+虚拟化为基础，具备更丰富的AI或者大数据能力的解决方案；在游戏领域，TKE也会与腾讯游戏技术运营部门合作，将腾讯内部的游戏架构容器化所用到的典型经验和技术分享出来，推出容器化的游戏解决方案。 另外，在容器私有云和混合云这里，腾讯云也推出了TKE企业容器平台，给企业提供私有化的容器解决方案。TKE企业版采用与腾讯公有云容器服务一致的架构和管理模式，所以企业在私有化管理容器服务的同时，也能够非常便捷的打通云上的容器服务并获得一致的管理体验，实现混合云部署；在未来，我们也会进一步扩展这里的功能，实现混合云管理。 腾讯云企业级容器云平台TKE采访之余，邹辉还针对容器厂商之间的竞争给出了自己的小建议。他表明，作为容器厂商在面对这个需求越来越明显且前景越来越广阔的市场环境，如果想要把握关键入场券，最重要还是应该聚焦产品底层的稳定性打磨，这是非常关键的一点。 此外更需要去补全以容器为基础的整体形态，对此阿晶这样理解：除了提供标准的K8S服务来使用，更重要的是提供完备的上层服务来解决弹性等系列需求，让整体变得更有价值。 最后在私有云容器领域，肯定需要不断提高容器的交付效率，降低成本来实现更标准化、更流程化的用户体验。阿晶觉得这不单单是给予容器服务厂商的小贴士，更是腾讯云在容器技术领域需要努力追求的目标之一。 AI、severless以及服务网格，火技术更需保持新鲜度 谈及AI技术关联容器的表现，邹辉还详细列举了腾讯云内部的实践情况。可以肯定的一点，目前以AI为代表的新学习框架，都在逐一向K8S看齐，因为应用容器底层的部署和调度能力能够很方便助力上层框架的运转，关于这一点，在腾讯云内部也确实积累了不少经验。 当然其中的困难也是存在的，例如有些团队可能在推理任务过程中或者在虚拟过程中按以前的方式使用GPU，可能就是买一些虚拟机，但与实际的GPU卡的运行效率相比是非常低的，运行与闲置相互交替，成本浪费较大；另外不同GPU卡的性能差异，以及底层环境异构问题也是AI团队所面临的挑战。腾讯在这几块（成本、性能、异构）做了大量的技术优化，如GPU虚拟化技术、GPU拓扑识别……等等，这是其一。 “此外，我们的一些AI团队之前部署AI框架及服务时，更多还是依靠人工来部署及管理底层资源；与容器服务结合后，这些都极大程度解放了他们运维部署方面的工作，带来了很多便利性。”他说。 邹辉在采访过程中十分肯定Severless无服务器技术对容器技术的创新发展，究竟可以起到何种作用？ 无服务计算的理念提出，让容器服务的产品形态能够得到更进一步扩展，用户能够真的不用关注底层那些资源，例如节点何时该扩容、节点是否故障、节点资源利用率是多少等，让用户从一些烦琐的工作中解放出来，更多关注业务以及架构情况。 此外，腾讯云针对服务网格方面的技术创新呢？据阿晶了解，关于服务网格，目前在腾讯内部也在逐渐推广，居高不下的同时也碰到的了两个最大的问题。首当其冲的就是性能问题。因为目前技术会对所有的容量做一套额外劫持、解包、分析、再打包这样的过程，所以在性能的优化上腾讯云其实做了挺多研究，比方说istio 数据转发层面与管控层面优化；另外在腾讯内部还有大量的istio扩展协议使用经验，怎么样把这些自定义协议适配到istio，也做了很多工作。 截止阿晶发稿之前，腾讯云已经在云原生技术大会 KubeCon + CloudNativeCon + Open Source Summit（原 LC3）上重磅发布四大云原生技术产品，包括企业级容器服务平台TKE、容器服务网格TKE Mesh、Serverless 2.0、一站式DevOps平台。作为云计算领域的引领者，阿晶觉得未来的腾讯云在容器、微服务以及无服务器领域的诸多实践，或将真正开启云原生时代。（本文转载自infoQ）

DockerDocker是一个开源的应用容器引擎，可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。 docker安装（CentOS）查看CentOS系统内核版本，需要高于3.10如果内核版本过低，可以参考此链接进行升级。 安装docker 移除旧版本$ sudo yum remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-selinux \ docker-engine-selinux \ docker-engine安装必要的系统工具$ sudo yum install -y yum-utils device-mapper-persistent-data lvm2添加软件源信息$ sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo更新yum缓存$ sudo yum makecache fast安装Docker-ce$ sudo yum -y install docker-ce启动Docker后台服务$ sudo systemctl start docker运行hello-word由于本地没有hello-world镜像，所以从仓库中下载该镜像并在容器中运行。- 镜像加速在`/etc/docker/daemon.json`文件(如果没有，自行创建)中添加：```json{ "registry-mirrors": ["http://hub-mirror.c.163.com"]}```docker基本操作查看镜像$ docker images查看容器$ docker ps，如果想要查看已经关闭的镜像可以加上-a参数删除镜像$ docker rmi <image-name/id>，强行删除加上-f参数删除容器$ docker rm <container-name/id>，强行删除加上-f参数构建镜像$ docker build -t <image-name> .，.表示当前路径，可以使用具体路径代替运行容器$ docker run -p <本机端口>:<docker容器内部端口> --name <container-name> -d <image-name>；-d参数表示在后台运行容器，并返回容器ID交互模式运行容器$ docker exec -it <container-name> /bin/bash；-i以交互模式运行容器、-t为容器重新分配一个伪输入终端标记本地镜像，将其归入某一仓库$ docker tag <image-name[:tag]> <registryhost/username/image-name[:tag]>查看docker日志$ docker logs <container-name>docker实战（构建MySQL数据库镜像）首先，准备好数据库所需的数据（sql文件）-- init.sql --drop database if exists starwars;create DATABASE starwars;use starwars;create table if not exists people ( _id INT NOT NULL AUTO_INCREMENT, ID char(100), Name char(100), Heigth char(100), Mass char(100), Hair_color char(100), Skin_color char(100), Eye_color char(100), Birth_year char(100), Gender char(100), Homeworld char(100), Films char(200), Species char(200), Vehicles char(200), Starships char(200), primary key(_id)); …………之后，书写Dockerfile文件以mysql5.7为基础镜像构建我们所需要的镜像，首先设置MYSQL_ALLOW_EMPTY_PASSWORD便于我们对数据库进行数据导入的操作，然后将文件(相对/绝对路径)拷贝到容器中，最后执行脚本写入数据。 ...

容器化部署越来越多的用于企业的生产环境中，如何构建可靠、安全、最小化的 Docker 镜像也就越来越重要。本文将针对该问题，通过原理加实践的方式，从头到脚帮你撸一遍。文章比较长，主要通过五个部分对容器镜像进行讲解。分别是： 镜像的构建讲解了镜像的手动构建与自动构建过程。镜像的存储与UnionFS联合文件系统讲解了镜像的分层结构以及UnionFS联合文件系统，以及镜像层在UnionFS上的实现。最小化镜像构建讲解了为什么需要最小化镜像，同时如何进行最小化构建。容器镜像的加固容器镜像加固的具体方式。容器镜像的审查高质量的项目中容器镜像也需要向代码一样进行审查。读者可以根据各自情况选择性阅读。 原文发自我的个人网站： GitDiG.com，参考链接构建安全可靠、最小化的 Docker 镜像.1. 构建镜像1.1 手动构建手动构建 Docker 镜像的流程图，如下： 现在依次按照流程采用命令行的方式手动构建一个简单的Docker 镜像。 1.1.1 创建容器并增加文件取busybox作为本次试验的基础镜像，因为它足够小，大小才 1.21MB。 $: docker run -it busybox:latest sh/ # touch /newfile/ # exit通过以上的操作，我们完成了流程图的前三步。创建了一个新容器，并在该容器上创建了一个新问题。只是，我们退出容器后，容器也不见了。当然容器不见了，并不表示容器不存在了，Docker 已经自动保存了该容器。如果在创建时，未显示设置容器名称，可以通过以下方式查找该消失的容器。 # 列出最近创建的容器$: docker container ls -n 1CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESc028c091f964 busybox:latest "sh" 13 minutes ago Exited (0) 27 seconds ago upbeat_cohen# 查询容器的详情$: docker container inspect c028c091f964...1.1.2 提交变更生成镜像手动构建镜像，很简单。先找到发生变更的容器对象，对其变更进行提交。提交完成后，镜像也就生成了。不过此时的镜像只有一个自动生成的序列号唯一标识它。为了方便镜像的检索，需要对镜像进行命名以及标签化处理。 命令行操作如下: # 提交变更, 构建镜像完成$: docker commit -a JayL -m "add newfile" c028c091f964sha256:01603f50694eb62e965e85cae2e2327240e4a68861bd0e98a4fb4ee27b403e6d# 对镜像进行命名, 原镜像ID取前几位就可以了$: docker image tag 01603f50694eb62e9 busybox:manual# 验证新镜像$: docker run busybox:manual ls -al newfile-rw-r--r-- 1 root root 0 Jun 15 05:25 newfile通过以上两步过程就完成了Docker 镜像手动创建。非常简单是不是。但是也非常麻烦，必须先创建新容器在提交变更，生成镜像。整个过程完全可以通过脚本化处理，这也是下节要说的，自动化构建Docker 镜像。 ...

目标需求：密码登录+容器数据共享，主从复制 1.配置启动添加配置文件夹，组织容器命令。 a.官方“未提供”相关信息从测试容器中匹配搜索得到 mongod.conf.orig，设置可以启动，网上查找配置项反不能启动，原因是配置是yaml格式！好像听说过。百度查询得到：官方配置说明，网站卡得出奇。 b.启动配置[]:~/tmp/dk/mongodb# docker run --rm --name mg1 -d mongo#默认数据目录root@199665dc0d08:/# ls /data/db -lhtotal 268K-rw------- 1 mongodb mongodb 45 Jun 29 23:39 WiredTiger-rw------- 1 mongodb mongodb 21 Jun 29 23:39 WiredTiger.lock... ...# mongod.conf 删除了一些注释选项# Where and how to store data.storage: #数据库数据存放目录 dbPath: /data/db #启用日志文件，默认启用 journal: enabled: true# where to write logging data.systemLog: destination: file logAppend: true #数据库日志存放目录? path: /var/log/mongodb/mongod.log #静默模式，过滤掉一些无用的日志信息 quiet: true# network interfacesnet: port: 27017 bindIp: 192.168.0.4security: 登录认证 authorization: "enable"测试过程中主要错误有： ...

sdn (software defines network)看了些相关的资料，这里记录一下自己对sdn的理解，能力有限，如有错误欢迎指正。 sdn软件定义网络，目的是想要利用软件来模拟网络设备，如交换机，路由器之类的。 为什么需要这么做? 一个主要原因是云计算的高速发展，给传统的数据中心带来了更加灵活和复杂的组网需求。 传统网络设备完成数据中心服务器的组网，在此之上，通过sdn来完成虚机和容器之间的连通 ovs (openvSwitch)官方的说法：Open vSwitch是一款高质量的多层虚拟交换机，以开源Apache 2许可证授权，非常适合在虚拟机环境中充当2层交换机。支持多种基于Linux的虚拟化技术，包括Xen / XenServer、KVM和VirtualBox。支持Open Flow协议，所以可以很方便的通过编程实现大规模网络的自动化，被大量运用于SDN网络中。 架构和原理之类的文章很多，这里就不在一一阐述，本文以实践为主。 安装# 安装dockeryum install -y docker-1.13.1# 预安装yum -y install wget openssl-devel gcc make python-devel openssl-devel kernel-devel graphviz kernel-debug-devel autoconf automake rpm-build redhat-rpm-config libtool python-twisted-core python-zope-interface PyQt4 desktop-file-utils libcap-ng-devel groff checkpolicy selinux-policy-devel# 安装open vswitch:yum install -y openvswitch-2.8.2-1.el7.x86_64 # 此版本包含ovs-dockersystemctl start openvswitch.servicesystemctl is-active openvswitchsystemctl enable openvswitchovs单机连通性创建容器, 设置net=none可以防止docker0默认网桥影响连通性测试 docker run -itd --name con6 --net=none ubuntu:14.04 /bin/bashdocker run -itd --name con7 --net=none ubuntu:14.04 /bin/bashdocker run -itd --name con8 --net=none ubuntu:14.04 /bin/bash创建网桥 ...

前面mysql容器重建后需要重新运行 change master to 命令绑定关联，8.0需要命令行下生效。redis首先想到用官方的，没想到进去各个基本shell命令无法使用，所以先弃了。这次由于官方没有提供基本的配置文件，解压redis-5.0.5.tar.gz复制 主配置redis.conf、哨兵配置sentinel.conf 到当前目录，如：/root/tmp/dk/redis。 1、制作配置文件搜索修改 # master服务器 redis.conf：- # requirepass foobared+ requirepass 123456- dir ./ # 持久化数据目录+ dir /data- appendonly no # 开启aof+ appendonly yes- bind 127.0.0.1 # 允许外网ip访问+ bind 0.0.0.0// 从服务器：主+额外 redis.conf：// remote_host：自己的内网、外网地址- # replicaof <masterip> <masterport> + replicaof remote_host 6379- # masterauth <master-password>+ masterauth 1234562、启动容器# 创建容器运行[]:~/tmp/dk/redis# docker run --name rm \ -p 6379:6379 --restart=always -v \ /root/tmp/dk/redis/data:/data -v \ /root/tmp/dk/redis/redis.conf:/etc/redis/redis.conf \ -d cffycls/redis5:1.6 redis-server /etc/redis/redis.conf[]:~/tmp/dk/redis# docker run --name rs \ -p 6381:6379 --restart=always -v \ /root/tmp/dk/redis_slave/data:/data -v \ /root/tmp/dk/redis_slave/redis.conf:/etc/redis/redis.conf \ -d cffycls/redis5:1.6 redis-server /etc/redis/redis.conf镜像是redis5.0.5编译的，直接启动后就是主从同步的，不需要向mysql一样进行配置（这里起始数据不一致时：修改到当前最终配置，重启即同步完好）。直接同步成功，在master、slave查看关系 info replication均有对方信息。 ...

公司为了省钱，除了一台服务器能够上网之外，其余的都是内网服务器，我把jenkins装在内网服务器下，用Dockder来搭建的，所以就出现题目的问题。怎么设置Docker jenkins容器下的gradle http代理，让gradle能下外网的依赖包。一、宿主机创建gradle.properties文件vim ./gradle.properties文件配置http代理信息 systemProp.http.proxyPort=8888systemProp.http.proxyHost=172.111.111.111systemProp.https.proxyPort=8888systemProp.https.proxyHost=172.111.111.111二、将配置文件copy到容器#暂且放到容器的/home/目录下吧docker cp ./gradle.properties jenkins:/home三、进入Jenkins容器#通过docker命令进入容器docker exec -it jenkins bash#进入容器后创建在用户目录创建「.gradle」目录mkdir ~/.gralde#把放在/home/目录的配置文件移动到~/.gralde目录mv /home/gradle.properties ~/.gradle四、完成可以去jenkins网页上试试重新build

5分钟快速部署DataDraw数字绘经常有小伙伴问，有没有一款好用又免费的画图软件，画画流程图、UML、思维导图？今天就介绍一款开源的在线画图软件，可以满足多方的需求。 DataDraw数字绘是一个在线线框图、流程图、网络图、组织结构图、UML、BPMN绘制网站，绘制完成之后可以导出成图片、SVG、XML，也可以保存在云端并能分享给其他用户。 为了方便部署和解决环境兼容性等问题，采用docker来部署安装DataDraw数字绘。 首先安装Docker容器管理面板URLOS，请参考官方文档：https://www.URLOS.com/center-...。登录URLOS：http://ip:9968（其中的IP是你的服务器的IP，登录的默认用户名和密码均为urlos）在应用市场中搜索“datadraw”并安装，如下图： 安装流程如下：1. 填写服务名称、端口号、选择智能部署 2. 填写域名：www.aaa.com（这里填写自己的域名） 3. 设置数据库选择自动添加并部署数据库，填写数据库密码；数据库名和数据库用户名跟前面的服务名称一致，这里已经自动设置好； 记下数据库密码、数据库名和数据库用户名，下面要用到； 然后点击“提交”按钮，等待部署完成； 4. 导入数据文件部署完成后，手动导入mysql.sql数据文件：https://raw.githubusercontent... 先开放数据库服务的对外访问端口，选择“修改并部署” 服务端口填写 3306，部署方式选择“智能部署”，点击提交重新部署数据库 等待部署完成后，用mysql的客户端连接上数据库，导入已下载的mysql.sql。如果想禁止外网访问数据库，服务端口不填，重新部署就行了） 5. 访问网站访问刚才填写的域名：http://domain/Login（domain是你的域名）账号：admin@datadraw.net 密码：admin

5分钟快速部署PESCMS TEAM 团队任务管理系统开发版所在的公司也经历过小团队的发展，为了高效率，通常都是面对面交流，很多时候事情谈论过后不久就已经淡忘了。而且工作任务不能全局观察，成员之间基本上都要主动去询问，效率反而低下。所以今天就介绍一款开源的中小团队的任务管理系统。 PESCMS TEAM是一款简便的任务管理系统。不主张走复杂的流程管理，记录工作中的任务，减少口头传达的遗忘率，提升工作的紧凑性。所以如果你需要的是一款非常严密的流程任务管理软件，PESCMS TEAM并不合适您。 为了方便部署和解决环境兼容性等问题，采用docker来部署安装PESCMS TEAM 团队任务管理系统开发版。 首先安装Docker容器管理面板URLOS，请参考官方文档：https://www.URLOS.com/center-...。登录URLOS：http://ip:9968（其中的IP是你的服务器的IP，登录的默认用户名和密码均为urlos）在应用市场中搜索“pescms-team-dev”并安装，如下图： 安装流程如下：1. 填写服务名称、端口号、选择智能部署 2. 填写域名：www.aaa.com（这里填写自己的域名） 3. 设置数据库选择自动添加并部署数据库，填写数据库密码；数据库名和数据库用户名跟前面的服务名称一致，这里已经自动设置好； 记下数据库密码、数据库名和数据库用户名，下面要用到； 然后点击“提交”按钮，等待部署完成； 4. 团队任务管理系统 1）数据库配置：数据库地址 填写服务名称就行，就是刚才选择自动添加并部署数据库的服务名称： 服务器端口号 3306数据库用户名和数据库名 填写刚才记下的数据库名和数据库用户名数据库密码 刚才填写的数据库密码 2）创建管理员账号 3）安装完成 4）登录 5）成功登录

在各种音视频应用充斥着市场的时候，毫无疑问，流媒体领域将会非常适合区块链技术进行场景落地。在上一篇文章中，我们主要讨论了 PPIO 的 PCDN 架构，接下来将介绍 PPIO 的中 P2SP 的下载逻辑和 IaaS 层的流量计数。 下载逻辑 上图为 PPIO 的 CDN 和 P2SP 的传输架构图。这里将会重点讲解 PPIO 中 P2SP 的下载逻辑，它主要分三个部分，Buffer 管理，下载状态机，和下载算法。接下来会对这三部分一一解释。 Buffer 管理 Buffer 管理，即理解为本地设备管理着资源情况，从而决定需要下载的 Piece 的优先级。Buffer 管理也是和实际应用场景是相关的，对于流媒体来说，存在一个视频播放位置，播放位置附近的内容就是紧急内容，该内容则会被优先下载。 #1 普通文件下载的 Buffer 管理逻辑 文件下载的 Buffer 管理相对简单，因为没有具体的播放位置，即内容在紧急程度上没有区别。下载算法将采用稀缺优先的逻辑，优先下载网络中稀缺的 Piece。Piece 越稀缺，其下载的优先级也就越高。如下图： 在示意图中，我们假设所有 Peer 都是一样的，而因为 CDN 节点的存在，实际情况则会复杂得多。CDN 可以被认为比较优质的，但是它不适合请求分散的碎片数据，更适合下载一段连续的数据。之所以将稀缺性作为普通文件的 Buffer 管理的指标，是为了增加 P2P 网络的资源健康度，并且让数据尽快在 P2P 网络中传播。 #2 流媒体的 Buffer 管理逻辑 和普通文件下载不同的是，流媒体下载存在具体播放位置，为了保证视频的观看体验，越接近播放位置的数据将会优先进行下载。 设计 PPIO 的时候，我们根据视频播放位置，在流媒体下载的过程中，将其分为多个区间，越靠近播放位置的区间，下载优先级越高。 已过区间：视频播放位置之前的数据，无需进行下载。 紧急区间：需要立即播放的数据，在此区间的数据将采用极端下载策略，旨在以最快的速度获取数据。Piece 越靠近播放位置，下载优先级越高。这种策略更加依赖于 CDN 和超级节点，尽管有重复下载的风险，该区间将同时进行 P2P 下载，即在第一时间从多个 Peer 下载数据。 ...

Docker Hub中有很多好用的Docker镜像，但镜像到底如何工作、能做什么、怎么做值得我们研究，如下所示为MySQL官方镜像的docker-entrypoint.sh脚本分析： #!/bin/bashset -eo pipefailshopt -s nullglob################################################################# 若启动命令时附加了参数，则在参数前添加mysqld，如$0 -f test，则经过此代码处理后，# $@参数变mysqld -f test。其中${1:0:1}从$1参数第0个位置取1字符，如$1为-f，则# 取'-'字符，若条件为真，通过set命令重置$@参数，添加mysqld前缀，即经过处理后$1变# 为mysqld。################################################################# if command starts with an option, prepend mysqldif [ "${1:0:1}" = '-' ]; then set -- mysqld "$@"fi# 解析参数，是否是获取帮助信息参数，并设置wantHelp值###################################################### skip setup if they want an option that stops mysqldwantHelp=for arg; do case "$arg" in -'?'|--help|--print-defaults|-V|--version) wantHelp=1 break ;; esacdone############################## 从文件中读取变量值############################## usage: file_env VAR [DEFAULT]# ie: file_env 'XYZ_DB_PASSWORD' 'example'# (will allow for "$XYZ_DB_PASSWORD_FILE" to fill in the value of# "$XYZ_DB_PASSWORD" from a file, especially for Docker's secrets feature)file_env() { local var="$1" local fileVar="${var}_FILE" local def="${2:-}" if [ "${!var:-}" ] && [ "${!fileVar:-}" ]; then echo >&2 "error: both $var and $fileVar are set (but are exclusive)" exit 1 fi local val="$def" if [ "${!var:-}" ]; then val="${!var}" elif [ "${!fileVar:-}" ]; then val="$(< "${!fileVar}")" fi export "$var"="$val" unset "$fileVar"}############################################################################ 运行mysqld --help --verbose --help 2>&1 >/dev/null命令，# 此命令会检查配置文件，若配置文件没问题，则成功，不成功则输出错误信息，及if中添# 加！取不成功。###########################################################################_check_config() { toRun=( "$@" --verbose --help ) if ! errors="$("${toRun[@]}" 2>&1 >/dev/null)"; then cat >&2 <<-EOM ERROR: mysqld failed while attempting to check config command was: "${toRun[*]}" $errors EOM exit 1 fi}# 1. $1参数为mysqld 以及 wanthelp 参数为空 以及root用户，执行此代码；# 2. _check_config检查配置文件是否正确# 3. 获取DATADIR目录，执行mysqld --verbose --help --log-bin-index=/tmp/tmp.4SyApJWeIo| \# awk '$1 == "'"datadir"'" { print $2; exit }'# 4. 创建并修改目录权限# 5. 执行exec gosu mysql docker-entrypoint.sh "$@"，即重新以mysql用户再次调用脚# 本# allow the container to be started with `--user`if [ "$1" = 'mysqld' -a -z "$wantHelp" -a "$(id -u)" = '0' ]; then _check_config "$@" DATADIR="$(_get_config 'datadir' "$@")" mkdir -p "$DATADIR" chown -R mysql:mysql "$DATADIR" exec gosu mysql "$BASH_SOURCE" "$@"fi# 1. $1参数为mysqld 以及 wanthelp 参数为空，执行此代码，及exec gosu会执行此代码；if [ "$1" = 'mysqld' -a -z "$wantHelp" ]; then# 2. 仍然检查配置文件以及获取datadir目录 # still need to check config, container may have started with --user _check_config "$@" # Get config DATADIR="$(_get_config 'datadir' "$@")"# 3. 若mysql数据库未创建，则执行本段逻辑 if [ ! -d "$DATADIR/mysql" ]; then# 4. 检查是否设置变量，如root密码、允许root密码为空亦或者随机密码 file_env 'MYSQL_ROOT_PASSWORD' if [ -z "$MYSQL_ROOT_PASSWORD" -a -z "$MYSQL_ALLOW_EMPTY_PASSWORD" -a -z "$MYSQL_RANDOM_ROOT_PASSWORD" ]; then echo >&2 'error: database is uninitialized and password option is not specified ' echo >&2 ' You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD' exit 1 fi# 5. 创建目录 mkdir -p "$DATADIR"# 6. 执行mysqld命令初始化数据库 echo 'Initializing database' "$@" --initialize-insecure echo 'Database initialized'# 7. command -v mysql_ssl_rsa_setup检查命令是否可执行，以及是否存在# server-key.pem文件，若不存在，则生成证书 if command -v mysql_ssl_rsa_setup > /dev/null && [ ! -e "$DATADIR/server-key.pem" ]; then # https://github.com/mysql/mysql-server/blob/23032807537d8dd8ee4ec1c4d40f0633cd4e12f9/packaging/deb-in/extra/mysql-systemd-start#L81-L84 echo 'Initializing certificates' mysql_ssl_rsa_setup --datadir="$DATADIR" echo 'Certificates initialized' fi# 8. 获取socket值并启动mysql SOCKET="$(_get_config 'socket' "$@")" "$@" --skip-networking --socket="${SOCKET}" & pid="$!"# 9. 设置mysql变量（列表形式），而后可以${mysql[@]}调用 mysql=( mysql --protocol=socket -uroot -hlocalhost --socket="${SOCKET}" )# 10. 运行30次，验证mysql是否已经启动完毕 for i in {30..0}; do if echo 'SELECT 1' | "${mysql[@]}" &> /dev/null; then break fi echo 'MySQL init process in progress...' sleep 1 done# 11. 若i为0值，则表明mysql启动失败 if [ "$i" = 0 ]; then echo >&2 'MySQL init process failed.' exit 1 fi# 11. 解决时区bug if [ -z "$MYSQL_INITDB_SKIP_TZINFO" ]; then # sed is for https://bugs.mysql.com/bug.php?id=20545 mysql_tzinfo_to_sql /usr/share/zoneinfo | \ sed 's/Local time zone must be set--see zic manual page/FCTY/' | "${mysql[@]}" mysql fi# 12. 生成root随机密码 if [ ! -z "$MYSQL_RANDOM_ROOT_PASSWORD" ]; then export MYSQL_ROOT_PASSWORD="$(pwgen -1 32)" echo "GENERATED ROOT PASSWORD: $MYSQL_ROOT_PASSWORD" fi# 13. 若MYSQL_ROOT_HOST不为空亦或者不为localhost，则创建root用户 rootCreate= # default root to listen for connections from anywhere file_env 'MYSQL_ROOT_HOST' '%' if [ ! -z "$MYSQL_ROOT_HOST" -a "$MYSQL_ROOT_HOST" != 'localhost' ]; then # no, we don't care if read finds a terminating character in this heredoc # https://unix.stackexchange.com/questions/265149/why-is-set-o-errexit-breaking-this-read-heredoc-expression/265151#265151 read -r -d '' rootCreate <<-EOSQL || true CREATE USER 'root'@'${MYSQL_ROOT_HOST}' IDENTIFIED BY '${MYSQL_ROOT_PASSWORD}' ; GRANT ALL ON *.* TO 'root'@'${MYSQL_ROOT_HOST}' WITH GRANT OPTION ; EOSQL fi# 14. 为'root'@'localhost'重置root密码# 使用$rootCreate创建root "${mysql[@]}" <<-EOSQL -- What's done in this file shouldn't be replicated -- or products like mysql-fabric won't work SET @@SESSION.SQL_LOG_BIN=0; SET PASSWORD FOR 'root'@'localhost'=PASSWORD('${MYSQL_ROOT_PASSWORD}') ; GRANT ALL ON *.* TO 'root'@'localhost' WITH GRANT OPTION ; ${rootCreate} DROP DATABASE IF EXISTS test ; FLUSH PRIVILEGES ; EOSQL# 15. 已设置root密码，故mysql需加上root密码 if [ ! -z "$MYSQL_ROOT_PASSWORD" ]; then mysql+=( -p"${MYSQL_ROOT_PASSWORD}" ) fi# 16. 若配置了MYSQL_DATABASE变量，则创建 file_env 'MYSQL_DATABASE' if [ "$MYSQL_DATABASE" ]; then echo "CREATE DATABASE IF NOT EXISTS \`$MYSQL_DATABASE\` ;" | "${mysql[@]}" mysql+=( "$MYSQL_DATABASE" ) fi# 17. 在数据库内创建用户 file_env 'MYSQL_USER' file_env 'MYSQL_PASSWORD' if [ "$MYSQL_USER" -a "$MYSQL_PASSWORD" ]; then echo "CREATE USER '$MYSQL_USER'@'%' IDENTIFIED BY '$MYSQL_PASSWORD' ;" | "${mysql[@]}" if [ "$MYSQL_DATABASE" ]; then echo "GRANT ALL ON \`$MYSQL_DATABASE\`.* TO '$MYSQL_USER'@'%' ;" | "${mysql[@]}" fi echo 'FLUSH PRIVILEGES ;' | "${mysql[@]}" fi# 18. 执行/docker-entrypoint-initdb.d目录下面的脚本，包含shell、sql echo for f in /docker-entrypoint-initdb.d/*; do case "$f" in *.sh) echo "$0: running $f"; . "$f" ;; *.sql) echo "$0: running $f"; "${mysql[@]}" < "$f"; echo ;; *.sql.gz) echo "$0: running $f"; gunzip -c "$f" | "${mysql[@]}"; echo ;; *) echo "$0: ignoring $f" ;; esac echo done# 19. 设置root密码是否过期 if [ ! -z "$MYSQL_ONETIME_PASSWORD" ]; then "${mysql[@]}" <<-EOSQL ALTER USER 'root'@'%' PASSWORD EXPIRE; EOSQL fi# 20. kill -s TERM "$pid" 杀掉mysql进程，执行成功则返回0，而！kill取反，即kill成# 功后才执行后面的!wait命令 if ! kill -s TERM "$pid" || ! wait "$pid"; then echo >&2 'MySQL init process failed.' exit 1 fi# 21. 初始化成功后，再次启动 echo echo 'MySQL init process done. Ready for start up.' echo fifi# 22. 正式启动数据库exec "$@"

默认运行docker pull获取镜像时，其仓库地址为docker.io，执行docker info有： % docker info...Registry: https://index.docker.io/v1/Experimental: falseInsecure Registries: 127.0.0.0/8Live Restore Enabled: falseRegistries: docker.io (secure)完整镜像名称格式为<hostname>/<namespace|project>/<image>:<tag>。 镜像提供了完整主机名称，则docker从此镜像库下载镜像，如从quay.io镜像库的coreos项目下载etcd:latest镜像：% docker pull quay.io/coreos/etcd若省略了hostname，则默认从docker.io下载镜像，而若省略project，其会补充project为library：% docker pull library/debianUsing default tag: latestTrying to pull repository docker.io/library/debian% docker pull debian # 未明确指定project，从docker.io下载时默认补充library/<image>Using default tag: latestTrying to pull repository docker.io/library/debian 若没有提供hostname，则下载镜像顺序从Registries列表获取，但默认只有docker.io，可调整顺序，如： % vi /etc/sysconfig/dockerADD_REGISTRY='--add-registry okd-lr.zyl.io:5000 --add-registry quay.io'INSECURE_REGISTRY='--insecure-registry okd-lr.zyl.io:5000' # 镜像库若是非TLS，则必须添加此参数此时docker info显示如下： Registry: https://okd-lr.zyl.io:5000/v1/ # 这里没啥用Experimental: falseInsecure Registries: okd-lr.zyl.io:5000 # 非安全镜像库 127.0.0.0/8Live Restore Enabled: false # 由ADD_REGISTRY添加了2个镜像库Registries: okd-lr.zyl.io:5000 (insecure), quay.io (secure), docker.io (secure)若此时下载镜像，则顺序遍历Registries列出的镜像库： ...

目前已完成：php7及扩展、redis5的Dockerfile测试版编写，稍许完善后同步上传到github，（记下这里memcached还没有剥离安装）。今天数据库，编程的一个重要原则是不要重复造轮子，php因为需要很多自定义插件、所以单独编译镜像，其实其他包括redis都应该使用官方的，直接pull就行。 一、mysql部分参考官方镜像，根据官方镜像，准备的mysql、mysql_slave文件树，添加了个数据文件夹。 []:~/tmp/dk/mysql/mysql_slave# tree ././├── config│   ├── conf.d│   │   └── docker.cnf│   └── my.cnf└── data1、创建mysql镜像 []:~/tmp/dk# docker pull mysql:8.0[]:~/tmp/dk# docker run --name mq -p 3306:3306 -v /root/tmp/dk/mysql/data:/var/lib/mysql \ -v /root/tmp/dk/mysql/config:/etc/mysql \ -v /root/tmp/dk/mysql/mysql-files:/var/lib/mysql-files -e MYSQL_ROOT_PASSWORD=123456 -d mysql:8.0[]:~/tmp/dk# docker run --name ms -p 3308:3306 -v /root/tmp/dk/mysql_slave/data:/var/lib/mysql \ -v /root/tmp/dk/mysql_slave/config:/etc/mysql \ -v /root/tmp/dk/mysql_slave/mysql-files:/var/lib/mysql-files -e MYSQL_ROOT_PASSWORD=123456 -d mysql:8.0退出后台运行的容器，按 Ctrl+D 进行退出容器，请牢记！run后运行的容器进入： a.旧式进入 []:~/tmp/dk# docker attach mqb.命令进入 []:~/tmp/dk# docker exec -it mq /bin/bash(或/bin/sh)参考《Docker容器进入的4种方式》a.普通进入：有一个问题。当多个窗口同时使用该命令进入该容器时，所有的窗口都会同步显示。如果有一个窗口阻塞了，那么其他窗口也无法再进行操作。所以docker attach命令不太适合于生产环境，平时自己开发应用时可以使用该命令。b.推荐 ...

关于 Lin Cms 全家桶部署及使用说明参考文档：2019 年 最简单最通俗的 vagrant 安装使用说明，附带示例Vagrantfile参考文档：2019年最新最快最简洁最详细的docker 和 docker-compose 安装使用说明 1：安装虚拟环境 vagrant + virtualbox1.1 安装 virtualbox【官网下载】 【VirtualBox 6.0.8 platform packages 下载】 Windows hostsOS X hostsLinux distributionsSolaris hosts安装说明： 下一步下一步，选择下安装目录就行 1.2 安装 vagrant【官网下载】 windows 64位安装说明： 下一步下一步，选择下安装目录就行 2：部署虚拟环境 vagrant + virtualbox2.1: 新建项目目录mkdir lincms2.1: 下载 全家桶源码 到 lincms 项目目录请加QQ群：1020151684， 备注：我想体验lincms全家桶 然后获取全家桶源码 2.3: 初始化Vagrantfilevagrant init2.4 修改文件内容# -*- mode: ruby -*-# vi: set ft=ruby :Vagrant.require_version ">= 1.6.0"boxes = [ { :name => "lincms", :eth1 => "10.10.1.10", :mem => "1024", :cpu => "1" }]Vagrant.configure(2) do |config| config.vm.box = "ubuntu/bionic" boxes.each do |opts| config.vm.define opts[:name] do |config| config.vm.hostname = opts[:name] config.vm.provider "vmware_fusion" do |v| v.vmx["memsize"] = opts[:mem] v.vmx["numvcpus"] = opts[:cpu] end config.vm.provider "virtualbox" do |v| v.customize ["modifyvm", :id, "--memory", opts[:mem]] v.customize ["modifyvm", :id, "--cpus", opts[:cpu]] end config.vm.network :private_network, ip: opts[:eth1] end end config.vm.synced_folder "./lincms", "/home/vagrant/lincms" config.vm.provision "shell", privileged: true, path: "./setup.sh"end2.5 新增 setup.sh文件# Timezonesudo /bin/cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ && echo 'Asia/Shanghai' > /etc/timezone# 设置国内源sudo mv /etc/apt/sources.list /etc/apt/sources.list.back && \ echo '# 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释 \n \ deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse \n \ deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse \n \ deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse \n \ deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse \n \ deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse \n \ deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse \n \ deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse \n \ deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse \n \ deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse \n \ deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse' >> /etc/apt/sources.list # Libssudo apt-get update && sudo apt-get install -y wget curl git vim gcc glibc-static telnet bridge-utils# install dockersudo curl -fsSL https://get.docker.com | sudo bash -s docker --mirror Aliyunsudo groupadd dockersudo gpasswd -a vagrant dockersudo systemctl start dockerrm -rf get-docker.sh# 配置镜像加速器sudo mkdir -p /etc/dockersudo tee /etc/docker/daemon.json <<-'EOF'{ "registry-mirrors": ["https://dt77flbr.mirror.aliyuncs.com"]}EOFsudo systemctl enable dockersudo systemctl daemon-reloadsudo systemctl restart docker# #下载docker-compose# sudo curl -L "https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose# #给docker-compose执行权限# sudo chmod +x /usr/local/bin/docker-compose # #测试安装是否成功，成功的话打印出docker-compose的版本信息# sudo docker-compose --version# 使用pip安装docker-compose sudo apt install python-pip -ysudo pip install docker-compose# 打印IP地址信息ip a# 进入项目目录cd lincms# 创建/启动项目sudo docker-compose build && sudo docker-compose up -d3： 部署后续资料3.1： API接口访问地址：10.10.1.10:9000curl 10.10.1.10:9000如果能看到 TP5.1欢迎页面，就证明部署成功了 ...

一、测试PHP1、在官方的基础上简化： # php7.3.5; Feb 7, 2019 link: https://github.com/docker-library/php/blob/master/7.3/alpine3.9/fpm/Dockerfile# Base images 基础镜像+阿里源FROM alpine:3.9#MAINTAINER 维护者信息MAINTAINER cffycls@foxmail.com# dependencies required for running "phpize"ENV PHP_VERSION 7.3.6ENV PHP_URL https://secure.php.net/get/php-$PHP_VERSION.tar.xz/from/this/mirrorENV PHPIZE_DEPS \ autoconf \ dpkg-dev dpkg \ file \ g++ \ gcc \ libc-dev \ make \ pkgconf \ re2cENV PHPIZE_DEVS \ argon2-dev \ coreutils \ curl-dev \ libedit-dev \ libsodium-dev \ libxml2-dev \ openssl-dev \ sqlite-dev \ libjpeg-turbo-dev \ libpng-dev \ gd-dev \ gettext-dev \ freetype-dev \ libxpm-dev \ libevent-devRUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories \ && apk update \ && addgroup -g 82 -S www-data \ && adduser -u 82 -D -S -G www-data www-data \ && mkdir -p "/usr/local/etc/php/conf.d" && mkdir -p "/var/www/html" \ && chown www-data:www-data /var/www/html && chmod 777 /var/www/html \ && apk add --no-cache\ curl \ tar \ xz \ openssl \ wget COPY php.tar.xz php.tar.xzRUN set -eux; \ apk add $PHPIZE_DEPS $PHPIZE_DEVS \ # && wget -O php.tar.xz "$PHP_URL" \ && tar -Jxf php.tar.xz && cd php-$PHP_VERSION && ./configure \ --prefix="/usr/local/php" \ --with-config-file-path="/usr/local/php/etc" \ --with-config-file-scan-dir="/usr/local/php/etc/conf.d" \ \ --enable-option-checking=fatal \ --with-mhash \ \ --enable-ftp \ --enable-exif \ --enable-mbregex \ --enable-mbstring \ --enable-mysqlnd \ --enable-sysvmsg \ --enable-opcache \ --enable-pcntl \ --enable-sockets \ --enable-sysvsem \ --enable-xml \ --with-curl \ --with-libedit \ --with-openssl \ --with-zlib \ --with-pcre-regex \ --with-pear \ --with-libxml-dir=/usr \ --with-jpeg-dir \ --with-freetype-dir \ --with-xpm-dir \ --with-png-dir \ --with-gettext \ --with-mhash \ --with-iconv \ --disable-fileinfo \ \ --enable-fpm --with-fpm-user=www-data --with-fpm-group=www-data --disable-cgi \ && make -j "$(nproc)" \ && find -type f -name '*.a' -delete \ && make install \# && make clean \ && rm -rf /tmp/pear ~/.pearrc \ && cd ../ && rm -rf php-$PHP_VERSION.tar.xz php-$PHP_VERSION2、添加扩展：这里目标 swoole-inotify-redis-uuid-memcached，这里是在运行上面镜像的容器测试得到结果，部分需要自行下载的插件或交互式安装的，使用单独下载源码编译的方式。/usr/local/php/etc/文件夹需要准备一个共享，这里取上面官方的配置稍加修改，并共享出来供后续安装使用： ...

当编写好docker-compose.yml，运行docker-compose up命令时，可能会报如下错误 docker-compose: line 1: {error:Not Found}: command not found这种情况是因为尚未安装docker compose对缘故。可以根据下面命令进行手动安装。 sudo curl -L "https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-composesudo chmod +x /usr/local/bin/docker-compose具体细节可以参考官网文档。

1. 安装1.1 确保删除旧版本DOCKER$ sudo yum remove docker \ docker-common \ docker-selinux \ docker-engine1.2 安装所需要的包安装所需要的依赖包，包括 yum-utils , device-mapper-persistent-data 和 lvm2. $ sudo yum install -y yum-utils \ device-mapper-persistent-data \ lvm21.3 配置yum的docker仓库$ sudo yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo1.4 安装DOCKER CE安装docker ce为社区版。ee是企业级。 $ sudo yum install docker-ce docker-ce-cli containerd.io# 安装指定版本$ sudo yum install docker-ce-<VERSION_STRING> docker-ce-cli-<VERSION_STRING> containerd.io安装成功后可查看版本号表示安装成功 [root@VM_0_16_centos ~]# docker --versionDocker version 18.09.6, build 481bc771562. 启动2.1 启动DOCKER$ sudo systemctl start docker2.2 配置开机启动DOCKER$ sudo systemctl enable docker3. 配置3.1 修改镜像加速器针对国内网络情况，访问docker仓库存在网络慢的问题。下面使用的是国内的加速器 ...

初始环境：[注：测试主机已设置好软件源，虚拟主机默认是root用户登录] []:~/tmp# lsb_release -aNo LSB modules are available.Distributor ID: DebianDescription: Debian GNU/Linux 9.9 (stretch)Release: 9.9Codename: stretch[]:~/tmp# 目标环境： [docker+]php-7.3.6redis-5.0.5memcached-1.5.16openresty-1.15.8.1(nginx+lua)mysql-8.0.16mongodb-4.0.10一、前期准备1、文件列表（mysql选择的是debian、x64、server版） https://www.php.net/distributions/php-7.3.6.tar.xzhttp://download.redis.io/releases/redis-5.0.5.tar.gzhttps://memcached.org/files/memcached-1.5.16.tar.gzhttps://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-community-server-dbgsym_8.0.16-2debian9_amd64.debhttps://openresty.org/download/openresty-1.15.8.1.tar.gzhttps://fastdl.mongodb.org/src/mongodb-src-r4.0.10.tar.gz2、依赖准备 PHP：apt-get install curl libxml2-dev libssl-dev libzip4 libzip-dev libbz2-dev libjpeg-dev libpng-dev libxpm-dev libfreetype6-dev libgmp-dev libgmp3-dev libcurl4-gnutls-dev librecode-dev libreadline-dev libtidy-dev libxslt1-dev -yOpenResty：apt-get install libpcre3-dev libssl-dev perl make build-essential curl -y3、docker准备环境搭建使用docker，参考相应官网：《Debian安装Docker》、《使用清华源安装docker》 []:~/tmp# vim docker_install.sh#!/bin/bash#1. 卸载旧版本apt-get remove docker docker-engine docker.io#2. 安装依赖apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common -y#3. curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -#4. x86_64添加软件仓库add-apt-repository "deb [arch=amd64] https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/debian $(lsb_release -cs) stable"#5. 更新源并安装apt-get update && apt-get install docker-ce -y[]:~/tmp# chmod +x docker_install.sh && ./docker_install.sh第一步准备完成 ...

背景Ant Design Pro是一个企业级中后台解决方案，在Ant Design组件库的基础上，提炼出典型模板/业务组件/通用页等，在此基础上能够使开发者快速的完成中后台应用的开发。 在使用Ant Design Pro的过程中，可以发现它提供了一系列基于docker的开发部署方式，如下图。但是官方文档中并没有具体的介绍，本文的主要目的就是解析Ant Design Pro中对于docker的使用。 docker相关为什么使用docker?环境部署是所有团队都必须面对的问题，随着系统越来越大，依赖的服务也越来越多，例如：Web服务器 + MySql数据库 + Redis缓存等依赖服务很多，本地搭建一套环境成本越来越高，初级人员很难解决环境部署中的一些问题服务的版本差异及OS的差异都可能导致线上环境BUG，项目引入新的服务时所有人的环境需要重新配置任何安装过Docker的机器都可以运行这个容器获得同样的结果, 同的容器，从而完全消除了不同环境，不同版本可能引起的各种问题。例如，在前端开发中通常会遇到nodejs版本问题，就可以通过docker的方式进行解决。 docker中的概念Docker有三个基本概念：镜像（image）,容器（container）,仓库（repository）。 镜像（image）: 镜像中包含有需要运行的文件。镜像用来创建container，一个镜像可以运行多个container；镜像可以通过Dockerfile创建，也可以从Docker hub/registry上下载。容器（container）: 容器是Docker的运行组件，启动一个镜像就是一个容器，容器是一个隔离环境，多个容器之间不会相互影响，保证容器中的程序运行在一个相对安全的环境中。仓库（repository）: 共享和管理Docker镜像，用户可以上传或者下载上面的镜像，官方地址为 https://registry.hub.docker.com/ （类似于github对源代码的管理），也可以搭建自己私有的Docker registry。常见docker命令使用当前目录Dockerfile创建镜像，标签为xxx:v1: docker build -t xxx:v1 .创建新容器并运行: docker run --name mynginx -d nginx:latest在容器中开启交互终端：docker exec -i -t container_id /bin/bash启动容器：docker start container_name/container_id停止容器：docker stop container_name/container_id重启容器：docker restart container_name/container_id什么是docker-compose?实际项目中，不可能只单单依赖于一个服务，例如一个常见的Web项目可能依赖于: 静态文件服务器，应用服务器，Mysql数据库等。我们可以通过分别启动单个镜像，并把镜像绑定到本地对应端口的形式进行部署，达到容器可通信的目的。但是为了更方便的管理多容器的情况，官方提供了docker-compose的方式。docker-compose是Docker的一种编排服务，是一个用于在 Docker 上定义并运行复杂应用的工具，可以让用户在集群中部署分布式应用。 compose中有两个重要的概念： 服务 (service)：一个应用的容器，实际上可以包括若干运行相同镜像的容器实例。项目 (project)：由一组关联的应用容器组成的一个完整业务单元，在docker-compose.yml 文件中定义。一个项目可以由多个服务（容器）关联而成，compose 面向项目进行管理，通过子命令对项目中的一组容器进行便捷地生命周期管理。 脚本解析本地开发运行npm run docker:dev该命令使用docker-compose up命令通过docker-compose.dev.yml模板启动相关容器。 docker-compose.dev.yml内容如下： 这个compose文件定义了一个服务：ant-design-pro_dev。该服务使用Dockerfile.dev构建了当前镜像。将该容器内部的8000端口映射到host的8000端口。为了容器和host的数据同步，该容器挂载三个数据卷：../src:/usr/src/app/src, ../config:/usr/src/app/config, ../mock:/usr/src/app/mock。它将主机目录映射到容器，这样容器内的三个目录可以跟host对应的三个目录做到数据同步。 Dockerfile.dev内容如下：该容器使用node:latest作为基础镜像，并设定/usr/src/app作为工作目录。首先将package.json文件复制到该目录，并安装相关的依赖包，之后复制该文件夹下所有内容到该目录下，并使用npm run start启动应用。由于数据卷的存在，本地的三个文件夹下的任何修改都可以同步到容器中，达到更新的目的。 ...

公司为了省钱，除了一台服务器能够上网之外，其余的都是内网服务器，我把jenkins装在内网服务器下，用Dockder来搭建的，所以就出现题目的问题。怎么设置Docker jenkins容器下的maven http代理，让mvn能下载包。一、进入jenkins容器并查看Maven的安装信息# 进入容器docker exec -it jenkins bash# 查看Maven安装配置cat /var/jenkins_home/hudson.tasks.Maven.xml<?xml version='1.1' encoding='UTF-8'?><hudson.tasks.Maven_-DescriptorImpl> <installations> <hudson.tasks.Maven_-MavenInstallation> <name>maven3.5.2</name> <properties> <hudson.tools.InstallSourceProperty> <installers> <hudson.tasks.Maven_-MavenInstaller> <id>3.5.2</id> </hudson.tasks.Maven_-MavenInstaller> </installers> </hudson.tools.InstallSourceProperty> </properties> </hudson.tasks.Maven_-MavenInstallation> </installations></hudson.tasks.Maven_-DescriptorImpl>可以看到我们这里用的是3.5.2版本那么的Maven所在的目录在 /var/jenkins_home/tools/hudson.tasks.Maven_MavenInstallation/maven3.5.2二、找到setting.xml并修改# 修改setting文件，如果有挂载，那直接在宿主机上修改即可，免得进来容器里面，还要安装vimvim /var/jenkins_home/tools/hudson.tasks.Maven_MavenInstallation/maven3.5.2/conf/settings.xml在xml中的settings标签下增加以下内容 <proxies> <proxy> <id>optional</id> <active>true</active> <protocol>http</protocol> <host>代理服务器IP</host> <port>代理服务器端口</port> <!-- <username></username> <password></password> --> </proxy> </proxies>三、重启Jenkins容器docker restart jenkins#重启完，打开jenkins，mvn命令能下载包了

作者注：联系方式 leontian1024@gmail.com || github.com/XinyaoTian新人入行，非常期待能与各位大牛们讨论，感谢各位的阅读，希望对您有所帮助。一切都要从云计算和容器技术的出现说起...相信每一位老道的开发者和软件工程师们都会有过，曾经( 也许现在仍然 )被庞大且复杂的软件系统所支配的恐惧。随着软件版本的迭代和开发团队人员规模的扩大，曾经那个小巧别致、设计精良的软件或应用一去不返，如今已经变得遍地狼藉，惨不忍睹——混乱的接口、不规范的调用、像贴狗皮膏药一般贴上去的新功能组件……曾经那个赏心悦目的应用，如今看了就反胃。这一切都预示着一个问题：开发软件的方式需要改变。 纵使有那么多种软件开发模式，但如果不能从底层技术上实现对设计的约束，问题将会随着时间的推移，最终暴露出来。譬如“高内聚，低耦合”的设计理念，如果不能从底层就实现模块间的隔离，而依靠开发时的技巧和经验，那么最终这个软件依旧会变得一团糟( 因为团队会有新人的加入、即使经验老道的开发者也会有头脑发昏的时候…… )。因此，“不这么写就无法运行”这样的硬性要求就很有必要了。 云计算和容器技术的出现，非常及时地帮助我们解决了这一难题。云计算的高弹性和按需分配、容器技术的快速启停和隔离，都很好的帮助了我们减少运维开销，且对于不同模块实现操作系统级别的隔离。在这两种关键技术出现前后，软件架构的差别如下图所示： ( 上图: 单体应用 与 微服务应用 )以 Web 应用为例，按照之前的开发方式，我们往往会选用一个功能齐全但相当复杂的开发框架( 比如JAVA开发常用的 SpringBoot )，然后在这个框架的基础上，根据开发经验和框架的功能将整个应用分层( 比如最常用的表示层、业务逻辑层和数据资源层的分层方法 )，之后根据需求分析得出的各个功能，通过不同目录、文件和函数的方式分别开发，最终一个完整的 Web 应用被开发出来。其过程如下图所示。 ( 上图: 基于框架的软件开发架构网格 )通过使用框架，我们把软件在层次上分为三层，而之后的每个功能，就相当于纵向地添加一个新列。如果以这种方式看待一个应用，那么我们就可以将任何基于这种开发方法的应用看作一个3行n列的表格或矩阵了。 然而，这种非常普及的开发方式仍然有一些问题...虽然这种开发方式已经非常普及，非常成熟，但其仍有许多有待改进的地方。比如： 依赖和库过于庞杂。理想情况下，我们希望针对每一个模块，单独管理其相应的依赖和库，而不是以整个应用作为单位来管理。 无法改变层次结构。某种层次结构对于某些业务需求来说很棒，但对于另外一些也许就显得不那么合适了。使用这种方式开发，几乎所有功能都要遵从这种既定的层次开发( 比如写 UI、写业务逻辑、写数据库层 )。而对于目前日渐快速的迭代和敏捷的开发思想，我们需要一种更加灵活轻便的方式进行开发。 无法实现跨语言开发。我们知道，几乎每种编程语言都有自己最擅长的领域。也许某些功能选用其他编程语言的开发效率更高，运行效果更好。然而，使用这种方式我们往往只能使用选定的框架所支持的语言。 模块的独立性不足。单纯通过函数和文件来进行隔离，隔离性仍然不够。一个疏忽或是加急上线就会让之前良好的高内聚低耦合的良好软件结构灰飞烟灭。因此，我们需要更加底层的机制来硬性约束我们实现“高内聚低耦合”，把“应该这么做”变为“必须这么做”。 而伴随着云计算和容器技术的发展，微服务的出现，恰巧将这些问题迎刃而解。 ( 上图: 容器技术的基本层次结构 )先来说说容器技术的代表 —— DockerDocker 可以看作是轻量级的虚拟机——它可以通过“容器镜像”快速启动和停止预先配置好的相应运行环境。每一个容器都可以被看作一个独立的操作系统，相互隔离，互不干扰。因此，借助docker 我们就可以针对一个应用中不同的功能，为其独立定制运行环境，独立装载依赖和工具库，独立运行独立停止，独立升级，每个功能可以使用其最适合的编程语言进行开发，也将整个应用拘泥于一种框架了。利用 docker 将每个模块在操作系统层面进行隔离，对于每个模块都可以独立管理其生命周期了，这就是“微服务”中“微”字的具体含义。 微服务开发的重点基于这种开发方式，每个功能模块可以被独立开发，独立部署，独立运行，独立进行版本控制，等等。而对于规模比较庞大的系统来说，这种利用微服务架构所开发的应用，其天然的优势就更能体现出来了——即每个模块可以独立的团队由单独负责。因此，微服务开发中的第一个重点，就是要有非常明确的需求，以及一个经验丰富的架构师，在设计之初就对各个功能模块进行合理的规划和拆分。 在整个应用设计之初由总设计师或架构师设计好各个功能模块后，第二个重点就来了：设计微服务中各个模块间的调用接口——通常由 Rest API 或者 gRPC 组成——来负责模块之间的交互，这就是微服务的第二个重点。良好的接口设计将会使你的应用结构清晰，开发起来事半功倍。而且每个独立团队在开发时都能感受到明显的模块边界，且可以放心利用模拟数据和测试数据进行开发( 只要符合接口规则的数据就能用，不用操心其他模块是如何实现的 )，从而真正实现每个团队富有效率的并行开发。 利用微服务架构开发除了上述好处之外，在运维方面的优势也非常直观——我们可以清晰地观测到整个系统的资源瓶颈在何处( 哪个容器的资源开销最大 )，从而实现有针对性的“定向扩缩容”。利用微服务架构前后的扩缩容机制如下图所示意。 ( 上图: 单体应用和微服务应用最直观的差别：定向扩缩容 示意图 )将庞大的单体应用逐步改造成微服务应用在看完上面的介绍后，相信饱受单体应用折磨的各位读者已经对微服务开发已经跃跃欲试了。但是，对于一个正在运行并使用的应用来说，完完全全从零开始开发并不现实。对于一个已经成熟并正在使用的单体应用系统来说，我们可以通过自己的努力，将一个单体应用在几次迭代过程中，逐渐改变为微服务应用。如何办到呢？下面放一张图片来帮助您激发灵感： ...

2019 年 最简单最通俗的 vagrant 安装使用说明，附带示例vagrantfileVagrant是一个基于Ruby的工具，用于创建和部署虚拟化开发环境。它 使用Oracle的开源VirtualBox虚拟化系统，使用 Chef创建自动化虚拟环境。 老套路，更新留坑vagrant 安装官网链接vagrant windows 下载64 位下载：https://releases.hashicorp.co...32 位下载：https://releases.hashicorp.co...百度云64位下载： 链接：https://pan.baidu.com/s/1oiztOlj0S_h6AfQ6WdUb_w 提取码：aoph vagrant mac 下载64 位下载: https://releases.hashicorp.co...vagrant box 下载官网下载:https://app.vagrantup.com/box...百度云下载： 提取码：aophvagrant box 添加到本地镜像下载好的镜像添加vagrant box add {镜像名称} {镜像地址}例如： vagrant box add C:/box/centos7.box --name centos/7.5 使用远程镜像vagrant box add https://mirrors.tuna.tsinghua.edu.cn/ubuntu-cloud-images/bionic/current/bionic-server-cloudimg-amd64-vagrant.box --name ubuntu/bionicvagrant 命令说明vagrant up 启动/创建虚拟机G:\project vagrant up ci1.cn && vagrant ssh ci1.cnBringing machine 'ci1.cn' up with 'virtualbox' provider...==> ci1.cn: Clearing any previously set forwarded ports...==> ci1.cn: Vagrant has detected a configuration issue which exposes a.....Last login: Mon Jun 24 06:40:46 2019 from 10.0.2.2[vagrant@ci1 ~]$ lsnode-v12.3.1 node-v12.3.1.tar.gz project[vagrant@ci1 ~]$vagrant ssh 进行虚拟机交互命令行G:\project vagrant ssh ci1.cnLast login: Mon Jun 24 06:40:46 2019 from 10.0.2.2[vagrant@ci1 ~]$vagrant reload 重新启动虚拟机vagrant reload ci1.cnvagrant up/reload --provision 重新创建或重新执行脚本vagrant up --provisionvagrant reload --provisionvagrant status 查看当前目录下的虚拟机状态vagrant status例如： ...

基于 Docker 的 Kong 的环境搭建本次操作都是基于 Docker 进行操作的，使用的 Kong 的版本是 1.2.0 ，使用的 PostgreSQL 版本是 9.6。本文档的前提是已经安装最新版 Docker，并能够连接至 Docker 官方镜像中心下载镜像。如果有不满足的条件，自行调整命令。 创建 Kong 专用网络 创建一个 Kong 相关镜像的专用网络，通过这个网络实现网络互通。 docker network create kong-network安装数据库 使用 Docker 安装 PostgreSQL 数据库，加入 Kong 专用网络，创建用户kong，创建数据库kong。 docker run -d \ --name kong-database \ --net kong-network \ -p 5432:5432 \ -e "POSTGRES_USER=kong" \ -e "POSTGRES_DB=kong" \ postgres:9.6初始化数据库 使用 Kong 官方镜像提供的功能初始化 PostgreSQL 数据库。因为接入了Kong专用网络，所以这里的KONG_PG_HOST 直接写 kong-database ，也就是前面创建的 PostgreSQL 数据库的容器 name。 docker run --rm \ --net kong-network \ -e "KONG_DATABASE=postgres" \ -e "KONG_PG_HOST=kong-database" \ -e "KONG_PG_PASSWORD=kong" \ -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \ kong:1.2.0 kong migrations bootstrap安装 Kong ...

Docker Swarm 是 Docker 官方三剑客项目之一，提供 Docker 容器集群服务，是 Docker 官方对容器云生态进行支持的核心方案。使用它，用户可以将多个 Docker 主机封装为单个大型的虚拟 Docker 主机，快速打造一套容器云平台。基本概念Swarm 是使用 SwarmKit 构建的 Docker 引擎内置（原生）的集群管理和编排工具。使用 Swarm 集群之前需要了解以下几个概念。 节点运行 Docker 的主机可以主动初始化一个 Swarm 集群或者加入一个已存在的 Swarm 集群，这样这个运行 Docker 的主机就成为一个 Swarm 集群的节点 ( node ) 。节点分为管理 ( manager ) 节点和工作 ( worker ) 节点。管理节点用于 Swarm 集群的管理， docker swarm 命令基本只能在管理节点执行（节点退出集群命令 docker swarm leave 可以在工作节点执行）。一个 Swarm 集群可以有多个管理节点，但只有一个管理节点可以成为 leader ， leader 通过 raft 协议实现。工作节点是任务执行节点，管理节点将服务 ( service ) 下发至工作节点执行。管理节点默认也作为工作节点。你也可以通过配置让服务只运行在管理节点。来自 Docker 官网的这张图片形象的展示了集群中管理节点与工作节点的关系 ...

背景：阿里云内网服务器无法访问外网，需要借助外网服务器的代理服务，让Docker能下载image，以及支持Docker的容器能访问外网。一、创建目录$ sudo mkdir -p /etc/systemd/system/docker.service.d二、创建配置文件/etc/systemd/system/docker.service.d/http-proxy.conf[Service]Environment="HTTP_PROXY=http://proxy.example.com:80/"三、重启Docker服务$ sudo systemctl daemon-reload$ sudo systemctl restart docker四、检验是否加载配置systemctl show --property=Environment docker如果配置成功则显示 Environment=HTTP_PROXY=http://proxy.example.com:80/五、测试docker search redis若能通过代理连上外网 Docker官网有详细说明https://docs.docker.com/confi...

2019年最新最快最简洁最详细的docker 和 docker-compose 安装使用屁话不多说，直接开始重要内容 本区域留用与后续更新docker 安装windows 专业版安装 docker系统要求Docker for Windows 支持 64 位版本的 Windows 10 Pro，且必须开启 Hyper-V。 百度盘下载链接：https://pan.baidu.com/s/1Lkcaz7rMyepsWDIxXTb1zw 提取码：xfwu 复制这段内容后打开百度网盘手机App，操作更方便哦直接下载链接点我安装下载好之后双击 Docker for Windows Installer.exe 开始安装。 mac版本下载点我安装下载好之后双击 Docker.dmg 开始安装。 linux 安装推荐安装方式：阿里云 # install docker curl -fsSL https://get.docker.com | sudo bash -s docker --mirror Aliyun rm -rf get-docker.sh # start docker service sudo systemctl enable docker sudo systemctl restart docker # 配置镜像加速器 sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://dt77flbr.mirror.aliyuncs.com"] } EOF sudo systemctl daemon-reload sudo systemctl restart dockerdocker 使用命令查看运行中的容器docker ps -a创建容器docker run ....举例： ...

“故障注入 Sidecar“——为您的微服务注入故障以验证集群性能! 由于导师和实验室师兄们的科研需要，本人专门以 Sidecar的模式设计了一个用于错误注入的微服务模块。该模块可以与任何微服务应用共同部署运行，为其模拟cpu、内存等错误。 本项目的 Github地址: https://github.com/iscas-micr...我的联系方式: leontian1024@gmail.com || 或直接留言 欢迎您提出问题批评指点!项目背景目前，本人正在中科院软件所的微服务研究组从事部分研究工作。由于本人所在科研小组的研究内容( 微服务自动扩缩容相关 )，需要经常使微服务应用处于"高 CPU 利用率" 和 "高内存使用"的状态。因此，为了方便导师和实验室的各位师兄进行实验，本人特地开发了一个可以注入进 Pod 中的错误注入容器，来模拟上述的高负载状态。 导师和师兄们使用后对我的工作给予了肯定，因此我准备将开发过程和简单使用方法写成文章做个记录( 也就是本文 )，一来方便自己日后工作学习，二来也方便有类似实验需求的其他同仁们使用这个小项目，为大家的研究节省时间。更具体的安装和使用方法，可以移步本项目 Github 的代码仓库，其中有非常详细的说明。 知识储备什么是微服务中的"Sidecar 运行模式?" 上图: 以 Sidecar 模式部署并运行的微服务单元Sidecar 运行模式是最近两年比较火的一种微服务部署和运行方法，它由目前流行的 ServiceMesh(服务网格) 架构推广而来。 具体而言，Sidecar 运行模式是一种"将不属于业务应用的功能以独立的容器运行于业务容器旁边"，在 K8s 中表现出的样子就是将具有不同功能的模块封装成不同的镜像，并以不同的容器运行在同一个 Pod 中。这种说法非常形象，因为 Sidecar 这个单词的本意就是三轮摩托侧面的"跨斗"，这里形容独立于业务应用但又与业务应用部署在一起非常合适。 上图: Sidecar ，中文意思为摩托车的跨斗，不由赞叹命名的非常生动主要设计思想架构设计本项目的错误注入模块也采用了 Sidecar 这种设计思想，将用于模拟 CPU、内存等故障的模块独立封装成一个镜像，并在 Pod 启动时以 Sidecar 的形式运行在主业务容器旁边。这样，不用它时他就会安安静静地当个美男子，完全不用担心它会影响到正常业务的运行；一旦需要它模拟错误产生，由于与业务容器同处于一个 Pod 之中(而 K8s 又以 Pod 为基本单元)，因此他模拟出的错误亦被 K8s 集群视为业务应用所在 Pod 产生而被监测到。 上图: Pod 中的每个容器都有自己的端口映射到外部主机，因此不会相互影响注入方式设计本项目在设计之初是采用“在容器内修改环境变量”的方式对容器注入故障的，但事实证明这种方法太low，而且非常麻烦。因此在后续设计和实现中采用了目前较为流行的通过 REST API 传递 POST 请求的方式使容器模拟错误，这样就极大地方便了师兄们展开实验，而且也可以模拟出“微服务间调用而产生错误”的场景( 上游服务调用错误注入的 API 而模拟下游服务产生错误 )。 ...

服务端启动命令 docker run -d -p 5000:5000 --restart always --name registry registry:2ip地址及验证api 客户端build root@swoole_dev:/home/tb/my_docker_helloworld# docker build -t 192.168.1.8:5000/hello_docker:latest .Sending build context to Docker daemon 916.5kBStep 1/3 : FROM scratch ---> Step 2/3 : ADD hello / ---> Using cache ---> 11b009df24b2Step 3/3 : CMD ["/hello"] ---> Using cache ---> 6c539eb137ddSuccessfully built 6c539eb137ddSuccessfully tagged 192.168.1.8:5000/hello_docker:latest## 验证imageroot@swoole_dev:/home/tb/my_docker_helloworld# docker images |grep 192192.168.1.8:5000/hello_docker latest 6c539eb137dd 21 hours ago 913kBroot@swoole_dev:/home/tb/my_docker_helloworld# 验证服务端 root@swoole_dev:/home/tb/my_docker_helloworld# telnet 192.168.1.8 5000Trying 192.168.1.8...Connected to 192.168.1.8.Escape character is '^]'.尝试push ...

关于docker的优势就不多介绍了，之前的文章已经说得比较明白了，那么在学习了docker的一些知识后，现在该用它来做点事儿了，^_^，有点小兴奋。接下来就来看看docker怎样去部署一个VueJs的项目，我们从以下三点来进行：VueJs项目初始化以及打包Nginx的配置Docker镜像文件VueJs项目初始化这里通过vue-cli对一个vuejs项目进行初始化，命令如下： vue init webpack projectName这里项目名称列如是docker-web，对项目初始化组件HelloWord.vue组件进行简单的修改 然后通过npm run build命令进行项目的打包 Nginx的配置这里首先需要从docker hub上面进行nginx进行的拉取，可通过docker pull nginx进行获取，获取完后，可通过命令docker image ls 命令来查看本地已存在的镜像列表然后在项目(docker-web)的根目录新增一个nginx.conf文件，配置如下： Docker镜像文件首先在项目(docker-web)的根目录新增一个Dockerfile文件，内容如下：然后需要通过Dockerfile这个文件来进行镜像的制作、运行，可通过docker build -t 镜像名称来构建制作一个镜像，如：再次查看该镜像是否已经构建完成。最后以这个镜像为基础运行一个容器。对于这部分的内容，如有不懂的地方，可查看我之前有关于docker镜像构建的文章哦。至此，所有准备工作已完成，然后在浏览器地址栏输入localhost:3000访问网页，即可看到刚才在docker-web这个项目的HelloWord.vue组件中修改的内容。 Over，接下来会通过docker对前端项目部署进行进一步的实战。

对docker 常用的一些命令做一个记录 镜像 image 相关## 拉去一个镜像文件docker pull [选项] [Docker Registry 地址[:端口号]/]仓库名[:标签]docker pull ubuntu:18.04## 查看镜像列表docker image lsdocker image ls -q -q是只列出id## 镜像列表过滤docker image ls -f dangling=true ## 虚悬镜像docker image ls -f since=mongo:3.2 ## 在指定的镜像之后创建的镜像docker image ls -f before=mongo:3.2 ## 在指定的镜像之前创建的镜像## 根据镜像名称和标签过滤docker image ls ubuntu docker image ls ubuntu:18.04 ## 删除虚悬镜像docker image prune ## 删除镜像docker image rm [选项] <镜像1> [<镜像2> ...]docker image rm d610e7d67ed0## 命令组合删除所有的镜像docker image rm $(docker image ls -q)## 构建一个新的imagedocker build [选项] <上下文路径/URL/->docker build -t nginx:v3 . 构建image容器 container 相关## 运行镜像生成容器docker run [选项] <镜像名称>docker run --name webserver -d -p 4000:80 nginx-d 是后端运行-p 宿主端口:容器内端口 端口映射## 进入container bashdocker exec -it [container名称] basheg:docker exec -it webserver bash## 提交容器docker commit [选项] <容器ID或容器名> [<仓库名>[:<标签>]]docker commit \ --author "cfl <cfl@qq.com>" \ --message "test" \ webserver \ nginx:v2## 提交历史docker history nginx:v2## container内容修改记录docker diff webserver其他命令## 查看镜像、容器、数据卷所占用的空间。docker system df未完待续

容器对前端开发真的有用吗？答案是肯定的。 最初当我向公司的前端同学「安利」容器技术的时候，很多人都会说：「容器？这不是用在后端的技术吗？我不懂啊，而且前端开发用不上吧。」 但其实，今天我们讨论的「前端」已经不是传统意义上的「前端」, 首先体现在终端类型的多样性，比如 iOS，Android，小程序等；另外，伴随着 Node.js 等技术的兴起，前端开发的边界也在逐渐服务端延伸。来到大前端时代，如何以工程化、服务化和自动化的方式来进行应用开发，实现业务的持续迭代、高可用、高并发是每一个成功的互联网产品不断探索的事情，而渐为成熟的容器技术大大提高了这个过程的效率。 本文将结合马蜂窝容器化平台赋能前端应用构建的实践经验，介绍整个平台背后的设计和实现原理，取得的一些效果及问题的优化方案。 容器与前端的结合点一般来说前端的开发流程是这样的：创建服务/项目 → 本地开发 → 开发环境测试 → 生产环境测试  → 生产灰度 → 上线。 基于容器化平台进行前端开发的优势在于，前端和后端完全分离，我们只需要关注前端的项目构建，而不需要和后端代码一起打包。每个构建版本及每个访问规则也都是独立的，一个版本构建失败并不影响其他版本的构建及访问。 那么，容器和前端的结合点在哪里？容器的优势在前端应用研发的哪个环节发生作用？我们可以从开发、测试、生产这三个阶段分别来看。  开发环节容器消除了线上线下的环境差异，保证了应用生命周期的环境一致性标准化。而对于前端开发来说，要完成的任务往往是完成内容的呈现和响应用户的输入，处理的是 HTML、JS、CSS 等静态资源，文件直接发送到客户端，不需要一个运行环境，这里好像用不上容器。 那 Build 的时候呢？毕竟不同的项目是用不同的 Node 版本在做构建，不同的容器可以进入不同的 Node 版本，这样就不会污染本机的 Node 环境。但其实没有容器，前端还可以用 NVM 去管理 Node 版本，切换起来很随意，也就是一两行命令就能搞定的事情。而且本地开发很方便，看起来真的没有必要用容器。 可以说，容器本身并没有帮助前端在开发阶段变得更加便利。因此如果对容器技术不熟悉，开发阶段没有必要非要用容器。 测试环节过去我们用虚拟机进行测试的一个常见的方案是，前端研发把自己的代码上传到虚拟机的一个目录下，QA 可以直接通过域名进行测试。但问题是，公司有很多的产品线，可能会存在很多项目同时提测的情况。虚拟机对系统资源的消耗比较大，数量有限，并且难扩容，影响测试效率。 如果使用容器化平台就不会出现这方面的担忧。因为容器非常轻量，消耗低、启动快，可以迅速扩容，不用担心不够用的问题。 生产环节容器的另一个优势是它可以实现应用程序的版本控制。比如我们在上线之后发现版本有问题需要回滚，这种情况不可避免，传统的做法是通过 Git 或者 SVN 回滚，一旦合入的代码想回退或者拆分就很难操作，而且重新部署也很耗时。 基于容器化的平台，我们可以直接通过流控，把流量切到旧的版本上去，几需要几秒钟的时间，回滚效率大大提升。 再如，前端性能的一个重要指标是页面加载时间，如果出现首页白屏是非常破坏用户体验的，特别是在做活动的时候，我们把几乎所有流量都引导到活动页，出现白屏会非常让人抓狂。找到运维排查之后发现有台服务器挂了，只能通过重启来解决。但是重启机器存在很多不确定性，有可能这台机器就起不来了，这种情况很常见。 但如果运行在容器化平台上，一个容器就是一个进程，一台机器如果宕机，集群会快速从另外一个节点把服务拉起，而且是秒级的，基本不用担心用户的访问会出现问题。 总结来看，容器与虚拟机相比主要的优势体现在可以实现快速扩容、秒级回滚和稳定保活。因此容器化对于前端开发来说，更重要的意义是能够保证服务的快速迭代，以及线上服务的稳定性。 前端需要了解的容器知识点通过上面的介绍，相信大家已经对容器技术为前端开发带来了哪些变化有了一些感受。那么为了更好地应用这项技术，前端同学也应该掌握一些容器的基础知识。  容器是什么首先我们来看容器到底是什么，它为什么轻量、高性能。通过下面这张图片，我们可以将虚拟机和容器进行一个更加直观的对比： 虚拟机通过在物理服务器上层通过运行 Hypervisor 模拟硬件系统，来提升服务器的能力和容量。每个虚拟机中有一个内核，运行着不同的操作系统，启动之后会做进程管理、内存管理之类的事情。但对于前端应用的构建来说，可能只是需要一个 Nginx 做静态服务器，这种场景下使用虚拟机就太重了。 容器之所以轻量，是因为容器没有 Hypervisor 层和内核层，每个容器都共享宿主机的内核和系统调用。因此一个容器内包含的仅仅是一个程序运行所需要的最少文件，启动容器就是启动进程，对资源的开销更小，维护起来更简单。 镜像、容器和 Docker 这是大家在聊到容器技术的时候经常会提到的三个词，下面来说下它们各自的概念以及之间的联系是什么。 镜像：可以简单理解为一层层文件系统的集合，或者说一些目录的集合。比如对于我们的前端代码，最下面那层目录可能是 Nginx 运行所需要的二进制，然后在上面再加一层目录是我们的代码，比如说 index.html。这个镜像分层所有的分层生成以后，都是只读的，每一层文件不可修改。 ...

Compose 项目是 Docker 官方的开源项目，负责实现对 Docker 容器集群的快速编排。其代码目前在 https://github.com/docker/com... 上开源。介绍Compose 定位是 「定义和运行多个 Docker 容器的应用（Defining and runningmulti-container Docker applications）」。 我们知道通过Dockerfile 模板文件，可以让用户很方便的定义一个单独的应用容器。然而，在日常工作中，经常会碰到需要多个容器相互配合来完成某项任务的情况。例如要实现一个 Web 项目，除了 Web 服务容器本身，往往还需要再加上后端的数据库服务容器，甚至还包括负载均衡容器等。 Compose 恰好满足了这样的需求。它允许用户通过一个单独的 docker-compose.yml 模板文件（YAML 格式）来定义一组相关联的应用容器为一个项目（project）。 Compose 中有两个重要的概念： 服务 ( service )：一个应用的容器，实际上可以包括若干运行相同镜像的容器实例。项目 ( project )：由一组关联的应用容器组成的一个完整业务单元，在docker-compose.yml 文件中定义。Compose 的默认管理对象是项目，通过子命令对项目中的一组容器进行便捷地生命周期管理。 Compose 项目由 Python 编写，实现上调用了 Docker 服务提供的 API 来对容器进行管理。因此，只要所操作的平台支持 Docker API，就可以在其上利用Compose 来进行编排管理。 安装与卸载Compose 支持 Linux、macOS、Windows 10 三大平台。Compose 可以通过 Python 的包管理工具 pip 进行安装，也可以直接下载编译好的二进制文件使用，甚至能够直接在 Docker 容器中运行。前两种方式是传统方式，适合本地环境下安装使用；最后一种方式则不破坏系统环境，更适合云计算场景。 接下来看看在Linux系统上的安装。 二进制包的安装在 Linux 上的也安装十分简单，从 官方 Github Realease 处直接下载编译好的二进制文件即可。比如64为的linux下可以通过如下命令进行安装： ...

docker小结Docker是一个开源的容器引擎，它有助于更快地交付产品。 Docker可将应用程序和基础设施层隔离，并且将基础设施当作程序一样进行管理。使用Docker，可以更快地打包，测试以及部署应用程序，并可以缩短从编程到部署运行代码的周期。 安装ubuntu wget -qO- https://get.docker.com/ | sh当要以非root用户可以直接运行docker时，需要执行 sudo usermod -aG docker runoob 命令，然后重新登陆，否则会报错 或者安装Docker社区版仓库 sudo apt-get -y install \ apt-transport-https \ ca-certificates \ curl curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" sudo apt-get update #在Ubuntu上安装最新的Docker社区版 sudo apt-get -y install docker-ce #测试你的Docker社区版是否安装成功 sudo docker run hello-world启动 sudo service docker start测试运行hello-world docker run hello-world镜像加速 ...

在介绍.gitlab-ci.yml之前，我们先看几个概念： GitLab Runner一般来说，构建任务都会占用很多的系统资源 (譬如编译代码)，而 GitLab CI 又是 GitLab 的一部分，如果由 GitLab CI 来运行构建任务的话，在执行构建任务的时候，GitLab 的性能会大幅下降。 GitLab CI 最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情就交给 GitLab Runner 来做啦。因为 GitLab Runner 可以安装到不同的机器上，所以在构建任务运行期间并不会影响到 GitLab 的性能。 GitLab Runner的安装特别简单，官网有各平台的安装方法或安装包，此处不再赘述。 注册打开GitLab 中的项目页面，在项目设置中找到 runners在runner运行的机器上，用命令行注册，比如：gitlab-runner register --name="XX" --url="https://git.xx.com/" --token="XXX" --executor="shell" 按照提示一步一步安装就可以了。其中，executor可以是多种类型，简单的话可以选shell。有熟悉docker的可以使用docker。 配置文件在/etc/gitlab-runner/config.toml 配置项类似下面，可能需要手动添加builds_dir和cache_dir这两个变量，再重启服务 [[runners]] name = "216XX" url = "https://git.XX.com/" token = "XX" executor = "shell" builds_dir = "/home/gitlab-runner/builds" cache_dir = "/home/gitlab-runner/cache" [runners.cache]常见命令 sudo gitlab-runner list 查看各个 Runner 的状态 sudo gitlab-runner stop 停止服务 sudo gitlab-runner start 启动服务 sudo gitlab-runner restart 重启服务StagesStages 表示构建阶段，说白了就是上面提到的流程。默认有3个stages：build, test, deploy。我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点： ...

问题microk8s安装过程中,部分镜像需要从google的镜像仓库拉取,但是国内无法访问其镜像仓库, 故需要手动获取镜像再自行安装(从官方提供的google mirror仓库获取)microk8s不是使用的宿主机器的docker进程, 故不能简单的把自己获取的镜像重新tag来完成安装; 需要导出之后然后使用microk8s提供的镜像管理功能进行导入解决原理获取到你需要的镜像名称和版本之后 (参见后面的排查技巧) docker pull mirrorgooglecontainers/$imageName:$imageVersiondocker tag mirrorgooglecontainers/$imageName:$imageVersion k8s.gcr.io/$imageName:$imageVersiondocker save k8s.gcr.io/$imageName:$imageVersion > $imageName.tarmicrok8s.ctr -n k8s.io image import $imageName.tar示例步骤视你开启的插件而言,需要手动安装需要的镜像, 以我为例, 需要如下这些(注意版本可能不一样) k8s.gcr.io/pause:3.1k8s.gcr.io/heapster-influxdb-amd64:v1.3.3k8s.gcr.io/heapster-grafana-amd64:v4.4.3k8s.gcr.io/heapster-amd64:v1.5.2k8s.gcr.io/kubernetes-dashboard-amd64:v1.8.3gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7安装脚本如下(可以根据原理做成通用脚本再传参安装): docker pull mirrorgooglecontainers/pause:3.1docker pull mirrorgooglecontainers/heapster-influxdb-amd64:v1.3.3docker pull mirrorgooglecontainers/heapster-grafana-amd64:v4.4.3docker pull mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.8.3docker pull mirrorgooglecontainers/heapster-amd64:v1.5.2docker pull mirrorgooglecontainers/k8s-dns-dnsmasq-nanny-amd64:1.14.7docker pull mirrorgooglecontainers/k8s-dns-kube-dns-amd64:1.14.7docker pull mirrorgooglecontainers/k8s-dns-sidecar-amd64:1.14.7docker tag mirrorgooglecontainers/pause:3.1 k8s.gcr.io/pause:3.1docker tag mirrorgooglecontainers/heapster-influxdb-amd64:v1.3.3 k8s.gcr.io/heapster-influxdb-amd64:v1.3.3docker tag mirrorgooglecontainers/heapster-grafana-amd64:v4.4.3 k8s.gcr.io/heapster-grafana-amd64:v4.4.3docker tag mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.8.3 k8s.gcr.io/kubernetes-dashboard-amd64:v1.8.3docker tag mirrorgooglecontainers/heapster-amd64:v1.5.2 k8s.gcr.io/heapster-amd64:v1.5.2docker tag mirrorgooglecontainers/k8s-dns-dnsmasq-nanny-amd64:1.14.7 gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7docker tag mirrorgooglecontainers/k8s-dns-kube-dns-amd64:1.14.7 gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7docker tag mirrorgooglecontainers/k8s-dns-sidecar-amd64:1.14.7 gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7docker save k8s.gcr.io/pause > pause.tardocker save k8s.gcr.io/heapster-influxdb-amd64 > heapster-influxdb-amd64.tardocker save k8s.gcr.io/heapster-grafana-amd64 > heapster-grafana-amd64.tardocker save k8s.gcr.io/kubernetes-dashboard-amd64 > kubernetes-dashboard-amd64.tardocker save k8s.gcr.io/heapster-amd64 > heapster-amd64.tardocker save gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64 > k8s-dns-dnsmasq-nanny-amd64.tardocker save gcr.io/google_containers/k8s-dns-kube-dns-amd64 > k8s-dns-kube-dns-amd64.tardocker save gcr.io/google_containers/k8s-dns-sidecar-amd64 > k8s-dns-sidecar-amd64.tarmicrok8s.ctr -n k8s.io image import pause.tarmicrok8s.ctr -n k8s.io image import heapster-influxdb-amd64.tarmicrok8s.ctr -n k8s.io image import heapster-grafana-amd64.tarmicrok8s.ctr -n k8s.io image import kubernetes-dashboard-amd64.tarmicrok8s.ctr -n k8s.io image import heapster-amd64.tarmicrok8s.ctr -n k8s.io image import k8s-dns-dnsmasq-nanny-amd64.tarmicrok8s.ctr -n k8s.io image import k8s-dns-kube-dns-amd64.tarmicrok8s.ctr -n k8s.io image import k8s-dns-sidecar-amd64.tar排查技巧遇到问题时先通过 microk8s.kubectr get pods 查看是否是RUNNING状态, 如果不是,先按照上述方法解决镜像问题查看具体的镜像版本时候可以通过 kubectl get pods --namespace=kube-system -o json |grep message直接过滤出错误消息注意namespace的选择, 特别是你自己定义了namespace之后

1. Docker 要求的内核版本>3.10 ，uname -r 命令检查内核版本 uname -r2. 更新yum yum update3.安装软件 yum install -y yum-utils device-mapper-persistent-data lvm24.查看docker 现有的版本 yum list docker-ce --showduplicates | sort -r5.选定一个版本安装 yum install docker-ce-18.06.3.ce-3.el76.启动docker systemctl start docker7.docker开机自启 systemctl enable docker8.docker验证 docker version9.修改docker 镜像源cd /etc/dockertouch daemon.jsonvim daemon.json10.输入配置文件内容，保存后退出{ "registry-mirrors":["https//registry.docker-cn.com"]}11.更新配置，重启dockersystemctl daemon-reloadsystemctl restart docker12.查询镜像docker search postgres13.下载镜像docker pull postgres:1014.创建镜像挂载目录docker volume reate pgdata15.启动镜像docker run --name pgsql -v pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=123456 -p 5432:5432 -d postgres:10 --name 命名镜像实例 -v 持久化挂载(宿主机目录:容器目录) -e 环境变量参数 -p 端口映射(宿主机端口:容器端口)16.查看运行中镜像docker ps

容器内部以及容器之间的数据管理是怎么样进行的？ 其实在 Docker 内部以及容器之间管理数据，在容器中管理数据主要有两种方式： 数据卷（Volumes）挂载主机目录 (Bind mounts)数据卷数据卷是一个可供一个或多个容器使用的特殊目录，它绕过 UFS，可以提供很多有用的特性： 数据卷可以在容器之间共享和重用对数据卷的修改会立马生效对数据卷的更新，不会影响镜像数据卷默认会一直存在，即使容器被删除注意： 数据卷 的使用，类似于 Linux 下对目录或文件进行 mount，镜像中的被指定为挂载点的目录中的文件会隐藏掉，能显示看的是挂载的 数据卷 。 既然数据卷可以对容器的数据进行管理，那么该怎么去创建和使用数据卷呢？ 数据卷操作创建数据卷可以通过命令docker volume create 数据卷的名称来创建一个数据卷，如： 从上图中可以看出我们创建的数据卷my-vol已经存在了。然后可以通过docker volume create 数据卷的名称来查看具体的某个数据卷的信息，如： 启动一个挂载数据卷的容器在用 docker run 命令的时候，使用 --mount 标记来将 数据卷 挂载到容器里。在一次 docker run 中可以挂载多个 数据卷 。下面创建一个名为 web 的容器，并加载一个 数据卷 到容器的 /webapp 目录。 docker run -d -P \--name web \# -v my-vol:/wepapp \--mount source=my-vol,target=/webapp \training/webapp \python app.py查看数据卷的具体信息在主机里使用以下命令可以查看 web 容器的信息 $ docker inspect web数据卷 信息在 "Mounts" Key 下面 ...

本文节选自我的博客文章：构建可靠、安全、最小化的 Docker 镜像: 原理与实践.正如Code Review一样，代码审查可以大大提升企业项目的质量。容器镜像同样作为开发人员或是运维人员的产出物，对其进行审查也是必要的。 虽然我们可以通过docker命令结合文件系统浏览的方式进行容器镜像的审查，但其过程需要人工参与，很难做到自动化，更别提将镜像审查集成到CI过程中了。但一个好的工具可以帮我们做到这点。 向大家推荐一个非常棒的开源项目dive，具体安装请参考其项目页。它不但可以方便我们查询具体镜像层的详细信息，还可以作为CI持续集成过程中的镜像审查之用。使用它可以大大提升我们审查镜像的速度，并且可以将这个过程做成自动化。 该项目的具体动态操作图示如下： 如果作为镜像审查之后，可以进行如下命令操作: $: CI=true dive <image-id>Fetching image... (this can take a while with large images)Parsing image...Analyzing image... efficiency: 95.0863 % wastedBytes: 671109 bytes (671 kB) userWastedPercent: 8.2274 %Run CI Validations... Using default CI config PASS: highestUserWastedPercent SKIP: highestWastedBytes: rule disabled PASS: lowestEfficiency从输出信息可以得到很多有用的信息，集成到CI过程也就非常容易了。 dive本身就提供了.dive-ci作为项目的CI配置: rules: # If the efficiency is measured below X%, mark as failed. # Expressed as a percentage between 0-1. lowestEfficiency: 0.95 # If the amount of wasted space is at least X or larger than X, mark as failed. # Expressed in B, KB, MB, and GB. highestWastedBytes: 20MB # If the amount of wasted space makes up for X% or more of the image, mark as failed. # Note: the base image layer is NOT included in the total image size. # Expressed as a percentage between 0-1; fails if the threshold is met or crossed. highestUserWastedPercent: 0.20集成到CI中，增加以下命令即可: ...

近期新闻css宣布支持三角函数ES10即将来临 基本架构注册中心： 每个服务提供者向注册中心登记自己的服务，将服务名与主机Ip，端口等一些附加信息告诉注册中心，注册中心按服务名分类组织服务清单。如A服务运行在192.168.1.82:3000，192.168.1.83：3000实例上。那么维护的内容如下：简单来说，服务中心会维护一份，在册的服务名与服务ip的映射关系。同时注册中心也会检查注册的服务是否可用，不可用则剔除。服务消费者：即在注册中心注册的服务，他们之间不再通过具体地址访问，而是通过服务名访问其他在册服务的资源。 技术说明Consul:采用Go开发的高可用的服务注册与配置服务，本文的注册中心采用Consul实现。Docker:基于Go语言的开源应用容器引擎。Registor:Go语言编写，针对docker使用的，通过检查本机容器进程在线或者停止运行状态，去注册服务的工具。这里主要用作对服务消费者的监控。示例环境： 系统：macos； docker: 17.09.1-ce； docker-compose:1.17.1。 docker命令创建注册中心docker run -h node1 --name consul -d --restart=always\ -p 8400 \ -p 8500:8500 \progrium/consul -server \-bootstrap-expect 1 -advertise 127.0.0.1下面来解释下各个参数-h 节点名字--name 容器（container）名称，后期用来方便启动关闭，看日志等，这个一定要写-d 后台运行-v /data:/data 使用宿主机的/data目录映射到容器内部的/data,用于保存consul的注册信息，要不docker 一重启，数据是不保留的。--restart=always 这个可以活得长一点下面几个参数都是consul集群用的，非集群模式可以不使用。 -p 8500:8500 \progrium/consul 镜像名称，本地没有就自动从公共docker库下载后面的都是consul的参数：-server 以服务节点启动-bootstrap-expect 3 预期的启动节点数3，最少是3，要不达不到cluster的效果-advertise 127.0.0.1 告诉集群，我的ip是什么，就是注册集群用的 使用docker-compose创建注册中心使用docker命令创建注册中心比较麻烦，并且不好维护，这里使用docker-compose来实现。docker-compose:compose是 Docker 容器进行编排的工具，定义和运行多容器的应用，可以一条命令启动多个容器，使用Docker Compose不再需要使用shell脚本来启动容器。 Compose 通过一个配置文件来管理多个Docker容器，在配置文件中，所有的容器通过services来定义，然后使用docker-compose脚本来启动，停止和重启应用，和应用中的服务以及所有依赖服务的容器，非常适合组合使用多个容器进行开发的场景。首先看下docker-compose配置文件： version: "3.0"services: # consul server，对外暴露的ui接口为8500，只有在2台consul服务器的情况下集群才起作用 consulserver: image: progrium/consul:latest hostname: consulserver ports: - "8300" - "8400" - "8500:8500" - "53" command: -server -ui-dir /ui -data-dir /tmp/consul --bootstrap-expect=3 # consul server1在consul server服务起来后，加入集群中 consulserver1: image: progrium/consul:latest hostname: consulserver1 depends_on: - "consulserver" ports: - "8300" - "8400" - "8500" - "53" command: -server -data-dir /tmp/consul -join consulserver # consul server2在consul server服务起来后，加入集群中 consulserver2: image: progrium/consul:latest hostname: consulserver2 depends_on: - "consulserver" ports: - "8300" - "8400" - "8500" - "53" command: -server -data-dir /tmp/consul -join consulserver这里consulserver,consulserver1等是服务名，image定义镜像名，depends_on定义依赖容器,command可以覆盖容器启动后默认命令。详细的配置项介绍及compose命令，可查看这里。下面进入模版目录，运行 ...

容器是 Docker 又一核心概念。简单的说，容器是独立运行的一个或一组应用，以及它们的运行态环境。对应的，虚拟机可以理解为模拟运行的一整套操作系统（提供了运行态环境和其他系统环境）和跑在上面的应用。关于容器的操作主要有： 创建启动停止导入导出删除等等启动容器启动容器有两种方式，一种是基于镜像新建一个容器并启动，另外一个是将在终止状态（ stopped ）的容器重新启动。因为 Docker 的容器实在太轻量级了，很多时候用户都是随时删除和新创建容器。 新建并启动所需要的命令主要为 docker run 这跟在本地直接执行 /bin/echo 'hello world' 几乎感觉不出任何区别。 下面的命令则启动一个 bash 终端，允许用户进行交互，如: docker run -t -i ubuntu:18.04 /bin/bash其中， -t 选项让Docker分配一个伪终端（pseudo-tty）并绑定到容器的标准输入上， -i 则让容器的标准输入保持打开。 那么当我们用docker run命令来创建并启动容器的时候，会发生哪些事儿呢？ 检查本地是否存在指定的镜像，不存在就从公有仓库下载启动利用镜像创建并启动一个容器分配一个文件系统，并在只读的镜像层外面挂载一层可读写层从宿主主机配置的网桥接口中桥接一个虚拟接口到容器中去从地址池配置一个 ip 地址给容器执行用户指定的应用程序执行完毕后容器被终止所以当我们通过bash进入终端的时候，其实就是进入另一个系统。 启动已终止容器可以利用 docker container start 命令，直接将一个已经终止的容器启动运行。 容器的核心为所执行的应用程序，所需要的资源都是应用程序运行所必需的。除此之外，并没有其它的资源。可以在伪终端中利用 ps 或 top 来查看进程信息。 可见，容器中仅运行了指定的 bash 应用。这种特点使得 Docker 对资源的利用率极高，是货真价实的轻量级虚拟化。 后台运行更多的时候，我们会在后台运行容器，这时可以加上-d参数来实现。下面是每个1秒打印一次hello world。 docker run ubuntu:18.04 /bin/sh -c "while true; do echo hello world;sleep 1;done"如果使用了 -d 参数运行容器，则就是在后台进行运行: ...

我们可以了解到，镜像的定制实际上就是定制每一层所添加的配置、文件。如果我们可以把每一层修改、安装、构建、操作的命令都写入一个脚本，用这个脚本来构建、定制镜像，那么之前提及的无法重复的问题、镜像构建透明性的问题、体积的问题就都会解决。这个脚本就Dockerfile。认识DockerfileDockerfile 是一个文本文件，其内包含了一条条的 指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。接下来以nginx为列通过Dockerfile文件来制定镜像。 在一个空白目录中，建立一个文本文件，并命名为 Dockerfile ： $ mkdir mynginx$ cd mynginx$ touch Dockerfile Dockerfile内容如下：这个 Dockerfile 很简单，一共就两行。涉及到了两条指令， FROM 和 RUN 。接下来就先了解这两个指令。 Dockerfile指令之FROMFROM指令的目的就是来指定基础镜像。 所谓定制镜像，那一定是以一个镜像为基础，在其上进行定制。而FROM就是指定基础镜像，因此一个 Dockerfile 中 FROM 是必备的指令，并且必须是第一条指令。 在 Docker Hub 上有非常多的高质量的官方镜像，有可以直接拿来使用的服务类的镜像，如 nginx 、 redis 、 mongo 、 mysql 、 httpd 、 php 、 tomcat等；也有一些方便开发、构建、运行各种语言应用的镜像，如node 、 openjdk 、 python 、 ruby 、 golang 等。可以在其中寻找一个最符合我们最终目标的镜像为基础镜像进行定制。 Dockerfile指令之RUNRUN 指令是用来执行命令行命令的。由于命令行的强大能力， RUN 指令在定制镜像时是最常用的指令之一。其格式有两种： shell 格式： RUN <命令> ，就像直接在命令行中输入的命令一样。刚才写的Dockerfile 中的 RUN 指令就是这种格式。 RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.htmlexec 格式： RUN ["可执行文件", "参数1", "参数2"] ，这更像是函数调用中的格式。前面的文章有说过，Dockerfile 中每一个指令都会建立一层， RUN 也不例外。每一个RUN 的行为，就和刚才我们手工建立镜像的过程一样：新建立一层，在其上执行这些命令，执行结束后， commit 这一层的修改，构成新的镜像。 ...

原文地址：https://chanjarster.github.io... 本文对应代码：github 用Docker部署基于GTID的MySQL Master-Slave Replication例子。 启动Master写一个文件mysql-master.cnf： [mysqld]server_id=1binlog_format=ROWgtid_mode=ONenforce-gtid-consistency=true这个配置文件把Master的server_id设置为1，要注意在同一个Master-Slave集群里，server_id不能重复。 启动Master： docker run -d --name mysql-master \ -e MYSQL_USER=my_user \ -e MYSQL_DATABASE=my_database \ -e MYSQL_PASSWORD=my_database_password \ -e MYSQL_ROOT_PASSWORD=my_root_password \ -p 3307:3306 \ -v $(pwd)/mysql-master.cnf:/etc/mysql/conf.d/mysql-master.cnf \ mysql:8.0 \ --log-bin=my启动Slave写一个文件mysql-slave-1.cnf： [mysqld]server_id=2binlog_format=ROWgtid_mode=ONenforce-gtid-consistency=trueread_only=ON这个文件把Slave的server_id设置为2，如果你有多个Slave，那么得分别设置不同的server_id。此外，将Slave设置为read_only模式（这样就不能在slave上执行写操作了）。 启动Slave： docker run -d --name mysql-slave-1 \ -e MYSQL_ROOT_PASSWORD=my_root_password \ -p 3308:3306 \ -v $(pwd)/mysql-slave-1.cnf:/etc/mysql/conf.d/mysql-slave-1.cnf \ mysql:8.0 \ --skip-log-bin \ --skip-log-slave-updates \ --skip-slave-start创建Replication用户到Master上创建Replication用户： $ docker exec -it mysql-master mysql -u root -pEnter password: my_root_passwordmysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'password';mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';将Slave和Master关联到Slave上把自己和Master关联起来： ...

我们知道Image(镜像)是Docker的三大组件之一，Docker 运行容器前需要本地存在对应的镜像，如果本地不存在该镜像，Docker 会从镜像仓库下载该镜像。接下来先看看，怎样去获取镜像。获取镜像DockerHub 上有大量的高质量的镜像可以用，这里我们就说一下怎么获取这些镜像。从 Docker 镜像仓库获取镜像的命令是 docker pull 。其命令格式为： docker pull [选项] [Docker Registry 地址[:端口号]/]仓库名[:标签]具体的选项可以通过 docker pull --help 命令看到，这里我们说一下镜像名称的格式。 Docker 镜像仓库地址：地址的格式一般是 <域名/IP>[:端口号] 。默认地址是 Docker Hub。仓库名：如之前所说，这里的仓库名是两段式名称，即 <用户名>/<软件名> 。对于 Docker Hub，如果不给出用户名，则默认为 library ，也就是官方镜像。先看一个例子，这里拉取ubuntu的一个镜像： root@huangche-PC:/# docker pull ubuntu:18.0418.04: Pulling from library/ubuntu6abc03819f3e: Pull complete 05731e63f211: Pull complete 0bd67c50d6be: Pull complete Digest: sha256:f08638ec7ddc90065187e7eabdfac3c96e5ff0f6b2f1762cf31a4f49b53000a5Status: Downloaded newer image for ubuntu:18.04 上面的命令中没有给出 Docker 镜像仓库地址，因此将会从 Docker Hub 获取镜像。而镜像名称是 ubuntu:18.04 ，因此将会获取官方镜像 library/ubuntu仓库中标签为 18.04 的镜像。其中library表示组。 从下载过程中可以看到我们之前提及的分层存储的概念，镜像是由多层存储所构成。下载也是一层层的去下载，并非单一文件。下载过程中给出了每一层的 ID 的前 12 位。如：6abc03819f3e: Pull complete ,并且下载结束后，给出该镜像完整的 sha256 的摘要，以确保下载一致性。 ...

上篇《前端也要学Docker啊!》介绍了 Docker 及它的三个主要概念：Image(镜像)、Container(容器)、Registry(仓库) 以及Docker安装。 本篇我们来动手实践：在本地创建一个自己的镜像(Node应用)，使用该镜像创建容器并执行容器中的Node应用。 创建一个Node项目在根目录创建index.js //index.jsconst Koa = require('koa');const app = new Koa();app.use(async ctx => { ctx.body = 'Hello Docker O(∩_∩)O~~';});app.listen(3000);创建 Docker 镜像需要用到 docker build命令，而docker build命令又是根据 Dockerfile 配置文件来构建镜像，所以我们要在项目根目录创建一个 Dockerfile 文件： #DockerfileFROM node:10.13-alpine #项目的基础依赖MAINTAINER chenLong #项目维护者COPY . . #将本机根目录所有文件拷贝到容器的根目录下 这个可以根据喜好调节路径EXPOSE 3000 #容器对外暴露的端口RUN npm i #安装node依赖CMD npm start #在容器环境里执行的命令你可以到 Docker 官网查看详细的Dockfile说明 构建镜像上面 Node 代码已经完成了，我们使用 yarn init -y或 npm init -y 完成package.json初始化，然后安装一个koa依赖：执行yarn add koa或 npm i koa。 然后我们在本地跑一下 node 程序：node index.js,打开浏览器输入 localhost:3000 ，可以看到浏览器中成功显示了 Hello Docker O(∩_∩)O~~ 。 ...

Redis集群概述Redis作为当前非常热门的内存型数据结构存储，可用于数据存储，缓存和消息代理等。本文将讲解如何基于docker搭建Redis集群，Redis的集群设计包括两个部分：主从复制和哈希Slot。1.1. 主从复制主从复制在数据库中很常见，一般用来做读写分离，Redis中也是如此。要求只有1个Master（主节点），可以有N个slaver（从节点），而且Slaver也可以有自己的Slaver，由于这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。读写分离，Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，所以Slaver的扩容只能提高读效率不能提高写效率。Slaver先将Master那边获取到的信息压入磁盘，再load进内存，client端是从内存中读取信息的。当一个新的Slaver加入到这个集群时，会主动找Master来拜码头，Master发现新的小弟后将全量数据发送给新的Slaver，数据量越大性能消耗也就越大，所以尽量避免在运行时做Slaver的扩容。优点：读写分离，通过增加Slaver可以提高并发读的能力。缺点：Master写能力是瓶颈，维护Slaver开销也总将会变成瓶颈。1.2. 哈希Slot哈希Slot名字上可能不好理解，其实就是数据库中的“水平划分”。如果你之前有了解过数据库的表分区的话，就会发现下来对于哈希Slot的描述，就和数据库表分区里面的“HASH分区”原理上大致相同。对象保存到Redis之前先经过CRC16哈希到一个指定的Node上，例如图中Object4最终Hash到了Node1上。每个Node被平均分配了一个Slot段，对应着0-16384，Slot不能重复也不能缺失，否则会导致对象重复存储或无法存储。Node之间也互相监听，一旦有Node退出或者加入，会按照Slot为单位做数据的迁移。例如Node1如果掉线了，0-5640这些Slot将会平均分摊到Node2和Node3上,由于Node2和Node3本身维护的Slot还会在自己身上不会被重新分配，所以迁移过程中不会影响到 5641-16384 Slot段的使用。优点：将Redis的写操作分摊到了多个节点上，提高写的并发能力，扩容简单。缺点：每个Node承担着互相监听、高并发数据写入、高并发数据读出，工作任务繁重。1.3. 合二为一看到这里大家也就发现了，主从和哈希的设计优缺点正好是相互弥补的，将二者结合在一起，就是Redis集群的终极形态，先Hash分逻辑节点，然后每个逻辑节点内部是主从，如图：2.集群安装默认我们已经有了docker环境，现在开始基于docker安装Redis集群。redis 5.0 版本之前，网上有很多教程都是通过redis-trib.rb 来创建集群，但是redis 5.0 版本以后，就只能通过 redis-cli 来实现。本文即通过 redis-cli 创建集群，因为redis集群的节点选举方式是需要半数以上的master通过，所以建议创建奇数个节点。本例中创建3个Master节点，并为每个Master节点各分配1个Slave节点。2.1. 宿主机环境首先需要找一份原始的redis.conf文件，将其重命名为：redis-cluster.tmpl，并配置如下几个参数，此文件的目的是生成每一个redis实例的redis.conf:vi redis-cluster.tmpl然后执行下列脚本，给3个Master和3个Slave创建各自的挂载卷目录当前目录结构为2.2. 创建Redis节点假设我们只考虑单纯的docker环境，并无docker-compose和k8s之类的服务编排，每个redis容器之间必须要保证通讯，可以通过创建docker network。（使用微服务编排的情况，后续再讨论）现在我们就可以运行docker redis 的 master 和 slave 实例了查看已创建的redis容器2.3. 构建集群通过redis-cli 命令构建集群，随便找一个redis容器，运行redis-cli --cluster create --cluster-replicas 1 ip:port 命令即可记住构建集群时，要保证节点redis数据为空，否则会出现下列错误。2.4. 集群验证集群搭建完成后，我们通过 redis-cli 命令连接集群节点验证一下。redis 集群节点的连接命令是通过 redis-cli -c -h ${ip} -p ${port}可以看到通过 "cluster info"命令看到集群的基本信息，所有的slot (16384) 都分配完毕。然后通过 "cluster nodes" 命令查看到每个master节点的slot分配的区域。至此，redis集群基本安装成功。3.后期运维3.1. 基本命令集群节点槽(slot)3.2. 常见问题（1）redis-cluster 把所有的物理节点映射到[ 0 ~ 16383 ]个slot（哈希槽）上，cluster负责维护 node<->slot<->value。（2）集群任意一个节点中，如果master挂掉，但是还有slaver，slave将自动升为 master，系统正常。（3）集群任意一个节点中，如果master挂掉，并且没有slaver，集群将进入fail状态。（4）如果集群超过半数以上节点的master挂掉，不管是否有slaver，集群都将进入fail状态。（5）节点判断是否失效的选举，是集群中所有的master参与的，如果半数以上的master节点与当前被检测的master节点通讯检测超时（cluster-node-timerout），就认为当前master节点挂掉了。本人创业团队产品MadPecker，主要做BUG管理、测试管理、应用分发网址:www.madpecker.com，有需要的朋友欢迎试用、体验！本文为MadPecker团队技术人员编写，转载请标明出处

最近在学习 Docker，并用 Docker 重新部署了cdfang-spider项目，使用 docker 后确实大幅度地降低了部署难度。如果你也想用 Docker 来部署自己的项目，那就让我们一起往下看。 本文通过以下 3 个方面来聊聊 Docker： Docker 发展史。Docker 基础。Docker 项目实战。Docker 发展史上古时代在很久以前，发布一个 App 应用，应该是这样的。首先购买一台物理服务器，然后手动安装对应的操作系统，搭建 App 应用运行环境，部署 App 应用，最后才能被其他人访问。这样做看似没毛病，但可能会造成几个问题： 部署非常慢。 购买物理服务器到收货需要时间。手动安装操作系统需要时间。安装 App 应用以及对应的环境需要时间。成本非常高。 物理服务器很贵。资源浪费。 如果项目很小，不能充分利用这台服务器的资源。难于迁移和扩展。 如果 CPU，内存，硬盘不够，只能加物理设备，但这个是有上限的。可能会被限定硬件厂商。虚拟化时代为了解决物理设备的诸多问题，出现了虚拟机。虚拟机出现之后大大地降低了部署难度，要想部署一个应用程序，新建一个虚拟机就可以了，还可以根据应用程序的大小，分配合适的系统资源。 虚拟技术有以下几个特点： 一个物理机的资源分配到了不同的虚拟机里。很容易扩展，加物理机 / 虚拟机。很容易云化，阿里云，AWS 等。虚拟化技术实现了物理层的隔离，但却还有以下问题： 每一个虚拟机都是一个完整的操作系统，每次新建都得手动安装一遍。虚拟机中的项目环境每次也需要重新安装。虚拟机本身消耗的系统资源也比较多。容器化时代为了更方便的部署项目，出现了容器化技术，主要有以下几个特点： 实现应用程序及其环境打包。实现应用之间相互隔离、共享同一个操作系统内核。容器本身比较轻，相比虚拟机，占用的系统资源更少。Docker 是容器化技术的一种，也是最流行的一个。Docker 提供了一种隔离机制，它将不同应用程序的依赖项和库打包在一起，运行在不同的容器中，从而实现应用层的隔离。 容器化技术大都是基于 Linux 内核提供的两个机制：Cgroups（实现资源按需分配）和 Namespace（实现任务隔离）。虚拟化 vs 容器化虚拟化和容器化都是目前主流的的部署技术，两者之间的差别如下： 虚拟机技术已经发展了很多年，配套技术和标准都已经标准化了，而容器最近几年才兴起，配套技术和标准还在完善中。虚拟机由于有 GuestOS(虚拟机操作系统) 存在，可以和宿主机运行不同 OS，而容器只能支持和宿主机内核相同的操作系统，隔离性相对较差。容器比虚拟机明显更轻量级，对宿主机操作系统而言，容器就跟一个进程差不多。因此容器有着更快的启动速度、更方便的集群管理等优点。同时由于没有 GuestOS 存在，在容器中运行应用和直接在宿主机上几乎没有性能损失，性能上优于虚拟机。Docker 基础Docker 的核心是在 Docker Engine 层实现应用层的隔离。 Docker 分层Application（应用层）Container（容器层）Docker Engine (隔离层)Host OS 操作系统infrastructure(基础设施)Docker 分为 Client 和 Server 两个部分，我们在 Client 中执行 Docker 命令，最后创建的 Container 和 Image 则会在 Server 中运行。Dcoker 架构如下图所示： ...

本篇博客主要介绍了自动化工具这个概念，在微服务集群当中的作用，算抛砖引玉，欢迎大家提出自己的见解。 写在前面在了解自动化工具的概念之前，我们先了解一下微服务和集群的概念。 什么是微服务这个概念其实有些广泛，而我的知识广度也有限，我会尽量用通俗的语言来描述什么是微服务，什么是集群，以及为什么我们需要微服务集群 。为什么需要集群可以去看看《小强开饭店-从单体应用到微服务》，这篇文章用非常通俗的语言和配图，通过一个漫画故事简单的解释了为什么我们需要微服务集群。 微服务传统的后端服务多为单体应用，例如使用Sprint Boot或者Node又或者Gin搭建的简单的后端服务，在此基础之上，实现了基本的业务之后再部署到服务器上运行起来，这就成为了一个单体应用。 随着业务需求的增加、业务代码慢慢的累加，单体应用变的也越来越大。同时各个模块的大量业务代码相互纠缠在一起，开发以及维护变得尤其困难。想象一下一个刚刚加入项目的新人看到相互纠缠的、逻辑复杂的业务代码的绝望。 这个时候我们就需要了解微服务的概念了。如果想要讲这个庞大的单体应用可维护、可扩展以及高可用，我们就需要对单体应用按照模块进行业务拆分 。 例如将用户相关的所有逻辑单独搞成一个服务，又例如订单、库存可以搞成一个单独的服务。这样一来，业务代码被分散到几个单独的服务中，每个服务只需要关心、处理自己这个模块的业务逻辑。这样一来，业务代码的逻辑清晰，对开发人员来说，条理以及思路都很清晰。即使是后加入的项目开发人员，面对业务逻辑清晰的代码也十分容易上手。 微服务的拆分其实我看到很多的文章关于微服务的介绍就基本到这了，但是还有个值得提的概念。首先，微服务怎么拆分其实是没有一个标准的。 你按照什么样的粒度去拆分你的服务其实是跟业务强相关的。并不是说一个服务的代码一定就很少，根据你的业务的量度，例如你的系统用户量特比的大，那么一个用户服务的代码量上千上万行我觉得都很正常。 当然我也见过用户不是很多，只是为了高可用和快速定位，而将系统拆分的非常细的系统，有好几十个服务。那么问题来了，有这么多服务，前端需要去维护的后端API的地址就相当的庞大了。 我们暂且先不讨论所有拆分的服务是否运行在同一个服务器上，就算是，那也得是不同的端口。前端也需要根据后端拆分的服务模块，去维护这样一张API的映射表。所以我们需要提出一个BFF，AKA Backend For Frontend. BFF其实BFF层最初被提出来，其实不是为了微服务拆分模块中提到的目的。其设计的目的是为了给不同的设备提供不同的API。例如一个系统的后端服务，同时需要支持不同的终端，例如移动端的iOS和Android，PC端。 这样一来，可以根据不同设备上的需求来提供对应的API，而且不需要更改我们现有的微服务。 这样一来，我们的底层服务群就具有了很强的扩展性，我们不需要为一个新增的客户端来更改底层的服务代码，而是新增一层BFF层，来专门针对该终端类型去做适配。 大家从上面的图可以看出来，客户端都没有直接访问我们的底层服务。而是都先经过BFF层提供的接口，再由BFF层来根据不同的路由来调用不同的底层服务。总结一下，加了BFF层的优点如下。 扩展性强，可以适应不同的客户端统一的API管理，客户端无须再维护API的映射表可做集中鉴权，所有的请求都会先经过BFF，可在这一层对调用接口的合法性进行验证当然，BFF也有缺点。 处理不当会有大量的代码冗余因需要调用不同底层的服务而增大开发的工作量当然在实际的生产环境下，我们也很少会将BFF层直接暴露给客户端。我们通常会在BFF层上再加一层网关。网关可以在请求还没有到BFF的时候，实现权限认证，限流熔断等等其他的功能。 集群上面简单的聊了一下什么是微服务，现在我们来聊聊什么是集群。我们知道，当一个单体应用大的已经很难维护的时候，最好的办法就是将其拆分成微服务。这样有什么好处呢？ 便于维护。每个微服务专注于自己这个模块的业务逻辑，不会存在各个模块的业务逻辑缠在一起的状况。提高可用性。当单体应用挂掉的时候，我们系统的所有模块都将不可用。而拆分成微服务就可以尽量的避免这个问题。单个服务挂掉了，不会影响到其他服务的正常运行。便于运维。单体应用重新部署的时候，会使整个系统不可用。而在微服务中，单个服务重新部署的代价明显要小的多。概念说了这么多，我们来给集群一个概念吧。集群就是将同一套服务部署在不同的服务器上，对外提供服务。 例子我举个具体的例子。例如我们使用Docker Swarm来提供容器的集群服务。 在Docker Swarm中有节点这样一个概念，凡是运行了Docker的主机都可以主动的创建一个Swarm集群或者加入一个已经存在的集群，一旦加入，这个主机就成为了这个集群中的一个节点。在集群中节点分为两类，分别是管理节点（manager）和工作节点（worker）。我们可以用Portainer来管理Docker主机和Swarm集群。 我们以一个集群中的请求来举个例子。 首先进入系统之后会先进入一个统一鉴权的系统去鉴权，鉴权成功之后就会到我们的微服务网关，如果这个地方还有系统自己的特殊鉴权的话，再次进行鉴权。之后网关这边会将我们的请求根据配置的路由来分发到具体的某个服务器上的某个容器中。 自动化工具自动化工具的都包含了哪些技术呢？ 其中的Java只是一个类比，代表你的编程语言。微服务中其实不是很关心具体用的什么语言，甚至每个服务都用不同的技术栈都行。 那么自动化工具是什么呢？其作用是什么？在集群中扮演了什么样的角色呢？我们通过一张图来简单的了解一下。 构建简单的梳理一下逻辑。 首先自动化工具将Jenkins构建所需要的参数组织好，调用Jenkins的构建API，并记录构建操作到自动化工具的数据库然后Jenkins用配置好的凭证去Gitlab的对应的项目的分支拉取代码，根据配置好的构建脚本开始构建，记录构建记录到自动化工具的数据库构建好后再推送到docker的仓库中，并记录到自动化工具的数据库到此构建的逻辑结束。 其他的功能自动化工具还可以直接在项目列表中，选择查看当前项目的日志，而不需要每次重新打开Kibana然后再加筛选filter。 自动化工具的项目设置中，我们还可以更改docker容器的配置，而不需要再去portainer中或者通过命令行去修改；如果想要命令行进入容器，首先我们得找到对应的service，然后找到对应运行的service实例，然后才能进入，而如果我们直接使用portainer的Api，在endpoint已知的情况下，可以直接将这个功能做到自动化工具中，直接使用webshell一键连接。 其好处是什么呢？ 对大部分开发屏蔽Swarm集群。对项目中非管理员的开发屏蔽Portainer，因为这个权限非常大，一旦不熟悉导致了误操作，那么有可能直接影响到线上的服务统一权限控制。在自动化工具里做权限以及环境的统一控制上手成本低。比起直接操作portainer和Jenkins和Kibana，自己搭建的自动化工具十分容易上手功能总结总结一下，其功能主要为以下几个。 构建部署回滚查看elk日志更改docker配置管理集群的环境、项目和容器命令行连接具体项目的容器…...看到这大家可能会有疑问。 构建？你的意思是我Jenkins是摆设咯？部署？更改 docker配置？命令行连接具体项目的容器？我的Iterm2也是个摆设？回滚？等于是我之前的docker镜像的tag白打了？elk日志？我的Kibana是拿来看新闻的吗？功能详解构建其实在构建这块，我个人认为自动化工具和Jenkins都很方便。而且自动化工具本身就是用的Jenkins，只不过是调用了Jenkins的API，传递了构建的参数，最终真正去构建的还是Jenkins。 只不过对于刚刚加入项目的测试来说，自己开发的Web UI对新人更加的友好，而且可以在自动化工具中做到权限控制。 部署和回滚部署在自动化工具的后端通过docker-client实现。首先我们根据配置，创建docker client。然后如果已经有在运行的服务了，就调用update service更新服务，否则就创建服务。 回滚与其本质相同，只不过是用了之前的参数和不同的tag。 elk日志首先，每个环境的配置中，会配置上kibana_host以及kibana_index，然后根据系统的projectKey，拼接成相应的Kibana日志的url，然后使用iframe嵌入到自动化工具中。这样一来就不用再手动的打开Kibana再去设置对应的filter了。特别是当你系统特别多的时候，添加和删除filter是很废时间的。 更新容器配置这里也同样是调用对应的API更新对应服务的配置，而不用登录portainer去修改。 同时，在自动化工具中还可以针对不同的环境配置不同的Base Setting。后续在该环境下添加的应用不用再单独配置，直接继承环境的Docker Setting即可。 管理集群的环境、项目和容器可以通过自动化工具统一的来创建和管理环境，同样有三种环境，研发、测试、生产环境。然后可以在自动化工具中创建角色和用户，分配给不同的角色不同的权限来达到控制权限的目的。 命令行连接具体项目的容器通常我们因为某个需求，需要进入到容器中查看，然而此时我们就面临两种选择。 通过portainer进入对应service，找个某个具体的container，点击连接命令行到容器具体运行的某个服务器上，然后再通过命令行连接但是有了自动化工具，我们就有了第三种选择。 点击连接怎么实现的呢？实际上就是通过endpointId去获取到所有的container的信息，然后遍历所有的container，找到与当前选中的containerId相同的容器，获取到其NodeName，这样一来我们就知道当前这个容器到底运行在哪个节点上的了。 然后通过已有的信息，构建WebSocket的url，最后前端通过xterm来建立ws连接，就这样直接连接了正在运行的容器实例。 总结自动化工具只是一种思路，一种解决方案，它的好处在上面也列出了很多。当然，它肯定也有坏处，那就是需要专门投入人力和资源去开发。 ...

什么是DockerDocker 是一个开源的应用容器引擎，基于 Go 语言 并遵从Apache2.0协议开源。Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低.Docker与传统的虚拟机相比有哪些优势呢？ 首先来看传统虚拟机与Docker的对比图： 可以看出传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整操作系统，在该系统上再运行所需应用进程；而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便为什么需要Docker作为一种新兴的虚拟化方式，Docker 跟传统的虚拟化方式相比具有众多的优势对于系统资源的利用更加的高效：由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销，Docker 对系统资源的利用率更高启动时间更快：传统的虚拟机技术启动应用服务往往需要数分钟，而 Docker 容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。一致的运行环境：由于开发环境、测试环境、生产环境不一致，导致有些 bug 并未在开发过程中被发现。而 Docker 的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性，从而不会再出现 「这段代码在我机器上没问题啊」 这类问题。持续交付和部署：对开发和运维（DevOps）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。开发人员可以通过 Dockerfile 来进行镜像构建，并结合 持续集成(Continuous Integration) 系统进行集成测试，而运维人员则可以直接在生产环境中快速部署该镜像，甚至结合持续部署(Continuous Delivery/Deployment) 系统进行自动部署。更轻松的迁移：由于 Docker 确保了执行环境的一致性，使得应用的迁移更加容易。更轻松的维护和扩展：Docker 使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。那么接下来针对Docker的三个基本概念进行了解。 Docker的基本概念Docker 包括三个基本概念: 镜像（ Image ）容器（ Container ）仓库（ Repository ）理解了这三个概念，就理解了 Docker 的整个生命周期。 镜像Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。 分层存储因为镜像包含操作系统完整的 root 文件系统，其体积往往是庞大的，因此在Docker 设计时，就充分利用 Union FS 的技术，将其设计为分层存储的架构。所以严格来说，镜像并非是像一个 ISO 那样的打包文件，镜像只是一个虚拟的概念，其实际体现并非由一个文件组成，而是由一组文件系统组成，或者说，由多层文件系统联合组成。 分层存储的特征还使得镜像的复用、定制变的更为容易。甚至可以用之前构建好的镜像作为基础层，然后进一步添加新的层，以定制自己所需的内容，构建新的镜像。 容器（ Container ）镜像（ Image ）和容器（ Container ）的关系，就像是面向对象程序设计中的类 和 实例 一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。 ...

该文章旨在描述从零开始搭建环境，中间遇到的问题以及最终的经验总结。当前版本针对于2.0 docker安装版 概要整体流程贯通，基本可以达到实用级别。满足2-5台服务器，少量的应用部署是完全可以的，但达到一定规模之后则Walle和Jenkins的差异马上就出来了，Walle的环境管理，服务器管理，上线通知，和各插件集成在这些巨大差距看来难以逾越。而除开Walle本身，整套设计还有不少可以优化的点，例如编译脚本，容器部署等。 Walle仍旧有很多需要提高的地方发布构建时（部署上线）服务器卡顿严重，基本不可以多项目发布。构建队列，不能按队列同时发布多个任务逐一执行并行构建，不能同时执行通过任务自定义脚本，针对非git的项目不友善缺少构建参数，目前仅有git的分支号和提交号，有时候需要传入额外参数作用于启动命令中环境变量，安装较为困难，docker-compose-python中对各环境变量支持不好。（例如angular-cli，使用起来相当别扭）该实战中 - 编译脚本可以优化的地方重复脚本多，可以使用其他方式进行脚本管理，并相互引用。例如直接运行shell,groovy,python等。在环境准备时从git拉去脚本库远程包发布，在无Ansible加持的情况下，远程多服务器发布的效率不可恭维（虽然比人工强）。该实战中 - 容器部署可以优化的地方日志查询难，运行时需要修改为sh方式启动。nohup无法直接使用，导致查询日志时候需要docker log等命令，学习成本较高服务监控难，docker-compose无法胜任大规模集群机器的监控（还是需要k8s啊）该实战中 - 经验分享Docker内openjdk8运行时区不一致：可以直接同宿主机映射时间命令；然后服务启动设置额外参数（参考文章五，java部署篇）Docker-compose启动，则必须用Docker-compose命令停止；否则docker网络无法关闭会超出30个上线后续想当初“docker学起来真麻烦，我又没那么多机器，不管怎么我也不愿意用这些东西”，现在===>“Docker，真香！”PS：最近可能会开一章k8s + SpringCloud部署实战

本章用于讲解如何在walle下构建和运行前端应用。主要包含React,Angular应用，以Nginx+Docker运行（Vue方式不讲，大家自行研究）新建项目项目中心 > 项目管理 > 新建项目以下是一份配置好的项目表 分组项目参考备注基本配置项目名称dev-我的JavaDemo项目随便填写，名称不要太长（不好看），最好把环境卸载最前，例如dev（开发环境）基本配置环境开发环境提前在环境管理配置好即可基本配置Git Repogit@gitlab.xxx.com:xxx/react-demo.gitGit仓库地址目标集群目标集群192.168.0.122提前配置服务器管理目标集群目标集群部署路径/data/walle-build/react-demo实际运行的环境目标集群目标集群部署仓库/data/walle-run会存放多个版本编译后的项目目标集群目标集群部署仓库版本保留数5可以回滚的版本数配置脚本前端生态下基本脚本区别较大，但拥有共通性，此处以Angular为例 基本脚本任务配置 - 部署包含文件包含方式 docker-compose.ymlnginx.confdist该方式用于描述从源码包到发布包中，排除/包含的内容。一般java使用target即可 任务配置 - 自定义全局变量# 运行目录# 运行目录NG_PATH=/data/walle-tool/node-v10.5.0-linux-x64/lib/node_modules/@angular/cli/binPORT=2222ENV=testSERVER_NAME=idp-server-ui-test【Angular to Docker】任务配置 - 高级任务-Deploy前置任务pwdecho "开始初始化"npm install \@angular/cli\@6.0.8 -g || echo "安装失败"任务配置 - 高级任务-Deploy后置任务pwdunzip -q node_modules.zipecho "${NG_PATH}/ng -v"${NG_PATH}/ng -v || echo "环境检查失败"${NG_PATH}/ng build --prod --configuration=${ENV}sed -i 's/${container_port}/'${PORT}'/g' docker-compose.yml sed -i 's/${container_name}/'${SERVER_NAME}'/g' docker-compose.yml 任务配置 - 高级任务-Release前置任务docker-compose -p ${SERVER_NAME} -f ${WEBROOT}/docker-compose.yml down || echo "服务不存在"docker stop ${SERVER_NAME} || echo "服务不存在"docker rm ${SERVER_NAME} || echo "服务不存在"rm -rf ${WEBROOT}任务配置 - 高级任务-Release后置任务docker-compose -p ${SERVER_NAME} up -decho "服务启动完成"项目 - nginx.conf 配置# gzip设置gzip on;gzip_vary on;gzip_comp_level 6;gzip_buffers 16 8k;gzip_min_length 1000;gzip_proxied any;gzip_disable "msie6";#gzip_http_version 1.0;gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;server { listen 80; server_name localhost; #charset koi8-r; #access_log /var/log/nginx/host.access.log main; location / { root /usr/share/nginx/html; index index.html index.htm; # 其作用是按顺序检查文件是否存在，返回第一个找到的文件或文件夹（结尾加斜线表示为文件夹），如果所有的文件或文件夹都找不到，会进行一个内部重定向到最后一个参数。 try_files $uri /index.html; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # #location ~ \.php$ { # root html; # fastcgi_pass 127.0.0.1:9000; # fastcgi_index index.php; # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; # include fastcgi_params; #} # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #}}项目 - docker-compose.yml配置version: '2'services: # 服务名称 nginx: # 镜像:版本 image: nginx:latest container_name: ${container_name} # 映射容器80端口到本地80端口 ports: - "${container_port}:80" # 数据卷 映射本地文件到容器 volumes: # 映射nginx.conf文件到容器的/etc/nginx/conf.d目录并覆盖default.conf文件 - ./nginx.conf:/etc/nginx/conf.d/default.conf # 映射build文件夹到容器的/usr/share/nginx/html文件夹 - ./dist/idp-server-ui:/usr/share/nginx/html # 覆盖容器启动后默认执行的命令。 command: /bin/bash -c "nginx -g 'daemon off;'"环境准备参考文档： https://segmentfault.com/a/11... ...

还在按照mysql安装教程一步一步配置服务配置账户吗？还在为每开一个新环境重新配置这些服务感到苦恼吗？使用Docker，服务快速构建部署。解决你的研发时间，早点下班～现代技术，还不会docker你就落后了。Docker百度百科定义 Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口比较全面的学习网站：https://www.runoob.com/docker... 以下资料来源于www.runoob.com，更多资料请直接访问该网站，侵删。Docker 教程 Docker 是一个开源的应用容器引擎，基于 Go 语言 并遵从Apache2.0协议开源。 Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。 容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。 Docker 从 17.03 版本之后分为 CE（Community Edition: 社区版） 和 EE（Enterprise Edition: 企业版），我们用社区版就可以了。 谁适合阅读本教程？本教程适合运维工程师及后端开发人员，通过本教程你可以一步一步了解 Docker 的使用。 阅读本教程前，您需要了解的知识在阅读本教程前，你需要掌握 Linux 的常用命令。你可以通过本站的 Linux 教程 来学习相关命令。 Docker的应用场景Web 应用的自动化打包和发布。自动化测试和持续集成、发布。在服务型环境中部署和调整数据库或其他的后台应用。从头编译或者扩展现有的OpenShift或Cloud Foundry平台来搭建自己的PaaS环境。Docker 的优点1、简化程序：Docker 让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，便可以实现虚拟化。Docker改变了虚拟化的方式，使开发者可以直接将自己的成果放入Docker中进行管理。方便快捷已经是 Docker的最大优势，过去需要用数天乃至数周的 任务，在Docker容器的处理下，只需要数秒就能完成。2、避免选择恐惧症：如果你有选择恐惧症，还是资深患者。Docker 帮你 打包你的纠结！比如 Docker 镜像；Docker 镜像中包含了运行环境和配置，所以 Docker 可以简化部署多种应用实例工作。比如 Web 应用、后台应用、数据库应用、大数据应用比如 Hadoop 集群、消息队列等等都可以打包成一个镜像部署。3、节省开支：一方面，云计算时代到来，使开发者不必为了追求效果而配置高额的硬件，Docker 改变了高性能必然高价格的思维定势。Docker 与云的结合，让云空间得到更充分的利用。不仅解决了硬件管理的问题，也改变了虚拟化的方式。相关链接Docker 官网：http://www.docker.com Github Docker 源码：https://github.com/docker/docker ...

创建 dockerfileDockerfile PS: 文件名字必须是这样Dockerfile FROM tomcat:8.0COPY index.jsp /usr/local/tomcat/webapps/ROOTEXPOSE 8080index.jsp <%out.println("Hello World, V1");%>build 并测试 The docker build command processes this file generating a Docker Image in your Local Image Cache, which you can then start-up using the docker run command, or push to a permanent Image Repository. docker build 创建一个docker镜像，这个镜像可以在你本地运行。 $docker build -t mytomcat:1.0 .$docker run -p 8080:8080 -d mytomcat:1.0$curl localhost:8080push 到 docker hub注册一个账号 Build image Docker login ...

该文章用于建立一个小型的基于Walle的持续集成工具。解决java,react,angular项目的编译发布。以便对整个持续集成印象加深。官方网站：https://walle-web.io/适用场景小型服务集群（选用Docker-Compose ; 不使用Ansible）简易构建脚本（选用Walle）大规模集群复杂的构建脚本，请学习Jenkins+Ansible+K8S等生态基本思路使用Walle替代Jenkins作为构建方案，简化部分操作。但整体的自定义程度会缺失（例如拉去多git路径进行统一编译，不支持额外构建参数的传入）使用Docker-Compose作为单机容器编排分方案环境使用Gitlab作为代码管理，Nexus作为包私有仓库操作流程研发环境搭建 Gitlab 搭建和基本操作Nexus 搭建（可选）Maven 发布Npm 发布Docker 发布持续集成 Docker 安装和基本操作Walle 安装和基本操作Java 前端项目构建脚本React/Angular 后端项目构建数据流程整体流程会串联整个环境上各技术点，最终形成完整的持续集成方案。 发起构建。配置完各环境发布脚本后，则可以使用构建发起进行触发环境准备。初始化环境参数，例如antd-pro的npm install -g umi或者npm install -g @tarojs/cli@1.2.11Nxues拉取环境相关包。包私有仓库会加速npm install以及mvn compile的下载速度，以及支持私有包的下载代码检出。根据branch的commit进行代码检出操作代码编译。使用mvn clean compile package -Dmaven.test.skip=true or npm run build等编译脚本，或者进行预处理（例如解压node_modules）远程登录。通过shh连接远程服务器本地版本。压缩内容，并发送到远程服务器上打包。并会在远程环境上存放多次发布的版本，用于回退和切换服务停用。进行kill等操作，停止原本运行的服务切换启用。通过软连接替换新的本地版本映射到运行路径，再进行服务启动构建完成。可以进行钉钉或者邮件发送。以上步骤中，在使用Walle的方案下，会集成[代码检出],[远程登录],[本地版本],[切换启用-切换部分],[构建完成]等步骤，且会自动化删除过程文件成果展示项目列表 项目详情 部署管理 部署日志 后记⚠️ 以上虽然看起来很复杂，实际情况下会更为复杂。容我们一步一步的解决各问题。

该文章用于概述一个小型持续集成环境的搭建的方案什么是持续集成？持续集成作为当今软件开发实践，可以简单理解为团队开发相对频繁的集成他们的工作，一般让每个成员每天至少集成一次，而这回造成每天会有多次的版本发布。于是我们需要应用到自动化的构建模式（编译发布到测试监控），从而尽早的发现集成中的错误。 持续集成流程常用生态仓库管理 Git 代码仓库(Gitlab,Gitee)Nexus 包私服库构建工具 Jenkins 热门-构建发布工具Ansible 配置管理工具Walle 构建发布工具运行环境 Linux 系统Docker 容器Nginx 负载均衡域名解析构建环境 mavennodejspythonjava经典流程手工发布 - Java SpringBoot应用到一台服务器特征：一个环境，一台服务，少量应用 1、Maven打包 mvn clean compile package -Dmaven.test.skip=true2、放到服务器 scp -r xxx.jar username@192.168.0.1:/data/app/ or FTP工具3、登录服务器 ssh root@192.168.0.14、停用旧应用 ps -ef | grep java -> kill -9 xxxx4、启用新应用 nohup java -server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -jar /data/app/xxx.jar > /data/app/xxx.log 2>&1 &手工发布 - React-Antdpro 应用到一台服务器特征：一个环境，一台服务，少量应用 1、Npm打包器 npm run build2、放到服务器 本地压缩dist.rar -> scp -r dist.rar username@192.168.0.1:/data/nginx/ or FTP工具 -> 解压内容3、登录服务器 ssh root@192.168.0.14、停用旧应用5、启动新应用 https://segmentfault.com/a/11...延伸问题⚠️ 在低频次小规模更新下，该方案可以在用最少的资源和适度的时间花费上得到平衡。如果出现 多人协作，发布频繁，多台服务，多套环境我们该如何管理这些内容？多人协作，如何代码管理？以及相关依赖引用？以下方案供选择，解决代码管理问题（他们比svn拥有更灵活更开放的管理手段）Gitlab 公网 / 私服Gitee 国内较好的代码仓库管理服务Githubhttps://git-scm.com/ ...

最佳实践原则 指令优化http://assets.processon.com/c...

导语全文搜索是很重要的功能，实现的方式也有很多种。以下通过 Laravel Scout 和 Elasticsearch 实现。先来看下各自的介绍 Laravel Scout 为 Eloquent 模型全文搜索实现提供了简单的、基于驱动的解决方案。通过使用模型观察者，Scout 会自动同步更新模型记录的索引。Elasticsearch是一个基于Lucene库的搜索引擎。它提供了一个分布式、支持多租户的全文搜索引擎，具有HTTP Web接口和无模式JSON文档。Elasticsearch是用Java开发的，并在Apache许可证下作为开源软件发布。官方客户端在Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby和许多其他语言中都是可用的。[5]根据DB-Engines的排名显示，Elasticsearch是最受欢迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene。新建测试数据新建 fake_articles 用来测试 新建模型以及数据迁移 php artisan make:model Models/FakeArticle -m在数据迁移中 database/migrations/2019_06_13_095420_create_fake_articles_table.php 编辑如下public function up(){ Schema::create('fake_articles', function (Blueprint $table) { $table->increments('id'); $table->string('author', 20)->comment('作者'); $table->string('title', 200)->comment('标题'); $table->text('content')->comment('内容'); $table->timestamps(); });}生成数据表 php artisan migrate新建数据填充 php artisan make:seeder FakeArticlesSeeder填充几条中文数据，以便后续测试public function run(){ \App\Models\FakeArticle::insert([ [ 'author' => '王二', 'title' => '黄金时代', 'content' => '那一天我二十一岁，在我一生的黄金时代，我有好多奢望。我想爱，想吃，还想在一瞬间变成天上半明半暗的云，后来我才知道，生活就是个缓慢受锤的过程，人一天天老下去，奢望也一天天消逝，最后变得像挨了锤的牛一样。可是我过二十一岁生日时没有预见到这一点。我觉得自己会永远生猛下去，什么也锤不了我。', 'created_at' => now(), 'updated_at' => now(), ], ['author' => '陈辉', 'title' => '绿毛水怪', 'content' => '大团的蒲公英浮在街道的河流口，吞吐着柔软的针一样的光，我们好像在池塘的水底，从一个月亮走向另一个月亮。', 'created_at' => now(), 'updated_at' => now(), ], ['author' => '迅哥', 'title' => '社戏', 'content' => '两岸的豆麦和河底的水草所发散出来的清香，夹杂在水气中扑面的吹来；月色便朦胧在这水气里。淡黑的起伏的连山，仿佛是踊跃的铁的兽脊似的，都远远的向船尾跑去了，但我却还以为船慢。他们换了四回手，渐望见依稀的赵庄，而且似乎听到歌吹了，还有几点火，料想便是戏台，但或者也许是渔火。', 'created_at' => now(), 'updated_at' => now(), ] ]);}运行填充 php artisan db:seed --class=FakeArticlesSeeder搭建 Elasticsearch 容器laradock 中支持 Elasticsearch，直接搭建就可以，省去了诸多麻烦 ...

题外话　最近对Docker和Kubernetes进行了一番学习，前两天做了一次技术分享，回去听了一遍自己演讲的录音，发现单单PPT做好还是远远不够的，没有提前准备好逻辑严谨的讲稿，在讲的时候出现了卡壳、漏掉技术点、逻辑矛盾的问题。为了解决这个问题，我打算以后在做技术分享前，都按着PPT的内容先写成博客，理顺表达逻辑。另外，我觉得每次技术分享使用的PPT都应该尽可能的做好，因为你不知道未来会不会还要拿来再讲几遍。本文以PPT+讲稿的方式编写，权当对自己这次技术分享做个记录，欢迎大家拍砖。 1. Docker出现的背景　在平常的研发和项目场景中，以下情况普遍存在： 个人开发环境 为了做大数据相关项目，需要安装一套CDH集群，常见的做法是在自己电脑里搭建3台与CDH版本对应的虚拟机，把CDH集群装起来后，考虑到以后很有可能还要使用一个干净的CDH集群，为了避免以后重复安装环境，通常会对整套CDH集群做一个备份，这样电脑里就有6个虚拟机镜像了。另外，后面在学习其他技术时，比如学习Ambari大数据集群，那么为了不破坏已有的虚拟机环境，又要重新搭建3台虚拟机，本机磁盘很快被一大堆的虚拟机镜像占满。公司内部开发环境 公司里往往会以小团队的方式来做项目，一般由运维部门从他们管理的服务器资源中分配出虚拟机供团队内部开发测试使用。比如做一个与机器学习相关的项目： 小明在运维部门分配的虚拟机上搭建了一套Ambari集群，拿来跑大数据相关业务小刚用python3写了一个机器学习算法，放到虚拟机上运行发现虚拟机里是python2，算法不兼容，于是把虚拟机里的python版本升级了，算法跑通了，但Ambari用到python的部分功能可能就报错了小李开发了应用，放到虚拟机上启动tomcat，发现虚拟机里的是OpenJDK，导致tomcat起不来，于是又安装了一个JDK，这时候可能Ambari里的Java代码可能就报错了小赵想利用服务器资源做性能测试，发现虚拟机严重削减了性能，最终还是要直接找物理机来跑测试，破坏了物理机原来的环境做完项目后，这些虚拟机上安装的东西往往变得没用了，下个项目组来还是得新申请虚拟机重新部署软件开发/测试/现场环境研发人员在开发环境里写好了代码做好测试后，提交给测试部门，测试人员在测试环境跑起来发现有BUG，研发人员说在开发环境没这个BUG，和测试人员多次扯皮解决BUG后发布版本，发到现场在生产环境部署后，又发现有BUG，这下轮到工程人员和测试人员扯皮。有时候为了兼容特殊的现场环境，还需要对代码进行定制化修改，拉出分支，这样导致了每次到现场升级都是一场噩梦升级或迁移项目 在每次发版本要升级到现场时，如果现场起了多个tomcat应用，那么需要对每个tomcat都先停掉，替换war包，然后再起起来，轮流着做，不仅繁琐而且很容易出错，如果遇到升级后出现严重BUG，还要手工做回退。另外，如果项目想上云，那么在云上部署后要重新进行一轮测试，如果后面考虑还云厂商，可能相同的测试还要再进行一次（比如更换了数据存储组件），费时费力。　总结以上列举的所有场景，他们存在的一个共同的问题是：没有一种既能够屏蔽操作系统差异，又能够以不降低性能的方式来运行应用的技术，来解决环境依赖的问题。Docker应运而生。 2. Docker是什么 Docker是一种应用容器引擎。首先说一下何为容器，Linux系统提供了Namespace和CGroup技术实现环境隔离和资源控制，其中Namespace是Linux提供的一种内核级别环境隔离的方法，能使一个进程和该进程创建的子进程的运行空间都与Linux的超级父进程相隔离，注意Namespace只能实现运行空间的隔离，物理资源还是所有进程共用的，为了实现资源隔离，Linux系统提供了CGroup技术来控制一个进程组群可使用的资源（如CPU、内存、磁盘IO等），把这两种技术结合起来，就能构造一个用户空间独立且限定了资源的对象，这样的对象称为容器。Linux Container是Linux系统提供的容器化技术，简称LXC，它结合Namespace和CGroup技术为用户提供了更易用的接口来实现容器化。LXC仅为一种轻量级的容器化技术，它仅能对部分资源进行限制，无法做到诸如网络限制、磁盘空间占用限制等。dotCloud公司结合LXC和以下列出的技术实现了Docker容器引擎，相比于LXC，Docker具备更加全面的资源控制能力，是一种应用级别的容器引擎。 Chroot：该技术能在container里构造完整的Linux文件系统；Veth：该技术能够在主机上虚拟出一张网卡与container里的eth0网卡进行桥接，实现容器与主机、容器之间的网络通信；UnionFS：联合文件系统，Docker利用该技术“Copy on Write”的特点实现容器的快速启动和极少的资源占用，后面会专门介绍该文件系统；Iptables/netfilter：通过这两个技术实现控制container网络访问策略；TC：该技术主要用来做流量隔离，限制带宽；Quota：该技术用来限制磁盘读写空间的大小；Setrlimit：该技术用来限制container中打开的进程数，限制打开的文件个数等也正是因为Docker依赖Linux内核的这些技术，至少使用3.8或更高版本的内核才能运行Docker容器，官方建议使用3.10以上的内核版本。3. 与传统虚拟化技术的区别 传统的虚拟化技术在虚拟机（VM）和硬件之间加了一个软件层Hypervisor，或者叫做虚拟机管理程序。Hypervisor的运行方式分为两类： 直接运行在物理硬件之上。如基于内核的KVM虚拟机，这种虚拟化需要CPU支持虚拟化技术；运行在另一个操作系统。如VMWare和VitrualBox等虚拟机。　因为运行在虚拟机上的操作系统是通过Hypervisor来最终分享硬件，所以虚拟机Guest OS发出的指令都需要被Hypervisor捕获，然后翻译为物理硬件或宿主机操作系统能够识别的指令。VMWare和VirtualBox等虚拟机在性能方面远不如裸机，但基于硬件虚拟机的KVM约能发挥裸机80%的性能。这种虚拟化的优点是不同虚拟机之间实现了完全隔离，安全性很高，并且能够在一台物理机上运行多种内核的操作系统（如Linux和Window），但每个虚拟机都很笨重，占用资源多而且启动很慢。 Docker引擎运行在操作系统上，是基于内核的LXC、Chroot等技术实现容器的环境隔离和资源控制，在容器启动后，容器里的进程直接与内核交互，无需经过Docker引擎中转，因此几乎没有性能损耗，能发挥出裸机的全部性能。但由于Docker是基于Linux内核技术实现容器化的，因此使得容器内运行的应用只能运行在Linux内核的操作系统上。目前在Window上安装的docker引擎其实是利用了Window自带的Hyper-V虚拟化工具自动创建了一个Linux系统，容器内的操作实际上是间接使用这个虚拟系统实现的。 4. Docker基本概念 Docker主要有如下几个概念： 引擎：创建和管理容器的工具，通过读取镜像来生成容器，并负责从仓库拉取镜像或提交镜像到仓库中；镜像：类似于虚拟机镜像，一般由一个基本操作系统环境和多个应用程序打包而成，是创建容器的模板；容器：可看作一个简易版的Linxu系统环境（包括root用户权限、进程空间、用户空间和网络空间等）以及运行在其中的应用程序打包而成的盒子；仓库：集中存放镜像文件的场所，分为公共仓库和私有仓库，目前最大的公共仓库是官方提供的Docker Hub，此外国内的阿里云、腾讯云等也提供了公共仓库；宿主机：运行引擎的操作系统所在服务器。5. Docker与虚拟机、Git、JVM的类比　为了让大家对Docker有更直观的认识，下面分别进行三组类比： 上图中Docker的镜像仓库类似于传统虚拟机的镜像仓库或存放镜像的本地文件系统，Docker引擎启动容器来运行Spark集群（容器内包含基础的Linux操作系统环境），类比于虚拟机软件启动多个虚拟机，在虚拟机内分别运行Spark进程，两者区别在于Docker容器内的应用在使用物理资源时，直接与内核打交道，无需经过Docker引擎。 Docker的仓库思想与Git是相同的。 Docker的口号是“Build，Ship，and Run Any App，Anywhere”，也就是可以基于Docker构建、装载和运行应用程序，一次构建到处运行。Java的口号是“Write Once,Run Anywhere”，即一次编写到处运行。Java是基于JVM适配操作系统的特点来屏蔽系统的差异，Docker则是利用内核版本兼容性的特点来实现一次构建导出运行，只要Linux系统的内核是3.8或更高的版本，就都能把容器跑起来。 当然，正如Java中如果应用代码使用了JDK10的新特性，基于JDK8就无法运行一样，如果容器内的应用使用了4.18版本的内核特性，那么在CentOS7（内核版本为3.10）启动容器时，虽然容器能够启动，但里面应用的功能是无法正常运行的，除非把宿主机的操作系统内核升级到4.18版本。6. Docker镜像文件系统 Docker镜像采用分层存储格式，每个镜像可依赖其他镜像进行构建，每一层的镜像可被多个镜像引用，上图的镜像依赖关系，K8S镜像其实是CentOS+GCC+GO+K8S这四个软件结合的镜像。这种分层结构能充分共享镜像层，能大大减少镜像仓库占用的空间，而对用户而言，他们所看到的容器，其实是Docker利用UnionFS（联合文件系统）把相关镜像层的目录“联合”到同一个挂载点呈现出来的一个整体，这里需要简单介绍一个UnionFS是什么： UnionFS可以把多个物理位置独立的目录（也叫分支）内容联合挂载到同一个目录下，UnionFS允许控制这些目录的读写权限，此外对于只读的文件和目录，它具有“Copy on Write（写实复制）”的特点，即如果对一个只读的文件进行修改，在修改前会先把文件复制一份到可写层（可能是磁盘里的一个目录），所有的修改操作其实都是对这个文件副本进行修改，原来的只读文件并不会变化。其中一个使用UnionFS的例子是：Knoppix，一个用于Linux演示、光盘教学和商业产品演示的Linux发行版，它就是把一个CD/DVD和一个存在在可读写设备（例如U盘）联合挂载，这样在演示过程中任何对CD/DVD上文件的改动都会在被应用在U盘上，不改变原来的CD/DVD上的内容。　UnionFS有很多种，其中Docker中常用的是AUFS，这是UnionFS的升级版，除此之外还有DeviceMapper、Overlay2、ZFS和 VFS等。Docker镜像的每一层默认存放在/var/lib/docker/aufs/diff目录中，当用户启动一个容器时，Docker引擎首先在/var/lib/docker/aufs/diff中新建一个可读写层目录，然后使用UnionFS把该可读写层目录和指定镜像的各层目录联合挂载到/var/lib/docker/aufs/mnt里的一个目录中（其中指定镜像的各层目录都以只读方式挂载），通过LXC等技术进行环境隔离和资源控制，使容器里的应用仅依赖mnt目录中对应的挂载目录和文件运行起来。 利用UnionFS写实复制的特点，在启动一个容器时， Docker引擎实际上只是增加了一个可写层和构造了一个Linux容器，这两者都几乎不消耗系统资源，因此Docker容器能够做到秒级启动，一台服务器上能够启动上千个Docker容器，而传统虚拟机在一台服务器上启动几十个就已经非常吃力了，而且虚拟机启动很慢，这是Docker相比于传统虚拟机的两个巨大的优势。 当应用只是直接调用了内核功能来运作的情况下，应用本身就能直接作为最底层的层来构建镜像，但因为容器本身会隔绝环境，因此容器内部是无法访问宿主机里文件的（除非指定了某些目录或文件映射到容器内），这种情况下应用代码就只能使用内核的功能。但是Linux内核仅提供了进程管理、内存管理、文件系统管理等一些基础且底层的管理功能，在实际的场景中，几乎所有软件都是基于操作系统来开发的，因此往往都需要依赖操作系统的软件和运行库等，如果这些应用的下一层直接是内核，那么应用将无法运行。所以实际上应用镜像往往底层都是基于一个操作系统镜像来补足运行依赖的。 Docker中的操作系统镜像，与平常安装系统时用的ISO镜像不同。ISO镜像里包含了操作系统内核及该发行版系统包含的所有目录和软件，而Docker中的操作系统镜像，不包含系统内核，仅包含系统必备的一些目录（如/etc /proc等）和常用的软件和运行库等，可把操作系统镜像看作内核之上的一个应用，一个封装了内核功能，并为用户编写的应用提供运行环境的工具。应用基于这样的镜像构建，就能够利用上相应操作系统的各种软件的功能和运行库，此外，由于应用是基于操作系统镜像来构建的，就算换到另外的服务器，只要操作系统镜像中被应用使用到的功能能适配宿主机的内核，应用就能正常运行，这就是一次构建到处运行的原因。 ...

欢迎关注个人微信公众号: 小哈学Java, 每日推送 Java 领域干货文章，关注即免费无套路附送 100G 海量学习、面试资源哟！！个人网站: https://www.exception.site/docker/how-to-config-ssl-with-docker-nginx 一、背景小哈最近收到阿里云短信，提示个站 www.exception.site 的云盾 SSL 证书(Https 证书)即将到期，需要赶快续费，不然无法继续使用 Https 协议来访问网站！ 这个 SSL 证书当时用的是阿里云免费型的，有效期为 1 年，到期后, 如果想继续使用这个证书，就得续费，而且费用还不低！ 其实，要想继续使用 Https 协议，我们可以在阿里云上再次申请一张 SSL 证书就可以了，时间一年，嗨呀，又能免费用一年。 本文小哈就主要介绍如何在 Ngnix 上配置 SSL 证书，从而让我们的网站能够使用 Https 来访问，另外再附带说一下如何配置反向代理。 二、Docker 快速安装&搭建 Ngnix 环境小哈的个站 Ngnix 搭建在容器当中，也就顺便说一下如何通过 Docker 快速安装&搭建 Ngnix 环境。 2.1 下载 Nginx 镜像docker pull nginx:alpinePS：我这里用的是 alipne 轻量级的镜像.下载完成后，通过 docker images 命令检查一下镜像是否下载成功： 2.2 先以简单的方式运行镜像docker run -d -p 80:80 --name nginx nginx:alpine-p 80:80: 将容器的 80 端口映射到宿主机的 80 端口上；-d: 以后台方式运行镜像；--name: 指定容器的名称为 nginx;命令执行完成后，通过 docker ps命令确认一下容器是否启动成功。确认成功后，再访问一下 80 端口，看看 nginx 服务是否启动成功： ...

URLOS本是基于docker容器运行，在入门URLOS开发之前，我们首先需要掌握docker的相关基础知识，本篇就以docker容器的基本使用方法为例，快速的让大家对docker有一个全面的印象。 Docker简介Docker 是一个开源的应用容器引擎，基于Go语言并遵从Apache2.0协议开源。 Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。 容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。 Ubuntu Docker 安装1、Docker官方安装方法Docker 要求 Ubuntu 系统的内核版本高于 3.10 ，查看本页面的前提条件来验证你的 Ubuntu 版本是否支持 Docker。 获取安装包： root@ubuntu:~# wget -qO- https://get.docker.com/ | sh安装完成后有提示： If you would like to use Docker as a non-root user, you should now consider adding your user to the "docker" group with something like: sudo usermod -aG docker runoob Remember that you will have to log out and back in for this to take effect! 启动docker服务 ...

RUN、CMD和ENTRYPOINT命令解释RUN 执行命令并创建新的Image LayerCMD 设置容器启动后默认执行的命令和参数ENTRYPOINT 设置容器启动时运行的命令执行方式EXEC FROM debianRUN ['apt-get','install','-y','vim']CMD ['/bin/echo','hello world!!']ENTRYPOINT ['/bin/echo','hello world!!']SHELL FROM debian RUN apt-get install -y vim CMD echo 'hello world!!' ENTRYPOINT echo 'hello world!!'注意事项使用run命令构建镜像时apt-get update && apt-get install -y需要放在同一个RUN命令中，否则apt-get install会从缓存中安装软件，导致apt-get update执行毫无意义apt-get install 的软件尽量一个一行并且按照字母顺序排列,这样可以避免安装重复的命令apt-get install安装软件时可以为软件指定特定的版本apt-get install -y aufs-tools s3cmd=1.1.*命令差异CMD 容器启动时默认执行的命令docker run 指定了其他命令，CMD会被忽略如果定义了多个CMD，只有最后一个会执行ENTRYPOINT 让容器以运用程序或者服务的形式运行不会被忽略，一定会执行最佳实践，写一个shell脚本作为entrypointCOPY ./script/test.sh /usr/local/binENTRYPOINT ['test.sh']

导语在本地安装 Laravel Dusk 一直失败，查了文档才发现在 laradock 中并不是只需要 composer require 就可以的，还有其他配置。下面记录一下。 配置 laradock切换到 laradock 目录中，将 workspace 容器先暂停 docker-compose sotp workspace修改 .env 文件中的 WORKSPACE_INSTALL_LARAVEL_INSTALLER 和 WORKSPACE_INSTALL_DUSK_DEPS，将配置值改为 true重新搭建 workspace 容器 docker-compose build workspace成功之后启动 docker-compose up -d workspace安装 Laravel Dusk进入到 workspace 容器中 docker-compose exec workspace bash，并且切换到项目目录中使用 composer require --dev laravel/dusk 安装 Laravel Dusk执行 php artisan dusk:install在 tests/DuskTestCase.php 文件中，修改 driver 方法，添加 —-no-sandbox 参数，如下protected function driver(){ $options = (new ChromeOptions)->addArguments([ '—disable-gpu', '—headless', '—window-size=1920,1080', '—no-sandbox',// 添加这行 ]); return RemoteWebDriver::create( 'http://localhost:9515', DesiredCapabilities::chrome()->setCapability( ChromeOptions::CAPABILITY, $options ) );}添加一个配置文件，cp .env .env.dusk.local，将 APP_URL 修改为 http://localhost:8000执行 php artisan serve —-quiet &最后可以使用 Laravel Dusk 进行测试了 php artisan dusk结语其实在 workspace 中有很多 alias 可是使用，为了便于理解，都是用了原命令。关于 Laravel Dusk 的使用，可以参考这个教程，其中不止关于测试的部分，其他部分很好。 ...

搜索镜像docker search redis 拉取镜像docker pull redis 启动容器，这里有些时候需要指定配置文件mkdir -pv /home/docker/redis && cd /home/docker/rediswget https://raw.githubusercontent... -O conf/redis.confdocker run -p 6379:6379 --name myredis -v $PWD/conf/redis.conf:/etc/redis/redis.conf -d redis redis-server 或者不指定配置文件docker run -p 6379:6379 --name myredis -d redis redis-server /etc/redis/redis.conf redis-cli连接docker run -it --link myredis:redis --rm redis redis-cli -h redis -p 6379

业界要闻Docker 基础镜像 Alpine 爆出提权漏洞（CVE-2019-5021）：该CVE影响自 Alpine Linux 3.3 版本开始的所有 Docker 镜像。该漏洞的机制在于 Alpine 的 root 用户包含一个空密码，这可能会导致攻击者获得 root 权限，进而造成攻击。报告中称：受影响范围是 Alpine Linux Docker 镜像 3.3、3.4、3.5、3.6、3.7、3.8、3.9、edge 等全部版本。目前，整个容器技术生态中很多项目的基础镜像层都在采用Alpine。在漏洞披露后，Alpine 最新版已经修复了该问题，用户可以使用3.9.4版本来规避风险。这里也可以参考一些开源项目更换其他基础镜像，例如 kubernetes-csi 项目的这个PR。Docker 项目本身爆出严重漏洞，攻击者可以直接访问宿主机文件系统（CVE-2018-15664）： 5 月 29 日，来自 SUSE 的 Linux 工程师 Aleksa Sarai 汇报了这个漏洞。他指出，在某些情况下，攻击者可以在 docker cp 进行文件路径解析和执行文件操作之间的短时间窗口将自己的符号链接（symlink）插入到路径中，从而在容器中以 root 的身份直接拿到宿主机文件的符号链接，在 docker cp 的场景下，这等同于直接拿到了宿主机任意文件的读写权限。可以看到，这个漏洞是 TOCTOU 攻击的一个典型变体，利用了 Linux 操作文件时候的竞争状态（race condition）。虽然它有可能影响所有 Docker 版本， Docker 官方出台了补丁计划，会在后续版本包含相应修复补丁。此次漏洞的攻击前提是攻击者拥有docker cp命令的使用权限，阿里云容器服务集群默认开启了基于RBAC的访问控制，非法用户是没有cp命令在容器内的访问权限的。作为用户，最安全的方法是禁止在多租环境下启用 docker cp 操作，并且将 Docker Daemon 通过 apparmor 等手段进行限制。万幸的是，这个漏洞的利用方法是非常复杂的，需要构造出上述文件竞态才能产生作用。更多详细内容，请参见阿里专家的CVE-2018-15664漏洞分析报告。上游重要进展Kubernetes 从 v1.15 开始将采用 go module 来进行包管理。相比于原来的 Godeps，go module 在打包、编译等多个环节上有着明显的速度优势，并且能够在任意操作系统上方便的复现依赖包。更重要的是，go module 本身的设计使得 Kubernetes 自身被其他项目引用变得更加容易，这也是 Kubernetes 项目向框架化演进的又一个重要体现。Envoy正在Redis Proxy中实现request mirror功能，用于对请求做镜像。该功能可以指定只对固定百分比的流量做镜像，且可以将read相关的请求给过滤掉。Envoy正增加路由debug的功能。通过这一功能，可掌握所发起的一个调用能否正常地路由出去，以及路由到了哪个集群。虽然社区已经提供了route table checker这一工具，但该工具只能用于检查静态路由，对于通过xDS下发的动态路由则无能为力，路由debug功能正是瞄准动态路由的。Knative 社区正在探索stateful-serverless，实验性项目由lightbend公司开发（著名产品akka），期望在knative中建立一个有状态的服务，主要依赖akka cluster加一个持久化的数据库，可以将请求分配给固定的容器。演示视频：演示了一个计数器服务，另附 KubeCon 上的演讲视频Eventing Security Requirements： 针对事件在数据平面的安全性的需求，knative提出了概要设计，主要定义事件处理的 3 个安全策略边界及对应的安全策略： ...

欢迎关注个人微信公众号: 小哈学Java, 文末分享阿里 P8 高级架构师吐血总结的 《Java 核心知识整理&面试.pdf》资源链接！！个人网站: https://www.exception.site/docker/docker-install-nginx 本节中，我们将学习如何通过 Docker 快速安装&搭建 Ngnix, 为您的服务添加反向代理功能。 一、下载 Nginx 镜像docker pull nginx:alpinePS：我这里用的是 alipne 轻量级的镜像.下载完成后，通过 docker images 命令检查一下镜像是否下载成功： 二、先以简单的方式运行镜像docker run -d --name nginx nginx:alpine-d: 以后台方式运行镜像；—name: 指定容器的名称为 nginx;命令执行完成后，通过 docker ps命令确认一下容器是否启动成功。确认成功后，再访问一下 80 端口，看看 nginx 服务是否启动成功： 三、复制相关配置文件至宿主机复制运行中 nginx 相关配置文件到宿主机的指定路径下： # 复制名称为 nginx 容器中 /etc/nginx/nginx.conf 文件夹到宿主机的 /docker/nginx 路径下docker cp nginx:/etc/nginx/nginx.conf /docker/nginx# 复制名称为 nginx 容器中 /etc/nginx/conf.d 文件到宿主机的 /docker/nginx 路径下docker cp nginx:/etc/nginx/conf.d /docker/nginx复制完成后，查看指定路径的配置文件，如下： 四、修改 Nginx 配置文件，添加反向代理先通过命令 ifconfig 命令获取 docker0网卡的 ip 地址： ...

前言Kubernetes（k8s） 凭借着其优良的架构，灵活的扩展能力，丰富的应用编排模型，成为了容器编排领域的事实标准。越来越多的企业拥抱这一趋势，选择 k8s 作为容器化应用的基础设施，逐渐将自己的核心服务迁移到 k8s 之上。 可用性对基础设施而言至关重要。各大云计算厂商纷纷推出了高可用、可扩展的 k8s 托管服务，其中比较有代表性的有 Amazon EKS、Azure Kubernetes Service (AKS)、Google Kubernetes Engine、阿里云容器服务 Kubernetes 版等。 虽然公有云托管的 k8s 服务百花齐放，但很多企业仍有自建集群的需求。正是这样的原因，促进了一大批出色的 k8s 集群部署方案的诞生，他们的特点如下表所示。 部署方案特点Kubeadm1. 官方出品的部署工具，提供了 k8s 集群生命周期管理的领域知识。2. 旨在成为更高级别工具的可组合构建块。 Kubespray1. 支持在裸机和 AWS、GCE、Azure 等众多云平台上部署 k8s。2. 基于 Ansible Playbook 定义 k8s 集群部署任务。3. 支持大部分流行的 Linux 发行版。 || Kops | 1. 仅支持在 AWS、GCE 等少数云平台上部署 k8s。2. 建立在状态同步模型上，用于 dry-run 和自动幂等性。3. 能够自动生成 Terraform 配置。 || Rancher Kubernetes Engine（RKE） | 1. 著名的开源企业级容器管理平台 Rancher 提供的轻量级 k8s 安装工具。2. 支持在裸机、虚拟机、公有云上部署和管理 k8s 集群。 | ...

本文档以构建一个 Java 软件项目并部署到 阿里云容器服务的Kubernetes集群 为例说明如何使用 Bamboo在阿里云Kubernetes服务上运行Remote Agents并在agents上运行Build Plans。 1. 源码项目本示例中创建的GitHub源码项目地址为： https://github.com/AliyunContainerService/jenkins-demo.git 分支为: bamboo2. 在Kubernetes中部署Remote Agent2.1 创建kaniko-docker-cfg secret kaniko-docker-cfg secret用于Remote Agent上构建任务使用kaniko推送容器镜像时的权限配置 kubectl -n bamboo create secret generic kaniko-docker-cfg --from-file=/root/.docker/config.json上面命令中的/root/.docker/config.json，是在linux服务器上使用root用户通过以下命令生成的： docker login registry.cn-hangzhou.aliyuncs.com2.2 创建serviceaccount bamboo以及clusterrolebinding用于kubectl部署应用到kubernetes集群的权限设置，创建bamboo-agent deployment 注意： 本示例中的clusterrolebinding为admin权限， 具体使用中可以根据自己的需要创建最小权限的serviceaccount bamboo-agent.yaml: ---apiVersion: v1kind: ServiceAccountmetadata: namespace: bamboo name: bamboo---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: bamboo-cluster-adminsubjects: - kind: ServiceAccount name: bamboo namespace: bambooroleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io---apiVersion: apps/v1beta2kind: Deploymentmetadata: name: bamboo-agentspec: replicas: 1 selector: matchLabels: app: bamboo-agent template: metadata: labels: app: bamboo-agent spec: serviceAccountName: bamboo containers: - name: bamboo-agent env: - name: BAMBOO_SERVER_URL value: http://xx.xx.xx.xx:8085 image: registry.cn-hangzhou.aliyuncs.com/haoshuwei/docker-bamboo-agent:v1 imagePullPolicy: Always volumeMounts: - mountPath: /root/.docker/ name: kaniko-docker-cfg volumes: - name: kaniko-docker-cfg secret: secretName: kaniko-docker-cfgkubectl -n bamboo apply -f bamboo-agent.yaml上述kubernetes资源创建完毕后等待remote agent完成初始化配置， 可以使用如下命令查看日志： ...

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。KubeCon EU 举办2019 年第一个 KubeCon + CloudNativeCon 于 5 月 20 ~ 23 日在巴塞罗那成功举办，这次大会吸引了七千多名参会者远超去年的参会人数。 这也从另一个侧面反映了 Kubernetes 和云原生在大大的普及 在大会上宣布了不少值得关注的信息, 我在此大致列一下我认为值得关注的信息（虽然有些内容之前已经关注到了）： OpenTracing, OpenCensus 合并为 OpenTelemetry；微软推出 Service Mesh Interface（SMI）规范；NGINX Ingress Controller 发布 1.5.0 版本；Google 宣布 GKE 将会支持 Windows Server Container；Helm 3 的发展历程；（推荐阅读我之前写的 初试 Helm 3）当然，大会上公布的信息还有很多，还有一些 CNCF 的计划等，这里暂且不提，感兴趣的朋友可以自行搜索或者参加下个月在上海举办的 KubeCon + CloudNativeCon 微软推出 Service Mesh Interface （SMI）Service Mesh 也是一个趋势，但现在并没有一个统一的规范，各个厂商的实现也都各有不同。微软本次提出的 SMI 主要是为 Kubernetes 服务网格提供通用接口，以便能让 Service Mesh 有更加通用的规范 （就像当初 CNI/CRI 那样子） ...

感谢 & 参考本文内容还是相对很浅的，Docker中关于分布式，集群的内容没有涉及，所以本文推荐前端同学看一看，后端同学就不推荐了。本文中所有命令都是针对Ubuntu16.04，拷贝粘贴时请注意。(这一篇文章有些复读机????，对docker感兴趣的可以直接看以下的参考资料) 本文主要参考了以下资料 docker docs docker官方文档Docker入门学习笔记Docker — 从入门到实践DockerInfoDocker学习路线图（配基于阿里云容器服务实践教程）命令汇总命令汇总，方面快速查询 # 创建镜像docker build -t [镜像名] .# Docker镜像列表docker image ls# 删除镜像docker rmi [id]# 删除所有的镜像docker image rm $(docker image ls -a -q)# Docker容器列表docker container lsdocker container ls --all# 全部的停止的容器docker container ls -aq# 删除容器docker rm [id]# 删除所有的容器docker container rm $(docker container ls -a -q)# 停止容器docker container stop [id]# 启动停止的容器docker container start [id]# 强制关闭指定容器docker container kill [id]# 重启容器docker container restart [id]# 进入容器内部docker exec -it [容器id] bash# 运行容器，外部的4000端口映射到容器的80端口docker run -p 4000:80 hello# 指定容器的名称 --namedocker run --name [name] -p 4000:80 [image]# 守护态运行容器（后台运行，不需要在打开一个终端）docker run -d -p 4000:80 hello# 随机映射本机的端口到容器的端口docker run -d -P [image]# 映射所有的地址docker run -d -p [宿主机端口]:[容器端口] [image]# 映射指定地址以及端口docker run -d -p [ip]:[宿主机端口]:[容器端口] [image]# 映射指定地址的任意端口docker run -d -p [ip]::[容器端口] [image]# 查看容器映射的端口docker port [容器名|容器id] [容器的端口]# 标记镜像docker tag [镜像名] [用户名]/[存储库]:[标签]# 上传镜像到DockerHubdocker push [用户名]/[存储库]:[标签]# 从DockeerHub上获取镜像docker pull [存储库]:[标签]# 从存储库运行镜像docker run -p [用户名]/[存储库]:[标签]# 创建数据卷docker volume create [数据卷名称]# 查看所有的数据卷docker volume ls# 查看数据卷的信息docker volume inspect [数据卷名称]# 删除数据卷docker volume rm [数据卷名称]# 清理无主的数据卷docker volume prune# 查看网络列表docker network lsDocker的基本概念 ...

使用docker搭建项目创建项目目录 mkdir php创建如下项目结构sites 目录放置项目文件services 目录放置服务相关配置script 放置自定义脚本├── Readme.md├── docker-compose.yml├── script├── services│   ├── mariadb│   │   └── Dockerfile│   ├── nginx│   │   ├── Dockerfile│   │   ├── conf.d│   │   │   └── default.conf│   │   └── nginx.conf│   ├── php│   │   └── Dockerfile│   └── redis│   └── Dockerfile└── sites ├── index.html └── index.php8 directories, 10 files编辑docker-compose文件version: "3"services: php: build: ./services/php # ports: # - "9001:9000" container_name: lnmp-php restart: always volumes: - ./sites:/www networks: lnmp_net: ipv4_address: 101.11.11.10 nginx: build: ./services/nginx ports: - "81:80" - "444:443" container_name: lnmp-nginx restart: always volumes: - ./sites:/www - ./services/nginx/nginx.conf:/etc/nginx/nginx.conf - ./services/nginx/conf.d:/etc/nginx/conf.d:rw networks: lnmp_net: ipv4_address: 101.11.11.11networks: lnmp_net: driver: bridge ipam: config: - subnet: 101.11.11.0/20编辑services/nginx文件FROM nginx:1.17.0-alpine# 更新安装源RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories# 设置时区为上海RUN apk update && apk add --upgrade \ && apk add tzdata \ && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ && echo "Asia/Shanghai" > /etc/timezone \ && apk del tzdata编辑services/php文件FROM php:7.3.6-fpm-alpine3.9# 更新安装源RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories# 设置时区为上海RUN apk update && apk add --no-cache tzdata autoconf gcc g++ make zlib-dev curl-dev\ && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ && echo "Asia/Shanghai" > /etc/timezone \ && apk del tzdata \ && docker-php-ext-install mysqli pdo_mysql opcache \ && pecl install grpc protobuf xdebug yaf yar swoole \ && docker-php-ext-enable xdebug yaf yar swoole grpc protobuf 以上我们的lnmp环境基本搭建完毕，下面我们针对Php解析做相关的配置修改services/nginx/nginx.conf,可根据需求自行修改user nginx;worker_processes auto;error_log /var/log/nginx/error.log warn;pid /var/run/nginx.pid;events { worker_connections 1024;}http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf;}修改services/nginx/conf.d目录下文件该目录是各个项目的配置文件，可根据需求配置单个或多个服务server { listen 80; server_name localhost; #charset koi8-r; #access_log /var/log/nginx/host.access.log main; #root /usr/share/nginx/html; root /www; index index.php index.html index.htm; #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # location ~ \.php$ { # root html; fastcgi_pass 101.11.11.10:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #}}启动服务cd php && docker-compose up --build -d 上述的步骤根据网速的docker的配置执行时间个不相同，因为php中编译了些许扩展，也可根据自身需求做响应的删减通过浏览器访问http://127.0.0.1:81,如果看到了phpinfo的输出信息，那么恭喜你，你的lnmp环境已经部署完成

一、前言我自己都对我自己博客记录的次数太少感到无语了~... 目前公司是没有使用docker的，因而自己希望对此作出改变，将服务都部署到docker容器中。 在这里是有几个方面是要考虑的：1.怎么去部署docker容器？2.对于镜像和容器该怎么去统一管理？3.使用docker发生线上故障该如何排查处理？4.使用docker的时候有哪些方面需要注意的？ 因为以前的公司也没有使用过docker，所以这次算是摸石头过河~ 二、怎么去部署docker容器部署docker容器有多种方式： 1.使用jenkins + git自动化部署（当然了我们公司运维都没有。。只能靠自己打包放服务器部署了）2.使用maven的docker 插件打包成镜像（大致是这样。。）3.创建好一个包含java环境的镜像，将某个文件夹挂载到容器上，后续更新服务的时候直接丢jar包到这个文件夹中重启容器就可以了在这里我采用第三种方式。 在这里我编写了一个较简单的Dockerfile 去构建镜像： FROM java:8VOLUME /tmpWORKDIR /appRUN bash -c "touch /app/app.jar"EXPOSE 9110ENTRYPOINT ["java", "-jar", "/app/bigdata-1.0.jar", "&"]编写后使用构建镜像命令：docker build -t xxx . （XXX为要构建的镜像名 注意最后的一个 .要加上） 如果需要暴露多个端口，比如开放JMX端口，则加在EXPOSE中 然后启动容器：docker run --name docker-bigdata -d -v /mnt/bigdata/docker-bigdata:/app -p 9110:9110 bad1deaec0b1 将jar包和外置配置的Config目录一起放在docker-bigdata目录里，挂载到容器的/app目录上，容器启动的时候会自己执行Dockerfile中的命令。 到这里的时候服务已经启动成功了。 三、怎么去管理docker中的容器或镜像使用可视化的UI界面管理。这里有几个选择： 1.k8s2.swarm3.portainer当然了还有其他工具可以选择。 在这里我们首选k8s，因为它可以做到一些更精细化的操作。但是因为学习成本太高，以及服务太少，这里我们略过选择。swarm是最贴合docker的，服务比较少的时候选择swarm是不错的选择，但是因为自己了解的比较少，所以不作选择。选择portainer是因为朋友公司在使用，部署以及管理都很方便，所以参考了他的推荐选择了portainer。 portainer的使用非常简单： 1.docker上面有portainer的镜像，可以直接拉取下来 2.使用命令：docker run -d -p 9000:9000 --restart=always -v /var/run/docker.sock:/var/run/docker.sock --name portainer docker.io/portainer/portainer 这里--restart=always设置关闭后总是会自动重启，至于挂载/var/run/docker.sock:/var/run/docker.sock是必须的，不然进入UI界面的时候会提示你挂载。 3.启动成功后，使用http://ip:port 直接登录，第一次登录会设置账号和密码。在这里应该注册个域名，将ip+port的访问方式屏蔽掉。 这是portainer的管理界面，可以很方便的管理镜像和容器，可以看到容器的运行状况(是否运行以及CPU等状况)，实时日志，容器信息，甚至还可以以命令行方式进入容器，具体一些管理操作等待后面熟悉。 ...

一份Java开发者的技术图谱　, 近期主要侧重点在 Java | Docker | 并发与分布式.

为什么是容器如果问你现在最热门的服务器端技术什么？想必很多人会不假思索的说是容器！ 容器技术实际上并不是一个新鲜的名词，现在大家一提到容器马上想到的就是Docker，但是容器这个词并不是Docker公司发明的，早期的Pass项目如CloudFoundry，其底层就是基于namespace和cgroups的容器技术。 Docker在当时实际上是个小弟，并没有引起大家的注意，但是现在Docker已经成为容器事实上的标准，是什么让Docker发展成现在这样的程度呢？ 这个功能就是Docker镜像。 早期的Pass平台最为人诟病的一个软肋就是应用的打包部署问题，一个应用包在本地部署的好好的，接入Pass平台后却问题重重，而Docker镜像解决了这个根本性问题。 容器到底是怎么回事前面我们说了容器实际上很早以前就有的技术，主要用到的是Linux的namespace，cgroups和rootfs。 我们经常说沙盒或者集装箱，他们里面装的是货物，那容器这个沙盒装的又是什么呢？是进程！ 我们把进程装进一个沙盒(容器)里面，给他制造边界，和盒子外面的世界隔离，所以我们会说容器实际上就是加了围墙的一个进程。 Namespace为进程制造边界就需要用到namespace技术，我们先运行一个docker进程看一下： docker run -it busybox /bin/sh # -it 是提供一个tty的输入输出环境# -d 后台运行程序# -v 挂载外部存储# -p 端口映射# -e 参数变量# busybox 轻量级的容器镜像我们执行ps命令，可以看到有趣的现象，PID为1的就是我们的启动进程。 而实际上在宿主机上面会启动一个进程，其PID在这里是22035。 这就是PID namespace实现的障眼法，它在Linux进程启动的时候（clone函数），会添加CLONE_NEWPID的参数，进程就会看到一个新的命名空间，所以进程ID就会变成1，实际上进程在宿主机上面还是22035。 除了PID namespace之外，还有很多的namespace，比如Network、Mount、User等，通过这些namespace对进程进行网络、储存、文件等进行限制，使这个进程看不到宿主机的真实情况，装在了盒子里，这就是容器的核心原理了。 Cgroups我们通过 Linux 的命名空间为新创建的进程隔离了文件系统、网络、宿主机器上的其他进程，但是命名空间并不能够为我们提供物理资源上的隔离，比如 CPU 或者内存。在同一台机器上可能运行着多个对彼此以及宿主机器一无所知的『容器』，但这些容器却共同占用了宿主机器的物理资源。 如果其中的某一个容器正在执行 CPU 密集型的任务，那么它就会影响其他容器的任务执行效率，导致多个容器相互影响并且抢占资源。如何对多个容器的资源使用进行限制就成了解决进程虚拟资源隔离之后的主要问题，而 Control Group（简称 cgroups）就能隔离宿主机器上的物理资源，例如 CPU、内存、磁盘 I/O 和网络带宽。cgroups介绍、应用实例及原理描述 容器是一个单进程的模型通过namespace和cgroups的学习我们知道了容器就是一个启用了多个namespace的应用进程，而这个进程能够使用的资源受到cgroups的限制。这里面有个很重要的概念：容器是一个单进程的模型。 由于容器本质上面是一个进程，即PID=1的进程，他是后续其他进程的父进程，这就意味着在一个容器内，你没有办法同时运行两个应用，除非找到一个公共的PID=1的父进程，并使用像systemd或者supervisor这样的软件替代PID=1的进程来做为容器的启动进程。 但是我们还是希望容器和应用是同生命周期的，因为如果容器是好的，而里面的进程却已经挂了，这样处理起来就会非常麻烦了。 通过上面对容器原理的了解，我们能不能分析出容器和虚拟机的区别？ 虚拟机需要hypervisor层，在上面创建虚拟机是一个完整的OS容器是Linux上的一个进程虚拟机的OS资源消耗比容器大的多容器使用的是宿主机上相同的内核容器隔离不了时间等资源镜像前面说了Docker能够成为容器现在的事实标准，主要是因为Docker创新了镜像这个东西，那么镜像在Linux系统里面是怎么存在的呢？ 我们Docker的工作目录是/app/docker/docker/ ，其中有个overlay2子目录，它就是我们的镜像目录。 我们在这个目录下有三个目录和一个l的目录，如下: 我们可以进入其中一个目录，并查看该目录下diff子目录的内容: 到这里我们可以知道，镜像是由多个层组织并定义的，这些层本质上是文件，这些文件是只读的，每层具体的文件存放在层标识符下的diff目录下。 所以我们在制作镜像的时候就需要理解层的概念，提高镜像制作的效率和重复使用性。 以我们最常使用的Dockerfile制作镜像举例： FROM node:8.16.0RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtimeRUN echo "Asia/Shanghai" >> /etc/timezoneRUN date -RRUN mkdir -p /opt/app/WORKDIR /opt/appRUN rm -rf /opt/app/node_modules/COPY package.json ./RUN npm install --registry=https://registry.npm.taobao.orgDockerfile 中的每一条命令在最终生成的镜像中都会产生一层。Docker为了提高镜像分发效率，给镜像赋予了复用层的能力，在拉取，推送，build不同镜像时，不同镜像中内容相同的层可以被复用从而节省大量操作。 ...

项目背景搭建一个基于springcloud的分布式博客系统,已经实现了基于eureka的配置中心和注册中心，为了减少本地的内存压力，使用docker将配置中心注册中心放到服务器上 初学者初探dockerfile中的WORKDIR的用处docker build -t imageName path， 这里path指的是上下文路径，如ADD COPY等命令都需要一个源路径和目标路径，那么源路径和目标路径的定位是相对于那个路径呢？ 源路径就是相对于path，它只能访问path下的目录，在path外的目标是不能被访问到，目标路径相对的就是这个WORKDIR，表示当前容器在运行是访问的根路径，比如RUN java -jar target.jar的时候，这个target在容器中的某个目录下，通过WORKDIR定位到这个目录，就能能通过RUN 来执行到这个target.jar，而不需要在RUN中指定额外的相对或者绝对路径定位这个jar文件制作一个含有jdk环境的Dockefile制作这么一个Dockerfile也不难，指定FROM centos, 通过add将jar解压到容器目录里面，最后通过ENTRYPOINT 指定java -jar && tail -f > /etc/null执行springboot的jar包并保证进程不退出。但jdk的环境变量配置需要注意，有三种写法，一种通过RUN SED -i "$a" /etc/profile 将jdk的环境变量写进profile,第二种通过RUN echo "JAVA_HOME" >> /etc/profile，第三种直接通过dockerfile提供的ENV JAVA_HOME 来设置jdk的环境变量。前面两种都是通过在/etc/profile中写环境变量来完成，但是指定RUN source /etc/profile是行不通的，你需要进入容器中source /etc/profile才能让/etc/profile的环境变量生效。第三种是最简单的设置方法，设置了在容器容器时直接生效。RUN命令中的&&命令连接RUN command 一个RUN会产生一个中间的容器，那么一套相关的命令可以通过RUM command && command来进行连接，换行可以指定 ，如果不指定直接换行连接command会出现一些语法错误，这样有什么好处呢？更加直观？命令功能分块集中？你觉得好就对了何必教科书般的说出个之所以然来，RUM cd /usr/local && npm install这条命令如果分开写成两个RUN会如何？ 导致install访问不到/usr/local的文件，它因为是重新开始一个容器，访问的路径时WORKDIR指定的根目录CMD的ENTRYPOINT的区别dockerfile中的一些指令都是可以通过docker run来覆盖的，比如 -v 挂载可以覆盖VOLUME -p 可以覆盖EXPOSE指定的端口, -w可以覆盖WORKDIR,-v 可以覆盖ENV环境变量，这里的docker run imageId command 中的command可以覆盖CMD，所以容器的启动后执行的命令还是写在ENTRYPOINT比较好，避免被覆盖掉。docker run中的-it是什么意思，-d是什么意思， 后面跟个command为/bin/bash又是什么意思i表示交互，t表示伪终端，-d是后台运行，/bin/bash是容器启动时执行/bin/bash命令在容器中打开一个进程进入/bin/bash。解释了但是没有实践又怎么知道是怎么个回事。那么如果不指定-d，会使容器在前台执行进程，将控制台打印这些执行信息，如果指定了-d那么容器进程在后台执行，不会打印执行信息，也不用想办法退出当前容器执行的进程。一般运行docker run以后直接在控制台打印这个容器的id信息，但是我又想进入容器怎么办？docker exec吗，我执行进去看看不想写这个命令，这时候可以通过docker run -it /bin/bash 执行完就能进入到这个容器里面查看一些信息，这应该就是所谓的交互dockerfile通过docker build通过docker images可以找到这个镜像，删除dockerfile上下文会生效吗之前试了一下，也不知道是不是服务器内存不够，执行docker run 没生效，还需要待实践挂载目录的理解挂载目录可以在dockerfile中通过volume指定，这只能指定容器的挂载目录，宿主机的挂载目录自动生成，可以通过docker inspect imageId查看，也可以通过docker run -v path:path 指定，那么我在宿主机的挂载目录中更改一些信息，它会立马响应到容器对应挂载的目录里面dockerfile制作启动springboot项目的镜像，如何更新jar包最初认为只要挂载好宿主机的存放jar的目录到指定的容器目录中，通过docker restart重新执行dockerfile中的ENTRYPOINT java -jar target.jar命令来执行这个容器的挂载目录更新的target.jar，这样就能完成jar的更新，发现行不通每次发布新的jar都需要通过docker build重新构建镜像，具体还需要实际操作总结

准备hadoop2（master）， Hadoop3，hadoop4，三台机器 vi /etc/profile.d/hadoop.sh export JAVA_HOME=/usr/local/src/jdk1.8.0_92export JRE_HOME=${JAVA_HOME}/jreexport CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib:$CLASSPATHexport JAVA_PATH=${JAVA_HOME}/bin:${JRE_HOME}/binexport PATH=$PATH:${JAVA_PATH}export HADOOP_HOME=/usr/local/src/hadoop-2.7.7export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbinexport HDFS_DATANODE_USER=rootexport HDFS_DATANODE_SECURE_USER=rootexport HDFS_SECONDARYNAMENODE_USER=rootexport HDFS_NAMENODE_USER=rootexport YARN_RESOURCEMANAGER_USER=rootexport YARN_NODEMANAGER_USER=root mapred-env.sh hadoop-env.xml yarn-env.sh 至少有一个设置JAVA_HOME core-site.xml，配置hdfs端口和地址，临时文件存放地址 更多参考core-site.xml <configuration><property> <name>fs.default.name</name> <value>hdfs://hadoop2:9091</value></property><property> <name>hadoop.tmp.dir</name><value>/data/docker/hadoop/tmp</value></property></configuration>hdfs-site.xml, 配置HDFS组件属性，副本个数以及数据存放的路径 更多参考hdfs-site.xml dfs.namenode.name.dir和dfs.datanode.data.dir不再单独配置，官网给出的配置是针对规模较大的集群的较高配置。 <font color=red>注意：这里目录是每台机器上的，不要去使用volumes-from data_docker资源共享卷</font> 三台机器同时做 mkdir -p /opt/hadoop/tmp && mkdir -p /opt/hadoop/dfs/data && mkdir -p /opt/hadoop/dfs/name <configuration> <property> <name>dfs.namenode.http-address</name> <value>hadoop2:9092</value> </property> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:/opt/hadoop/dfs/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:/opt/hadoop/dfs/data</value> </property> <property> <name>dfs.namenode.handler.count</name> <value>100</value> </property></configuration>mapred-site.xml，配置使用yarn框架执行mapreduce处理程序 ...

导读 目前以Kubernetes为基础构建的容器生态逐渐完善，这其中Kubernetes、Istio、Knative三个独立项目被越来越多的人提及，并且已经开始尝试大规模落地实践，它们恰好构成了容器云的未来拼图。今天与大家一起分享下，这三个项目究竟解决了什么问题，为什么它们能够一鸣惊人。 随着微服务理念不断深入人心，越来越多的企业把自己的应用逐步由单体转变成微服务架构，Container容器技术的出现恰恰加速了这个转移过程，因为它有效地解决了N多服务的快速部署问题。但是随着服务数目的增多，越来越多的企业希望能够把相关服务有效地“聚合”在一起，方便统一部署与管理。Kubenretes的出现恰恰解决了大规模微服务编排部署所带来的挑战，让整个行业意识到PaaS的落地可以成为现实。 当随着微服务体系下的服务数目越来越多，服务运维成为必然要解决的问题，于是Istio出现了，基于网络代理与控制相分离的实现策略，允许对服务控制策略进行有效合理的管控。 到这里似乎到了很美好的阶段：微服务：解决应用内聚、臃肿的问题。Container：解决服务运行环境统一，和部署问题。Kubernetes：解决大量微服务有效“聚合”部署问题。Istio：解决服务上线面临的一系列治理问题。 这个阶段乍一看来，构建容器云似乎有了一个完整的链路和解决方式，一切都将变得那么“完美”。 现在让我们回过头来深入分析一下，微服务体系下的服务交互，目前是否存在问题。 首先，无论是http，还是rpc，本质上都是服务与服务的远程调用。开发应用程序中，无法做到服务与服务间的彼此透明。这样会导致一个问题：无论微服务业务拆分多么“精细”，本质上业务单元之间还是不能够独立运行和发展。同时在面向不同开发领域的衍生，无法选择最合适的实现方式。因此我们希望能够基于不同的“模板”+“配置”的方式能够把开发环境标准化处理，同时提供“事件”机制，将服务与服务交互的耦合度降到最低。 其次，服务线上运行的动态伸缩问题。当下kubernetes环境下的弹性伸缩，需要由客户搜集监测数据，并自主手动来实现，但是我们更希望服务线上能够更加自动化和智能化。 最后，服务标准化问题。我们希望服务内部的模型是标准的、能够快速复制和快速构建的；服务通信是标准的：协议标准，格式标准；运行环境是标准的：快速部署，快速迁移。 Knative的出现恰好解决远程直接调用，服务线上自动管理以及一些列标准化问题。 下面我们来看一下三者的关联： Kubernetes和Istio相信大家比较熟悉了，这里不做过多介绍，有需要的同学可以关注下我们之前发布的相关文章，这里我们重点来看一下Knative。 Knative是谷歌开源的serverless架构方案，旨在提供一套简单易用的serverless方案，把serverless标准化。目前参与的公司主要是Google、Pivotal、IBM、Red Hat，于2018年7月份对外发布，目前处于快速发展阶段。 Knative组成 Build构建系统：把用户定义的应用构建成容器镜像，面向kubernetes的标准化构建，区别于Dockerfile镜像构建，重点解决kubernetes环境的构建标准化问题。 Serving服务系统：利用Istio的部分功能，来配置应用路由，升级以及弹性伸缩。Serving中包括容器生命周期管理，容器外围对象（service，ingres）生成（恰到好处的把服务实例与访问统一在一起），监控应用请求，自动弹性负载，并且利用Virtual service和destination配置服务访问规则。只有这样才能保证服务呈现一致性以及服务运行自动化管理。 Eventing事件系统：用于自动完成事件的绑定与触发。事件系统与直接调用最大的区别在于响应式设计，它允许运行服务本身不需要屏蔽了调用方与被调用方的关系。从而在业务层面能够实现业务的快速聚合，或许为后续业务编排创新提供事件。 现在我们换一个角度，聚焦应用服务生命周期：**Knative 解决应用模板+面向统一环境的标准化构建场景；Kubernetes作为基础设施，解决应用编排和运行环境场景；Isito作为通信基础设施层，保证应用服务运行可检测、可配置、可追踪问题。** 这三者贯穿应用服务生命周期全过程，容器云恰恰也是管理应用服务的控制平台，这就能够很好地解释，为什么Kubernetes，Istio，Knative在未来会成为构建容器云的三驾马车。

痛点笔者在尝试起一个新web项目时，往往会陷入重新建立一套Docker环境的繁琐事当中。我想大家在开始做一个新项目时，或者快速为了和以前的项目做完全的隔离，也会起一套新docker环境。 从这篇文章你会得到采用docker-compose容器编排技术，一步启动全部服务。php容器在官方的基础上还打包了一些常用拓展（附带build源码，动手能力强可以自己打包)，php，nginx，mysql都附带有自定义配置文件（便于开发测试的配置调整），都供下载。 架构 本片文章搭建出来的环境如上图。 环境说明运行环境Mac OS 10.13.6Virtual Box 5.2.14Ubuntu 16.04.4Docker 17.07.0-ce容器Nginx 1.12.1-alpinePHP-fpm 5.6MySQL 5.7Redis 3.2Memcached 1.4.27这里说明一下笔者运行环境，采用了在Mac机上安装vbox虚拟机，在虚拟机里面的debian环境安装了Docker环境，文件放在Mac环境，通过文件挂载方式，达到Mac环境编辑，Docker环境实时更新效果。你要问为啥不在Mac下直接装Docker，历史原因～运行材料.├── build ## docker 镜像build 材料│   ├── php5.6 ## php 5.6│   │   ├── Dockerfile│   │   ├── imagick-3.4.3.tgz│   │   ├── memcached-2.2.0.tgz│   │   ├── redis-4.0.2.tgz│   │   ├── sources.list│   │   └── xdebug-XDEBUG_2_5_5.tar.gz│   └── php-cli ## php cli 的自建镜像│   ├── amqp-1.9.3.tgz│   ├── Dockerfile│   ├── Dockerfile-php-swoole│   ├── memcached-3.0.4.tgz│   ├── redis-4.1.1.tgz│   ├── sources.list.jessie│   ├── swoole-4.0.4.tgz│   ├── swoole-4.2.6.tgz│   ├── xdebug-2.6.1.tgz│   └── yaf-3.0.7.tgz├── config ## 配置文件│ ├── apt ## 由于使用的debian系列，所以命名apt│ │ └── sources.list ## 更新为国内源│ ├── memcached ## memchached的配置│ │ └── memcached.conf│ ├── mysql ## mysql 的配置│   │   ├── conf.d│   │   │   └── mysqld_safe_syslog.cnf│   │   └── my.cnf│ ├── nginx ## nginx 的配置│   │   ├── conf.d│   │   │   ├── default│   │   │   └── xiuno│   │   ├── mime.types│   │   ├── nginx.conf│   │   └── sites-enabled│ ├── php ## php的配置，分cli，和fpm配置│   │   ├── cli│   │   │   ├── conf.d│   │   │   │   ├── 05-opcache.ini│   │   │   │   ├── 10-pdo.ini│   │   │   │   ├── 20-curl.ini│   │   │   │   ├── 20-gd.ini│   │   │   │   ├── 20-imagick.ini│   │   │   │   ├── 20-json.ini│   │   │   │   ├── 20-memcache.ini│   │   │   │   ├── 20-mysqli.ini│   │   │   │   ├── 20-mysql.ini│   │   │   │   ├── 20-pdo_mysql.ini│   │   │   │   ├── 20-readline.ini│   │   │   │   ├── 20-redis.ini│   │   │   │   ├── 20-xdebug.ini│   │   │   │   └── swoole.ini│   │   │   └── php.ini│   │   ├── fpm│   │   │   ├── conf.d│   │   │   │   ├── docker.conf│   │   │   │   ├── www.conf│   │   │   │   └── zz-docker.conf│   │   │   ├── docker-php-fpm.conf│   │   │   ├── php-fpm.conf│   │   │   ├── php.ini│   │   │   └── pool.d│   │   │   └── www.conf│   │   └── mods-available│   │   ├── curl.ini│   │   ├── gd.ini│   │   ├── imagick.ini│   │   ├── json.ini│   │   ├── memcache.ini│   │   ├── mysqli.ini│   │   ├── mysql.ini│   │   ├── opcache.ini│   │   ├── pdo.ini│   │   ├── pdo_mysql.ini│   │   ├── readline.ini│   │   ├── redis.ini│   │   └── xdebug.ini│ └── redis ## redis 配置│   ├── redis.conf│   ├── redis-server.sh│   └── sentinel.conf├── data ## 为了数据持久化│ ├── mysql ## mysql 文件挂载│ └── redis ## redis 持久化数据文件夹├── docker-compose.yaml ## 容器编排 ！！！├── log ## 各个容器产生的日志│ ├── mysql ## mysql日志│ │ ├── error.log│ │ └── mysql.log│ ├── nginx ## nginx 日志│   │   ├── access.log│   │   ├── access_xiuno.log│   │   ├── error.log│   │   └── error_xiuno.log│   └── php├── php ## php代码存放目录│ └── xiunobbs ## php项目└── tool ## php 一些工具 ├── composer.phar └── phpunit-4.8.36.phar配置文件下载git clone https://gitee.com/xupaul/docker_fast_init配置说明目前笔者还没有写相关自动化脚本自动适配用户的使用环境，所以这里需要先调整一下下载后的配置文件。docker-compose.yml 文件调整这个文件有大量的文件挂载配置，这块就需要调整，拿一个举例。 ...

docker简介1.docker是基于go语言实现主要目标是对对应组件的封装、分发、部署、运行等生命周期的管理，使应用程序及其运行环境能够做到“一次封装，到处运行” 2.docker为了解决了运行环境和配置问题的软件容器，方便做持续集成并有助于整体发布的容器虚拟化技术 3.docker能干些什么？ 虚拟机技术简单理解可以在一种操作系统里面运行另外一种操作系统，比如windows中运行linux系统，常见的是vmware；缺点：占用资源，启动慢，安装步骤繁琐。容器虚拟化技术docker既是一种容器虚拟化技术，docker本身是一个容器运行载体或称之为管理引擎，我们把应用程序和配置依赖打包好形成一个可交付的运行环境，这个打包好的运行环境就是镜像文件，只有通过这个镜像文件才能生成docker容器。docker 根据 image 镜像文件生成容器实例。同一个image文件可以生成多个同时运行的容器实例。docker 架构 docker使用docker的三大要素仓库:存储镜像的地方，分为公开仓库和私有仓库镜像容器:用镜像创建的运行实例，可以把容器看成简易版的Linux的容器hello world 运行docker run hello-world docker底层原理docker是一个client-server结构的进程，docker守护进程运行在主机上，然后通过socket连接从客户端的访问，守护进程从客户端接受命令并管理运行在主机上的docker容器。容器是一个运行时环境，就是鲸鱼背上的一个个集装箱。 docker常用命令1.帮助命令 docker versiondocker infodocker --help2.镜像命令 docker images : 列出本地镜像docker image -qa : 显示全部镜像iddocker images --digests : 显示镜像简介信息docker images --digests --no-truncdocker search tomcat : 搜索某个镜像docker pull tomcat : 下载镜像到本地 等价于 docker pull tomcat:latest（默认下最新版本）docker rmi tomact : 删除某个镜像 docker rmi tomcat:6.5 删除制定版本镜像docker rmi -f tomcat 强制删除镜像docker rmi -f nginx tomcat 强制删除多个镜像docker rmi -f ${docker images -qa} 强制删除全部3.容器命令 ...

毫不夸张的说，所有的 Docker 版本都存在同一个漏洞，这个漏洞可以让攻击者获得主机服务器上所有路径的读写访问权限。据了解，之所以会出现该漏洞，主要是因为 Docker 软件处理某些符号链接的方式，而这些符号链接中往往会包含有到其他目录或文件的路径的文件。1.事件回溯研究员 Aleksa Sarai 发现，在某些情况下，攻击者可以在路径解析时间和操作时间之间的短时间窗口将自己的符号链接插入到路径中。这是 TOCTOU 问题的一个变体，特别是“docker cp”命令，它可以将文件从主机复制到容器，或从容器复制到主机。 Sarai 表示，“这次攻击的基本前提是 FollowSymlinkInScope 遭受了相当根本的 TOCTOU 攻击。FollowSymlinkInScope 的目的是获取给定路径并安全解析，就好像进程位于容器内部一样。完整路径被解析之后，路径会被传递，同时会进行一些操作（例如，在’docker cp’的情况下，它会在创建流式传输到客户端的存档时打开）。” “如果攻击者在解析之后、操作之前，向路径添加符号链接组件，那么主机上的符号链接路径组件就会被解析为 root。如果正好是在‘docker cp’的情况下，攻击者就可以对主机上的所有路径进行读写访问。” 研究人员认为针对 Docker 的这种攻击可能会持续几年时间。Sarai 针对这一漏洞开发了利用代码，并表示：潜在的攻击场景可能来自云平台，“最可能受到影响的是托管云，因为它允许配置文件复制到正在运行的容器中，也允许从容器中读取文件。” 虽然这个漏洞只有针对“docker cp”的攻击代码，但它是最容易被攻击的端点。另外还有一个值得注意的点，如果选择了一条路径，扩展了其中的所有符号链接，并假设该路径是安全的，那么这是一种非常危险的行为。 2.如何修复“这个 Docker 漏洞虽然看起来很严重，但对大多数企业来说未必是紧急情况。” Capsule8 产品开发副总裁 Kelly Shortridge 表示：“Docker 的这个 TOCTOU 漏洞允许攻击者不仅在容器内，而且在主机上违反数据完整性和机密性。除了禁止在任何正在运行的容器上使用 docker cp 实用程序或使用攻击保护产品之外，利用 docker cp 的 Docker 用户很容易受到攻击，但仅限于动机足够强的攻击者，他们有意愿与 docker cp 竞争。” 据了解，Sarai 已经提交了针对该漏洞的修复建议，其中包括在使用文件系统时暂停容器。 这个问题最完整的解决方案是修改 chrootarchive，这样所有的存档操作都将以根目录作为容器 rootfs 进行 (而不是父目录，因为父目录是由攻击者控制的，所以导致了这个漏洞)。不过，要对 Docker 核心部分做更改几乎是不可能完成的事情。 退而求其次，我们选择了在使用文件系统时暂停容器。这种方法能够阻止最基本的攻击，但是在某些攻击场景下无法发挥作用，例如 shared volume mounts。 不过，截止到目前还没有关于 Docker 官方何时修复漏洞的消息。 ...

Docker 安装通过 Homebrew 来安装 Dockerbrew install docker 这个安装可能比较慢，可以通过阿里云镜像服务来下载 Docker.dmg http://mirrors.aliyun.com/doc... 安装 Docker 的图形管理界面 Kitematichttps://github.com/docker/kit... golang 语言环境配置brew install go go 环境变量配置参考：https://www.jianshu.com/p/358... protobuf 安装brew install protobuf 如果安装不成功的话，可手动安装protobuf 下载：https://github.com/protocolbu...下载完成后解压安装 tar -zxf protobuf-all-3.7.1.tar.gzcd protobuf-3.7.1./autogen.sh./configuremakemake checksudo make install如果在执行 ./autogen.sh 出现如下错误： + mkdir -p third_party/googletest/m4+ autoreconf -f -i -Wall,no-obsolete./autogen.sh: line 37: autoreconf: command not found解决方法： brew install autoconfbrew install automakebrew install libtool然后再执行 ./ autogen.sh 就不报错了万里长城第一步，终于把docker和两个语言环境搭好了，接下来继续。 执行 go get 命令go get -u -v github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gatewaygo get -u -v github.com/grpc-ecosystem/grpc-gateway/protoc-gen-swaggergo get -u -v github.com/golang/protobuf/protoc-gen-go如果你在自己的电脑执行上述命令可能会出现问题，go get 被墙，就算有vpn，网速不好会超时： ...

学习背景近些年，如果你是一名开发，那么Docker这个热门的技术名词你一定听说过，我也不例外，但是因为平时没接触过，所以一直都没动力去了解使用。最近在折腾自己维护在github上的项目的时候，发现项目所依赖的外部环境比较多，比如zookeeper、redis、elasticsearch等等，如果都安装一遍的话比较麻烦，而且因为是自己整理平时积累用的项目，对数据也没什么要求，只要有这样一个环境能保证项目运行起来就行了。第一时间想到的就是利用docker容器，这样自己不但可以顺便学习一下这个热门技术，还可以把搭建成果作为这个项目的一部分让有兴趣研究的项目关注者直接在接触到这个项目的时候可以快速把环境搭建起来，可谓是一举两得。 有兴趣的朋友可以访问项目地址:https://github.com/MartinDai/... 安装 Docker Desktop参考 [https://www.docker.com/get-started][1]，安装并启动后就可以使用下面的这些命令了docker 命令docker --version 查看当前docker版本，可以顺便验证docker是否安装成功且启动好了 docker --help 查看docker命令帮助，包含所有支持的操作命令使用规则及简介 还可以看某个指令的详细帮助,如：`docker images --help` docker pull [OPTIONS] NAME[:TAG|@DIGEST] 下载镜像，如果没有指定镜像地址，默认从[官方的hub][2]下载指定的镜像，官方的hub提供了绝大多数热门的组件镜像，可以根据自己的需要进行搜索，这个网站有点类似github的模式，各个官方组件一般都会有比较详细的使用说明，比如Redis 可以使用docker pull redis下载最新版本的redis镜像 当然也可以指定下载的版本,如docker pull redis:5.0.5 当然有一些组件没有发布在官方的hub上，比如elasticsearch和kibana,这两个镜像需要从docker.elastic.co这个地址下载,可以使用docker pull docker.elastic.co/elasticsearch/elasticsearch:6.2.4下载 docker images 查看当前已下载的镜像列表，如果是刚安装好以后的话，列表是空的，下图是我的镜像

一、 本质上的区别 VM(VMware)在宿主机器、宿主机器操作系统的基础上创建虚拟层、虚拟化的操作系统、虚拟化的仓库，然后再安装应用；Container(Docker容器)，在宿主机器、宿主机器操作系统上创建Docker引擎，在引擎的基础上再安装应用。那么问题来了，没有操作系统，怎么运行程序？可以在Docker中创建一个ubuntu的镜像文件，这样就能将ubuntu系统集成到Docker中，运行的应用就都是ubuntu的应用。 二、使用上的区别： size:1.虚拟机中ubuntu所占内存： 2.Docker容器中ubuntu镜像文件所占内存： Startup: Docker在宿主机器的操作系统上创建Docker引擎，直接在宿主主机的操作系统上调用硬件资源，而不是虚拟化操作系统和硬件资源，所以操作速度快。这个其实安装一个ubuntu的虚拟机和拉取一个Docker的ubuntu镜像文件，运行一下就知道了，区别很明显，虚拟机开一下大概得2分多钟，而Docker只需要2秒钟。 Integration：Docker的集成性要比VM好。这个并没有深入研究，不过可以提供一个博客，这里面关于Docker集成的内容写的很好。https://blog.csdn.net/karamos... 三、Docker特点1）上手快用户只需要几分钟，就可以把自己的程序“Docker 化”。Docker 依赖于“写时复制” (copy-on-write)模型，使修改应用程序也非常迅速，可以说达到“随心所致，代码即改” 的境界。随后，就可以创建容器来运行应用程序了。大多数 Docker 容器只需要不到 1 秒中即可 启动。由于去除了管理程序的开销，Docker 容器拥有很高的性能，同时同一台宿主机中也 可以运行更多的容器，使用户尽可能的充分利用系统资源。 2）职责的逻辑分类使用 Docker，开发人员只需要关心容器中运行的应用程序，而运维人员只需要关心如 何管理容器。Docker 设计的目的就是要加强开发人员写代码的开发环境与应用程序要部署 的生产环境一致性。从而降低那种“开发时一切正常，肯定是运维的问题(测试环境都是正 常的，上线后出了问题就归结为肯定是运维的问题)” 3）快速高效的开发生命周期Docker 的目标之一就是缩短代码从开发、测试到部署、上线运行的周期，让你的应用 程序具备可移植性，易于构建，并易于协作。(通俗一点说，Docker 就像一个盒子，里面 可以装很多物件，如果需要这些物件的可以直接将该大盒子拿走，而不需要从该盒子中一件 件的取。) 4）鼓励使用面向服务的架构Docker 还鼓励面向服务的体系结构和微服务架构。Docker 推荐单个容器只运行一个应 用程序或进程，这样就形成了一个分布式的应用程序模型，在这种模型下，应用程序或者服 务都可以表示为一系列内部互联的容器，从而使分布式部署应用程序，扩展或调试应用程序 都变得非常简单，同时也提高了程序的内省性。(当然，可以在一个容器中运行多个应用程 序)

一.概述cortex：一个支持多租户、水平扩展的prometheus服务。 当时调研cortex其实是因为看到了Weave Cloud这个商业产品中的监控模块介绍，weave也叫weave works，官方地址是：https://cloud.weave.works，是一个专注于容器微服务的paas平台。 WeaveCloud在监控模块最大化利用了Prometheus，并在其基础上添加了很多组件，实现了多租户管理、高可用的监控集群。其使用的核心监控组件就是cortex。 本文主要分享的是cortex的运行机制，关于Weave Cloud的产品定位和功能可以看下后续的文章:[商业方案-weave work]() Cortex是一个CNCF的沙盒项目，目前被几个线上产品使用：Weave Cloud、GrafanaCloud和FreshTracks.io 为什么不直接运行Prometheus，而用Cortex？ ps:来自cortex kubecon大会演讲 作为服务，cortex提供了鉴权和访问控制数据永久保留，状态能够被管理提供持久化、高可用、伸缩性提供更好的查询效率，尤其是长查询二.主要功能针对以上需求，Cortex提供的主要功能或特色如下： 支持多租户：Prometheus本身没有的租户概念。这意味着，它无法对特定于租户的数据访问和资源使用配额，提供任何形式的细粒度控制。Cortex可以从多个独立的prometheus实例中获取数据，并按照租户管理。长期存储：基于远程写入机制，支持四种开箱即用的长期存储系统：AWS DynamoDB、AWS S3、Apache Cassandra和Google Cloud Bigtable。全局视图：提供所有prometheus server 整合后的时间序列数据的单一，一致的“全局”视图。高可用：提供服务实例的水平扩展、联邦集群等最大化利用了Prometheus相似的竞品： Prometheus + InfluxDB：使用InfluxDataPrometheus + Thanos：长期存储、全局视图Timbala：多副本、全局视图，作者是Matt BostockM3DB：自动扩缩容，来自uber产品形态ps:来自weave work上试用监控模块时的截图 1.安装监控的agent: 2.概览视图 3.资源监控面板 4.监控详情页面 5.添加监控 6.配置报警 在k8s集群中部署所需要的yaml列表为： [https://github.com/weaveworks...](https://github.com/weaveworks...) 部署的agent时的脚本内容是： #!/bin/shset -e# Create a temporary file for the bootstrap binaryTMPFILE="$(mktemp -qt weave_bootstrap.XXXXXXXXXX)" || exit 1finish(){ # Send only when this script errors out # Filter out the bootstrap errors if [ $? -ne 111 ] && [ $? -ne 0 ]; then curl -s >/dev/null 2>/dev/null -H "Accept: application/json" -H "Authorization: Bearer $token" -X POST -d \ '{"type": "onboarding_failed", "messages": {"browser": { "type": "onboarding_failed", "text": "Installation of Weave Cloud agents did not finish."}}}' \ https://cloud.weave.works/api/notification/external/events || true fi # Arrange for the bootstrap binary to be deleted rm -f "$TMPFILE"}# Call finish function on exittrap finish EXIT# Parse command-line argumentsfor arg in "$@"; do case $arg in --token=*) token=$(echo $arg | cut -d '=' -f 2) ;; esacdoneif [ -z "$token" ]; then echo "error: please specify the instance token with --token=<TOKEN>" exit 1fi# Notify installation has startedcurl -s >/dev/null 2>/dev/null -H "Accept: application/json" -H "Authorization: Bearer $token" -X POST -d \ '{"type": "onboarding_started", "messages": {"browser": { "type": "onboarding_started", "text": "Installation of Weave Cloud agents has started"}}}' \ https://cloud.weave.works/api/notification/external/events || true# Get distributionunamestr=$(uname)if [ "$unamestr" = 'Darwin' ]; then dist='darwin'elif [ "$unamestr" = 'Linux' ]; then dist='linux'else echo "This OS is not supported" exit 1fi# Download the bootstrap binaryecho "Downloading the Weave Cloud installer... "curl -Ls "https://get.weave.works/bootstrap?dist=$dist" >> "$TMPFILE"# Make the bootstrap binary executablechmod +x "$TMPFILE"# Execute the bootstrap binary"$TMPFILE" "--scheme=https" "--wc.launcher=get.weave.works" "--wc.hostname=cloud.weave.works" "--report-errors" "$@"三.实现原理Cortex与Prometheus的交互图： ...

一.概述Dockbix意为docker+zabbix，即使用zabbix来监控docker容器的插件或者模块，既然有专业的cadvisor、prometheus等容器监控方案，为什么还要用传统的zabbix呢？ 在docker刚出现时，还没有专业的容器监控方案公司已有zabbix的成熟实践，想直接集成到zabbix中(虽然不太优雅)使用zabbix来监控docker有几种方案，比如: 自己写agent，利用docker的api获取stats信息，暴露api接口给zabbix采集使用zabbix的Module，将docker的采集展示集成到现有的zabbix系统中如何使用写APIpython sdk：https://docker-py.readthedocs.io/en/stable/containers.html#docker.models.containers.Container.stats stats(**kwargs)Stream statistics for this container. Similar to the docker stats command.Parameters: decode (bool) – If set to true, stream will be decoded into dicts on the fly. Only applicable if stream is True. False by default.stream (bool) – If set to false, only the current stats will be returned instead of a stream. True by default.Raises: docker.errors.APIError – If the server returns an error.如计算cpu： ...

近日，阿里云安全发现了一个使用未授权访问漏洞部署恶意Docker镜像进行挖矿的僵尸网络团伙。我们给这一团伙取名为Xulu，因为该团伙使用这个字符串作为挖矿时的用户名。 Xulu并不是第一个攻击Docker的恶意挖矿团伙，但它不同于其他僵尸网络。Xulu感染一台服务器后，并不对外进行大规模扫描，而是使用OSINT技术，即利用开源情报，动态地从shodan网站获得可能的“猎物”ip列表。 此外，Xulu僵尸网络将自己的服务器放在Tor洋葱网络中，这使得对幕后黑手的追溯变得更加困难。 会挖矿的恶意Docker镜像Docker容器是一个开源的应用容器引擎，可以让开发者打包他们的应用及依赖包到一个轻量级、可移植的容器中，从而在不同环境中可靠运行。 近年来随着微服务的流行，越来越多的企业在部署应用时使用容器，然而在这一过程中安全往往没有得到应有的重视，导致Docker容器在多起事件中成为网络攻击的靶子。 在本次Xulu僵尸网络事件中，我们注意到沦陷服务器上都被创建了镜像名为zoolu2/auto的恶意容器。 这些恶意容器中运行着如下进程 其中的挖矿进程很容易分辨： /toolbin/darwin -o us-east.cryptonight-hub.miningpoolhub.com:20580 -u xulu.autodeploy -p x --currency monero -i 0 -c conf.txt -r尽管miningpoolhub.com是公开矿池，但由于它不提供每个用户的历史收益数据，我们无从得知攻击者从恶意挖矿中总共赚了多少钱。 僵尸网络的传播和持久化Xulu僵尸网络进行自身的传播和持久化的过程中，使用了OSINT技术并借助了洋葱网络。 首先，该僵尸网络的控制服务器地址是http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion。".onion"后缀表明这是一个必须通过洋葱匿名网络访问的“洋葱服务”(又名“隐藏服务”)。 该僵尸网络以/toolbin/shodaemon作为守护进程： 不难看出该脚本下载了http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion/shodan.txt，与本地硬编码的/toolbin/hcode.txt文件内容一起存入search.txt 运行/toolbin/shodan，读取search.txt的列表并对shodan发送如上图所示的查询。 这些查询会返回互联网上一系列开放了Docker服务(2375端口)的主机ip。尽管这些主机并非每个都存在漏洞，但攻击者仍然通过使用shodan的信息，避免了大规模扫描的进行。 在获取了使用Docker服务的主机列表并去除重复ip后，已沦陷的主机会向表中ip发送docker run命令，其中未授权访问漏洞的Docker服务将被部署"zoolu2/auto"恶意镜像，从而完成蠕虫的传播。 此外，Xulu僵尸网络还会每30分钟下载并执行从http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion/bnet1.txt下载的脚本，从而保持自身在受害主机上的活跃。 受害规模和安全建议在docker hub官网我们可以看到，前文提到的"zoolu2/auto"已被下载超过1万次： 并且僵尸网络作者似乎仍在积极开发变种： 为了避免您成为此种恶意入侵和挖矿事件的受害者，阿里云安全为您提供如下安全建议：不要将对内使用的服务(如Docker)开放在互联网上，应使用ACL或复杂密码等措施来保证仅有受到信任的用户才可以访问这些服务。因为基于洋葱网络的“隐藏服务”已被用于多个僵尸网络的传播，不常使用洋葱网络服务的用户可以使用如下命令对其进行屏蔽：echo -e "n0.0.0.0 .onion" >> /etc/hosts我们推荐您使用阿里云下一代防火墙，因为它在阻止、拦截此类需要外联的攻击时十分有效。用户将在AI技术的帮助下，免于恶意挖矿事件的困扰我们同样推荐阿里云安全管家服务。该服务的用户可以就碰到的问题随时咨询安全专家。安全专家还可以帮助用户进行安全加固、事件溯源、蠕虫清理等IOCcontrol server: http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion url: http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion/bnet1.txthttp://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion/shodan.txt pool:us-east.cryptonight-hub.miningpoolhub.com:20580 md5: c29dfe75862b6aed91bec4ffc7b20b9c Referencehttps://www.alibabacloud.com/blog/dockerkiller-threat-analysis-first-instance-of-batch-attack-and-exploitation-of-docker-services_593947https://www.docker.com/resources/what-container 本文作者：云安全专家阅读原文 本文为云栖社区原创内容，未经允许不得转载。

1. Redis集群概述Redis作为当前非常热门的内存型数据结构存储，可用于数据存储，缓存和消息代理等。本文将讲解如何基于docker搭建Redis集群，Redis的集群设计包括两个部分：主从复制和哈希Slot。 1.1. 主从复制主从复制在数据库中很常见，一般用来做读写分离，Redis中也是如此。要求只有1个Master（主节点），可以有N个slaver（从节点），而且Slaver也可以有自己的Slaver，由于这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。 读写分离，Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，所以Slaver的扩容只能提高读效率不能提高写效率。 Slaver先将Master那边获取到的信息压入磁盘，再load进内存，client端是从内存中读取信息的。当一个新的Slaver加入到这个集群时，会主动找Master来拜码头，Master发现新的小弟后将全量数据发送给新的Slaver，数据量越大性能消耗也就越大，所以尽量避免在运行时做Slaver的扩容。 优点：读写分离，通过增加Slaver可以提高并发读的能力。缺点：Master写能力是瓶颈，维护Slaver开销也总将会变成瓶颈。1.2. 哈希Slot哈希Slot名字上可能不好理解，其实就是数据库中的“水平划分”。如果你之前有了解过数据库的表分区的话，就会发现下来对于哈希Slot的描述，就和数据库表分区里面的“HASH分区”原理上大致相同。 对象保存到Redis之前先经过CRC16哈希到一个指定的Node上，例如图中Object4最终Hash到了Node1上。  每个Node被平均分配了一个Slot段，对应着0-16384，Slot不能重复也不能缺失，否则会导致对象重复存储或无法存储。  Node之间也互相监听，一旦有Node退出或者加入，会按照Slot为单位做数据的迁移。例如Node1如果掉线了，0-5640这些Slot将会平均分摊到Node2和Node3上,由于Node2和Node3本身维护的Slot还会在自己身上不会被重新分配，所以迁移过程中不会影响到 5641-16384 Slot段的使用。 优点：将Redis的写操作分摊到了多个节点上，提高写的并发能力，扩容简单。缺点：每个Node承担着互相监听、高并发数据写入、高并发数据读出，工作任务繁重。1.3. 合二为一看到这里大家也就发现了，主从和哈希的设计优缺点正好是相互弥补的，将二者结合在一起，就是Redis集群的终极形态，先Hash分逻辑节点，然后每个逻辑节点内部是主从，如图： 2. 集群安装默认我们已经有了docker环境，现在开始基于docker安装Redis集群。redis 5.0 版本之前，网上有很多教程都是通过redis-trib.rb 来创建集群，但是redis 5.0 版本以后，就只能通过 redis-cli 来实现。本文即通过 redis-cli 创建集群，因为redis集群的节点选举方式是需要半数以上的master通过，所以建议创建奇数个节点。本例中创建3个Master节点，并为每个Master节点各分配1个Slave节点。 2.1. 宿主机环境首先需要找一份原始的redis.conf文件，将其重命名为：redis-cluster.tmpl，并配置如下几个参数，此文件的目的是生成每一个redis实例的redis.conf: [root@kerry2 redis]# wget https://raw.githubusercontent.com/antirez/redis/5.0/redis.conf[root@kerry2 redis]# mv redis.conf redis-cluster.tmplvi redis-cluster.tmpl # bind 127.0.0.1protected-mode noport ${PORT}daemonize nodir /data/redisappendonly yescluster-enabled yescluster-config-file nodes.confcluster-node-timeout 15000然后执行下列脚本，给3个Master和3个Slave创建各自的挂载卷目录 # 创建 master 和 slave 文件夹for port in `seq 7700 7705`; do ms="master" if [ $port -ge 7703 ]; then ms="slave" fi mkdir -p ./$ms/$port/ && mkdir -p ./$ms/$port/data \ && PORT=$port envsubst < ./redis-cluster.tmpl > ./$ms/$port/redis.conf;done当前目录结构为 ...