Currently I am practicing with Kubernetes resources like replicaSet , deployment and services. When I created my sample deployment and service for testing , I used kube apply command for creating the deployment and service into the Kubernetes cluster.That is properly working.
Now I am trying to make a end-to-end deployment using CI/CD pipeline. So when I am adding the deployment step in the Jenkinsfile , Can I use the kube apply command inside Jenkinsfile. Means If I am continuously committing in my SVN repo , changes will get update by using kube apply command? For each change I am making to repo need to reflect in deployment.
Can I use kube apply command for update also in Kubernetes ? Or Do I need to use rollout for updation of Kubernetes resource?
If I am continuously committing in my SVN repo , changes will get update by using kube apply command?
Ans:Yes
Below is the definition from kube document
Apply is a command that will update a Kubernetes cluster to match
state defined locally in files.
https://kubectl.docs.kubernetes.io/pages/app_management/apply.html
Related
I have different git repos for microservice A,B,C. Also one git repo where the terraform config is stored. When one microservice's code changes a pipeline is triggered and the docker image is published to the google cloud artifact registry.
I then manually run terraform apply. My terraform files specify a kubernetes deployment for each service. The newest docker image version for each deployment is specified in the terraform file (hardcoded).
I want to run terraform apply automatically, after the pipeline of a service runs. But because the current tag is hardcoded in the terraform files it needs to be updated manually.
Approach 1:
I could make the tag as an input variable but everytime one service's new image gets build the others tags stays the same. So I wouldn't know the not changed ones.
Approach 2:
Using the tag latest is also not possible, because the image changes, but the kubernetes deployment in terraform gets not rebuild because the tag stayed the same.
image_A = "${var.gcp_region}-docker.pkg.dev/${var.gcp_project}/${local.artifact_repository_id}/A:28"
image_B = "${var.gcp_region}-docker.pkg.dev/${var.gcp_project}/${local.artifact_repository_id}/B:20"
image_C = "${var.gcp_region}-docker.pkg.dev/${var.gcp_project}/${local.artifact_repository_id}/C:48"
Does someone have an idea how to solve this problem?
Currently I am trying to deploy one sample micro service developed using Spring Boot using Jenkins and Kubernetes on my on premise server. For that I am already created my Kubernetes resource using Helm chart.
I tested the Helm chart deployment using login in remote machine and in my home directory I created. And using terminal command "helm install" I deployed into kubernetes cluster. And end point is successfully working.
My Confusion
Now only tested from terminal. Now I am trying to add the helm install command in my Jenkins pipeline job. So where I need to keep this helm chart? Need to copy to /var/lib/jenkins directory (Jenkins home directory) ? Or I only need to give the full path in command ?
What is the best practice for saving Helm chart for Jenkins deployment? I am confused about to follow standard way of implementation. I am new to this CI/CD pipeline.
The Helm chart(s) should almost definitely be source controlled.
One reasonable approach is to keep a Helm chart in the same repository as your service. Then when Jenkins builds your project, it will also have the chart available, and can directly run helm install. (Possibly it can pass credentials it owns to helm install --set options to set values during deployment.) This scales reasonably well, since it also means developers can make local changes to charts as part of their development work.
You can also set up a "repository" of charts. In your Jenkins setup one path is just to keep a second source control repository with charts, and check that out during deployment. Some tools like Artifactory also support keeping Helm charts that can be directly deployed without an additional checkout. The corresponding downside here is that if something like a command line or environment variable changes, you need coordinated changes in two places to make it work.
I suggest to follow the below path for SDLC of helm charts and apps they whose deployment they describe:
keep spring boot app source code (incl. Dockerfile) in a dedicated repo (CI process builds docker image out of it)
keep app helm chart repo source code (which references the app image) in a dedicated repo (CI process builds helm chart out of it, tags it with version and pushes it to artifact registry, e.g. Artifactory or Harbor)
To deploy the chart using Jenkins job, you code the necessary steps you would use to deploy helm chart manually in the pipeline.
Modern alternative to the last step would be using GitOps methodology. In that case, you'd only put the latest released chart's tag in GitOps repository. The deployment will be done using GitOps operator.
I am trying to move the complete eco-system of our SAAS product to Kubernetes (and use Docker containers).
I am supposed to give a bash script which will set up everything. Only manual intervention should be setting up the Kubernetes cluster and mounting Persistent Volumes.
We were using Jenkins for code deployment and cron jobs. I am able to create the Jenkins service but I can not find ways to configure it using the command line. Tried finding ways online but can not find any good documentation.
First welcome to kubernetes, second, there are a lot of tools, templates over there, I would recommend you to check what is Helm
This is the Jenkins chart if you want to check:
https://github.com/helm/charts/tree/master/stable/jenkins
There is also a "fork" of jenkins for containerized environments, that I like, you can check more about Jenkins-X here
You can use helm package manager and simply install the Jenkin stable version.
Before using helm you have to setup tiller on kubernetes cluster.
$ helm install --name my-release stable/jenkins
here stable version of jenkin using helm.
https://github.com/helm/charts/tree/master/stable/jenkins
I can add that you can store Jenkins home folder as well as plugins and artifacts folder on persistent volume and mount that volume to Jenkins pod as a part of Helm installation. You can also make daily snapshots/backups of Jenkins disk. In this way Jenkins deployment becomes very smooth, quick and reliable.
I have created a cluster using minikube which has 2 namespaces, dev and infra. dev contains my UI and backend apps while infra contains my Jenkins StatefulSet. I set Jenkins and added the Kubernetes plugin (v 1.1.3). Now I want to create a Jenkins job so that I can redeploy services in my dev namespace.
However, when my Jenkins job runs, I can see that it spins a new pod in the infra namespace as expected for the build, but this pod does not have access to the kubeconfig or the kubectl command. How do I promote builds in this case?
Here is my Kubernetes Cloud Configuration
And here is the console output of a sample job
The sample job above does nothing, I was just testing to make sure that it spins off a pod of its own every time it is run.
How can I use these Jenkins jobs now to redeploy my services/pods in the dev namespace?
this pod does not have access to the kubeconfig or the kubectl command
You need to use a jenkins agent docker image that has those commands
You also need that agent pod to use a service account that has permission to access the dev namespace if you want to change things there
I've been struggling with setting up the Jenkins Kubernetes Plugin on the Google Container Engine.
I have the plugin installed but I think all my builds are still running on master.
I haven't found any good documentation or guides on configuring this.
UPDATE
I removed the master executor from my Jenkins image. So now my builds aren't running on master but now they have no executor so they don't run at all. Just waits in the queue forever.
You'll need to tell Jenkins how and where to run your builds by adding your Kubernetes cluster as a 'cloud' in the Jenkins configuration. Go to Manage Jenkins -> Configure System -> Cloud -> Add new cloud and select 'Kubernetes'. You'll find the server certificate key, user name and password in your local kubectl configuration (usually in ~/.kube/config). The values for 'Kubernetes URL' and 'Jenkins URL' depend on your cluster setup.
Next, you'll need to configure the docker images that should be used to run your builds by selecting 'Add Docker Template'. Use labels to define which tasks should be run with which image!
Here's a good video tutorial and here you'll find a nice tutorial which explains everything in detail.
The important bit after you've installed the plugin, set up access to your Kubernetes cluster, and set up your first Kubernetes Pod Template with a label like jnlp-slave, is that in your Jenkinsfile you need to begin with something like node('jnlp-slave') {}. Then the pod will be started when you trigger a build.
There's also a helm chart for easy deployment if that helps :)
This example might also help once you've set the plugin up too.