读书笔记《hands-on-docker-for-microservices-with-python》评估
Assessments
Chapter 1
- What is a monolith?
单体是在单个块中创建的软件应用程序。此应用程序作为单个进程运行。它只能统一部署,尽管可以创建多个相同的副本。
- What problems can monoliths run into?
随着它们的增长,单体应用程序可能会遇到以下问题:
- The code becomes too big and difficult to read.
- Scalability problems.
- The need to coordinate deployments.
- Bad usage of resources.
- It's not possible to use conflicting technologies for different situations (for example, different versions of the same library, or two programming languages).
- A single bug and deployment can affect the whole system.
- Can you describe the microservice architecture?
微服务架构是松散耦合的专业服务的集合,它们协同工作以提供全面的服务。
- What is the most important property of a microservice?
微服务最重要的特性是它们可以独立部署,从而可以独立开发。
- What are the main challenges that we need to overcome when migrating from a monolith to a microservice?
可能的挑战包括:
-
- Big changes are needed that require us to change the way the services operate, including the culture of the teams. This can result in training, which is costly.
- Debugging a distributed system is more complicated.
- We need to plan changes so that they don't interrupt the service.
- There's a significant amount of overhead for each microservice that's developed.
- We need to find a balance between allowing each team to decide how to work and standardizing to avoid reinventing the wheel.
- We need to document the service so that we can interact with another team.
- How can we make such a migration?
我们需要分析系统,测量,相应地计划,并执行计划。
- Describe how we can use a load balancer to migrate from an old server to a new one, without interrupting the system.
首先,我们必须配置负载均衡器,使其指向旧的 Web 服务器,这将使流量通过 Web 服务器。然后,我们必须更改 DNS 记录,使其指向负载均衡器。流量通过负载均衡器后,我们需要为新服务创建一个新条目,以便负载均衡器在两者之间拆分流量。在确认一切都按预期工作后,我们需要从旧服务中删除该条目。现在,所有流量都将路由到新服务。
Chapter 2
- What are the characteristics of RESTful applications?
虽然 RESTful 应用程序被理解为将 URI 转换为对象表示并通过 HTTP 方法操作它们(通常使用 JSON 格式化请求)的 Web 界面,但 REST 架构的教科书特征如下:
- Uniform interface
- Client-server
- Stateless
- Cacheable
- Layered system
- Code on demand (optional)
您可以在 https://restfulapi.net/ 找到有关 REST 架构的更多信息。
- What are the advantages of using Flask-RESTPlus?
使用 Flask-RESTPlus 的一些优点如下:
- Automatic Swagger generation.
- A framework that can define and parse inputs and marshal outputs.
- It allows us to structure the code in namespaces.
- What are some alternatives to Flask-RESTPlus?
其他替代方案包括 Flask-RESTful(这类似于 Flask-RESTPlus,但它不支持 Swagger)和 Django REST 框架,它具有丰富的生态系统,其中充满了第三方扩展。
- Name the Python package used through the tests to fix the time.
冻结。
- Describe the authentication flow.
身份验证系统(用户后端)生成编码令牌。此令牌使用只有用户后端拥有的私钥编码。此令牌以 JWT 编码并包含用户 ID 以及其他参数,例如,告诉我们令牌的有效期。此令牌包含在 Authentication 标头中。
令牌是从标头中获取的,并使用相应的公钥进行解码,公钥存储在 Thoughts Backend 中。这允许我们独立地获取用户 ID,并确定它已被用户后端验证。
- Why did we choose SQLAlchemy as a database interface?
SQLAlchemy 在 Flask 中得到很好的支持,允许我们定义已经存在的数据库。它是高度可配置的,允许我们在低级别工作,即接近底层 SQL 和更高级别,这消除了对任何样板代码的需要。在我们的用例中,我们从遗留系统继承了一个数据库,因此需要与现有模式无缝协作。
Chapter 3
- What does the FROM keyword do in a Dockerfile?
它从现有图像开始我们的图像,向其中添加更多层。
- How would you start a container with its predefined command?
您将运行以下命令:
- Why won't creating a step to remove files from a Dockerfile create a smaller image?
由于 Docker 使用的文件系统的分层结构,Docker 文件中的每个步骤都会创建一个新层。文件系统是所有操作协同工作的结果。最终图像包括所有现有层;添加图层永远不会减小图像的大小。删除的新步骤不会出现在最终图像中,但它始终作为前一层的一部分可用。
- How does a multistage Dockerfile work?
一个多阶段 Dockerfile 包含多个阶段,每个阶段都以 FROM 命令开始,该命令指定充当起点的映像。数据可以在一个阶段生成,然后复制到另一个阶段。
如果我们希望减小最终图像的大小,多阶段构建很有用;只有结果数据将被复制到最后阶段。
- What is the difference between the run and exec commands?
run 命令从映像启动一个新容器,而 exec 命令连接到一个已经存在的正在运行的容器。请注意,如果容器在您执行时停止,会话将关闭。
- When should we use the -it flag?
当您需要保持终端打开时,例如,以交互方式运行 bash 命令。记住助记符交互式终端。
- What are the alternatives to using uWSGI to serve web Python applications?
任何支持 WSGI Web 协议的 Web 服务器都可以用作替代方案。最受欢迎的替代品是旨在易于使用和配置的 Gunicorn、mod_wsgi(支持 WSGI Python 模块的流行 Apache Web 服务器的扩展)和 CherryPy,它包含自己的 Web 框架。
- What is docker-compose used for?
docker-compose 允许轻松编排,也就是说,我们可以协调多个互连的 Docker 容器,使它们协同工作。它还可以帮助我们配置 Docker 命令,因为我们可以使用 docker-compose.yaml 文件来存储所有受影响容器的配置参数。
- Can you describe what a Docker tag is?
Docker 标记是一种标记图像的方法,同时保留它们的根名称。它通常标记同一应用程序或软件的不同版本。默认情况下,latest 标签将应用于镜像构建。
- Why do we need to push images to a remote registry?
我们将图像推送到远程注册表,以便我们可以与其他系统和其他开发人员共享图像。 Docker 在本地构建镜像,除非它们需要被推送到另一个存储库以便其他 Docker 服务可以使用它们。
Chapter 4
- Does increasing the number of deployments reduce the quality of deployments?
不;事实表明,部署数量的增加与其质量的提高有很强的相关性。能够快速部署的系统必须依赖强大的自动化测试,从而提高系统的稳定性和整体质量。
- What is a pipeline?
管道是用于执行构建的有序连续的步骤或阶段。如果其中一个步骤失败,则构建停止。步骤的顺序应该旨在最大限度地尽早发现问题。
- How do we know if our main branch can be deployed?
如果我们自动运行管道以在每次提交时生成构建,我们应该在主分支提交后立即检测到问题。构建应该向我们保证可以部署主分支的顶部提交。主分支的破损应尽快修复。
- What is the main configuration source for Travis CI?
.travis.yml 文件,可以在存储库的根目录中找到。
- By default, when does Travis CI send notification emails?
每当构建中断以及先前中断的分支成功通过时,Travis CI 都会发送通知电子邮件。当上一次提交成功但未报告时,会发生成功的构建。
- How can we avoid merging a broken branch into our main branch?
我们可以通过在 GitHub 中进行配置来避免这种情况,这样可以确保分支在我们将其合并到受保护的分支之前通过构建。为了确保特性分支没有偏离主分支,我们需要强制它与构建合并。它需要与主分支保持同步才能发生这种情况。
- Why should we avoid storing secrets in a Git repository?
由于 Git 的工作方式,任何引入的秘密都可以通过查看提交历史来检索,即使它已被删除。由于提交历史可以在任何克隆的存储库中复制,因此我们无法验证它是否正确——我们无法将提交历史重写到克隆的存储库中。除非正确加密,否则不应将机密存储在 Git 存储库中。任何错误存储的秘密都应该被删除。
Chapter 5
- What is a container orchestrator?
容器编排器是一个系统,我们可以在其中部署多个协同工作的容器,并以有序的方式管理配置和部署。
- In Kubernetes, what is a node?
节点是属于集群一部分的物理服务器或虚拟机。可以从集群中添加或删除节点,Kubernetes 将相应地迁移或重新启动正在运行的容器。
- What is the difference between a pod and a container?
一个 pod 可以包含多个共享相同 IP 的容器。要在 Kubernetes 中部署容器,我们需要将其与 pod 相关联。
- What is the difference between a job and a pod?
一个 pod 预计会持续运行。一个作业或 cron 作业执行单个操作,然后所有 pod 容器完成它们的执行。
- When should we add an Ingress?
当我们需要能够从集群外部访问服务时,我们应该添加一个 Ingress。
- What is a namespace?
命名空间是一个虚拟集群。集群内的所有定义都需要具有唯一的名称。
- How can we define a Kubernetes element in a file?
我们需要以 YAML 格式指定它,并提供有关其 API 版本、元素类型、具有名称和命名空间的元数据部分以及 spec 部分中的元素定义的信息。
- What is the difference between the kubectl get and describe commands?
kubectl get 获取多个元素,例如服务或 Pod,并显示它们的基本信息。另一方面,describe 访问单个元素并提供有关它的更多信息。
- What does the CrashLoopBackOff error indicate?
此错误表示容器已完成执行定义的启动命令。此错误仅与 pod 相关,因为它们永远不应该停止执行。
Chapter 6
- What are the three microservices that we are deploying?
以下是我们正在部署的三个微服务:
- The Users Backend, which controls authentication and how users are handled.
- The Thoughts Backend, which stores thoughts and allows us to create and search for them.
- The Frontend, which provides us with a user interface so that we can interact with the system. It calls the other two microservices through RESTful calls.
- Which of the three microservices requires the other two microservices to be available?
前端调用其他两个微服务,因此它们需要可供前端工作。
- Why do we need to use external IPs to connect to microservices while they're running in docker-compose?
docker-compose 为每个微服务创建一个内部网络,因此它们需要使用外部 IP 进行通信,以便正确路由。当我们在主机中公开端口时,可以使用外部主机 IP。
- What are the main Kubernetes objects that are required for each application?
对于每个微服务,我们提供一个部署(它会自动生成一个 pod)、一个服务和一个 Ingress。
- Are any of the objects not required?
用户后端和想法后端的入口不是严格要求的,因为它们可以通过节点端口访问,但它确实使访问它们更容易。
- Can we detect issues if we scale to more than one pod or any other microservice?
用户后端和想法后端创建一个带有两个容器的 pod,其中包括数据库。如果我们创建多个 pod,我们将创建多个数据库,并且在它们之间交替可能会导致问题。
例如,如果我们在其中一个 pod 中创建了一个新想法,如果请求是在另一个 pod 中发出的,我们将无法搜索它。
另一方面,前端可以毫无问题地扩展。
- Why are we using the /etc/hosts file?
我们正在使用这个文件,以便我们可以定义一个路由到我们本地 Kubernetes 集群的 host。这避免了我们必须定义 FQDN 和配置 DNS 服务器。
Chapter 7
- Why shouldn't we manage our own Kubernetes cluster?
由于 Kubernetes 是一个抽象层,让云提供商负责维护和管理以及安全最佳实践会更方便。将集群委托给现有的商业云提供商也很便宜。
- Can you name some commercial cloud providers that have a managed Kubernetes solution?
Amazon Web Services、Google Cloud Services、Microsoft Azure、Digital Ocean 和 IBM Cloud 都是拥有托管 Kubernetes 解决方案的商业云提供商。
- What action do you need to perform to be able to push to an AWS Docker registry?
您需要登录到您的 Docker 守护程序。您可以使用以下代码获取登录命令:
- What tool do we use to set up an EKS cluster?
eksctl 允许我们从命令行创建整个集群,以及根据需要向上或向下扩展。
- What are the main changes we made in this chapter so that we could use the YAML files from the previous chapters?
我们必须更改映像定义才能使用 AWS 注册表。我们包括了活跃度和就绪性探测,以及部署策略。
- Are there any Kubernetes elements that are not required in this cluster?
Ingress 元素不是严格要求的,因为无法从外部访问 Thoughts Backend 和 Users Backend。前端服务能够创建面向外部的 ELB。
- Why do we need to control the DNS associated with an SSL certificate?
我们需要证明我们拥有 DNS,以便 SSL 证书可以验证只有 DNS 地址的合法所有者才能访问该 DNS 的证书。这是 HTTPS 的根元素,表明您正在与特定 DNS 的所有者私下通信。
- What is the difference between the liveness and the readiness probes?
如果就绪探测失败,则 pod 将不会接受请求,直到再次通过。如果 liveness 探测失败,容器将重新启动。
- Why are rolling updates important in production environments?
它们很重要,因为它们可以避免服务中断。他们一个一个地增加工人,同时去除旧的工人,确保随时可用的工人数量保持不变。
- What is the difference between autoscaling pods and nodes?
由于节点反映在物理实例中,因此缩放它们会影响系统中的资源。同时,扩展 pod 会使用它们可用的资源,但不会修改它们。
换句话说,增加我们拥有的节点数量会增加更多需要在系统上运行的硬件。这有一个相关的成本,因为我们需要从我们的云提供商那里租用更多的硬件。增加我们拥有的 pod 的数量并没有硬件成本,这就是为什么应该有一些开销来允许增加。
这两种策略应该相互协调,以便我们能够对负载增加做出快速反应,同时减少正在使用的硬件数量,从而降低成本。
- In this chapter, we deployed our own database containers. In production, this isn't required. However, if you're connected to an already existing database, how would you do this?
第一步是更改 thoughts_backend/deployment.yaml 和 users_backend/deployment.yaml 文件中的环境变量。要连接的主要是 POSTGRES_HOST,但用户和密码可能也必须更改。
这将一次性部署,以确保我们可以连接到外部数据库。
然后,我们可以删除部署中描述的数据库容器,即 thoughts-backend-db 和 users-backend-db。这些容器的镜像仅用于测试和开发。
Chapter 8
- What is the difference between using a script to push new code to servers and using a configuration management tool such as Puppet?
当使用脚本将新代码推送到服务器时,每个服务器都需要单独推送代码。 Puppet 和其他配置管理工具有一个中央服务器,用于接收新数据并适当地分发它。他们还监视服务器按预期运行并可以执行修复任务的事实。
配置管理工具用于大型集群,因为它们减少了需要在自定义脚本中处理的工作量。
- What is the core idea behind DevOps?
DevOps 背后的核心理念是赋予团队权力,使他们能够控制执行自己的部署和基础设施。这需要采用自动化程序形式的安全网络,以确保这些操作简单、安全和快速执行。
- What are the advantages of using GitOps?
使用 GitOps 的主要优点如下:
- Git is a common tool that most teams already know how to use.
- It keeps a copy of the infrastructure definition, which means we can use it as a backup and recover from catastrophic failures or create a new cluster based on a previous definition with ease.
- The infrastructure changes are versioned, which means we can make small discrete changes one by one and revert any of them if there's a problem.
- Can only GitOps be used in Kubernetes clusters?
尽管 GitOps 确实与 Kubernetes 有协同作用,但由于 Kubernetes 可以由 YAML 文件控制,所以没有什么能阻止我们使用 Git 存储库来控制集群。
- Where does the Flux deployment live?
它存在于自己的 Kubernetes 集群中,因此可以从 Git 中提取数据。
- What do you need to configure in GitHub so that Flux can access it?
您需要将 SSH 密钥添加到 GitHub 存储库的部署密钥。您可以通过调用 fluxctl identity 获取 SSH 密钥。
- When you're working in production environments, what features that are provided by GitHub ensure that we have control over deployments?
在合并到主分支之前,我们需要经过审核和批准,这会触发部署。包含代码所有者以强制特定用户批准可以帮助我们控制敏感区域。
Chapter 9
- When new business features are received, what analysis needs to be done in a system working under a microservice architecture?
我们需要确定新的业务特性会影响哪些微服务或哪些微服务。影响多个微服务的功能使其实现更加困难。
- If a feature requires two or more microservices to be changed, how do we decide which should be changed first?
这应该以背对前的方式完成,以保持向后兼容性。应该在考虑向后兼容性的同时添加新功能,因此可能性是有限的。后端准备好后,可以相应地更改前端,以便我们可以利用新功能。
- How does Kubernetes help us set up multiple environments?
在 Kubernetes 中创建新的命名空间非常容易。由于系统的定义被封装在 YAML 文件中,因此可以复制和修改它们以创建复制环境。这可以用作基线,然后进行演进。
- How do code reviews work?
将一个分支中的代码与主分支进行比较。另一位开发人员可以查看它们之间的差异并发表评论,要求澄清或更改。然后可以讨论这些,然后如果审阅者认为它足够好,则可以批准代码。在获得一个或多个批准之前,可以阻止合并。
- What is the main bottleneck for code reviews?
主要瓶颈是没有审阅者来提供反馈和批准代码。这就是为什么有足够多的人可以担任审稿人的角色很重要。
- Under GitOps principles, are the reviews for deployment different from code reviews?
不;在 GitOps 下,部署被视为代码,因此可以像任何其他代码审查一样对它们进行审查。
- Why is it important to have a clear path to deployment once a feature is ready to be merged into the main branch?
有一条清晰的部署路径很重要,这样每个人都在同一个页面上。它还提供了对部署速度的明确预期。通过这样做,我们可以指定何时需要审查。
- Why are database migrations different from regular code deployments?
它们是不同的,因为它们不能轻易回滚。虽然可以回滚代码部署以便再次部署之前的映像,但数据库迁移会更改数据库或数据的架构,如果它们被还原,可能会导致数据丢失。通常,数据库迁移是只向前的,发生的任何问题都需要通过新的部署来纠正。
这是我们必须特别注意数据库迁移并确保它们不会向后不兼容的主要原因。
Chapter 10
- What is the observability of a system?
这是一个系统的容量。它让你知道它的内部状态是什么。
- What are the different severity levels that are available in logs by default?
按照严重程度递增的顺序,不同的严重级别分别为 DEBUG、INFO、WARNING、ERROR 和 严重。
- What are metrics used for?
指标允许您找出系统上正在发生的事件的聚合状态,并允许您了解系统的一般状态。
- Why do you need to add a request ID to the logs?
您需要在日志中添加一个请求 ID,以便您可以对与同一请求对应的所有日志进行分组。
- What kinds of metrics are available in Prometheus?
计数器,对特定事件进行计数;仪表,它跟踪可以上升或下降的值;和直方图(或摘要),它们使用与事件相关联的值来跟踪事件,例如事件发生的时间或请求的状态代码被返回的时间。
- What is the 75th percentile in a metric and how is it different from the average?
对于直方图,75th 百分位是 25% 的事件高于平均值,而 75% 低于它。通过将所有值相加并将该值除以最初相加的值的数量来找到平均值。通常,平均值将接近第 50 个百分位,但这取决于值的分布方式。
如果我们希望确定延迟,则 90th-95th 百分位很好,因为它提供了请求的上限时间,不计算异常值。平均值可能会受到异常值的影响,因此无法为绝大多数请求提供一个现实的数字。
- What are the four golden signals?
四个黄金信号是收集系统健康状况描述的四个测量值。它们是请求的延迟、流量、返回错误的百分比和资源的饱和度。
Chapter 11
- What are the differences between releasing changes in a microservice architecture system and a monolith?
发布单体架构中的更改将只涉及一个存储库,因为单体架构只是一个代码库。在微服务架构中进行的一些更改将需要我们更改两个或多个微服务,以便我们可以分配它们。这需要更多的计划和关注,因为我们需要确保这得到适当的协调。在适当架构的微服务系统中,此类多存储库更改应该相对较少,因为它们会产生开销。
- Why should release changes be small in a microservice architecture?
微服务的优势在于我们可以并行发布微服务,这比单体发布要快。但是,鉴于微服务中的发布可能会影响其他微服务,它们应该以迭代的方式工作,减少更改的大小并提高部署速度。
如果需要,小的更改风险较小并且更容易回滚。
- How does semantic versioning work?
在语义版本控制中,版本有三个数字:Major 版本号、Minor 版本号和Patch 版本号。这些都用点分隔:
- An increase in a Patch version only fixes bugs and security problems.
- An increase in a Minor version adds more features, but without backward-incompatible changes.
- An increase in a Major version produces backward-incompatible changes.
- What are the problems with semantic versioning for internal interfaces in a microservice architecture system?
由于微服务中的部署非常普遍,并且向后兼容性非常重要,因此 主要 版本的意义被淡化了。此外,微服务的大多数消费者都是内部的,因此版本之间的隐式通信不太重要。
当发布变得普遍时,语义版本控制就失去了意义,因为目标是不断完善和改进产品,而不是标记大版本。
- What are the advantages of adding a version endpoint?
任何使用微服务的消费者都可以像发出任何其他请求一样请求其版本:通过使用 RESTful 调用。
- How can we fix the dependency problem in this chapter's code?
本章代码存在TO BE FILLED 之间的依赖问题。
- What configuration variables should we store in a shared ConfigMap?
我们应该存储多个微服务访问的配置变量。抢先式,我们应该存储大部分配置变量,以便它们可以被重用。
- Describe the advantages and disadvantages of putting all the configuration variables into a single shared ConfigMap.
单个共享的 ConfigMap 使配置变量非常明确。它鼓励每个人重用它们并告诉其他人该配置在其他微服务中的用途。
改变一个微服务的依赖会触发重启,所以改变一个充当一切依赖的ConfigMap会导致集群中的所有微服务重启,这是很耗时的。
此外,单个 ConfigMap 文件最终可能会非常大,将其拆分为几个较小的文件可以帮助我们更有效地组织数据。
- What's the difference between a Kubernetes ConfigMap and a Kubernetes Secret?
Kubernetes Secret 可以更好地防止意外访问。直接访问工具不会以纯文本形式显示秘密。还需要以更明确的方式配置对 Secrets 的访问。另一方面,ConfigMap 可以批量配置,因此 pod 将能够访问已存储在 ConfigMap 中的所有值。
- How can we change a Kubernetes Secret?
我们可以使用 kubectl edit 更改 Secret,但它需要以 Base64 格式编码。
例如,要将 postgres-password 密码替换为 someotherpassword 值,我们可以使用以下代码:
重新启动后,我们的 pod 将能够使用新的 Secret。
- Imagine that, based on our configuration, we decided to change public_key.pub from a Secret to a ConfigMap. What changes do we have to make?
我们需要更改 ConfigMap,使其包含 configuration.yaml 中的文件:
请注意用于分隔文件的缩进。 | 字符标记多行字符串。
然后,在 deployment.yaml 文件中,我们需要将挂载的来源从 Secret 更改为 ConfigMap:
请记住首先将这些更改应用到 ConfigMap,以便在应用部署文件时它们可用。
在所有 pod 重新启动后,可以删除 Secret。
Chapter 12
- Why is a leading architect convenient for a microservice architecture system?
在微服务架构中构建系统允许我们创建可以并行处理的独立服务。这些服务仍然需要相互通信和合作。
独立团队通常无法把握全局,倾向于专注于自己的项目。为了帮助整个系统的协调和发展,独立团队需要一位对系统有高层次概览的领先架构师。
- What is Conway's Law?
康威定律是一句格言,它说软件结构复制了编写它的组织的通信结构。
这意味着,要改变软件的结构方式,组织需要改变,这是一项困难得多的任务。
为了成功设计和发展大型系统,需要考虑并相应地规划组织。
- How is technical debt introduced?
有很多方法可以产生技术债务。
通常,技术债务属于以下四类之一或混合:
- By developing too quickly without taking the time to analyze other options
- By making a compromise to shorten development time while knowing that the comprise will need to be fixed later
- By not having a good enough understanding of the current system or tools, or having a lack of training or expertise
- By making incorrect assumptions regarding an external problem, thereby designing for something that doesn't necessarily need to be fixed
- Why is it important to create a culture so that we can work continuously to reduce technical debt?
创建一种文化非常重要,这样我们就可以避免软件腐烂,这是由于现有软件的复杂性增加而导致性能和可靠性不断下降。除非解决技术债务成为一个持续的过程,否则发布新版本的日常压力意味着我们将无法进行维护。
- Why is it important to document problems in releases and share them with the rest of the team?
这很重要,因为每个团队都可以从其他人的经验和解决方案中学习并改进他们的流程。这也可以创造一种开放的文化,人们不害怕为自己的错误承担责任。
- What is the main objective of a post-mortem meeting?
事后分析会议的主要目标是创建解决事件原因的后续任务。为此,我们需要尽可能确信根本原因已被成功检测到(这也是次要目标)。