Rancher

进入节点后 cd /var/lib/docker/containers du -sh * 找到文件大的容器 docker 容器的日志文件很大 如何处理呢 在rancher中找到对应节点的 pod 删除当前pod 大文件 日志消失了 来源： CSDN 作者： giserinchina 链接： https://blog.csdn.net/wxb880114/article/details/103489588

在容器的使用过程中，如果能及时的掌握容器使用的系统资源，无论对开发还是运维工作都是非常有益的。幸运的是 docker 自己就提供了这样的命令：docker stats。 默认输出 docker stats 命令用来显示容器使用的系统资源。不带任何选项执行 docker stats 命令： 1 $ docker stats 默认情况下，stats 命令会每隔 1 秒钟刷新一次输出的内容直到你按下 ctrl + c。下面是输出的主要内容： [CONTAINER]：以短格式显示容器的 ID。 [CPU %]：CPU 的使用情况。 [MEM USAGE / LIMIT]：当前使用的内存和最大可以使用的内存。 [MEM %]：以百分比的形式显示内存使用情况。 [NET I/O]：网络 I/O 数据。 [BLOCK I/O]：磁盘 I/O 数据。 [PIDS]：PID 号。 只返回当前的状态 如果不想持续的监控容器使用资源的情况，可以通过 --no-stream 选项只输出当前的状态： ? 1 $ docker stats --no-stream 这样输出的结果就不会变化了，看起来省劲不少。 只输出指定的容器 如果我们只想查看个别容器的资源使用情况，可以为 docker stats 命令显式的指定目标容器的名称或者是 ID： ? 1 $ docker stats --no-stream

持续集成/持续交付（CI/CD）在服务精细化、更新频繁的当下显得愈发重要。 本文将分享如何使用托管的GitLab.com解决方案来实现CI/CD，并将其与Kubernetes原生集成。且文中方法适合其他一切提供Kubernetes接口的CI/CD工具噢！ 持续集成/持续交付（CI/CD）的主题，在服务变得越来越细化、更新越来越频繁的当下，显得愈发重要。它让公司能够按照一种一致的、可重复操作的方式完全自动化地完成代码的搭建、测试和部署。 市场中有不少不同的CI/CD工具可供用户使用，它们中的很多将可以和Kubernetes进行原生集成。 本文将介绍如何使用托管的GitLab.com解决方案来实现CI/CD。不过本文中讨论到的Kubernetes集成是通用的，其他的CI/CD工具只要提供了Kubernetes接口，就同样可以按本文的方法、使用服务账号来与Kubernetes进行对接。 先决条件 用于部署工作负载的Rancher 2.0集群 登陆gitlab.com 设置GitLab.com 我们准备使用GitLab提供的一个模版，首先第一步先通过网址 https://gitlab.com/users/sign_in登陆gitlab.com 创建项目 将Kubernetes端点添加到你的项目中 上面所有的字段都需要填入内容，我会在下文介绍如何填写。 API URL API

实操：将一个spring boot项目部署到docker容器里运行 实验需要的环境： 腾讯云+Ubuntu 16.04 x64+idea+插件docker integration+daocloud 第一步，安装操作系统 首先在 腾讯云 上安装一个干净的Ubuntu系统 系统使用Ubuntu 16.04 64位 这里服务市场虽然有docker，但是版本都太低（1.8.2左右），现在的一些镜像都不支持这些低版本的了，所以自己手动装个 腾讯云推荐使用 ssh连接 ，配置好后就不用输入登入密码了 秘钥可以在腾讯云上创建，也可以在Xshell上创建 创建好密钥之后，腾讯云会给你一个私钥下载，这个应该保存好 然后找到密钥，绑定到主机 然后在xshell里面建立ssh连接，把用户秘钥配置上去，就是腾讯云发给你的私钥 然后成功连接上 第二步，搭建docker环境 由于网络的原因。。。推荐在DaoCloud里安装docker，国内镜像快 首先安装docker： 登录到daocloud 这里可以使用一键脚本，方便快捷 下载地址，按照它的说明安装 https://download.daocloud.io/Docker_Mirror/Docker 我使用了这个脚本安装docker 这里可能会卡在-qq这个地方，这是网络的原因，因为是外链。。ctrl+c，在运行，多试多等待就可以了 然后运行脚本 安装完成后

在这一部分，我们将一步步的走进Rancher，细致的探讨Rancher将如何解决在部署与容器管理时出现的种种的问题。回顾教程的 第二部分 ，你会发现我们已经将应用的部署迁移至Docker Compose，并且已经建立了一系列工作步骤来部署我们的应用。这将使得开发人员能够轻松的对他们的应用部署逻辑进行修正，运维人员也可以查看应用的部署时间。当然，在上一个部分教程的一系列操作中，也存在一些显而易见的问题需要解决。 使用Docker-Compose时面临的挑战 首先，运维人员必须手动地调整所有服务的执行计划。部署人员需要决定将哪一个应用部署至哪一台主机，这意味着部署人员需要时刻对每一台主机的剩余可用资源都有了解，如果某一台主机或者容器崩溃了，部署的操作人员将需要对应用进行重新部署。实际生产中，这意味着主机常常处于负载失衡的状态，并且服务在崩溃之后需要很长时间才能得到恢复。 其次，使用Docker-Compose时，想要获得你的服务的当前状态是十分困难的。举个例子来说，我们经常会从运维人员、项目经理以及开发者口中听到这样的问题：“现在部署环境中运行的到底是XX应用程序的哪个版本？”如果我们采用的是手动调整服务的执行计划的方式，想要得到这个问题的答案通常需要询问指定的进行操作的工程师，工程师们需要登陆服务器并运行docker中的ps命令来查看容器的信息。然而面对这些问题

最近一直在研究Rancher的持久化问题。 目前已找到两种方式实现Rancher里的容器文件实现持久化方法。 方法一： 配置映射（只适用单个文件，不适用于目录） 这个算不上是真正的持久化，只是相当于配置一个键值，然后键值内容等于文件内容，从而使得容器重启后，该文件内容会自动读取该键值内容，从而实现保持配置文件内容 （1）添加配置映射 （2）输入映射名称（可随意取，但是注意部分特殊字符无法使用），选中命名空间（建议选择zabbix-agent容器所在命名空间），配置映射键（输入需要保持的文件名字即可），输入值（直接复制zabbix_agentd.conf的内容）。点击确认 （3）配置升级容器。找到相应的容器，点击进入升级界面 下拉找到数据卷，做如下配置 升级该容器，可以发现以下配置内容不会丢失了。当需要修改该文件时，直接在配置映射那里修改对应的值即可 方法二： 映射主机目录：（同时使用于文件及目录） （1）指定该容器运行主机 因为这种方式，相当于将容器内部的文件映射至宿主机，映射之后，宿主机对应的文件和文件夹会自动更新到容器内（PS：注意是，宿主机上的文件或文件夹覆盖容器内的）。如果不指定运行的主机，可能会导致，该容器升级之后，在另一台主机上运行，例如在192.168.68.233上运行，那么如果233上对应的文件夹是空的，将会使得容器内部对应的文件夹也会被清空