【云原生 | 拓展02】在单台宿主机上管理Docker容器

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: Docker依赖的技术实际上已经以不同形式存在一段时间了,但Docker是那个成功抓住技术行业兴趣点的解决方案。这把Docker推到了一个令人羡慕不已的位置——社区先驱们完成

🍁作者简介:🏅云计算领域优质创作者🏅新星计划第三季python赛道第一名🏅 阿里云ACE认证高级工程师🏅

✒️个人主页:小鹏linux

💊个人社区:小鹏linux(个人社区)欢迎您的加入!

目录

1. 简单的单台宿主机

2. 为什么要使用systemd管理宿主机上的容器

3. 安装systemd

4.用systemd设置一个简单的Docker应用程序

5. 使用systemd编排宿主机上的容器

👑👑👑结束语👑👑👑


Docker依赖的技术实际上已经以不同形式存在一段时间了,但Docker是那个成功抓住技术行业兴趣点的解决方案。这把Docker推到了一个令人羡慕不已的位置——社区先驱们完成了这一系列工具的开创工作,这些工具又吸引使用者加入社区并不断地回馈社区,形成了一个自行运转的生态系统。

有多种不同的方式来组合编排工具的家族树。图下图展示了我们熟悉的一些工具。


树的根节点是docker run命令,这是启动容器最常用的方式。Docker家族的几乎所有工具都衍生于这一命令。树的左侧分支上的工具将一组容器视为单个实体,中间分支的工具借助systemd或服务文件管理容器,右侧分支上的工具将单个容器视为单个实体。沿着这些分支往下,这些工具做的事情越来越多,例如,它可以跨多台宿主机工作,或者让用户远离手动部署容器的繁琐操作。

image.gif

大家可能会注意到图 9-1 中看似孤立的两个区域——Mesos和 Consul/etcd/Zookeeper组。Mesos是一个有趣的东西,它在Docker之前就已经存在,并且它对Docker的支持是一个附加功能,而不是核心功能。虽然它做得不 错,但是也需要仔细评估,如果仅仅是从功能特性上来看,用户可能在其他工具中也想要有这些。相比之下,Consul、etcd和Zookeeper根本不是编排工具。相反,它们为编排提供了重要的补充功能——服务发现。

1. 简单的单台宿主机


在本地机器上管理容器可能是一种痛苦的体验。Docker为长期运行的容器提供的管理功能比较原始,而启动带有链接和共享卷的容器更是一个令人沮丧的手动过程。

2. 为什么要使用systemd管理宿主机上的容器

在这一技巧里,我们将使用systemd配置一个简单的Docker服务。如果大家熟悉systemd,跟进本章内容将会相对容易些,但我们假设大家之前对此工具并不了解。

对于一个拥有运维团队的成熟公司来说,֯使用systemd控制Docker是很有用的,因为他们更喜欢沿用自己已经

了解并且已经工具化的经过生产验证的技术。

systemd是一个系统管理的守护进程,它在前段时间取代了Fedora的SysVinit脚本。它可以通过独立单元的形式管理系统上的所有服务——从挂载点到进程,甚至到一次性脚本。它在被推广到其他发行版和操作系统后变得愈加受欢迎,虽然在一些系统上安装和启用它可能还有问题。设置systemd时,别人使用systemd过程中遇到类似问题的处理经验值得借鉴。

3. 安装systemd

如果用户的宿主机系统上还没有安装systemd(可以运行systemctl status命令来检查,查看是否能得到正确的响应),可以使用标准包管理工具将其直接安装到宿主机的操作系统上。如果不太习惯以这种方式与宿主机系统交 互,推荐使用Vagrant来部署一个已经安装好systemd的虚拟机,如下:

$ mkdir centos7_docker                        #创建并进入一个新的目录
$ cd centos7_docker                           
$ vagrant init jdiprizio/centos-docker-io     #将目录初始化成一个Vagrant环境,指定Vagrant镜像
$ vagrant                                     #启动虚拟机
$ vagrant ssh                                 #采用SSH的方式登入虚拟机

image.gif

4.用systemd设置一个简单的Docker应用程序

现在机器上安装好了systemd和Docker,systemd通过读取INI格式的配置文件来工作。

INI文件:INI文件是一种简单的文本文件,其基本结构由节、属性和值组成

首先以root身份创建一个服务文件/etc/systemd/system/todo.service

在这个文件里告诉systemd在宿主机的8000端口上运行一个名为todo的Docker容器。

[Unit]                                         #Unit部分定义了systemd对象的通用信息
Description=Simple ToDo Application After=docker.service #Docker服务启动之后立即启动这个单元
Requires=docker.service                        #该单元成功运行的前提是运行Docker服务
[Service]                                      #Service 部分定义了与systemd 服务单元类型相关的配置信息
Restart=always                                 #如果服务终止了,总是重启它
ExecStartPre=/bin/bash \
-c '/usr/bin/docker rm -f todo || /bin/true'   #ExecStartPre 定义了一个命令。该命令会在该单元启动前运行。要确保启动该单元前容器已经删掉,可以在这里删除它
ExecStartPre=/usr/bin/docker pull dockerinpractice/todo #确保运行容器之前已经下载了该镜像
ExecStart=/usr/bin/docker run --name todo \
-p 8000:8000 dockerinpractice/todo             #ExecStart 定义了服务启动时要运行的命令
ExecStop=/usr/bin/docker rm -f todo            #ExecStop 定义了服务停止时要运行的命令
[Install]                                      #Install 部分包含了启用该单元时systemd 所需的信息
WantedBy=multi-user.target                     #告知systemd当进入多用户目标环境的时候希望启动该服务单元

image.gif


从该配置文件可以非常清楚地看出,systemd为进程的管理提供了一种简单的声明式模式,将依赖管理的细节交给systemd服务去处理。但这并不意味着用户可以忽视这些细节,只是它确实为用户提供了很多方便的工具来管理Docker(和其他)进程

启动一个新的服务单元即是调用systemctl enable命令。如果希望系统启动的时候该服务单元能够自动启动,也可以在systemd的multi-user.target.wants目录下创建一个符号链接。一旦完成,就可以使用systemctl start来启动该单元了:

$ systemctl enable /etc/systemd/system/todo.service
$ ln -s '/etc/systemd/system/todo.service' \
'/etc/systemd/system/multi-user.target.wants/todo.service'
$ systemctl start todo.service

image.gif

然后只要等它启动。如果出现问题会有相应的提示。

可以使用systemctl status命令来检查是否一切正常。它会打印一些关于该服务单元的通用信息,如进程运行的时间以及相应的进程 ID,紧随其后的是该进程的日志信息。通过以下例子可以中看出Swarm服务端在8000端口下正常启动:

[root@centos system]# systemctl status todo.service 
todo.service - Simple ToDo Application
  Loaded: loaded (/etc/systemd/system/todo.service; enabled)
  Active: active (running) since Wed 2015-03-04 19:57:19 UTC; 2min 13s ago 
Process: 21266 ExecStartPre=/usr/bin/docker pull dockerinpractice/todo 
➥ (code=exited, status=0/SUCCESS)
Process: 21255 ExecStartPre=/bin/bash -c /usr/bin/docker rm -f todo ||
➥ /bin/true (code=exited, status=0/SUCCESS)
Process: 21246 ExecStartPre=/bin/bash -c /usr/bin/docker kill todo || 
➥ /bin/true (code=exited, status=0/SUCCESS)
Main PID: 21275 (docker)
  CGroup: /system.slice/todo.service
        ??21275 /usr/bin/docker run --name todo 
        ➥ -p 8000:8000 dockerinpractice/todo
Mar 04 19:57:24 centos docker[21275]: TodoApp.js:117:
➥ // TODO scroll into view
Mar 04 19:57:24 centos docker[21275]: TodoApp.js:176:
➥ if (i>=list.length()) { i=list.length()-1;} // TODO .length 
Mar 04 19:57:24 centos docker[21275]: local.html:30:
➥ <!-- TODO 2-split, 3-split -->
Mar 04 19:57:24 centos docker[21275]: model/TodoList.js:29:
➥ // TODO one op - repeated spec? long spec?
Mar 04 19:57:24 centos docker[21275]: view/Footer.jsx:61:
➥ // TODO: show the entry's metadata
Mar 04 19:57:24 centos docker[21275]: view/Footer.jsx:80:
➥ todoList.addObject(new TodoItem()); // TODO create default
Mar 04 19:57:24 centos docker[21275]: view/Header.jsx:25:
➥ // TODO list some meaningful header (apart from the id)
Mar 04 19:57:24 centos docker[21275]: > todomvc-swarm@0.0.1 start /todo
Mar 04 19:57:24 centos docker[21275]: > node TodoAppServer.js
Mar 04 19:57:25 centos docker[21275]: Swarm server started port 8000

image.gif

本技巧中介绍的一些原理不只适用于systemd,大部分进程管理器,包括其他的init系统,都可以采用类似的方式来配置。

5. 使用systemd编排宿主机上的容器


不同于docker-compose(编写本书时),systemd已经是一个用于生产的成熟技术。在本技巧中,我们将展示如何使用systemd来实现和docker-compose类似的本地编排功能。

如果大家在学习如下技巧的时候遇到问题,可能需要升级一下Docker版本,1.7.0及以上版本应该会正常工作

展示了我们计划实现的systemd服务单元配置中的依赖:

image.gif

如下代码展示了sqliteserver服务的代码。像以前一样,它依赖Docker服务,但和前面介绍的to-do实例有一些不同之处。

[Unit]                                                    #Unit小节定义了该systemd对象的通用信息
Description=SQLite Docker Server After=docker.service     #Docker服务启动之后启动该单元
Requires=docker.service                                   #为了让该服务正常运行,Docker服务必须处于正常运行状态
[Service]
Restart=always
ExecStartPre=-/bin/touch /tmp/sqlitedbs/test              #这几行代码确保服务启动之前SQLite的数据库文件是存在的,touch命令行之前的-告诉systemd:如果该命令返回错误代码则表明启动失败
ExecStartPre=-/bin/touch /tmp/sqlitedbs/live 
ExecStartPre=/bin/bash \ 
-c '/usr/bin/docker kill sqliteserver || bin/true'
ExecStartPre=/bin/bash \                                  #ExecStartPre定义了服务单元被启动之前运行的命令。为了确保容器在用户启动之前已被删除,这里使用了一个前置命令将其删除
-c '/usr/bin/docker rm -f sqliteserver || /bin/true'
ExecStartPre=/usr/bin/docker \
pull dockerinpractice/docker-compose-sqlite               #确保启动容器之前镜像已下载完成了
ExecStart=/usr/bin/docker run --name sqliteserver \       #ExecStart 定义了服务被启动之后运行的命令。这里值得注意的是,我们在另一个/bin/bash–c调用中包含了socat 命令,因为在ExecStart 这一行定义的命令是由systemd来运行的
-v /tmp/sqlitedbs/test:/opt/sqlite/db \
dockerinpractice/docker-compose-sqlite /bin/bash -c \
'socat TCP-L:12345,fork,reuseaddr \
EXEC:"sqlite3 /opt/sqlite/db",pty'
ExecStop=/usr/bin/docker rm -f sqliteserver               #ExecStop定义了服务停止之后运行的命令
[Install]
WantedBy=multi-user.target

image.gif

如下代码列出的是sqliteproxy服务。这里最大的区别在于,代理服务依赖于刚刚定义的服务器进程,而服务端进程又依赖于Docker服务。

[Unit]
Description=SQLite Docker Proxy 
After=sqliteserver.service                                     #该代理单元必须在前面定义的sqliteserver服务之后运行
Requires=sqliteserver.service                                  #启动该代理之前要求服务器实例在运行
[Service]
Restart=always
ExecStartPre=/bin/bash -c '/usr/bin/docker kill sqliteproxy || /bin/true' 
ExecStartPre=/bin/bash -c '/usr/bin/docker rm -f sqliteproxy || /bin/true' ExecStartPre=/usr/bin/docker pull dockerinpractice/docker-compose-sqlite 
ExecStart=/usr/bin/docker run --name sqliteproxy \
-p 12346:12346 --link sqliteserver:sqliteserver \ 
dockerinpractice/docker-compose-sqlite /bin/bash \
-c 'socat TCP-L:12346,fork,reuseaddr TCP:sqliteserver:12345'   #该命令用于运行容器
ExecStop=/usr/bin/docker rm -f sqliteproxy
[Install]
WantedBy=multi-user.target

image.gif

通过这两个配置文件,我们为在systemd控制下安装和运行SQLite服务奠定了基础。现在我们可以启用这些服务了:

$ sudo systemctl enable /etc/systemd/system/sqliteserver.service ln -s '/etc/systemd/system/sqliteserver.service' \ 
'/etc/systemd/system/multi-user.target.wants/sqliteserver.service' 
$ sudo systemctl enable /etc/systemd/system/sqliteproxy.service
ln -s '/etc/systemd/system/sqliteproxy.service' \ 
'/etc/systemd/system/multi-user.target.wants/sqliteproxy.service'

image.gif

然后启动它们:

$ sudo systemctl start sqlit\eproxy 
$ telnet localhost 12346
[vagrant@centos ~]$ telnet localhost 12346 
Trying ::1...
Connected to localhost.
Escape character is '^]'.
SQLite version 3.8.2 2013-12-06 14:53:30
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select * from t1;
select * from t1;
test

image.gif


值得注意的是,sqliteproxy服务依赖于sqliteserver服务的运行。只需要启动sqliteproxy服务即可,其他依赖的服务会自动启动。

👑👑👑结束语👑👑👑

image.gif

目录
相关文章
|
12天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
8天前
|
监控 NoSQL 时序数据库
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
130 77
|
16天前
|
监控 Docker 容器
在Docker容器中运行打包好的应用程序
在Docker容器中运行打包好的应用程序
|
6天前
|
供应链 安全 Cloud Native
阿里云容器服务助力企业构建云原生软件供应链安全
本文基于2024云栖大会演讲,探讨了软件供应链攻击的快速增长趋势及对企业安全的挑战。文中介绍了如何利用阿里云容器服务ACK、ACR和ASM构建云原生软件供应链安全,涵盖容器镜像的可信生产、管理和分发,以及服务网格ASM实现应用无感的零信任安全,确保企业在软件开发和部署过程中的安全性。
|
7天前
|
人工智能 Kubernetes Cloud Native
阿里云容器服务,智算时代云原生操作系统
2024云栖大会,阿里巴巴研究员易立分享了阿里云容器服务的最新进展。容器技术已成为云原生操作系统的基石,支持多样化的应用场景,如自动驾驶、AI训练等。阿里云容器服务覆盖公共云、边缘云、IDC,提供统一的基础设施,助力客户实现数字化转型和技术创新。今年,阿里云在弹性计算、网络优化、存储解决方案等方面进行了多项重要升级,进一步提升了性能和可靠性。
|
10天前
|
数据建模 应用服务中间件 nginx
docker替换宿主与容器的映射端口和文件路径
通过正确配置 Docker 的端口和文件路径映射,可以有效地管理容器化应用程序,确保其高效运行和数据持久性。在生产环境中,动态替换映射配置有助于灵活应对各种需求变化。以上方法和步骤提供了一种可靠且易于操作的方案,帮助您轻松管理 Docker 容器的端口和路径映射。
44 3
|
13天前
|
Kubernetes Cloud Native Docker
云原生之旅:从容器化到微服务
本文将带领读者踏上云原生的旅程,深入探讨容器化和微服务架构的概念、优势以及它们如何共同推动现代软件的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务应用,并解释相关的配置和操作。无论你是云原生新手还是希望深化理解,这篇文章都将为你提供有价值的见解和实操指南。
|
16天前
|
负载均衡 网络协议 算法
Docker容器环境中服务发现与负载均衡的技术与方法,涵盖环境变量、DNS、集中式服务发现系统等方式
本文探讨了Docker容器环境中服务发现与负载均衡的技术与方法,涵盖环境变量、DNS、集中式服务发现系统等方式,以及软件负载均衡器、云服务负载均衡、容器编排工具等实现手段,强调两者结合的重要性及面临挑战的应对措施。
44 3
|
16天前
|
存储 安全 数据安全/隐私保护
Docker 容器化应用管理更加高效,但数据安全和业务连续性成为关键。
在数字化时代,Docker 容器化应用管理更加高效,但数据安全和业务连续性成为关键。本文探讨了 Docker 应用的备份与恢复策略,涵盖备份的重要性、内容、方法及常见工具,制定备份策略,恢复流程及注意事项,并通过案例分析和未来趋势展望,强调备份与恢复在保障应用安全中的重要性。
25 2
|
16天前
|
存储 安全 数据中心
Docker 容器凭借轻量级和高效的特性,成为应用部署的重要工具
Docker 容器凭借轻量级和高效的特性,成为应用部署的重要工具。本文探讨了 Docker 如何通过 Namespace 和 Cgroups 实现 CPU、内存、网络和存储资源的隔离,提高系统安全性和资源利用率,以及面临的挑战和应对策略。
32 1