容器技术

一，什么是镜像？ Docker的镜像文件是由文件系统叠加而成的。最底端是一个引导文件系统，即bootfs。Docker用户几乎永远没有机会和引导文件有什么交互，实际上，当一个容器启动之后，容器就会被移动到内存中，而创建容器镜像文件中的引导文件系统就会被卸载。 Docker镜像的第二层是root文件系统rootfs，位于引导文件系统之上，rootfs可以是一种或者多种操作系统的文件系统（比如说Debian或者Ubuntu的文件系统）。在传统的Linux引导过程中，root文件系统最先会以只读的方式加载，当引导完成并完成了完整性检查之后，才会切换到读写模式。但是在Docker里，root的文件系统只能为只读状态，并且Docker利用联合加载（union mount）技术又会在root文件系统上加载更多的只读文件系统。联合加载是指一次同时加载多个文件系统，但是外面只能看到一个文件系统。联合加载会将各层文件系统叠加在一起，这样最终的文件系统会包含所有底层的文件和目录。Docker将这样的文件系统称为镜像。一个镜像可以放在另一个镜像的顶部，位于下部的镜像称之为父镜像，可以以此类推，直到最底部，最底部的镜像是基础镜像。最后，当从一个镜像启动容器时，Docker会在该镜像的最顶层加载一个读写文件系统。我们想在Docker中运行的程序就是在这个读写层中执行的。

Kubernetes 核心概念 本文整理自 CNCF 和阿里巴巴联合举办的云原生技术公开课的课时 3：Kubernetes 核心概念。本次课程中，阿里巴巴资深技术专家、CNCF 9个 TCO 之一 李响为大家介绍了 Kubernetes 的主要功能与能力、Kubernetes 的架构以及其核心概念与核心 API 等，精彩不容错过。 本次课程的分享主要围绕以下 3 个部分： 什么是 Kubernetes ：介绍 Kubernetes 的主要功能以及能力； Kubernetes 的架构：介绍 Kubernetes 的核心组件，以及介绍它们之间是如何相互互动连接； Kubernetes 的核心概念与核心 API； 一、什么是 Kubernetes Kubernetes，从官方网站上可以看到，它是一个工业级的容器编排平台。Kubernetes 这个单词是希腊语，它的中文翻译是“舵手”或者“飞行员”。在一些常见的资料中也会看到“ks”这个词，也就是“k8s”，它是通过将8个字母“ubernete ”替换为“8”而导致的一个缩写。 Kubernetes 为什么要用“舵手”来命名呢？大家可以看一下这张图： 这是一艘载着一堆集装箱的轮船，轮船在大海上运着集装箱奔波，把集装箱送到它们该去的地方。我们之前其实介绍过一个概念叫做 container，container 这个英文单词也有另外的一个意思就是

CI/CD with Data: 通过AWS Developer Tools、 Kubernetes和Portworx来实现软件交付Pipeline的数据迁移能力 数据是应用最重要的部分。容器技术让应用打包和部署变得更快更容易。对于软件的可靠交付来说，测试环节变得更加重要。由于所有的应用都包含数据，开发团队需要办法来可靠的控制、迁移、和测试真实的应用数据。 对于一些团队来说，通过CI/CD pipeline来移动应用数据，为了保持合规性和兼容其他一些问题，一直是通过手动方式来完成的，无法有效扩展。通常只能适用于一小部分应用，而且无法在不同环境中迁移。目标应该是运行和测试有状态容器，如同无状态容器一样简单（有状态容器 – 例如数据库或者消息总线，其中运行是被追踪的；无状态容器 – 例如网页前端） 为什么测试场景中“状态-State”十分重要？一个原因是许多bug只会在真实数据的环境下才会产生。例如，你需要测试一个数据库的schema的升级，而一个小的数据集并不能完全代表包含复杂商业逻辑的关键应用。如果你需要进行端到端的完整测试，我们需要能够容易的管理我们的数据和State。 在本篇文章中，我们定义CI/CD Pipeline的参考架构，从而能够达到应用间的自动数据迁移。我们也展示如何配置CI/CD pipeline的步骤。 有状态Pipelines: 需要可迁移的卷 作为持续集成

一、基本介绍 docker镜像是容器启动的基础，镜像里面包含容器启动所需要的文件系统及其内容。docker镜像采用分层构建的机制，这种分层大致分为两部分，一部分是最底层的引导文件系统bootfs，类型有aufs，btffs或者overlay2等；另一部分真正让用户来构建用户空间并运行进程的容器称为rootfs。 bootfs：用于引导文件系统，包括BootLoader和kernel，容器启动完成后会被卸载以节约内存资源。（这里说的卸载，是从内存中移除而不是删除） rootfs：位于bootfs之上，表现为docker的根文件系统，比如/dev、/bin之类。 传统模式中，系统启动时，内核挂载rootfs时会先将其挂在为”只读“模式，自检完成后将其重新挂载为读写模式。 docker中，rootfs由内核挂载为”只读“模式，而后通过”联合挂载“技术额外挂载一个”可写“层。（我们在docker container中的操作就是可写层） 分层构建最底层的是基础镜像，位于上层的镜像称为父镜像（系统层），每添加一个镜像都是一个独立的层次。最上层为“可写层”。其它均为“只读”层。删除容器的时候，可写层会一并被删除 启动容器时，docker daemon会试图从本地获取相关镜像；本地不存在时，会从docker Registry（默认就是docker hub）中下载并保存到本地。 docker

原文: 容器化的 DevOps 工作流 对于 devops 来说，容器技术绝对是我们笑傲江湖的法宝。本文通过一个小 demo 来介绍如何使用容器技术来改进我们的 devops 工作流。 devops 的日常工作中难免会有一些繁琐的重复性劳动。比如管理 Azure 上的各种资源，我们会使用 Azure CLI 工具。同时我们也会使用 Ansible 完成一些自动化的任务。当我们同时使用二者的时候就会碰到一些尴尬的事情：Azure CLI 依赖的 python 版本为 3.x，而 Ansible 的主流版本还在依赖 python 2.x。如果我们要同时使用二者，就需要在环境中搞一些飞机。如果团队中的每个成员都需要使用这样的工具，那么每个人的环境中都需要这些飞机！下面是一些比较类似的问题： 一些工作流在陌生的环境中不能正确的工作 在工作流中加入新的工具时，整个团队都需要获取并安装这些新的工具 运行 devops 工作流不能对当前的环境产生影响(应该允许在 build 环境中运行 devops 工作流) 工作流的变化不会对运行环境产生任何的影响 实现这些需求的最好方式就是容器技术！通过容器把我们的 devops 工作流和运行环境隔离开就可以了。文本的 demo 会演示一个非常简单的使用 Azure CLI 的工作流，我们的目标是为整个团队打造一个满足以上需求的工具集(容器镜像)

这是 LXD 2.0 系列介绍文章的第四篇。 LXD 入门 安装与配置 你的第一个 LXD 容器 资源控制 镜像管理 远程主机及容器迁移 LXD 中的 Docker LXD 中的 LXD 实时迁移 LXD 和 Juju LXD 和 OpenStack 调试，及给 LXD 做贡献 因为 LXD 容器管理有很多命令，因此这篇文章会很长。 如果你想要快速地浏览这些相同的命令，你可以 尝试下我们的在线演示 ！ 可用资源限制 LXD 提供了各种资源限制。其中一些与容器本身相关，如内存配额、CPU 限制和 I/O 优先级。而另外一些则与特定设备相关，如 I/O 带宽或磁盘用量限制。 与所有 LXD 配置一样，资源限制可以在容器运行时动态更改。某些可能无法启用，例如，如果设置的内存值小于当前内存用量，但 LXD 将会试着设置并且报告失败。 所有的限制也可以通过配置文件继承，在这种情况下每个受影响的容器将受到该限制的约束。也就是说，如果在默认配置文件中设置 limits.memory=256MB ，则使用默认配置文件（通常是全都使用）的每个容器的内存限制为 256MB。 我们不支持资源限制池，将其中的限制由一组容器共享，因为我们没有什么好的方法通过现有的内核 API 实现这些功能。 磁盘 这或许是最需要和最明显的需求。只需设置容器文件系统的大小限制，并对容器强制执行。 LXD 确实可以让你这样做！

这是 LXD 2.0 系列介绍文章的第七篇。 LXD 入门 安装与配置 你的第一个 LXD 容器 资源控制 镜像管理 远程主机及容器迁移 LXD 中的 Docker LXD 中的 LXD 实时迁移 LXD 和 Juju LXD 和 OpenStack 调试，及给 LXD 做贡献 为什么在 LXD 中运行 Docker 正如我在 系列的第一篇 中简要介绍的，LXD 的重点是系统容器，也就是我们在容器中运行一个完全未经修改的 Linux 发行版。LXD 的所有意图和目的并不在乎容器中的负载是什么。它只是设置容器命名空间和安全策略，然后运行 /sbin/init 来生成容器，接着等待容器停止。 应用程序容器，例如由 Docker 或 Rkt 所实现的应用程序容器是非常不同的，因为它们用于分发应用程序，通常在它们内部运行单个主进程，并且比 LXD 容器生命期更短暂。 这两种容器类型不是相互排斥的，我们的确看到使用 Docker 容器来分发应用程序的价值。这就是为什么我们在过去一年中努力工作以便让 LXD 中运行 Docker 成为可能。 这意味着，使用 Ubuntu 16.04 和 LXD 2.0，您可以为用户创建容器，然后可以像正常的 Ubuntu 系统一样连接到这些容器，然后运行 Docker 来安装他们想要的服务和应用程序。 要求 要让它正常工作要做很多事情，Ubuntu 16.04

这是 LXD 2.0 系列介绍文章的第一篇。 LXD 入门 安装与配置 你的第一个 LXD 容器 资源控制 镜像管理 远程主机及容器迁移 LXD 中的 Docker LXD 中的 LXD 实时迁移 LXD 和 Juju LXD 和 OpenStack 调试，及给 LXD 做贡献 关于 LXD 几个常见问题 什么是 LXD ? 简单地说， LXD 就是一个提供了 REST API 的 LXC 容器管理器。 LXD 最主要的目标就是使用 Linux 容器而不是硬件虚拟化向用户提供一种接近虚拟机的使用体验。 LXD 和 Docker/Rkt 又有什么关系呢 ? 这是一个最常被问起的问题，现在就让我们直接指出其中的不同吧。 LXD 聚焦于系统容器，通常也被称为架构容器。这就是说 LXD 容器实际上如在裸机或虚拟机上运行一般运行了一个完整的 Linux 操作系统。 这些容器一般基于一个干净的发布镜像并会长时间运行。传统的配置管理工具和部署工具可以如在虚拟机、云实例和物理机器上一样与 LXD 一起使用。 相对的， Docker 关注于短期的、无状态的、最小化的容器，这些容器通常并不会升级或者重新配置，而是作为一个整体被替换掉。这就使得 Docker 及类似项目更像是一种软件发布机制，而不是一个机器管理工具。 这两种模型并不是完全互斥的。你完全可以使用 LXD 为你的用户提供一个完整的

作者 | 邓青琳（轻零） 阿里巴巴技术专家 导读 ：本文转载自阿里巴巴技术专家邓青琳(轻零)在内部的分享，他从阿里云控制台团队转岗到 ECI 研发团队（Serverless Kubernetes 背后的实现基石），从零开始了解 K8s，并从业务发展的视角整理了 K8s 是如何出现的，又是如何工作的。 前言 2019 年下半年，我做了一次转岗，开始接触到 Kubernetes，虽然对 K8s 的认识还非常的不全面，但是非常想分享一下自己的一些收获，希望通过本文能够帮助大家对 K8s 有一个入门的了解。文中有不对的地方，还请各位老司机们帮助指点纠正。 其实介绍 K8s 的文章，网上一搜一大把，而且 Kubernetes 官方文档也写的非常友好，所以直接上来讲 K8s，我觉得我是远远不如网上的一些文章讲的好的。因此我想换一个角度，通过一个业务发展的故事角度，来讲 K8s 是怎么出现的，它又是如何运作的。 故事开始 随着中国老百姓生活水平的不断提高，家家户户都有了小汽车，小王预计 5 年后，汽车报废业务将会迅速发展，而且国家在 2019 年也出台了新政策 《报废机动车回收管理办法》 ，取消了汽车报废回收的“特种行业”属性，将开放市场化的竞争。 小王觉得这是一个创业的好机会，于是找了几个志同道合的小伙伴开始了创业，决定做一个叫“淘车网”的平台。 故事发展 淘车网一开始是一个 all in

转载自：http://blog.csdn.net/m13666368773/article/details/7802126 一. IoC理论的背景 　　 我们都知道，在采用面向对象方法设计的软件系统中，它的底层实现都是由N个对象组成的，所有的对象通过彼此的合作，最终实现系统的业务逻辑。 　　如果我们打开机械式手表的后盖，就会看到与上面类似的情形，各个齿轮分别带动时针、分针和秒针顺时针旋转，从而在表盘上产生正确的时间。图1中描述的就是 这样的一个齿轮组，它拥有多个独立的齿轮，这些齿轮相互啮合在一起，协同工作，共同完成某项任务。我们可以看到，在这样的齿轮组中，如果有一个齿轮出了问 题，就可能会影响到整个齿轮组的正常运转。 齿轮组中齿轮之间的啮合关系,与软件系统中对象之间的耦合关系非常相似。对象之间的耦合关系是无法避免的，也是必要的，这是协同工作的基础。现在，伴随着工业级应用的规模越来越庞大，对象之间的依赖关系也越来越复杂，经常会出现对象之间的多重依赖性关系，因此，架构师和设计师对于系统的分析和设计，将面临 更大的挑战。对象之间耦合度过高的系统，必然会出现牵一发而动全身的情形。 　　耦合关系不仅会出现在对象与对象之间，也会出现在软件系统的各模块之间，以及软件系统和硬件系统之间。如何降低系统之间、模块之间和对象之间的耦合度，是软件工程永远追求的目标之一。 为了解决对象之间的耦合度过高的问题