容器技术

Docker学习笔记 一，运行容器 如图运行容器 容器执行完命令后就退出了。 容器的生命周期依赖于启动时执行的命令，只要该命令不结束，容器也就不会退出。 可以通过加上参数-d以后台方式启动容器，如图 CONTAINER ID 是容器的短id，前面启动容器时返回的使长id。短id是长id的前12个字符。 NAMES字段显示容器的名字，在启动容器时可以通过–name参数显示地为容器命名，如果不指定，docker会自动为容器分配名字。 二，两种进入容器的方法 我们经常需要进入到容器里去做一些工作，比如查看日志、调试、启动其他进程等。有两种方法进入容器： 1，docker attach 通过docker attach可以attach到容器启动命令的终端 2，docker exec 通过docker exec进入相同的容器，-it指定以交模式打开，执行exit退出容器，回到docker host 3，attach和exec的区别： attach直接进入容器启动命令的终端，不会启动新的进程。 exec则是在容器中打开新的终端，并且可以 启动新的进程。 如果想直接在终端查看启动命令的输出，用attach，其他情况使用exec。 如果只是为了查看启动命令的输出，可以使用docker logs命令。 三，运行容器的最佳实践 按用途容器大致可分为两类：服务类容器和工具类容器。

对于用户来说，可能一开始在不了解的情况下会对容器报以拒绝的态度，但是在尝到容器的甜头、体验到它的强大性能之后，相信大家最终是无法抵挡其魅力的。容器技术能够解决IT业目前面临的很多问题，而且优势也很明显，比如说： 1、容器具有不可变的特性。 容器将操作系统、程序库、配置文件、路径和应用程序打包在一起运行，也就是说，我们在做QA测试的时候整个镜像是什么样，投入到产品环境以后就是什么样，其性能不会有任何差距。 2、容器都非常轻量。 单个容器的内存占用很小，不像其他进程动辄占用上万MB的内存空间，容器只会给主进程分配内存，可以有效降低系统开销。 3、容器的速度更快。 虚拟机的启动时间一般都在分钟级，容器的启动速度可以达到秒级，启动容器就跟启动linux进程一样快。 虽然容器的好处这么多，但是有很多用户还不了解，还认为容器跟一般的虚拟机没什么差别。实际上，容器是可销毁的，这是容器跟虚拟机之间最大的差别。容器的存在周期很短，只要用户使用完毕，就可以立即销毁容器，所以用“朝生暮死”来形容也不算过分。 在对容器进行使用和维护时，我们应该充分利用容器的这个特性，不要再把容器当成一般的虚拟机来看待，不然就真的大材小用了。在实际使用过程中，为了最大限度地发挥容器的优势，有些错误还是少犯为妙。我总结出了下面几个要点供大家参考，在跑容器的时候大家最好还是尽量遵照这几条原则： 1) 不要将数据储存在容器中。

Dockerfile 最佳实践 本文是 Docker 官方文档 docs/archive:v1.1 中 Best practices for writing Dockerfiles 的理解和翻译。包含了 Docker 官方对编写 Dockerfile 的最佳实践和建议。这些建议是为了让你写出高效易用的 Dockerfile。Docker 官方强烈建议你遵从这些建议（实际上，如果你是在创建官方镜像，你必须得遵从这些建议）。 阅读该文档需要你已经会通过 Dockerfile 构建镜像，并了解 Dockerfile 中各条指令的用途。 一般性的指南和建议 容器应该是短暂的 通过 Dockerfile 定义的镜像所产生的容器应该尽可能短暂（生命周期短）。“短暂”，意味着可以停止和销毁容器，并且创建一个新容器并部署好所需的设置和配置工作量应该是极小的。 使用 .dockerignore 文件 一般最好的方法是将 Dockerfile 放置在一个单独地空目录下。然后，将构建镜像所需要的文件添加到目录下。为了提高构建的效率，你也可以在目录下创建一个 .dockerignore 文件来指定要忽略的文件和目录。.dockerignore 文件的排除模式语法和 Git 的 .gitignore 文件类似。 避免安装不必要的包 为了降低复杂性、减少依赖、减小文件大小、节约构建时间

Docker创建镜像的方式有两种： 一种通过commit的方式：把做了一系列操作的容器关闭，然后利用docker的commit指令：dockercommit 容器ID 镜像名：tag。然后dockerpush到镜像仓库。别人pull下来的再次启动的时候，就是你当前的操作的形态。 另一种是通过Dockerfile构建的方式：把操作的步骤通过脚本的形式写下来，然后构建的时候，Docker会按照你写的步骤，一步一步构建。这是目前主流的构建方式。 Dockerfile指令说明 FROM： 格式为 FROM<image> 或 FROM<image>:<tag> 第一条指令必须是FROM指令。并且，如果在同一个Dockerfile中创建多个镜像时，可以使用多个FROM指令（每个镜像一次）。 MAINTAINER：格式为MAINTAIER<name>，指定维护者信息。 RUN： 格式为RUN <command>或者RUN [“executable”，“param1”，“param2”]。 前者将在shell终端中运行的命令，即/bin/sh–c；后者则使用exec执行。指定使用其他终端可以通过第二种方式实现，例如RUN[“/bin/bash”，“-c”，“echohello”]。每条RUN指令将在当前镜像基础上执行指定命令，并提交为新的镜像。当命令较长时可以使用\来换行。

前言 事情是这样的，首先之前不知道git这个利器，就把代码复制来粘贴去，一个人写代码还好，几个人，特别是一个团队协同工作，这种复制粘贴，U盘拷贝代码，QQ发来发去代码的方式简直就是噩梦，非但麻烦，而且非常凌乱，反正我是受不了。然后，知道git以后才发现自己和它相见恨晚，先别说什么版本控制工具，首先光是托管代码就让我爽一番(svn工作流模式)，请注意，我现在是以完全菜鸟的视角阐述，大神们请掠过。 引入了git，整个协同工作有条不紊多了，我的思路也清晰多了，可是问题又来了，项目开始的时候我只是考虑本机开发的问题，嗯，在本机的确没有问题了，但是后面有个新人加进项目后有个问题突然暴露了出来——多人协同开发中除了代码还有环境[环境描述，依赖，缓存，参数，配置等]！首先他和我习惯用不同的系统开发(他用windows，我用linux - -)，然后各种环境问题(一会儿缺这个包，一会儿又编译不通过，等下报个错，分分钟折腾死你）。讲真，加班加点不重要，我突然想到，如果以后要部署到很多服务器，那岂不是又要重重复复做同样的功夫？想想都心累，可是docker解决了我这个困扰。 docker是个热门的虚拟容器的技术，其实我是想都没有想过要用到它的时候，虽然我之前知道有docker这么一个玩意，好像很牛逼，但是也就是仅仅停留在知道的程度，至于它能做什么，为什么会存在，我没有任何概念

## 背景 > 在开发过程中经常会遇到批量创建容器，拉取镜像等一系列的操作，如果手动一个一个的操作，那将浪费很多时间，而且毫无技术含量，因此要提高工作效率，必须让这些动作能够实现自动化，最不济也要实现半自动化，下面介绍一些我最常用的一些脚本工具。 ##场景分析 - 批量停止并删除容器(filter为需要处理的容器共同标识符) >通常我们在测试某个服务时，可能会涉及多个工具，比如web服务，我们需要启动tomcat服务器、数据库，nginx等（存在一种情况，在启动容器时需要给每个容器设定一个名字，设定名字有一个好处，我们可以把一组相互协作的容器设定为相同的前缀，一方面方便管理，另一方面，易于实现自动化），如果web服务启动失败了或者需要停止容器，则需要重启，重启时就会发生容器名字冲突，一种较好的方式就是清掉启动失败的容器，再重启。 停止容器（适用于具有相同的容器名前缀或者各个镜像的名字类似） ``` docker ps | grep filter | awk '{print $1}' | xargs docker stop ＃该条命令分为四部分，docker ps, grep filter, awk '{print $1}', xargs docker stop docker ps 用于列出所有正常运行的容器 ｜grep filter 将上一命令的结果通过管道传给过滤器

进大厂,身价翻倍的法宝来了! 主讲内容：docker/kubernetes 云原生技术，大数据架构，分布式微服务，自动化测试、运维。 腾讯课堂： 点击进入 网易课堂： 点击进入 7月1号-7月29号 8折优惠！！！ 7月1号-7月29号 8折优惠！！！ 7月1号-7月29号 8折优惠！！！ 课程简介： 第一章 熟悉Linux环境 1、Win10安装Ubuntu18.04双系统 2、熟悉Linux常用工具和命令 第二章 熟悉Docker 3、安装配置Docker 4、Docker命令实践 5、Dockerfile文件编写 ​​​​​​​ 6、常用镜像部署 ​​​​​​​ 第三章 熟悉Kubernetes ​​​​​​​ 7、kubernetes架构和部署 ​​​​​​​ 8、熟悉kubectl命令使用 ​​​​​​​ 9、k8s应用部署实践（上） ​​​​​​​ 10、k8s应用部署实践（下） ​​​​​​​ 第四章 熟悉Helm ​​​​​​​ 11、Helm安装配置 ​​​​​​​ 12、熟悉Helm应用书写规则 ​​​​​​​ 13、编写自己的Helm应用 （作者：陈玓玏） Docker中我们一般会有两种执行命令的方式，一种是直接进入容器的命令行，在终端执行并查看结果，一种是在后台执行，并不会在终端查看结果。 1、进入容器命令行 su root docker run -i -t

导读 通过提供独立的执行环境而不需要整个虚拟机的开销，容器已经成为大规模部署应用程序的很有吸引力的选择。 Docker让容器变得易于使用，因此受到欢迎。通过使多个工程团队能够利用自己的配置进行开发、对齐基准或部署可扩展的微服务架构，容器在各个地方都有用。 基于GPU的应用程序，正在迅速成为标准工作流程的一部分，特别是在深度学习领域。 这些应用程序在容器化应用程序中的部署、测试和基准测试已经迅速成为公认的惯例。 但Docker容器的本地实现不支持NVIDIA GPU，这就是为什么我们开发了nvidia-docker插件。 在这里，笔者会告诉你如何使用它。 Nvidia-docker NVIDIA GPU要求内核模块和用户级库来被识别并用于计算。有一个解决这个问题的办法，但需要安装Nvidia驱动程序和对应于NVIDIA GPU字符设备的映射。但是，如果主机的Nvidia驱动程序已更改，则安装在容器内的驱动程序版本将不再兼容，因此会中断主机上的容器使用。这违背了容器的主要特征，即可移动性。但是使用Nvidia Docker，可以无缝地配置一个GPU设备可见的容器，并准备好执行基于GPU的应用程序。 Nvidia关于nvidia-docker的博客强调了使用便携式GPU容器的两个关键点： ——与驱动程序无关的CUDA镜像 ——Docker命令行包装器

引言 最近容器比较火，容器支持对CPU和内存的资源限制，但是GPU还不是很明朗，多个容器能不能共享一个GPU呢？如果共享的话，是并行的方式还是并发的方式呢？又如何确保GPU的资源能够被高效利用呢？本文，通过查阅大量官方文档，并通过实验验证，想一探究竟~ 问题描述 GPU是深度学习的利器，相比于CPU，并行化的执行方式能够实现更高的时间效率。同时，它的价格也比较昂贵，此次想要做实验的NVIDIA TESLA V100（32G）在京东标价就高达7万人民币，楼主没钱买智能在普通的GPU上做做实验。当一个学校或者一个公司配备了一个土豪级GPU，如果想要让所有人都能使用，同时考虑到系统安全问题，可以让每个用户的编程环境被约束在一个docker容器（container）中。目前，可以实现CPU和内存的虚拟化（即限制用户可用的CPU配额和内存空间） [1] ，甚至可以实时地调整配额 [2] ，但GPU在容器中虚拟化的文章还是很少。 考虑这样一个问题，当多个用户同时在同一个GPU上提交作业时，GPU资源如何进行分配，现有的技术能否满足用户需求？ 现有技术 多进程服务（Mutil-Process Service, MPS）为多进程CUDA应用提供了共享NVIDA GPU的途径。特别地，Volta MPS（即Volta架构的GPU所提供的MPS服务）相对于pre-Volta

既然是简述，就说的简单一点了，因为 Java 的类加载是一个很大的话题。很多技术，例如 Java EE 容器、OSGi 容器、JVM 上面的动态语言，都有自己在类加载上的特殊之处。 JVM 的类加载 <br/> 先回顾一下 JVM 类加载的基本知识点： 代理模式<br/> 从上面的这个图我们可以看到，类加载器在加载某个类的时候会先将加载请求提交给它的父加载器，逐级上交。如果出于最根部的 Bootstrap Classloader 不能加载此类，类的加载请求会逐级向下传递，直到那个能加载到这个类的类加载器。 这么做的原因在于，我想，没有人会希望下面这个情况的发生。像 JDK 中的那些公用的类，同一个类会因为被不同的类加载器加载，而被认为是不同的类。同时，公用的类被多次加载也是对资源的浪费。 类的可见性<br/> 这一点简单来说就是父类加载到的类对子类是可简单，反之不成立。 Java EE 容器的类加载 <br/> Java EE 应用常以 EAR 格式来部署，这种格式也相较于 WAR 复杂，所以就只以 EAR 为例介绍了。 EAR 包中可以存在一个或多个 EJB-JAR 包和同样可以一个或多个的 WAR 包。EAR 包在 Java EE 容器中会有自己的类加载器，同时 EJB-JAR 和 WAR 也有自己的类加载器。EAR 包的类加载器会是 其 EJB-JAR 包和 WAR