DevOps Tools for Java Developers (Stephen Chin, Melissa McKay etc.) (z-library.sk, 1lib.sk, z-lib.sk)

Stephen Chin, Melissa McKay, Ixchel Ruiz, and Baruch Sadogursky DevOps Tools for Java Developers Best Practices from Source Code to Production Containers Boston Farnham Sebastopol TokyoBeijing

978-1-492-08402-0 [LSI] DevOps Tools for Java Developers by Stephen Chin, Melissa McKay, Ixchel Ruiz, and Baruch Sadogursky Copyright © 2022 Stephen Chin, Melissa McKay, Ixchel Ruiz, and Baruch Sadogursky. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Suzanne McQuade Development Editor: Corbin Collins Production Editor: Elizabeth Faerm Copyeditor: Sharon Wilkey Proofreader: Piper Editorial Consulting, LLC Indexer: Sue Klefstad Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea April 2022: First Edition Revision History for the First Edition 2022-04-15: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781492084020 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. DevOps Tools for Java Developers, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the authors and do not represent the publisher’s views. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

Table of Contents Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii 1. DevOps for (or Possibly Against) Developers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 DevOps Is a Concept Invented by the Ops Side 2 Exhibit 1: The Phoenix Project 2 Exhibit 2: The DevOps Handbook 2 Google It 4 What Does It Do? 4 State of the Industry 5 What Constitutes Work? 6 If We’re Not About Deployment and Operations, Then Just What Is Our Job? 6 Just What Constitutes “Done”? 7 Rivalry? 7 More Than Ever Before 8 Volume and Velocity 9 Done and Done 9 Float Like a Butterfly… 10 Integrity, Authentication, and Availability 11 Fierce Urgency 12 The Software Industry Has Fully Embraced DevOps 12 Making It Manifest 13 We All Got the Message 14 iii

2. The System of Truth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Three Generations of Source Code Management 16 Choosing Your Source Control 18 Making Your First Pull Request 22 Git Tools 26 Git Command-Line Basics 27 Git Command-Line Tutorial 31 Git Clients 32 Git IDE Integration 35 Git Collaboration Patterns 38 git-flow 38 GitHub Flow 41 GitLab Flow 42 OneFlow 43 Trunk-Based Development 44 Summary 44 3. An Introduction to Containers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Understanding the Problem 48 The History of Containers 49 Why Containers? 52 Intro to Container Anatomy 55 Docker Architecture and the Container Runtime 58 Docker on Your Machine 62 Basic Tagging and Image Version Management 68 Image and Container Layers 69 Best Image Build Practices and Container Gotchas 71 Respect the Docker Context and .dockerignore File 71 Use Trusted Base Images 72 Specify Package Versions and Keep Up with Updates 73 Keep Your Images Small 73 Beware of External Resources 74 Protect Your Secrets 75 Know Your Outputs 75 Summary 75 4. Dissecting the Monolith. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Cloud Computing 79 Microservices 80 Antipatterns 80 iv | Table of Contents

DevOps and Microservices 82 Microservice Frameworks 83 Spring Boot 84 Micronaut 90 Quarkus 94 Helidon 97 Serverless 100 Setting Up 102 Summary 109 5. Continuous Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Adopt Continuous Integration 112 Declaratively Script Your Build 114 Build with Apache Ant 117 Build with Apache Maven 120 Build with Gradle 123 Continuously Build 126 Automate Tests 127 Monitor and Maintain Tests 128 Summary 129 6. Package Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Why Build-It-and-Ship-It Is Not Enough 132 It’s All About Metadata 133 Key Attributes of Insightful Metadata 133 Metadata Considerations 134 Determining the Metadata 135 Capturing Metadata 135 Writing the Metadata 138 Dependency Management Basics for Maven and Gradle 142 Dependency Management with Apache Maven 142 Dependency Management with Gradle 155 Dependency Management Basics for Containers 160 Artifact Publication 162 Publishing to Maven Local 162 Publishing to Maven Central 163 Publishing to Sonatype Nexus Repository 166 Publishing to JFrog Artifactory 167 Summary 167 Table of Contents | v

7. Securing Your Binaries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Supply Chain Security Compromised 169 Security from the Vendor Perspective 171 Security from the Customer Perspective 171 The Full Impact Graph 171 Securing Your DevOps Infrastructure 172 The Rise of DevSecOps 172 The Role of SREs in Security 173 Static and Dynamic Security Analysis 174 Static Application Security Testing 174 Dynamic Application Security Testing 175 Comparing SAST and DAST 177 Interactive Application Security Testing 178 Runtime Application Self-Protection 179 SAST, DAST, IAST, and RASP Summary 180 The Common Vulnerability Scoring System 181 CVSS Basic Metrics 181 CVSS Temporal Metrics 182 CVSS Environmental Metrics 183 CVSS in Practice 183 Scoping Security Analysis 184 Time to Market 184 Make or Buy 184 One-Time and Recurring Efforts 186 How Much Is Enough? 186 Compliance Versus Vulnerabilities 186 Vulnerabilities Can Be Combined into Different Attack Vectors 187 Vulnerabilities: Timeline from Inception Through Production Fix 188 Test Coverage Is Your Safety Belt 190 Quality Gate Methodology 191 Quality Gate Strategies 192 Fit with Project Management Procedures 193 Implementing Security with the Quality Gate Method 193 Risk Management in Quality Gates 194 Practical Applications of Quality Management 195 Shift Security Left 195 Not All Clean Code Is Secure Code 197 Effects on Scheduling 198 The Right Contact Person 198 Dealing with Technical Debt 198 vi | Table of Contents

Advanced Training on Secure Coding 199 Milestones for Quality 199 The Attacker’s Point of View 199 Methods of Evaluation 200 Be Aware of Responsibility 201 Summary 201 8. Deploying for Developers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Building and Pushing Container Images 204 Managing Container Images by Using Jib 205 Building Container Images with Eclipse JKube 207 Deploying to Kubernetes 210 Local Setup for Deployment 212 Generate Kubernetes Manifests by Using Dekorate 213 Generate and Deploy Kubernetes Manifests with Eclipse JKube 216 Choose and Implement a Deployment Strategy 219 Managing Workloads in Kubernetes 225 Setting Up Health Checks 226 Adjusting Resource Quotas 231 Working with Persistent Data Collections 233 Best Practices for Monitoring, Logging, and Tracing 234 Monitoring 237 Logging 240 Tracing 241 High Availability and Geographic Distribution 245 Hybrid and MultiCloud Architectures 247 Summary 249 9. Mobile Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Fast-Paced DevOps Workflows for Mobile 253 Android Device Fragmentation 255 Android OS Fragmentation 256 Building for Disparate Screens 258 Hardware and 3D Support 261 Continuous Testing on Parallel Devices 265 Building a Device Farm 266 Mobile Pipelines in the Cloud 270 Planning a Device-Testing Strategy 275 Summary 276 Table of Contents | vii

10. Continuous Deployment Patterns and Antipatterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Why Everyone Needs Continuous Updates 279 User Expectations on Continuous Updates 280 Security Vulnerabilities Are the New Oil Spills 281 Getting Users to Update 287 Case Study: Java Six-Month Release Cadence 288 Case Study: iOS App Store 291 Continuous Uptime 294 Case Study: Cloudflare 294 The Hidden Cost of Manual Updates 300 Case Study: Knight Capital 300 Continuous Update Best Practices 302 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 viii | Table of Contents

Foreword When we began writing Continuous Delivery in Java in 2017, both Abraham Marín- Pérez and I knew that DevOps would be a big part of our book. Since then, the importance for Java developers to know and understand operational concepts has only increased. With the rise of technologies such as cloud and containers, and supporting concepts of observability and site reliability engineering (SRE), the vast majority of us are no longer “just” developers; we’re now often responsible for the coding, shipping, and running of our applications. Therefore, it makes sense for developers to embrace ops and vice versa. The term DevOps is not new; it has been in use for 15 or so years. The concept was originally based around agile infrastructure, which emerged from the 2008 Agile Conference in Toronto where Patrick Debois, Andrew Clay Shafer, and many others met to discuss the challenges within traditional sysadmin approaches. The desire to “program” infrastructure meant that there has always been the influence of software engineering in this space. At the 2009 O’Reilly Velocity conference, John Allspaw and Paul Hammond presented their now-famous talk entitled, “10 Deploys a Day: Dev and Ops Cooperation at Flickr,” which cemented the importance of devs collaborating with ops. In my day job at Ambassador Labs, I see an increasing number of organizations building platforms to enable developers to rapidly get their ideas and code into production and in front of customers. The two most important goals are obtaining fast feedback and doing so safely, without crashes or security incidents. In my mind, these platforms are the products resulting from the effective collaboration of dev and ops. We know from the research by Dr. Nicole Forsgren, Jez Humble, and Gene Kim, which was captured in the must-read book, Accelerate (IT Revolution Press, 2018), that high-performing organizations have a higher deployment frequency, lower lead time for changes, smaller change failure rate, and lower mean time to restore pro‐ duction issues. All of these factors are influenced by your platform, processes, and ix

people. Developers have to think like operators, and operators have to embrace development principles. It’s all about shared ownership, and this starts with shared understanding. This book will help you develop this shared understanding. As a developer, you’ve no doubt been using version control to store and manage your application code for the past decade. Modern DevOps practices like GitOps take this one step further and store application and infrastructure code and configuration in version control. It is, therefore, vital to learn version control systems skills as presented in the early chapters. The rise of microservices has presented many opportunities for developers, and also many challenges. Some of these challenges can be mitigated by using appropriate technology. Containers and related scheduling frameworks, like Kubernetes, help with packaging and running microservice in a standardized and automated fashion. Of course, you will also need to understand the impact of these “cloud native” tech‐ nologies on continuous integration and continuous delivery practices. The authors of this book have done an excellent job of walking you through all the related steps, from package management to securing artifacts and deploying. I’ve been fortunate to learn firsthand from all of the authors. I’ve lost count of the number of times that I’ve been attending a DevOps conference with crowds of people wandering around only to see Baruch’s distinctive top hat moving slowly through the crowd, or to bump up against a leather jacket-wearing motorbiker, only to realize it’s Stephen. From this point on, I know I will soon be engrossed in interesting conversations about continuous delivery and the Java ecosystem. I’ve also keenly followed Melissa’s teachings on building and securing containers as part of her work at JFrog. And seeing her receive her Java Champion recognition live (and unexpectedly!) at Jfokus 2021 was a great moment. Ixchel has long been a guiding influence in the Java and JVM spaces. Since I first attended JavaOne, back in 2013—where I saw her copresent with Andres Almiray on the future of the polyglot JVM—I have learned many things from her that have made me a better developer. I’ve also had the privilege of sitting on several panels alongside Ana-Maria Mihal‐ ceanu (who wrote Chapter 8) over the years, most recently covering topics such as containers, Kubernetes, and Quarkus. I always enjoy hearing her take on the operational impact of new technologies on the Java platform, and I typically leave our conversation with a bunch of new tools to research. x | Foreword

Whether you’re a seasoned Java programmer who is new to the DevOps space, or a novice programmer keen to build on your existing knowledge about containers and cloud, I know you’ll learn many things from this book. So, what are you waiting for? Sit down, grab your favorite brew (maybe a cup of Java?), and prepare to level up in all things related to DevOps tooling for Java developers. — Daniel Bryant Head of DevRel at Ambassador Labs Java Champion March 2022 Foreword | xi

Preface This book was written in a time of immense change as the world was thrown upside down by the largest pandemic in a century. However, this work was never needed more as the software industry embraced DevOps and cloud native development to handle the accelerated pace of software delivery. We organized this book so that the topics are in an incremental order of lifecycle, complexity, and maturity. However, DevOps is a broad enough journey that you may find some chapters more relevant than others for your project needs. As a result, we designed the chapters so that you can start in any order and focus on a particular subject for which you need expertise, examples, and best practices to advance your knowledge. We hope you enjoy reading this title as much as we have enjoyed putting the content together. Our one ask is that you share your newfound knowledge with a friend or colleague so that we can all become better developers. Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords. Constant width bold Shows commands or other text that should be typed literally by the user. xiii

Constant width italic Shows text that should be replaced with user-supplied values or by values deter‐ mined by context. This element signifies a tip or suggestion. This element signifies a general note. This element indicates a warning or caution. Using Code Examples Supplemental material (code examples, exercises, etc.) is available for download at https://github.com/devops-tools-for-java-developers. If you have a technical question or a problem using the code examples, please send email to bookquestions@oreilly.com. This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “DevOps Tools for Java Developers by Stephen Chin, Melissa McKay, Ixchel Ruiz, and Baruch Sadogursky (O’Reilly). Copyright 2022 Stephen Chin, Melissa McKay, Ixchel Ruiz, and Baruch Sadogursky, 978-1-492-08402-0.” xiv | Preface

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. O’Reilly Online Learning For more than 40 years, O’Reilly Media has provided technol‐ ogy and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, conferences, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in- depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, please visit http://oreilly.com. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/EHNuR. Email bookquestions@oreilly.com to comment or ask technical questions about this book. For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://youtube.com/oreillymedia Preface | xv

Acknowledgments This book wouldn’t have been possible without the support of our family and friends who stood with us and supported our dedication and focus on this subject. While we passionately worked to put this title together, they helped to take care of our loved ones and personal health so we could deliver the broad range of content required to cover the entire DevOps and Java ecosystem. Also, a special thanks to Shlomi Ben Haim, CEO of JFrog. When other companies were pulling back and tightening budgets, Shlomi extended personal support for this title and gave us the freedom and flexibility to focus on the intense task of covering this extremely broad subject. Special thanks to Ana-Maria Mihalceanu, for Chapter 8, and to Sven Ruppert, for his contribution to Chapter 7. We would like to thank our technical reviewers, Daniel Pittman, Cameron Pietrafeso, Sebastian Daschner, and Kirk Pepperdine, for improving the accuracy of this book. And finally a huge thanks to you, the reader, who has taken the initiative to improve your knowledge of the entire DevOps pipeline and be a change agent for improve‐ ments in automation, process, and culture. xvi | Preface

CHAPTER 1 DevOps for (or Possibly Against) Developers Baruch Sadogursky While you here do snoring lie, Open-eyed conspiracy His time doth take. If of life you keep a care, Shake off slumber, and beware: Awake, awake! —William Shakespeare, The Tempest Some might ask if the DevOps movement is simply an ops-inspired plot against developers. Most (if not all) who would do so wouldn’t expect a serious response, not least because they intend the question as tongue-in-cheek teasing. It’s also because— and regardless of whether your origins are on the development or the operations side of the equation—when anyone strikes up a conversation about DevOps, it will take approximately 60 seconds before someone inquires, “But what is DevOps really?” And you’d think, 11 years after the coining of the term (a decade within which industry professionals have spoken, debated, and shouted about it), that we’d all have arrived at a standard, no-nonsense, commonly understood definition. But this simply isn’t the case. In fact, despite an exponentially increasing corporate demand for DevOps personnel, it’s highly doubtful that any five DevOps-titled employees, chosen at random, could tell you precisely what DevOps is. So, don’t be embarrassed if you still find yourself scratching your head when the sub‐ ject comes up. Conceptually, DevOps may not be easy to grok, but it’s not impossible either. But regardless of how we discuss the term or what definition(s) we might agree upon, there’s one thing, above all else, that’s critical to bear in mind: DevOps is an entirely invented concept, and the inventors came from the ops side of the equation. 1

DevOps Is a Concept Invented by the Ops Side My premise about DevOps may be provocative, but it’s provable too. Let’s start with the facts. Exhibit 1: The Phoenix Project The Phoenix Project by Gene Kim et al. (IT Revolution) became a classic since published almost a decade ago. It’s not a how-to manual (not in the traditional sense, anyway). It’s a novel that tells the story of a highly problematic company and its IT manager who is suddenly assigned the task of implementing a make-or-break corporate initiative that’s already way over budget and months behind schedule. If you dwell in the realms of software, the rest of the book’s central characters will be familiar to you. For the moment, though, let’s have a look at their professional titles: • Director, IT service support • Director, distributed technology • Manager, retail sales • Lead systems administrator • Chief information security officer • Chief financial officer • Chief executive officer Notice the connective tissue between them? They’re the protagonists of one of the most important books about DevOps ever written and not one of them is a developer. Even when developers do figure into the plotline, well…let’s just say they’re not spoken of in particularly glowing terms. When victory comes, it’s the hero of the story (together with a supportive board member) who invents DevOps, pulls the project’s fat out of the fire, turns his com‐ pany’s fortunes around, and gets rewarded with a promotion to chief information officer (CIO) of the enterprise. And everyone lives happily—if not ever after, then for at least the two or three years such successes tend to buy you in this business before it’s time to prove your worth all over again. Exhibit 2: The DevOps Handbook It’s better to read The Phoenix Project before The DevOps Handbook by Gene Kim et al. (IT Revolution) because the former places you within a highly believable, human scenario. It’s not difficult to immerse yourself in the personality types, the professional predicaments, and the interpersonal relationships of the characters. The hows and whys of DevOps unfold as inevitable and rational responses to a set of 2 | Chapter 1: DevOps for (or Possibly Against) Developers