docker

1. 问题 docker容器日志导致主机磁盘空间满了。docker logs -f container_name噼里啪啦一大堆，很占用空间，不用的日志可以清理掉了。 2. 解决方法 2.1 找出Docker容器日志 在linux上，容器日志一般存放在/var/lib/docker/containers/container_id/下面， 以json.log结尾的文件（业务日志）很大，查看各个日志文件大小的脚本docker_log_size.sh，内容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日志（治标) 如果docker容器正在运行，那么使用rm -rf方式删除日志后，通过df -h会发现磁盘空间并没有释放。原因是在Linux或者Unix系统中，通过rm -rf或者文件管理器删除文件，将会从文件系统的目录结构上解除链接（unlink）。如果文件是被打开的（有一个进程正在使用），那么进程将仍然可以读取该文件，磁盘空间也一直被占用。正确姿势是cat /dev/null > *-json.log，当然你也可以通过rm -rf删除后重启docker。接下来，提供一个日志清理脚本clean_docker_log.sh，内容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json....

Docker 在不重建容器的情况下，日志文件默认会一直追加，时间一长会逐渐占满服务器的硬盘的空间，内存消耗也会一直增加，本篇来了解一些控制日志文件的方法。 清理单个文件 运行时控制 全局配置 Docker 的日志文件存在 /var/lib/docker/containers 目录中，通过下面的命令可以将日志文件夹根据升序的方式罗列出来。 $ sudo du -d1 -h /var/lib/docker/containers | sort -h 28K /var/lib/docker/containers/0db860afe94df368335c2e96f290275f4c396b996b4e8d22770b01baafd9982c 36K /var/lib/docker/containers/6ee184044661c436b44769d56c203f1fc296dbfe08f6ed4cf79aa6fb8cae6659 44K /var/lib/docker/containers/66c44231981fcb5ecd33bf0fc3390e71c5cbbabb839d79441eb3317b8500d551 60K /var/lib/docker/containers/bc4136199037e73d712614ef57de0915d294cbe51045d213f0d822d71a86cf2c 344K /var/lib/docker/containers/7bd3a179cf67b1537e0965c1d1f518420ac5d4cd151ecb75c37ada8c2347ca6b 984K /var/lib/docker/containers/6bd1f79f16b8b06f2bd203dd84443004ba08c150ac51d23fa620e8b2cbf4b773 1.7M /var/lib/docker/containers/a93a4275571b0033367f9cab8213c467b21a03c600e2203195640b5a5bc7f523 4.4M /var/lib/docker/containers/082564c5bdb19b642491b09419a69061122483c0f959a36eb186dd1fec53c163 14M /var/lib/docker/containers/05fc24ef7a14e31e4557c9881482d350cfb05f2f1cb870638de344581154ca01 32M /var/lib/docker/containers/5d70c82942083d16593670058aefed339cfe874c9027205b1e6eb8e569894d65 129M /var/lib/docker/containers/a88d104d20e5ee58ffeaeecbb559b3231c5b8c73ad1443538928ebeae4ff705c 285M /var/lib/docker/containers/b623602a667c0b31068563f244610a548ed055ff9802197f372ff436a294ab5c 917M /var/lib/docker/containers/3d71c509ab6aea34400d37f6c006914eed2cb05e6e6cd07b3ee03eb783dc367b 1.4G /var/lib/docker/containers 有三种方式可以清理日志文件 清理单个文件 感觉哪个容器的日志太大就清理哪个 $ sudo sh -c "cat /dev/null > ${log_file}" ${log_file} 就是日志文件，可以通过 find 命令查找全部日志 $ sudo find /var/lib/docker/containers -name *.log /var/lib/docker/containers/3d71c509ab6aea34400d37f6c006914eed2cb05e6e6cd07b3ee03eb783dc367b/3d71c509ab6aea34400d37f6c006914eed2cb05e6e6cd07b3ee03eb783dc367b-json....

#因在容器中排查故障需要，需要安装基础工具 # 查看系统版本： cat /etc/os-release Debian基础镜像 #先添加163源 tee /etc/apt/sources.list << EOF deb http://mirrors.163.com/debian/ jessie main non-ffree contrib deb http://mirrirs.163.com/debian/ jessie-updates main non-free contrib EOF #安装 curl telnet apt-get update && apt-get install -y curl telnet vim Alpine基础镜像 #先添加阿里源 cat > /etc/apk/repositories << EOF http://mirrors.aliyun.com/alpine/v3.12/main/ http://mirrors.aliyun.com/alpine/v3.12/community EOF #安装 curl scp telnet vim apk update && apk add curl openssh-client busybox-extras vim

拉取Consul镜像 $ docker pull consul # 默认拉取latest $ docker pull consul:1.9.3 # 拉取指定版本 安装并运行 docker run -d -p 8500:8500 --restart=always --name=consul consul:1.9.3 agent -server -bootstrap -ui -node=1 -client='0.0.0.0' agent: 表示启动 Agent 进程。 server：表示启动 Consul Server 模式 client：表示启动 Consul Cilent 模式。 bootstrap：表示这个节点是 Server-Leader ，每个数据中心只能运行一台服务器。技术角度上讲 Leader 是通过 Raft 算法选举的，但是集群第一次启动时需要一个引导 Leader，在引导群集后，建议不要使用此标志。 ui：表示启动 Web UI 管理器，默认开放端口 8500，所以上面使用 Docker 命令把 8500 端口对外开放。 node：节点的名称，集群中必须是唯一的，默认是该节点的主机名。 client：consul服务侦听地址，这个地址提供HTTP、DNS、RPC等服务，默认是127.0.0.1所以不对外提供服务，如果你要对外提供服务改成0.0.0.0 join：表示加入到某一个集群中去。 如：-json=192.168.0.11

私有镜像仓库搭建 docker run -d -p 5050:5000 --restart always --name registry registry:2 仓库配置 vim /etc/docker/daemon.json { "registry-mirrors": ["https://aqwaeuv8.mirror.aliyuncs.com"], "insecure-registries":["10.3.55.134:5050"] // 取消仓库认证 } 测试，push和pull镜像没有问题，使用docker swarm update时出现找不到镜像错误 问题1： update时提示，No such image: 10.3.55.134:5050/ms-group/ly-12320-server-ks_online:5f223018@sha256:261b7ef562bf95a7293046fb0524e5ff2fe70ad55dcd5ffe7981b35f9d50ff56 解决方案： 需要在所有的docker swarm集群节点都配置daemon.json，并重启docker systemctl restart docker 问题2： 修复完以上问题后，再更新时，出现starting container failed: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: “/bin/sh”: stat /bin/sh: no such file or directory: unknown 解决方案： 基础镜像没有/bin/sh导致，检查基础镜像...

基于Istio实现微服务治理 微服务架构可谓是当前软件开发领域的技术热点，它在各种博客、社交媒体和会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。 尤其是近些年来，微服务架构逐渐发展成熟，从最初的星星之火到现在的大规模的落地与实践，几乎已经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在做微服务架构的落地和推广。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。 而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的应用系统在享受其优势的同时，痛点也越加明显。这些痛点包括但不限于以下几点： 侵入性强。想要集成 SDK 的能力，除了需要添加相关依赖，往往还需要在业务代码中增加一部分的代码、或注解、或配置；业务代码与治理层代码界限不清晰。 升级成本高。每次升级都需要业务应用修改 SDK 版本，重新进行功能回归测试，并且对每一台机器进行部署上线，而这对于业务方来说，与业务的快速迭代开发是有冲突的，大多不愿意停下来做这些与业务目标不太相关的事情。 版本碎片化严重。由于升级成本高，而中间件却不会停止向前发展的步伐，久而久之，就会导致线上不同服务引用的 SDK 版本不统一、能力参差不齐，造成很难统一治理。 中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着 “枷锁” 前行，无法实现快速迭代。 内容多、门槛高。Spring Cloud 被称为微服务治理的全家桶，包含大大小小几十个组件，内容相当之多，往往需要几年时间去熟悉其中的关键组件。而要想使用 Spring Cloud 作为完整的治理框架，则需要深入了解其中原理与实现，否则遇到问题还是很难定位。 治理功能不全。不同于 RPC 框架，Spring Cloud 作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。而这些功能往往是企业大规模落地不可获缺的功能，因此公司往往还需要投入其它人力进行相关功能的自研或者调研其它组件作为补充。 Service Mesh 服务网格 架构和概念 目的是解决系统架构微服务化后的服务间通信和治理问题。设计初衷是提供一种通用的服务治理方案。 Sidecar 在软件系统架构中特指边车模式。这个模式的灵感来源于我们生活中的边三轮：即在两轮摩托车的旁边添加一个边车的方式扩展现有的服务和功能。 这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦：原来两轮摩托车的驾驶者集中注意力跑赛道，边车上的领航员专注周围信息和地图，专注导航。 Service Mesh 这个服务网络专注于处理服务和服务间的通讯。其主要负责构造一个稳定可靠的服务通讯的基础设施，并让整个架构更为的先进和 Cloud Native。在工程中，Service Mesh 基本来说是一组轻量级的与应用逻辑服务部署在一起的服务代理，并且对于应用服务是透明的。 开源实现 第一代服务网格 Linkerd和Envoy Linkerd 使用Scala编写，是业界第一个开源的service mesh方案。作者 William Morgan 是 service mesh 的布道师和践行者。Envoy 基于C++ 11编写，无论是理论上还是实际上，后者性能都比 Linkderd 更好。这两个开源实现都是以 sidecar 为核心，绝大部分关注点都是如何做好proxy，并完成一些通用控制面的功能。 但是，当你在容器中大量部署 sidecar 以后，如何管理和控制这些 sidecar 本身就是一个不小的挑战。于是，第二代 Service Mesh 应运而生。...

Spring Cloud微服务项目交付 微服务扫盲篇 微服务并没有一个官方的定义，想要直接描述微服务比较困难，我们可以通过对比传统WEB应用，来理解什么是微服务。 单体应用架构 如下是传统打车软件架构图： 这种单体应用比较适合于小项目，优点是： 开发简单直接，集中式管理 基本不会重复开发 功能都在本地，没有分布式的管理开销和调用开销 当然它的缺点也十分明显，特别对于互联网公司来说： 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断 代码维护难：代码功能耦合在一起，新人不知道何从下手 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉 扩展性不够：无法满足高并发情况下的业务需求 微服务应用架构 微服务架构的设计思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能，比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。 比如，前面描述的系统可被分解为： 每个业务逻辑都被分解为一个微服务，微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。 微服务架构优点： 解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务 体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响 微服务架构可以使每个微服务独立部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI／CD成为可能 微服务架构问题及挑战 微服务的一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。 微服务的一大挑战是跨多个服务的更改 比如在传统单体应用中，若有A、B、C三个服务需要更改，A依赖B，B依赖C。我们只需更改相应的模块，然后一次性部署即可。 在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新C，然后更新B，最后更新A。 部署基于微服务的应用也要复杂得多 单体应用可以简单的部署在一组相同的服务器上，然后前端使用负载均衡即可。 微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址 以上问题和挑战可大体概括为： API Gateway 服务间调用 服务发现 服务容错 服务部署 数据调用 https://www.kancloud.cn/owenwangwen/open-capacity-platform/1480155，自助餐吃吃喝喝，竟然秒懂微服务 微服务框架 如何应对上述挑战，出现了如下微服务领域的框架： Spring Cloud（各个微服务基于Spring Boot实现） Dubbo...

基于sharedLibrary进行CI/CD流程的优化 由于公司内部项目众多，大量的项目使用同一套流程做CICD 那么势必会存在大量的重复代码 一旦某个公共的地方需要做调整，每个项目都需要修改 因此本章主要通过使用groovy实现Jenkins的sharedLibrary的开发，以提取项目在CICD实践过程中的公共逻辑，提供一系列的流程的接口供公司内各项目调用。 开发完成后，对项目进行Jenkinsfile的改造，最后仅需通过简单的Jenkinsfile的配置，即可优雅的完成CICD流程的整个过程，此方式已在大型企业内部落地应用。 Library工作模式 由于流水线被组织中越来越多的项目所采用，常见的模式很可能会出现。 在多个项目之间共享流水线有助于减少冗余并保持代码 “DRY”。 流水线支持引用 “共享库” ，可以在外部源代码控制仓库中定义并加载到现有的流水线中。 @Library('my-shared-library') _ 在实际运行过程中，会把library中定义的groovy功能添加到构建目录中： /var/jenkins_home/jobs/test-maven-build/branches/feature-CDN-2904.cm507o/builds/2/libs/my-shared-library/vars/devops.groovy 使用library后，Jenkinsfile大致的样子如下： @Library('my-shared-library') _ ... stages { stage('build image') { steps { container('tools') { devops.buildImage("Dockerfile","172.21.51.67:5000/demo:latest") } } } } post { success { script { container('tools') { devops.notificationSuccess("dingTalk") } } } } ....

基于Kubernetes的DevOps平台实践 持续集成工具： Jenkins gitlabci Tekton 本章基于k8s集群部署gitlab、sonarQube、Jenkins等工具，并把上述工具集成到Jenkins中，以Django项目和SpringBoot项目为例，通过多分支流水线及Jenkinsfile实现项目代码提交到不同的仓库分支，实现自动代码扫描、单元测试、docker容器构建、k8s服务的自动部署。 DevOps、CI、CD介绍 Jenkins、sonarQube、gitlab的快速部署 Jenkins初体验 流水线入门及Jenkinsfile使用 Jenkins与Kubernetes的集成 sonarQube代码扫描与Jenkins的集成 实践Django项目的基于Jenkinsfile实现开发、测试环境的CI/CD DevOps、CI、CD介绍 Continuous Integration (CI) / Continuous Delivery (CD) 软件交付流程 一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护，基于这些阶段，我们的软件交付模型大致经历了几个阶段： 瀑布式流程 前期需求确立之后，软件开发人员花费数周和数月编写代码，把所有需求一次性开发完，然后将代码交给QA（质量保障）团队进行测试，然后将最终的发布版交给运维团队去部署。瀑布模型，简单来说，就是等一个阶段所有工作完成之后，再进入下一个阶段。这种模式的问题也很明显，产品迭代周期长，灵活性差。一个周期动辄几周几个月，适应不了当下产品需要快速迭代的场景。 敏捷开发 任务由大拆小，开发、测试协同工作，注重开发敏捷，不重视交付敏捷 DevOps 开发、测试、运维协同工作, 持续开发+持续交付。 我们是否可以认为DevOps = 提倡开发、测试、运维协同工作来实现持续开发、持续交付的一种软件交付模式？ 大家想一下为什么最初的开发模式没有直接进入DevOps的时代？ 原因是：沟通成本。 各角色人员去沟通协作的时候都是手动去做，交流靠嘴，靠人去指挥，很显然会出大问题。所以说不能认为DevOps就是一种交付模式，因为解决不了沟通协作成本，这种模式就不具备可落地性。 那DevOps时代如何解决角色之间的成本问题？DevOps的核心就是自动化。自动化的能力靠什么来支撑，工具和技术。 DevOps工具链 靠这些工具和技术，才实现了自动化流程，进而解决了协作成本，使得devops具备了可落地性。因此我们可以大致给devops一个定义： devops = 提倡开发、测试、运维协同工作来实现持续开发、持续交付的一种软件交付模式 + 基于工具和技术支撑的自动化流程的落地实践。 因此devops不是某一个具体的技术，而是一种思想+自动化能力，来使得构建、测试、发布软件能够更加地便捷、频繁和可靠的落地实践。本次课程核心内容就是要教会大家如何利用工具和技术来实现完整的DevOps平台的建设。我们主要使用的工具有： gitlab，代码仓库，企业内部使用最多的代码版本管理工具。 Jenkins， 一个可扩展的持续集成引擎，用于自动化各种任务，包括构建、测试和部署软件。 robotFramework， 基于Python的自动化测试框架 sonarqube，代码质量管理平台 maven，java包构建管理工具 Kubernetes Docker Jenkins初体验 Kubernetes环境中部署jenkins 其他部署方式 注意点： 第一次启动很慢 因为后面Jenkins会与kubernetes集群进行集成，会需要调用kubernetes集群的api，因此安装的时候创建了ServiceAccount并赋予了cluster-admin的权限 默认部署到jenkins=true的节点 初始化容器来设置权限 ingress来外部访问 数据存储通过hostpath挂载到宿主机中 jenkins/jenkins-all....

第四天 Kubernetes集群的日志及监控 k8s日志收集架构 https://kubernetes.io/docs/concepts/cluster-administration/logging/ 总体分为三种方式： 使用在每个节点上运行的节点级日志记录代理。 在应用程序的 pod 中，包含专门记录日志的 sidecar 容器。 将日志直接从应用程序中推送到日志记录后端。 使用节点级日志代理 容器日志驱动： https://docs.docker.com/config/containers/logging/configure/ 查看当前的docker主机的驱动： $ docker info --format '{{.LoggingDriver}}' json-file格式，docker会默认将标准和错误输出保存为宿主机的文件，路径为： /var/lib/docker/containers/<container-id>/<container-id>-json.log 并且可以设置日志轮转： { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3", "labels": "production_status", "env": "os,customer" } } 优势： 部署方便，使用DaemonSet类型控制器来部署agent即可 对业务应用的影响最小，没有侵入性 劣势: 只能收集标准和错误输出，对于容器内的文件日志，暂时收集不到 使用 sidecar 容器和日志代理 方式一：sidecar 容器将应用程序日志传送到自己的标准输出。 思路：在pod中启动一个sidecar容器，把容器内的日志文件吐到标准输出，由宿主机中的日志收集agent进行采集。 $ cat count-pod.yaml apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1....