DevOps 2.4：Jenkins与Kubernetes深度集成，实现自动化部署

Kubernetes

CI/CD

需积分: 18 179 浏览量更新于2024-07-16 1 收藏 8.89MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

《Packt.The.DevOps.2.4.Toolkit.2019.11.pdf》是一本由Viktor Farcic编著的专业技术书籍，旨在探索在Kubernetes集群上进行持续部署的实践。这本书是Viktor Farcic DevOps Toolkit系列的第五部，紧随前作《The DevOps 2.3 Toolkit: Kubernetes》而来，专注于通过Jenkins在容器化环境中实现自动化应用部署。书中内容涵盖了以下几个关键知识点： 1. **连续部署理解**：读者将学习到什么是连续部署（Continuous Deployment），以及它与连续交付（Continuous Delivery）的区别。Viktor会深入讨论哪种方法更适合不同场景，并帮助读者决定最佳实践。 2. **应用构建、测试与部署**：书中提供了详尽的指导，教读者如何使用Jenkins构建、测试应用程序，并将其无缝地部署到Kubernetes集群中，确保整个过程的自动化和高效性。 3. **容器内持续集成**：读者将了解到如何在Kubernetes集群内部执行持续集成（Continuous Integration），这对于容器环境下的软件开发至关重要。 4. **Kubernetes应用分发**：书中还会涉及如何有效地在Kubernetes环境中分发和管理应用程序，包括安装和配置Jenkins。 5. **适应性和自我修复系统**：Viktor鼓励读者学习如何创建能够自我适应和自我恢复的系统，这在现代DevOps实践中是非常重要的能力。 6. **实践案例和最佳实践**：作者分享了自己在实践中应用的最佳策略，确保读者能够理解和实施一套完整的DevOps工具链。《The DevOps 2.4 Toolkit》适合那些对DevOps、Docker、Kubernetes、CI/CD（持续集成与持续部署）和TDD（Test-Driven Development）感兴趣的开发者和运维人员。通过阅读这本书，读者可以提升自己的技能，了解如何在不断变化的技术栈中建立和维护高效的自动化流程。此外，这本书遵循版权规定，未经出版商事先书面许可，不得复制、存储或通过任何方式传播书中的内容。作者和出版社对书中信息的准确性给予了最大努力，但不承担因本书导致的直接或间接损失的责任。同时，出版社强调了商标使用的一致性，尽管尽力确保准确性，但并不能完全保证所有提及的公司和产品信息的准确性。

资源详情

资源推荐

Preface

[ 7 ]

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book

title in the subject of your message and email us at customercare@packtpub.com.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes

do happen. If you have found a mistake in this book, we would be grateful if you would

report this to us. Please visit www.packtpub.com/support/errata, selecting your book,

clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we

would be grateful if you would provide us with the location address or website name.

Please contact us at copyright@packt.com with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in

and you are interested in either writing or contributing to a book, please visit

authors.packtpub.com.

Reviews

Please leave a review. Once you have read and used this book, why not leave a review on

the site that you purchased it from? Potential readers can then see and use your unbiased

opinion to make purchase decisions, we at Packt can understand what you think about our

products, and our authors can see your feedback on their book. Thank you!

For more information about Packt, please visit packt.com.

Preface

[ 8 ]

Rumblings Of An Old Man

Continuous Deployment is about making a decision to do things right. It

is a clear goal and a proof that the changes across all levels were

successful. The primary obstacle is thinking that we can get there without

drastic changes in the application's architecture, processes, and culture.

Tools are the least of our problems.

I spend a significant chunk of my time helping companies improve their systems. The most

challenging part of my job is going back home after an engagement knowing that the next

time I visit the same company, I will discover that there was no significant improvement. I

cannot say that is not partly my fault. It certainly is. I might not be very good at what I do.

Or maybe I am not good at conveying the right message. Maybe my advice was wrong.

There can be many reasons for those failures, and I do admit that they are probably mostly

my fault. Still, I cannot shake the feeling that my failures are caused by something else. I

think that the root cause is in false expectations.

People want to improve. That is in our nature. Or, at least, most of us do. We became

engineers because we are curious. We like to play with new toys. We love to explore new

possibilities. And yet, the more we work in a company, the more we become complacent.

We learn something, and then we stop learning. We shift our focus towards climbing

company ladders. The more time passes, the more emphasis we put on defending our

positions which often mean the status quo.

We become experts in something, and that expertise brings us to glory and, hopefully, it

lands a promotion, or two. From there on, we ride on that glory. Look at me, I'm a DB2

expert. That's me, I set up VMWare virtualization. I brought the benefits of Spring to our Java

development. Once that happens, we often try to make sure that those benefits stay intact

forever. We won't switch to NoSQL because that would mean that my DB2 expertise is not

as valuable anymore. We won't move to Cloud, because I am the guru behind VMWare. We

will not adopt Go, because I know how to code in Java.

Those voices are critical because they are being voiced by senior people. Everyone needs to

listen to them, even though the real motivations behind those voices are selfish. They are

not based on actual knowledge, but often on repeated experience. Having twenty years of

experience with DB2 is not truly twenty years of improvement, but rather the same

experience repeated twenty times. Yet, twenty years has weight. People listen to you, but

not because they trust you, but because you are senior and management believes in your

capabilities to make decisions.

Preface

[ 9 ]

Combine voices from the old with management's fear of unknown and their quest for short-

term benefits. The result is often status quo. That worked for years, why would we change it to

something else. Why would I trust a junior developer telling me what to do? Even if a claim for

change is backed by the experience from giants like Google, Amazon, and Netflix (just to

name a few), you are likely to get a response along the following lines. "We are

different". "That does not apply here." "I'd like to do that but regulations, which I do not truly

understand, prevent me from changing anything."

Still, sooner or later, a directive to change comes along. Your CTO might have gone to the

Gartner meeting where he was told to switch to microservices. Too many people spoke

about Agile for upper management to ignore it. DevOps is a huge thing, so we need to

employ it as well. Kubernetes is everywhere, so we'll start working on a PoC soon.

When those things do happen, when a change is approved, you might be ecstatic. This is

your moment. This is when you'll start doing something delicious. That is often the

moment when I receive a call. "We want to do this and that. Can you help us?" I usually (not

always) say yes. That's what I do. And yet, I know that my engagement will not produce a

tangible improvement. I guess that hope dies last.

Why am I so pessimistic? Why do I think that improvements do not produce tangible

benefits? The answer lies in the scope of required changes.

Almost every tool is a result of specific processes. A process, on the other hand, is a product

of a particular culture. Adopting a process without making cultural changes is a waste of

time. Adopting tools without accepting the processes behind them is a futile effort that will

result only in wasted time and potentially substantial license costs. In infrequent occasions,

companies do choose to accept the need to change all three (culture, processes, and tools).

They make a decision, and sometimes they even start moving in the right direction. Those

are precious cases that should be cherished. But they are likely to fail as well. After a while,

usually a few months later, we realize the scope of those changes. Only the brave will

survive, and only those committed will see it through.

Those who do choose to proceed and indeed change their culture, and their processes, and

their tools, will realize that they are incompatible with the applications they've been

developing over the years. Containers work with everything, but benefits are genuinely

tremendous when developing microservices, not monoliths. Test-driven development

increases confidence, quality, and speed, but only if applications are designed to be

testable. Zero-downtime deployments are not a myth. They work, but only if our

applications are cloud-native, if they follow at least some of twelve factors (https:/󰾬/

12factor.󰾬net/󰾬), and so on.

Preface

[ 10 ]

It's not only about tools, processes, and culture, but also about getting rid of the technical

debt you've been accumulating over the years. By debt, I don't necessarily mean that you

did something wrong when you started, but rather that time converted something

awesome into a horrible monster. Do you spend fifty percent of your time refactoring? If

you're not, you're accumulating technical debt. It's unavoidable.

When faced with all those challenges, giving up is the expected outcome. It's human to

throw down the towel when there's no light at the end of the tunnel. I don't judge you. I

feel your pain. You're not moving forward because the obstacles are too big. Still, you have

to get up because there is no alternative. You will continue. You will improve. It'll hurt a

lot, but there is no alternative, except slow death while your competition is looking over

your soon-to-be corpse.

You got this far, and I can assume only two possible explanations. You are one of those

who read technical books as a way to escape from reality, or you are applying at least some

of the things we discussed thus far. I hope it's the latter. If that's the case, you do not fall

into "yet another failure of mine." I thank you for that. It makes me feel better.

If you do employ the lessons from this book, without faking, you are indeed doing

something great. There is no way of pretending continuous delivery (CD). Every commit

you make is ready for production if all the stages are green. The decision whether to deploy

it to production is based on business or marketing needs, and it is not technical in any

sense. You can even take a step forward and practice continuous deployment (CDP). It

removes the only action performed by a human and deploys every green commit to

production. Neither of the two can be faked. You cannot do CD or CDP partly. You cannot

be almost there. If you are, you're doing continuous integration, it-will-be-deployed-

eventually process, or something else.

All in all, you are, hopefully, ready to do this. You will take a step towards continuous

deployment inside a Kubernetes cluster. By the end of this book, the only thing left for you

is to spend an unknown amount of time "modernizing" architecture of your applications or

throwing them to thrash and starting over. You'll be changing your tools, processes, and

culture. This book will not help you with all of those. We're focused on tools and processes.

You'll have to figure out what to do with your culture and architecture. The same holds

true for the way you write your tests. I won't teach you testing, and I won't preach TDD. I'll

assume that you already know all that and that we can focus on continuous deployment

pipeline only.

At this moment, you might feel desperate. You might not be ready. You might think that

you don't have a buyout from your management, that the people in your company will not

accept this direction, or that you don't have enough time and funds.

剩余385页未读，继续阅读

andyyoung01

粉丝: 1
资源: 24

DevOps 2.4：Jenkins与Kubernetes深度集成，实现自动化部署

Packt.Mastering.Blockchain.2nd.Edition.2018.3.pdf

有关liunx的英文参考文献

给我列举几个关于SpringBoot的文献引用

关于Java的外文期刊参考文献

有关matplotlib库的文献

mastering elasticsearch[m]. 2nd edition. uk: packt publishing

深入理解ElasticSearch.pdf

能不能找出那种专著类型的参考文献至少三个外文的，跟Java，JavaEE有关的并且是2018年以后的

关于MongoDB的十条参考文献

kotlin .apply

有关python大数据分析技术的文献及其作者和出处

node.js毕设参考文献

关于springboot的外文参考文献

html5的网页设计与制作研究参考文献

人工智能深度学习参考文献

关于java的外语文献_java英文参考文献（涵盖3年最新120个）

springboot参考文献

custom tiles provider - humanitarian map style | packt courseware

关于vue的外文文献参考

asp.net.mvc图书管理系统参考文献资料

最新资源