Jenkins and Kubernetes

Slides from the talk at the Jul 5th CI/CD meetup at Bitnami office in Seville.

Transcript

1. Jenkins and Kubernetes Better Together / Andres Rodriguez (@andresrc)
2. Agenda AGENTS IN KUBERNETES MASTERS IN KUBERNETES CLOUD NATIVE APPLICATIONS • Get the most from Jenkins and Kubernetes, by making them work together • Three (related) perspectives:
3. Running Agents in Kubernetes Additional flexibility and scalability for your builds
4. Jenkins Agents Dedicated Agents 4 • Initially agents were dedicated boxes. ◦ Using labels to select different features (platform, machine size, etc) ◦ Manually provisioned. • Still useful: ◦ Executors with special requirements (licenses, constrained resources, ...) • As our CI / CD requirements grow, we need more elasticity. Jenkins Master Agent 1 Agent 2 Agent 3 Agent n
5. Jenkins Agents Clouds 5 • We need mechanisms to get agents on demand. • Jenkins provide “clouds”: ◦ Configure some “template agents”. ◦ Assign labels. ◦ Agents created and returned on demand. • Some examples: ◦ Amazon EC2 Plugin ◦ Azure VM Agents Plugin • Could be used for VMs and containers, though for the latter could be a bit different: one-shot executors. Jenkins Master Provisioned Agent Agent no longer needed Configured Cloud Request new agent when needed. Provision new agent Destroy agent
6. Jenkins Agents Kubernetes as a Cloud 6 • Kubernetes Plugin, created by Carlos Sánchez • Dynamic Jenkins Agents, running as Pods. • Multi-container support: ◦ One container in the pod runs the Jenkins Agent, the others are custom. ◦ Pipeline support for both agent pod definition and execution. Jenkins Master Kubernetes cluster Agent Pod JNLP Cont. Other Cont.
7. Jenkins Agents Advantages of Kubernetes Agents 7 • Agents are not only provided on demand, but can also be defined on demand. ◦ And as part of the build code, providing great flexibility and decoupling from administrators and developers ◦ Capability to configure really complex build scenarios. • Access to Kubernetes capabilities and ecosystem. Agent Pod JNLP Agent Build & Test Chrome Selenium Hub Build & Test Firefox Chrome Browser Image Firefox Browser Image
8. Jenkins Agents Pipeline Integration 8
9. Jenkins Agents Ok, but how about Docker? 9
10. Running Masters in Kubernetes Improved manageability and availability
11. Jenkins Masters The “traditional” model - Deployment 11 Jenkins Home Jenkins Instance • The “PowerPoint mode”: ◦ Everything on disk ◦ Main parts in memory • Pro: very simple deployment. ◦ Helped with Jenkins adoption. • Con: not suitable for advanced deployments ◦ High availability ◦ Horizontal scalability
12. Jenkins Masters The “traditional” model - Configuration 12 Jenkins Core • Plugin model: ◦ Enabler for Jenkins success. • Original focus was making configuration through UI simple • Pros: ◦ Very extensible UI. ◦ Great plugin ecosystem • Cons: ◦ Very difficult to evolve the UI. ◦ Does not fulfill today’s expectations on service configuration. Plugin 1 Plugin 2 Plugin 3 Plugin 4 Plugin n
13. Jenkins Masters Things are improving... 13 • Configuration as Code • Removing things from JENKINS_HOME: ◦ And move them to some external / shareable storage.
14. Jenkins Masters Why deploy in Kubernetes? 14 • Jenkins is not a Cloud-Native architecture. • Still can get advantages from running in Kubernetes: ◦ Manageability. ◦ Use k8s primitives instead of roll-your-own solutions for things like high-availability. Persistent Volume Claim Deployment (StatefulSet is another option) Master Pod (only 1 replica!) Service Ingress
15. Jenkins Masters Secrets and Credentials 15 • Even Better with Sealed Secrets! • Using K8s Secrets as Credentials
16. Jenkins Masters Some deployment options 16 • Kubecfg ◦ Built for declarative, “gitops” workflow. ◦ Heavily inspired by an existing proprietary tool. ◦ JSON, YAML, jsonnet input. ◦ Whole config in one invocation, not separate fragments. ◦ Optimised for automated pipelines, rather than interactive use. ◦ Simple client-side tool: ▪ Obeys RBAC. No need for an “admin” uber-job in-cluster. ▪ Can be used on multiple clusters. • Helm Charts ◦ The “apt-get” of Kubernetes ◦ Bitnami Chart for Jenkins
17. CI/CD for Cloud Native Applications A peek into the (near) future
18. Jenkins X A CI/CD solution for cloud native applications 18 • An opinionated way to develop cloud-native applications: ◦ Microservice-based. ◦ Deployed in k8s, as charts • Based on Jenkins, but Jenkins is barely visible: ◦ The system creates the pipelines. • Focus on GitOps
19. Jenkins X 19 Applications and Environments Applications Production Preview 1 Preview 3 Preview 2 Preview n Staging PRs to App PR Merged Environment Promotion • The “unit of work” is the Application. • Each Application has multiple “environments”: ◦ A place where the app is deployed. ◦ There’s a git repo for each, containing the Helm charts, configuration,... ◦ Each environment maps to a k8s namespace.
20. Jenkins X 20 Applications and Environments • Every change is done via “GitOps”. • Every change turns into a PR in an environment repo. ◦ Changes chart content, configuration, etc. • When the change is merged the (automatically generated) pipeline deploys the (version of the) app in the cluster. • “Promotions” are PR to other environments
21. Thank You (we’re hiring!) For more information visit bitnami.com