Container

咱们通常能够将一台或多台服务器作为Docker主机，应用容器跑一些开源的工具服务。而往往咱们不晓得该什么时候这个这些利用有了更新的版本，最近发现了一个开源的工具，能够查看主机上运行的容器的镜像是否有更新，并能够通过集成多种渠道发送更新告诉，这款工具就是 DIUN(Docker Image Update Notifier) 。 DUIN介绍DUIN是一款应用GO语言编写的命令行工具，能够本地运行，也能够通过容器运行（开发者提供了构建好的镜像 )，当监控的容器镜像在相应的注册表（Registry）中更新时，能够接管到相应的告诉。 DUIN反对多种监控配置（Providers）： Docker - 剖析Docker主机上运行容器的镜像，并查看其更新Podman - 相似Docker，须要Podman以服务形式启动Kubernetes - 剖析Kubernetes集群中的Pods，查看pod应用的镜像Swarm - 剖析Swarm集群中服务应用的镜像Nomad - 相似Docker，剖析Nomad引擎运行的镜像Dockerfile - 剖析Dockerfile中援用的镜像File - yaml格局的配置文件，间接配置须要查看的镜像信息DUIN反对集成多种告诉渠道，例如 Discord， Slack，Matrix，Telegram 以及 Webhook 等。 DUIN应用示例这里将演示在Docker主机上应用Docker Compose来运行duin服务，并集成Slack，将告诉发送到相应的频道。 docker-compose.yml : services: diun: image: crazymax/diun:latest container_name: diun hostname: home200-diun command: serve volumes: - diundata:/data - "/var/run/docker.sock:/var/run/docker.sock" environment: - "TZ=Asia/Shanghai" - "LOG_LEVEL=info" - "LOG_JSON=false" - "DIUN_WATCH_WORKERS=20" - "DIUN_WATCH_SCHEDULE=0 */6 * * *" - "DIUN_WATCH_JITTER=30s" - "DIUN_PROVIDERS_DOCKER=true" - "DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true" - "DIUN_NOTIF_SLACK_WEBHOOKURL=https://hooks.slack.com/services/xxxxxxxxxxxxx" restart: on-failurevolumes: diundata:下面的环境变量中 ...

[图片源：https://bell-sw.com/announcem...] 介绍测试环境配置容量 POD 容量配置JVM 容量配置 神秘的 MaxDirectMemorySize 默认值maxThreadCount 最大线程数起源使用量 Java 的视角看使用量 如何采集理论使用量原生利用的视角看使用量 *lib.so 动静库占用*.jar mapping 占用glibc malloc 耗费GC 内存耗费tmpfs 内存耗费操作系统 RSS CGroup 限度潜在问题和举荐解决办法 Native Buffer 限度glibc malloc arena 的节约Jetty 线程池Java code cache 慢涨容器的内存限度瞻望免责申明领会介绍置信很多人都晓得，云环境中，所有服务都必须作资源限度。内存作为一个重要资源当然不会例外。限度说得容易，但如何在限度的同时，保障服务的性能指标(SLA)就是个技术和艺术活。 为利用内存设置下限，从来不是个容易的事。因为设置下限的理据是： 应用程序对内存的应用和回收逻辑，而这个逻辑个别异样地简单古代操作系统简单的虚拟内存治理、物理内存调配、回收机制如果是 Java ，还要加上： JVM 中各类型组件的内存管理机制以上 3 个方面还能够进一步细分。每一个细分都有它的内存机制。而只有咱们漏算了其中一个，就有可能让利用总内存应用超限。 而让人揪心的是，当利用总内存应用超限时，操作系统会无情地杀死利用过程(OOM, Out Of Memory)。而很多人对这一无所觉，只晓得容器重启了。而这可能是连锁反应的开始： 如果容器 OOM 的起因只是个偶尔，那还好说。如果是个 BUG 引起的，那么这种 OOM 可能会在服务的所有容器中一一暴发，最初服务瘫痪原来服务容器群的资源就缓和，一个容器 OOM 敞开了，负载平衡把流量分到其它容器，于是其它容器也呈现同样的 OOM。最初服务瘫痪JVM 是个 Nice 的经理，在发现内存缓和时，就不厌其烦地进行利用线程和执行 GC，而这种内存缓和的信号，在设计界称为“背压(Backpressure)”。但操作系统相同，是个雷厉风行的司令，一发现有过程超限，间接一枪 OOM Killed。 或者你深入研究过 cgroup memory，它其实也有一个 Backpressure 的告诉机制，不过当初的容器和 JVM 均疏忽之。终上所述，容器过程 OOM Kllled 是件应该防止，但须要深入研究能力防止的事件。 ...

引言这是如何制作最小化Docker镜像系列文章的第四篇：动态二进制文件。 在第一篇文章中，我谈到了如何通过编写更好的Dockerfiles创立较小的镜像；在第二篇文章中，我探讨了如何应用docker-squash压缩镜像层以制作较小的镜像；在第三篇文章中，我介绍了如何将Alpine Linux用作较小的根底镜像。 在这篇文章中，我将探讨制作最小化镜像的最终形式：动态二进制文件。 如果应用程序没有任何依赖关系，并且除了应用程序自身之外什么都不须要，这种状况下该怎么做？ 这就是动态二进制文件所实现的，它们包含运行在二进制文件自身中的动态编译程序的所有依赖项。为了了解其含意，让咱们退后一步。 动静链接大多数应用程序是应用称为动静链接的过程构建的，每个应用程序在编译时都是以这样一种形式来实现的，即它定义了须要运行的库，但实际上在其外部并不蕴含这些库。 这对于操作系统发行版来说十分重要，因为能够独立于应用程序更新库，然而在容器内运行应用程序时，它并不是那么重要。 每个容器镜像都蕴含它将要应用的所有文件，因而无论如何都不会重用这些库。 来看一个例子，创立一个简略的C++程序并按如下所示进行编译，则将取得一个动静链接的可执行文件。 ianlewis@test:~$ cat hello.cpp #include <iostream>int main() { std::cout << "Hello World!\n"; return 0;}ianlewis@test:~$ g++ -o hello hello.cpp$ ls -lh hello-rwxrwxr-x 1 ianlewis ianlewis 8.9K Jul 6 07:31 hellog++实际上正在执行两个步骤，它正在编译我的程序并将其链接。 编译这一步只会创立一个一般的C++指标文件，链接这一步是增加运行应用程序所需的依赖项。 辛运的是，大多数编译工具都做到了这一点，编译和链接能够按如下形式进行。 ianlewis@test:~$ g++ -c hello.cpp -o hello.oianlewis@test:~$ g++ -o hello hello.oianlewis@test:~$ ls -lhtotal 20K-rwxrwxr-x 1 ianlewis ianlewis 8.9K Jul 6 07:41 hello-rw-rw-r-- 1 ianlewis ianlewis 85 Jul 6 07:31 hello.cpp-rw-rw-r-- 1 ianlewis ianlewis 2.5K Jul 6 07:41 hello.o通过在Linux零碎上对其运行ldd命令会输入命令行指定的每个程序或共享对象所需的共享对象（共享库） 。 如果你应用的是Mac OS，则能够通过运行otool -L取得雷同的信息。 ...

引言这是系列文章的第三篇，在第一篇文章中，我概述了容器运行时，同时介绍了低级容器运行时与高级容器运行时之间的区别；在第二篇文章中我具体介绍了低级容器运行时，并构建了一个简略的低级容器运行时。高级容器运行时的技术栈要高于低级容器运行时，低级容器运行时负责容器的理论运行，而高级容器运行时负责容器镜像额传输和治理。 通常，高级运行时提供了守护程序应用程序和API，近程应用程序能够应用它们来逻辑运行容器并对其进行监督，但 它们位于底层运行时或委托给底层运行时或其余高层运行时进行理论工作。 高级运行时还能够提供听起来有些低级的性能，但这些性能能够在计算机上的各个容器中应用。 例如，其中一个性能可能是网络名称空间的治理，并容许容器退出另一个容器的网络名称空间。 这里有一个概念图，用于理解各个组件如何组合在一起： 高级运行时示例为了更好地了解高级运行时，请看一些示例。 像低级运行时一样，每个运行时都实现了不同的性能。 DockerDocker是最早的开源容器运行时之一。 它是由提供PaSS服务的公司dotCloud开发的，用于在容器中运行其用户的Web应用程序。 Docker是一个容器运行时，其中蕴含构建，打包，共享和运行容器。 Docker具备C/S架构，最后是作为整体守护程序，dockerd和docker client程序构建的。 该守护程序提供了构建容器，治理镜像和运行容器的大多数逻辑，以及一个API，能够从客户端命令行运行命令从守护程序获取信息。 它是第一个风行的运行时，它整合了在构建和运行容器的生命周期中所需的全副性能。 Docker最后同时实现了高级和低级运行时性能，但起初这些局部被合成为runc和容器化的独自我的项目。 Docker当初包含dockerd守护程序，docker-containerd守护程序以及docker-runc。 docker-containerd和docker-runc只是Docker打包的“香草”容器和runc的版本。dockerd提供诸如构建镜像之类的性能，而dockerd应用docker-containerd提供诸如镜像治理和运行中的容器之类的性能。 例如，Docker的构建步骤实际上只是一些逻辑，该逻辑解释Dockerfile，应用containerd在容器中运行必要的命令，并将生成的容器文件系统保留为镜像。 containerdcontainerd是从Docker分离出来的高级运行时。 就像runc一样被合成为低级运行时组件，containered也被合成为Docker的高级运行时组件。 containerd实现下载镜像，治理镜像以及从镜像运行容器。 当须要运行容器时，它将镜像解压缩到OCI runtime bundle中，而后将其打包到runc来运行它。 容器化还提供了可用于与其交互的API和客户端应用程序，容器命令行客户端是ctr。 ctr相干命令提取容器镜像： $ sudo ctr images pull docker.io/library/redis:latest列出以后所有镜像： $ sudo ctr images list从镜像运行一个容器： $ sudo ctr container create docker.io/library/redis:latest redis列出运行的容器： $ sudo ctr container list进行容器： $ sudo ctr container delete redis这些命令相似于用户与Docker交互的形式，然而，与Docker相比，containerd只专一于运行中的容器，因而它不提供构建容器的机制。 Docker专一于最终用户和开发人员用例，而containerd则专一于操作具体的容器实例，例如在服务器上运行容器，而诸如构建容器镜像之类的工作留给其余工具解决。 rkt在上一篇文章中，我提到rkt同时具备低级和高级性能的运行时，与Docker一样，rkt容许您构建容器镜像，在本地存储库中获取和治理容器镜像，并通过单个命令运行它们。 rkt不足Docker的性能，因为它不提供长期运行的守护程序和近程API。 你能够应用如下命令获取近程镜像： $ sudo rkt fetch coreos.com/etcd:v3.3.10列出本地镜像： $ sudo rkt image listID NAME SIZE IMPORT TIME LAST USEDsha512-07738c36c639 coreos.com/rkt/stage1-fly:1.30.0 44MiB 2 minutes ago 2 minutes agosha512-51ea8f513d06 coreos.com/oem-gce:1855.5.0 591MiB 2 minutes ago 2 minutes agosha512-2ba519594e47 coreos.com/etcd:v3.3.10 69MiB 25 seconds ago 24 seconds ago删除镜像： ...

前言 在波及到容器时你常常听到一个术语：容器运行时。每个人对这个术语都有不同的了解，即便在容器社区也是这种状况。这篇文章是这个系列文章的第一篇，它们别离是： 容器运行时介绍：为什么它们令人如此困惑？深刻Low-Level 运行时深刻High-Level 运行时Kubernetes运行时和CRI 这篇文章将会介绍容器运行时是什么和为什么会让人如此困惑，而后深刻介容器运行时不同的类型，它们是如何工作的以及它们之间的不同点。 通常来说，一个计算机程序员可能将一个程序的运行周期了解为"运行时"，或者是反对其运行的语言的特定实现，其中的一个例子是`Java HotSpot运行时，后者更靠近"容器运行时"的概念。容器运行时负责一个容器运行的所有局部，而容器实际上并未在运行程序自身。正如咱们将从本系列文章中看到的那样，运行时实现了各个级别的性能个性，但实际上运行一个容器就是调用容器运行时所需的全副。 为什么容器让人如此困惑？Docker于2013年公布，它端到端地解决了开发者运行容器的诸多问题： 容器镜像格局构建镜像的办法（Dcokerfile/docker build）治理容器镜像的办法（Docker images, docker rm, etc）治理容器实例的办法（docker ps, docker rm, etc）分享容器镜像的办法（docker push/pull）运行容器的办法（docker run）在那时，Docker是一个一体化的零碎，然而事实上这些性能个性彼此之间并没有相互依赖，它们中的每一个都能够在一个更小更专一的工具实现，每个工具都能够在一个通用的规范（容器规范）下一起应用。因为这个缘故，Docker,Google,CoreOS以及其余的供应商一起创建了凋谢容器标准（OCI），同时他们拆分了容器运行这部分的代码将其作为一个工具或lib库称之为run c,而后捐献给OCI作为OCI运行规范的参考范例。 最后，这使Docker对OCI的捐献感到困惑，他们捐献的是一个规范而不是运行容器的办法，其中并没有蕴含镜像格局或者镜像仓库拉取推送规定，当你运行一个Docker容器的时候，它们实际上通过了以下的步骤： 下载镜像将镜像文件解开为bundle文件，将一个文件系统拆分成多层从bundle文件运行容器Docker标准化的仅仅是第三步。在此之前，每个人都认为容器运行时反对Docker反对的所有性能。最终，Docker方面廓清：原始OCI标准指出，只有“运行容器”的局部组成了runtime。这种“概念失联”始终继续到明天，并使“容器运行时”成为一个令人困惑的话题。心愿我能证实单方都不是齐全谬误的，并且在本博文中将宽泛应用该术语。 Low-Level和High-Level容器运行时当人们想到容器运行时时，可能会想到许多示例。runc，lxc，lmctfy，Docker（containerd），rkt，cri-o。这些中的每一个都是针对不同的状况而构建的，并实现了不同的性能。有些容器（例如containerd和cri-o容器）实际上应用runc来运行容器，在runc之上实现了镜像治理和API接口。与runc的Low-Level个性相比，您能够将这些性能（包含图像传输，图像治理，图像解压缩和API）视为High-Level个性。思考到这点，能够看到容器运行时空间相当简单，每个运行时涵盖了从Low-Level到High-Level的不同局部，这里有一张十分直观的图： 因而，从理论登程，通常只专一于正在运行的容器的runtime通常称为“Low-Level容器运行时”，反对更多高级性能（如镜像治理和gRPC / Web API）的运行时通常称为“High-Level容器运行时”，“High-Level容器运行时”或通常仅称为“容器运行时”，我将它们称为“高级容器运行时”。值得注意的是，Low-Level容器运行时和High-Level容器运行时是解决不同问题的、从根本上不同的事物。容器是通过Linux nanespace和Cgroups实现的，Namespace能让你为每个容器提供虚拟化系统资源，像是文件系统和网络，Cgroups提供了限度每个容器所能应用的资源的如内存和CPU使用量的办法。在最低级别的运行时中，容器运行时负责为容器建设namespaces和cgroups,而后在其中运行命令，Low-Level容器运行时反对在容器中应用这些操作系统个性。 通常状况下，开发人员想要运行一个容器不仅仅须要Low-Level容器运行时提供的这些个性，同时也须要与镜像格局、镜像治理和共享镜像相干的API接口和个性，而这些个性个别由High-Level容器运行时提供。就日常应用来说，Low-Level容器运行时提供的这些个性可能满足不了日常所需，因为这个缘故，惟一会应用Low-Level容器运行时的人是那些实现High-Level容器运行时以及容器工具的开发人员。那些实现Low-Level容器运行时的开发者会说High-Level容器运行时比方containerd和cri-o不像真正的容器运行时，因为从他们的角度来看，他们将容器运行的实现外包给了runc。然而从用户的角度来看，它们只是提供容器性能的单个组件，能够被另一个的实现替换，因而从这个角度将其称为runtime依然是有意义的。即便containerd和cri-o都应用runc，然而它们是截然不同的我的项目，反对的个性也是十分不同的。