通过CI ci设计案例( 二 ) _云知道

在输出的信息下面有一个网址 http://localhost:32768
我们打开网址:

环境在swarm中运行docker
在这里我们用swarm来管理docker 。而不是用K8s ， swarm稍微简单些，也便于大家通过这篇文章来自己实现CI/CD 。
让应用程序运行在docker中
docker compose 如下
version: "3.7"services:www:image: registry.gitlab.com/lucj/sophia.eventsnetworks:- proxydeploy:mode: replicatedreplicas: 2update_config:parallelism: 1delay: 10srestart_policy:condition: on-failurenetworks:proxy:external: true
简单说明:
· image被放在了gitlab.com私有仓库中
· 服务处于具有两个副本的复制模式，这意味着服务的两个任务/容器同时运行。VIP(虚拟IP地址)通过集群与服务相关联，因此每个针对服务的请求都在两个副本之间实现负载平衡。
· 每次更新服务(部署web站点的新版本)时，更新一个副本， 10秒后更新第二个副本。这确保在更新过程中web站点仍然可用。我们也可以使用回滚策略，但是现在还不需要。
· 该服务附加到外部代理网络，因此TLS终端(运行于部署在集群上的另一个服务中，但不在此项目中)可以向www服务发送请求。
我们通过如下命令运行docker服务:
docker stack deploy -c sophia.yml sophia_events
Docker管理平台portainer.io
Portainer平台有一个很棒的web UI界面，它允许用户非常容易地管理Docker主机和Docker集群。下面是Portainer界面的截图，它列出了集群中可用的应用。

我们看到有三个实例
· portainer自己
· Sophia_events
· TLS
下面列出位于Sophia_events中的www服务的详细信息，我们可以看到服务webhook已被激活。自从Portainer 1.19.2(到目前为止的最后一个版本)以来，这个特性就可用了，它允许我们定义一个HTTP Post端点，可以调用它来触发服务的更新。稍后我们将看到， GitLab运行器负责调用这个webhook 。

注意:从屏幕截图中可以看到，我从localhost:8888访问Portainer UI 。由于我不想将Portainer实例暴露给外部世界，所以通过ssh隧道进行访问，使用以下命令打开ssh隧道:
ssh -i ~/.docker/machine/machines/labs/id_rsa -NL 8888:localhost:9000 $USER@$HOST
然后，所有针对端口8888上的本地机器的请求都通过ssh发送到虚拟机上的端口9000 。9000是Portainer在VM上运行的端口，但是这个端口不对外开放，所以是相对安全的。
注意:在上面的命令中，用于连接VM的ssh密钥是Docker机器在创建VM期间生成的密钥。
Gitlab runnerGitLab runner 是一个负责执行. GitLab –ci.yml 文件的驱动，当代码被push到主分支的时候，会自动执行预先写好的脚本，从而实现自动化。对于这个项目，我们将自己的GitLab runner定义为VM上的docker服务。
下面是配置脚本:
docker run — rm -t -i \-v $CONFIG_FOLDER:/etc/gitlab-runner \gitlab/gitlab-runner register \--non-interactive \--executor "docker" \--docker-image docker:stable \--url "" \--registration-token "$PROJECT_TOKEN" \--description "Exoscale Docker Runner" \--tag-list "docker" \--run-untagged \--locked="false" \--docker-privileged
可以使用PROJECT_TOKEN在gitlab上注册额外的runners