云计算深度实践者。《每天5分钟玩转OpenStack》《每天5分钟玩转Docker容器技术》作者。
前面学习了如何限制容器对内存和CPU的使用,本节我们来看 Block IO。 Block IO 是另一种可以限制容器使用的资源。Block IO 指的是磁盘的读写,docker 可通过设置权重、限制 bps 和 iops 的方式控制容器读写磁盘的带宽,下面分别讨论。
上节学习了如何限制容器对内存的使用,本节我们来看CPU。 默认设置下,所有容器可以平等地使用 host CPU 资源并且没有限制。 Docker 可以通过 -c 或 --cpu-shares 设置容器使用 CPU 的权重。
一个 docker host 上会运行若干容器,每个容器都需要 CPU、内存和 IO 资源。对于 KVM,VMware 等虚拟化技术,用户可以控制分配多少 CPU、内存资源给每个虚拟机。对于容器,Docker 也提供了类似的机制避免某个容器因占用太多资源而影响其他容器乃至整个 host 的性能。
前面我们已经讨论了容器的各种操作,对容器的生命周期有了大致的理解,下面这张状态机很好地总结了容器各种状态之间是如何转换的。 如果掌握了前面的知识,要看懂这张图应该不难。不过有两点还是需要补充一下: 可以先创建容器,稍后再启动。
前面讨论了如何运行容器,本节学习容器的其他常用操作。 stop/start/restart 容器 通过 docker stop 可以停止运行的容器。 容器在 docker host 中实际上是一个进程,docker stop 命令本质上是向该进程发送一个 SIGTERM 信号。
按用途容器大致可分为两类:服务类容器和工具类的容器。 1. 服务类容器以 daemon 的形式运行,对外提供服务。比如 web server,数据库等。通过 -d 以后台方式启动这类容器是非常合适的。如果要排查问题,可以通过 exec -it 进入容器。
我们经常需要进到容器里去做一些工作,比如查看日志、调试、启动其他进程等。有两种方法进入容器:attach 和 exec。 docker attach 通过 docker attach 可以 attach 到容器启动命令的终端,例如: 这次我们通过 “长ID” attach 到了容器的启动命令终端,之后看到的是echo 每隔一秒打印的信息。
上一章我们学习了如何构建 Docker 镜像,并通过镜像运行容器。本章将深入讨论容器:学习容器的各种操作,容器各种状态之间如何转换,以及实现容器的底层技术。 运行容器 docker run 是启动容器的方法。
本节我们对 Docker 镜像做个小结。 这一部分我们首先讨论了镜像的分层结构,然后学习了如何构建镜像,最后实践使用 Docker Hub 和本地 registry。 下面是镜像的常用操作子命令: images 显示镜像列表 history 显示镜像构建历史 commit 从容器创建...
Docker Hub 虽然非常方便,但还是有些限制,比如: 需要 internet 连接,而且下载和上传速度慢。 上传到 Docker Hub 的镜像任何人都能够访问,虽然可以用私有 repository,但不是免费的。
保存和分发镜像的最直接方法就是使用 Docker Hub。 Docker Hub 是 Docker 公司维护的公共 Registry。用户可以将自己的镜像保存到 Docker Hub 免费的 repository 中。
我们已经学会构建自己的镜像了。接下来的问题是如何在多个 Docker Host 上使用镜像。 这里有几种可用的方法: 用相同的 Dockerfile 在其他 host 构建镜像。 将镜像上传到公共 Registry(比如 Docker Hub),Host 直接下载使用。
RUN、CMD 和 ENTRYPOINT 这三个 Dockerfile 指令看上去很类似,很容易混淆。本节将通过实践详细讨论它们的区别。 简单的说: RUN 执行命令并创建新的镜像层,RUN 经常用于安装软件包。
是时候系统学习 Dockerfile 了。下面列出了 Dockerfile 中最常用的指令,完整列表和说明可参看官方文档。 FROM指定 base 镜像。 MAINTAINER设置镜像的作者,可以是任意字符串。
包括 Dockerfile 在内的任何脚本和程序都会出错。有错并不可怕,但必须有办法排查,所以本节讨论如何 debug Dockerfile。 先回顾一下通过 Dockerfile 构建镜像的过程: 从 base 镜像运行一个容器。
上一节我们学习了镜像的分层结构,今天讨论镜像的缓存特性。 Docker 会缓存已有镜像的镜像层,构建新镜像时,如果某镜像层已经存在,就直接使用,无需重新创建。 举例说明。在前面的 Dockerfile 中添加一点新内容,往镜像中复制一个文件: root@ubuntu:~# ...
Dockerfile 是一个文本文件,记录了镜像构建的所有步骤。 第一个 Dockerfile 用 Dockerfile 创建上节的 ubuntu-with-vi,其内容则为: 下面我们运行 docker build 命令构建镜像并详细分析每个细节。
对于 Docker 用户来说,最好的情况是不需要自己创建镜像。几乎所有常用的数据库、中间件、应用软件等都有现成的 Docker 官方镜像或其他人和组织创建的镜像,我们只需要稍作配置就可以直接使用。 使用现成镜像的好处除了省去自己做镜像的工作量外,更重要的是可以利用前人的经验。
Docker 支持通过扩展现有镜像,创建新的镜像。 实际上,Docker Hub 中 99% 的镜像都是通过在 base 镜像中安装和配置需要的软件构建出来的。比如我们现在构建一个新的镜像,Dockerfile 如下: ① 新镜像不再是从 scratch 开始,而是直接在 Debian base 镜像上构建。
上一节我们介绍了最小的 Docker 镜像,本节讨论 base 镜像。 base 镜像有两层含义: 不依赖其他镜像,从 scratch 构建。
镜像是 Docker 容器的基石,容器是镜像的运行实例,有了镜像才能启动容器。 本章内容安排如下: 首先通过研究几个典型的镜像,分析镜像的内部结构。 然后学习如何构建自己的镜像。 最后介绍怎样管理和分发镜像。
Docker 的核心组件包括: Docker 客户端 - Client Docker 服务器 - Docker daemon Docker 镜像 - Image Registry Docker 容器 - Container Docker 架构如下图所示: Docker 采用的是 Client/Server 架构。
学习任何东西都可以按照3W的框架进行,容器技术也是一样,先回答 What、Why 和 How 这三个问题。 What - 什么是容器? 容器是一种轻量级、可移植、自包含的软件打包技术,使应用程序可以在几乎任何地方以相同的方式运行。
这两天制作的视频,安装 Docker 并运行第一个容器,希望对大家有帮助。 可在公众号(cloudman6)回复 “容器” 查看。
为了让大家对容器有个感性认识,我们将尽快让一个容器运行起来。 首先我们需要搭建实验环境。 环境选择 容器需要管理工具、runtime 和操作系统,我们的选择如下: 管理工具 - Docker Engine因为 Docker 最流行使用最广泛。
容器生态系统包含核心技术、平台技术和支持技术三个方面。上一节我们讨论了核心技术,今天讨论另外两个部分。 容器平台技术 容器核心技术使得容器能够在单个 host 上运行。而容器平台技术能够让容器作为集群在分布式环境中运行。
《每天5分钟玩转容器技术》是一个有关容器技术的教程,有下面两个特点: 系统讲解当前最流行的容器技术。从容器的整个生态环境到各个具体的技术,从整体到细节逐一讨论。 重实践并兼顾理论。
本节介绍几个 cloud-init 的典型应用:设置 hostanme,设置用户初始密码,安装软件。 设置 hostname cloud-init 默认会将 instance 的名字设置为 hostname。
上一节最后问了大家一个问题:如果 subnet 没有开 DHCP,会是怎样一个情况? 在其他条件不变的情况下,cloud-init 依然会完成那 3 个步骤,也就是说网卡还是会被配置成 dhcp 模式,只是最后网卡没办法获得 IP 而已。
instance 的网卡是如何被配置并拉起的?这是理解和用好 cloud-init 非常关键的一步。我们先讨论一个最简单基础的场景:镜像中没有安装 cloud-init。 此时 instance 启动时网卡能不能被拉起来完全 靠运气!是的,就是运气。
cloud-init 是 linux 的一个工具,当系统启动时,cloud-init 可从 nova metadata 服务或者 config drive 中获取 metadata,完成包括但不限于下面的定制化工作: 设置 default locale 设置 hostname 添加 ssh keys到 .
如果 instance 无法通过 metadata service 获取 metadata(无 DHCP 或者 nova-api-metadata 服务),instance 还可以通过 config drive 获得 metadata。
要想从 nova-api-metadata 获得 metadata,需要指定 instance 的 id。但 instance 刚启动时无法知道自己的 id,所以 http 请求中不会有 instance id 信息,id 是由 neutron-metadata-agent 添加进去的。
OpenStack 默认通过 l3-agent 创建和管理 neutron-ns-metadata-proxy,进而与 nova-metadata-api 通信。但不是所有环境都有 l3-agent,比如直接用物理 router 的场景。
接上节,启动 neutron router 后 instance c1 终于拿到了 metadata, 从下面 c1 的启动日志可知: c1 所认为的 metadata 服务地址是 169.254.169.254,端口为 80。
我们将通过实验详细分析 instance 从 nova-api-metadata 获取信息的完整过程。 环境介绍 1. 一个 all-in-one 环境(多节点类似)。 2. 已创建 neutron 网络 test_net,DHCP 已启动。
下面是 Metadata Service 的架构图,本节我们详细讨论各个组件以及它们之间的关系。 nova-api-metadata nova-api-metadata 是 nova-api 的一个子服务,它是 metadata 的提供者,instance 可以通过 nova-api-metadata 的 REST API 来获取 metadata 信息。
实现 instance 定制化,cloud-init(或 cloudbase-init)只是故事的一半,metadata service 则是故事的的另一半。两者的分工是:metadata service 为 cloud-init 提供自定义配置数据,cloud-init 完成配置工作。
这是 OpenStack 实施经验分享系列的第 13 篇。 instance snapshot 操作可用于备份或者将 instance 保存为新的 image。如果在生产系统中执行 snapshot 操作,必须确保此操作快速且安全。
这是 OpenStack 实施经验分享系列的第 12 篇。 问题描述 客户报告了一个问题:对 instance 执行 migrate 操作,几个小时了一直无法完成,不太正常。 问题分析 遇到这种情况,第一个要检查的就是 instance 所在计算节点的 nova-compute.log 日志,但不幸的是没有发现相关的错误。
这是 OpenStack 实施经验分享系列的第 11 篇。 本节教大家更新 OpenStack 组件的方法。请注意,是更新(Update)而不是升级(Upgrade)。更新是给组件打补丁,版本不变;而升级是刷新版本,比如从 kilo 升级到 liberty。
这是 OpenStack 实施经验分享系列的第 10 篇。是软件就会有 bug,OpenStack 也不例外,只要用它就一定会遇到故障。Troubleshooting(故障排除)是运维 OpenStack 等开源项目的重要技能,遇到问题后一定要借助社区的力量定位、搜索、分析并解决问题。
这是 OpenStack 实施经验分享系列的第 9 篇。 OpenStack 用多了,经常会遇到这种情况:对 instance 执行某个操作如果失败了就会处于 “error” 状态: 而且这时我们除了删除 instance 外,几乎做不了其他操作。
这是 OpenStack 实施经验分享系列的第 8 篇。 先来看张图:这是 Nova 的架构图,我们可以看到有两个组件处于架构的中心位置:数据库和Queue。数据库保存状态信息,而几乎所有的 nova-* 服务都直接依赖于 Queue 实现服务之间的通信和调用。
这是 OpenStack 实施经验分享系列的第 7 篇。 传统运维中为服务器配置静态 IP 是再常见不过的了。但在 OpenStack 环境下只能指定 network,IP 都是 Neutron 从 subnet IP 池中自动分配的。
这是 OpenStack 实施经验分享系列的第 6 篇。 在项目实施过程中,经常会有添加删除网卡的需求。比如一个运行数据库的 instance,初始只有一个网卡,数据库服务和备份共用这块网卡,后来为提高性能以及合规的要求需要加一块网卡专门做备份用。
这是 OpenStack 实施经验分享系列的第 5 篇。 对于 Linux 镜像,cloud-init 负责 instance 的初始化工作。cloud-init 功能很强大,能做很多事情,而且我们可以通过修改配置文件灵活定制 cloud-init。
这是 OpenStack 实施经验分享系列的第 4 篇。 cloudbase-init 的一项功能是自动扩展 windows 的 C 盘。比如 windows 镜像是 20G,在部署 instance 时选择的 flavor 磁盘定义是 40G,那么 instance 部署时 cloudbase-init 会自动将 C 盘扩到 40G。
这是 OpenStack 实施经验分享系列的第 3 篇。 问题描述 通过上一节部署出来的 Windows instance 有时候会发现操作系统时间总是慢 8 个小时,即使手工调整好时间和时区,下次 instance 重启后又会差 8 个小时。
这是 OpenStack 实施经验分享系列的第 2 篇。 OpenStack 通过 Glance 镜像部署 instance,上一节我们介绍了 linux 镜像制作方法,windows 镜像与 linux 有很大不同,今天我们以 windows2008 为例详细讨论。