DevOps

我有一本Ansible剧本，我想按顺序更新许多片状设备。我可以使用serial:1，但是如果出现故障，我想完全停止该剧本，这样我可以在继续之前进行修复，而不是积累错误。 我还想在停止的同一台主机上重新启动剧本。当前使用Ansible v2.0，但如果仅在较新的版本中可用，则也可以切换到较新的版本。

15 ansible 

我们确实使用内部证书颁发机构在我的公司中创建服务器证书。 我们还必须处理执行SSL侦听（MITM）的透明代理。 由于Chef不知道CA证书，我经常遇到SSL验证错误，有时它是围绕Chef本身的工具（berkshelf，knife；甚至是第一次与服务器对话时，chef客户本身，因为Chef 12默认启用SSL）。 问题是：如何使Chef知道我的CA证书以获得有效的SSL交换？

15 chef  ssl 

在大型组织中，使用瀑布方法通常会导致非常复杂的分支结构（又称分支spagetti）。 可以使用哪些分支策略从复杂的分支现实过渡到基于分支的开发之类的单分支模型？ 更新： 要澄清的是，问题是关于迁移/过渡本身，而不是关于之前和之后的方法，这很清楚。 不可能真的是“今天在EOB，我们仍然是拥有数以万计的分支机构的瀑布，但是明天第一件事，我们将切换到基于中继的单分支CI”。

15 continuous-integration  branch  waterfall 

我想订购要从S3复制到物理驱动器（SATA HD）并发送到该地址的数据备份。我知道可以使用Amazon Glacier，但是我在任何地方都找不到这种选择。最简单的方法是什么？

15 amazon-s3  storage  amazon-web-services 

我很好奇一个矩阵，例如对每种服务器的安全性/管理简便性/取证能力进行比较。我可能还会忘记每种类型的其他一些关键功能。 我对类型有一个大致的了解，但是在某些情况下（例如，对于应用程序而言自动化变得复杂时），在它们之间进行选择时，引用矩阵会有所帮助。 为了避免担心它的范围太广，我认为将其拆分为多个问题会分散信息，并且有关安全性比较的问题也需要比较每种类型。

15 servers  architecture 

通常的情况是，某些VCS系统中存储库所拥有的产品的代码库会发展到可以认为该代码库包含多个产品的地步。在多个VCS存储库中拆分代码库，每个VCS存储库专用于单个产品，可以利用多种好处（请参见下面的膨胀存储库模型，每个VCS存储库都有一个产品的好处）。从技术方面来说，拆分代码库是一个相当简单的步骤，因为大多数VCS支持此操作。但是，拆分可能会引起与自动化测试，持续交付，服务集成或监视有关的工程问题（请参阅拆分所引发的问题）。）因此，计划进行这种拆分的组织需要知道如何尽可能平稳地执行此过渡，即在不中断其交付和监视管道的情况下。第一步可能是更好地理解项目的概念，以及如何在整体代码库中描述拆分。 在此问题的答案中，我希望看到： 尝试给出产品的实际定义，这提供了在实际代码库中实际描绘产品的实用准则。 根据此工作定义，制定一个实际执行拆分的计划。我们可以简化假设，即代码库是由实现连续集成和持续交付的全自动sdlc处理的。也就是说，每个分支都由在当前代码库中实现的自动化测试套件进行验证，并且每个合并到某个“魔术”分支中都会生成经过测试和部署的产品工件。（产品文物是如源压缩包，文档，二进制软件包，多克尔图像阿美族，unikernels。） 如果它说明了如何规避 分裂引起的问题 自动化测试程序如何与预先存在的整体存储库和拆分存储库相关联？ 自动化部署过程如何与预先存在的整体存储库和拆分存储库相关联？ 自动部署过程本身的代码存储在哪里？ 存储的基础架构，监视和高可用性策略在哪里？ 如何确保开发人员一次只需要一个代码库（但可能会使用其他代码库的伪像）。 像git-bisect这样的工具 边际说明：与膨胀的存储库模型相比，每个VCS存储库拥有产品的好处 与“膨胀存储库”方法相比，拥有多个小型存储库来保存特定产品的代码库具有以下优点： 使用膨胀的存储库，当产品不稳定时，很难回滚发布，因为历史记录与其他产品历史记录混合在一起。 对于庞大的存储库，使用小型存储库很难查看项目历史记录或请求，而我们更可能阅读此信息。（这可能特定于git之类的VCS，与svn不同，我们无法检出子树！） 使用庞大的存储库，我们在开发时必须做更多的分支舞蹈。如果有N个存储库，则可以在N个分支上并行工作；如果只有1个存储库，则只能在一个分支上工作，或者有大量工作副本，这也很麻烦。 日志中有几个小型存储库，提供了该项目的热图。他们甚至可以用作开发团队中知识传播的代理人：如果我三个月以来没有从事repo X，最好将我分配到从事repo X的团队中，以便我随时了解发展情况。在该组件中。 使用小型存储库，更容易获得组件的清晰概述。如果所有内容都放在一个大的存储库中，则没有描绘每个组件的明显伪像，并且代码库可以轻松地移向泥潭。 小型存储库迫使我们致力于组件之间的接口。但是由于我们希望有一个好的封装，无论如何我们都应该做这项工作，因此我认为这对于小型存储库是一个优势。 使用几个小型存储库，可以轻松拥有多个产品所有者。 使用几个小型存储库，可以轻松地拥有与完整存储库相关的简单代码标准，并且可以自动进行验证。

15 deployment  repository 

在应用程序中使用功能标志切换的不同方式是什么？ 如果您要向开发人员说明要从无到有完成功能标记切换的应用程序应该执行的确切操作，那么这些步骤将是什么？

15 feature-flags  continuous-delivery 

我的团队目前正在尝试确定是否应将我们的Nodejs应用程序部署为deb软件包，而不是尝试在诸如Docker的容器中运行它。 我从这里阅读此博客时得到了这个想法，该博客为将deb包用于预先存在的python应用程序提供了一些很好的论据。这个博客吸引我们的重点是维护Docker生态系统的问题（端口共享，权限，Docker映像的托管等）。 对于没有端口冲突且所有依赖项都在虚拟环境中维护的小型服务而言，“将dep-packages作为原始容器”似乎很有意义。 但是，我的直觉告诉我，如果deb软件包非常合适，它将更加常见，并且docker将被宣传为一种针对特定语言的解决方案。使用诸如deb包之类的东西来部署我们的服务，而不是使用诸如docker这样的完整系统是否有任何弊端？

15 deployment  docker 

“当您要求软件工程师设计运营团队时，就会发生SRE。” – 站点可靠性工程 自Google发布《网站可靠性工程手册》以来，我不止一次被告知SRE是现有运营或应用程序支持模型的扩展。 我们有几个问题定义了Sys之间的差异。管理员，DevOps工程师和站点可靠性工程师： Sysadmin和DevOps Engineer有什么区别？ SRE和DevOps有什么区别？ 将DevOps引入新手的有效定义是什么？ 但是，这些问题或其答案均无法说明系统管理员与站点可靠性工程师之间的区别。 从广义上讲：Google的站点可靠性工程实践与企业中传统的分离开发与运营职能之间的主要区别是什么？

15 sre  operating-model  sysadmin 

我正在寻找一种使用Jenkins声明性管道在后台运行Java进程的方法。下面是代码片段 stage('Deploy'){ steps{ script{ withEnv(['BUILD_ID=dontkill']) { sh "nohup java -jar test-0.0.1-SNAPSHOT.war &" } } } } 已经知道詹金斯（Jenkins）的ProcessTreeKiller，并且每个答案都建议这样做。我尝试在步骤块内使用环境没有运气。 Jenkins版本：2.60.1 管道插件：1.1.7 任何帮助是极大的赞赏。

15 jenkins  jenkins-pipeline  jenkinsfile 

我不明白docker和chroot之间的区别。是的，在打包注册表方面非常好。但是不知何故，我感觉到它只是带有额外的铃铛和哨子的根。 我知道我想念什么。如果chroot可以做些类似的事情，那么知道它们之间的不同以及对docker的需求将是很棒的。 我也找不到这个Chroot Vs Docker足够清晰。

15 docker  linux  containers 

我想将我的应用程序以docker映像的形式交付给客户。但是至关重要的是确保最终用户不要更改容器内的任何内容。用户只能运行/停止容器并通过网络与容器交互。 是否可以禁止接触容器内部？是否可以验证该容器制成的图像的完整性？

14 docker  security 

我公司有一个销售的系统，该系统基本上由运行Ubuntu 12.04的微型计算机“ Smartbox”组成。此框运行Django应用程序以及与此相关的许多不同的新贵进程。没什么。我们在现场有成千上万个这样的盒子。我们通过deb软件包管理软件包的依赖关系，过程注册等，并获得不同程度的成功。 我们需要一种有效，强大地将更新发布给我们的用户的方法。我们还需要一些东西，当我们升级操作系统时（如您所知，我们已经过时了进行Ubuntu升级），我们可以对我们的软件包“可以正常使用”感到相对安全。 我对Docker知之甚少，但是当我第一次听说我们的问题（我是新员工）时，Docker是我的第一个想法。但是我想得更多，我觉得可能不是，因为这些盒子是我们的，我们控制着它的操作系统，这是Docker价值主张的重要组成部分，或者据我所知。因此，如果我们知道我们的机器始终是Ubuntu，那么我们基本上只有Django应用程序和一些要运行的进程，那么Doc​​ker是否比deb包更好？ TL; DR：适用于始终运行Ubuntu的分布式设备的Docker vs deb软件包，因此平台独立性并不那么重要。

14 docker 

在开发过程中，拥有完整的Git修订历史记录会有很多好处。 但是我们的产品是源代码，我们使用的脚本语言不需要编译或处理，因此Git历史记录成为部署的负担-在我们的示例中，我们在每次更改后都部署了一个干净的虚拟环境，并在其中进行了多次部署一台机器。 有一些方法可以减少历史记录的数量，例如，浅克隆，其效率取决于分支中修订的深度，执行提取操作而不是克隆，但仍然可以从修订中获取历史记录，或者获取完整的历史记录。回购一次，然后在需要时拉回，但是这在磁盘空间方面是浪费的，并且可靠性较差。 有没有没有历史的Git可以得到一个修订版本的方法？

14 git 

我有以下设置： 创建多个工作程序，进行计算，并在计算完成后终止它们。 因此，每次运行任务都会是一个不同的实例，因此每个主机都有自己的日志文件，这将导致文件列表很大。 这是一个好习惯吗？如果不是，那么在这种特殊用例中记录任务处理的更好方法是什么？ PS：我的基础架构是无服务器的。所以，现在，我正在登录（AWS）CloudWatch。但是，请独立于AWS回答问题，并尽可能适合无服务器设置。

14 serverless  logging