Deploying web applications to Kubernetes doesn't have to be complex. Follow these steps to leverage the power of Monokle to deploy successfully to Civo Cloud on the first try.
In a previous [blog post](https://monokle.io/blog/get-started-validate-kubernetes-resources), we talked about developers deploying a Kubernetes application. They may face challenges such as handling high traffic and maintaining availability during peak times. They also have to ensure security and compliance along with set up monitoring and logging. All this requires using multiple tools.
Technologists prefer to have validation enabled for YAML syntax or Kubernetes schema. To be able to preview Helm/Kustomize and visualize resource relationships would help them avoid vulnerabilities and maintain consistent application performance.
With the right approach, the application can be deployed with high availability, scalability, and security. Hence, many engineers choose cloud-native managed Kubernetes platforms like EKS, AKS, GKE, and Civo to deploy their applications as most of these things are managed by the platform. Their end goal is the same, deploy successfully, securely, and as fast as possible. [Civo](https://www.civo.com/) has become a developer's (and ours too) favorite platform to deploy Kubernetes clusters because of blazing fast cluster launch time and transparent pricing.
In this post, we'll deploy an [e-commerce](https://microservices-demo.github.io/deployment/kubernetes-start.html) application to a cluster on Civo Cloud. We'll also show how [Monokle](https://github.com/kubeshop/monokle) makes it easier to deploy applications to remote clusters. Lastly, we'll see how you can leverage the power of Monokle to get visibility into your deployments.
## Why Monokle?
After the application is developed, we need to create manifests to deploy it to the cluster. Creating manifests that are error-proof and deploying them securely is challenging. There are many tools available to help us with YAML but none of them address all the complex layers. It is not mandatory to check for vulnerabilities. But we do not want to waste our or your time by first deploying something that doesn’t work or doesn’t follow the company’s best practices.
Context switching is again a challenge after the application is deployed. Managing, monitoring, troubleshooting the application, and making changes to the manifest corresponding to application requirements is difficult. Constant changes in the environment and the application imply reviews and more troubleshooting. The manifest has its lifecycle that could make us invest more time. We would prefer all the information to be easily and quickly available without investing much time in executing commands or learning multiple tools.
With Monokle you can create, validate or manage manifests and configure multiple local as well as remote clusters for deployment. Monokle provides three ways to deploy applications: Direct YAML manifests, Kustomize, and Helm charts. This way a developer can decide which deployment method is best based on the application without worrying about vulnerabilities and spending time learning multiple tools.
In this blog, we are focussing on Monokle Desktop. If you do not wish to install the tool on your local machine, you can make use of AppImage(available for Linux) or access [Monokle Cloud](https://app.monokle.com/). If you like kubectl, you’ll love [Monokle CLI](https://github.com/kubeshop/monokle-core/tree/main/packages/cli#usage) which enables you to validate YAML from the command line and much more.
## Deploy a web application to Civo Cloud
We'll be deploying the [sock-store application](https://github.com/microservices-demo/microservices-demo) on a Civo cloud Kubernetes cluster. The sock store application demonstrates the deployment of microservices and has different components talking to each other. We'll be using the supplied Helm charts to deploy the application. Let us look into the prerequisites for this and then deep dive into the workings.
### What you need to get started
* [Monokle Desktop](https://github.com/kubeshop/monokle)
* [Civo account](https://www.civo.com/)
### How to provision a cluster on Civo Cloud
We are going to use the Civo cloud for provisioning a Kubernetes cluster. Civo defines itself as the first cloud-native service provider powered only by Kubernetes. The sheer ease of use and developer-friendly tools makes Civo a preferred choice. You can [sign up](https://dashboard.civo.com/signup) for Civo cloud which is quick and free to start.
To [create a cluster on the Civo cloud](https://www.civo.com/docs/kubernetes/create-a-cluster), log in to your account and navigate to Kubernetes. Create a new cluster, provide a name, choose the size as Medium, and leave all the default settings as is.
After the cluster is provisioned, it will allow you to download the kubeconfig file. You can use this file to connect to the cluster from your local machine. Make sure you keep this kubeconfig at a secure location for cluster integration. Let us go ahead and see all the preparation that needs to be done for error-free application deployment.
###Deploying an application with Monokle to Civo Cloud
Launch Monokle Desktop and you can get started in a few simple steps:
#### Clone the repo
Create a new project by cloning the Git repository. This saves your effort of manual configuration or importing.
#### Integrate with Civo cluster
After the repo is cloned, you can view the manifests list in the Monokle file explorer. Monokle provides an option to configure local as well as remote clusters. [Configure Monokle Desktop](https://kubeshop.github.io/monokle/tutorials/how-to-configure-monokle/) to integrate with the Civo cluster.
Monokle allows you to work with multiple clusters. Click on Settings and provide the kubeconfig you downloaded for Civo Cloud to configure access to it. For new users, in the top right corner Monokle shows “NO CLUSTER CONFIGURED”, click on **Configure** to configure access to a new cluster. If you are facing any issues configuring access to your clusters on Monokle, you can refer to our [troubleshooting guide](https://kubeshop.github.io/monokle/cluster-issues/).
#### View and validate Kubernetes resources
With Monokle, all the files available in the repository are listed in the file explorer. Monokle understands these files and generates the list of resources in the navigator. It provides this list along with the [validation errors](https://kubeshop.github.io/monokle/resource-validation/) and outgoing/incoming links to those resources. Resource manifests can be viewed in the editor and the errors can be fixed using key-based input through the [form editor](https://kubeshop.github.io/monokle/form-editor/).
In the above screenshot, we can see that the sock shop has multiple types of validation errors. The [broken link](https://kubeshop.github.io/monokle/tutorials/how-to-fix-broken-links/) error is highlighted with a warning sign and the Kubernetes schema plus YAML syntax error is highlighted with a red circle. You can enable Open Policy Agent(OPA) validation in Monokle to inspect [policy errors](https://kubeshop.github.io/monokle/resource-validation/#inspecting-policy-errors). Navigator shows the count of current OPA rules applied to manifests. This helps in error-proofing the manifests and avoiding vulnerabilities.
#### How to preview Helm charts
As a developer, it feels powerful to have the ability to preview Helm before deployment and avoid guessing due to abstraction. With built-in support for [Helm](https://monokle.io/blog/monokle-helm-kubernetes-deployments), Monokle Desktop identifies Helm charts and accesses its values files. Helm preview fakes locally any values that would normally be looked up or retrieved in a cluster. This helps to understand pre-deployment and what resources would be installed in the cluster.
Let us preview the sock store by clicking Preview at Helm chart in the “View Helm Charts” section in the toolbar.
For the sock-shop application, the resources created include Deployments, ConfigMap, Service, ServiceAccount, and CustomResourceDefinition resources. The resource relationship can be viewed by hovering over the link button available in each resource.
In the above screenshot, we have selected the deployment `helm-chart-nginx-ingress` in the navigator. It shows both outgoing and incoming links. In the navigator, the resources that are linked to the Deployment resource are highlighted. It means that any change in the Service would impact the Deployment. This helps in maintaining consistency when a change has to be made.
#### Deploying web applications
Now that we have validated and previewed the resources, let us go ahead and deploy the sock store to the Civo cluster.
* Select the file complete-demo.yaml. You can view linked resources in Navigator and manifest in Editor.
* Click on Deploy to deploy the sock-shop application to the Civo cluster.
After the deployment is successful, if you try to access the application using the IP address provided by Civo, you’ll end up getting an error. This is because we have not configured any ingress that will allow outside traffic to reach our application. We will create and deploy an [ingress](https://www.civo.com/learn/exposing-applications-https-traefik#create-the-ingress) using the Monokle resource template. This way, any traffic that hits the public IP address will be redirected to the sock shop app.
Let us go ahead and create the ingress:
* Click on “Create new resource” in the navigator.
* Enter the details for ingress.
After the resource is created, click on the resource file. Its source can be viewed and updated in the editor. Provide the following details:
* spec.rules.host: DNS name from Civo Kubernetes.
* spec.rules.http.paths.path: /
* spec.rules.http.paths.pathType: Prefix
* spec.rules.http.paths.backend.service.name: front-end
* spec.rules.http.paths.backend.service .port.number: 80
Select the nginx-ingress.yaml file and click on Deploy. Now when you access the sock shop application using the URL provided by Civo, you’ll be able to access the application.
Hurray! Monokle made it so easy to deploy the application. Visit [Monokle](https://kubeshop.github.io/monokle/) if you face challenges. You can also access the documentation from Monokle Desktop Help drop-down.
#### Verifying Deployment
The e-commerce application sock-store should be accessible via browser using the URL provided by Civo.
#### Using Monokle's Dashboard to view resource status in Production
Monokle not only helps with pre-deployment but also with post-deployment. [Cluster Mode](https://monokle.io/blog/kubernetes-cluster-management-with-monokle) allows you to view the application resource utilization which helps in infrastructure planning and cost optimization.
You can also view the status of each resource and any validation error available in the cluster. This helps you to troubleshoot and spot issues in the cluster quickly. It saves you from guessing what happened or learning to use multiple tools.
You can view in the above screenshot, the status of the catalog pod, its dependencies, and validation error count. Hover over the count to view the list of errors. You can also access the logs and resource manifest. Spotting issues get easier and allows you to fix them at the earliest.
Using Monokle, you can deploy an application like an e-commerce platform. With pre-deployment features, you will avoid issues post-deployment. You get a better understanding of resource relationships that helps in debugging and troubleshooting post-deployment.
It's a nightmare for developers to deploy an application with too many Kubernetes components. After using Monokle, certain things get easier like the pre-validation of resources. Helm chart abstraction for resources leaves developers most of the time guessing about what will happen after deployment which causes uncertainty. Using Monokle, we have seen how to avoid that by previewing Helm charts and understanding resource relationships.
We have also learned how easy and fast it is to use Civo. This week, Civo organized the first-ever [Civo Navigate Conference](https://www.civo.com/navigate) Conference which in Florida where attendees saw Monokle in action during the talk "Git" a Handle on IT! A scalable Approach to GitOps Configuration Patterns".
We hope you are already loving Monokle, so feel free to check our [upcoming blogs](https://monokle.io/blog) that focus on Kubernetes applications. Explore other ecosystems of Monokle like [CLI](https://monokle.io/blog/monokle-cli-flexible-kubernetes-yaml-validation) and [Cloud](https://thenewstack.io/the-quest-for-high-quality-kubernetes-deployments/) to take full advantage of the complete suite of tools.
You can also reach out to Monokle Product Leader [Sergio](https://calendly.com/sergio-ocon/sergio-30) if you have feedback about how we can make Monokle work better for you or drop a mail to firstname.lastname@example.org for information/assistance. You can also join in conversation with other users via [Discord](https://discord.com/invite/6zupCZFQbe) as part of our growing community.
Writing “good” policies is a complex, time-consuming task. Learn to build and troubleshoot policies interactively – with immediate feedback with the power of Monokle Cloud.
Have you been struggling to adopt Kubernetes Pod Security Standards? Monokle is here to help!
Join the Monokle Community in one of these channels: