基于容器的部署
发布网友
发布时间:2022-10-18 19:03
我来回答
共1个回答
热心网友
时间:2023-11-24 10:44
首先我们的问题是:产品包含了大量的服务,并且服务之间存在复杂的依赖关系,以拓扑的形式运行并相互协作,部署的时候需要手动解决整体的依赖,配制通信的协议和地址,重新部署新环境复杂度非常高。因此,我们希望有一种容器技术可以让我们构建产品所需要的所有的服务能够迅速快捷的重新部署,并且可以根据需求横向的扩展,且保证高可用性,在出现问题的时候可以自动重启或者启动备份服务。
目前有多种解决方案,考虑我们有私有云,亚马逊云以及物理机的几种部署方式,所以Docker作为解决方案的基础,在其之上选择合适的容器拓扑管理工具就成了主要任务,常见的解决方案有:
多种解决方案中我们优先选择官方提供的工具,一般来说官方提供的工具跟自己的原生服务结合的更好,也具有更长远的规划,在官方工具确实不足的情况下辅助以第三方的工具,因此初步我们决定采用Docker原生的工具Machine+Swarm+Compose辅助以Mesos来实现整个工程的部署,其中Swarm负责某一功能模块小规模的容器分配调度,Mesos负责整个集群最外层大规模容器资源调度,可以说以Mesos为主,Swarm为辅助,因为Mesos是比较成熟的资源管理框架,也有非常适合的调度引擎,Swarm还相对初步随着时间演进,也许会接管更多的调度。
简单介绍下Docker官方原生的工具:
关于Docker网络解决方案的争论比较多了,CoreOS和Kubernetes都有自己的解决方案,前两者都是比较通用的PAAS工具,作为通用性的服务编排工具容器的具体实现可以是多种,Docker只是其中之一,而Docker libnetwork的解决方案过于底层,不适合作为通用的插件集成到Kubernetes或者CoreOS中,因此这两家都有自己CNI类型的解决方案,对于使用者来说我们不那么关心到底这个工具支持多少种容器,只需要知道Docker这种容器能够满足当前产品部署的需求就好,因此我们仍然以Docker的工具为主,尽管不那么通用,但是能够解决我们目前服务编排的问题。
官方的工具看起来很美好,解决方案也足够优雅和简洁,问题就是成熟程度,compose和swarm的结合仍然是在试验阶段,对于处于不同host的container,进行link仍然需要手动对整个Swarm集群设置网络,对于大规模或者复杂拓扑的部署工作量不小,因此我们借助于Mesos来做第一级的资源或者容器管理,其中第二级或者说小规模容器部署是可以在swarm中实现。
Mesos作为资深的资源管理平台,在Docker出现之前就已经被广泛利用了,基本上所有的主从类型的分布式计算框架都支持使用Mesos来做基本的资源分配调度,比如hadoop, storm,spark等等,同时Mesos的设计也可允许长时间运行的application, 不管是batch job, stream job还是普通的应用服务都可以接入Mesos来申请资源启动自身的容器。早期Mesos只支持LXC形式的资源*,在Docker崛起之后Mesos也开始支持直接使用Docker容器来运行具体的计算框架,可以说二者既有竞争又相辅相成。说竞争是因为目前Docker自己的工具已经慢慢的可以替代一部分Mesos的应用场景了,只要机器上安装了Docker engine就可以无差别的管理所有主机,比如Swarm就可以组建简单的服务集群,管理容器在集群中的运行,同时也能够利用Machine来进行远程管理,说相辅是因为Swarm的设计是可以替换具体的调度后端的,默认情况使用自己的调度器在服务发现的基础上选择一个host来启动容器,通过配置可以选择Mesos作为其调度后端,将Swarm 作为跟Spark同等的Compute Framework来运行,这样Swarm就能够使用Mesos更加成熟和灵活的调度机制来管理容器,在此之上Compose就可以把编排好的服务运行在Mesos集群,可见Mesos和Docker结合的生态系统在当前阶段是比较和谐的。
这样,最终我们的解决方案就基本确定了,Mesos作为最基础的集群资源管理或者调度工具运行在所有的服务器上,Spark等计算框架不再独立部署,而是使用Mesos最初的LXC容器来运行,Swarm使用Docker容器通过Mesos来调度,Compose文件用来启动结合比较紧密服务堆栈,比如Tachyon集群,我们自己所开发的应用服务以及ACO集群也作为一个Docker服务堆栈在Swarm上运行。所以我们的Mesos集群上目前运行两种计算框架,Spark和Swarm,负责我们的应用和分布式计算的部署,具体的应用和服务编排都是在Compose中完成,个别复杂的应用需要手动去处理关联关系,依然是以Docker的形式运行在Mesos中。
Mesos可以把我们的机器聚合在一起作为一个机器来使用,不管是我们的应用还是分布式计算的任务,都直接提交给Mesos来进行调度,减少了对服务器的垂直划分,不存在Spark的集群, Hadoop的集群等概念,Spark或者Hadoop的job直接在Mesos的slave中分配资源并运行各自job相关的Executor, 运行结束后释放资源,就像Spark没有存在过一样, 因此从更高的角度看Mesos的Framework其实就是一个调度器加一个运行时的处理流程,不用再需要Spark或者Storm等框架的Standalone 模式自己来处理调度,只需要使用Mesos的API,实现自己的scheler和具体启动停止运行过程的Executor就好, 而对于我们自己的应用如果要作为Framework存在也需要实现对应的Scheler和Executor, 不过可以利用现成的比较好的调度器比如Marathon来托管我们的应用,减少开发Framework的工作量。使用Mesos这样的好处是资源的利用率更高, 因此我们在也不需要除了Mesos之外的long running 集群, 即使有Long running的服务,也是在Mesos分配好的容器内运行。
Framework = Scheler + Executor
Mesos的安装过程稍微有点服务,虽然Docker镜像可以减少Mesos的部署复杂度,但是这样就存在了两层容器, Mesos在Docker 容器中运行,而Mesos里边的任务也是在自己的Docker容器里运行,如果有些长时间运行的任务需要暴露出端口跟外界交互,就需要先Expose port到Mesos slave级别的容器, 然后再Expose到最外层的物理机,复杂度增加且对性能有损耗,因此我们最终还是倾向于在物理机上部署Mesos, 只保留一层Docker容器不推荐嵌套,而且有了Mesosphere的DCOS系统,在AWS上部署Mesos就比较简单了。
Mesos看起来很完美,那我们为什么还需要Docker容器呢, 直接使用LXC标准Linux kernel支持的容器不就可以了,在这个解决方案中我们期望所有运行的应用或者分布式计算框架的任务的Executor都是在Docker容器中运行,也是因为Docker杀手级的功能,一个Docker容器就像一个集装箱,里边包含了需要运行一个服务或者任务的所有的依赖条件或者配置,都可以根据需求自身灵活的修改,并且一次装箱随处运行,不用关心外在环境,举个例子假如直接使用LXC来运行Spark的某个任务的Executor,需要提供Spark jar包的地址,相关的配置集成到ExecutorInfo中才能运行,而如果使用Docker container就简单很多,Spark executor运行需要的信息都在某个Docker image中,Mesos slave只要调用Docker client启动某个镜像就足以运行一个Framework的某个任务,任务的执行在Docker 容器中。对于我们自己开发的各种服务同理也是组织成镜像最终在Docker容器中运行, Scheler依赖Marathon就可以。
基于Kubernetes部署安装KubeSphere
基于Kubernetes部署KubeSphere的简要指南KubeSphere是一个以应用为中心的分布式容器平台,它在Kubernetes基础之上提供企业级解决方案。其目标是简化容器调度操作,降低学习成本,解决Kubernetes在存储、网络、安全和易用性上的挑战。它整合了多项功能,包括DevOps、微服务管理、监控告警等,以满足多样化业务场景需求,...
非结构化数据如何可视化呈现?
通常情况下,我们会按照结构模型把系统产生的数据分为三种类型:结构化数据、半结构化数据和非结构化数据。结构化数据,即行数据,是存储在数据库里,可以用二维表结构来逻辑表达实现的数据。最常见的就是数字数据和文本数据,它们可以某种标准...
容器化部署四大优势简单说明-行云管家
首先,容器化部署能够实现快速交付和部署。使用标准的镜像,开发者可以在构建应用程序时打包,这样应用程序可以在各种环境中运行。同时,开发和运维人员可以快速部署应用程序,容器可以在几秒钟内启动。其次,容器化部署提供高效虚拟化。容器基于操作系统级虚拟化,因此它们具有更高的性能和效率。相比之下,传统...
容器化部署和传统部署区别
容器化部署与传统部署的区别如下:以Docker为例子,Docker是能够把应用程序自动部署到容器的开源引擎。传统的部署模式是:安装(包管理工具或者源码包编译)->配置->运行;Docker的部署模式是:复制->运行。实现更轻量级的,方便快速部署,对于部署来说可以极大地减少部署的时间成本和人力成本。容器化部署的优...
基于容器的部署
Mesos的安装过程稍微有点服务,虽然Docker镜像可以减少Mesos的部署复杂度,但是这样就存在了两层容器, Mesos在Docker 容器中运行,而Mesos里边的任务也是在自己的Docker容器里运行,如果有些长时间运行的任务需要暴露出端口跟外界交互,就需要先Expose port到Mesos slave级别的容器, 然后再Expose到最外层的物...
基于Kubernetes的持续部署方案
本技术方案为基于Kubernetes为核心的持续部署(下文简称CD)方案,可以满足开发方的程序级日志查看分析,运维方的快速扩容与日常运维分析,并且可以保证用户的服务体验。并且整套放在可以在资源利用率上进一步提升,在不降低服务可靠性的前提下降低资源使用成本。使用场景分析 本方案适用于以Tomcat为容器的JavaWeb...
什么是“CBV”?
英语缩写 "CBV" 简单易懂,它代表 "Container-Based Versioning",中文直译为 "基于容器的版本控制"。这个术语在软件开发和容器技术中扮演重要角色,尤其在版本管理和部署流程中。CBV的中文拼音为 "jī yú róng qì de bǎn běn kòng zhì",在英语中具有相当的流行度,达到了9258次引用。CBV主要...
基于docker快速搭建zabbix监控平台
zabbix是一款功能全面的监控系统,能够对硬件、操作系统、数据库、网络等多种目标介质进行统一监控,同时集成了UI、监控展示、告警、服务发现等功能,能高效完成监控任务。尽管zabbix应用广泛,但由于其包含多个组件,安装过程较为繁琐,需要大量时间进行部署和调试。本文将介绍如何基于docker容器,快速搭建最新...
K8S容器环境下GitLab-CI和GItLab Runner 部署记录
本文档详细记录了在Kubernetes环境中部署GitLab CI和GitLab Runner的步骤。首先,GitLab CI是一个集成的、开源的持续集成工具,强调快速交付和优化。GitLab Runner则是其在容器化部署中的执行者,用于在K8s中运行构建任务。在部署过程中,关键步骤包括:使用NFS作为持久化存储,创建Redis、PostgreSQL和GitLab...
1Panel docker容器版-1分钟部署wg-easy面板、wireguard可视化管理...
一、介绍 使用1Panel Docker容器版部署wg-easy面板、WireGuard可视化管理的步骤如下,实现两个客户端通过wireguard服务器建立加密通道,连接服务端后通过服务器连接外网,以及提供其他功能。二、部署 部署步骤包括启动依赖的网络模块,需在rc.local文件中写入命令以实现开机启动。通过命令行启动容器时,需输入...
Docker 这九个不同的应用场景,你都用到了吗?
Docker 是一个开源的容器引擎,能够为任何应用创建轻量级、可移植、自给自足的容器。开发者与系统管理员可以在笔记本上编译测试通过的容器,批量部署于生产环境,包括虚拟机、裸机、OpenStack 集群、云端、数据中心等基础应用平台。容器完全使用沙箱机制,相互之间无任何接口。本文将介绍 Docker 的九种用法,以...