1. 搭建虚拟机

Ubuntu

1.1 网络类型

桥接模式
- 独立IP地址：虚拟机可获取一个独立的IP地址，可以直接访问外部网络，而无需依赖主机。
- 适用场景：适合需要让虚拟机作为网络中独立设备出现的情况，例如作为服务器或需要进行网络测试的环境。
NAT模式
- 间接连接：虚拟机共享宿主机的IP地址，通过宿主机进行网络通信。
  
  从外部网络来看，虚拟机的流量似乎来源于宿主机。
- 适用场景：适合需要网络隔离、资源共享的环境，或者当宿主机的网络设置不允许分配额外IP地址时，如在家庭网络或小型办公网络中。

1.2 I/0控制器

:thinking:当你想要从硬盘读取数据或向硬盘写入数据，I/O控制器就是负责处理这些请求的硬件。

SCSI（Small Computer System Interface，小型计算机系统接口）控制器是一种特定类型的I/O控制器。SCSI是一种用于计算机硬件的接口标准，它定义了计算机和外部设备（如硬盘、扫描仪、光驱等）之间通信的规则。SCSI控制器是实现这种通信的设备。

LSI Logic：这是标准的SCSI控制器，适用于大多数操作系统，特别是对于Windows和Linux系统来说，通常是推荐的选择。

2. 配置连接服务器

Username要写ip地址
尝试了vscode，goland远程连接。配好了本地连接还是挺方便的

3. 部署

用虚拟机来模拟远程服务器

3.1 GitHub Actions

持续集成/持续部署（CI/CD）流程

:thinking:现在我的认知是：在多人开发的时候，用docker给每个人赋予相同的开发环境。代码上传到GitHub上。到项目部署阶段，再用自动化部署工具。

尝试用了用GitHub Actions自动化部署挺方便的。
- 可集成build，deploy，test等等功能
  - test
  - docker
关于配置等敏感信息
- 在本地开发时，你可以直接在代码中或通过本地配置文件（如.env文件）设置必要的配置信息。确保这些文件不会被推送到远程仓库（使用.gitignore）。
- 在GitHub环境中，你可以使用GitHub Secrets或其他类似的机制来安全地存储这些信息。
- 在代码中假如if判断语句，判断是否在本地
  - :heavy_exclamation_mark:误区：到云服务器，还可以读取到GitHub secret吗——不可以

:thought_balloon:`deploy.yml`的编写

源代码就不贴了

GitHub Actions 中的运行器（runner）理解为一个预配置的虚拟机环境（“空白的”），所以对于每个任务job中的每一个步骤都要加载
1
2
# 检出代码
- uses: actions/checkout@v3
GitHub Actions 中的上传和下载构件
- 为什么需要上传和下载构件？
  
  在 GitHub Actions 中，不同的作业（jobs）运行在隔离的环境中。如果您在一个作业中构建了一个应用程序，并希望在另一个作业中使用这个构建的应用程序，那么您需要使用构件（artifacts）来在作业之间传递数据。您首先在构建作业中上传构件，然后在需要使用这些文件的作业中下载构件。这是实现作业间数据共享的一种方式。

部署中该命令会覆盖旧的指定文件

ARGS: "-rltgoDzvO --delete" # 部署参数，表示递归、压缩、保留权限、保留所有者、删除目标目录中源目录没有的文件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

### :thought_balloon:**部署时如何处理** `secrets`

* **GitHub Actions 的 `secrets` 使用逻辑**
  - GitHub Actions 的 `secrets` 是为了在 GitHub 的 CI/CD 环境中安全地使用敏感信息而设计的。在 GitHub Actions 工作流中，您可以使用这些 `secrets` 来完成多种任务，比如构建 Docker 镜像、测试、部署等，而无需将敏感信息硬编码在代码中或公开暴露。

> 虽然 `secrets` 不能直接从 GitHub Actions 传递到您的生产服务器，但有几种方法可以安全地在部署过程中使用这些 `secrets`

#### 3.11 **环境变量注入**：

> **每次部署都需要设置**：您需要在每次部署时通过 GitHub Actions 脚本设置这些环境变量。这确保了敏感数据的安全，因为它们不会在服务器上以文件形式持久存储。

- 在部署脚本中，您可以将 `secrets` 作为环境变量注入到应用程序中。这意味着在部署过程中（如通过 SSH 运行远程命令），`secrets` 会临时作为环境变量设置，供应用程序读取。

  - :ear: **配置**`deploy_script.sh` **脚本**

    - `deploy_script.sh` 是一个在服务器上执行的脚本，它定义了部署过程中应该执行的步骤。这个脚本的作	用包括：

      - **接收环境变量**：脚本可以使用通过 SSH 命令传递的环境变量，如 `SECRET_VAR`。

      - **定义部署逻辑**：脚本中包含了将应用程序从代码库部署到生产环境所需的所有命令。这可能包括复制文件、运行数据库迁移、启动或重启服务等。

        :book:比如：
  
        - `sudo ./voiceHanter`
          - 超级用户（root）权限下，运行当前目录下的可执行文件` voiceHanter`

  
        * 一直在后台运行
          * `nohup sudo ./voiceHanter`

  - **示例场景**

    假设您的应用程序连接一个数据库来运行。在 GitHub Actions 工作流中，您通过 SSH 将数据库dns作为环境变量传递给 `deploy_script.sh` 脚本。脚本使用这个dns来配置应用程序或执行数据库相关的操作。一旦 SSH 会话结束，这个密码不会留在服务器上，确保了敏感信息的安全。

* 具体实现

  * 在 GitHub Actions 中通过环境变量注入 `secrets` 到应用程序中，通常涉及以下步骤：

    ##### **步骤 1: 在 GitHub 仓库中设置 Secrets**

    - 在 GitHub 仓库中，进入 Settings > Secrets。
    - 添加您需要的敏感数据作为 Secrets，比如 `DATABASE_PASSWORD` 或 `API_KEY`。

    ##### **步骤 2: 编写 GitHub Actions 工作流配置**

    * 编辑或创建一个 GitHub Actions 工作流 YAML 文件，比如 `.github/workflows/deploy.yml`。

    * **示例配置**：

      ```yaml
      yamlCopy codename: Deploy Application
      
      on:
        push:
          branches:
            - main
      
      jobs:
        deploy:
          runs-on: ubuntu-latest
          steps:
          - name: Checkout code
            uses: actions/checkout@v2
      
          - name: Deploy to Server
            run: ssh user@your_server_ip "export SECRET_VAR=${{ secrets.SECRET_VAR }}; ./deploy_script.sh"
            env:
              SECRET_VAR: ${{ secrets.SECRET_VAR }}



* 解释:

  - 在 `deploy` 作业的 `run` 命令中，使用 SSH 命令连接到您的服务器，并在远程命令中设置环境变量。这里，`SECRET_VAR` 是通过环境变量传递给远程服务器的。

  - `${{ secrets.SECRET_VAR }}` 是从 GitHub Secrets 获取的值。


**步骤 3: 在服务器上准备部署脚本**

* 确保服务器上有一个脚本（如 `deploy_script.sh`），它可以使用这些环境变量。
  * 示例 `deploy_script.sh`:

1
2
3
4
5
6
bashCopy code#!/bin/bash

# 使用环境变量
echo "使用的密钥: $SECRET_VAR"

# 在这里添加其他部署逻辑


* 确保此脚本在服务器上具有执行权限 (`chmod +x deploy_script.sh`)。

**安全性注意事项**

- 确保 SSH 命令不会在日志中暴露敏感信息。
- 使用 SSH 密钥进行认证，而非密码。

3.12 配置文件生成：

在 GitHub Actions 工作流中，使用 secrets 生成配置文件（如 .env），然后将该文件传输到服务器。这样，应用程序可以在运行时读取这些配置。【已测试成功】
- 会将.env留着服务器上。不如上面那个方法安全性高。

3.13 云服务密钥管理：

使用云服务提供的密钥管理服务（如 AWS Secrets Manager、Azure Key Vault、Google Cloud Secret Manager）来存储 secrets。应用程序可以在运行时通过 API 调用这些服务来获取所需的 secrets。

3.14服务容器化：

如果应用程序是以 Docker 容器形式部署的，可以在构建容器镜像时使用 secrets，然后将镜像推送到私有容器注册中心。部署时，直接从注册中心拉取镜像到生产环境。

3.2 goland部署

vscode也试了试，同理。

本来想用goland直接远程开发。但在服务器上只有4g内存。goland就要占用3g多，就放弃了
- 而且建议本地开发环境要和生产环境分开比较好
- 也更安全
goland可以直接连接服务器，并且可以把本地代码实时更新到服务器上去。

如果是单人开发挺好，就不用部署了。

3.3 XShell

XShell可以在Windows界面下来访问远端不同系统下的服务器，从而比较好的达到远程控制终端的目的。

才疏学浅，感觉和goland相比，goland中也可以调出服务器的终端。浅浅用一下感觉在集成化goland中更加方便

进入服务器控制面板

开启预编译的go项目
- cd myproject
  - 到指定目录下
- chmod -x voiceHanter
- sudo ./voiceHanter
  - 超级用户（root）权限下，运行当前目录下的可执行文件 voiceHanter
- 一直在后台运行
  - nohup sudo ./voiceHanter

Jexi Jiang' Blog

虚拟机VMware-模拟开发

1. 搭建虚拟机

1.1 网络类型

1.2 I/0控制器

2. 配置连接服务器

3. 部署

3.1 GitHub Actions

:thought_balloon:`deploy.yml`的编写

3.12 配置文件生成：

3.13 云服务密钥管理：

3.14服务容器化：

3.2 goland部署

3.3 XShell

参考资料

Jexi Jiang' Blog

虚拟机VMware-模拟开发

1. 搭建虚拟机

1.1 网络类型

1.2 I/0控制器

2. 配置连接服务器

3. 部署

3.1 GitHub Actions

:thought_balloon:deploy.yml的编写

3.12 配置文件生成：

3.13 云服务密钥管理：

3.14服务容器化：

3.2 goland部署

3.3 XShell

参考资料

:thought_balloon:`deploy.yml`的编写