一、VSCode 插件 shellman：提供智能提示和自动补全功能。 shellcheck：提供语法检查的功能。 shell-format：提供代码格式化功能，快捷键：Alt+Shift+f。 Code Runner：提供代码运行功能。 Linux 上脚本首行要声明 bash 解释器，Windows 上也一样。不过，路径要更改为安装 Git 的路径，例如: E:\SOFTWARE\Git\bin/bash。 #!E:\SOFTWARE\Git\bin\bash # basic for command for test in Alabama Alaska Arizona do echo The next state is $test done 二、VSCode 实现 Shell 脚本调试 2.1、Windows 配置 SSH 2.1.1、通过「设置」安装 1、使用 Windows + I 快捷键打开「设置」，依次选择「系统」>「可选功能」。 2、点击「查看功能」，在搜索框中输入 OpenSSH 进行筛选。 3、根据需要勾选： OpenSSH 客户端：可以使用 ssh 命令连接到其他支持 SSH 的设备。 OpenSSH 服务器：允许其他设备通过 SSH 连接到你的电脑。 4、选择好后点击「下一步」，然后点击「安装」开始安装过程。 2.1.2、使用 PowerShell 安装 1、使用 Windows + R 快捷键打开「运行」对话框，输入 powershell，然后按 Ctrl + Shift + Enter 以管理员权限打开 PowerShell 窗口。 2、执行以下命令查看 OpenSSH 安装状态： 3、根据需要安装 OpenSSH 客户端和服务器组件： # 安装 OpenSSH 客户端 Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 # 安装 OpenSSH 服务器 Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 2.1.3、在 Windows 中配置 OpenSSH 服务器 1、当你在 Windows 上安装了 OpenSSH 服务器之后，需要进行一些配置才能接受连接： 2、使用 Windows + R 快捷键打开「运行」对话框，输入 powershell，然后按 Ctrl + Shift + Enter 以管理员权限打开 PowerShell。 Set-Service -Name sshd -StartupType 'Automatic' 3、设置 SSHD 服务自动启动： Start-Service sshd 4、检查 SSH 服务器是否在侦听 22 端口： netstat -an | findstr /i ":22" 5、确保 Windows Defender 防火墙允许 TCP 22 端口的入站连接： Get-NetFirewallRule -Name *OpenSSH-Server* | select Name, DisplayName, Description, Enabled 如规则丢失或被禁用，可以创建新规则： New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22 6、可选）如果要修改配置，如设置用户访问权限，可以编辑 sshd_config 配置文件： Start-Process Notepad C:\Programdata\ssh\sshd_config 7、根据需要修改配置文件，保存后关闭记事本。 8、完成更改后，重启 SSHD 服务应用配置： Restart-Service sshd 按照这些步骤，你的 Windows 就能通过 SSH 协议接受连接了。 2.2、使用 VSCode 远程连接 linux 服务 安装 VSCode 插件：Remote - SSH & Bash Debug。 输入：ssh root@192.168.10.102 进行连接。 Remote - SSH 连接后生成 .config： Host 192.168.10.102 HostName 192.168.10.102 User root Bash Debug 配置 launch.json： { // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "type": "bashdb", "request": "launch", "name": "Bash-Debug (type in script name)", "cwd": "${workspaceFolder}", "program": "${command:AskForScriptName}", "args": [] }, { "type": "bashdb", "request": "launch", "name": "Bash-Debug (select script from list of sh files)", "cwd": "${workspaceFolder}", "program": "${command:SelectScriptName}", "args": [] }, { "type": "bashdb", "request": "launch", "name": "Bash-Debug (hardcoded script name)", "cwd": "${workspaceFolder}", "program": "${workspaceFolder}/path/to/script.sh", "args": [] }, { "type": "bashdb", "request": "launch", "name": "Bash-Debug (simplest configuration)", "program": "${file}" } ] } 参考： 【OpenSSH】Windows 上的 OpenSSH：安装、配置和使用指南 在 Windows 下用 VScode 构造 shell 脚本的 IDE 使用 vscode 实现 shell 脚本调试
一、docker compose Kafka 单机docker-compose.yml： version: "3.8" services: kafka: image: bitnami/kafka:4.0.0 container_name: kafka ports: - "9092:9092" environment: - KAFKA_ENABLE_KRAFT=yes - KAFKA_KRAFT_CLUSTER_ID=4L6g3nShT-eMCtK--X86sw - KAFKA_CFG_NODE_ID=1 - KAFKA_CFG_PROCESS_ROLES=broker,controller - KAFKA_CFG_LISTENERS=PLAINTEXT://0.0.0.0:9092,CONTROLLER://:9093 - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://192.168.10.200:9092 - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT - KAFKA_CFG_INTER_BROKER_LISTENER_NAME=PLAINTEXT - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@kafka:9093 - KAFKA_CFG_LOG_DIRS=/bitnami/kafka/data volumes: - kafka-data:/bitnami/kafka volumes: kafka-data: 启动： docker compose up -d docker compose logs -f kafka version: "3.8": 使用 Compose 文件规范 3.8 版本。 services: 定义要运行的服务集合。 kafka: 服务名（同时也是默认的内部 DNS 名称）。 image: bitnami/kafka:4.0.0: 使用 Bitnami 的 Kafka 4.0.0 镜像（KRaft 模式支持）。 container_name: kafka: 指定容器名为 kafka（便于管理）。 ports: "9092:9092": 将宿主机 9092 暴露到容器 9092（客户端用 9092 连接 Kafka）。未暴露 9093，因为控制面只在容器网络内通信。 environment: Kafka 配置（通过环境变量注入） KAFKA_ENABLE_KRAFT=yes: 启用 KRaft 模式（不使用 Zookeeper）。 KAFKA_KRAFT_CLUSTER_ID=...: KRaft 集群 ID，需固定不变（初始化生成一次即可复用）。 KAFKA_CFG_NODE_ID=1: 当前节点 ID（单节点可为 1）。 KAFKA_CFG_PROCESS_ROLES=broker,controller: 同一进程同时扮演 broker 与 controller。 KAFKA_CFG_LISTENERS=PLAINTEXT://0.0.0.0:9092,CONTROLLER://:9093: 定义监听端口 PLAINTEXT://0.0.0.0:9092：客户端监听在所有网卡 9092。 CONTROLLER://:9093：控制面监听在 9093（对容器网络可见）。 KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://192.168.10.200:9092: 对客户端“宣告”的地址，客户端拿到元数据后按此地址回连；需填宿主机可达的 IP/域名与端口。 KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT: 将自定义监听名映射到安全协议（此处均为明文，无 TLS/SASL）。 KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER: 控制面使用名为 CONTROLLER 的监听器。 KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@kafka:9093: KRaft 控制器投票者列表（节点 ID@地址）；单节点为 1@kafka:9093，其中 kafka 为 Compose 内部主机名。 KAFKA_CFG_LOG_DIRS=/bitnami/kafka/data: Kafka 数据目录（分区/段文件等）在容器内的路径。 volumes: kafka-data:/bitnami/kafka: 将命名卷 kafka-data 挂载到容器路径 /bitnami/kafka，持久化数据与配置。 volumes: kafka-data: 定义命名卷 kafka-data（使用默认本地驱动）。 补充要点： 外部客户端应使用 bootstrap.servers=192.168.10.200:9092。 确认宿主机防火墙放行 TCP 9092；若 IP/域名变更，记得同步更新 KAFKA_CFG_ADVERTISED_LISTENERS。 二、docker run（Kafka 单容器） docker run -d --name kafka \ -p 9092:9092 \ -e KAFKA_ENABLE_KRAFT=yes \ -e KAFKA_KRAFT_CLUSTER_ID=4L6g3nShT-eMCtK--X86sw \ -e KAFKA_CFG_NODE_ID=1 \ -e KAFKA_CFG_PROCESS_ROLES=broker,controller \ -e KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093 \ -e KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092 \ -e KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER \ -e KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@127.0.0.1:9093 \ -e KAFKA_CFG_LOG_DIRS=/bitnami/kafka/data \ -v kafka-data:/bitnami/kafka \ bitnami/kafka:4.0.0 创建主题： docker exec -it kafka /opt/bitnami/kafka/bin/kafka-topics.sh \ --create --topic test --bootstrap-server localhost:9092 \ --replication-factor 1 --partitions 1 生产者： docker exec -it kafka /opt/bitnami/kafka/bin/kafka-console-producer.sh \ --bootstrap-server localhost:9092 --topic test 消费者： docker exec -it kafka /opt/bitnami/kafka/bin/kafka-console-consumer.sh \ --bootstrap-server localhost:9092 --topic test --from-beginning 列出主题： docker exec -it kafka /opt/bitnami/kafka/bin/kafka-topics.sh \ --bootstrap-server localhost:9092 --list
一、简介 1.1、流水线 所谓的流水线，其实就是将之前的一个任务或者一个脚本就做完的事情，划分为多个子任务，然后分别执行，他们两者实现的最终效果是一样的，但是由于原始任务划分为多个子任务之后，以流水线的方式来执行，可以随时看任意子任务的执行效果，即使在某个阶段出现问题，我们也可以随时直接定位问题的发生点，大大提高项目的效率。 Pipeline 就是一套运行于Jenkins上的工作流框架，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排与可视化。 Pipeline 作为 Jenkins2.X 的最核心的特性，提供了一组可扩展的工具，通过 Pipeline Domain Specific Language（DSL）syntax 可以达到 Pipeline as Code 的目的，帮助 Jenkins 实现从 CI 到 CD 与 DevOps 的转变。 1.2、简单的项目发布流水线样式 这个漂亮的展示界面是 pipeline 配套的 BlueOcean 插件的功能。 1.3、功能特性 代码实现：以代码的形式实现，不仅可以被纳入版本控制，还可以通过编辑代码实现目标效果。 可持续性：任务的执行，不受jenkins等其他环境的限制。 操作灵活：子任务可以随意终止和继续 多功能：支持复杂CD要求，包括fork/join子进程，循环和并行执行工作的能力 可扩展：支持DSL的自定义扩展以及与其他插件集成。 自由风格借助于 Build Trigger 中的 Block xxx is building 或者 Post-build Action 中的 Build other projects 属性将多个独立的巨型任务关联在一起，逻辑复杂(并行|级联依赖)场景下不太适用。 pipeline 风格以一个任务的方式来实现，将各种我们能想到的任意复杂场景进行合理的组合。它不仅仅可以以 web 页面的方式进行定制化配置，还可以直接以 Jenkinsfile 的方式来实现。不过，无论哪种方式，其核心都是大量的脚本代码的正常运行，而且在 web 界面定制的脚本格式与 Jenkinsfile 中的脚本格式一致。通常认为最佳实践是在 Jenkinsfile Jenkins 中直接从源代码控制中加载 Pipeline。 二、Pipeline 插件 Pipeline 插件是 Jenkins 中用于创建和管理流水线的核心插件，它提供了一种强大而灵活的方式来定义整个软件开发过程中的构建、测试和部署流程。 2.1、插件安装 Pipeline 插件是 Jenkins 的默认安装插件之一，通常在安装 Jenkins 后就会自动包含。如果你的 Jenkins 没有安装 Pipeline 插件，可以通过 Jenkins 管理界面的插件管理功能进行安装。 2.2、Pipeline DSL Pipeline 插件引入了一种名为 Pipeline DSL（Domain-Specific Language）的脚本语言，它是基于 Groovy 语言的，并提供了一系列关键字和语法来定义流水线的各个阶段和任务。Pipeline DSL 主要包括以下几个核心概念： pipeline：定义整个流水线的入口，包括流水线的名称、参数、触发条件等信息。 stage：定义流水线的一个阶段，包括阶段的名称、任务、并行执行等信息。 step：定义流水线的一个任务，可以是构建、测试、部署等操作。 node：指定流水线的执行节点，可以是 Jenkins 主节点或者代理节点。 agent：指定流水线的代理节点，即流水线的执行环境。 parameters：定义流水线的参数，可以在流水线执行时传入不同的参数值。 2.3、Pipeline 编写 编写 Pipeline 脚本通常分为以下几个步骤： 定义流水线：使用 pipeline 关键字定义流水线，并设置流水线的参数和触发条件。 定义阶段：使用 stage 关键字定义流水线的各个阶段，并设置阶段的名称和任务。 编写任务：在每个阶段中使用 steps 或其他任务相关的关键字来编写具体的任务脚本，如构建、测试、部署等。 设置代理节点：如果需要在特定的节点上执行任务，可以使用 agent 或 node 关键字来设置执行节点。 参数化：如果流水线需要接受外部参数，可以使用 parameters 关键字定义参数列表，并在流水线执行时传入参数值。 2.4、示例 下面是一个简单的 Pipeline 脚本示例，演示了一个简单的构建和测试流水线： pipeline { agent any stages { stage('Build') { steps { sh 'mvn clean package' } } stage('Test') { steps { sh 'mvn test' } } } } 三、Pipeline 脚本语法 Pipeline 脚本语法是 Pipeline 插件提供的一种特定语法，用于编写 Jenkins 流水线的各个阶段和任务。 3.1、Stage（阶段） Stage 是流水线中的一个逻辑单元，用于将流水线划分为不同的阶段，如构建、测试、部署等。 使用 stage 关键字定义一个阶段，并指定阶段的名称。 pipeline { agent any stages { stage('Build') { steps { // 构建步骤 } } stage('Test') { steps { // 测试步骤 } } // 更多阶段... } } 3.2、Step（步骤） Step 是流水线执行的最小单元，用于执行具体的任务，如构建项目、运行测试、发送通知等。 使用不同的关键字或函数来定义一个步骤，如 sh（执行 Shell 命令）、echo（输出信息）、git（Git 操作）等。 pipeline { agent any stages { stage('Build') { steps { sh 'mvn clean package' } } stage('Test') { steps { echo 'Running unit tests...' sh 'mvn test' } } // 更多步骤... } } 3.3、Parallel（并行执行） Parallel 允许将多个步骤或阶段并行执行，以提高流水线的执行效率。 使用 parallel 关键字将多个步骤或阶段包裹起来，并在其中定义需要并行执行的任务。 pipeline { agent any stages { stage('Test') { parallel { stage('Unit Tests') { steps { // 执行单元测试 } } stage('Integration Tests') { steps { // 执行集成测试 } } } } } } 3.4、Node（节点） Node 用于指定流水线的执行节点，即流水线的执行环境，可以是 Jenkins 主节点或代理节点。 使用 node 或 agent 关键字指定执行节点，并在其中定义流水线的各个阶段和任务。 pipeline { agent { label 'my-agent' // 指定代理节点 } stages { stage('Build') { steps { // 构建步骤 } } // 更多阶段... } } 四、流水线基础 在 Jenkins 中创建简单的流水线通常涉及以下几个步骤：定义流水线的结构、设置环境变量、编写脚本以及运行流水线。 4.1、定义流水线结构 首先需要定义流水线的结构，包括流水线的名称、代理节点、阶段和步骤等。 下面是一个简单的流水线定义示例，包括了一个构建阶段和一个测试阶段。 pipeline { agent any // 使用任意可用的代理节点 stages { stage('Build') { // 定义构建阶段 steps { echo 'Building...' sh 'make build' } } stage('Test') { // 定义测试阶段 steps { echo 'Testing...' sh 'make test' } } } } 4.2、设置环境变量 可以在流水线中设置环境变量，用于在流水线执行过程中传递参数、配置选项等。 下面示例演示了如何设置一个环境变量并在流水线的步骤中使用。 pipeline { agent any environment { NAME = 'John' // 设置一个环境变量 } stages { stage('Print') { steps { echo "Hello, ${NAME}!" // 使用环境变量 } } } } 4.3、编写流水线脚本 在流水线的各个阶段中编写脚本来实现具体的构建、测试、部署等任务。 下面示例展示了一个简单的流水线，其中包括了一个构建阶段和一个测试阶段，并在每个阶段中执行了一些命令。 pipeline { agent any stages { stage('Build') { steps { echo 'Building...' sh 'make build' } } stage('Test') { steps { echo 'Testing...' sh 'make test' } } } } 4.4、运行流水线 在 Jenkins 中，可以通过在 Jenkins 界面上选择相应的流水线项目并点击“构建”按钮来手动触发流水线的执行。也可以通过配置触发器来实现自动触发流水线的执行，如定时触发、代码提交触发等。 手动触发流水线的执行通常在 Jenkins 界面上进行，点击流水线项目的“构建”按钮即可。自动触发流水线的执行需要在流水线项目的配置中配置相应的触发器，如下： pipeline { triggers { cron('H/5 * * * *') // 每隔 5 分钟触发一次流水线执行 } ... } 五、流水线高级特性 在 Jenkins 中，流水线不仅可以实现简单的构建和测试任务，还可以利用一些高级特性来增强流水线的灵活性、可维护性和扩展性。下面详细介绍几种流水线的高级特性，并提供相应的示例代码。 5.1、参数化构建 参数化构建允许在流水线执行时传递参数值，使得流水线具有更大的灵活性。 下面是一个示例，演示了如何定义一个参数化的流水线，其中包括一个字符串类型的参数 ENVIRONMENT，用于指定环境名称。 pipeline { parameters { string(name: 'ENVIRONMENT', defaultValue: 'production', description: 'Environment name') } agent any stages { stage('Build') { steps { echo "Building for environment: ${params.ENVIRONMENT}" } } } } 5.2、流水线共享库 流水线共享库允许将常用的流水线代码封装为可复用的库，并在多个流水线项目中共享和引用。 创建一个名为 vars 的目录，并在其中编写一个 Groovy 脚本文件（如 utils.groovy），定义一个名为 sayHello 的全局函数，然后在流水线脚本中引用该函数： // vars/utils.groovy def call() { echo 'Hello, world!' } // Jenkinsfile @Library('my-shared-library') _ pipeline { agent any stages { stage('Test') { steps { utils.sayHello() } } } } 5.3、异常处理 异常处理允许在流水线执行过程中捕获和处理异常情况，以实现更健壮的流水线。 下面示例展示了如何使用 try-catch 块来捕获异常，并在出现异常时执行相应的处理逻辑。 pipeline { agent any stages { stage('Deploy') { steps { script { try { sh 'deploy.sh' } catch (Exception e) { echo "Failed to deploy: ${e.message}" currentBuild.result = 'FAILURE' } } } } } } 5.4、日志记录 日志记录允许在流水线执行过程中输出自定义的日志信息，以便在 Jenkins 界面中查看流水线的执行日志。 下面示例展示了如何使用 echo 函数输出自定义的日志信息。 pipeline { agent any stages { stage('Build') { steps { echo 'Building...' sh 'make build' } } } } 六、与源代码管理集成 将流水线与版本控制系统（如 Git、SVN 等）集成可以实现当代码发生变更时自动触发流水线的执行，从而实现持续集成和持续交付。 6.1、Git 集成 Git 是目前最流行的版本控制系统之一，在 Jenkins 中配置 Git 集成可以实现当代码提交或分支变更时自动触发流水线的执行。 下面是一个简单的流水线配置示例，其中包括了 Git 集成，使用了 checkout 步骤来拉取代码并切换到指定分支。 pipeline { agent any stages { stage('Checkout') { steps { checkout([$class: 'GitSCM', branches: name: 'master', userRemoteConfigs: url: 'https://github.com/myuser/myrepo.git']) } } stage('Build') { steps { sh 'make build' } } } } 6.2、SVN 集成 SVN 是另一种常用的版本控制系统，与 Git 类似，通过配置 SVN 集成可以实现当代码提交或分支变更时自动触发流水线的执行。 下面是一个简单的流水线配置示例，其中包括了 SVN 集成，使用了 checkout 步骤来拉取代码并切换到指定路径。 pipeline { agent any stages { stage('Checkout') { steps { svn 'https://svn.example.com/svn/repo/trunk' } } stage('Build') { steps { sh 'make build' } } } } 6.3、高级配置 除了简单的拉取代码外，还可以配置更多高级选项，如指定分支、拉取代码的深度、使用认证信息等。 例如： pipeline { agent any stages { stage('Checkout') { steps { git branch: 'main', credentialsId: 'my-git-credentials', url: 'https://github.com/myuser/myrepo.git' } } // 其他阶段... } } 七、与测试框架集成 将流水线与测试框架集成可以实现自动执行测试并生成测试报告，从而实现持续集成和持续交付。 7.1、1、JUnit 集成 JUnit 是 Java 平台上广泛使用的单元测试框架，通过配置 JUnit 集成可以在流水线执行过程中自动执行单元测试，并生成 JUnit 格式的测试报告。 下面是一个简单的流水线配置示例，其中包括了 JUnit 集成，使用了 junit 步骤来执行单元测试并生成测试报告。 pipeline { agent any stages { stage('Build') { steps { sh 'make build' } } stage('Test') { steps { sh 'make test' } post { always { junit 'target/surefire-reports/*.xml' } } } } } 7.2、TestNG 集成 TestNG 是 Java 平台上的另一个流行的测试框架，与 JUnit 类似，通过配置 TestNG 集成可以在流水线执行过程中自动执行测试并生成测试报告。 下面是一个简单的流水线配置示例，其中包括了 TestNG 集成，使用了 testng 步骤来执行测试并生成测试报告。 pipeline { agent any stages { stage('Build') { steps { sh 'make build' } } stage('Test') { steps { sh 'make test' } post { always { testng 'target/surefire-reports/*.xml' } } } } } 7.3、Selenium 集成 Selenium 是用于自动化 Web 应用程序测试的工具，通过配置 Selenium 集成可以在流水线执行过程中自动执行 Web UI 测试，并生成测试报告。 下面是一个简单的流水线配置示例，其中包括了 Selenium 集成，使用了 sh 步骤来执行 Selenium 测试脚本。 pipeline { agent any stages { stage('Build') { steps { sh 'make build' } } stage('Test') { steps { sh 'make test' } post { always { sh 'python selenium_tests.py' } } } } } 八、与部署工具集成 将流水线与部署工具集成可以实现自动化部署和发布，从而实现持续交付和持续部署。 8.1、Docker 集成 Docker 是一个流行的容器化平台，通过配置 Docker 集成可以在流水线执行过程中构建、打包和发布 Docker 镜像。 下面是一个简单的流水线配置示例，其中包括了 Docker 集成，使用了 Docker Pipeline 插件提供的 docker.build 和 docker.push 步骤来构建和发布 Docker 镜像。 pipeline { agent any stages { stage('Build') { steps { script { docker.build('my-image:latest') } } } stage('Push') { steps { script { docker.withRegistry('https://docker.example.com', 'docker-credentials') { docker.image('my-image:latest').push() } } } } } } 8.2、Kubernetes 集成 Kubernetes 是一个开源的容器编排平台，通过配置 Kubernetes 集成可以在流水线执行过程中部署和管理容器化应用。 下面是一个简单的流水线配置示例，其中包括了 Kubernetes 集成，使用了 Kubernetes Pipeline 插件提供的 kubectl 步骤来部署应用到 Kubernetes 集群。 pipeline { agent any stages { stage('Deploy') { steps { script { kubernetesDeploy( kubeconfigId: 'my-kube-config', configs: 'kube/*.yml' ) } } } } }
一、简介 Docker Machine 是Docker官方编排项目之一，使用go语言编写的，使用不同引擎在多种平台上快速的安装Docker环境。 Docker Machine 是一个工具，它允许你在虚拟宿主机上安装Docker，并使用docker-machine命令管理这个宿主机，可以使用Docker Machine在本地的MAC或者windows box、公司网络，数据中心或者AWS这样的云提供商上创建docker。 使用docker-machine命令，可以启动、审查、停止、重启托管的docker 也可以升级Docker客户端和守护程序并配置docker客户端和宿主机通信。 Docker Machine 也可以集中管理所以得docker主机。 二、为什么要使用 Docker Machine Docker Machine 使你能够在各种 Linux 上配置多个远程 Docker 宿主机。 此外，Machine 允许你在较早的 Mac 或 Windows 系统上运行 Docker，如上一主题所述。 Docker Engine Linux 系统上原生地运行。如果你有一个 Linux 作为你的主系统，并且想要运行 docker 命令，所有你需要做的就是下载并安装 Docker Engine 。然而，如果你想要在网络上、云中甚至本地配置多个 Docker 宿主机有一个有效的方式，你需要 Docker Machine。 无论你的主系统是 Mac、Windows 还是 Linux，你都可以在其上安装 Docker Machine，并使用 docker-machine 命令来配置和管理大量的 Docker 宿主机。它会自动创建宿主机、在其上安装 Docker Engine 、然后配置 docker 客户端。每个被管理的宿主机（“machine”）是 Docker 宿主机和配置好的客户端的结合 三、Docker和Docker Machine之间的区别 当人们说“Docker”时，他们通常是指 Docker Engine，它是一个客户端 - 服务器应用程序，由 Docker 守护进程、一个REST API指定与守护进程交互的接口、和一个命令行接口（CLI）与守护进程通信（通过封装REST API）。Docker Engine 从 CLI 中接受docker 命令，例如 docker run 、docker ps 来列出正在运行的容器、docker images 来列出镜像，等等。 Docker Machine 是一个用于配置和管理你的宿主机（上面具有 Docker Engine 的主机）的工具。通常，你在你的本地系统上安装 Docker Machine。Docker Machine有自己的命令行客户端 docker-machine 和 Docker Engine 客户端 docker。你可以使用 Machine 在一个或多个虚拟系统上安装 Docker Engine。 这些虚拟系统可以是本地的（就像你在 Mac 或 Windows 上使用 Machine 在 VirtualBox 中安装和运行 Docker Engine 一样）或远程的（就像你使用 Machine 在云提供商上 provision Dockerized 宿主机一样）。Dockerized 宿主机本身可以认为是，且有时就称为，被管理的“machines”。 四、安装 Docker Mechine 可以在多种平台上安装使用，包括Linux 、MacOS已经windows Docker Mechine 安装非常的简单：GitHub 地址:Releases。 安装 Docker Mechine： curl -L https://github.com/docker/machine/releases/download/v0.15.0/docker-machine-$(uname -s)-$(uname -m) >/tmp/docker-machine && chmod +x /tmp/docker-machine && sudo cp /tmp/docker-machine /usr/local/bin/docker-machine 查看版本确认是否安装成功： docker-machine -v 五、常用命令参数 active 查看当前激活状态的Docker主机 config 查看当前激活状态Docker主机的连接信息 creat 创建Docker主机 env 显示连接到某个主机需要的环境变量 inspect 以json格式输出指定Docker的详细信息 ip 获取指定Docker主机的地址 kill 直接杀死指定的Docker主机 ls 列出所有的管理主机 provision 重新配置指定主机 regenerate-certs 为某个主机重新生成TLS信息 restart 重启指定的主机 rm 删除某台Docker主机，对应的虚拟机也会被删除 ssh 通过SSH连接到主机上，执行命令 scp 在Docker主机之间以及Docker主机和本地主机之间通过scp远程复制数据 mount 使用SSHFS从计算机装载或卸载目录 start 启动一个指定的Docker主机，如果对象是个虚拟机，该虚拟机将被启动 status 获取指定Docker主机的状态(包括：Running、Paused、Saved、Stopped、Stopping、Starting、Error)等 stop 停止一个指定的Docker主机 upgrade 将一个指定主机的Docker版本更新为最新 url 获取指定Docker主机的监听URL version 显示Docker Machine的版本或者主机Docker版本 help 显示帮助信息 参考： Docker三剑客之Docker Machine
一、前言 Swarm 是 Docker 公司推出的用来管理 docker 集群的平台，几乎全部用 GO 语言来完成的开发的，代码开源：https://github.com/docker/swarm Docker Swarm 和 Docker Compose 一样，都是 Docker 官方容器编排项目，但不同的是，Docker Compose 是一个在单个服务器或主机上创建多个容器的工具，而 Docker Swarm 则可以在多个服务器或主机上创建容器集群服务，对于微服务的部署，显然 Docker Swarm 会更加适合。从 Docker 1.12.0 版本开始，Docker Swarm 已经包含在 Docker 引擎中（docker swarm），并且已经内置了服务发现工具，就不需要像之前一样，再配置 Etcd 或者 Consul 来进行服务发现配置了。 上图可以看出，Swarm 是典型的 master-slave 结构，通过发现服务来选举 manager。manager 是中心管理节点，各个 node 上运行 agent 接受 manager 的统一管理，集群会自动通过 Raft 协议分布式选举出 manager 节点，无需额外的发现服务支持，避免了单点的瓶颈问题，同时也内置了 DNS 的负载均衡和对外部负载均衡机制的集成支持。 二、Docker Swarm 工作原理 2.1、Docker Engine client 通过 docker service create 命令去创建一个服务。 2.2、swarm manager API 这个请求直接由 Swarm manager 的 API 进行接收，接收命令并创建服务对象。 orchestrator 为服务创建一个任务。 allocater 为这个任务分配 IP 地址。 dispatcher 将任务分配到指定的节点。 scheduler 再该节点中下发指定命令。 2.3、worker node：接收manager任务后去运行这个任务 container 创建相应的容器。 worker 连接到调度程序以检查分配的任务。 executor 执行分配给工作节点的任务。 三、Swarm 重要概念 Swarm 集群的管理和编排是使用嵌入 docker 引擎的 SwarmKit，可以在 docker 初始化时启动 swarm 模式或者加入已存在的 swarm。 Node 每一个 docker engin 都是一个node（节点），分为 manager 和worker。Manager节点还执行维护所需群集状态所需的编排和集群管理功能。Work节点接收并执行从管理器节点分派的任务。 Service 一个服务是任务的定义，管理机或工作节点上执行。它是群体系统的中心结构，是用户与群体交互的主要根源。创建服务时，需要指定要使用的容器镜像。 Task 任务是在 docekr 容器中执行的命令，Manager 节点根据指定数量的任务副本分配任务给 worker 节点。一个任务包含了一个容器及其运行的命令。task 是 service 的执行实体，task 启动 docker 容器并在容器中执行任务。 3.1、Swarm 命令行说明 docker swarm 集群管理，子命令有 init, join, leave, update。（docker swarm --help查看帮助）； 执行集群的管理功能，维护集群的状态，选举一个 leader 节点去执行调度任务。 init #初始化集群 join #将节点加入集群 join-token #管理加入令牌 leave #从集群中删除某个节点，强制删除加参数--force update #更新集群 unlock #解锁集群 docker node 节点管理，子命令有 accept, promote, demote, inspect, update, tasks, ls, rm。（docker node --help 查看帮助） 接收和执行任务。参与容器集群负载调度，仅用于承载 task。 demote #将集群中一个或多个节点降级 inspect #显示一个或多个节点的详细信息 ls #列出集群中的节点 promote #将一个或多个节点提升为管理节点 rm #从集群中删除停止的节点，--force强制删除参数 ps #列出一个或多个节点上运行的任务 update #更新节点 docker service 服务创建，子命令有 create, inspect, update, remove, tasks。（docker service--help 查看帮助） 一个服务是 work 节点上执行任务的定义。创建一个服务，指定了容器所使用的镜像和容器运行的命令。 create #创建一个新的服务 inspect #列出一个或多个服务的详细信息 ps #列出一个或多个服务中的任务信息 ls #列出服务 rm #删除一个或多个服务 scale #扩展一个或多个服务 update #更新服务 四、Swarm 的调度策略 Swarm在调度(scheduler)节点（leader节点）运行容器的时候，会根据指定的策略来计算最适合运行容器的节点，目前支持的策略有：spread, binpack, random。 4.1、Random 顾名思义，就是随机选择一个 Node 来运行容器，一般用作调试用，spread 和 binpack 策略会根据各个节点的可用的 CPU, RAM 以及正在运行的容器的数量来计算应该运行容器的节点。 4.2、Spread 在同等条件下，Spread 策略会选择运行容器最少的那台节点来运行新的容器，binpack策略会选择运行容器最集中的那台机器来运行新的节点。使用 Spread 策略会使得容器会均衡的分布在集群中的各个节点上运行，一旦一个节点挂掉了只会损失少部分的容器。 4.3、Binpack Binpack 策略最大化的避免容器碎片化，就是说 binpack 策略尽可能的把还未使用的节点留给需要更大空间的容器运行，尽可能的把容器运行在一个节点上面。 五、Swarm Cluster 模式特性 批量创建服务：建立容器之前先创建一个 overlay 的网络，用来保证在不同主机上的容器网络互通的网络模式。 强大的集群的容错性：Swarm Cluster 不光只是提供了优秀的高可用性，同时也提供了节点弹性扩展或缩减的功能。当容器组想动态扩展时，只需通过 scale 参数即可复制出新的副本出来。如果有需求想在每台节点上都 run 一个相同的副本，方法其实很简单，只需要在命令中将 --replicas n 更换成 --mode=global 即可。 复制服务（--replicas n）：将一系列复制任务分发至各节点当中，具体取决于您所需要的设置状态，例如 --replicas 3 。 全局服务（--mode=global）：适用于集群内全部可用节点上的服务任务，例如 --mode global 。如果大家在 Swarm 集群中设有 7 台 Docker 节点，则全部节点之上都将存在对应容器。 调度机制：所谓的调度其主要功能是cluster的server端去选择在哪个服务器节点上创建并启动一个容器实例的动作。它是由一个装箱算法和过滤器组合而成。每次通过过滤器（constraint）启动容器的时候，swarm cluster 都会调用调度机制筛选出匹配约束条件的服务器，并在这上面运行容器。 六、Dcoker Swarm 集群部署 6.1、环境准备(三台 linux 机器，centos 系统) IP：192.168.10.130 主机名：manager130 担任角色：swarm manager IP：192.168.10.131 主机名：node131 担任角色：swarm node IP：192.168.10.132 主机名：node132 担任角色：swarm node 6.2、创建 Swarm cluster 1、准备工作 1、修改主机名 # 192.168.10.130执行 hostnamectl set-hostname manager130 # 192.168.10.131执行 hostnamectl set-hostname node131 # 192.168.10.132执行 hostnamectl set-hostname node132 2、在所有节点上配置 /etc/hosts 文件 192.168.10.130 manager130 192.168.10.131 node131 192.168.10.132 node132 3、设置防火墙 关闭三台机器上的防火墙，不建议直接关闭防火墙，一般生成环境上不允许直接关闭防火墙。如果开启防火墙，则需要在所有节点的防火墙上依次放行 2377/tcp（管理端口）、7946/tcp/udp（节点间通信端口）、4789/udp（overlay 网络端口）端口。 # 放开2377/tcp，7946/udp，4789/udp端口 firewall-cmd --zone=public --add-port=2377/tcp --permanent firewall-cmd --zone=public --add-port=7946/tcp --permanent firewall-cmd --zone=public --add-port=7946/udp --permanent firewall-cmd --zone=public --add-port=4789/udp --permanent # 重新加载生效 firewall-cmd --reload # 查看 firewall-cmd --list-ports 4、安装 Docker Docker 安装 2、创建 Swarm 并添加节点 1、创建Swarm集群（manager110） docker swarm init --advertise-addr 192.168.10.130 Swarm initialized: current node (sxwaiyl5j64dbxeanxw7wgj8e) is now a manager. To add a worker to this swarm, run the following command: docker swarm join --token SWMTKN-1-4ev72f2jax5vhkhc7bjx6gfb61m8w99ctscpc84p96gdp1xrcz-9mwpr765ca0fdunc94j09wlzf 192.168.10.130:2377 To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions. 上面命令执行后，该机器自动加入到 swarm 集群。这个会创建一个集群 token，作为集群唯一标识。记住这个 token 值，后续将其他节点加入集群都会用到这个 token 值。其中，--advertise-addr 参数表示其它 swarm 中的 worker 节点使用此ip地址与 manager 联系。命令的输出包含了其它节点如何加入集群的命令。再次执行会报如下错误。 解决方法： # 这里的leave就是在集群中删除节点，-f参数强制删除，执行完在重新执行OK docker swarm leave -f docker swarm init --advertise-addr 192.168.10.130 2、查看集群的相关信息 docker info 发现 swarm 状态 active，且是 manager 节点。 docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION sxwaiyl5j64dbxeanxw7wgj8e * manager130 Ready Active Leader 20.10.22 3、添加 node 节点主机到 Swarm 集群 在创建 Swarm 集群的时候就已经给出了添加节点的方法。如果忘记了，可以通过以下命令查看 token 和添加方法。 docker swarm join-token worker node131 & node132 主机上执行： docker swarm join --token SWMTKN-1-4ev72f2jax5vhkhc7bjx6gfb61m8w99ctscpc84p96gdp1xrcz-9mwpr765ca0fdunc94j09wlzf 192.168.10.130:2377 在 manager130 节点上查看 node 信息： docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION sxwaiyl5j64dbxeanxw7wgj8e * manager130 Ready Active Leader 20.10.22 zk6jluzkwevz73yzxu9za8h55 node131 Ready Active 20.10.22 owzfehdo3p0mc807n2328gb9k node132 Ready Active 20.10.22 MANAGER STATUS 的三种状态： Leader 为群体做出所有群管理和编排决策的主要管理者节点。 Reachable 如果 Leader 节点变为不可用，该节点有资格被选举为新的 Leader。 Unavailable 该节点不能和其他 Manager 节点产生任何联系，这种情况下，应该添加一个新的 Manager 节点到集群，或者将一个 Worker 节点提升为 Manager 节点。 升级/降级节点，示例： # 升级 docker node promote node131 # 降级 docker node demote node131 七、在 Swarm 中部署服务 7.1、Nginx 为例 Docker 1.12 版本提供服务的 Scaling、health check、滚动升级等功能，并提供了内置的 dns、vip 机制，实现 service 的服务发现和负载均衡能力。 1、创建网络（overlay） docker node ls docker network create -d overlay nginx_net docker network ls | grep nginx_net 2、部署服务 # 就创建了一个具有一个副本（--replicas 1 ）的nginx服务，使用镜像 nginx docker service create --replicas 1 --network nginx_net --name my_nginx -p 80:80 nginx # 查看 docker service ls 3、查询 Swarm 中服务的信息 --pretty 使命令输出格式化为可读的格式，不加 --pretty 可以输出更详细的信息： docker service inspect --pretty my_nginx 查询到哪个节点正在运行该服务： docker service ps my_nginx 如下该容器被调度到 manager-node 节点上启动了，然后访问 http://192.168.10.130 即可访问这个容器应用（如果调度到其他节点，访问也是如此）。 登陆该节点，可以查看到 nginx 容器在运行中 docker ps 4、在 Swarm 中动态扩展服务(scale) 当然，如果只是通过 service 启动容器，swarm 也算不上什么新鲜东西了。Service 还提供了复制（类似 kubernetes 里的副本）功能。可以通过 docker service scale 命令来设置服务中容器的副本数比如将上面的 my_nginx 容器动态扩展到 4 个。 docker service scale my_nginx=4 和创建服务一样，增加 scale 数之后，将会创建新的容器，这些新启动的容器也会经历从准备到运行的过程，过一分钟左右，服务应该就会启动完成，这时候可以再来看一下 nginx 服务中的容器。 docker service ps my_nginx 可以看到，之前 my_nginx 容器只在 manager-node 节点上有一个实例，而现在又增加了 3 个实例。 5、模拟宕机 node 节点 如果一个节点宕机了（即该节点就会从swarm集群中被踢出），则Docker应该会将在该节点运行的容器，调度到其他节点，以满足指定数量的副本保持运行状态。 将 node131 宕机后或将 node131 的 docker 服务关闭，那么它上面的 task 实例就会转移到别的节点上。当 node131 节点恢复后，它转移出去的 task 实例不会主动转移回来，只能等别的节点出现故障后转移 task 实例到它的上面。使用命令 docker node ls，发现 node131 节点已不在 swarm 集群中了(状态为：Down)。然后过一会查询服务的状态列表。 6、Swarm 动态缩容服务(scale) 同理，swarm 还可以缩容，同样是使用 scale 命令。将 my_nginx 容器变为 1 个 docker service scale my_nginx=1 7、docker service update 除了上面使用 scale 进行容器的扩容或缩容之外，还可以使用 docker service update 命令。 可对服务的启动参数进行更新/修改。 docker service update --replicas 3 my_nginx docker service ps my_nginx 8、删除服务 docker service rm my_nginx 7.2、Swarm 中使用 Volume(挂载目录，mount 命令) 1、查看 volume 的帮助信息 docker volume --help 2、创建一个 volume docker volume create --name testvolume docker volume ls docker volume inspect testvolume 3、创建新的服务并挂载 testvolume(nginx 为例) docker service create --replicas 3 --mount type=volume,src=testvolume,dst=/usr/share/nginx/html --name test_nginx nginx tip：参数 src 写成 source 也可以；dst 表示容器内的路径，也可以写成 target。查看 docker service ls docker service ps test_nginx 7.3、多服务 Swarm 集群部署 这里部署的服务有三个 (nginx服务，visualizer 服务，portainer 服务) 除了 nginx 服务作为示例之外，visualizer（官方地址）和 portainer（官方地址）都是集群 GUI 管理服务。docker service 部署的是单个服务，我们可以使用 docker stack 进行多服务编排部署。 1、编写 docker-compose.yml 文件 version: "3" services: nginx: image: nginx ports: - 8888:80 deploy: mode: replicated replicas: 3 visualizer: image: dockersamples/visualizer ports: - "8080:8080" volumes: - "/var/run/docker.sock:/var/run/docker.sock" deploy: replicas: 1 placement: constraints: [node.role == manager] portainer: image: portainer/portainer ports: - "9000:9000" volumes: - "/var/run/docker.sock:/var/run/docker.sock" deploy: replicas: 1 placement: constraints: [node.role == manager] 2、通过这个 yml 文件部署服务 docker stack deploy -c docker-compose.yml deploy_deamon 2、测试验证 第一个服务：deploy_deamon_nginx，先查看调度到哪个节点上 docker service ps deploy_deamon_nginx 看调度到 manager130 和 node132 节点上。访问：http://192.168.10.130:8888、http://192.168.10.132:8888。 八、Docker Swarm 网络管理 8.1、Swarm 集群产生两种不同类型的流量 控制和管理层面：包括 Swarm 消息管理等，例如请求加入或离开 Swarm，这种类型的流量总是被加密的。(涉及到集群内部的 hostname、ip-address、subnet、gateway 等) 应用数据层面：包括容器与客户端的通信等。（涉及到防火墙、端口映射、网口映射、VIP 等） 8.2、在 Swarm Service 中有三个重要的网络概念 Overlay networks 覆盖物网络，顾名思义是附着在主机底层网络之上的网络， 这个网络保证了不同主机之间容器通信，手动创建。 ingress network 进入网络，顾名思义是外部客户端访问服务时，服务节点间负载均衡（节点在开放端口上收到请求，上交给 IPVS，选择容器），是一种特殊的 overlay 网络，创建集群的时候自动创建。初始化或加入 Swarm 集群时会自动创建 ingress 网络，大多数情况下，用户不需要自定义配置，但是 docker 17.05 和更高版本可以自定义网络 docker_gwbridge 是一种桥接网络，将 overlay 网络（包括 ingress 网络）连接到一个单独的 Docker 守护进程的物理网络。默认情况下，服务正在运行的每个容器都连接到本地 Docker 守护进程主机的 docker_gwbridge 网络。docker_gwbridge 网络在初始化或加入 Swarm 时自动创建。大多数情况下，用户不需要自定义配置，但是 Docker 允许自定义。 在初始化或刚加入 Swarm 集群时，会自动创建一个 Ingress 和 docker-gwbridge 网络 九、docker-machine、docker swarm、docker node、docker service 和 docker stack 常用命令 9.1、docker-machine 常用命令 docker-machine create 创建一个 Docker 主机（常用-d virtualbox） docker-machine ls 查看所有的 Docker 主机 docker-machine ssh SSH 到主机上执行命令 docker-machine env 显示连接到某个主机需要的环境变量 docker-machine inspect 输出主机更多信息 docker-machine kill 停止某个主机 docker-machine restart 重启某台主机 docker-machine rm 删除某台主机 docker-machine scp 在主机之间复制文件 docker-machine start 启动一个主机 docker-machine status 查看主机状态 docker-machine stop 停止一个主机 9.2、docker swarm 常用命令 docker swarm init 初始化集群 docker swarm join-token worker 查看工作节点的 token docker swarm join-token manager 查看管理节点的 token docker swarm join 加入集群中 9.3、docker node 常用命令 docker node ls 查看所有集群节点 docker node rm 删除某个节点（-f强制删除） docker node inspect 查看节点详情 docker node demote 节点降级，由管理节点降级为工作节点 docker node promote 节点升级，由工作节点升级为管理节点 docker node update 更新节点 docker node ps 查看节点中的 Task 任务 9.4、docker service 常用命令 docker service create 部署服务 docker service inspect 查看服务详情 docker service logs 查看某个服务日志 docker service ls 查看所有服务详情 docker service rm 删除某个服务（-f强制删除） docker service scale 设置某个服务个数 docker service update 更新某个服务 9.5、docker stack 常用命令 docker stack deploy 部署新的堆栈或更新现有堆栈 docker stack ls 列出现有堆栈 docker stack ps 列出堆栈中的任务 docker stack rm 删除堆栈 docker stack services 列出堆栈中的服务 docker stack down 移除某个堆栈（不会删除数据） 十、Docker 组件 docker-compose 主要是解决本地 docker 容器编排问题。 docker-machine 是解决 docker 运行环境问题。 docker-swarm 是解决多主机多个容器调度部署问题。
一、Harbor 简介 1.1、简介 Harbor 是 VMware 公司开源的企业级 Docker Registry 项目，其目标是帮助用户迅速搭建一个企业级的 Docker Registry 服务。 Harbor 以 Docker 公司开源的 Registry 为基础，提供了图形管理 UI 、基于角色的访问控制(Role Based AccessControl) 、AD/LDAP 集成、以及审计日志(Auditlogging) 等企业用户需求的功能，同时还原生支持中文。 Harbor 的每个组件都是以 Docker 容器的形式构建的，使用 docker-compose 来对它进行部署。用于部署 Harbor 的 docker-compose 模板位于 harbor/docker-compose.yml。 1.2、Harbor 的特性 1、基于角色控制：用户和仓库都是基于项目进行组织的，而用户在项目中可以拥有不同的权限。 2、基于镜像的复制策略：镜像可以在多个 Harbor 实例之间进行复制（同步）。 3、支持 LDAP/AD：Harbor 可以集成企业内部已有的 AD/LDAP（类似数据库的一张表），用于对已经存在的用户认证和管理。 4、镜像删除和垃圾回收：镜像可以被删除，也可以回收镜像占用的空间。 5、图形化用户界面：用户可以通过浏览器来浏览，搜索镜像仓库以及对项目进行管理。 6、审计管理：所有针对镜 像仓库的操作都可以被记录追溯，用于审计管理。 7、支持 RESTful API：RESTful API 提供给管理员对于 Harbor 更多的操控, 使得与其它管理软件集成变得更容易。 8、Harbor 和 docker registry 的关系：Harbor 实质上是对 docker registry 做了封装，扩展了自己的业务模板。 1.3、Harbor的构成 Harbor 在架构上主要有 Proxy、Registry、Core services、Database（Harbor-db）、Log collector（Harbor-log）、Job services 六个组件。 Docker Harbor 私有仓库操作的过程： 1、所有的请求或认为的操作都会首先交给 proxy（反向代理）。 2、proxy 会先将请求转发给后端Core services，Core services 中包含 UI、token（身份验证服务）、webhook（网站的一些服务功能）。 3、转发给registry（镜像存储），若需要下载镜像等权限操作，需要通过 Core services 中的 token 令牌的身份验证服务才行。 4、每一次下载和上传都产生操作记录，生成日志，保存至 database 中。 5、database 记录保存镜像的元信息及用户与组的身份信息，通过验证授权才能允许相关操作。 Proxy: 是一个 nginx 的前端代理，Harbor 的 Registry、UI、Token 服务等组件，都处在 nginx 反向代理后边。 该代理将来自浏览器、docker clients 的请求转发到后端不同的服务上。 Registry: 负责储存 Docker 镜像，并处理 Docker push/pull 命令。由于要对用户进行访问控制，即不同用户对 Docker 镜像 有不同的读写权限，Registry 会指向一个 Token 服务，强制用户的每次 Docker pull/push 请求都要携带一个合法的 Token， Registry 会通过公钥对 Token 进行解密验证。 Core services: Harbor的核心功能， UI（harbor-ui）: 提供图形化界面，帮助用户管理 Registry 上的镜像（image）, 并对用户进行授权。 WebHook：为了及时获取Registry上image 状态变化的情况，在Registry 上配置 Webhook，把状态变化传递给 UI 模块。 Token 服务：负责根据用户权限给每个 Docker push/pull 命令签发 Token。Docker 客户端向 Registry 服务发起的请求， 如果不包含 Token，会被重定向到 Token 服务，获得 Token 后再重新向 Registry 进行请求。 Database（harbor-db）：为core services提供数据库服务，负责储存用户权限、审计日志、Docker 镜像分组信息等数据。 Job services: 主要用于镜像复制，本地镜像可以被同步到远程 Harbor 实例上。 Log collector（harbor-log）: 负责收集其他组件的日志到一个地方。 二、部署Harbor 2.1、部署 Docker-Compose 服务 Docker-Compose 容器编排 2.2、部署 Harbor 服务 2.2.1下载或上传 Harbor 安装程序 # 下载harbor离线安装包 wget -c https://github.com/goharbor/harbor/releases/download/v2.8.1/harbor-offline-installer-v2.8.1.tgz # 解压 tar -zxvf harbor-offline-installer-v2.8.1.tgz -C /opt/module 2.3、修改Habor配置文件 harbor.cfg cp harbor.yml.tmpl harbor.yml //修改配置文件中hostname内容 vim harbor.yml .... hostname: 192.168.10.130 #修改为当前主机的IP或域名 # http related config http: port: 80 #https: #注释掉https服务 # port: 443 # certificate: /your/certificate/path # private_key: /your/private/key/path # internal_tls: # enabled: true # dir: /etc/harbor/tls/internal harbor_admin_password: Harbor12345 --指定密码 2.4、安装 Harbor ./install.sh 2.5、登录harbor的web平台 默认用户名：admin，默认密码：Harbor12345 2.6、登录成功界面 2.7、推送镜像至 Harbor docker login -u admin -p Harbor12345 http://127.0.0.1 或者： docker login 192.168.10.130 Username: admin Password: Error response from daemon: Get "https://192.168.10.130/v2/": dial tcp 192.168.2.50:443: connect: connection refused 解决登录失败方法如下： 默认访问 Docker 仓库使用 443 端口，要修改为 80 端口仓库地址。 # 重启harbor服务： docker-compose stop && docker-compose start 下载镜像并修改 tag： docker pull nginx docker tag nginx:latest 192.168.10.130/library/nginx:v1 推送镜像到 library 项目： docker push 192.168.10.130/library/nginx:v1 2.8、Harbor 启停 # 进入 Harbor 安装目录 cd harbor # 关闭 Harbor docker-compose down # 开启 Harbor docker-compose up -d # 查看服务状态 docker-compose ps # 重启 Harbor docker-compose restart # 查看服务日志 docker-compose logs # 查看某个具体服务的日志，例如 nginx docker-compose logs nginx # 停止某个具体服务 docker-compose stop nginx # 启动某个具体服务 docker-compose start nginx
一、初始化环境 在节点安装必要的软件环境： JDK 11 及以上 | Linux - JDK 安装 Maven | Linux - Maven 安装 Git | Linux - Git 安装 二、系统配置 System Configuration 2.1、Credentials Dashboard > Manage Jenkins > Credentials 2.2、Tools Dashboard > Manage Jenkins > Tools JDK： Git： 2.3、System Dashboard > Manage Jenkins > System GitHub： 三、Freestyle Project 3.1、General 3.2、源码管理 3.3、Triggers 3.4、Environment 3.5、Build Steps pkill -f jenkins_demo-1.0-SNAPSHOT.jar || true cd target pwd source /etc/profile BUILD_ID=dontKillMe nohup java -jar jenkins_demo-1.0-SNAPSHOT.jar > /usr/local/nohup.out 2>&1 & 3.6、构建后操作 四、使用 nohup 构建失败 通过 jenkins 执行 shell 脚本时，脚本中是通过 nohup java -jar xxx.jar & 的方式启动，显示执行成功，但是服务却没启动，脚本如下： nohup java -jar xxx.jar & 4.1、原因 jenkins 默认会在构建完成后，杀掉构建过程中由 shell 命令触发的衍生进程。 jenkins 根据 BUILD_ID 识别某个进程是否为构建过程的衍生进程，故修改 BUILD_ID 后，jenkins 就无法识别是否为衍生进程，则此进程能在后台保留运行。 结论就是 Jenkins 程序只负责运行伪命令行 nuhup 命令，并不保证是否成功运行 nuhup 后面的命令。 4.2、解决 1、使用 BUILD_ID=xxx ，其中 xxx 可以是任意内容（只要不是原来的BUILD_ID内容即可），同时需要把 nohup 输出内容重定向到文件里面，如 /usr/local/nohup.out。 BUILD_ID=dontKillMe nohup java -jar jenkins_demo-1.0-SNAPSHOT.jar > /usr/local/nohup.out 2>&1 & 2、使用 at now 代替 nohup 命令。 #so "at now" will run even if java -jar fails set +e #Run java app in background echo "java -jar jenkins_demo-1.0-SNAPSHOT.jar > /usr/local/nohup.out 2>&1 &" | at now set -e 执行的时候如果出现了返回值为非零，整个脚本就会立即退出。 set +e 执行的时候如果出现了返回值为非零将会继续执行下面的脚本。 五、开启 Webhooks 监听 git 提交自动构建： github 项目开启钩子： 现有项目的 webhooks 选项，Payload URL：jekins地址/github-webhook/。
一、下载 git官网 有两种安装方法第一种，yum 安装，直接输入一行命令就可以进行安装了。 yum install git 输入 git --version 查看 Git 是否安装完成以及查看其版本号 1.8.3.1(不建议)。 默认安装位置：/usr/libexec/git-core。 卸载：yum remove git。 二、安装 将下载的安装包，上传到 /opt/software，解压： tar -zxvf git-2.34.1.tar.gz -C /opt/module/git 安装编译环境： yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker 编译源码，prefix 里面填你想要放的文件夹位置： make prefix=/opt/module/git all 安装 git： make prefix=/opt/module/git install 配置环境变量： vim /etc/profile export GIT_HOME=/opt/git export PATH=$GIT_HOME/bin:$PATH source /etc/profile 查看安装的版本： git --version 查看 git 命令位置： whereis git 参考： Windows安装Git
一、简介 Jenkins 是一个开源的持续集成（CI）工具，用于自动化构建、测试和部署软件项目。它提供了一个易于使用和可扩展的平台，帮助团队更高效地开发和交付软件。 官网 中文文档 二、安装前准备 Jenkins 的入门指南 Jenkins 对机器的要求是至少要 256 MB 的内存，还需要安装 Java。 可以 java -version 命令来检查是否已经安装了 Java。 如何在 Linux 上安装 Java。 使用 Jenkins 在 Linux 上构建 Java 项目，可先安装一下 maven，可参考：Linux-安装 maven。 三、下载与安装 进入 Jenkins 的 官方下载页面。 LTS 是长期支持的版本，是稳定的版本。 在下载安装包之前要先确定应该下载哪个版本的 Jenkins，Jenkins 的版本依赖于 Java 的版本，可在 Jenkins-Java Support Policy 中进行查看。 1、上传文件至 /opt/software 目录下。 2、创建启动脚本。 touch start-jenkins.sh echo "nohup java -jar /opt/software/jenkins.war --httpPort=8080 >./jenkins.log 2>&1 &" > start-jenkins.sh chmod -R 777 ./start-jenkins.sh 3、启动 jenkins，bash start-jenkins.sh。 查看日志：tail -f jenkins.log。 4、访问并初始化 Jenkins（需要服务器能从公网访问） 注意：防火墙请开启 8080 端口。 如果是阿里云服务器，需要在安全组内开放 8080 端口的访问权限。 四、常用插件 JDK Parameter Plugin JDK 版本控制器，用于管理多个版本 JDK 环境。 Maven Integration Maven 项目构建。 Git Parameter Plug-In 参数化构建插件。 Redeploy Rancher2.x Workload Plugin 触发镜像自动部署 rancher。 CloudBees Docker Build and PublishVersion 打包镜像并推送镜像仓库。 Docker Pipeline 构建 docker 流水线。 GitLab gitlab 触发自动构建插件，GitLab 插件允许您使用 WebHooks 从 GitLab 调用管道，并将构建结果发布回 GitLab。 Version Number 版本号自定义管理。 Material Theme jenkins 主题。 Job Configuration History Plugin jenkins 配置管理。 Role-based Authorization Strategy Jenkins 用户视图权限管理插件。 Timestamper 将时间戳添加到控制台输出。 HTML Publisher plugin html 报告。 Allure Jenkins Plugin Allure 报告。 Publish Over SSH ssh 管理，通过 ssh 发布到远程的服务器。 NodeJS Plugin vue 项目所需 nodejs 环境管理。 Pipeline 流水线管理。 Veinmind Jenkins 镜像扫描（有些许问题）。 Blue Ocean Jenkins 现代和直观用户界面，提供了 CI/CD 流水线的可视化表示。 DingTalk 钉钉通知插件。 Git Parameter Plug-In Git Parameter 插件允许您将 Git branches、tags 或 revisions 作为启动作业或管道的参数。 Branch API Plugin 分支管理。 Credentials Binding Plugin Credentials Plugin Plain Credentials Plugin SSH Credentials Plugin Authentication Tokens API Plugin 凭据管理。 Resource Disposer Plugin 资源清理。 Variant Plugin 变量管理。 Workspace Cleanup Plugin 工作空间清理。
一、Keepalived 介绍 Keepalived 是 Linux 下一个轻量级别的高可用解决方案，通过虚拟路由冗余协议来实现服务或者网络的高可用。 起初是为 LVS 设计的，专门用来监控集群系统中各个服务节点的状态。 如果某个服务器节点出现故障，Keepalived 将检测到后自动将节点从集群系统中剔除。 而在故障节点恢复正常后，Keepalived 又可以自动将此节点重新加入集群中。 这些工作自动完成，不需要人工干预，需要人工完成的只是修复出现故障的节点。 1.1、特点： 1、部署简单，只需要配置一个配置文件即可。 2、加入了虚拟路由冗余协议，可以保证业务或网络不间断稳定运行。 1.2、核心功能： 1.2.1、健康检查 采用 tcp 三次握手，icmp 请求，http 请求，udp、echo 请求等方式对负载均衡器后面的实际的服务器 (通常是承载真实业务的服务器) 进行保活。 1.2.2、故障切换 主要应用在配置了主备的服务器上，使用虚拟路由冗余协议维持主备之间的心跳。 当主服务器出现问题时，由备服务器承载对应的业务，从而在最大限度上减少损失，并提供服务的稳定性。 1.3、VRRP 协议 在现实的网络环境中，主机之间的通信都是通过配置静态路由（默认网关）来完成的。 而主机之间的路由器一旦出现故障，就会通信失败。 因此在这种通信模式下，路由器就会有单点瓶颈问题，为了解决这个问题，引入了 VRRP 协议（虚拟路由冗余协议）。 通过 VRRP 可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。 VRRP 可以将两台或多台物理路由器设备虚拟成一个虚拟路由器，这个虚拟路由器通过虚拟 IP（一个或多个）对外提供服务，而在虚拟路由器内部是多个物理路由器协同工作，VRRP 角色如下： 1.3.1、角色 虚拟路由器：VRRP 组中所有的路由器，拥有虚拟的 IP+MAC (00-00-5e-00-01-VRID) 地址。 主路由器（master）：虚拟路由器内部通常只有一台物理路由器对外提供服务，主路由器是由选举算法产生，对外提供各种网络功能。 备份路由器（backup）：VRRP 组中除主路由器之外的所有路由器，不对外提供任何服务，只接受主路由的通告，当主路由器挂掉之后，重新进行选举算法接替 master 路由器。 master 路由器由选举算法产生，它拥有对外服务的 VIP，提供各种网络服务，如 ARP 请求、数据转发、ICMP 等等，而 backup 路由器不拥有 VIP，也不对外提供网络服务。 当 master 发生故障时，backup 将重新进行选举，产生一个新的 master 继续对外提供服务。 1.3.2、VRRP 工作模式 VRRP 有三种工作状态，分别是： Initialize 状态 Master 状态 Backup 状态 选举机制: 抢占模式：一旦有优先级高的路由器加入，立即成为 Master。 非抢占模式：只要 Master 不挂掉，优先级高的路由器只能等待。 二、Keepalived 原理 keepalived 工作在 TCP/IP 参考模型的第三、四和第五层，也就是网络层、传输层和应用层。 网络层：通过 ICMP 协议向集群每个节点发送一个 ICMP 数据包（类似于 ping 功能），如果某个节点没有返回响应数据包，那么认定此节点发生了故障，Keepalived 将报告此节点失效，并从集群中剔除故障节点。 传输层：通过 TCP 协议的端口连接和扫描技术来判断集群节点是否正常，keepalived 一旦在传输层探测到这些端口没有响应数据返回，就认为这些端口所对应的节点发生故障，从集群中剔除故障节点。 应用层：用户可以通过编写程序脚本来运行 keepalived，keepalived 根据脚本来检测各种程序或者服务是否正常，如果检测到有故障，则把对应的服务从服务器中删除。 2.1、组件架构 我们将整个体系结构分层用户层和内核层： Scheduler I/O Multiplexer I/O 复用分发调用器，负责安排 Keepalived 所有的内部的任务请求 Memory Management 内存管理机制，提供了访问内存的一下通用方法 Keepalived Control Plane 控制面板，实现对配置文件的编译和解析，Keepalived 的配置文件解析比较特殊，它并不是一次解析所有模块的配置，而是只有在用到某模块时才解析相应的配置 Core components Keepalived 的核心组件，包含了一系列功能模块，主要有 watch dog、Checkers、VRRP Stack、IPVS wrapper、Netlink Reflector。 watch dog 一个极为简单又非常有效的检测工具，针对被监视目标设置一个计数器和阈值，watch dog 会自己增加此计数值，然后等待被监视目标周期性的重置该数值，一旦被监控目标发生错误，就无法重置该数值，watch dog 就会检测到。Keepalived 是通过它来监控 Checkers 和 VRRP 进程。 Checkers 实现对服务器运行状态检测和故障隔离。 VRRP Stack 实现 HA 集群中失败切换功能，通过 VRRP 功能再结合 LVS 负载均衡软件即可部署一个高性能的负载均衡集群。 IPVS wrapper 实现 IPVS 功能，该模块可以将设置好的 IPVS 规则发送到内核空间并提交给 IPVS 模块，最终实现负载均衡功能。 Netlink Reflector 实现 VIP 的设置和切换。 三、安装 & 配置 yum install -y keepalived 配置文件都是以块（block）的形式组成，每一个块的内容都包含在 { } 中。 手动安装： tar -zxvf keepalived-2.2.8.tar.gz cd keepalived-2.2.8 ./configure --prefix=/usr/local/keepalived make install 复制 Keepalived 到系统服务目录： cp /root/tool/keepalived-2.2.8/keepalived/etc/init.d/keepalived /etc/rc.d/init.d 设置开机自启动： chkconfig --add keepalived chkconfig keepalived on 3.1、全局配置 ! Configuration File for keepalived global_defs { notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 192.168.200.1 smtp_connect_timeout 30 router_id LVS_DEVEL vrrp_skip_check_adv_addr vrrp_strict vrrp_garp_interval 0 vrrp_gna_interval 0 } 其中： global_defs 全局配置标识。 notification_email 用于设置报警的邮件地址，可以设置多个，每行一个。如果要开启邮件报警，需要开启本机的 sendmail 服务。 notification_email_from 邮件的发送地址。 smtp_server 设置邮件的 smtp server 地址。 smtp_connect_timeout 设置连接 smtp server 的超时时间。 router_id 运行 keepalived 的一个标识，唯一。 vrrp_skip_check_adv_addr 对所有通告报文都检查，会比较消耗性能，启用此配置后，如果收到的通告报文和上一个报文是同一个路由器，则跳过检查，默认值为全检查。 vrrp_strict 严格遵守 VRRP 协议，启用此项后以下状况将无法启动服务：1. 无 VIP 地址 2. 配置了单播邻居 3. 在 VRRP 版本 2 中有 IPv6 地址，开启动此项并且没有配置 vrrp_iptables 时会自动开启 iptables 防火墙规则，默认导致 VIP 无法访问，建议不加此项配置。 vrrp_iptables 此项和 vrrp_strict 同时开启时，则不会添加防火墙规则，如果无配置 vrrp_strict 项，则无需启用此项配置。 vrrp_garp_interval 0 gratuitous ARP messages 报文发送延迟，0 表示不延迟。 vrrp_gna_interval 0 unsolicited NA messages （不请自来）消息发送延迟。 3.2、VRRP 实例配置 vrrp_script nginx_check { script"/tools/nginx_check.sh" interval 1 } vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 52 mcast_src_ip 192.168.10.102 # 填写本机ip priority 100 advert_int 1 authentication { auth_type PASS auth_pass test } virtual_ipaddress { 192.168.149.100 } track_script { nginx_check } notify_master /tools/master.sh notify_backup /tools/backup.sh notify_fault /tools/fault.sh notify_stop /tools/stop.sh } 其中： vrrp_instance VI_1 VRRP 实例开始的标识 VI_1 为实例名称。 state 指定 keepalived 的角色，MASTER 表示此主机是主服务器，BACKUP 表示此主机是备服务器。 interface 指定检测网络的网卡接口。 virtual_router_id 虚拟路由标识，数字形式，同一个 VRRP 实例使用唯一的标识，即在同一个 vrrp_instance 下，master 和 backup 必须一致。 mcast_src_ip 填写本机ip priority 节点优先级，数字越大表示节点的优先级越高，在一个 VRRP 实例下，MASTER 的优先级必须要比 BACKUP 高，不然就会切换角色。 advert_int 用于设定 MASTER 与 BACKUP 之间同步检查的时间间隔，单位为秒。 auth_type PASS 预共享密钥认证，同一个虚拟路由器的 keepalived 节点必须一样。 auth_pass 设置密钥。 virtual_ipaddress 设置虚拟 IP 地址，可以设置多种形式：10.0.0.100 不指定网卡，默认为 eth0, 注意：不指定 /prefix, 默认为 / 32；10.0.0.101/24 dev eth1 指定 VIP 的网卡；10.0.0.102/24 dev eth2 label eth2:1 #指定 VIP 的网卡 label。 nopreempt 设置为非抢占模式，同一实例下主备设置必须一样。 preemtp_delay 设置抢占模式的延时时间，单位为秒。 3.3、脚本相关配置 vrrp_script 自定义资源监控脚本，vrrp 实例根据脚本返回值进行下一步操作，脚本可被多个实例调用。 track_script 调用 vrrp_script 定义的脚本去监控资源，定义在实例之内，调用事先定义的 vrrp_script。实现主备切换，保证服务高可用。 vrrp_script 仅仅通过监控脚本返回的状态码来识别集群服务是否正常，如果返回状态码是 0，那么就认为服务正常，反之亦然。 notify_master 当前节点成为主节点时触发的脚本。 notify_backup 当前节点转为备节点时触发的脚本。 notify_fault 当前节点转为 “失败” 状态时触发的脚本。 notify_stop 当停止 VRRP 时触发的脚本。 四、Nginx+Keepalived 案例 4.1、Nginx 配置 使用 Nginx + Keepalived 实现一个 web 服务高可用方案。 架构图如下： 首先安装 Nginx：参照 Nginx 安装。 安装完 Nginx 之后接着配置 web 站点。 nginx1： [root@nginx1 ~]# vim /etc/nginx/conf.d/web.conf server { listen 8080; root /usr/share/nginx/html; index test.html; } [root@nginx1 ~]# echo " This is web1 " > /usr/share/nginx/html/test.html nginx2： #web2 [root@nginx2 ~]# vim /etc/nginx/conf.d/web.conf server { listen 8080; root /usr/share/nginx/html; index test.html; } [root@nginx2 ~]# echo " This is web2 " > /usr/share/nginx/html/test.html 接着启动 Nginx： ./nginx -t 和 ./nginx 4.2、Keepalived 配置 配置 Keepalived（不同角色有些选项不一样）。 web1:master： vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 192.168.200.1 smtp_connect_timeout 30 router_id LVS_DEVEL vrrp_skip_check_adv_addr vrrp_garp_interval 0 vrrp_gna_interval 0 } vrrp_script nginx_check { script "/tools/nginx_check.sh" interval 1 } vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 52 priority 100 mcast_src_ip 192.168.10.102 # 填写本机ip advert_int 1 authentication { auth_type PASS auth_pass test } virtual_ipaddress { 192.168.149.100 } track_script { nginx_check } notify_master /tools/master.sh notify_backup /tools/backup.sh notify_fault /tools/fault.sh notify_stop /tools/stop.sh } web2:slave： vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 192.168.200.1 smtp_connect_timeout 30 router_id LVS_DEVEL vrrp_skip_check_adv_addr vrrp_garp_interval 0 vrrp_gna_interval 0 } vrrp_script nginx_check { script "/tools/nginx_check.sh" interval 1 } vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 52 priority 99 mcast_src_ip 192.168.10.103 # 填写本机ip advert_int 1 authentication { auth_type PASS auth_pass test } virtual_ipaddress { 192.168.149.100 } track_script { nginx_check } notify_master /tools/master.sh notify_backup /tools/backup.sh notify_fault /tools/fault.sh notify_stop /tools/stop.sh } 将所有脚本放在同一个目录下，方便集中管理。 mkdir /tools 首先是编写 Keepalived 日志脚本 (将每次工作过程输出到日志上)。 vim master.sh #!/bin/bash ip=`hostname -I | awk '{print $1}'` dt=$(date +'%Y%m%d %H:%M:%S') echo "$0--${ip}--${dt}--master" >> /tmp/kp.log vim backup.sh #!/bin/bash ip=$(hostname -I | awk '{print $1}') dt=$(date +'%Y%m%d %H:%M:%S') echo "$0--${ip}--${dt}--backup" >> /tmp/kp.log vim fault.sh #!/bin/bash ip=$(ip addr|grep inet| grep 192.168 |awk '{print $2}') dt=$(date +'%Y%m%d %H:%M:%S') echo "$0--${ip}--${dt}--fault" >> /tmp/kp.log vim stop.sh #!/bin/bash ip=$(ip addr|grep inet| grep 192.168| awk '{print $2}') dt=$(date +'%Y%m%d %H:%M:%S') echo "$0--${ip}--${dt}--stop" >> /tmp/kp.log 编写健康检查脚本 nginx_check.sh。 该脚本对 Nginx 进程进行检测，如果发现 Nginx 进程没了则返回失败（1）。 cat nginx_check.sh #!/bin/bash result=`pidof nginx` if [ ! -z "${result}" ]; then exit 0 else exit 1 fi 添加执行权限，并启动 Keepalived。 cd /tools/ && chmod +x *.sh systemctl restart keepalived.service 五、Keepalived 常用命令 1、启动 keepalived sudo systemctl start keepalived 2、停止 keepalived sudo systemctl stop keepalived 3、重启 keepalived sudo systemctl restart keepalived 4、查看 keepalived 状态 sudo systemctl status keepalived 5、查看 keepalived 运行日志 sudo journalctl -u keepalived 6、设置 keepalived 开机自启 sudo systemctl enable keepalived 7、取消 keepalived 开机自启 sudo systemctl disable keepalived 8、检查 keepalived 配置文件语法（部分发行版支持） sudo keepalived -t -f /etc/keepalived/keepalived.conf 9、查看 keepalived 进程 ps -ef | grep keepalived 10、重新加载配置（有些系统支持 reload） sudo systemctl reload keepalived