gitlab ci cd 不完全指南

gitlab 可能大家很常用,CI、CD 也应该早有耳闻,但是可能还没有去真正地了解过,这篇文章就是我对 gitlab CI、CD 的一些理解,以及踩过的一些坑,希望能帮助到大家。

什么是 CI、CD

CI(Continuous Integration)持续集成,CD(Continuous Deployment)持续部署(也包含了持续交付的意思)。

CI 指的是一种开发过程的的自动化流程,在我们提交代码的时候,一般会做以下操作:

  • lint 检查,检查代码是否符合规范
  • 自动运行测试,检查代码是否能通过测试

这个过程我们可以称之为 CI,也就是持续集成,这个过程是自动化的,也就是说我们不需要手动去执行这些操作,只需要提交代码,这些操作就会自动执行。

CD 指的是在我们 CI 流程通过之后,将代码自动发布到服务器的过程,这个过程也是自动化的。
在有了前面 CI 的一些操作之后,说明我们的代码是可以安全发布到服务器的,所以就可以进行发布的操作。

为什么要使用 CI、CD

实际上,就算没有 CI、CD 的这些花里胡哨的概念,对于一些重复的操作,我们也会尽量想办法会让它们可以自动化实现的,只不过可能效率上没有这么高,但是也是可以的。

CI、CD 相比其他方式的优势在于:

  • 一次配置,多次使用:我们需要做的所有操作都通过配置固定下来了,每次提交代码我们都可以执行相同的操作。
  • 可观测性:我们可以通过 CI、CD 的日志来查看每次操作的执行情况,而且每一次的 CI、CD 执行的日志都会保留下来,这样我们就可以很方便地查看每一次操作的执行情况。
  • 自动化:我们不需要手动去执行 CI、CD 的操作,只需要提交代码,CI、CD 就会自动执行。
  • 少量配置:一般的代码托管平台都会提供 CI、CD 的功能,我们只需要简单的配置一下就可以使用了。同时其实不同平台的 CI、CD 配置也是有很多相似之处的,所以我们只需要学习一种配置方式,就可以在不同平台上使用了。

gitlab CI、CD

在开始之前,我们可以通过下图来了解一下 CI、CD 的整体流程:

在这里插入图片描述

  1. 在开发人员提交代码之后,会触发 gitlab 的 CI 流水线。也就是上图的 CI PIPELINE,也就是中间的部分。
  2. 在 CI 流水线中,我们可以配置多个任务。比如上图的 buildunit testintegration tests 等,也就是构建、单元测试、集成测试等。
  3. 在 CI 流水线都通过之后,会触发 CD 流水线。也就是上图的 CD PIPELINE,也就是右边的部分。
  4. 在 CD 流水线中,我们可以配置多个任务。比如上图的 stagingproduction 等,也就是部署到测试环境、部署到生产环境等。

在 CD 流程结束之后,我们就可以在服务器上看到我们的代码了。

gitlab CI、CD 中的一些基本概念

在开始之前,我们先来了解一下 gitlab CI、CD 中的一些基本概念:

  • pipeline:流水线,也就是 CI、CD 的整个流程,包含了多个 stage,每个 stage 又包含了多个 job
  • stage: 一个阶段,一个阶段中可以包含多个任务(job),这些任务会并行执行,但是下一个 stagejob 只有在上一个 stagejob 执行通过之后才会执行。
  • job:一个任务,这是 CI、CD 中最基本的概念,也是最小的执行单元。一个 stage 中可以包含多个 job,同时这些 job 会并行执行。
  • runner:执行器,也就是执行 job 的机器,runner 跟 gitlab 是分离的,runner 需要我们自己去安装,然后注册到 gitlab 上(不需要跟 gitlab
    在同一个服务器上,这样有个好处就是可以很方便实现多个机器来同时处理 gitlab 的 CI、CD 的任务)。
  • tag: runnerjob 都需要指定标签,job 可以指定一个或多个标签(必须指定,否则 job 不会被执行),这样 job 就只会在指定标签的 runner 上执行。
  • cache: 缓存,可以缓存一些文件,这样下次流水线执行的时候就不需要重新下载了,可以提高执行效率。
  • artifacts: 这代表这构建过程中所产生的一些文件,比如打包好的文件,这些文件可以在下一个 stage 中使用,也可以在 pipeline 执行结束之后下载下来。
  • variables:变量,可以在 pipeline 中定义一些变量,这些变量可以在 pipeline 的所有 stagejob 中使用。
  • services:服务,可以在 pipeline 中启动一些服务,比如 mysqlredis 等,这样我们就可以在 pipeline 中使用这些服务了(常常用在测试的时候模拟一个服务)。
  • script: 脚本,可以在 job 中定义一些脚本,这些脚本会在 job 执行的时候执行。

CI、CD 的工作模型

我们以下面的配置为例子,简单说明一下 pipelinestagejob 的工作模型,以及 cacheartifacts 的作用:

ci 配置文件(也就是一个 pipeline 的所有任务):

# 定义一个 pipeline 的所有阶段,一个 pipeline 可以包含多个 stage,每个 stage 又包含多个 job。
# stage 的顺序是按照数组的顺序来执行的,也就是说 stage1 会先执行,然后才会执行 stage2。
stages:- stage1 # stage 的名称- stage2# 定义一个 job,一个 job 就是一个任务,也是最小的执行单元。
job1:stage: stage1 # 指定这个 job 所属的 stage,这个 job 只会在 stage1 执行。script: # 指定这个 job 的脚本,这个脚本会在 job 执行的时候执行。- echo "hello world" > "test.txt"tags: # 指定这个 job 所属的 runner 的标签,这个 job 只会在标签为 tag1 的 runner 上执行。- tag1# cache 可以在当前 pipeline 后续的 job 中使用,也可以在后续的 pipeline 中使用。cache: # 指定这个 job 的缓存,这个缓存会在 job 执行结束之后保存起来,下次执行的时候会先从缓存中读取,如果没有缓存,就会重新下载。key: $CI_COMMIT_REF_SLUG # 缓存的 key(也可以是文件名列表,那样对应的)paths: # 缓存的路径- node_modules/artifacts: # 指定这个 job 的构建产物,这个构建产物会在 job 执行结束之后保存起来。可以在下一个 stage 中使用,也可以在 pipeline 执行结束之后下载下来。paths:- test.txtjob2:stage: stage1script:- cat test.txttags:- tag1cache:key: $CI_COMMIT_REF_SLUGpaths:- node_modules/# 指定这个 job 的缓存策略,只会读取缓存,不会写入缓存。默认是既读取又写入,在 job 开始的时候读取,在 job 结束的时候写入。# 但是实际上,只有在安装依赖的时候是需要写入缓存的,其他 job 都使用 pull 即可。policy: pull# job3 和 job4 都属于 stage2,所以 job3 和 job4 会并行执行。
# job3 和 job4 都指定了 tag2 标签,所以 job3 和 job4 只会在标签为 tag2 的 runner 上执行。
# 同时,在 job1 中,我们指定了 test.txt 作为构建产物,所以 job3 和 job4 都可以使用 test.txt 这个文件。
job3:stage: stage2script:- cat test.txttags:- tag1cache:key: $CI_COMMIT_REF_SLUGpaths:- node_modules/policy: pulljob4:stage: stage2script:- cat test.txttags:- tag1cache:key: $CI_COMMIT_REF_SLUGpaths:- node_modules/policy: pull

上面的配置文件的 pipeline 执行过程可以用下面的图来表示:

在这里插入图片描述

说明:

  1. 上面的图有两个 pipeline 被执行了,但是 pipeline2 没有全部画出来
  2. 其中,在 pipeline 1 中,stage1 中的 job 会先被执行,然后才会执行 stage2 中的 job
  3. stage1 中的 job1job2 是可以并行执行的,这也就是 stage 的本质上的含义,表示了一个阶段中不同的任务,比如我们做测试的时候,可以同时对不同模块做测试。
  4. job1job2 都指定了 tag1 标签,所以 job1job2 只会在标签为 tag1runner 上执行。
  5. job1 中,我们创建了一个 test.txt 文件,这个文件会作为 stage1 的构建产物,它可以在 stage2 中被使用,也就是 job3job4
    都可以读取到这个文件。一种实际的场景是,前端部署的时候,build 之后会生成可以部署的静态文件,这些静态文件就会被保留到部署相关的 stage 中。需要注意的是,artifacts 只会在当前
    pipeline 后续的 stage 中共享,不会在 pipeline 之间共享。
  6. 同时,在 job1 中,我们也指定了 cache,这个 cache 会在 job1 执行结束之后保存起来,不同于 artifactscache 是可以在不同的 pipeline
    之间共享的。一种很常见的使用场景就是我们代码的依赖,比如 node_modules 文件夹,它可以加快后续 pipeline 的执行流程,因为避免了重复的依赖安装。

需要特别注意的是:cache 是跨流水线共享的,而 artifacts 只会在当前流水线的后续 stage 共享。

gitlab runner 和 executor

gitlab runner 在 CI/CD 中是一个非常重要的东西,因为我们写的 CI/CD 的配置就是在 runner 上运行的,如果我们想要执行 CI/CD 任务,我们必须先安装配置 gitlab-runner

其中 runner 是一台执行 CI/CD 脚本的机器(也就是安装了 gitlab-runner 的机器)。这个机器可以部署在 gitlab 服务器以外的任意一台电脑上,当然也可以跟 gitlab 在同一台服务器。

而每一个 runner 会对应一种特定的 executorexecutor 就是我们执行 CI/CD 里面 script 的环境。比如如果我们指定了 executor 类型为 docker,那么我们 CI/CD 脚本里面的 script 将会在一个独立的 docker 容器中执行。

简单来说,runner 是执行 CI/CD 脚本的机器,这个机器上有不同类型的 executor,一个 executor 代表着一个不同类型的命令行终端,最常见的是 shelldocker,当然也支持 widnows 的 powershell

我们可以通过下图来了解一下 gitlab 是怎么跟 runner 配合的:

gitlab 是通过 tags 来找到运行脚本的 runner 的,如果 jobtagsrunnertags 匹配了,就可以将那个 job 放到 runner 上处理。

在这里插入图片描述

说明:

  • 我们在两台机器上安装了 gitlab-runner,它们的 IP 是 192.168.2.123192.168.2.234
  • test-jobtags 中包含了 api 这个 tag,而 runner1tags 也包含了 api 这个 tag,因此 test-job 会被 runner1 执行。
  • 同理,npm-install 这个 job 会被 runner3 处理。

从上图我们可以看到,其实不同的 runner 是有可能位于不同的机器上的。

其他一些在个人实践中的一些经验

gitlab 的 CI、CD 是一个很庞大的话题,同时很多内容可能比较少用,所以本文只是介绍个人在实践中用到的一些内容,其他的东西如果有需要,可以自行查阅官方文档。

指定特定分支才会执行的 job

这个算是基本操作了,我们可以通过 only 来指定特定分支才会执行的 job,也有其他方法可以实现,比如 rules,具体请参考官方文档。

deploy-job:stage: deploy# 当前的这个 job 只会在 master 分支代码更新的时候会执行only:- "master"

不同 job 之间的依赖

这个也是基本操作,我们可以通过 needs 来指定不同 job 之间的依赖关系,比如 job1 依赖 job2,那么 job1 就会在 job2 执行完毕之后才会执行。

job1:stage: deployneeds:- job2

指定执行 job 的 runner

我们可以通过 tags 来指定 job 执行的 runner,比如我们可以指定 job 只能在 api 标签的 runner 上执行。

build-job:stage: buildtags:- api

如果我们没有标签为 apirunner,那么这个 job 就会一直不会被执行,所以需要确保我们配置的 tag 有对应的 runner

指定 job 的 docker image

注意:这个只在我们的 runnerexecutordocker 的时候才会生效。也就是我们的 runner 是一个 docker 容器。

有时候,我们需要执行一些特定命令,但是我们全局的 docker 镜像里面没有,可能只需要一个特定的 docker 镜像,这个时候我们可以通过 image 来指定 jobdocker 镜像。

deploy-job:stage: deploytags:- api# 指定 runner 的 docker imageimage: eleven26/rsync:1.3.0script:# 下面这个命令只在上面指定的 docker 镜像中存在- rsync . root@example.com:/home/www/foo

为我们的集成测试指定一个 service

在我们的 CI 流程中,可能会有一些集成测试需要使用到一些服务,比如我们的 mysql,这个时候我们可以通过 services 来指定我们需要的服务。

test_rabbitmq:# 这会启动一个 rabbitmq 3.8 的 docker 容器,我们的 job 就可以使用这个容器了。# 我们的 job 可以连接到一个 rabbitmq 的服务,然后进行测试。# 需要注意的是,这个容器只会在当前 job 执行的时候存在,执行完毕之后就会被删除。所以产生的数据不会被保留。services:- rabbitmq:3.8stage: testonly:- mastertags:- goscript:# 下面的测试命令会连接到上面启动的 rabbitmq 服务- "go test -v -cover ./pkg/rabbitmq"

复用 yaml 配置片段

yaml 中,有一种机制可以让我们复用 yaml 配置片段,比如:

# 发布代码的 job
.deploy-job: &release-jobtags:- apiimage: eleven26/rsync:1.3.0script:- rsync . root@example.com:/home/www/foodeploy-release:<<: *release-jobstage: deployonly:- "release"deploy-master:<<: *release-jobstage: deployonly:- "master"

上面的代码中,我们定义了一个 release-job 的配置片段,然后在 deploy-releasedeploy-master 中,我们都引用了这个配置片段,这样我们就可以复用这个配置片段了。
等同于下面的代码:

# 发布代码的 job
.deploy-job: &release-jobtags:- apiimage: eleven26/rsync:1.3.0script:- rsync . root@example.com:/home/www/foodeploy-release:tags:- apiimage: eleven26/rsync:1.3.0script:- rsync . root@example.com:/home/www/foostage: deployonly:- "release"deploy-master:tags:- apiimage: eleven26/rsync:1.3.0script:- rsync . root@example.com:/home/www/foostage: deployonly:- "master"

yaml 的术语中,这一种机制叫做 anchor

cache vs artifacts

初次使用的人,可能会对这个东西有点迷惑,因为它们好像都是缓存,但是实际上,它们的用途是不一样的。

  • cache 是用来缓存依赖的,比如 node_modules 文件夹,它可以加快后续 pipeline 的执行流程,因为避免了重复的依赖安装。
  • artifacts 是用来缓存构建产物的,比如 build 之后生成的静态文件,它可以在后续的 stage 中使用。表示的是单个 pipeline 中的不同 stage 之间的共享

指定 artifacts 的过期时间

我们可以通过 expire_in 来指定 artifacts 的过期时间,比如:

job1:stage: buildonly:- "release"image: eleven26/apidoc:1.0.0tags:- apiartifacts:paths:- publicexpire_in: 1 hour

因为我们的 artifacts 有时候只是生成一些需要部署到服务器的东西,然后在下一个 stage 使用,所以是不需要长期保留的。所以我们可以通过 expire_in 来指定一个比较短的 artifacts 的过期时间。

cache 只 pull 不 push

gitlab CI 的 cache 有一个 policy 属性,它的值默认是 pull-push,也就是在 job 开始执行的时候会拉取缓存,在 job 执行结束的时候会将缓存指定文件夹的内容上传到 gitlab 中。

但是在实际使用中,我们其实只需要在安装依赖的时候上传这些缓存,其他时候都只是读取缓存的。所以我们在安装依赖的 job 中使用默认的 policy,而在后续的 job 中,我们可以通过 policy: pull 来指定只拉取缓存,不上传缓存。

job:tags:- apiimage: eleven26/rsync:1.3.0cache:key:files:- composer.json- composer.lockpaths:- "vendor/"policy: pull  # 只拉取 vendor,在 job 执行完毕之后不上传 vendor

cache 的 key 使用文件

这一个特性是非常有用的,在现代软件工程的实践中,往往通过 *.lock 文件来记录我们使用的额依赖的具体版本,以保证在不同环境中使用的时候保持一致的行为。

所以,相应的,我们的缓存也可以在 *.lock 这类文件发生变化的时候,重新生成缓存。上面的例子就使用了这种机制。

script 中使用多行命令

script 中,我们可以使用多行命令,比如:

job:script:# 我们可以通过下面这种方式来写多行的 shell 命令,也就是以一个竖线开始,然后换行- |if [ "$release_host" != "" ]; thenhost=$release_hostfi

CD - 如何同步代码到服务器

如果我们的项目需要部署到服务器上,那么我们还需要做一些额外的操作,比如同步代码到服务器上。
如果我们的 gitlab 是通过容器执行的(也就是说 gitlab 是通过 docker 启动的),或者我们的 runner 的 executor 是 docker,那么有一种比较常见的方法是通过 ssh 私钥来进行部署。

我们可以通过以下流程来实现:

  1. 新建一对 ssh key,比如 id_rsaid_rsa.pub
  2. id_rsa.pub 的内容添加到服务器的 authorized_keys 文件中。
  3. id_rsa 上传到 gitlab 中(在项目的 CI/CD 配置中,配置一个变量,变量名为 PRIVATE_KEY,内容为 id_rsa 的内容,类型为 file)。
  4. 在我们的 ci 配置文件中,添加如下配置即可:
before_script:- chmod 600 $PRIVATE_KEYdeploy:stage: deployimage: eleven26/rsync:1.3.0script:# $user 是 ssh 的用户# $host 是 ssh 的主机# $port 是 ssh 的端口# $PRIVATE_KEY 是我们在 gitlab 中配置的私钥- rsync -az -e "ssh -o StrictHostKeyChecking=no -p $port -i $PRIVATE_KEY" --delete --exclude='.git' . $user@$host:/home/www

这里的 rsync 命令中,我们使用了 -o StrictHostKeyChecking=no 参数,这是为了避免每次都需要手动输入 yes 来确认服务器的指纹。

安全最佳实践:

  • 为每一个 project 配置 ssh key 变量,如果是全局变量的话,其他 project 可以在未授权的情况下,访问到这个私钥,这是非常危险的。
  • 使用单独的仓库来保存 ci 配置文件,防止其他人未经授权就修改 ci 配置文件,这也是非常危险的。

必须严格遵循以上两步,否则会造成严重的安全问题。因为拿到了私钥,就等于拿到了我们的服务器密码。

ERROR: Job failed: exit code xx 解决方案

我们在使用的时候可能会经常遇到这种错误(在 job 执行的输出里面),如果运气好,在输出里面也有一些额外的错误信息,
这种是最好处理的,它已经告诉你错误原因了。还有一种非常坑爹的情况是:job 失败了,只有一个非 0 的退出状态码,但是没有任何的报错信息,这种情况就比较难处理(更加坑爹的是,偶尔出现这种失败)。

job script 的执行流程

如果我们理解了 gitab CI/CD 中 job 的执行原理,那么这个问题其实就很好解决了,jobscript 执行流程如下:

  1. 拿到 script 中第一条命令,然后执行。
  2. 检查上一步的退出状态码,如果状态码为 0,继续执行下一条命令。否则,job 直接失败,然后显示信息 ERROR: Job failed: exit code <xx>,最后的 <xx> 就是上一条命令的非 0 的那个退出状态码。
  3. 按以上两个步骤来一条条执行 script 中的命令。

如果使用的是 bash shell,我们可以通过 echo $? 来获取上一条命令的退出状态码。状态码方面的约定都是:0 表示成功,非 0 表示不成功。

解决方法

知道了 job 的执行原理之后,问题就很好解决了,我们只需要在 job 执行日志中找到最后那一条命令即可:

  1. 先看这个命令是否有执行失败相关的错误输出信息,如果有,那么解决对应错误即可。
  2. 如果这个执行失败的命令,一点输出都没有。那么我们可以深入了解一下这个命令的退出状态码什么时候等于我们 job 的状态码,然后再对症下药。

一个实例

下面是一个 job 日志的最后几行,但是不包含具体的错误信息:

$ if (( $need_restart_queue == 1 )); then ssh $user@$host "supervisorctl restart xx"; fi
Cleaning up project directory and file based variables
ERROR: Job failed: exit code 1, no message

第一行是执行的命令,这个命令中,通过 ssh 执行了一条远程命令,然后退出。第二行是 job 失败后做清理操作输出的日志,最后一行输出 job 失败的错误码。

就是这个错误,困扰了我几天,因为它是偶尔失败的。

在这个例子中,比上面说到的要复杂一点,这里通过了 ssh 来执行远程命令,如果通过 ssh 执行远程命令,那么 ssh 命令的退出状态码就是执行的那个远程命令的退出状态码。
明确了这一点,我们就可以把问题定位在那个远程命令 supervisorctl restart xx 上,也就是说我们的失败是因为这个命令导致的。

后面排查发现,supervisorctl 命令本身就有一定几率失败,针对这种情况,有两种解决方案:

  1. 重试,可以给 job 指定重试次数,可以是 0~2,也就是说 gitlab 的 job 最多可以重试 2 次。
  2. 忽略这个错误,使用其他解决方案。(我们可以在 ssh 命令后面加上 || true 来忽略,加上这个,命令退出状态码一定是 0 了)

我是采取了后面那一种解决方法,因为服务器上还有一个定时任务来检测对应的进程,如果进程不存在,则会使用 supervisorctl start xx 来启动对应的服务。

总结

最后,总结一下本文中一些比较关键的内容:

  • gitlab 中的一些基本概念:
    • pipeline:代表了一次 CI 的执行过程,它包含了多个 stage
    • stage:代表了一组 job 的集合,stage 会按照顺序执行。
    • job:代表了一个具体的任务,比如 buildtestdeploy 等。
  • 一个 stage 中的多个 job 是可以并行执行的。但是下一个 stagejob 必须要等到上一个 stage 的所有 job 都执行完毕之后才会执行。
  • cacheartifacts 的区别:
    • cache 是用来缓存依赖的,比如 node_modules 文件夹,它可以加快后续 pipeline 的执行流程,因为避免了重复的依赖安装。
    • artifacts 是用来缓存构建产物的,比如 build 之后生成的静态文件,它可以在后续的 stage 中使用。表示的是单个 pipeline 中的不同 stage 之间的共享
  • cache 在安装依赖的 job 中才需要使用默认的 policy,也就是 pull-push,在其他不需要安装依赖的 job 中使用 pull 就可以了,不需要上传缓存。
  • cachekey 可以指定多个文件,这样在指定的文件变动的时候,缓存会失效,这往往用在依赖相关的文件中。
  • 可以使用 services 关键字来指定需要启动的服务,比如 mysqlredis 等,在 job 中可以连接到这些 services,从而方便进行测试。
  • 可以使用 yamlanchor 机制来复用一些配置片段,可以少写很多重复的配置。
  • 一个 job 必须运行在某个 runner 上,jobrunner 的关联是通过 tag 来指定的。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/662393.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

云计算底层技术、磁盘技术揭秘虚拟化管理、公有云概述

查看本机是否具备虚拟化支持 硬件辅助虚拟化 处理器里打开 虚拟化Inter VT-x/EPT 或AMD-V 构建虚拟化平台工具软件包 yum 与 dnf Yum和DNF都是用于管理Linux系统中的软件包的工具&#xff0c;但它们在许多方面存在一些差异。以下是一些可能的区别&#xff1a; 依赖解…

Python爬虫某云免费音乐——多线程批量下载

重点一&#xff1a;每首音乐的下载地址 重点二&#xff1a;如何判断是免费音乐 重点三&#xff1a;如何用线程下载并保存 重点四&#xff1a;如何规避运行错误导致子线程死掉 重点五&#xff1a;如何管理子线程合理运行 需要全部代码的私信或者VX:Kmwcx1109 运行效果&…

通过阿里云仓库来下载docker镜像

本文的前提是你已经在你的centos中安装了docker。 Step1&#xff1a; 注册登录阿里云登录 - 欢迎登录阿里云&#xff0c;安全稳定的云计算服务平台注册一个阿里云&#xff08;直接用支付宝扫码就行&#xff09;。 Step2&#xff1a; 创建个人实例 ​ Step3&#xff1a; 进…

关于bypassuac的探究——bypass的实现

经过前面的探究过后&#xff0c;我们整理下思路&#xff0c;首先要创建注册表&#xff0c;并添加DelegateExecute这个键值对&#xff0c;并修改command的指向exe路径即可bypassuac&#xff0c;那么这里用到一下几个函数 RegCreateKeyExA 首先是创建注册表项&#xff0c;对应的…

书客、米家、柏曼大路灯哪款好?多维度实测对比推荐!

每到寒暑假&#xff0c;各个论坛上出现“大路灯怎么选”的类似话题非常频繁&#xff0c;因为现在的孩子出来上学期间需要读写之外&#xff0c;在寒暑假时也在不断的学习&#xff0c;许多家长关注到孩子学习时的光线问题&#xff0c;担心影响到孩子的视力状况&#xff0c;都纷纷…

HTTP(Java web方向补充篇)

HTTP&#xff08;Java web方向补充篇&#xff09; HTTP简介 概念&#xff1a;Hyper Text Transfer Protocol,超文本传输协议&#xff0c;规定了浏览器和服务器之间数据传输的规则 HTTP协议特点&#xff1a; 基于TCP协议&#xff1a;面向连接&#xff0c;安全基于请求-响应模…

如何有效获取 Go 变量类型?探索多种方法

嗨&#xff0c;大家好&#xff01;本文是系列文章 Go 小技巧第九篇&#xff0c;系列文章查看&#xff1a;Go 语言小技巧。 文章目录 Go 的类型系统类型获取使用 fmt.Printf类型选择类型选择反射 reflect.TypeOf 其他注意点错误处理性能考量 总结 在 Python 中&#xff0c;可以使…

freertos 源码分析二 list链表源码

list.c 一、链表初始化 void vListInitialise( List_t * const pxList ) { pxList->pxIndex ( ListItem_t * ) &…

求n的k次方

递归法&#xff1a; #include<stdio.h> int mi(int n, int k) {if (k 1) //如果是1次方{return n; //返回n的1次方&#xff08;也就是n&#xff09;}else{return n * mi(n, k - 1); //n*n的k-1次方} } int main() {int n 0, k 0, sum 0;printf("请输入n值…

【Spark实践6】特征转换FeatureTransformers实践Scala版--补充算子

本节介绍了用于处理特征的算法&#xff0c;大致可以分为以下几组&#xff1a; 提取&#xff08;Extraction&#xff09;&#xff1a;从“原始”数据中提取特征。转换&#xff08;Transformation&#xff09;&#xff1a;缩放、转换或修改特征。选择&#xff08;Selection&…

Day02-数据类型和运算符(基本数据类型转换,赋值运算符,算术运算符,关系运算符,逻辑运算符,条件运算符,位运算符,赋值运算符,运算符优先级,标点符号)

文章目录 Java基础语法学习目标1 基本数据类型转换&#xff08;Conversion&#xff09;&#xff08;掌握&#xff09;1.1 自动类型转换&#xff08;隐式类型转换&#xff09;1.2 强制类型转换&#xff08;显式类型转换&#xff09;1.3 基本数据类型与字符串类型的转换 2 运算符…

FluxMQ:新一代的高性能MQTT代理服务器

FluxMQ&#xff1a;新一代的高性能MQTT代理服务器 前言 FLuxMQ是一款基于java开发&#xff0c;支持无限设备连接的云原生分布式物联网接入平台。FluxMQ基于Netty开发&#xff0c;底层采用Reactor3反应堆模型&#xff0c;具备低延迟&#xff0c;高吞吐量&#xff0c;千万、亿级…

二、Gradle 与 Idea 整合

这里写自定义目录标题 1、Groovy简介2、Groovy 安装3、创建 Groovy 项目4、Groovy 基本语法5、在 idea 中创建普通 java 工程 1、Groovy简介 详细了解请参考&#xff1a;http://www.groovy-lang.org/documentation.html 2、Groovy 安装 下载后解压到本地 验证&#xff1a; …

2024美赛数学建模A题思路源码——七鳃鳗性别比例和生态系统关系

赛题目的:分析一个物种根据资源可用性改变其性别比例的能力的利弊。开发一个模型,分析对生态系统中由此产生的相互作用。 问题一.七鳃鳗性别比例对生态系统的影响 问题分析 建立一个简化版的模型,来探讨以下问题: 1.我们假设七鳃鳗种群的增长遵循Logistic生长模型,其中食…

(学习日记)2024.02.01:引用变量 / 默认实参 / 一元作用域运算符 / 函数重载

写在前面&#xff1a; 由于时间的不足与学习的碎片化&#xff0c;写博客变得有些奢侈。 但是对于记录学习&#xff08;忘了以后能快速复习&#xff09;的渴望一天天变得强烈。 既然如此 不如以天为单位&#xff0c;以时间为顺序&#xff0c;仅仅将博客当做一个知识学习的目录&a…

【ChatGPT】文本向量化与余弦相似度:揭开文本处理的神秘面纱(5)

1、引言 在这个数字化的时代&#xff0c;我们每天都会面对大量的文本信息&#xff0c;从社交媒体到新闻报道&#xff0c;文本无处不在。但是&#xff0c;计算机要如何理解和处理这些文字呢&#xff1f;本文将为大家揭开其中的一些奥秘&#xff0c;详细解释文本向量化的概念&am…

postgresql|数据库|pg_repack插件的部署和使用

一&#xff0c; 表和索引的膨胀现象 Postgres SQL 实现的MVCC的机制不同于 oracle &#xff0c; mysql innodb 的 undo tablespace 的机制。 表上所用的更新和删除等操作的行为&#xff0c;都不会实际的删除或修改&#xff0c;而是标记为死元祖 &#xff08;dead rows or dead…

3D应用开发平台HOOPS Platforms优化制造流程和数字化转型

Tech Soft 3D公司的HOOPS Platform &#xff08;包括HOOPS Native Platform 和HOOPS Web Platform&#xff09;&#xff0c;是一种用于开发顶级3D软件的集成技术。具有高性能3D图形&#xff0c;准确&#xff0c;快速的CAD数据转换&#xff0c;3D数据发布以及与流行的建模内核的…

微分几何——梅向明第四版学习笔记(一) 向量函数和曲线论

目录 引出向量函数曲线论简单曲线定义曲线的向量参数表示 曲线的切线【重要】曲线的法面【重要】曲线的自然参数表示 空间曲线曲线的密切平面空间曲线的基本三棱形【重要】单位切向量主法向量副法向量Frenet标架螺旋线的案例 曲线的曲率和曲率半径曲率的几何意义 曲线的挠率挠率…

玻璃钢制品三维扫描机械抄数全尺寸检测服务对比测量检查重合度

玻璃钢制品是一种广泛应用于建筑、汽车、航空航天等领域的复合材料。其制作过程中&#xff0c;需要确保每个环节的精确度&#xff0c;以确保最终产品的质量和性能。为了实现这一目标&#xff0c;三维扫描仪在玻璃钢制品的生产过程中发挥着至关重要的作用。 CASAIM中科广电高精度…