标签: devops

我们使用BotKit开发bot,现在我们尝试以最小的部署停机时间来解决问题.

此服务器上运行服务器和docker容器.内部容器运行bot-app实例与RTM-server(Slack)连接.当我开始部署bot-app的新版本(v2)时,我希望零停机时间,用户不应该看到"僵尸程序脱机".

部署脚本使用新版本的bot-app运行第二个docker容器.bot-app也连接到RTM服务器.通过这种方式,当两个应用程序都运行时,几秒钟连接到RTM服务器并响应用户命令(并且用户将看到他的命令的两个答案).

如果一方面我们希望获得零停机时间,另一方面,我们希望阻止用户同时与这两个实例进行交互,那么我可以得到什么样的最佳决策？

决策1:当两个实例都响应用户命令时,允许发生冲突的可能性很小.

决策2:放弃零停机部署.在这种情况下,部署脚本首先停止第一个docker-container,然后启动另一个docker-container.该应用程序不会响应用户命令,在停止当前版本的应用程序和完全启动应用程序的新版本之间发送.

决策3:通过并行运行当前和新版本的应用程序或互斥体进行交互.一般原理图:1)当前版本的应用程序正在运行2)部署脚本启动应用程序的新版本3)我新的应用程序版本几乎运行并准备连接到RTM服务器,它发送到当前版本的app命令关闭RTM-连接.4)当前版本的应用程序关闭RTM连接5)新版本的应用程序打开RTM连接

我认为还有其他好的解决方案.

您如何在应用程序中解决此问题？

使用 xdotool 执行任何命令都会给我以下错误：

Error: Can't open display: (null)
Failed creating new xdo instance

我尝试导出 display='0' 但似乎没有任何效果。

任何的想法 ？

部署/升级时如何安全地进行 npm install/update ？

• 问题一： npm install是有状态的操作，在命令执行的时候依赖于最新版本的依赖。这会在部署时引起意外，因为package.json文件指示范围而不是特定版本。

• 问题 2：每次我制作npm update或使用时ncu，我都会花费数小时/数天的时间来处理模块之间的不连贯性。为什么会在 2018 年发生这种情况？

• 问题 3：如何拥有package.json准确描述已安装包的状态而不是范围的文件，以便我可以毫无意外地进行部署？

注意：我使用 Angular

使用 helm 在我的 Kubernetes 集群上部署图表，自从有一天，我无法部署新的或升级现有的。

事实上，每次我使用 helm 时，我都会收到一条错误消息，告诉我无法安装或升级资源。

如果我运行helm install --name foo . -f values.yaml --namespace foo-namespace我有这个输出：

错误：释放 foo 失败：服务器找不到请求的资源

如果我运行helm upgrade --install foo . -f values.yaml --namespace foo-namespace或helm upgrade foo . -f values.yaml --namespace foo-namespace出现此错误：

错误：升级失败：“foo”没有部署的版本

我真的不明白为什么。

这是我的掌舵版本：

Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}

在我的 kubernetes 集群上，当我运行时，我部署了相同版本的分蘖kubectl describe pods tiller-deploy-84b... -n kube-system：

Name:               tiller-deploy-84b8...
Namespace:          kube-system
Priority:           0
PriorityClassName:  <none>
Node:               k8s-worker-1/167.114.249.216
Start Time:         Tue, 26 Feb 2019 10:50:21 …

我想V.1.0.00在 Azure DevOps 的持续交付中更改发布名称，例如手动发布，但如果没有这个$(rev:r)，我将无法删除或更改命名，我该如何使用自定义名称？

默认名称： Release- $(rev:r)

必填名称： V.1.0.0

目前，我正在开发一个 azure 基础设施，其中包括以下内容：

• 资源组
• 应用网关
• 应用服务
• 等等

我所拥有的一切都在一个main.tf文件中，我知道这是一个错误，但我想从那里开始。我目前正在尝试将每个部分移动到我的回购中自己的子文件夹中。看起来像这样：

terraform-repo/
??? applicationGateway/
?   ??? main.tf
?   ??? vars.tf
??? appService/
?   ??? main.tf
?   ??? vars.tf
??? main.tf
??? vars.tfvars

但是，当我在尝试从单个文件结构移动时创建它时，我的远程状态出现问题，它想删除不属于当前处理的子文件夹的任何内容。例如，如果我想运行，terraform apply applicationGateway我将得到以下信息：

  # azurerm_virtual_network.prd_vn will be destroyed

Plan: 0 to add, 2 to change, 9 to destroy.

在 terraform repo 中设置多个逻辑上组织的子文件夹的正确方法是什么？或者我是否必须破坏我当前的环境才能像这样设置它？

与自托管运行器中的并行性主题相关的问题：

一个自托管运行器一次只能运行一个作业，当没有可用运行器空闲时，后续作业将排队等待，直到有可用运行器空闲。

我可以通过在具有多个 CPU 的同一台机器上运行多个自托管运行器来实现并行性吗？

在GitHub Actions - Getting Started - Usage Limits我发现：

您可以在您的帐户中运行的并发作业数取决于您的 GitHub 计划，如下表所示。如果超过，任何其他作业都会排队。自托管运行器没有并发限制。

但我不确定如何在多核机器的上下文中理解这一点。

我在 DevOps 中寻找构建自动化时遇到了这个术语，我仍然不确定这个术语到底是什么意思。谁能解释一下？

我正在将 EC2 作为自托管运行器运行。我已将 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY 导出到 EC2，我可以看到它们是用printenv命令设置的。

这样做的原因是我不想将 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY 保存在 github 秘密中。

有什么方法可以在我的 github 操作工作流程中访问和使用环境变量（AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY）？

我制作了自己的 Docker 镜像，这是一个简单的 React 应用程序，并将其推送到 Docker Hub 上。现在我试图在系统中提取我的图像，然后它显示一个错误

来自守护程序的错误响应：abhishek8054/token-app 的清单：未找到最新版本：清单未知：清单未知”。

我做错事了。

我的Dockerfile代码是：

FROM node:16-alpine
WORKDIR /app/
COPY package*.json .
RUN npm install
COPY . .
EXPOSE 3000
CMD ["npm","start"]

我通过以下命令制作了图像：

docker image build -t abhishek8054/token-app:latest .

并使用以下命令推送我的图像：

docker push abhishek8054/token-app:latest

并使用以下命令再次拉取它：

docker pull abhishek/8054/token-app

它给了我上面的错误。