The deployment guides walk you through setting up a specific deployment using Harness, such as ECS, Kubernetes, and Helm. They are written to provide you with everything you need to learn how to model your CD process in Harness.
In this topic:
Always start with the Quickstarts in Start Here. These will take you from novice to advanced Harness user in a matter of minutes.
The following topics will walk you through how Harness implements common deployments according to platforms and scenarios:
- AMI (Amazon Machine Image)
- AWS Elastic Container Service (ECS)
- AWS Lambda
- CI/CD: Artifact Build and Deploy Pipelines
- Google Cloud
- Native Helm
- IIS (.NET)
- Kubernetes (includes Helm, OpenShift, etc)
- Pivotal Cloud Foundry
- Traditional Deployments
- Custom Deployments
Also, other key platforms that help you make your CD powerful and efficient:
- Configuration as Code (work exclusively in YAML and sync with your Git repos)
- Harness GitOps
For topics on general CD modeling in Harness, see Model Your CD Pipeline.
Kubernetes or Native Helm?
Harness includes both Kubernetes and Helm deployments, and you can use Helm charts in both. Here's the difference:
- Harness Kubernetes Deployments allow you to use your own Kubernetes manifests or a Helm chart (remote or local), and Harness executes the Kubernetes API calls to build everything without Helm and Tiller needing to be installed in the target cluster.
Harness Kubernetes deployments also support all deployment strategies (Canary, Blue/Green, Rolling, etc).
- For Harness Native Helm Deployments, you must always have Helm and Tiller running on one pod in your target cluster. Tiller makes the API calls to Kubernetes in these cases.
Harness Helm deployments only support Basic deployments.
Check out Harness Youtube channel for the latest videos.
Deployment Logging Limitations
There is a hard limit of 25MB for logs produced by 1 Workflow step. Logs beyond this limit will be skipped and not available for download as well.