Speaker Ioannis Gkourtzounis from Comquent MEPE in Thessaloniki.
A short description of the presentation:
The CI/CD processes play an essential role to the quality of the product that is delivered at the end of every release cycle. Not only many people are involved, but different technologies and tools should be chosen wisely in order for the CI/CD to offer high value while the software goes through the build, test and deploy phases. But the strategy used by the team to implement the automation of those tools, depends heavily on the underlying infrastructure and architecture of the software under test. Most companies used to develop monolithic applications and just in the last decades an era of cloud computing and highly available microservices, started to gain momentum. Container technology and Kubernetes made possible the rapid deployment and scaling of such applications. What does this mean for our CI/CD strategies? In this presentation we will take a look at some common problems when trying to automate CI and CD on the traditional infrastructure and see how we can tackle them using a Cloud Native approach. We will learn how Kubernetes works, what are the benefits of GitOps and how to use Jenkins X to easily build, deploy and promote to production.
11. More than 2 years of experience as a QA Engineer
DevOps Enthusiast
CI/CD with Jenkins
Test Automation with Selenium
Software Development background
AWS Certified Cloud Practitioner (CLF-C01)
Kubernetes Application Developer (CKAD)
Certified Jenkins Engineer (CJE)
ISTQB Agile Tester
ABOUT ME
Slide 1 of 40
12. Fully automate a CD pipeline with zero lines of code
Use dynamic test environments with minimum effort
See the actual impact of a code change, before merging the code
No need of CI/CD server, so no maintenance needed
Self-healing infrastructure, updates with zero downtime, super easy to scale up/down
➢ What does this mean for our CI/CD processes?
OBJECTIVES
Slide 2 of 40
17. DISTRIBUTED SYSTEMS
Components distributed on different networks
Complex infrastructure with remote servers and APIs
Communication and data exchange involve many parts
API gateways and Middleware systems help with connectivity
Widely used on data migrations and integrations to bigger systems
Slide 7 of 40
18. PROBLEMS OF THE TRADITIONAL INFRASTRUCTURE
Complexity – too much effort to automate everything
Hard to maintain – too many dependencies, difficult to debug and extend
Delivery pipelines –manage environment configurations and deploy the code
Error prone – too many different configurations and permission settings
Reliability – “it works on my machine”, single point of failure
Cost – the servers/environments are “always on”
➢ We need a new, more dynamic infrastructure for our CI/CD processes
Slide 8 of 40
19. WHAT IS THE CLOUD NATIVE APPROACH
➢ Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments
such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and
declarative APIs exemplify this approach (CNCF).
Source: https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition
Company Services in production Deployment frequency
Netflix 600+ Hundred times per day
Uber 1,000+ Thousand times each week
WeChat 300+ 1,000 times a day
Slide 9 of 40
20. CHARACTERISTICS OF CLOUD NATIVE
Applications are packaged in containers
The application is broken down into microservices
A service mesh applies logic to service-to-service communication
The services are not modified after they are deployed
The infrastructure is described in declarative language
Slide 10 of 40
22. ADVANTAGES OF CONTAINERS
Distribute applications in self-contained environments
Isolated code execution is faster and more reliable
Environments can be setup with “Configuration as a Code”
Easy and fast deployment of applications
Create/destroy multi-container applications with just 1 command
Great for dynamic environments creation
Slide 12 of 40
23. SINGLE CONTAINER APPLICATION
How to interact with a container:
with the Entrypoint
with Volume mapping
with Port mapping
Slide 13 of 40
25. CONTAINER ORCHESTRATION
An orchestration platform that automates:
Resource allocation and scheduling
Provision and deployment of containers
Load balancing and traffic routing
Scaling activities based on workloads
Health monitoring of containers
Slide 15 of 40
26. BENEFITS OF KUBERNETES
Follows the “Infrastructure as a Code” paradigm
Version control of the whole infrastructure
Optimized resource usage
Zero downtime with rolling updates
Self-healing in case of failures
Easy scale up/down with just 1 command
Slide 16 of 40
33. STATEFUL APPLICATION
ReplicaSets
ConfigMaps and Secrets
Persistent Volumes and Claims
Readiness and Liveness Probes
Jobs and Cronjobs
Network Policies and Ingress
Slide 23 of 40
34. MANAGE YOUR APPLICATIONS EASILY
Description Command
Apply rolling update container image in the deployment kubectl set image deployment/frontend www=image:v2
Check the history of deployments kubectl rollout history deployment/frontend
Rollback to the previous deployment kubectl rollout undo deployment/frontend
Autoscale a deployment kubectl autoscale deployment foo --min=2 --max=10
Update deployment properties in realtime Kubectl edit deployment frontend
Slide 24 of 40
35. BREAK TIME !
Source: https://www.jenkins.io/artwork/
Slide 25 of 40
Jenkins Cosmonaut
36. EXTENDING KUBERNETES
Kubernetes Operators with custom resource definitions
Helm Charts package manager with templates and values
https://helm.sh
Slide 26 of 40
37. GITOPS PRINCIPLES
Automates cluster management and application delivery
The system consists of the cluster state and the application state
The cluster state and application are described declaratively
Git is the “single source of truth” and everything is version controlled
Approved changes are applied automatically to the system
The system always matches desired state with agents
Slide 27 of 40
39. JENKINS X
A cloud native CI/CD solution built on Kubernetes
Includes fully automated default pipelines for quickstart projects
Jenkins X pipelines are serverless (better resource utilization)
Automatically creates preview environments for pull requests
See the actual impact of a code change, before merging the code
Follows GitOps principles for environment promotion
Slide 29 of 40
40. JENKINS X REQUIREMENTS
Kubernetes cluster in Google Cloud or AWS
Dynamic provisioning enabled in the cluster
LoadBalancer with available IPs
GitHub organization account
GitHub bot account
Bot personal access token
Slide 30 of 40
46. JENKINS X BUILDPACKS
BuildPacks describe the stages to Build, Package and Deploy
A buildPack includes: agent, env, pipelines, stages, steps
Jenkins X autodetects the buildPack to use based on the source code
Jenkins X pulls Git repositories with default buildBacks
We can override this and specify a base buildPack with inheritance
We can then add custom steps or replace the steps of a stage
Slide 36 of 40
47. JENKINS X BENEFITS AND CHALLENGES
Benefits
Cloud native solution for Kubernetes clusters
Automation of CD pipeline allows to “shift left”
Simple, “ready-to-go” pipelines
The team can move fast with small lifecycles
Go from releases per week to releases per day
Challenges
Does not fully support Kubernetes “bare metal”
Effort for migrating pipelines to the new platform
Traditional Jenkins plugins are not supported
No production-ready UI with dashboards
Slide 37 of 40
48. Fully automate a CD pipeline with zero lines of code
Use dynamic test environments with minimum effort
See the actual impact of a code change, before merging the code
No need of CI/CD server, so no maintenance needed
Self-healing infrastructure, updates with zero downtime, super easy to scale up/down
➢ All these can be accomplished with a Cloud Native CI/CD approach: Kubernetes + Jenkins X
OBJECTIVES
Slide 38 of 40
49. IS THE CLOUD NATIVE APPROACH, RIGHT FOR YOU?
Benefits
Great for dynamic scaling based on workloads
Deployments can be fast and more frequently
Reduced risk with progressive delivery
No need to manage the underlying infrastructure
Reduced cost by paying only for what you use
Challenges
Time and cost to re-architecture the application
The need to re-establish processes and workflows
Not suitable for legacy applications that work well with the
“traditional approach”
Slide 39 of 40
50. THANK YOU! QUESTIONS ??? KUBERNETES + JENKINS X: A CLOUD NATIVE APPROACH
Slide 40 of 40