container

上一篇奠定了基础的知识点以后，我们开始区块链之旅了！ 我们要做的第一件事是将“geth”节点连接到以太坊生产网络，从而保证我们的本地区块链同步，并为其他工具打开服务端口 - 当然也是在容器中运行。 通过“docker run”命令，启动镜像“ethereum / client-go”。 RUN命令具有以下参数： “-it”以交互模式启动容器，并将容器的标准输出发送到我们的终端。当以后重新启动容器时，我们可以选择在后台运行该进程，但是现在我们要看看发生了什么。 “ - -name”给容器以逻辑名“ethereum”，我们稍后可以使用它来访问这个实例。 “-p 30303：30303 -p 8545：8545 -p 8546：8546”公开并且将三个端口从容器内部映射到外部。 “-v /opt/docker/ethereum:/root/.ethereum”将主机目录“/ opt / docker / ethereum”（我们要存储区块链数据的位置）挂载到位置“/ root / .ethereum“。后者是“geth”在使用root用户帐户启动时存储所有信息的默认位置。 这个镜像的ENTRYPOINT命令“geth”可以通过INSPECTing可视化来调用，就像我们在主机上直接运行时使用该工具一样。请注意，容器命令行参数不能（容易）过后更改，如果需要不同的命令行

本文假设读者已对OOS有一定的认识了解并且已经自行成功搭建过Swift，背景还有部署方法这里就不多说了，这里Swift使用的身份认证组件为Keystone，参照官方文档步骤操作发现，对container设置ACL后仍没法实现允许任何人访问该容器下的object。后来查看Swift中间件源码中的注释得知，只需在proxy-server.conf中启动相应配置即可解决上述问题。 首先来看看proxy-server.conf中的pipline顺序： [pipeline:main] pipeline = catch_errors healthcheck proxy-logging cache bulk slo ratelimit authtoken keystoneauth container-quotas account-quotas staticweb proxy-logging proxy-server 上面标红部分为keystone认证组件，在正常情况下，请求要顺利通过proxy-server，必须要从keystone或者cache中拿到一个有效token，然而要想拿到token的话，必须要输入Tenant、User和password等相关信息。这样来说，swift仅提供了私有存储的服务，要想实现公有存储服务，仍需做以下操作。 第一，修改proxy-server.conf配置

镜像和层 镜像是由一些只读并且描绘文件系统区别的层组成的.它们一层一层堆叠起来,组成了镜像的基础文件系统.这些层都是只读的. 下图是由4层构成的ubuntu镜像: 而docker存储驱动的职责就是将这些层堆叠起来.并提供一个统一的视图.让我们觉得跟普通文件系统没什么区别. 当你创建了一个容器时.会在镜像的层上再添加一层叫做"容器层(container layer)",所有在运行中的容器中所做的修改操作,都是影响的这一层. 看下图 内容可寻址的存储 docker 1.10 开始,介绍了一种全新的寻址镜像和层上数据的存储模型.之前的镜像和层上数据的存放,都是通过随机UUID存放.新模型采用一种安全的内容hash来存放. 新模型特点包括提高了安全性.防止了id冲突,保证了pull,push,load,save操作后的数据一致性.并且更好的提供了层之间的共享问题. 参考图片: 容器层还是random uuid 对于新的模型,原先旧模型的镜像数据需要重新计算id来迁移.这些操作会在你运行新版本docker进程后自动执行. 镜像较多的话会比较耗资源.如需手工迁移请参考官方文档. 容器和层 容器和镜像主要区别就在于容器多了最上层的容器层.所有在容器中的修改操作,都是影响的容器各自的容器层.底下镜像的层都是只读不变的. 下图展示了多个容器共享同一个镜像,但是拥有各自的容器层.互相不受影响.

理解镜像image和容器container Docker Engine是Docker的核心，是镜像 image 和容器 container 的基础。在之前 安装Docker 过程的最后一步中，我们运行了命令: docker run hello-world ,命令中包含3部分。 一个镜像 image 是一个文件系统和一些参数，在运行时使用。 image 没有状态，不会改变。容器 container 是镜像 image 的运行实例。运行上述命令时，Docker Engine执行以下操作： 检查是本地否存在 hello-world 镜像 本地不存在就从Docker Hub上下载 加载镜像到容器并运行 根据镜像的构建复杂程度，简单的镜像可能只是运行一个单一的命令就退出了，比如hello-world。但是，Docker image能干的事可远不止这么点。 image 可以启动复杂的软件，例如数据库，你可以添加数据，存储数据待以后或其他人使用。那么谁可以构建镜像呢？上面的 hello-world 是Docker官方构建的，但事实上谁都可以构建。Docker Engine允许个人或组织通过镜像创建分享软件。使用Docker Engine,你不必担心你的电脑是否可以运行镜像里的软件—— A Docker container can always run it. 来源： oschina 链接：

概述 在过去的一段时间里容器已经大量的使用到了IT软件生产的各个环节当中：从软件开发，持续集成，持续部署，测试环境到生产环境。 除了Docker官方的Docker Swarm, Docker Machine以及Docker Compose以外，开源软件社区还涌现了一系列的与容器相关的工具，涵盖了从容器编排，调度，监控，日志等等各个方面的需求。 本文将从针对软件研发流程，基于容器解决软件的持续交付问题，以及团队协作问题。 在持续集成中使用容器 构建环境统一管理 在传统模式下使用持续集成工具诸如Jenkins，在部署企业持续持续集成平台的第一个问题就是多样化的构建构建环境需求，而通常的做法是将构建Agent（服务器或者虚拟机）分配给团队由团队自己管理构建服务器的环境配置信息，安装相应的构建依赖等。 在持续集成中使用docker docker run --rm -v `pwd`:/workspace -v /tmp/.m2/repository:/root/.m2/repository --workdir /workspace maven:3-jdk-8 /bin/sh -c 'mvn clean package' 如上所示，我们可以非常方便的通过容器来完成软件包的构建，其中有几个点需要注意的是： --rm 命令可以确保当命令执行完成后能够自动清理构建时产生的容器

小贴士 Harbor是由VMware团队为企业用户设计的Registry Server开源项目,用户可以利用Harbor搭建自己的私有镜像仓库。即使你是harbor小白，也可以从本文快速从认识Harbor到利用Harbor搭建自己的企业级registry server。 Harbor特性 基于角色控制 用户和仓库都是基于项目进行组织的, 而用户基于项目可以拥有不同的权限。 基于镜像的复制策略 镜像可以在多个Harbor实例之间进行复制。 支持LDAP Harbor的用户授权可以使用已经存在LDAP用户。 镜像删除 & 垃圾回收 Image可以被删除并且回收Image占用的空间。 用户UI 用户可以轻松的浏览、搜索镜像仓库以及对项目进行管理。 镜像删除 & 垃圾回收 绝大部分的用户操作API, 方便用户对系统进行扩展。 轻松的部署功能 Harbor提供了online、offline安装,除此之外还提供了virtual appliance安装。 Harbor和docker registry关系 Harbor实质上是对docker registry做了封装,扩展了自己的业务模块.下面展示一下docker registry和Harbor的架构图用以说明。 Harbor认证过程 1、docker daemon从docker registry拉取镜像。 2、如果docker

概述 接着上一篇的内容，我们有讲到“持续交付是文化，自动化是基石，垮职能团队协作是根本”，本文将以软文的形式介绍持续交付平台WiseBuild结合Rancher容器管理平台我们是如何进行跨职能团队协作的。 文末有彩蛋！文末有彩蛋！文末有彩蛋！ 基础设施自动化 使用Rancher理由很简单，Rancher是目前市面上唯一一个能满足开箱即用的容器管理平台，同时能够支持多种编排引擎，如Rancher自己的Cattle，Google的K8S,以及Docker官方的Swarm作为容器编排引擎。同时Rancher提供的Catalog应用商店能够帮助研发团队自主创建所需要的服务实例。 基于Rancher提供的Environment我们分别为开发，测试，以及运维创建了独立的环境。确保不同职能人员之间对于环境的隔离性需求。 持续交付流水线 建立持续交付流水线的核心问题是如何定义企业的软件交付价值流动。 正如上文所说，创建持续交付流水线的本质就是定义软件的交付的价值流动，反应正式的软件交付流程。价值的流动则涉及到团队中各个职能的成员的高度协同。 基于容器的持续交付实践当中以镜像作为在不同职能人员之间的价值传递物。 开发流水线 开发人员：频繁提交持续集成，通过持续的编译，打包，测试，镜像构建，自动化验收测试等环节产生可测试的候选镜像列表(如：0.1-dev)。 以源码仓库为起点，开发人员频繁提交