Minecraft Modding with Forge – Print and Ebook Now Available

kids, personal, , ,

Would you like to learn Minecraft Modding in a family-friendly way?
Don’t have any previous programming experience?
Never programmed in Java?

This new O’Reilly book on Minecraft Modding with Forge is targeted at parents and kids who would like to learn how to create new Minecraft mods. It can be read by parents or kids independently, and is more fun when they read it together. No prior programming experience is required however some familiarity with software installation would be very helpful.

Minecraft Modding with Forge Book Cover

Release Date: April 2015
Language: English
Pages: 194
Print ISBN:978-1-4919-1889-0| ISBN 10:1-4919-1889-6
Ebook ISBN:978-1-4919-1883-8| ISBN 10:1-4919-1883-7

Minecraft is commonly associated with “addiction”. This book hopes to leverage the passionate kids and teach them how to do Minecraft Modding, and in the process teach some fundamental Java concepts. They also pick up basic Eclipse skills as well.

It uses Minecraft Forge and shows how to create over two dozen mods. Here is the complete Table of Content:

Chapter 1 Introduction
Chapter 2 Block Break Message
Chapter 3 Fun with Explosions
Chapter 4 Entities
Chapter 5 Movement
Chapter 6 New Commands
Chapter 7 New Block
Chapter 8 New Item
Chapter 9 Recipes and Textures
Chapter 10 Sharing Mods
Appendix A What is Minecraft?
Appendix B Eclipse Shortcuts and Correct Imports
Appendix C Downloading the Source Code from GitHub
Appendix D Devoxx4Kids

Each chapter also provide several additional ideas on what readers can try based upon what they learned.

It has been an extremely joyful and rewarding experience to co-author the book with my 12-year old son. Many thanks to O’Reilly for providing this opportunity of a lifetime experience to us.

Here is the effort distribution by different collaborators on the book:

The book is available in print and ebook and can be purchased from shop.oreilly.com/product/0636920036562.do.

Three reviews so far are all five star and so that is encouraging:

Minecraft Modding with Forge Book Feedback - April 2015

Its also marked as #1 hot new release at Amazon in Game Programming:

Minecraft Modding with Forge - #1 Hot Release on Amazon

Scan the QR code to get the URL on your favorite device and give the first Java programming lesson to your kid – the Minecraft Way. They are going to thank you for that!

minecraft-modding-book-qrcode

Happy modding and looking forward to your reviews.

Microservice Design Patterns

microservices,

The main characteristics of a microservices-based application are defined in Microservices, Monoliths, and NoOps.  They are functional decomposition or domain-driven design, well-defined interfaces, explicitly published interface, single responsibility principle, and potentially polyglot. Each service is fully autonomous and full-stack. Thus changing a service implementation has no impact to other services as they communicate using well-defined interfaces. There are several advantages of such an application, but its not a free lunch and requires a significant effort in NoOps.

But lets say you understand the required effort, or at least some pieces of it, that is required to build such an application and willing to take a jump. What do you do? What is your approach for architecting such applications? Are there any design patterns on how these microservices work with each other?

microservices-function

Functional decomposition of your application and the team is the key to building a successful microservices architecture. This allows you to achieve loose coupling (REST interfaces) and high cohesion (multiple services can compose with each other to define higher level services or application).

Verb (e.g. Checkout) or Nouns (Product) of your application are one of the effective ways to achieve decomposition of your existing application. For example, product, catalog, and checkout can be three separate microservices and then work with each other to provide a complete shopping cart experience.

Functional decomposition gives the agility, flexibility, scalability, and other *ilities but the business goal is still to create the application. So once different microservices are identified, how do you compose them to provide the application’s functionality?

This blog will discuss some of the recommended patterns on how to compose microservices together.

Aggregator Microservice Design Pattern

The first, and probably the most common, is the aggregator microservice design pattern.

In its simplest form, Aggregator would be a simple web page that invokes multiple services to achieve the functionality required by the application. Since each service (Service A, Service B, and Service C) is exposed using a lightweight REST mechanism, the web page can retrieve the data and process/display it accordingly. If some sort of processing is required, say applying business logic to the data received from individual services, then you may likely have a CDI bean that would transform the data so that it can be displayed by the web page.

Microservice Aggregator Design Pattern

Another option for Aggregator is where no display is required, and instead it is just a higher level composite microservice which can be consumed by other services. In this case, the aggregator would just collect the data from each of the individual microservice, apply business logic to it, and further publish it as a REST endpoint. This can then be consumed by other services that need it.

This design pattern follows the DRY principle. If there are multiple services that need to access Service A, B, and C, then its recommended to abstract that logic into a composite microservice and aggregate that logic into one service. An advantage of abstracting at this level is that the individual services, i.e. Service A, B, and C, and can evolve independently and the business need is still provided by the composite microservice.

Note that each individual microservice has its own (optional) caching and database. If Aggregator is a composite microservice, then it may have its own caching and database layer as well.

Aggregator can scale independently on X-axis and Z-axis as well. So if its a web page then you can spin up additional web servers, or if its a composite microservice using Java EE, then you can spin up additional WildFly instances to meet the growing needs.

Proxy Microservice Design Pattern

Proxy microservice design pattern is a variation of Aggregator. In this case, no aggregation needs to happen on the client but a different microservice may be invoked based upon the business need.

Microservice Proxy Design Pattern

 

Just like Aggregator, Proxy can scale independently on X-axis and Z-axis as well. You may like to do this where each individual service need not be exposed to the consumer and should instead go through an interface.

The proxy may be a dumb proxy in which case it just delegates the request to one of the services. Alternatively, it may be a smart proxy where some data transformation is applied before the response is served to the client. A good example of this would be where the presentation layer to different devices can be encapsulated in the smart proxy.

Chained Microservice Design Pattern

Chained microservice design pattern produce a single consolidated response to the request. In this case, the request from the client is received by Service A, which is then communicating with Service B, which in turn may be communicating with Service C. All the services are likely using a synchronous HTTP request/response messaging.

Microservice Chain Design Pattern

The key part to remember is that the client is blocked until the complete chain of request/response, i.e. Service <-> Service B and Service B <-> Service C, is completed. The request from Service B to Service C may look completely different as the request from Service A to Service B. Similarly, response from Service B to Service A may look completely different from Service C to Service B. And that’s the whole point anyway where different services are adding their business value.

Another important aspect to understand here is to not make the chain too long. This is important because the synchronous nature of the chain will appear like a long wait at the client side, especially if its a web page that is waiting for the response to be shown. There are workarounds to this blocking request/response and are discussed in a subsequent design pattern.

A chain with a single microservice is called singleton chain. This may allow the chain to be expanded at a later point.

Branch Microservice Design Pattern

Branch microservice design pattern extends Aggregator design pattern and allows simultaneous response processing from two, likely mutually exclusive, chains of microservices. This pattern can also be used to call different chains, or a single chain, based upon the business needs.

Microservice Branch Design Pattern

Service A, either a web page or a composite microservice, can invoke two different chains concurrently in which case this will resemble the Aggregator design pattern. Alternatively, Service A can invoke only one chain based upon the request received from the client.

This may be configured using routing of JAX-RS or Camel endpoints, and would need to be dynamically configurable.

Shared Data Microservice Design Pattern

One of the design principles of microservice is autonomy. That means the service is full-stack and has control of all the components – UI, middleware, persistence, transaction. This allows the service to be polyglot, and use the right tool for the right job. For example, if a NoSQL data store can be used if that is more appropriate instead of jamming that data in a SQL database.

However a typical problem, especially when refactoring from an existing monolithic application, is database normalization such that each microservice has the right amount of data – nothing less and nothing more. Even if only a SQL database is used in the monolithic application, denormalizing the database would lead to duplication of data, and possibly inconsistency. In a transition phase, some applications may benefit from a shared data microservice design pattern.

In this design pattern, some microservices, likely in a chain, may share caching and database stores. This would only make sense if there is a strong coupling between the two services. Some might consider this an anti-pattern but business needs might require in some cases to follow this. This would certainly be an anti-pattern for greenfield applications that are design based upon microservices.

Microservice Branch Shared Data Design Pattern

This could also be seen as a transition phase until the microservices are transitioned to be fully autonomous.

Asynchronous Messaging Microservice Design Pattern

While REST design pattern is quite prevalent, and well understood, but it has the limitation of being synchronous, and thus blocking. Asynchrony can be achieved but that is done in an application specific way. Some microservice architectures may elect to use message queues instead of REST request/response because of that.

Microservice Async Messaging Design Pattern

In this design pattern, Service A may call Service C synchronously which is then communicating with Service B and D asynchronously using a shared message queue. Service A -> Service C communication may be asynchronous, possibly using WebSockets, to achieve the desired scalability.

A combination of REST request/response and pub/sub messaging may be used to accomplish the business need.

Coupling vs Autonomy in Microservices is a good read on what kind of messaging patterns to choose for your microservices.

Hope you find these design patterns are useful.

What microservice design patterns are you using?

JavaOne Cloud, DevOps, Containers, Microservices etc. Track

conferences, containers, microservices, , , ,

javaone-logo

Every year, for the past 19 years, JavaOne is the biggest and most awesome gathering of Java enthusiasts from around the world. JavaOne 2015 is the 20th edition of this wonderful conference. How many conferences can claim this? :)

Would you like to be part of JavaOne 2015? Sure, you can get notified when the registration opens and attend the conference. Why not take it a notch higher on this milestone anniversary?

Submit a session and become a speaker? Tips for Effective Sessions Submissions at Technology Conferences provide detailed tips on how to make the session title/abstract compelling for the program committee.

Have you been speaking at JavaOne for past several years? Don’t wait, and just submit your session today. The sooner you submit, higher the chances of program committee members voting on it. You know the drill!

Important Dates

  • Call for Papers closes April 29, 2015
  • Notifications for accepted and declined sessions: mid-June
  • Conference date: Oct 25 – 29

JavaOne Tracks

JavaOne conference is organized by tracks, and the tracks for this year are:

  • Core Java Platform
  • Java and Security
  • JVM and Emerging Languages
  • Java, DevOps, and the Cloud
  • Java and the Internet of Things
  • Java and Server-Side Development
  • Java, Clients, and User Interfaces
  • Java Development Tools and Agile Techniques

I’m excited and honored to co-lead the Java, DevOps, and the Cloud track with Bruno Borges (@brunoborges). The track abstract is:

The evolution of service-related enterprise Java standards has been underway for more than a decade, and in many ways the emergence of cloud computing was almost inevitable. Whether you call your current service-oriented development “cloud” or not, Java offers developers unique value in cloud-related environments such as software as a service (SaaS) and platform as a service (PaaS). The Java Virtual Machine is an ideal deployment environment for new microservice and container application architectures that deploy to cloud infrastructures. And as Java development in the cloud becomes more pervasive, enabling application portability can lead to greater cloud productivity. This track covers the important role Java plays in cloud development, as well as orchestration techniques used to effectively address the service lifecycle of cloud-based applications. Track sessions will cover topics such as SaaS, PaaS, DevOps, continuous delivery, containers, microservices, and other related concepts.

So what exactly are we looking for in this track?

  • How have you been using PaaS effectively for solving customer issues?
  • Why is SaaS critical to your business? Are you using IaaS, PaaS, SaaS all together for different parts of your business?
  • Have you used microservices in a JVM-based application? Lessons from the trenches?
  • Have you transformed your monolith to a microservice-based architecture?
  • How are containers helping you reduce impedance mismatch between dev, test, and prod environments?
  • Building a deployment pipeline using containers, or otherwise
  • Are PaaS and DevOps complimentary? Success stories?
  • Docker machine, compose, swarm recipes
  • Mesosphere, Kubernetes, Rocket, Juju, and other clustering frameworks
  • Have you evaluated different containers and adopted one? Pros and Cons?
  • Any successful practices around containers, microservices, and DevOps together?
  • Tools, methodologies, case studies, lessons learned in any of these, and other related areas
  • How are you moving legacy applications to the Cloud?
  • Are you using private clouds? Hybrid clouds? What are the pros/cons? Successful case studies, lessons learned.

These are only some of the suggested topics and are looking forward to your creative imagination. Remember, there are a variety of formats for submission:

  • 60 mins session or panel
  • Two-hour tutorial or hands-on lab
  • 45 mins BoFs
  • 5 mins Ignite talk

We think this is going to be the coolest track of the conference, with speakers eager to share everything about all the bleeding edge technologies and attendees equally eager to listen and learn from them. We’d like to challenge all of you to submit your best session, and make our job extremely hard!

Once again, make sure to read Tips for Effective Sessions Submissions at Technology Conferences for a powerful session submission. One key point to remember: NO vendor or product pitches. This is a technology conference!

Dilbert Technology Show

Links to Remember

  • Call for Papers: oracle.com/javaone/call-for-proposals.html
  • Tracks: oracle.com/javaone/tracks.html
  • Submit your Proposal: oracleus.activeevents.com/2015/portal/cfp/cfpLogin.ww

JavaOne is where you have geekgasm multiple times during the day. This is going to be my 17th attendance in a row, and so looking forward to see you there!

Microservices, Monoliths, and NoOps

microservices,

Monolithic Applications

A monolith application, in layman terms, is where entire functionality of the application is packaged together as a single unit or application. This unit could be JAR, WAR, EAR, or some other archive format, but its all integrated in a single unit. For example an online shopping website will typically consists of customer, product, catalog, checkout, and other features. Another example is of a movieplex. Such an application would typically consist of show booking, add/delete movie, ticket sales, accrue movie points, and other features. In case of a monolithic application, all these features are implemented and packaged together as one application.

Movieplex7 is one such canonical Java EE 7 sample application and the main features are shown below:

Movieplex7 Features

This application when packaged as a WAR would looks like:

Moviexplex WAR Package

The archive consists of some web pages that forms the UI. Classes implement the business logic, persistence, backing beans, etc. And finally there are some configuration files that define database connection, CDI configuration, etc.

More specifically, structure of the WAR looks like:

Movieplex7 WAR Structure

In this WAR structure, web pages are within the green box, all classes are within the orange box, and configuration files are within the blue box.

This application is somewhat modular as all the classes are neatly organized in package by different functionality. Web pages and configuration files follow a similar pattern as well.

Advantages of Monolithic Applications

There are a few advantages of this style of application:

  1. Well Known: This is how typically applications have been built so far. Its easy to conceptualize and all the code is in one place. Majority of existing tools, application servers, frameworks, scripts are able to deal with such kind of applications.
  2. IDE-friendly: Development environments, such as NetBeans, Eclipse, or IntelliJ, can be easily setup for such applications. IDEs are typically designed to develop, deploy, debug, profile a single application easily. Stepping through the code base is easy because the codebase is all together.
  3. Easy Sharing: A single archive, with all the functionality, can be shared between teams and across different stages of deployment pipeline.
  4. Simplified Testing: Once the application is deployed successfully, all the services, or features, are up and available. This simplifies testing as there are no additional dependencies to wait for in order for the testing to begin. Either the application is available, in which case all features are available, or the application is not available at all. Accessing or testing the application is simplified in either case.
  5. Easy Deployment: Easy to deploy since, typically, a single archive needs to be copied to one directory. The deployment times could vary but the process is pretty straight forward.

Disadvantages of Monolithic Applications

Monolith applications have served us well so far, and most likely will continue to work for some in the years to come. There are websites like Etsy that have 60 million monthly visitors and 1.5 billion monthly page views and are built/deployed as one large monolith. They have taken monoliths to an extreme where they are doing 50 deploys/day using a single large application. Unfortunately, most of the companies are not like that.

A monolithic application, no matter how modular, will eventually start to break down as the team grows, experienced developers leave and new ones join, application scope increases, new ways to access the applications are added, and so on. Take any monolith application that has spanned multiple years and teams and the entire code base will look like a bug ball of mud. That’s how software evolves especially when there is a pressure to deliver.

Lets look at some of the disadvantages of monolithic applications

  • Limited Agility: Every tiny change to the application means full redeployment of the archive. Consider the use case where only one piece of functionality in the application needs to be updated, such as booking or add/delete movie. This would require the entire application to be built again, and deployed again, even though other parts of the application has not changed. This means that developers will have to wait for the entire application to be deployed if they want to see the impact of quick change made in their workspace. Even if not intentional, but this may require tight coupling between different features of the application. This may not be possible all the time, especially if multiple developers are working on the application. This reduces agility of the team and the frequency by which new features can be delivered.
  • Obstacle for continuous delivery: The sample application used here is rather small so the time it takes to rebuild and deploy the archive would not be noticeable much. But a real-life application would be much bigger, and deployment times can be frustratingly long and slow. If a single change to the application would require entire application to be redeployed then this could become an obstacle to frequent deployments, and thus an impediment of continuous deployment. This could be a serious issue if you are serving a mobile application where users expect latest cool new feature all the time.
  • “Stuck” with Technology Stack: Choice of technology for such applications are evaluated and decided before the application development starts. Everybody in the team is required to use the same language, persistence stores, messaging system, and use similar tools to keep the team aligned. But this is like fitting a square peg in a round hole. Is MySQL an appropriate data store for storing graph databases? Is Java the most appropriate language for building front-end reactive applications? Its typically not possible to change technology stack mid stream without throwing away or rewriting significant part of existing application.
  • Technical Debt: “Not broken, don’t fix it” methodology is very common in software developed, more so for monolithic applications. This is convenient and enables to keep the application running.  A poor system design or badly written code is that much difficult to modify because other pieces of the application might be using it in unexpected ways. Software entropy of the system increases over a period of time unless it is refactored. Typically such an application is built over several years with the team that is maintaining the code base completely different from the one that created the application. This increases technical debt of the application and makes it that much harder to refactor the application later on.

What are Microservices?

The growing demand for agility, flexibility, and scalability to meet rapidly evolving business needs creates a strong need for a faster and more efficient delivery of software.

Meet Microservices!

Microservices is a software architectural style that require functional decomposition of an application. A monolithic application is broken down into multiple smaller services, each deployed in its own archive, and then composed as a single application using standard lightweight communication, such as REST over HTTP. The term “micro” in microservices is no indication of the LOCs in the service, it only indicates the scope is limited to a single functionality.

We’ve all been using microservices for a few years already. Think about a trivial mobile application can tell you the ratings of a hotel, find out the weather at your destination, book the hotel, locate directions to your hotel, find a nearby restaurant, and so on. This application is likely using different services such as Yelp, Google Maps, Yahoo Weather API, etc to accomplish these tasks. Each of this functionality is effectively running as an independent service and composed together in this single mobile application. Explosion of mobile apps, and their support for the growing business demand is also highlighted by Forrester’s four-tier engagement platform, and services are a key part of that.

Lets look at what are the characteristics of a microservice based application.

Characteristics of Microservices

Lets look at the characteristics of an application built using microservices.

  • Domain Driven Design: Functional decomposition of an application can be achieved using well-defined principles of Domain Driven Design by Eric Evans. This is not the only way to break down the applications but certainly a very common way. Each team is responsible for building the entire functionality around that domain or function of the business. Teams building a service include full range of developers, thus following the full-stack development methodology, and include skills for user interface, business logic, and persistence.
  • Single Responsibility Principle: Each service should have responsibility over a single part of the functionality, and it should do that well. This is one of the SOLID principles and has been very well demonstrated by Unix utilities.
  • Explicitly Published Interface: Each service publishes an explicitly defined interface and honors that all times. The consuming service only cares about that interface, and does not, rather should not, have any runtime dependency on the consumed service. The services agree upon the domain models, API, payload, or some other contract and they communicate using only that. A newer version of the interface may be introduced, but either the previous versions will continue to exist or the newer services are backwards compatible. You cannot break compatibility by changing contracts.
  • Independently Deploy, Upgrade, Scale, Replace: Each service can be independently deployed, and redeployed again, without impacting the overall system. This allows a service to be easily upgraded, for example to add more features. Each service can also scale independently on X-axis (horizontal duplication) or Z-axis (lookup oriented splits) as defined in Art of Scalability. Implementation of the service, or even the underlying technology stack, can change as long as the exact same contract is published. This is possible because other services rely only upon the published interface.
  • Potentially Heterogeneous/Polyglot: Implementation detail of the one service should not matter to another service. This enables the services to be decoupled from each other, and allows the team building the service to pick the language, persistence store, tools, methodology that is most appropriate for them. A service that requires to store data in a RDBMS can choose MySQL, and another service that needs to store documents can choose Mongo. Different teams can choose Java EE, NodeJS, Python, Vert.x, or whatever is most efficient for them.
  • Light-weight Communication: Services communicate with each other using a light-weight communication, such as REST over HTTP. This is inherently synchronous and so could have some potential bottle necks. An alternative mechanism is to use publish-subscribe mechanism that supports asynchronous messaging. Any of the messaging protocols such as AMQP, STOMP, MQTT, or WebSocket that meet the needs can be used there. Simple messaging implementations, such as ActiveMQ, that provide a reliable asynchronous fabric are quite appropriate for such usages. The choice of synchronous and asynchronous messaging is very specific to each service. They can even use a combination of the two approaches. Similarly the choice of protocol is very specific to each service but there is enough choice and independence for each team building the service.

Netflix is a poster child for microservices and several articles have been published on their adoption of microservices. A wide range of utilities that power their architecture are available at netflix.github.io.

Advantages of Microservices

  • Easier to develop, understand, and maintain: Code in a microservice is restricted to one function of the business and is thus easier to understand. IDEs can load the small code base very easily and keep the developers productive.
  • Starts faster than a monolith: Scope of each microservice is much smaller than a monolith and this leads to a smaller archive. As a result the deployment and the startup is much faster keeping developers productive.
  • Local change can be easily deployed: Each service can be deployed independent of other services. Any change local to the service can be easily made by the developer without requiring coordination with other teams. For example, performance of a service can be improved by changing the underlying implementation. As a result this keeps the agility of the microservice. This is also a great enabler of CI/CD.
  • Scale independently: Each service can scale independently using X-axis cloning and Z-axis partitioning based upon their need. This is very different from monolithic applications that may have very different requirements and yet must be deployed together.
  • Improves fault isolation: A misbehaving service, such as with a memory leak or unclosed database connections, will only affect that service as opposed to the entire monolithic application. This improves fault isolation and does not brings the entire application down, just a piece of it.
  • No long term commitment to any stack: Developers are free to pick language and stack that is best suited for their service. Even though the organizations may restrict the choice of technology but you are not penalized because of past decisions. It also enables to rewrite the service using better languages and technologies. This gives freedom of choice to pick a technology, tools, and frameworks.

Microservices may seem like a silver bullet that can solve significant amount of software problems. They serve a pretty good purpose but are certainly not easy. A significant operations overhead is required for these, and this article from Infoworld clearly points out.

with microservices, some technical debt is bound to shift from dev to ops, so you’d better have a crack devops team in place

This is very critical as now your one monolith is split across multiple microservices and they must talk to each other. Each microservice may be using a different platform, stack, persistent store and thus will have different monitoring and management requirements. Each service can then independently scale on X-axis and Z-axis. Each service can be redeployed multiple times during the day.

Microservices and NoOps

This imposes additional requirements on your infrastructure. These are commonly put together and called as NoOps. Essentially these are a set of services that provide a better process for deploying applications, and keep them running.

  • Service replication: Each service need to replicate, typically using X-axis cloning or Y-axis partitioning. Does each service need to build their logic to scale? For example, Kubernetes provide a great way to replicate services easily using Replication Controller.
  • Service discovery: Multiple services might be collaborating to provide an application’s functionality. This will require a service to discover other services. It could be tricky in a cloud environment where the services are ephemeral and possibly scale up and down. Resolving the services that are required for a service is thus a common functionality for all other services. Services need to register with a central registry and other services need to query this registry for resolving any dependencies. Netflix Eureka, Etcd, Zookeeper are some options in this space (more details).
  • Resiliency: Failure in software occurs, no matter how much and how hard you test it. The key question is not “how to avoid failure” but “how to deal with it”. This is all the more prominent in microservices where services are distributed all over the Internet. Its important for services to automatically take corrective action and ensure the user experience is not impacted. Michael Nygard’s book Release It! introducs Circuit Breaker pattern to deal with software resiliency. Netflix’s Hystrix provide an implementation of this design pattern (more details).
  • Service monitoring: One of the most important aspects of a distributed system is service monitoring and logging. This allows to take a proactive action, for example, if a service is consuming unexpected resources.

Refactoring into Microservices

Microservices also does not mean you need to throw away your existing application. Rather in majority (99.9%?) cases, you cannot throw away the application. So you’ve to build a methodology on how to refactor an existing application using microservices. However you need to bring your monolith to a stage where it is ready for refactoring. As Distributed big balls of mud highlight:

If you can’t built a monolith, what makes you think microservices are the answer?

Refactoring may not be trivial but in the long terms this has benefits which is also highlighted in the previously quoted article from Infoworld:

Refactoring a big monolithic application [using microservices] can be the equivalent of a balloon payment [for reducing technical debt] … you can pay down technical debt one service at a time

Functional decomposition of a monolith is very important otherwise it becomes a distributed monolith as opposed to a microservice based application.

Future Blogs

A subsequent blog on blog.arungupta.me will show how to refactor an existing Java EE application using microservices.

Some more questions that would be answered in subsequent blogs ….

  • How is it different from SOA?
  • Is REST the only way to exchange data? What messaging prorotocols?
  • Does microservices simplify/require CI/CD?
  • How is it related to Containers and DevOps? Are containers required to run microservices?
  • Are there any standards around microservices?
  • Are we pushing the problems around to orchestration?
  • What roles does PaaS play to enable microservices?
  • How can existing investment be leveraged?
  • Microservices Maturity Model

 

Minecraft Server on Google Cloud – Tech Tip #82

java, kids, techtip, , , ,

Minecraft Logo

Bukkit Logo

If you’ve not followed the Minecraft/Bukkit saga over the past few months, Bukkit and CraftBukkit downloads were taken down by DMCA because a developer (@wolvereness) wanted Mojang to open up. Mojang (@vubui) posted an official statement in their forums. The general feeling is that @wolvereness left the Bukkit community hanging, and Mojang is not responsible for this debacle.

One of my friends (@ryanmichela), and a contributor to Bukkit, prepared a slide deck explaining the unfortunate debacle:

Anyway, leaving all the gory details behind, this blog will show how to get started with Bukkit 1.8.3.

What?

You just said, Bukkit was shutdown by DMCA.

SpigotMC LogoHail Spigot for reviving Bukkit, and updating to 1.8.3!

Its still not clear how did Spigot get around DMCA shutdown but the binaries seem to be available again, at least for now.

As a refresher, Bukkit is the API used by developers to make plugins. CraftBukkit is the modified Minecraft server that can understand plugins made by the Bukkit API.

Minecraft Server Hosting on OpenShift already explained how to setup a Minecraft server on OpenShift. This Tech Tip will show how to get a Minecraft server running on Google Cloud.

Lets get started!

Get Started with Google Cloud

Google Cloud Platform logo

  1. Sign up for a free trial at cloud.google.com. This gives you credit of $300, which should be pretty decent to begin with.

Create and Configure Google Compute Engine

  1. Go to console.developers.google.com and create a new project by specifying the values as shown:Create Project on Google Cloud
  2. In console.developers.google.com, go to “Compute”, “Compute Engine”, “Networks”, “default”, “New firewall rule” and enter the values as shown and click on “Create”.Google Cloud Firewall Rule
  3. In the left menu bar, click on “VM Instances” under “Compute Engine”, “Create instance”. Take everything default except:
    1. Provide a name as “minecraft-instance”
    2. Change Image to Ubuntu 14.10.
    3. Change External IP to “New static IP address” and fill in the details. IP address is automatically assigned.

    Exact values are shown here:

    Google Cloud Create Instance

    And click on “Create”.

    Note down the IP address, this will be used later to connect from Minecraft launcher.

  4. Click on the newly created instance, “Add tags”, and specify “minecraft” tag. Exact same tag on the VM instance and Firewall rule ensures that the rule is applied to the appropriate instance.

Install JDK, Git, and Spigot

In console.developers.google.com, select the recently created instance, click on “SSH”, “Open in browser window”. The software is installed in the shell window.

Install JDK

Make sure to answer questions and accept license during the install. Using OpenJDK 8 to install Spigot gives the following exception:

Install Git

This is required for installing Spigot.

Install Spigot

Download and Install Spigot

A successful completion of this task shows the following message:

Start Minecraft Server on Google Cloud

Run the server as:

This will generate “eula.txt”. Accept license agreement by giving the following command:

Run server as:

This will start the CraftBukkit 1.8 server in background.

Connect to Minecraft Server from the Client

Launch Minecraft client and create a new Minecraft server as:

Google Cloud Minecraft Multiplayer

Clicking on Done shows:

Google Cloud Multiplayer Minecraft Server

Now your client can connect to the Minecraft server running on Google Cloud.
Google Cloud Minecraft Client

The server is now live. Add 104.155.38.193  to your Minecraft launcher and put some Google resources to test :)

I was hoping to provide a script that can be run using Google Cloud SDK but the bundled CLI seems to have some issues creating the project. CLI equivalent for other commands can be easily seen from the console itself.

Enjoy and happy Minecrafting!

Minecraft Modding Course at Elementary School – Teach Java to Kids

java, kids, , ,

Cross posted from weblogs.java.net/blog/arungupta/archive/2015/03/22/minecraft-modding-course-elementary-school-teach-java-kids

minecraft-logo

Exactly two years ago, I wrote a blog on Introducing Kids to Java Programming using Minecraft. Since then, Devoxx4Kids has delivered numerous Minecraft Modding workshops all around the world. The workshop material is all publicly accessible at bit.ly/d4k-minecraft. In these workshops, we teach attendees, typically 8 – 16 years of age, how to create Minecraft Mods. Given the excitement around Minecraft in this age range, these workshops are typically sold out very quickly.

One of the parents from our workshops in the San Francisco Bay Area asked us to deliver a 8-week course on Minecraft modding at their local public school. As an athlete, I’m always looking for new challenges and break the rhythm. This felt like a good option, and so the game was on!

My son has been playing the game, and modding, for quite some time and helped me create the mods easily. We’ve also finished authoring our upcoming O’Reilly book on Minecraft Modding using Forge so had a decent idea on what needs to be done for these workshops.

Minecraft Modding Workshop Material

All the workshop material is available at bit.ly/d4k-minecraft.

Getting Started with Minecraft Modding using Forge shows the basic installation steps.

These classes were taught from 7:30am – 7:45am, before start of the school. Given the nature of workshop, the enthusiasm and concentration in the kids was just amazing.

Minecraft Modding Course Outline

The 8 week course was delivered using the following lessons:

Week LESSON Java concepts
1 Watch through the video and understand the software required for modding Familiarity with JDK, Forge, Eclipse
2 Work through the installation and get the bundled sample mod running. This bundled mod, without any typing, allows to explain the basic concepts of Java such as class, packages, methods, running Minecraft from Eclipse, seeing the output in Eclipse panel.
3 Chat Items mod shows how to create a stack of 64 potatoes if the word “potato” is typed in the chat window.
  • Create a new class in Eclipse
  • Annotations and event-driven programming to listen for events when a player types a message in the chat window is introduced.
  • String variable types and how they are enclosed within a quotes is introduced.
4 Continue with Chat Items mod and a couple of variations. Change the number of items to be generated. Generate different items on different words, or multiple items on same word.
  • Integer variables for changing the number of items.
  • How  use Eclipse allows code completion and scroll through the list of items that can be generated.
  • Multiple if/else blocks and scope of a block.
5 Eclipse Tutorial for Beginners Some familiarity with Eclipse
6 Ender Dragon Spawner mod spawns an Ender Dragon every time a dragon egg is placed.
  •  == to compare objects
  • Accessing properties using . notation
  • Creating a new class
  • Calling methods on a class
7 Creeper Spawn Alert mod alerts a player when creeper is spawned
  •  instanceof operator
  • for loop
  • java.util.List
  • Enums
  • && and || operators
  • Parent/child class
8 Sharp Snowballs mod turns all snowballs into arrows
  • 15-20 LOC of methods
  • ! operator
  • Basic Math in Minecraft

Most of the kids in this 8-week course had no prior programming experience. And it was amazing to see them be able to read the Java code by week 7. Some kids who had prior experience finished the workshop in first 3-4 weeks, and were helping other kids.

Check out some of pictures from the 8-week workshops:

 Minecraft Modding at Public Elementary School
 

Many thanks to attendees, parents, volunteers, Parent Teacher Association, and school authorities for giving us a chance. The real benchmark was when all the kids raised their hands to continue workshop for another 8 weeks … that was awesome!

Is Java difficult as kids first programming language?

One of the common questions asked during these workshops is “Java is too difficult a language to start with”. Most of the times these questions are not based on any personal experience but more on the lines my-friend-told-me-so or i-read-an-article-explaining-so. My typical answer consists of the following parts:

  1. Yes, Java is a bit verbose, but was designed to be readable by humans and computer. Ask somebody to read Scala or Clojure code at this age and they’ll probably never come back to programming again. These languages serve a niche purpose, and their concepts are now anyway getting integrated into the mainstream language already.
  2. Ruby, Groovy, and Python are alternative decent languages to start with. But do you really want to start teaching them fundamental programming using Hello World.
  3. Kids are already “addicted” to Minecraft. Game is written using Java and modding can be done using Java. Lets leverage that addiction and convert that into their passion for programming. Minecraft provides a perfect platform for gamification of programming experience at this early age.
  4. There are 9 million Java developers. It is a very well adopted and understood language, with lots of help in terms of books, articles, blogs, videos, tools, etc. And the language has been around for almost 20 years now. Other languages come and go, but this is the one to stay!

As Alan Kay said

The best way to predict the future is to create it

Lets create some young Java developers by teaching them Minecraft modding. This will give them bragging rights in their friends, parents a satisfaction that their kids are learning a top notch programming language, and budding Java developers to the industry.

I dare you to pick up this workshop and run in your local school :)

Minecraft Modding Course References

Sign up for an existing Devoxx4Kids chapter in your city, or open a new one.

If you are in the San Francisco Bay Area, then register for one of our upcoming workshops at meetup.com/Devoxx4Kids-BayArea/. There are several chapters in the USA (Denver, Atlanta, Seattle, Chicago, and others).

Would your school be interested in hosting a similar workshop? Devoxx4Kids can provide train-the-trainer workshop. Let us know by sending an email to .

As a registered NPO and 501(c)(3) organization in the US, it allows us to deliver these workshops quite selflessly, fueled by our passion to teach kids. But donations are always welcome :)

Configure JRebel with Docker containers – Tech Tip #81

containers, javaee, techtip, wildfly, , , ,

JRebel allows you to skip build and redeploy process by instantly deploying your application to the application server of your choice. It is supported in all the major IDEs such as NetBeans, Eclipse, and IntelliJ. It is also supported in a wide variety of application servers such as JBoss EAP, WildFly, WebLogic, WebsFear (err, WebSphere), Tomcat, and many others.

You can easily get started with JRebel in JBoss Developer Studio  or Integrate JRebel with JBoss on your local desktop. It can also be easily used with JBoss Developer Studio and Ticket Monster on OpenShift.

This Tech Tip will explain how do you set up JRebel with Docker containers. Specifically, we’ll use the sample application provided by Java EE 7 Hands-on Lab (jrebel branch), JBoss Tools with Eclipse Mars M5, and running the sample application in WildFly Docker container.

Many thanks to Adam Koblentz (@akoblentz) for helping me through the steps!

Lets get started!

Install JRebel in Eclipse

JRebel runs in three modes:

  • Local: App server is running from inside the IDE
  • External: App server is running from outside the IDE, such as using CLI, but on the same machine
  • Remote: App server is running on a different machine, VM, container, or cloud

Docker containers need to be configured using the “remote” mode.

  1. Install JBoss Tools  as explained at tools.jboss.org/downloads/. JRebel’s remote mode can only be enabled using the IDE. Install JRebel plugin from Eclipse Marketplace.

Package rebel.xml and rebel-remote.xml with the WAR

These files define the location of classes and resources in your archive.

  1. Clone the Java EE 7 HOL repo:
  2. Import the Maven project (from the solution directory) in the IDE, right-click on the project, select JRebel menu, and click on “Enable JRebel Nature”. This will generate rebel.xml in src/main/resources directory and would look something like:
  3. Right-click on the project again, and select “Enable Remoting”. This generates rebel-remote.xml, in src/main/resources directory again, and will look like:

    This needs to be done on the machine where JRebel will be used in the IDE. This will ensure that the public key is generated appropriately.
  4. Package your application as

    This will package rebel.xml and rebel-remote.xml in the WAR file.

Configure and Run the Application Server

Application server needs to know about JRebel agent and platform-specific library. Both of these files are available from Eclipse if JRebel was installed earlier. On Mac these files are available in eclipse/mars/m5/eclipse/plugins/org.zeroturnaround.eclipse.embedder_6.1.1.RELEASE-201503121801/jr6/jrebel/ directory. The exact name would very likely differ in your case.

  1. Build the image using the Dockerfile:

    The key parts in this image are:

    1. Using the official jboss/wildfly Docker image
    2. Copying the JRebel agent and platform-specific library to the image
    3. Configuring application server such that it knows about the “remote” mode and platform-specific library
    4. Start WildFly
    5. Downloads the pre-built WAR file from GitHub. This will not work for you, and you’ll need to replace it with something like:

      This WAR file is the same that was generated earlier.
  2. Actually build the image as:
  3. Run the container as:

    and this should show something like:

    JRebel license information is a good sign that everything is configured properly.

    If you used Docker Machine to Setup Docker Host then the application should now be accessible at 192.168.99.100:8080/movieplex7/.

Configure Eclipse

Last step is to configure Eclipse so that it knows where the application is deployed.

  1. In Eclipse, right-click on the project, select JRebel, Advanced Properties
  2. Click on “Edit” on next to “Deployment URLs”
  3. Click on Add and specify the URL of the application, 192.168.99.100:8080/movieplex7/ in our case.
  4. Click on Continue, Apply, OK.

Voila, the configuration is now complete.

Now changing any class, adding any method, updating any entity or HTML or JSF page will push the changes to the Docker container instantly. No need to redeploy the application.

Enjoy!

9 Docker recipes for Java EE Applications – Tech Tip #80

containers, javaee, techtip, , , , ,

Cross-posted from www.voxxed.com/blog/2015/03/9-docker-recipes-for-java-ee-applications/

So, you’d like to start using Docker for Java EE applications?

A typical Java EE application consists of an application server, such as WildFly, and a database, such as MySQL. In addition, you might have a separate front-end tier, say Apache, for load balancing a number of application server. A caching layer, such as Infinispan, may be used to improve overall application performance. Messaging system, such as ActiveMQ, may be used for processing queues. Both the caching and messaging components could be setup as a cluster for further scalability.

This Tech Tip will show some simple Docker recipes to configure your containers that use application server and database. Subsequent blog will cover more advanced recipes that will include front-end, caching, messaging, and clustering.

Lets get started!

Docker Recipe #1: Setup Docker using Docker Machine

If Docker is not already setup on your machine, then as a first step, you need to set it up. If you are on a recent version of Linux then you already have Docker. Or optionally can be installed as:

On Mac and Windows, this means installing boot2docker which is a Tinycore Linux VM and comes with Docker host. Then you need to configure ssh keys and certificates.

Fortunately, this is extremely simplified using Docker Machine. It takes you from zero-to-Docker on a host with a single command. This host could be your laptop, in the cloud, or in your data center. It creates servers, installs Docker on them, then configures the Docker client to talk to them.

This recipe is explained in detail in Docker Machine to Setup Docker Host.

Docker Recipe #2: Application Server + In-memory Database

One of the cool features of Java EE 7 is the default database resource. This allows you to not worry about creating a JDBC resource in an application server-specific before your application is accessible. Any Java EE 7 compliant application server will map the default JDBC resource name (java:comp/DefaultDataSource) to the application server-specific resource in the bundled database server.

For example, WildFly comes bundled with H2 in-memory database. This database is ready to be used as soon as WildFly is ready to accept your requests. This simplifies your development efforts and allows you to do a rapid prototyping. The default JDBC resource is mapped to
java:jboss/datasources/ExampleDS which is then mapped to the JDBC URL of jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE.

In such a case, the Database server is another application running inside the Application server.

Docker Recipe for Java EE Application #1

Here is the command that runs Java EE 7 application in WildFly:

If you want to run a typical Java EE 7 application using WildFly and H2 in-memory database, then this Docker recipe is explained in detail in Java EE 7 Hands-on Lab on WildFly and Docker.

Docker Recipe #3: Two Containers on Same Host Using Linking

The previous recipe gets you started rather quickly but becomes a bottleneck soon as the database is only in-memory. This means that any changes made to your schema and data are lost after the application server shuts down. In this case, you need to use a database server that resides outside the application server. For example, MySQL as the database server and WildFly as the application server.

To keep things simple, both the database server and application server can run on the same host.

Docker Recipe for Java EE Application #2

Docker Container Links are used to link the two containers. Creating a link between two containers creates a conduit between a source container and a target container and securely transfer information about source container to target container. In our case, target container (WildFly) can see information about source container (MySQL). The important part to understand here is that none of this information needs to be publicly exposed by the source container, and is only made available to the target container.

Here are the commands that start the MySQL and WildFly containers and link them:

WildFly and MySQL linked on two Docker containers explains how to set up this recipe.

Docker Recipe #4: Two Containers on Same Host Using Fig

The previous recipe require you to run the containers in a specific order. Running multi-container applications can quickly become challenging if each tier of your application is sitting in a container. Fig (deprecated in favor of Docker Compose) is a Docker Orchestration Tool that:

  • Define multiple containers in a single configuration file
  • Create dependencies between two containers by creating links between them
  • Start containers in the right sequence

Docker Recipe for Java EE Application #3

The entry point for Fig is a configuration file as shown:

and all the containers can be started as:

Docker orchestration using Fig explains this recipe in detail.

Fig is only receiving updates. Its code base is used as basis for Docker Compose. This is explained in the next recipe.

Docker Recipe #5: Two Containers on Same Host Using Compose

Docker Compose is a tool for defining and running complex applications with Docker. With Compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running.

The application configuration file is the same format as from Fig. The containers can be started as:

This recipe is explained in detail in Docker Compose to Orchestrate Containers.

Docker Recipe #6: Two Containers on Different Hosts using IP Address

In the previous recipe, the two containers are running on the same host. These two could easily communicate using Docker linking. But simple container linking does not allow cross-host communication.

Running containers on the same host means you cannot scale each tier, database or application server, independently. This is where you need to run each container on a separate host.

Docker Recipe for Java EE Application #4

MySQL container can start as:

JDBC resource can be created as:

And WildFly container can start as:

Complete details for this recipe is explained in Docker container linking across multiple hosts.

Docker Recipe #7: Two Containers on Different Hosts using Docker Swarm

Docker Machine

Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual host. It picks-up where Docker Machine leaves off by optimizing host resource utilization and providing failover services.  Specifically, Docker Swarm allows users to create resource pools of hosts running Docker daemons and then schedule Docker containers to run on top, automatically managing workload placement and maintaining cluster state.

More details about this recipe are coming in a subsequent blog.

Docker Recipe #8: Deploy Java EE Application from Eclipse

Last recipe will deal with how to deploy your existing applications to a Docker container.

Lets say you are using JBoss Tools as your development environment and WildFly as your application server.

eclipse-logo JBoss Tools Logo

There are a couple of ways by which these applications can be deployed:

  • Use Docker volumes + Local deployment:  Here a directory on your local machine is mounted as a Docker Volume. WildFly Docker container is started by mapping that directory to the deployment directory as:

    Configure JBoss Tools to deploy WAR files to this directory.
  • Use WildFly management API + Remote deployment: Start WildFly Docker container, and additionally expose the management port 9990 as:

    Configure JBoss Tools to use a remote WildFly server and deploy using management APIs.

This recipe is explained in detail at Deploy to WildFly and Docker from Eclipse.

Docker Recipe #9: Test Java EE Applications using Arquillian Cube

Arquillian Cube allows you to control the lifecycle of Docker images as part of the test lifecyle, either automatically or manually. Cube uses Docker REST API to talk to the container. It uses the remote adapter API, for example WildFly in this case, to talk to the application server. Docker configuration is specified as part of the maven-surefire-plugin as:

Complete details about this recipe are available on Run Java EE Tests on Docker using Arquillian Cube.

What other recipes are you using to deploy your Java EE applications using Docker?

Enjoy!

Deploy to WildFly and Docker from Eclipse – Tech Tip #79

containers, javaee, wildfly, , , ,

Docker and WildFly Part 1 – Deployment via Volumes and Docker and WildFly Part 2 – Deployment over Management API shows two approaches of how JBoss Tools can be configured to run any application on WildFly server running as a Docker container.

The blogs provide detailed setup and the underlying background. This Tech Tip will provide a quick summary of how to deploy a Java EE 7 application to WildFly and Docker from Eclipse.

Lets get started!

Configure Docker

  1. Configure Docker on your machine using Docker Machine.
  2. Find the IP address as:

    and add an entry in /etc/hosts as:

Deployment to WildFly Container using Docker Volumes

  1. Create a folder that will be mounted as volume in the WildFly Docker container. In this case, the folder is /Users/arungupta/tmp/deployments.WildFly Docker container can be started as:

    rw ensures that the Docker container can write to it.
  2. Create a new server adapter:
    WildFly Docker Server Adapter
  3. Assign or create a WildFly 8.x runtime:

     Docker WildFly Server Adapter

    Changed properties are highlighted.

  4. Setup the server properties as:

    Docker WildFly Adapter Properties

     

    Changed properties are highlighted. The two properties on the left are automatically propagated from the previous dialog. Additional two properties on the right side are required to disable to keep deployment scanners in sync with the server.

  5. Specify a custom deployment folder on Deployment tab of Server Editor:

    Docker WildFly Server Adapter

  6. Right-click on the newly created server adapter and click “Start”.

    Docker WildFly Server Synchronized

    Status quickly changes to “Started, Synchronized” as shown.

  7. Open up any Java EE 7 project (for example javaee7-simple-sample), right-click, Run on Server, and chose this server. The project runs and displays the page:

    Docker Java EE 7 Output

 

Deployment to WildFly Container using Management API

  1. Run WildFly management image as:

    This is only a convenience image to reduce the number of steps required to get started. Dockerfile for this image has more details, including admin credentials.

    Volume mapping is not required in this case, instead additional management port is exposed.

  2. Configure a remote server controlled by management operations:Docker WildFly Remote Server Configuration

    Changed properties are highlighted.

  3. Take the defaults:

    Docker WildFly Remote System Integration

  4. Set up server properties by specifying the admin credentials (Admin#70365). Note, you need to delete the existing password and use this instead:

    Docker WildFly Admin Credentials

  5. Right-click on the newly created server adapter and click “Start”.Status quickly changes to “Started, Synchronized” as shown.

    Docker WildFly Server Synchronized

  6. Open up any Java EE 7 project (for example javaee7-simple-sample), right-click, Run on Server, and chose this server. The project runs and displays the page:

    Docker Java EE 7 Output

Enjoy!

This blog showed how how to deploy a Java EE 7 application to WildFly and Docker from Eclipse.

Is there any other way that you deploy to WildFly Docker container from Eclipse?

Docker Machine to Setup Docker Host – Tech Tip #78

containers, techtip, wildfly, ,

Running Docker containers typically involve three components:

  • Docker Client is a binary that accepts commands from the user and communicates back and forth with host
  • Docker Daemon runs on a host machine and does the heavy lifting of building, running, and distributing Docker containers
  • Docker Registry is SaaS platform for sharing and managing Docker images.Docker Hub is a public hub. Private registries can be easily setup as well, such as one by Artifactory. More on this in a subsequent blog.

Docker Client communicates with Daemon, either co-located on the same host, or on a different host. It requests the Daemon to pull an image from the repository using pull command. The Daemon then downloads the image from Docker Hub, or whatever registry is configured. Multiple images can be downloaded from the registry and installed on Daemon host.

Docker Architecture

 

In a typical development environment setup, Docker Client and Host/Daemon will be co-located on the same host machine. Even if they are on separate machines, it still require to login to the Host and setup Docker Daemon for that OS.

docker-logoDocker Machine takes you from zero-to-Docker on a host with a single command. This host could be your laptop, in the cloud, or in your data center. It creates servers, installs Docker on them, then configures the Docker client to talk to them.

This downloads the boot2docker VM, setup ssh keys, generate certificates, start the VM. It basically takes care of all the boring work so that you can focus on all the fun things.

This Tech Tip will show you to get started with Docker Machine and use it to setup Docker Host on Mac. It does not work on Windows yet because of github.com/docker/machine/issues/742.

Lets get started!

Install Docker Machine

  1. Download the appropriate binary from docs.docker.com/machine/#installation. Binary for Mac can be downloaded as:
  2. Verify the installation as:

Setup Mac Host using Docker Machine

  1. Docker Machine can be configured to use with multiple drivers, such as Amazon Web Services, Google Compute Engine, Microsoft Azure, and Oracle VirtualBox. On a developer laptop, Virtual Box is a convenient option.Virtual Box 4.3.20 is the minimum requirement. So make sure you’ve the correct version installed.
  2. Create a Docker Host using VirtualBox provider and call the machine as “mydocker”.Make sure ssh-keygen is in the PATH before invoking this command. On Mac, this is already in /usr/bin/ssh-keygen. On Windows, this can be installed as part of Git Bash.This can be done as:

    This downloads boot2docker with the Docker daemon installed, and will create and start a VirtualBox VM with Docker running.
  3. Find IP address of the machine as:

    Note down this IP address, this will be used for accessing the application.
  4. Check the status of running machine as:

    The * in the ACTIVE column indicates this is an active host.
  5. Check the environment of newly created machine as:

Setup Docker client to Communicate

  1. Setup your client to talk to this host as:

Run Java Application on Host

  1. Run Java EE 7 Application discussed in Java EE 7 Hands-on Lab on WildFly and Docker on this host as:
  2. Access the application at 192.168.99.101:8080/movieplex7/ and looks like:Docker Machine Output

Docker Machine Commands

Complete list of Docker Machine commands can be seen as:

Learn more about Docker Machine, Swarm, and Compose in this video:

Why would you use anything else other than Docker Machine to setup Docker host? How do you setup Docker Host otherwise?

Some useful references …

  • Full documentation
  • GitHub Repo
  • Issues
  • #docker-machine on freenode

Enjoy!

Docker Compose to Orchestrate Containers – Tech Tip #77

containers, javaee, , , ,

Docker Orchestration using Fig showed how to defining and control a multi-container service using Fig. Since then, Fig has been renamed to Docker Compose, or Compose for short.

First release of Compose was announced recently

From github.com/docker/compose

Compose is a tool for defining and running complex applications with Docker. With Compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running.

Docker Compose uses the same API used by other Docker commands and tools.

Docker Compose

This Tech Tip will rewrite Docker Orchestration using Fig blog to use Docker Compose. In other words, it will show how to run a Java EE 7 application that is deployed using MySQL and WildFly.

Lets get started!

Install Docker Compose

Install Compose as:

Docker Compose Configuration File

Entry point to Compose is docker-compose.yml. To begin with, docker-compose tool also recognizes fig.yml file name but shows the following message:

And if both fig.yml and docker-compose.yml are available in the directory then the following message is shown:

Use the same configuration file from the previous blog and rename to docker-compose.yml:

This YML-based configuration file has:

  1. Two containers defined by the name “mysqldb” and “mywildfly”
  2. Image names are defined using “image”
  3. Environment variables for the MySQL container are defined in “environment”
  4. MySQL container is linked with WildFly container using “links”
  5. Port forwarding is achieved using “ports”

Start, Verify, Stop Docker Containers

  1. All the containers can be started, in detached mode, by giving the command:

    And that shows the output as:
  2. Verify the containers as:
  3. Logs for the containers can be seen as:

    And shows the output as:
  4. Find the IP address of the host as:

    And access the application as:

    To see the output as:

    Or in the browser as:

    Docker Compose Output

  5. Stop the containers as:

    to see the output as:

Docker Compose Commands

Complete list of Docker Compose commands can be seen by typing docker-compose and shows the output as:

A subsequent blog will likely play with scale command.

Help for each command is shown by typing -h after the command name. For example, help for run command is shown as:

Enjoy!

Jenkins to Nexus with Git Polling – Tech Tip #76

devops, javaee

Build Binaries Only Once is a very important principle of Continuous Deployment (CD). However that blog guides you to build and deploy binaries to Nexus from your development machine. This is fine as a starting step where everything is locally contained on your laptop and you are just testing setup to figure out how things work. But everybody in the team having a local Nexus repository defies the purpose of a “shared repository”.  This is also against Continuous Integration (CI) where the source code committed by different team members checked out and build on a CI server. And CI is a fundamental requirement for Continuous Deployment. How do you set this up then?

You use a CI server to push binaries to Nexus.

There are a varety of CI servers in both open source and commercial range. Jenkins, Travis,  CruiseControl and Go are some of the popular ones in the open source land. They all have a commercial edition as well. Bamboo and AnthillPro are a couple of popular commercial-only offerings. This blog will use the simplest, most popular, and easiest to use Jenkins CI server.

The overall flow is shown in the diagram and explained after that.

Jenkins, GitHub, Nexus setup

 

The flow is:

  • Developers push code from inside firewall to GitHub
  • Jenkins is polling GitHub for code updates
  • Build the binaries and push the artifacts to Nexus (inside firewall)

This tech tip will show how to get started with Jenkins and push binaries to Nexus by polling the GitHub workspace. While polling is inefficient, it may be the only, and probably a simplified, choice.

In this setup, Jenkins and Nexus are both setup inside your firewall. This is a more common scenario as at least Nexus would be typically inside firewall. However Jenkins may be configured outside firewall in which case it will be able to archive artifacts but not directly push to Nexus. A proxy needs to be configured for Jenkins and Nexus to communicate in this case.

Lets get started!

Download and Start Jenkins Server

All information about Jenkins can be found at jenkins-ci.org.

  1. Download the latest WAR file:

    The total time to download will differ based upon your network speed.
  2. Start Jenkins as

    Starting and Accessing Jenkins provide more details about starting Jenkins and different configuration options.
  3. Once Jenkins is started, it can be accessed at localhost:8080 and shown as:

    Default Jenkins Output

Install Git Plugin

By default, Jenkins does not have the ability to handle Git workspace. Hopefully this will be fixed in a subsequent release because of INFRA-253. In the meanwhile, lets install Git plugin.

  1. Click on “Manage Jenkins”, “Manage Plugins”
  2. Click on “Available” tab, select “GIT Plugin” and click on “Install without restart”Git plugin installation in Jenkins
  3. Click on “Restart Jenkins …” to restart Jenkins.

Create a Jenkins Job

  1. Configure Maven at Configure System as explained here
  2. Create a new Jenkins job by going to localhost:8080/newJob
  3. Choose “Maven project” and give the name as shown:

    Jenkins New JobClick on “OK”.

  4. In “Source Code Management”, choose “Git” and specify the repository “https://github.com/javaee-samples/javaee7-simple-sample” as shown:
    Java EE 7 Simple Sample GitHub Repo in Jenkins
  5. In “Build Triggers”, choose “Poll SCM” and specify the schedule to poll the repo every 5 minutes as “H/5 * * * *”:

    techtip75-polling-schedule

  6. In “Build”, specify “deploy” target as shown:

    Maven target in Jenkins

Deploy SNAPSHOT to Nexus

Once the setup is done, deploying to Nexus is just a click or a poll away.

  1. Click on Build Now to build the job

    Jenkins Build Job

  2. Console output for the first job will show something like:

  3. Git Polling Log will show the last poll to your workspace repo. If there are any commits to the workspace after last job then a new job will be started.

This blog showed how to push binaries from Jenkins to Nexus using Git Polling.

Enjoy!

Announcing JBoss Champions

jboss, redhat, ,

JBoss Champion

JBoss Champions is a selected group of community members who are passionate advocate of JBoss technologies under a program sponsored by Red Hat. It fosters the growth of individuals that promote adoption of JBoss Projects and/or JBoss Products and actively share their deep technical expertise about it in the community, within their company and their customers or partners. This could be done in forums, blogs, screencasts, tweets, conferences, social media, whitepapers, articles, books, and other means.

Founding JBoss Champions

Proud and excited to announce the first set of JBoss Champions:

  1. Adam Bien (@AdamBien)
  2. Alexis Hassler (@alexishassler)
  3. Antonin Stefanutti (@astefanut)
  4. Antonio Goncalves (@agoncal)
  5. Bartosz Majsak (@majson)
  6. Francesco Marchioni (@mastertheboss)
  7. Geert Schuring (@geertshuring)
  8. Guillaume Scheibel (@g_scheibel)
  9. Jaikiran Pai
  10. John Ament (@JohnAment)
  11. Mariano Nicolas De Maio (@marianbuenosayr)
  12. Paris Apostolopoulos (@javapapo)

Many congratulations to the first set of JBoss Champions! Make sure to wish them using email, tweet, blog, or any other means that is available on their jboss.org profile. Give them a hug when you meet them at a conference. Ask them a tough JBoss question, challenge them! Invite them to your local Java User Group to give a talk about JBoss

Want to nominate a JBoss Champion?

Do you have it in you, and feel worthy of being a JBoss Champion?

Want to nominate yourself, or somebody else?

Send an email to .

Here are some likely candidates:

  • Senior developers, architects, consultants, academia who are using and promoting JBoss technologies using different means
    • Blogs and webinars
    • Publish articles on jboss.org, InfoQ, DZone, etc.
    • Social media
    • Talks at conferences and local JUGs/JBUGs
  • Implemented real-world projects using JBoss technologies
  • Actively answering questions in JBoss forums/StackOverflow
  • Authored a book on JBoss topic
  • Lead a JBoss User Group
  • Mentoring other community members and grooming champions

Make sure the nominee has a current jboss.org profile and has all the relevant details. Include any references that will highlight your value to the JBoss community. The complete list of criteria is clearly defined at jboss.org/champions.

Subscribe to the twitter feed of existing JBoss Champions.

Once again, many congratulations to the first set of JBoss Champions, and looking forward to many others. Submit your nomination today!

Bind WildFly to a different IP address, or all addresses on multihomed (Tech Tip #75)

techtip, wildfly,

Interface is a logical name, in WildFly parlance, for a network interface/IP address/host name to which sockets can be bound. There are two interfaces: “public” and “management”.

The “public” interface binding is used for all application related network communication (i.e. Web, Messaging, etc). The “management” interface is used for all components and services that are required by the management layer (i.e. the HTTP Management Endpoint).

By default, “public” interface is configured to listen on the loopback address of 127.0.0.1. So if you start WildFly as:

Then WildFly default page can be accessed as http://127.0.0.1:8080. Usually, /etc/hosts provide a mapping of 127.0.0.1 to localhost, and so the same page is accessible at http://localhost:8080. 8080 is the port where all applications are accessed.

On a multihomed machine, you may like to start WildFly and bind “public” interface to a specific IP address. This can be easily done as:

Now the applications can be accessed at http://192.168.1.1:8080.

For compatibility, -b 192.168.1.1 is also supported but -b=192.168.1.1 is recommended.

Or, if you want to bind to all available IP addresses, then you can do:

Similarly, by default, WildFly can be managed using Admin Console at http://127.0.0.1:9990. 9990 is the management port.

WildFly “management” interface can be bound to a specific IP address as:

Now Admin Console can be accessed at http://192.168.1.1:9990.

Or, bind “management” interface to all available IP addresses as:

You can also bind to two specific addresses as explained here.

Of course, you can bind WildFly “public” and “management” interface together as:

Learn more about it Interface and Port Configuration in WildFly. And more about these switches in Controlling the Bind Address with -b.

Build Binaries Only Once for Continuous Deployment

devops, , ,

What is Build Binaries Only Once?

One of the fundamental principle of Continuous Delivery is Build Binaries Only Once, or in short BBOO. This means that the binary artifacts should be build once, and only once. These artifacts should then be stored in a repository manager, such as a Nexus Repository. Subsequent deploy, test, and release cycles should never attempt to build this binary again and instead reuse this binary. This ensures that the exact same binary has gone through all different test cycles and delivered to the customer.

Several times binaries are rebuilt during each testing phase using a specific tag of the workspace, and considered the same. But that is still different! This might turn out to be the same but that’s more incidental. Its more likely not same because of different environment configurations. For example, development team might be using JDK 8 on their machine and the test/staging might be using JDK 7. There are a multitude reasons because of which the binary artifacts could differ. So it’s very essential to build binaries only once, store them in a repository, and make them go through different test, staging, and production cycle. This increases the overall confidence level of delivery to the customer.

Build Binaries Only Once

This image shows how the binaries are built once during Build stage and stored on Nexus repository. There after, Deploy, Test, and Release stages are only reading the binary from Nexus.

The fact that dev, test, and staging environments differ is a different issue. And we’ll deal with that in a subsequent blog.

How do you setup Build Binaries Only Once?

For now, lets look at the setup:

  1. A Java EE 7 application WAR file is built once
  2. Store in a Nexus repository, or .m2 local repository
  3. Same binary is used for smoke testing
  4. Same binary is used for running full test suite

The smoke test in our case will be just a single test and full suite has four tests. Hopefully this is not your typical setup in terms of the number of tests, but at least you get to see how to setup everything.

Also only two stages of testing, smoke and full but the concept can be easily extended to add other stages. A subsequent blog will show a full blown deployment pipeline.

Lets get started!

  1. Check out a trivial Java EE 7 sample application from github.com/javaee-samples/javaee7-simple-sample. This is a typical Java EE application with REST endpoints, CDI beans, JPA entities.
  2. Setup a local Nexus Repository and deploy a SNAPSHOT of the application to it as:

    By default, Nexus repository is configured on localhost:8081/nexus. Note down the host/port if you are using a different combination. Also note down the exact version number that is deployed to Nexus. By default, it will be 1.0-SNAPSHOT.

    You can also deploy a RELEASE to this Nexus repository as:

    Note down whether you deployed SNAPSHOT or RELEASE.

    In either case, you can also specify -P release Maven profile and sources and javadocs will be attached with the deployment. So if RELEASE is deployed as:

    Then sources and javadocs are also attached.

  3. Check out the test workspace from github.com/javaee-samples/javaee7-simple-sample-test. Make the following changes in this project:
    1. Change nexus-repo property to match the host/port of the Nexus repository. If you used the default installation of Nexus and deployed a RELEASE, then nothing needs to be changed.By default, Nexus has one repository for SNAPSHOTs and another for RELEASEs. The workspace is configured to use RELEASE repository. If you deployed a SNAPSHOT, then “releases” in nexus-repo needs to be changed to “snapshots”to point to the appopriate repository.
    2. Change javaee7-sample-app-version property to match the version of the application deployed to Nexus.
  4. Start WildFly and run smoke tests as:

    This will run all files ending in “SmokeTest”. ShrinkWrap and Arquillian perform the heavy lifting of resolving the WAR file from Nexus and using it for running the tests:

    Running the smoke tests will show the results as:

  5. Run the full tests as:

    This will run all files included in your test suite and will show the results as:

    In both cases, smoke tests and full tests are using the binary that is deployed to Nexus.

Learn more about your toolset for creating this simple yet powerful setup:

arquillian-logo nexus-logowildfly-logo

 

Here are some other blogs coming in this series:

  • Use a CI server to deploy to Nexus
  • Run tests on WildFly running in a PaaS
  • Add static code coverage and code metrics in testing
  • Build a deployment pipeline

Enjoy!