- Home
- >
- Software Development
- >
- Deploy Microservices on Kubernetes Through Rudr – InApps 2022
Deploy Microservices on Kubernetes Through Rudr – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Deploy Microservices on Kubernetes Through Rudr – InApps in today’s post !
Read more about Deploy Microservices on Kubernetes Through Rudr – InApps at Wikipedia
You can find content about Deploy Microservices on Kubernetes Through Rudr – InApps from the Wikipedia website
The Open Application Model (OAM) specification defines how to compose modern applications as microservices. Launched last week, Rudr is a reference implementation of OAM from Microsoft targeting Kubernetes.
Applications targeting Rudr have three elements: Components, Configuration, and Traits:
- Components define one or more container images targeting an OS and their hardware requirements such as CPU, RAM, and storage.
- Configuration deals with runtime parameters such as environment variables.
- Traits declare runtime attributes such as volumes, ingress, and scaling.
In this tutorial, we’ll explore the concepts of Rudr by mapping an existing app to the OAM specifications. We will take an existing containerized web application, model it for Rudr, and deploy it on Kubernetes running in Minikube. Rudr is a collection of Kubernetes CRDs that map the OAM artifacts to Kubernetes objects. Make sure you have kubectl installed on your machine.
You can build the container from the source code available on this GitHub repository. But you can try this tutorial by using the public image that I already pushed to Docker Hub.
The node.js-based web application and MongoDB container images are Components of our deployment. The MongoDB connection string sent as an environment variable forms the simple Configuration. Finally, we will configure ingress as a Trait.
Before going ahead, install the Ingress addon on Minikube.
minikube addons enable ingress |
kubectl get pods —all–namespaces –l app.kubernetes.io/name=nginx–ingress–controller |
Installing Rudr
We will start by deploying Rudr Helm Chart. Download the latest beta of Helm3 and add it to the path. Note that Helm3 doesn’t have Tiller running as the server.
Clone the Rudr repo that has the Helm Chart and install it.
helm install rudr ./charts/rudr —wait |
You can verify the installation by checking the CRDs and the Pod.
kubectl get crds –l app.kubernetes.io/part–of=core.oam.dev |
kubectl get deployment rudr |
Declaring the Rudr App Artifacts
We will now create the definition of two components from the MongoDB container image and the web container image. The node.js container image is a simple todo app based on the Express framework which stores the tasks in MongoDB.
Let’s call these components backend and frontend.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | apiVersion: core.oam.dev/v1alpha1 kind: ComponentSchematic metadata: name: backend annotations: version: “1.0.0” description: Mongodb Database spec: workloadType: core.oam.dev/v1alpha1.SingletonServer containers: – name: backend ports: – containerPort: 27017 name: mongo image: mongo —– apiVersion: core.oam.dev/v1alpha1 kind: ComponentSchematic metadata: name: frontend annotations: version: “1.0.0” description: Node.js Web Server spec: workloadType: core.oam.dev/v1alpha1.Server parameters: – name: database type: string required: false containers: – name: frontend ports: – containerPort: 3000 name: http image: janakiramm/todo:v1 env: – name: DB value: db fromParam: database |
The first interesting aspect about the above definitions is the workload type. Since both are long-running processes listening on a specific port, they are defined as Server. But MongoDB container is always run as a single Pod, which translates to SingletonServer.
The node.js web app checks the environment variable DB which if found empty will be populated with string “db”. The web app declaration contains the parameters section followed by the env section that retrieves the value defined in the database parameter.
Both components have the ports mentioned in the declaration.
This artifact is expected to be created by the developers as a part of the build process.
Once the ComponentSchematic is in place, we will define the Configuration and Traits.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | apiVersion: core.oam.dev/v1alpha1 kind: ApplicationConfiguration metadata: name: todo–app spec: components: – name: backend instanceName: mongo – name: frontend instanceName: fe parameterValues: – name: database value: mongo traits: – name: ingress parameterValues: – name: hostname value: todo.example.com – name: service_port value: 3000 – name: path value: / |
The above configuration does two important things — defining the instance name for each component and setting the environment variable expected by the web app. Next, it defines the ingress rule for accessing the web application.
It’s time to deploy the Components, Configuration, and Traits.
kubectl create –f components.yaml |
This operation doesn’t result in the creation of Kubernetes Pods. The deployment takes place only when the Rudr Configuration associated with the Components is deployed.
Let’s submit the Configuration to Kubernetes.
kubectl create –f configuration.yaml |
The Pods will now get deployed. The default Namespace has three Pods – rudr, frontend, and backend.
Since the Configuration has the definition of an Ingress, the Pods and Service belonging to the web app are associated with the Ingress.
To access the web application from the browser through the Ingress, add the IP address of the Minikube to /etc/hosts file.
We are now ready to access the app by visiting the URL todo.example.com.
Janakiram MSV’s Webinar series, “Machine Intelligence and Modern Infrastructure (MI2)” offers informative and insightful sessions covering cutting-edge technologies. Sign up for the upcoming MI2 webinar at http://mi2.live.
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
Feature image by Alexas_Fotos from Pixabay.
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.
