Kubernetes deployment without Docker

Hi all. I’m trying to figure out what sort of service/workflow/deployment I need in my case for Kubernetes. When I choose a Kubernetes service type, Harness forces me into a Docker artifact type, but all I really have in my case per “service” is:

  • a tar file of data in Artifactory (a machine learning model) which I can deploy via script (kubectl cp into a PVC at present) and
  • a yaml fragment to apply to the k8s cluster since all the real CODE is implemented in CRDs already on the cluster. this creates my actual service endpoint for me via Knative

Thoughts on how one might factor this into services/workflows? As a start, I am doing this:

  • put the service yaml in the manifest for the service (I could templatize that)
  • hacked up a Custom artifact source for the so-called Docker artifact type (it just mangles up some yaml to communicate the location of the data file to the workflow.
  • in the workflow, it reads the variables output from the artifact source, fetches from artifactory, pushes to the cluster, then finally the yaml for the custom resource gets deployed for the service.

It works but seems kind of ugly. Thoughts greatly appreciated!

@Jeff

This is an interesting use case.

Here’s where I would start:

  1. Create an SSH Service with a TAR file as the Artifact Type (no application stack). This will allow you to link to the TAR file in Artifactory.
    a. Remove any of the parts of the Deployment Specifications
    b. Add a new Deployment Specification with the desired name and Command Type.
    c. Add a new Exec script where you can put in the desired kubectl script and templatize it as much as possible
    d. Example: Use ${artifact.metadata.image} for the artifact image and other variables that could be filled in at runtime as needed.
  2. Add another Harness Service that is of Kubernetes type
    a. No Artifact Source is required
    b. Add the desired kubernetes manifests
    c. Make sure to add # harness.io/skip-file-for-deploy to the top of any files that are either CRDs, jobs, or anything that you’d like to deploy in a specified order.
  3. Add an environment (if one is not there) and an infrastructure definition for kubernetes
  4. Add a Multi-service Workflow where you can point to both of the services that we created above. In the case of the kubernetes service, you can use the Kubernetes Apply step to execute those manifest files separately. If you are running any CRDs, make sure you check the box that says “Skip Dry-Run”, or else it will fail the deploy.

Let me know if you have any questions on this!

2 Likes

Thanks a lot @sneakyaneurysm ! I’ll give that a try and let you know how it goes.

2 Likes