That blog post is structured in:
- Setup and configuration of Visual Studio Code
- Run the Authors microservice in the remote development container
- Debug the Authors microservice in the remote development container
That blog post is structured in:
This is a very short blog post about the usage of a Docker container in detached and attached mode. Some times participants in workshops want to reconnect to a docker container, because they closed their terminal session with the container which was in an interactive mode and they want to reconnect to their exiting container image.
In that blog post I want to point out the awesome topic, how to automate the deployment of a Microservice using a delivery pipeline on IBM Cloud.
Maybe you already know Niklas, Harald and I made the great project called Cloud Native Starter. That project includes a Hands-on workshop that is called “Build a Java Microservice and deploy the Microservice to Kubernetes on IBM Cloud”. In Lab 4 you have to deploy the Authors Microservice to Kubernetes on IBM Cloud. Sometimes we have limited time in workshops. The limited time is the reason why we want to reduce the manual effort for students in a workshop to a minimum, therefor we took the IBM® Cloud Continuous Delivery and I created a repeatable way with minimal human interaction. The delivery pipeline contains sequences of stages which retrieve inputs and run jobs, such as builds, and deployments.
That image shows two stages, one stage is called FETCH and the other DEPLOY_SERVICES. The FETCH stages contains a job called Fetch code and the DELOY_SERVICES has two jobs one for build and one for deployment.
With the realization of the automated setup for the creation of the toolchain, you can just press the button Create toolchain in the GitHub project and follow a guided wizard to deploy the Authors Microservice.
The Cloud Native Starter project now contains the new great topic, the development of Reactive Microservices with Java, quarkus, MicroProfile and Vue.js as front-end. The Reactive example implementation runs on minikube, local OpenShift and on IBM Cloud Kubernetes.
But what does reactive mean? Here is an extract of the definition in The Reactive Manifesto.
“Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.”
But be aware, our example is not a full Reactive System it shows reactive programming techniques.
Note: To understand the difference between these two topics, that badge on cognitiveclass is useful Reactive Architecture: Introduction to Reactive Systems.
In this blog post I want to share, how you deploy that awesome Reactive example to a free IBM Cloud Kubernetes Cluster and using the free quota of the IBM Cloud Container Registry. We avoid for the setup that you have to use any paid IBM Cloud services, because you want just to see how the Reactive example works on IBM Cloud.
To create a free Cluster you need a feature code to create a Trial Account or you create a pay as you go account and you only use the free services of IBM Cloud.
That is the major architecture of the Reactive example. Three Java Microservices, one Vue UI application and two infrastructure components running on Kubernetes.
But what is reactive programming in more detail? If you want to get more details of the Reactive topic, just visit the blog post Development of Reactive Applications with Quarkus from Niklas Heidloff and if you want to explore the setup for local OpenShift take a look into the blog post Cloud Native Starter on Red Hat OpenShift 4 from Harald Uebele.
Usually, when you use an existing container image to create your own customized configuration, you don’t have deep knowledge how that container image is built, and you have questions like: “What are the folder rights?”, or “What are the installation paths of applications?”, or other information you need to customize the container image to your needs.
You can learn about the existing image, when you visit the GitHub or Dockerhub project of that image (for example: links to GitHub “docker-library / repo-info” and Dockerhub “jenkins repo-info” project of Jenkins). But to ensure that your customization works, you have to run and access the running container in the commandline mode and verify your changes step by step running the image in Kubernetes.
Why do I say “non-productive”? Because of the free IBM Cloud Kubernetes Cluster , which will be deleted after 30 days. Surely you can also deploy WordPress for production usage, when you deploy to a paid cluster. But maybe you got a feature code for free IBM Cloud at a conference or at a hackathon and you want play around with IBM Cloud, that could be one option.
You can find the instructions for the deployment here: Scalable WordPress deployment on Kubernetes Cluster. By the way, the project is under Apache 2.0 license.
In this blog post I want to shortly highlight the topic central management of billing and resource usage tracking across multiple accounts. I think it is good to know that topic, even if you will currently not use it.
I didn’t use IBM Cloud Enterprise until now, but is great to know that this is possible. This organisational topic is (more or less 😉 ) related to one of my older blog posts “What are major elements to organize my services, apps and devices in IBM Cloud?”
The announcement was in Juli 2019 :
“Now you can organize multiple IBM Cloud accounts in flexible hierarchical groups.”
For more details please visit that blog post introducing IBM Cloud Enterprises.
In that blog post I want to highlight how I did my first configuration of the App Identity and Access Adapter for Istio Mixer in my Cloud Native Starter system on a free IBM Cloud Kubernetes cluster.
Once more I want to highlight, that the cool thing from my perspective of App Identity and Access Adapter is “that the adapter can be configured to work with any OIDC compliant identity provider, which enables it to control authentication and authorization policies in all environments including frontend and backend applications. And, it does it all without any change to your code or the need to redeploy your application.”
I did a combination of the steps from the videos inside the IBM Cloud App ID service documentation and of the videos from Anton Aleksandrov. With that in mind I applied needed changes of that configurations in the videos to run it on our Cloud Native Starter setup.
In that blog post I want to highlight that I started to integrate the open source App Identity and Access Adapter for Istio Mixer into our open source Cloud Native Starter sample that uses the free IBM Cloud Kubernetes cluster setup with a manual Istio installation.
The cool thing from my perspective of the App Identity and Access Adapter is “that the adapter can be configured to work with any OIDC compliant identity provider, which enables it to control authentication and authorization policies in all environments including frontend and backend applications. And, it does it all without any change to your code or the need to redeploy your application.” I had a short problem with the installation you can find on stackoverflow.
Today, just a very short note. You should be aware of opentracinqZipkin when you use MicroProfile OpenTracing with OpenLiberty, because I noticed with the update to MicroProfile 3.0 I had a problem with usr:opentracinqZipkin-0.31. I created an issue on OpenLiberty.
“MicroProfile 2.1 includes
mpOpenTracing-1.2. MicroProfile 3.0 includes
mpOpenTracing-1.3. Please make sure you are using the Zipkin sample built for
mpOpenTracing-1.3. It can be downloaded at https://github.com/WASdev/sample.opentracing.zipkintracer/releases/tag/1.3”
I got that solution from Felix Wong.
But inside the server.xml will not reflect the version change, it will remaining the same feature name usr:opentracingZipkin-0.31.
<server description=”OpenLiberty Server”><featureManager><feature>microProfile-3.0</feature><feature>webProfile-8.0</feature><feature>usr:opentracingZipkin-0.31</feature></featureManager><httpEndpointid=”defaultHttpEndpoint”host=”*”httpPort=”8080″httpsPort=”9443″/>….</server>
I hope this was useful for you and let’s see what’s next?
#ibmdeveloper, #MicroProfile, #Java, #OpenTracing