首页  思维导图  详情

开发工具

2024-03-18 12:27:15   0  举报





AI智能生成

开发工具

作者其他创作

大纲/内容

Maven

本质是一个软件项目管理和理解工具。基于项目对象模型 (Project Object Model，POM) 的概念，Maven 可以管理项目的构建、报告和文档。

POM

项目对象模型 (Project Object Model，POM)

每一个 Maven 工程都有一个 pom.xml 文件，位于根目录中，包含项目构建生命周期的详细信息。

通过 pom.xml 文件，可以定义项目的坐标、项目依赖、项目信息、插件信息等等配置。

作用

项目构建：提供标准的、跨平台的自动化项目构建方式。

依赖管理：方便快捷的管理项目依赖的资源（jar 包），避免资源间的版本冲突问题。

统一开发结构：提供标准的、统一的项目结构。

坐标

groupId(必须)：定义了当前 Maven 项目隶属的组织或公司。一般分为多段，通常情况下，第一段为域，第二段为公司名称。

artifactId(必须)：定义了当前 Maven 项目的名称，项目的唯一的标识符，对应项目根目录的名称。

version(必须)：定义了 Maven 项目当前所处版本。

packaging（可选）：定义了 Maven 项目的打包方式（比如 jar，war...），默认使用 jar。

classifier(可选)：常用于区分从同一 POM 构建的具有不同内容的构件，可以是任意的字符串，附加在版本号之后。

依赖

配置

dependencies：一个 pom.xml 文件中只能存在一个这样的标签，是用来管理依赖的总标签。

dependency：包含在 dependencies 标签中，可以有多个，每一个表示项目的一个依赖。

groupId，artifactId，version(必要)：依赖的基本坐标。

type(可选)：依赖的类型，对应于项目坐标定义的 packaging。大多不必声明，默认值 jar。

scope(可选)：依赖的范围，默认值是 compile。

optional(可选)：标记依赖是否可选。

exclusions(可选)：用来排除传递性依赖，例如 jar 包冲突。

范围

classpath 用于指定 .class 文件存放的位置，类加载器会从该路径中加载所需的 .class 文件到内存中。

compile：编译依赖范围（默认），使用此依赖范围对于编译、测试、运行三种都有效。

test：测试依赖范围，只能用于测试，而在编译和运行项目时无法使用此类依赖，典型的是 JUnit。

provided：此依赖范围，对于编译和测试有效，而对运行时无效。例如比如 Tomcat 的 servlet-api.jar

runtime：运行时依赖范围，对于测试和运行有效，但是在编译主代码时无效，典型的就是 JDBC 驱动实现。

system：系统依赖范围，必须通过 systemPath 元素显示地指定依赖文件的路径，不依赖 Maven 仓库解析，所以可能会造成建构的不可移植。

传递依赖性

依赖冲突

对于 Maven 而言，同一个 groupId 同一个 artifactId 下，只能使用一个 version。
若相同类型但版本不同的依赖存在于同一个 pom 文件，只会引入后一个声明的依赖。

项目的两个依赖同时引入了某个依赖。

依赖调解

遵循路径最短优先和声明顺序优先两大原则解决问题。

排除依赖

单纯依赖 Maven 来进行依赖调解，在很多情况下是不适用的，需要我们手动排除依赖。

一般我们在解决依赖冲突的时候，都会优先保留版本较高的。因为大部分 jar 在升级的时候都会做到向下兼容。

仓库

定义

坐标和依赖是构件在 Maven 世界中的逻辑表示方式，构件的物理表示方式是文件，Maven 通过仓库来统一管理这些文件。

构件

在 Maven 世界中，任何一个依赖、插件或者项目构建的输出，都可以称为构件。

分类

本地仓库

运行 Maven 的计算机上的一个目录，它缓存远程下载的构件并包含尚未发布的临时构件。

本地仓库路径配置

settings.xml 文件

默认：${user.home}/.m2/repository

远程仓库

官方或者其他组织维护的 Maven 仓库。

分类

中央仓库：由 Maven 社区来维护，里面存放了绝大多数开源软件的包，并且是作为 Maven 的默认配置，不需要开发者额外配置。

私服：一种特殊的远程 Maven 仓库，架设在局域网内的仓库服务，私服一般被配置为互联网远程仓库的镜像，供局域网内的 Maven 用户使用。

其他的公共仓库：有一些公共仓库是为了加速访问（比如阿里云 Maven 镜像仓库）或者部分构件不存在于中央仓库中。

依赖包寻找顺序

先去本地仓库找寻，有的话，直接使用。

本地仓库没有找到的话，会去远程仓库找寻，下载包到本地仓库。

远程仓库没有找到的话，会报错。

生命周期

为了对所有的构建过程进行抽象和统一，包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有构建步骤。

Maven 定义了 3 个生命周期 META-INF/plexus/components.xml

分类

default

在没有任何关联插件的情况下定义的，是 Maven 的主要生命周期，用于构建应用程序，共包含 23 个阶段。

validate

验证项目是否正确，并且所有必要的信息可用于完成构建过程。

initialize

建立初始化状态，例如设置属性。

generate-sources

生成要包含在编译阶段的源代码。

process-sources

处理源代码。

generate-resources

生成要包含在包中的资源。

process-resources

将资源复制并处理到目标目录中，为打包阶段做好准备。

compile

编译项目的源代码。

process-classes

对编译生成的文件进行后处理，例如对 Java 类进行字节码增强/优化。

generate-test-sources

生成要包含在编译阶段的任何测试源代码。

process-test-sources

处理测试源代码。

generate-test-resources

生成要包含在编译阶段的测试源代码。

process-test-resources

处理从测试代码文件编译生成的文件

test-compile

编译测试源代码。

process-test-classes

处理从测试代码文件编译生成的文件。

test

使用合适的单元测试框架（Junit 就是其中之一）运行测试。

prepare-package

在实际打包之前，执行任何的必要的操作为打包做准备。

package

获取已编译的代码并将其打包成可分发的格式，例如 JAR、WAR 或 EAR 文件。

pre-integration-test

在执行集成测试之前执行所需的操作。例如，设置所需的环境。

integration-test

处理并在必要时部署软件包到集成测试可以运行的环境。

post-integration-test

执行集成测试后执行所需的操作。例如，清理环境。

verify

运行任何检查以验证打的包是否有效并符合质量标准。

install

将包安装到本地仓库中，可以作为本地其他项目的依赖。

deploy

将最终的项目包复制到远程仓库中与其他开发者和项目共享。

clean

clean 生命周期的目的是清理项目，共包含 3 个阶段。

pre-clean

执行一些需要在clean之前完成的工作。

clean

移除所有上一次构建生成的文件。

post-clean

执行一些需要在clean之后立刻完成的工作。

site

site 生命周期的目的是建立和发布项目站点，共包含 4 个阶段。

pre-site

执行一些需要在生成站点文档之前完成的工作。

site

生成项目的站点文档作。

post-site

执行一些需要在生成站点文档之后完成的工作，并且为部署做准备。

site-deploy

将生成的站点文档部署到特定的服务器上。

特点

这些生命周期是相互独立的，每个生命周期包含多个阶段(phase)。

这些阶段是有序的，也就是说，后面的阶段依赖于前面的阶段。当执行某个阶段的时候，会先执行它前面的阶段。
因此当我们执行 mvn test命令的时候，会执行从 validate 到 test 的所有阶段，这也就解释了为什么执行测试的时候，项目的代码能够自动编译。

插件

Maven 本质上是一个插件执行框架，所有的执行过程，都是由一个一个插件独立完成的。

分类

Build plugins：在构建时执行。

Reporting plugins：在网站生成过程中执行。

举例

maven-surefire-plugin：配置并执行单元测试。

maven-failsafe-plugin：配置并执行集成测试。

maven-javadoc-plugin：生成 Javadoc 格式的项目文档。

maven-checkstyle-plugin：强制执行编码标准和最佳实践。

jacoco-maven-plugin: 单测覆盖率。

sonar-maven-plugin：分析代码质量。

多模块管理

将一个项目分为多个模块，每个模块只负责单一的功能实现。

表现

一个 Maven 项目中不止有一个 pom.xml 文件，会在不同的目录中有多个 pom.xml 文件，进而实现多模块管理。

优点

降低代码之间的耦合性（从类级别的耦合提升到 jar 包级别的耦合）。

减少重复，提升复用性。

每个模块都可以是自解释的（通过模块名或者模块文档）。

模块还规范了代码边界的划分，开发者很容易通过模块确定自己所负责的内容。

多模块管理下，会有一个父模块，其他的都是子模块。父模块通常只有一个 pom.xml，没有其他内容。

父模块的 pom.xml 一般只定义了各个依赖的版本号、包含哪些子模块以及插件有哪些。

Gradle

定义

Gradle 就是一个运行在 JVM 上的自动化的项目构建工具，用来帮助我们自动构建项目。

Gradle 构建脚本是使用 Groovy 或 Kotlin 语言编写的，表达能力非常强，也足够灵活。

Groovy 是运行在 JVM 上的脚本语言，是基于 Java 扩展的动态语言，它的语法和 Java 非常的相似，可以使用 Java 的类库。

作用

项目构建：提供标准的、跨平台的自动化项目构建方式。

依赖管理：方便快捷的管理项目依赖的资源（jar 包），避免资源间的版本冲突问题。

统一开发结构：提供标准的、统一的项目结构。

优点

在灵活性上，Gradle 支持基于 Groovy 语言编写脚本，侧重于构建过程的灵活性，适合于构建复杂度较高的项目。

在粒度性上，Gradle 构建的粒度细化到了每一个 task 之中。并且它所有的 Task 源码都是开源的。

在扩展性上，Gradle 支持插件机制，所以我们可以复用这些插件，就如同复用库一样简单方便。

包装器

Gradle 包装器（Gradle Wrapper），它将 Gradle 再次包装，让所有的 Gradle 构建方法在 Gradle 包装器的帮助下运行。

流程

首先当我们刚创建的时候，如果指定的版本没有被下载，就先会去 Gradle 的服务器中下载对应版本的压缩包。

下载完成后需要先进行解压缩并且执行批处理文件。

后续项目每次构建都会重用这个解压过的 Gradle 版本。

优点

在给定的 Gradle 版本上标准化项目，从而实现更可靠和健壮的构建。

可以让我们的电脑中不安装 Gradle 环境也可以运行 Gradle 项目。

为不同的用户和执行环境提供新的 Gradle 版本就像更改 Wrapper 定义一样简单。

生成

本地配置好 Gradle 环境变量，因内置了 Wrapper Task，在项目根目录执行 gradle wrapper 命令即生成 Gradle Wrapper。

生成的文件

gradle-wrapper.jar：包含了 Gradle 运行时的逻辑代码。

gradle-wrapper.properties：定义了 Gradle 的版本号和 Gradle 运行时的行为属性。

gradlew：Linux 平台下，用于执行 Gralde 命令的包装器脚本。

gradlew.bat：Windows 平台下，用于执行 Gralde 命令的包装器脚本。

gradle-wrapper.properties 文件的内容如下：
distributionBase：Gradle 解包后存储的父目录。
distributionPath：distributionBase指定目录的子目录。distributionBase+distributionPath就是 Gradle 解包后的存放的具体目录。
distributionUrl：Gradle 指定版本的压缩包下载地址。
zipStoreBase：Gradle 压缩包下载后存储父目录。
zipStorePath：zipStoreBase指定目录的子目录。zipStoreBase+zipStorePath就是 Gradle 压缩包的存放位置。

更新

方式

接修改distributionUrl字段，然后执行 Gradle 命令。

执行 gradlew 命令 gradlew wrapper –-gradle-version [version]。

自定义

Gradle 已经内置了 Wrapper Task，因此构建 Gradle Wrapper 会生成其属性文件，该属性文件可以通过自定义 Wrapper Task 来设置。

也可以设置 Gradle 发行版压缩包的下载地址和 Gradle 解包后的本地存储路径等配置。

任务

任务(Task)是构建执行的单个工作单元。

Gradle 的构建是基于 Task 进行的，当你运行项目的时候，实际就是在执行了一系列的 Task 比如编译 Java 源码的 Task、生成 jar 文件的 Task。

Action

创建一个 Task 后，可以根据需要给 Task 添加不同的 Action。

一个 Task 中可以有多个 Action，从队列头部开始向队列尾部执行 Action。

Action 代表的是一个个函数、方法，每个 Task 都是一堆 Action 按序组成的执行图。

dependsOn

Task 声明依赖的关键字是dependsOn，支持声明一个或多个依赖。

执行 Task 之前，会先执行它的依赖 Task。

还可以设置默认 Task，脚本中我们不调用默认 Task ，也会执行。

Gradle 本身也内置了很多 Task 比如 copy（复制文件）、delete（删除文件）。

插件

Gradle 提供的是一套核心的构建机制，而 Gradle 插件则是运行在这套机制上的一些具体构建逻辑，其本质上和 .gradle 文件是相同。

分类

脚本插件：脚本插件就是一个普通的脚本文件，它可以被导入都其他构建脚本中。

二进制插件 / 对象插件：在一个单独的插件模块中定义，其他模块通过 Plugin ID 应用插件。大多是该插件。

Gradle 插件与 .gradle 文件

逻辑复用：将相同的逻辑提供给多个相似项目复用，减少重复维护类似逻辑开销。当然 .gradle 文件也能做到逻辑复用，但 Gradle 插件的封装性更好。

组件发布：可以将插件发布到 Maven 仓库进行管理，其他项目可以使用插件 ID 依赖。当然 .gradle 文件也可以放到一个远程路径被其他项目引用。

构建配置： Gradle 插件可以声明插件扩展来暴露可配置的属性，提供定制化能力。当然 .gradle 文件也可以做到，但实现会麻烦些。

构建生命周期

Gradle 构建的生命周期有三个阶段：初始化阶段，配置阶段和运行阶段。

在初始化阶段与配置阶段之间、配置阶段结束之后、执行阶段结束之后，可以加一些定制化的 Hook。

初始化阶段

Gradle 支持单项目和多项目构建。在初始化阶段，Gradle 确定哪些项目将参与构建，并为每个项目创建一个 Project 实例。

本质

就是执行 settings.gradle 脚本，从而读取整个项目中有多少个 Project 实例。

配置阶段

Gradle 会解析每个工程的 build.gradle 文件，
创建要执行的任务子集和确定各种任务之间的关系，以供执行阶段按照顺序执行，并对任务的做一些初始化配置。

每个 build.gradle 对应一个 Project 对象，配置阶段执行的代码包括 build.gradle 中的各种语句、闭包以及 Task 中的配置语句。

在配置阶段结束后，Gradle 会根据 Task 的依赖关系会创建一个有向无环图。

运行阶段

在运行阶段，Gradle 根据配置阶段创建和配置的要执行的任务子集，执行任务。

与 Maven 差异。

Git

版本控制

一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。

作用

可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态。

可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因。

分类

本地版本控制系统

复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。

唯一的好处就是简单，但是特别容易犯错。

集中化的版本控制系统

集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）。

一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

问题

单点故障：中央服务器宕机，则其他人无法使用；如果中心数据库磁盘损坏又没有进行备份，你将丢失所有数据。

必须联网才能工作：受网络状况、带宽影响。

分布式版本控制系统

分布式版本控制系统（Distributed Version Control System，简称 DVCS）。

客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。

应用

Git

实现方式

差异比较

以文件变更列表的方式存储信息。将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。

原理

每次更新文件，只记录更新内容，最终版本只需要将这些原文件和这些增加进行相加就行了。

问题

更新特别多的话，如果我们要得到最终的文件会耗费时间和性能。

应用

CVS、Subversion、Perforce、Bazaar 等等。

记录快照

把数据看作是对小型文件系统的一组快照。对待数据更像是一个快照流。

原理

提交更新或保存项目状态时，对当时的全部文件制作一个快照并保存这个快照的索引。

为了高效，如果文件没有修改，就不再重新存储该文件，而是只保留一个链接指向之前存储的文件。

应用

Git

状态

已提交（committed）：数据已经安全的保存在本地数据库中。

已修改（modified）：已修改表示修改了文件，但还没保存到数据库中。

已暂存（staged）：表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。

工作区

Git 仓库(.git directory)、工作目录(Working Directory) 、暂存区域(Staging Area) 。

流程

在工作目录中修改文件。

暂存文件，将文件的快照放入暂存区域。

提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。

使用

获取 Git 仓库

在现有目录中初始化仓库：进入项目目录运行 git init 命令，该命令将创建一个名为 .git 的子目录。

从一个服务器克隆一个现有的 Git 仓库：git clone [url] 自定义本地仓库的名字。

记录每次更新到仓库

检测当前文件状态：git status。

提出更改（把它们添加到暂存区）：git add filename (针对特定文件)、git add *(所有文件)、git add *.txt（支持通配符，所有 .txt 文件）。

忽略文件：.gitignore 文件。

提交更新：git commit -m "代码提交信息" （每次提交前，先用 git status 看下是否都已暂存起来了，然后再运行提交命令 git commit）。

跳过使用暂存区域更新的方式 : git commit -a -m "代码提交信息"。

移除文件：git rm filename （从暂存区域移除，然后提交。）

对文件重命名：git mv A.md B.md(这个命令相当于mv A.md B.md、git rm A.md、git add B.md 这三条命令的集合)。

推送改动到远程仓库

没有远端仓库：使用如下命令添加：git remote add origin <server>，然后再提交改动到远端仓库。

将这些改动提交到远端仓库：git push origin master (可以把 master 换成你想要推送的任何分支)

Docker

容器

容器就是将软件打包成标准化单元，以用于开发、交付和部署。

容器镜像是轻量的、可执行的独立软件包，包含软件运行所需的所有内容：代码、运行时环境、系统工具、系统库和设置。

容器化软件适用于基于 Linux 和 Windows 的应用，在任何环境中都能够始终如一地运行。

容器赋予了软件独立性，使其免受外在环境差异的影响，从而有助于减少团队间在相同基础设施上运行不同软件时的冲突。

容器虚拟化的是操作系统而不是硬件，容器之间是共享同一套操作系统资源的。

定义

Docker 是世界领先的软件容器平台。

Docker 使用 Google 公司推出的 Go 语言进行开发实现，基于 Linux 内核提供的 CGroup 功能和 namespace 来实现的，以及 AUFS 类的 UnionFS 等技术。

由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。

Docker 能够自动执行重复性任务，例如搭建和配置开发环境，从而解放了开发人员以便他们专注在真正重要的事情上：构建杰出的软件。

用户可以方便地创建和使用容器，把自己的应用放入容器。容器还可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。

思想

集装箱、标准化（ ① 运输方式 ② 存储方式 ③ API 接口）、隔离。

特点

轻量 : 在一台机器上运行的多个 Docker 容器可以共享这台机器的操作系统内核；它们能够迅速启动，只需占用很少的计算和内存资源。
镜像是通过文件系统层进行构造的，并共享一些公共文件。这样就能尽量降低磁盘用量，并能更快地下载镜像。

标准 : Docker 容器基于开放式标准，能够在所有主流 Linux 版本、Microsoft Windows 以及包括 VM、裸机服务器和云在内的任何基础设施上运行。

安全 : Docker 赋予应用的隔离性不仅限于彼此隔离，还独立于底层的基础设施。Docker 默认最强的隔离，因此问题只会出现在单个容器而不是整台机器。

优点

一致的运行环境

Docker 的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性。

更快速的启动时间

可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。

隔离性

避免公用的服务器，资源会容易受到其他用户的影响。

弹性伸缩，快速扩展

善于处理集中爆发的服务器使用压力。

迁移方便

以很轻易的将在一个平台上运行的应用，迁移到另一个平台上，而不用担心运行环境的变化导致应用无法正常运行的情况。

持续交付和部署

使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。

容器 VS 虚拟机

传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整操作系统，在该系统上再运行所需应用进程。
容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。
因此容器要比传统虚拟机更为轻便。

虚拟机更擅长于彻底隔离整个运行环境。例如，云服务提供商通常采用虚拟机技术隔离不同的用户。
Docker 通常用于隔离不同的应用，例如前端，后端以及数据库。

容器与虚拟机两者是可以共存的。

基本概念

镜像（Image）

一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，
还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

原理

Docker 设计时，就充分利用 Union FS 的技术，将其设计为分层存储的架构。镜像实际是由多层文件系统联合组成。

镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。

容器（Container）

容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

实质

实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的命名空间。容器也是分层存储。

容器存储层的生存周期和容器一样，容器消亡时，容器存储层也随之消亡。因此，任何保存于容器存储层的信息都会随容器删除而丢失。

最佳实践

容器不应该向其存储层内写入任何数据，容器存储层要保持无状态化。

所有的文件写入操作，都应该使用数据卷（Volume）、或者绑定宿主目录。使用后，容器可以随意删除、重新 run ，数据却不会丢失。

注意：直接对宿主(或网络存储)发生读写，其性能和稳定性更高。

仓库（Repository）

如果需要在其它服务器上使用这个镜像，就需要一个集中的存储、分发镜像的服务，这个服务就是仓库（Repository）。

一个 Docker Registry 中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。

一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。

Docker Registry 公开服务

开放给用户使用、允许用户管理镜像的 Registry 服务。

官方的 Docker Hub（默认的 Registry）、时速云镜像库、网易云镜像服务、DaoCloud 镜像市场、阿里云镜像库等。

私有 Docker Registry

本地搭建私有 Docker Registry 。Docker 官方提供了 Docker Registry 镜像，可以直接使用做为私有 Registry 服务。

常见命令

docker version # 查看docker版本
docker images # 查看所有已下载镜像，等价于：docker image ls 命令
docker container ls # 查看所有容器
docker ps #查看正在运行的容器
docker image prune # 清理临时的、没有被使用的镜像文件。-a, --all: 删除所有没有用的镜像，而不仅仅是临时文件；
docker search mysql # 查看mysql相关镜像
docker pull mysql:5.7 # 拉取mysql镜像
docker image ls # 查看所有已下载镜像
docker rmi f6509bac4980 # 或者 docker rmi mysql

搬运工人

Build（构建镜像）：镜像就像是集装箱包括文件以及运行环境等等资源。

Ship（运输镜像）：主机和仓库间运输，这里的仓库就像是超级码头一样。

Run （运行镜像）：运行的镜像就是一个容器，容器就是运行程序的地方。

底层原理

虚拟化技术

一种资源管理技术，是将计算机的各种实体资源，予以抽象、转换后呈现出来并可供分割、组合为一个或多个电脑配置环境。

LXC

名称来自 Linux 软件容器（Linux Containers）的缩写，一种操作系统层虚拟化（Operating system–level virtualization）技术。

它将应用软件系统打包成一个软件容器（Container），内含应用软件本身的代码，以及所需要的操作系统核心和库。

通过统一的名字空间和共用 API 来分配不同软件容器的可用硬件资源，创造出应用程序的独立沙箱运行环境。

LXC 技术主要是借助 Linux 内核中提供的 CGroup 功能和 namespace 来实现的，通过 LXC 可以为软件提供一个独立的操作系统运行环境。