|
Note
|
This repository contains the guide documentation source. To view the guide in published form, view it on the Open Liberty website. |
Explore how to deploy microservices to Kubernetes Engine (GKE) on Google Cloud Platform (GCP).
You will learn how to deploy two microservices in Open Liberty containers to a Kubernetes cluster on Google Cloud Platform.
Kubernetes is an open source container orchestrator that automates many tasks involved in deploying, managing, and scaling containerized applications. If you would like to learn more about Kubernetes, check out the Deploying microservices to Kubernetes guide.
There are different cloud-based solutions for running your Kubernetes workloads. A cloud-based infrastructure enables you to focus on developing your microservices without worrying about low-level infrastructure details for deployment. Using a cloud helps you to easily scale and manage your microservices in a high-availability setup.
<IBM Cloud Kubernetes Service (IKS) is part of IBM’s public cloud offerings. It provides a hosted Kubernetes cluster where you can deploy your microservices. You will use it with IBM Cloud Container Registry, a private registry used to store and distribute your container images.>
The two microservices you will deploy are called system and inventory. The system
microservice returns the JVM system properties of the running container.
It also returns the pod’s name in the HTTP header, making replicas easy to distinguish
from each other. The inventory microservice adds the properties from the system
microservice to the inventory. This demonstrates how communication can be established
between pods inside a cluster.
You will use Helm to deploy these microservices to Kubernetes Engine using Open Liberty Helm charts. Helm is a package manager for Kubernetes. It uses templates to generate Kubernetes yaml files and then deploys and manages them as releases in your cluster.
Before you begin, the following additional tools need to be installed:
-
Docker: You need a containerization software for building containers. Kubernetes supports various container types, but you will use Docker in this guide. For installation instructions, refer to the official Docker documentation.
-
kubectl: You need the Kubernetes command-line tool
kubectlto interact with your Kubernetes cluster. See the official Install and Set Up kubectl documentation for information about downloading and setting upkubectlon your platform. -
Helm: You will use the Helm Command Line Interface (CLI) to install Helm’s Tiller to your Kubernetes cluster and to manage releases in your Kubernetes cluster. Download Helm v2.13.1 and see the official Installing Helm documentation for information about setting up
helmon your platform. -
Google SDK You will use the Google SDK to interact with Google Cloud Platform. To install the Google SDK for your platform, run one of the following commands:
Open command prompt as an administrator and run the following command.
powershell -command "Set-ExecutionPolicy Unrestricted; iex(New-Object Net.WebClient).DownloadString('https://clis.cloud.ibm.com/install/powershell')"curl -fsSL https://clis.cloud.ibm.com/install/osx | shcurl -fsSL https://clis.cloud.ibm.com/install/linux | sh-
IBM Cloud Container Registry plug-in: To install the container registry plug-in, run the following command:
ibmcloud plugin install container-registry
Before you can deploy your microservices, you must create a Kubernetes cluster on Kubernetes Engine.
Log in to IBM Cloud by using the ibmcloud command line.
When you are prompted to select a region, choose us-south. This allows you to create a
free cluster, which is limited to specific regions. Note that if you are using a federated
user ID, you will have to use the --sso flag to get a one-time code for single sign-on.
gcloud init
gcloud config set compute/zone <<compute zone>><< To create a Kubernetes cluster, you need Administrator access to IBM Cloud Kubernetes Service.
To confirm that you have Administrator access, navigate to the IBM Cloud Dashboard.
Then, navigate to Manage > Access (IAM) > Users > [Your Username] > Access Policies and
confirm that Administrator is listed as a policy for all resources in the account or
for the Kubernetes service. >>
Once you have confirmed that you have appropriate permissions, use the following command to provision a cluster.
gcloud container clusters create guide-clusterThis command provisions a new cluster.
The 'machine-type' flag was not specified. So a free cluster will be created.
Creating cluster...
OKCheck the current status of your cluster.
ibmcloud ks clustersWait until your cluster is in the normal state before proceeding. It will start off in the deploying state.
Creating cluster guide-cluster in us-central1-a… Cluster is being health-checked…⠶ ---
After creating a cluster, you need to get authentication credentials to interact with the cluster.
Configure kubectl by authenticating for the cluster.
gcloud container clusters get-credentials guide-cluster ---
Fetching cluster endpoint and auth data.
kubeconfig entry generated for guide-cluster.In this section, you will learn how to deploy two microservices in Open Liberty containers to a Kubernetes cluster on Kubernetes Engine. You will build and containerize the system and inventory microservices, push them to a container registry and, then deploy them to your Kubernetes cluster.
The first step of deploying to Kubernetes is to build and containerize your microservices.
The starting Java project, which you can find in the start directory, is a multi-module Maven
project. It’s made up of the system and inventory microservices. Each microservice resides in its own directory, start/system and start/inventory. Each of these directories also contains a Dockerfile, which is necessary for building Docker images. If you’re unfamiliar with Dockerfiles, check out thehttps://openliberty.io/guides/containerize.html[Containerizing Microservices^] guide.
To build these microservices, navigate to the start directory and run the following command:
mvn packageNext, run the docker build commands to build container images for your application:
docker build -t system:1.0-SNAPSHOT system/.
docker build -t inventory:1.0-SNAPSHOT inventory/.The -t flag in the docker build command allows the Docker image to be labeled (tagged) in the name[:tag] format.
The tag for an image describes the specific image version. If the optional [:tag] tag is not specified, the latest tag is created by default.
During the build, you’ll see various Docker messages describing what images are being downloaded and built. When the build finishes, run the following command to list all local Docker images:
docker imagesVerify that the system:1.0-SNAPSHOT and inventory:1.0-SNAPSHOT images are listed among them, for example:
REPOSITORY TAG
system 1.0-SNAPSHOT
inventory 1.0-SNAPSHOT
open-liberty latestIf you don’t see the system:1.0-SNAPSHOT and inventory:1.0-SNAPSHOT images, then check the Maven
build log for any potential errors.
Pushing the images to a registry enables the cluster to create pods by using your container images. << Since it’s a private repository, only users with access to your IBM Cloud account will have access to these images. >>
The registry you will use is called Container Registry. It is a private container image registry that runs on Google Cloud.
Configure Docker to use the gcloud command-line tool to authenticate requests to Container Registry.
gcloud auth configure-dockerNext, tag your container images with the relevant data about your registry.
Remember to replace [project-id] with the ID of the project you created earlier in the guide.
liberty-microservice-on-gcp
docker tag system:1.0-SNAPSHOT gcr.io/[project-id]/system:1.0-SNAPSHOT
docker tag inventory:1.0-SNAPSHOT gcr.io/[project-id]/inventory:1.0-SNAPSHOTFinally, push your images to the registry. Remember to replace [project-id] with the ID of the project you created earlier in the guide.
docker push gcr.io/[project-id]/system:1.0-SNAPSHOT
docker push gcr.io/[project-id]/inventory:1.0-SNAPSHOTUse kubectl to deploy the system microservice. Remember to replace [project-id] with the ID of the project you created earlier in this guide.
kubectl create deployment --image=gcr.io/[project-id]/system:1.0-SNAPSHOT system-app
kubectl expose deployment system-app --type NodePort \
--port 9080 --target-port 9080Use kubectl to deploy the inventory microservice. Remember to replace [project-id] with the ID of the project you created earlier in this guide.
kubectl create deployment --image=gcr.io/[project-id]/inventory:1.0-SNAPSHOT inventory-app
kubectl expose deployment inventory-app --type NodePort \
--port 9080 --target-port 9080UPDATED TILL HERE
The service used to expose our deployments has a type of NodePort. This means you can
access these services from outside of your cluster via a specific port. In this case,
since nodePort is not specified, the ports are randomized so you must obtain
the ports before making requests to the services. You must also obtain the public IP address
of our cluster. Note that there are other ways to expose your services such as using a
LoadBalancer service type or using an Ingress. In production, you would most likely
use an Ingress.
First, find the current context of your cluster.
kubectl config current-contextTake note of the context shown in the command’s output.
guide-clusterThen, substitute the context into the following command to get the public IP address of your cluster.
ibmcloud ks workers [current-context]Take note of the Public IP in the command’s output. This will be the hostname you
substitute into commands later in this guide.
OK ID Public IP Private IP Machine Type State Status Zone Version kube-hou02-pad15e5f9-w1 172.173.65.24 10.77.198.71 free normal Ready hou02 1.10.11_1538*
Get the node port of the system microservice.
kubectl get service system-service -o jsonpath="{.spec.ports[0].nodePort}{'\n'}"Get the node port of the inventory microservice.
kubectl get service inventory-service -o jsonpath="{.spec.ports[0].nodePort}{'\n'}"Take note of the IP address and ports. They are required to make the HTTP requests.
To make a request to the system and inventory microservices, curl or visit the
following URLs to access your microservices, substituting the appropriate hostname and node ports:
-
http://[hostname]:[system-node-port]/system/properties -
http://[hostname]:[inventory-node-port]/inventory/systems/system-service
The first URL returns system properties and the name of the pod in an HTTP header called X-Pod-Name.
To view the header, you can use the -I option in the curl when making a request to http://[hostname]:[system-node-port]/system/properties.
The second URL adds properties from system-service to the inventory.
A few tests are included for you to test the basic functionality of the microservices. If a test failure
occurs, then you might have introduced a bug into the code. To run the tests, wait for all pods to be
in the ready state before proceeding further. The default properties that are defined in the pom.xml are:
| Property | Description |
|---|---|
|
IP or hostname for your cluster |
|
Name of the Kubernetes Service wrapping the |
|
The NodePort of the Kubernetes Service |
|
The NodePort of the Kubernetes Service |
Use the following command to run the integration tests against your cluster. Substitute
[hostname], [system-node-port] and [inventory-node-port] with the appropriate values.
mvn verify -Ddockerfile.skip=true -Dcluster.ip=[hostname] -Dsystem.node.port=[system-node-port] -Dinventory.node.port=[inventory-node-port]The dockerfile.skip parameter is set to true in order to skip building a new container image.
If the tests pass, you’ll see an output similar to the following for each service respectively:
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running it.io.openliberty.guides.system.SystemEndpointTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.673 sec - in it.io.openliberty.guides.system.SystemEndpointTest
Results:
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running it.io.openliberty.guides.inventory.InventoryEndpointTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.222 sec - in it.io.openliberty.guides.inventory.InventoryEndpointTest
Results:
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0Optionally, you might want to make changes to your microservice and learn how to redeploy
the updated version of your microservice. In this section, you will bump the version of
the system microservice to 2.0-SNAPSHOT and redeploy the new version of the microservice.
You can redeploy a microservice using Helm to upgrade the release.
Use Maven to repackage your microservice:
mvn packageNext, build the new version of the container image as 2.0-SNAPSHOT:
docker build -t system:2.0-SNAPSHOT system/.Since you built a new image, it will have to be pushed to the repository again.
Tag your container image with the relevant data about your registry.
docker tag system:2.0-SNAPSHOT us.icr.io/[your-namespace]/system:2.0-SNAPSHOTPush your image to the registry.
docker push us.icr.io/[your-namespace]/system:2.0-SNAPSHOTUse Helm to redeploy the system microservice.
helm upgrade ^
--set image.repository=us.icr.io/[your-namespace]/system ^
--set image.tag=2.0-SNAPSHOT ^
--set image.pullSecret=default-us-icr-io ^
--set service.name=system-service ^
--set service.port=9080 ^
--set service.targetPort=9080 ^
--set ssl.enabled=false ^
system-app ibm-charts/ibm-open-libertyhelm upgrade \
--set image.repository=us.icr.io/[your-namespace]/system \
--set image.tag=2.0-SNAPSHOT \
--set image.pullSecret=default-us-icr-io \
--set service.name=system-service \
--set service.port=9080 \
--set service.targetPort=9080 \
--set ssl.enabled=false \
system-app ibm-charts/ibm-open-libertyUse the following command to find the name of the pod that is running the system microservice.
kubectl get podsNAME READY STATUS RESTARTS AGE
inventory-app-ibm-open-l-5c586b9cfc-h5zmg 1/1 Running 0 23s
system-app-ibm-open-libe-84976bccfb-r22lj 1/1 Running 0 2m15smObserve that in this case the system microservice is running in the pod called system-app-ibm-open-libe-84976bccfb-r22lj. Substitute the name of your pod into the following command to see more details about the pod.
kubectl describe pod [pod-name]View the events at the bottom of the command’s output. Observe that the pod is using the new container image system:2.0-SNAPSHOT.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 47s default-scheduler Successfully assigned default/system-app-ibm-open-libe-84976bccfb-r22lj 172.173.65.24
Normal Pulling 47s kubelet, 172.173.65.24 pulling image "registry.ng.bluemix.net/[your-namespace/system:2.0-SNAPSHOT"
Normal Pulled 40s kubelet, 172.173.65.24 Successfully pulled image "registry.ng.bluemix.net/[your-namespace]/system:2.0-SNAPSHOT"
Normal Created 40s kubelet, 172.173.65.24 Created container
Normal Started 39s kubelet, 172.173.65.24 Started containerWhen you no longer need your deployed microservices, you can delete them with the following Helm commands:
helm delete --purge system-app
helm delete --purge inventory-appUninstall Tiller from your cluster by running the following Helm command.
helm resetLog out of your container registry.
docker logout us.icr.ioRemove your IKS cluster.
ibmcloud ks cluster-rm guide-clusterLog out of the ibmcloud command line tool.
ibmcloud logoutYou have just deployed two microservices to IBM Cloud. You have learned to use Helm to install your microservices on a Kubernetes cluster using the Open Liberty helm chart.