Best Practices for production ready Rancher Deployment

Rancher
1

What are the best practices to deploy in-house product on Rancher?
1 How to deploy it using CI/CD pipelines (using Jenkins)?
2 How to deploy and maintain different environment like Staging, Development, Pre-production and production?
3 Is there any way to build full cluster using any template(like yaml or something) on single push?

Any link or material would help a lot.

Thanks and Regards
Chetan Gupta

2

Here is my answer to the same kind of question from different angle, but from all angles there is one thing in the middle - Rancher:

3

I guess this partly depends on your starting point, which you haven’t given any details of. For your cluster(s) you haven’t said whether you are making use of a hosted solution like GKE or AKS or EKS. If you are, then from an infrastructure perspective most of the work is done for you and typically you are only concerned with provisioning worker nodes (though hosted solutions do tend to give you less freedom). If you are building your own custom clusters then I would strongly recommend using Terraform. You can also use the Rancher2 Terraform provider to automate the creation of your cluster resources too. How much you lean on the Rancher API and to what extent you want to stick to vanilla K8s is also a choice you will want to consider carefully. All of this is automation that should run within your preferred CI/CD pipeline tool (Azure DevOps, JenkinsX, whatever).

Setting up and configuring clusters for Rancher is comprehensively covered in their docs, so I won’t repeat that here.

As far as setting up multiple environments for application teams, there are a number of common patterns each of which have pros/cons. Probably the most common is a shared multi-tenant cluster where each of your app teams have access to namespaces which represent their development lifecycle. Some like to have traditional dev, sys, uat, pre, prod separation, whereas others like to split based on teams and apps/app groups. Rancher provides the ‘project’ construct which is pretty useful, although again is a divergence from vanilla K8s. Either way (and many others) namespaces can provide a management, resource and security boundary which is typically what you need for multi-tenant. Alternatively you can go for multiple clusters. These provide stronger isolation, are in some ways easier to manage and secure, but can increase your costs since their is less resource sharing and higher redundancy overall. No right or wrong, just choices.

Deployment of application workloads is most often easiest to achieve using a combination of Helm and you CI/CD tooling. You don’t need a Helm repo but it is easier if you have one (Jfrog Artifactory supports this type and API but you can just as easily use an S3 bucket or virtually any web server). The management of RBAC and how that plays into your build and release pipelines is critical, as is secrets management. Again plenty of choices which depend to some extent on your size and the security classification of the data that you need to secure.

HTHs

Fraser.