Jumpstart: Deploy a Java Microservices Application to Code Engine¶
Attention: Outdated! Doesn't work fully correctly anymore!
Objectives¶
The workshop addresses the topic containerized applications on IBM Cloud Code Engine. (GitHub project)
After you complete this workshop, you'll have a basic understanding of the following:
- Deploy an existing Java microservices
containerizedapplication example toCode Engine- See the usage of the
IBM Cloud Code Engine CLI
- See the usage of the
- Understand internal and external
HTTP/HTTPS routingbetween the microservices - Use the
Out-Of-The-Boxmonitoring for the example application - Use the
Out-Of-The-Boxlogging for the example application
The scope of this workshop is not to explain every aspect of running an application or job on
Code Engine. It's just about containerized applications.
Here is a 1-hour YouTube live stream on IBM Developer
Prerequisites¶
- To run this workshop, you will need to create an IBM Cloud
PayAsYouGoaccount (or log in to your existing account).
Code Enginehas afree tierper month, and we expect, if you haven't used thatfree tierin current month, you can execute the workshop without creating any additional costs. For the monitoring and logging we will use free lite plans for the service instances IBM Cloud Monitoring and IBM Cloud Log Analysis.
- You should have a basic understanding of containerized applications
Estimated time and level¶
| Time | Level |
|---|---|
| 1 h | beginners |
Architecture¶
This
workshopis related to the Cloud Native Starter project. In the workshop we use a customized version of the security application example.
The example application simply shows articles protected with an Identity and Access Management.
In the following picture you see the frontend with the articles and the valid user alice is logged on.

The following diagram shows the architecture of the example application. There is a web-app frontend application that serves the JavaScript/Vue.js code to the browser. The web-app code running in the browser invokes a REST API of the web-api microservice. The web-api microservice in turn invokes a REST API of the articles microservice. Keycloak is used for the Identity and Access Management of that microservices based application. To see the results in the web application, users need to be authenticated and they need to have the role user.
The image below shows the dependencies of the example:

- External and internal routing
In our context it's useful to have a basic understanding of the routing for example application. Based on the functionality of the application, we need three external routes for the example application.
Each external route communication will be automatically secured with a TLS Encryption created by Code Engine using Let's encrypt. The three applications are the web-app which will be loaded into the browser, the Keycloak that must be available for the authentication/authorization to our application and for potential configuration the Identity and Access Management and finally the web-api microservice which provides the articles data and will be invoked be the web-app.
The articles microservice doesn't need to be invoked from external, so it's configured to provide only an internal route, which is used by the web-api microservice to get the articles from.
- Basics about the deployment
For an easy deployment prebuild containers were created and pushed to a Quay container registry. In the following table you see the application/container, the exposed routes, uses of TLS Encryption, the scale to zero configuration, the container registry where the prebuild container comes from, the configuration for vCPU and Memory in GB and the min/max Instances for the applications.
| Application | Route | TLS Encryption | Scale to zero | Container Registry | vCPU | Memory | min Instances | max Instances |
|---|---|---|---|---|---|---|---|---|
| web-app | external | yes | yes | Quay | 0.5 | 1 GB | 0 | 1 |
| keycloak | external | yes | no | Quay | 0.5 | 1 GB | 1 | 1 |
| web-api | external | yes | yes | Quay | 0.5 | 1 GB | 0 | 1 |
| articles | internal | no (mTLS coming sone) | yes | Quay | 0.25 | 0.5G GB | 0 | 1 |
The Keycloak application for the Identity and Access Management isn't configured to scale to zero, because the application is stateful and contains the realm configuration, which will be deleted, if you would restart the application.
Note: The project also contains the source code, that you can use to customize to your an own version of the microservices based example application.
About this workshop¶
Agenda¶
These are the sections of this workshop, go through all of them in sequence, start with Lab 1. Setup the example application :
- Setup the example application
- Inspect the
Code Engineproject - Monitoring of the applications
- Logging of the applications
- Cleanup the example application
Optional Labs:
- Run the example application locally
- Push the example containers to a container registry
- Use IBM Cloud App ID for the example application
- Use Code Engine to build a container image
Compatibility¶
The workshop uses following IBM Cloud Services:
- IBM Cloud Code Engine
- IBM Cloud Monitoring (lite plan)
- IBM Cloud Log Analysis (lite plan)
IBM CloudCode Engine` is built on Open Source](https://en.wikipedia.org/wiki/Open_source) technologies:
Technology Used¶
The example microservices application example is built with the following technologies/tools/frameworks`.
- Microservices architecture
- Keycloak
- Jakarta EE
- MicroProfile
- Quarkus
- Vue.js
- NGINX
- git 2.24.1 or higher
- yarn 1.22.4 or higher
- Node.js v14.6.0 or higher
- Apache Maven 3.6.3
Credits¶
- Thomas Südbröcker
- Niklas Heidloff (Feedback and Cloud Native Starter project)
- Simon Moser (Feedback)
- Doug Davis (Feedback)
Additional resources¶
-
IBM CLoud Code Engine:
-
Cloud Native Starter example source code:
-
Keycloak
-
Quarkus
-
Vue.js
