14 Essential DevOps Interview Questions *

数据库迁移和新特性是增加DevOps管道复杂性的常见挑战.

特性标志是在CI环境中处理增量产品发布的常用方法.

如果数据库迁移不成功, but was run as a scheduled job, 系统现在可能处于不可用状态. 有多种方法可以预防和减轻潜在的问题:

1. 部署实际上是通过多个步骤触发的. 管道中的第一步启动应用程序的构建过程. 迁移在应用程序上下文中运行. If the migrations are successful, 它们将触发部署管道，否则应用程序将不会被部署.
2. 定义一个约定，所有迁移必须向后兼容. 在这种情况下，所有特性都是使用特性标志实现的. 因此，应用程序回滚独立于数据库.
3. 创建一个基于docker的应用程序，在每个部署上从零开始创建一个隔离的生产镜像. 集成测试在此生产镜像上运行，没有破坏任何关键基础设施的风险.

始终建议使用支持回滚的数据库迁移工具.

Pod是Kubernetes中容器之间的映射. A Pod may contain multiple containers. pod在覆盖网络中有一个扁平的网络层次结构，并以扁平的方式相互通信, 这意味着从理论上讲，覆盖网络中的任何pod都可以与其他pod通话.

取决于您使用的CNI网络插件, 如果它支持Kubernetes网络策略API, Kubernetes允许您指定限制网络访问的网络策略.

策略可以基于IP地址、端口和/或选择器进行限制. (选择器是kubernetes特有的功能，允许在彼此之间连接和关联规则或组件. 例如，您可以将特定的卷连接到特定的pod based on labels by leveraging selectors.)

云提供商允许对网络平面进行细粒度控制，以隔离组件和资源. 一般来说，云提供商的使用概念有很多相似之处. 但是，当您深入了解细节时，会发现各种云提供商处理这种隔离的方式存在一些根本的差异.

在Azure中，这称为虚拟网络(VNet)。, 而AWS和谷歌云引擎(GCE)称之为虚拟私有云(VPC)。.

这些技术将网络与子网隔离，并使用非全局可路由的IP地址.

这些技术之间的路由是不同的. 而客户必须在AWS中自己指定路由表, Azure VNets中的所有资源都允许使用系统路由的流量.

不同云提供商之间的安全策略也存在显著差异.

有多种方法可以构建混合云. 常见的方法是在内部网络和云VPC/VNet之间创建VPN隧道.

AWS Direct Connect或Azure ExpressRoute绕过公共互联网，在私有数据中心和VPC之间建立安全连接. 这是大型生产部署的首选方法.

The Container Network Interface (CNI)是一种API规范，主要关注容器工作负载的创建和连接.

CNI有两个主要命令:添加和删除. Configuration is passed in as JSON data.

When the CNI plugin is added, 在Pod网络命名空间和Host网络命名空间之间创建一个虚拟以太网设备对. 一旦ip和路由被创建和分配, 将信息返回给Kubernetes API服务器.

在后来的版本中添加的一个重要特性是链接CNI插件的能力.

Kubernetes容器是根据它们的调度策略和可用资源来调度运行的.

每个需要运行的Pod都被添加到队列中，调度器将其从队列中取出并对其进行调度. 如果失败，错误处理程序将其添加回队列以供以后调度.

经典的自动化包括软件安装和系统配置(如用户创建)的自动化, permissions, security baselining, 而编排更侧重于现有服务和提供的服务之间的连接和交互. (配置管理涵盖了经典的自动化和编排.)

大多数云提供商都有应用服务器组件, caching servers, block storage, message queueing databases etc. 它们通常可以配置为自动备份和日志记录. 由于所有这些组件都是由云提供商提供的，因此编排这些组件以创建基础设施解决方案就成了一个问题.

云环境中所需的传统自动化的数量取决于可用组件的数量. 现有的组件越多，就越不需要经典的自动化.

在本地或On-Premise环境中，首先必须自动创建这些组件，然后才能编排它们.

对于AWS来说，一个常见的解决方案是CloudFormation，它周围有许多不同类型的包装器. Azure使用部署，而Google Cloud有Google部署管理器.

一个与云提供商无关的常见编排解决方案是Terraform. While it is closely tied to each cloud, 它提供了一种公共状态定义语言来定义资源(如虚拟机), networks, 以及子网)和数据(引用云上的现有状态).)

现在，大多数配置管理工具还提供组件来管理云提供商提供的编排解决方案或api.

CI代表“持续集成”，CD代表“持续交付”或“持续部署”.“持续集成是持续交付和持续部署的基础. 持续交付和持续部署自动化了发布，而CI只自动化了构建.

而持续交付旨在生产可以随时发布的软件, 发布到生产环境仍然是由某人决定手动完成的. 持续部署更进一步，实际上将这些组件发布到生产系统中.

蓝绿部署和金丝雀发布是常见的部署模式.

在蓝绿色部署中，您有两个相同的环境. “绿色”环境承载着当前的生产系统. 部署发生在“蓝色”环境中.

“蓝色”环境被监视是否有故障，以及是否一切正常, 负载平衡和其他组件从“绿色”环境切换到“蓝色”环境.

金丝雀版本是向用户子集推出特定功能的版本，以减少发布新功能所涉及的风险.

AWS上的vpc一般由一个CIDR和多个子网组成. AWS支持每个VPC配置一个IG (internet gateway), 哪一个是用来路由来往互联网的流量. 有IG的子网被认为是公共子网，其他所有子网都被认为是私有子网.

在AWS上创建VPC所需的组件如下:

• 创建空VPC资源，并关联CIDR.
• A public 子网，其中的组件可以从Internet访问. This subnet requires an associated IG.
• A private 可以通过a访问Internet的子网 NAT gateway. NAT网关位于公网子网内部.
• A route table for each subnet.
• 两条路由:一条路由经过IG，一条路由经过NAT网关, 分配到各自的路由表.
• 然后将路由表关联到各自的子网.
• 然后由安全组控制允许哪些入站和出站流量.

这种方法在概念上类似于物理基础设施.

基础设施即代码(IaC)是一种范例，它管理和跟踪文件中的基础设施配置，而不是手动或图形用户界面. 这允许更多可伸缩的基础设施配置，更重要的是允许通过通常的版本控制系统透明地跟踪更改.

配置管理系统是允许以一致的方式管理环境的软件系统, reliable, and secure way.

通过使用优化的领域特定语言(DSL)来定义系统组件的状态和配置, 多人可以在一个地方工作并存储数千台服务器的系统配置.

CFEngine是用于配置管理的第一代现代企业解决方案之一.

他们的目标是通过自动化诸如安装软件、创建和配置用户之类的事情来拥有一个可复制的环境, groups, and responsibilities.

第二代系统为大众带来了配置管理. While able to run in standalone mode, Puppet和Chef通常以主/代理模式配置，其中主将配置分发给代理.

与前面提到的解决方案相比，Ansible是一种新的解决方案，因为简单而受欢迎. 配置存储在YAML中，没有中央服务器. 状态配置通过SSH(或WinRM)传输到服务器, on Windows) and then executed. 这个过程的缺点是，当管理数千台机器时，它可能会变得很慢.

任何被认为能够自我修复的系统都需要能够处理故障和分区.e. 当系统的一部分在一定程度上不能访问系统的其他部分时.

对于数据库，处理分区容忍度的一种常用方法是为写操作使用仲裁. 这意味着每次写入内容时，必须有最少数量的节点确认写入.

从单个节点故障中正常恢复所需的最小节点数是三个节点. 这样，健康的两个节点就可以确认系统的状态.

对于云应用程序，通常将这三个节点分布在三个可用性区域.

日志解决方案用于监视系统运行状况. 事件和指标通常都被记录下来，然后由警报系统进行处理. Metrics could be storage space, memory, 加载或任何其他类型的持续监控的连续数据. 它允许检测偏离基线的事件.

In contrast, 基于事件的日志记录可能涵盖诸如应用程序异常之类的事件, 哪些将被发送到中心位置进行进一步处理, analysis, or bug-fixing.

一个常用的开源日志解决方案是Elasticsearch-Kibana-Logstash (ELK)堆栈. 像这样的堆栈通常由三个组件组成:

1. A storage component, e.g. Elasticsearch.
2. 日志或度量摄取守护进程，如Logstash或Fluentd. 它负责摄取大量数据，并在此过程中添加或处理元数据. 例如，它可能为IP地址添加地理位置信息.
3. 一种可视化解决方案，如Kibana，用于在任何给定时间显示系统状态的重要可视化表示.

大多数云解决方案要么有自己的集中式日志解决方案，其中包含上述一个或多个产品，要么将它们绑定到现有的基础设施中. AWS CloudWatch, for example, 包含上述所有部分，并大量集成到AWS的每个组件中, 同时还允许将数据并行导出到AWS S3以获得廉价的长期存储.

另一个流行的商业解决方案是Splunk，它可以在本地和云中集中记录和分析. Splunk被认为具有很强的可扩展性，通常也用作安全信息和事件管理(SIEM)系统，并具有先进的表和数据模型支持.