This tutorial provides an introduction for using the divert option in Okteto Manifests. The divert feature enhances the deployment of your development container when using HTTP-based services.
This tutorial makes use of a demonstration application that mimics a service catalog. The service catalog tracks services, their owners, and health information.
The original deployment contains only the most recent health data for each service in the catalog. This is helpful but it could be better.
A developer decides that health data for each service would be more helpful if it contained historical data. In this scenario, the developer adds a data store and changes the health-checking service to provide more data.
The developer uses the divert feature to develop the new feature side-by-side with the original application.
Let's get started!
- Install the Okteto CLI. Follow this guide if you haven't done it yet.
- Configure Access to your Okteto Cloud Namespace using the Okteto CLI or using the Okteto Cloud UI.
- Clone the catalog repo locally.
git clone https://github.com/okteto/catalog.git
Deploying the service catalog sample application is as simple as...
okteto pipeline deploy command creates all of the necessary components for the service catalog sample application.
The okteto-pipeline.yml file defines the steps to deploy the application.
--wait flag instructs the
okteto pipeline deploy command to wait until the application is up and running (this could take about 2 minutes).
Once your pipeline is successfully deployed, visit Okteto Cloud.
Your application will be available in a URL similar to
Visiting the URL will bring up the service catalog application with only the most recent health data available.
Now, you will change into the directory
health-checker and run
The manifest for the health checker service contains the divert option.
Adding the divert option alters how Okteto deploys the development container. The default behavior, without the divert option, will replace the target deployment with the dev container. This prevents you from using the original application without either bringing down the development container or deploying a duplicate of your application. When using the divert option your development container will be brought up alongside your original container. In addition, a duplicate of the specified ingress is provisioned so that you can use either endpoint. The original endpoint to access the original application and the duplicate endpoint to access your application as you develop. Try it out now!
At this point, Okteto has duplicated the health-checker service and the original deployment as a development deployment.
Along with the development deployment, there is now a new URL similar to
Accessing the application with the development URL will divert all traffic bound to the health-checker service to your development deployment.
The application code already contains an advanced health checker client that has historical health data.
Now, we need to make use of this newly developed advanced health checker.
To do so we edit the file
health-checker/cmd/main.go so that the health handler uses your advanced client.
With our edits in place, it is now time to run the application in the development container.
Build and run by typing
go run cmd/main.go in the container.
Now if you visit the development URL you can see the changes live. The original application is left untouched and is still available at the original URL.
With the catalog application deployed, and the divert development container in place the resulting deployment is...