Mastering spring cloud build self healing, microservices based, distributed systems using spring cloud

Mastering Spring Cloud Build self-healing, microservices-based, distributed systems using Spring Cloud Piotr Mińkowski BIRMINGHAM - MUMBAI Mastering Spring Cloud Copyright © 2018 Packt Publishing All rights reserved No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews Every effort has been made in the preparation of this book to ensure the accuracy of the information presented However, the information contained in this book is sold without warranty, either express or implied Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals However, Packt Publishing cannot guarantee the accuracy of this information Commissioning Editor: Richa Tripathi Acquisition Editor: Karan Sadawana Content Development Editor: Lawrence Veigas Technical Editor: Adhithya Haridas Copy Editor: Safis Editing Project Coordinator: Prajakta Naik Proofreader: Safis Editing Indexer: Rekha Nair Graphics: Jisha Chirayil Production Coordinator: Arvindkumar Gupta First published: April 2018 Production reference: 1250418 Published by Packt Publishing Ltd Livery Place 35 Livery Street Birmingham B3 2PB, UK ISBN 978-1-78847-543-3 www.packtpub.com mapt.io Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career For more information, please visit our website Why subscribe? Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals Improve your learning with Skill Plans built especially for you Get a free eBook or video every month Mapt is fully searchable Copy and paste, print, and bookmark content PacktPub.com Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy Get in touch with us at service@packtpub.com for more details At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks Contributors About the author Piotr Mińkowski has more than 10 years of experience working as a developer and an architect in the banking and telecommunications sectors He specializes in Java as well as in technologies, tools, and frameworks associated with it Now, he is working at Play, a mobile operator in Poland, where he is responsible for the IT systems architecture Here, he helps the organization migrate from monoliths/SOA to a microservices-based architecture, and also helps set up full Continuous Integration and Delivery environments Provisioning brokered services We have already looked at how to bind an application to a service using the cf bind-service command and the Maven plugin However, we should now look at how to enable and configure our service You can easily display a list of all the available services and then enable them using Pivotal's dashboard; this can be found under Marketplace The provisioning of a brokered service with Pivotal Web Services is very easy After installation, some services are already available to use without any additional configuration All we have to is to bind them to selected applications and properly pass their network addresses in the application's settings Every application can be easily bound to a service using the UI dashboard First, navigate to the main page of the service There, you will see a list of the currently bound applications You can bind a new application to the service by clicking BIND APP and then choosing one from the list displayed, as shown in the following screenshot: You don't have to anything more than enable the registry service in the marketplace and bind it to the application in order to enable the discovery feature on Pivotal Web Services Of course, you can override some configuration settings on the client-side if needed A full list of registered applications can be displayed in the Eureka dashboard under Manage in the main configuration panel of the service There are two running instances of account-service because we scaled it up in the previous section; the other microservices however have only one running instance, shown as follows: In contrast to a discovery service, a configuration server needs to include additional settings As before, you should navigate to its main panel and then select Manage Here, you will be redirected to the configuration form The configuration parameters have to be provided there as a JSON object The count parameter specifies the number of nodes needed for provision, upgrade options if an instance can be upgraded, and force forces that upgrade even if the instance is already the latest available version Other configuration parameters are dependent on a type of backend used to store property sources As you may remember from Chapter 5, Distributed Configuration with Spring Cloud Config, the most popular solution for Spring Cloud Config Server is based on the Git repository We have created an example repository on GitHub, where all the required sources have been committed The following are the parameters in a JSON format that should be provided for a Config Server on Pivotal Web Services: { "count": 1, "git": { "password": "****", "uri": "https://github.com/piomin/sample-spring-cloud-pcf-config.git", "username": "piomin" } } The last brokered service used by the example application provided hosted an instance of MongoDB After navigating to Manage on the main panel of that service, you should be redirected to https://mlab.c om/home , where you will be able to use the database's node The Heroku platform Heroku is one of the oldest cloud platforms created using the PaaS (Platform as a Service) model In comparison to Pivotal Cloud Foundry, Heroku doesn't have built-in support for Spring Cloud applications It complicates our model a little because we can't use a platform's services to enable typical microservices components, including service discovery, a configuration server, or a circuit breaker In spite of this, Heroku contains some really interesting features that are not provided by Pivotal Web Services Deployment methods We can manage our application using the CLI, web console or a dedicated Maven plugin Deploying Heroku is pretty similar to deploying the Pivotal platform, however, the methods are slightly different The main approach assumes that you deploy the application by building it from the source code stored in your local Git repository or on GitHub The build is executed by the Heroku platform automatically after you have pushed some changes in a branch to a repository, or on demand from the newest version of the code in the selected branch Another interesting way to deploy an application is by pushing your Docker image to Heroku's container registry Using the CLI You can begin by installing Heroku Command Line Interface (CLI) available at https://cli-assets.he roku.com/heroku-cli/channels/stable/heroku-cli-x64.exe (for Windows) In order to deploy and run your application on Heroku using CLI you have to perform the following steps: After installation, you can use the command Heroku from your shell First, log in to Heroku using your credentials, as follows: $ heroku login Enter your Heroku credentials: Email: piotr.minkowski@play.pl Password: ******** Logged in as piotr.minkowski@play.pl Next, navigate to the application's root directory and create an application on Heroku After running the following command, not only will the application be created, but a Git remote called heroku will as well This is associated with your local Git repository, shown as follows: $ heroku create Creating app done, aqueous-retreat-66586 https://aqueous-retreat-66586.herokuapp.com/ | https://git.heroku.com/aqueous-retreat-66586.git Git remote heroku added Now you can deploy your application by pushing the code to Heroku's Git remote Heroku will then all the work for you, as follows: $ git push heroku master If the application is started successfully, you will be able to manage it using some basic commands In accordance with the order presented as follows, you can display logs, change the number of running dynos (in other words, scale the application), assign new add-ons, and list all of the enabled add-ons: $ $ $ $ heroku heroku heroku heroku logs tail ps:scale web=2 addons:create mongolab addons Connecting to the GitHub repository Personally, I prefer to deploy my applications to Heroku by connecting to the projects using the GitHub repository There are two possible approaches related to this deployment method: manual and automatic You can choose either by navigating to the Deploy tab on the application's details panel and then connect it to the specified GitHub repository, as you can see in the following screenshot If you click the Deploy Branch button, the building of and the deployment to Heroku would immediately start on the given Git branch Alternatively, you can also enable automatic deploys on the chosen branch by clicking Enable Automatic Deploys Additionally, you can configure Heroku to wait for a Continuous Integration build result if it is enabled for your GitHub repository; this is a really helpful feature because it allows you to run automated tests on your project and ensure they have passed before it is pushed: Docker Container Registry Following the newest trends, Heroku allows you to deploy a containerized application using Docker In order to be able to that, you should have Docker and the Heroku CLI installed on your local machine: First, log in to Heroku Cloud by running the command heroku Container Registry: The next step is to log in to the login $ heroku container:login Next, make sure that your current directory contains Dockerfile If present, you can proceed to building and pushing the image to Heroku's Container Registry by executing the following command: $ heroku container:push web If you have an existing built image, you may only be interested in tagging and pushing it to Heroku In order to that, you need to use Docker's command line by executing the following commands (assuming your application's name is piomin-order-service): $ docker tag piomin/order-service registry.heroku.app/piomin-order-service/web $ docker push registry.heroku.app/piomin-order-service/web After the image has been successfully pushed, the new application should be visible in the Heroku dashboard Preparing an application When deploying an application based on Spring Cloud components to Heroku, we no longer have to perform any extra changes in its source code or add any additional libraries, which we when running it locally The only difference here is in the configuration settings, where we should set an address in order to integrate the application with service discovery, databases, or any other add-on that can be enabled for your microservice The current example, which is the same as the examples provided for Pivotal's deployment, is to store data in MongoDB that is assigned to the application as an mLab service Additionally, here, each client registers itself on the Eureka server, which is deployed as piomin-discovery-service The following screenshot displays a list of the applications deployed on Heroku for our examples: I deployed the previous applications on Heroku by connecting them with the GitHub repository This, in turn, requires you to create a separate repository per microservice For example, the repository of order-service is available at https://github.com/piomin/sample-heroku-order-service.git; other microservices may be at under similar addresses You can easily fork these microservices and deploy them on your Heroku account in order to perform tests Now let's take a look at the configuration settings provided for one of our example applications: account-service First, we have to override the auto-configured address of MongoDB using the MONGODB_URI environment variable provided by the Heroku platform There is also a necessity to provide the correct address of a Eureka server, as well as override the hostname and port sent by a discovery client during registration This is required because, by default, each application will try to register using an internal address that is not available for other applications Without overriding these values, inter-service communication with the Feign client would be unsuccessful: spring: application: name: account-service data: mongodb: uri: ${MONGODB_URI} eureka: instance: hostname: ${HEROKU_APP_NAME}.herokuapp.com nonSecurePort: 80 client: serviceUrl: defaultZone: http://piomin-discovery-service.herokuapp.com/eureka Notice that the environment variable HEROKU_APP_NAME is the name of the current application deployed on Heroku, as seen in the preceding snippet This is not available by default To enable a variable for your application, for example, customer-service, run the following command with the experimental addon runtime-dyno-metadata: $ heroku labs:enable runtime-dyno-metadata -a piomin-customer-service Testing deployments After deployment, every application is available at an address made up of its name and a platform's domain name, for example, http://piomin-order-service.herokuapp.com You are able to call the Eureka dashboard exposes using the URL, http://piomin-discovery-service.herokuapp.com/, which will allow you to check whether our example microservices have been registered If everything worked correctly, you should see something similar to the following screenshot: Each microservice exposes API documentation automatically generated by Swagger2, so you can easily test every endpoint by calling it from the Swagger UI dashboard, available on /swagger-ui.html; for example, http://piomin-order-service.herokuapp.com/swagger-ui.html The HTTP API visualization for order-service is as follows: Each microservice stores data in MongoDB This database can be enabled for your project by adding add-ons provided by Heroku, for example, mLab As you may remember, we have already used an example of the same service for storing data in applications deployed on the Pivotal platform Addons can be enabled for an application by provisioning it with the selected plan in the Resources tab of every application's details panel Once done, you can manage every plugin by simply clicking on it For mLab, you will be redirected to the mLab (mlab.com) site, where you are able to see a list of all the collections, users, and generated statistics The following screenshot illustrates the mLab dashboard for our examples: Summary We have reached the end of our Spring Cloud microservices journey! Our exercises began with simple deployments on the local machine, but in the last chapter we deployed our microservices in an environment fully-managed by the cloud vendor, which also automatically built, started, and exposed HTTP APIs on specified domains I personally think that it is amazing how easily we can run, scale, and expose data outside an application using any of the most popular programming languages or thirdparty tools, such as a database or a message broker In fact, each one of us can now implement and launch a production-ready application to the web within a few hours without worrying about the software that has to be installed This chapter has shown you how easily you can run Spring Cloud microservices on different platforms The given examples illustrate the real power of cloud-native applications No matter whether you launch an application locally on your laptop, inside a Docker Container, using Kubernetes, or on an online cloud platform such as Heroku or Pivotal Web Services, you don't have to change anything in the application's source code; the modifications have to be performed only in its properties (Assuming you use Config Server in your architecture, these changes are not invasive.) In the last two chapters, we looked at some of the most recent trends seen in the IT world Such topics as CI and CD, containerization with Docker, orchestration using Kubernetes, and cloud platforms are increasingly used by many organizations In fact, these solutions are partly responsible for the increasing popularity of microservices Currently, there is one leader in this area of programming— Spring Cloud There is no other Java framework with as many features, or that can implement so many patterns related to microservices, as Spring Cloud I hope this book will help you to use this framework effectively when building and honing your microservice-based enterprise system Other Books You May Enjoy If you enjoyed this book, you may be interested in these other books by Packt: Spring: Microservices with Spring Boot Ranga Rao Karanam ISBN: 978-1-78913-258-8 Use Spring Initializr to create a basic spring project Build a basic microservice with Spring Boot Implement caching and exception handling Secure your microservice with Spring security and OAuth2 Deploy microservices using self-contained HTTP server Monitor your microservices with Spring Boot actuator Learn to develop more effectively with developer tools Spring Security - Third Edition Mick Knutson, Robert Winch, Peter Mularien ISBN: 978-1-78712-951-1 Understand common security vulnerabilities and how to resolve them Learn to perform initial penetration testing to uncover common security vulnerabilities Implement authentication and authorization Learn to utilize existing corporate infrastructure such as LDAP, Active Directory, Kerberos, CAS, OpenID, and OAuth Integrate with popular frameworks such as Spring, Spring-Boot, Spring-Data, JSF, Vaaden, jQuery, and AngularJS Gain deep understanding of the security challenges with RESTful webservices and microservice architectures Integrate Spring with other security infrastructure components like LDAP, Apache Directory server and SAML Leave a review - let other readers know what you think Please share your thoughts on this book with others by leaving a review on the site that you bought it from If you purchased the book from Amazon, please leave us an honest review on this book's Amazon page This is vital so that other potential readers can see and use your unbiased opinion to make purchasing decisions, we can understand what our customers think about our products, and our authors can see your feedback on the title that they have worked with Packt to create It will only take a few minutes of your time, but is valuable to other potential customers, our authors, and Packt Thank you! .. .Mastering Spring Cloud Build self- healing, microservices- based, distributed systems using Spring Cloud Piotr Mińkowski BIRMINGHAM - MUMBAI Mastering Spring Cloud Copyright ©... in touch Reviews Introduction to Microservices The blessings of microservices Building microservices with Spring Framework Cloud- native development Learning the microservices architecture Understanding... implementations Using Spring Cloud Gateway Enable Spring Cloud Gateway for a project Built-in predicates and filters Gateway for microservices Integration with service discovery Summary Distributed