• Docker如何进行实践应用?


    2013年初,一个名字从云计算领域横空出世,并在整个IT行业激起千层浪。这就是Docker——一个孕育着新思想的“容器”。Docker选择容器作为核心和基础,依靠容器技术之称的Docker迅速成为国内外各大云计算厂商以及开发者手中的至宝。

    那么这些厂商以及开发者在实践中该如何使用Docker呢?Docker是否可以用来解决实践中这样或那样的同题呢?本文将从容器化思维对Docker的实践应用进行详细讲解。

    一、什么是容器化思维呢?
    一些人将Docker视为轻量级虚拟机技技术,然而如果你是混迹IT圈或者是经验十足的老手,你也许会提出如下问题:

    1、如果需要进入容器调试, 该怎么办?

    2、sshd要怎么配置?

    3、容器里是否应该獸认存在一个公钥文件?

    4、应该如何做备份容器?

    不难看出,如果真把Docker当成虚拟机用, 仍然很难。要正确使用Docker, 就要建立起容器化思维。从技术角度去理解容器化思维, 就是要意识到容器的本质是一个进程以及运行该进程所需要的各种依赖。 当有了容器化思维,再来去看上面五个问題,就能白该从哪里下手了。比知,当理解了容器实际上是一个进程, 那么我们就不需要去备份一个容器了, 而是应该把需要备份的数据放在容器挂的volume里或者数据库里。

    二、容器化思维如何解决日常运维中的问题

    本文将通过分析两个方案来举例说明容器化思维如何解决日常运维中的问题。一个是“SSH服务器的替代方案”,另一个是“Docker内应用日志管理方案”。

    1、SSH服务器的替代方案

    试想一下, 当用户知道容器实际上是一个送程, 还会在进程里启功一个SSH服务器吗? 显然不会,那么自然就不需要考虑sshd的配置问题,也不用考虑公钥的管理问题。实所上Docker提供了一个Docker exec命令,可以在已运行的容器中执行想要的命令,并得到反馈的结果。这个命令实际上可以解决大部分需要ssh进入容器的问题,提供与宿主机原有功能的结合,同样也可以解决诸如定时任务等问题。可见,SSH服务器的使用是跟具体的需求相结合的。

    对于用户需要进入容器修改配置文件的需求主要有三方面:

    1)如果长期需要使用这份配置文件,那么它应该被集成到镜像中;

    2)如果需要经常修改这份配置又件,那么应该使用Docker数据共享这份配置;

    3)对于某些特殊需求需要进入容器,如程序调试等,则可以使用Docker exec直接在容器中启动一个shell,然后再进行一系列操作。

    2、Docker内应用日志管理方案

    当前Docker对运行在它内部应用的日志管理比较薄弱,每个运行在容器内应用的日志输出统一保存在宿主机的/var/1og目录下,文件夹以容器ID命名。当前Docker 仅将应用的stdout和stderr两个日志输出通过通道重定向到/var/1og下。Docker以JSON消息记录每一行日志,这将导致文件增长过快,从而超过主机磁盘限额。此外,日志没有自动切分功能,docker logs 命令返回的日志记录也过于冗长。

    目前处理Docker日志的主流方案, 按照日志处理工具安装的位置主要分为3种。

    1)在容器内收集。除了正在运行的应用程序外,每个容器设置一个日志收集进程。这种方案需要定制Docker镜像,典型代表为baseimage-docker项目,它使用runit连同syslog提供了这方面的日志收集方案示例。

    2)在容器外收集。在宿主机上运行一个单独收集日志的代理,收集所有容器的日志。容器有一个从该宿主机挂载的volume卷,它们把日志记录在挂载卷中,由代理进程接收。当然,也可以使用代理直接处理存储在/var/log目录下的容器日志,该方案的典型代表为Fluentd项目。

    3)在专用容器中收集。这是直接在宿主机上运行代理收集日志的变种方案。该收集代理同样运行在一个容器中,并且该容器的卷使用docker run的volumes-from选项被绑定给所有应用程序容器。

    由此可见,目前Docker的日志处理方案虽然并不完善,但灵活多样。如果与docker ps等命令结合使用,还可以获得与容器日志相对应的应用状态信息。

    三、 容器化思维及更多

    我们在前面讲到,从技术角度理解容器化思维就是要意识到容器的本质是一个进程以及运行该进程所需要的各种依赖。但如果我们不止步于“从技术角度理解容器化思维”,而是把容器化思维扩展到“如何更好地使用容器”这一层面,那么容器化思维所包含的概念和实践方法就有很多了。其中,读者接触的比较多的应该就是微服务了。

    所谓微服务模式有如下三大特性:

    1)彼此独立:微服务模式下的每一个组成部分,都是一个独立的服务,有一整套完整的运行机制以及标准化的对外接口。不依赖于其他部分就能正常运转,同时可以探测其他组成部分的存在。

    2)原子化:微服务应该是不可再分的原子化服务。如果一个服务还能继续划分为几个更小的服务,那便不能称为微服务,而更像是由多个微服务组成的“微系统”。

    3)组合和重构:微服务的最大特点就在于它能快速地组合和重构,彼此组合成一个系统。系统里所有的实体在逻辑上是等价的,因此它的结构相对简单和松散,具有极强的可扩展性和鲁棒性。

    谈到容器经常会谈起微服务,这是因为容器技术轻量级的特性和“构建一次,到处运行”的特性降低了微服务型应用的额外开销(overhead),提升了微服务式的应用开发流程效率,使得微服务的开发模式成为可能6。而与之相关的可以涵盖在容器化思维内的理念还包括DevOps、持续集成和持续交付(CICD)以及不可变基础设施(immutable infrastructure)。

    看来,使用Docker时需要关注容器本身,时刻提醒自己我是在使用容器,从而享受它带来的种种便利,比如:快速的应用分发能力、高效的操作及反应能力、弹性灵活的部署能力以及低廉的部署成本;同时我们也要学习和解决围绕容器的各类实践问题,如网络、存储、监控、资源控制、配置管理、安全等。

  • 相关阅读:
    对象数组转成strin再进行,隔开的字符串,包括赛选某个字段的子,或者求和,
    C语言常见题目 过关斩将(1)C语言的那些坑题,你可知道❓
    C#程序的启动显示方案(无窗口进程发送消息) - 开源研究系列文章
    Locust 之 User
    others-AppLovin广告接入
    K线形态识别_十字星和十字线
    一次Mybaits查询的源码分析
    什么是闭包
    交叉熵损失函数以及二分类任务(机器学习)
    解决Python使用GPU
  • 原文地址:https://blog.csdn.net/HarmonyCloud_/article/details/125999398