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

    🍁作者简介：🏅云计算领域优质创作者🏅新星计划第三季python赛道第一名🏅 阿里云ACE认证高级工程师🏅
    ✒️个人主页：小鹏linux
    💊个人社区：小鹏linux（个人社区）欢迎您的加入！

    为大家推荐一款刷题神奇 点击链接访问牛客网

    各大互联网大厂面试真题。基础题库到进阶题库等各类面试题应有尽有！

    牛客网面经合集,满足大厂面试技术深度，快速构建Java核心知识体系大厂面试官亲授，备战面试与技能提升，主要考点+主流场景+内功提升+真题解析

    ​

    目录

    1. 简单的单台宿主机

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

    3. 安装systemd 

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

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

     👑👑👑结束语👑👑👑

    Docker依赖的技术实际上已经以不同形式存在一段时间了，但Docker是那个成功抓住技术行业兴趣点的解决方案。这把Docker推到了一个令人羡慕不已的位置——社区先驱们完成了这一系列工具的开创工作，这些工具又吸引使用者加入社区并不断地回馈社区，形成了一个自行运转的生态系统。
    有多种不同的方式来组合编排工具的家族树。图下图展示了我们熟悉的一些工具。
    树的根节点是 docker run命令，这是启动容器最常用的方式。Docker家族的几乎所有工具都衍生于这一命令。树的左侧分支上的工具将一组容器视为单个实体，中间分支的工具借助systemd或服务文件管理容器，右侧分支上的工具将单 个容器视为单个实体。沿着这些分支往下，这些工具做的事情越来越多，例如， 它可以跨多台宿主机工作，或者让用户远离手动部署容器的繁琐操作。

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

    1. 简单的单台宿主机

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

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

    在这一技巧里，我们将使用systemd配置一个简单的Docker服务。如果大家熟悉systemd，跟进本章内容将会相对容易些，但我们假设大家之前对此工具并不了解。
    对于一个拥有运维团队的成熟公司来说，֯使用systemd控制Docker是很有用的，因为他们更喜欢沿用自己已经
    了解并且已经工具化的经过生产验证的技术。
    systemd是一个系统管理的守护进程，它在前段时间取代了Fedora的SysV init脚本。它可以通过独立单元的形式管理系统上的所有服务——从挂载点到进 程，甚至到一次性脚本。它在被推广到其他发行版和操作系统后变得愈加受欢迎，虽然在一些系统上安装和启用它可能还有问题 。设置systemd时，别人使用systemd过程中遇到类似问题的处理经验值得 借鉴。

    3. 安装systemd 

    如果用户的宿主机系统上还没有安装systemd（可以运行 systemctl status命令来检查，查看是否能得到正确的响应），可以使用标准包管理工具将其直接安装到宿主机的操作系统上。如果不太习惯以这种方式与宿主机系统交 互，推荐使用Vagrant来部署一个已经安装好systemd的虚拟机，如下： 
    1. $ mkdir centos7_docker                        #创建并进入一个新的目录
    2. $ cd centos7_docker                           
    3. $ vagrant init jdiprizio/centos-docker-io     #将目录初始化成一个Vagrant环境，指定Vagrant镜像
    4. $ vagrant                                     #启动虚拟机
    5. $ vagrant ssh                                 #采用SSH的方式登入虚拟机

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

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

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

    首先以root身份创建一个服务文件/etc/systemd/system/todo.service
    在这个文件里告诉systemd在宿主机的8000端口上运行一个名为todo的Docker容器。 
    1. [Unit]                                         #Unit部分定义了systemd对象的通用信息
    2. Description=Simple ToDo Application After=docker.service #Docker服务启动之后立即启动这个单元
    3. Requires=docker.service                        #该单元成功运行的前提是运行Docker服务
    4. [Service]                                      #Service 部分定义了与systemd 服务单元类型相关的配置信息
    5. Restart=always                                 #如果服务终止了，总是重启它
    6. ExecStartPre=/bin/bash \
    7. -c '/usr/bin/docker rm -f todo || /bin/true'   #ExecStartPre 定义了一个命令。该命令会在该单元启动前运行。要确保启动该单元前容器已经删掉，可以在这里删除它
    8. ExecStartPre=/usr/bin/docker pull dockerinpractice/todo #确保运行容器之前已经下载了该镜像
    9. ExecStart=/usr/bin/docker run --name todo \
    10. -p 8000:8000 dockerinpractice/todo             #ExecStart 定义了服务启动时要运行的命令
    11. ExecStop=/usr/bin/docker rm -f todo            #ExecStop 定义了服务停止时要运行的命令
    12. [Install]                                      #Install 部分包含了启用该单元时systemd 所需的信息
    13. WantedBy=multi-user.target                     #告知systemd当进入多用户目标环境的时候希望启动该服务单元
    从该配置文件可以非常清楚地看出，systemd为进程的管理提供了一种简单的声明式模式，将依赖管理的细节交给systemd服务去处理。但这并不意味着用户可以忽视这些细节，只是它确实为用户提供了很多方便的工具来管理Docker（和其他）进程
    启动一个新的服务单元即是调用 systemctl enable命令。如果希望系统启动的时候该服务单元能够自动启动，也可以在systemd的multi-user.target.wants目录下创建一个符号链接。一旦完成，就可以使用systemctl start 来启动该单元了： 
    1. $ systemctl enable /etc/systemd/system/todo.service
    2. $ ln -s '/etc/systemd/system/todo.service' \
    3. '/etc/systemd/system/multi-user.target.wants/todo.service'
    4. $ systemctl start todo.service
    然后只要等它启动。如果出现问题会有相应的提示。
    可以使用systemctl status命令来检查是否一切正常。它会打印一些关于该服务单元的通用信息，如进程运行的时间以及相应的进程 ID，紧随其后的是该进程的日志信息。通过以下例子可以中看出Swarm服务端在8000端口下正常启动： 
    1. [root@centos system]# systemctl status todo.service 
    2. todo.service - Simple ToDo Application
    3.   Loaded: loaded (/etc/systemd/system/todo.service; enabled)
    4.   Active: active (running) since Wed 2015-03-04 19:57:19 UTC; 2min 13s ago 
    5. Process: 21266 ExecStartPre=/usr/bin/docker pull dockerinpractice/todo 
    6. ➥ (code=exited, status=0/SUCCESS)
    7. Process: 21255 ExecStartPre=/bin/bash -c /usr/bin/docker rm -f todo ||
    8. ➥ /bin/true (code=exited, status=0/SUCCESS)
    9. Process: 21246 ExecStartPre=/bin/bash -c /usr/bin/docker kill todo || 
    10. ➥ /bin/true (code=exited, status=0/SUCCESS)
    11. Main PID: 21275 (docker)
    12.   CGroup: /system.slice/todo.service
    13.         ??21275 /usr/bin/docker run --name todo 
    14.         ➥ -p 8000:8000 dockerinpractice/todo
    15. Mar 04 19:57:24 centos docker[21275]: TodoApp.js:117:
    16. ➥ // TODO scroll into view
    17. Mar 04 19:57:24 centos docker[21275]: TodoApp.js:176:
    18. ➥ if (i>=list.length()) { i=list.length()-1;} // TODO .length 
    19. Mar 04 19:57:24 centos docker[21275]: local.html:30:
    20. ➥ 
    21. Mar 04 19:57:24 centos docker[21275]: model/TodoList.js:29:
    22. ➥ // TODO one op - repeated spec? long spec?
    23. Mar 04 19:57:24 centos docker[21275]: view/Footer.jsx:61:
    24. ➥ // TODO: show the entry's metadata
    25. Mar 04 19:57:24 centos docker[21275]: view/Footer.jsx:80:
    26. ➥ todoList.addObject(new TodoItem()); // TODO create default
    27. Mar 04 19:57:24 centos docker[21275]: view/Header.jsx:25:
    28. ➥ // TODO list some meaningful header (apart from the id)
    29. Mar 04 19:57:24 centos docker[21275]: > todomvc-swarm@0.0.1 start /todo
    30. Mar 04 19:57:24 centos docker[21275]: > node TodoAppServer.js
    31. Mar 04 19:57:25 centos docker[21275]: Swarm server started port 8000
    本技巧中介绍的一些原理不只适用于systemd，大部分进程管理器，包括其他的init系统，都可以采用类似的方式来配置。

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

    不同于docker-compose（编写本书时），systemd已经是一个用于生产的成熟技术。在本技巧中，我们将展示如何使用systemd来实现和docker-compose类似的本地编排功能。
    如果大家在学习如下技巧的时候遇到问题，可能需要升级一下Docker版本，1.7.0及以上版本应该会正常工作
    展示了我们计划实现的systemd服务单元配置中的依赖：
    如下代码展示了sqliteserver服务的代码。像以前一样，它依赖Docker服务，但和前面介绍的to-do实例有一些不同之处。 
    1. [Unit]                                                    #Unit小节定义了该systemd对象的通用信息
    2. Description=SQLite Docker Server After=docker.service     #Docker服务启动之后启动该单元
    3. Requires=docker.service                                   #为了让该服务正常运行，Docker服务必须处于正常运行状态
    4. [Service]
    5. Restart=always
    6. ExecStartPre=-/bin/touch /tmp/sqlitedbs/test              #这几行代码确保服务启动之前SQLite的数据库文件是存在的，touch命令行之前的-告诉systemd：如果该命令返回错误代码则表明启动失败
    7. ExecStartPre=-/bin/touch /tmp/sqlitedbs/live 
    8. ExecStartPre=/bin/bash \ 
    9. -c '/usr/bin/docker kill sqliteserver || bin/true'
    10. ExecStartPre=/bin/bash \                                  #ExecStartPre定义了服务单元被启动之前运行的命令。为了确保容器在用户启动之前已被删除，这里使用了一个前置命令将其删除
    11. -c '/usr/bin/docker rm -f sqliteserver || /bin/true'
    12. ExecStartPre=/usr/bin/docker \
    13. pull dockerinpractice/docker-compose-sqlite               #确保启动容器之前镜像已下载完成了
    14. ExecStart=/usr/bin/docker run --name sqliteserver \       #ExecStart 定义了服务被启动之后运行的命令。这里值得注意的是，我们在另一个/bin/bash–c调用中包含了socat 命令，因为在ExecStart 这一行定义的命令是由systemd来运行的
    15. -v /tmp/sqlitedbs/test:/opt/sqlite/db \
    16. dockerinpractice/docker-compose-sqlite /bin/bash -c \
    17. 'socat TCP-L:12345,fork,reuseaddr \
    18. EXEC:"sqlite3 /opt/sqlite/db",pty'
    19. ExecStop=/usr/bin/docker rm -f sqliteserver               #ExecStop定义了服务停止之后运行的命令
    20. [Install]
    21. WantedBy=multi-user.target
    如下代码列出的是sqliteproxy服务。这里最大的区别在于，代理服务依赖于刚刚定义的服务器进程，而服务端进程又依赖于Docker服务。 
    1. [Unit]
    2. Description=SQLite Docker Proxy 
    3. After=sqliteserver.service                                     #该代理单元必须在前面定义的sqliteserver服务之后运行
    4. Requires=sqliteserver.service                                  #启动该代理之前要求服务器实例在运行
    5. [Service]
    6. Restart=always
    7. ExecStartPre=/bin/bash -c '/usr/bin/docker kill sqliteproxy || /bin/true' 
    8. ExecStartPre=/bin/bash -c '/usr/bin/docker rm -f sqliteproxy || /bin/true' ExecStartPre=/usr/bin/docker pull dockerinpractice/docker-compose-sqlite 
    9. ExecStart=/usr/bin/docker run --name sqliteproxy \
    10. -p 12346:12346 --link sqliteserver:sqliteserver \ 
    11. dockerinpractice/docker-compose-sqlite /bin/bash \
    12. -c 'socat TCP-L:12346,fork,reuseaddr TCP:sqliteserver:12345'   #该命令用于运行容器
    13. ExecStop=/usr/bin/docker rm -f sqliteproxy
    14. [Install]
    15. WantedBy=multi-user.target
    通过这两个配置文件，我们为在systemd控制下安装和运行SQLite服务奠定了基础。现在我们可以启用这些服务了： 
    1. $ sudo systemctl enable /etc/systemd/system/sqliteserver.service ln -s '/etc/systemd/system/sqliteserver.service' \ 
    2. '/etc/systemd/system/multi-user.target.wants/sqliteserver.service' 
    3. $ sudo systemctl enable /etc/systemd/system/sqliteproxy.service
    4. ln -s '/etc/systemd/system/sqliteproxy.service' \ 
    5. '/etc/systemd/system/multi-user.target.wants/sqliteproxy.service'
    然后启动它们： 
    1. $ sudo systemctl start sqlit\eproxy 
    2. $ telnet localhost 12346
    3. [vagrant@centos ~]$ telnet localhost 12346 
    4. Trying ::1...
    5. Connected to localhost.
    6. Escape character is '^]'.
    7. SQLite version 3.8.2 2013-12-06 14:53:30
    8. Enter ".help" for instructions
    9. Enter SQL statements terminated with a ";"
    10. sqlite> select * from t1;
    11. select * from t1;
    12. test
    值得注意的是，sqliteproxy服务依赖于sqliteserver服务的运行。只需要启动sqliteproxy服务即可，其他依赖的服务会自动启动。

     👑👑👑结束语👑👑👑

  • 相关阅读:
    iOS小技能：保存图片到相册( 监听用户的相册授权动作）
    后端开发基础概念
    详解C#中的命名空间
    postgres Full Page Write全页写机制
    简单宿舍管理系统（springboot+vue）
    车牌识别称重系统是怎么工作运行的
    如何在Pacman (Arch Linux)中用Configuration设置HTTP？
    【云原生】K8s pod 动态弹性扩缩容 HAP（metrics-server）
    C++ 三大特性之多态(一)
    [hadoop全分布部署]虚拟机Hadoop集群配置/etc/hosts、配置无密码登录（SSH）
  • 原文地址：https://blog.csdn.net/qq_62294245/article/details/126028000