Getting started with Jenkins X

Getting started with Jenkins X

This tutorial is on What is Jenkins X will introduce you to its features and how it is different from Jenkins. How to install Jenkins X. Jenkins Vs Jenkins X. How Jenkins X works? Jenkins X is a CI/CD solution for modern cloud applications on Kubernetes. Features of Jenkins X

Getting started with Jenkins X

What is Jenkins X | Easy CI/CD for Kubernetes | DevOps Certification Training

This video is on What is Jenkins X will introduce you to its features and how it is different from Jenkins. It will also, show how to install Jenkins X. This session will focus on the following pointers:

  • What is Jenkins X?
  • Jenkins Vs Jenkins X
  • Features of Jenkins X
  • How Jenkins X works?
  • Installation

DevOps Tutorial for Beginners - DevOps Full Course

DevOps Tutorial for Beginners - DevOps Full Course

In this DevOps tutorial for beginners - DevOps full course you will learn DevOps end to end right from what is DevOps , various DevOps tools it has like Docker, Git, Jenkins, Chef, Kubernetes, Nagios, Puppet, Ansible in detail.

In this DevOps tutorial for beginners - DevOps full course you will learn DevOps end to end right from what is DevOps , various DevOps tools it has like Docker, Git, Jenkins, Chef, Kubernetes, Nagios, Puppet, Ansible in detail.

Following topics are covered in this video:

  • 01:06 - why devops
  • 03:45 - traditional IT vs devops
  • 07:25 - what is devops
  • 11:00 - devops lifecycle
  • 11:05 - how devops work
  • 22:55 - devops tools
  • 29:37 - what is git
  • 31:45 - common git commands
  • 1:20:28 - problems before docker
  • 01:27:12 - what is docker
  • 01:33:07 - docker vs virtal machine
  • 01:35:30 - docker installation
  • 01:40:15 - docker container lifecycle
  • 01:42:45 - common docker operations
  • 02:17:59 - what is a dockerfile
  • 02:35:55 - introduction to docker volumes
  • 03:18:15 - what is docker swarm
  • 03:34:56 - what is puppet
  • 03:57:05 - code basics for puppet
  • 04:24:35 - what is ansible
  • 04:51 - introduction to software testing
  • 04:57:30 - introduction to selenium
  • 05:26:41 - how to create automated tests in selenium
  • 05:41:42 - features of testng
  • 05:44:45- annotations in testng
  • 06:50:21 - continuous integration in jenkins
  • 07:46:32 - why kubernetes
  • 07:56:08 - what is kubernetes
  • 08:01:16 - kubernetes architecture
  • 08:32:48 - what is nagios
  • 08:52:44 - devops interview questions & answers

How Kubernetes Helps to Enable DevOps

How Kubernetes Helps to Enable DevOps

The automation and infrastructural capabilities of Kubernetes makes it an ideal technological partner for DevOps. In this article, you'll see 10 ways Kubernetes enables DevOps

The automation and infrastructural capabilities of Kubernetes makes it an ideal technological partner for DevOps. In this article, you'll see 10 ways Kubernetes enables DevOps

DevOps was an idea before its time.

It actually took a while for technology to catch up and fully implement the principles and vision of DevOps, but that is how innovation works.

A new set of tools in our toolboxes (though it's now taking up more and more mindshare) is end-to-end automation, and Kubernetes helps you manage that. Kubernetes is an open source framework for "automating deployment, scaling, and management of containerized applications." Originally introduced by Google, Red Hat, and others pushed it forward the last 3-4 years.

At the 2017 All Day DevOps conference, Siamak Sadeghianfar laid out 10 ways Kubernetes enables DevOps. We thought it was worth revisiting what he had to say as **Kubernetes **only becomes more prominent.

**So, how exactly does Kubernetes enable DevOps? Let's dive into what Siamak had to say: **

1. Deployment automation.

You should automate every step of your delivery pipeline. Kubernetes automates the deployment of containers. Each component becomes a container image.

**2. Infrastructure as code. **

With **Kubernetes **your entire infrastructure is code. This means any part in your application (databases, ports, access controls, etc.) can be described in a way **Kubernetes **can use. For example, you store your infrastructure code in a version-control repository. **Kubernetes **takes the code, and based on instruction, deploys, and maintains your infrastructure. This happens automatically and consistently.

3. Configuration as code.

**Kubernetes **allows you to "configure as code." Traditionally, an admin had to run configuration scripts manually to make sure they get the right one. **Kubernetes **keeps the file in the source repo. This allows you to describe where the file needs to go in the container and how the application consumes it. Additionally, it can be version controlled.

4. Immutable infrastructure.

Since the inception of servers, there's been one problem: every time you put out a fire you change the state of the virtual machine. Eventually, you don't know exactly what the server looks like and you can't recreate it, even though you know it works. (These virtual machines are referred to as snowflakes.)

In Kubernetes, new containers are immutable; they are created when there is a problem with the original state. So, you can be confident that you know exactly how the new environment is configured.

5. On-Demand Infrastructure.

Developers can create hybrid services and infrastructure on-demand from the self-service catalog. This gives control to developers to get the resources they need, yet allows operations to control the configuration of the services. Kubernetes follows open service and API standards so you can expose cloud services.

6. Environment consistency.

Build once, and deploy into production-like environments everywhere. Kubernetes allows you to build a golden image and use the exact same image for every single place you deploy your container. This gives you a consistent, production-like environment so it is the exact same whether you are on your local Windows or Mac development machine, a test server, etc. This helps you "shift left" so that you can see issues when you are in development instead of in production.

7. Continuous Delivery pipeline.

This is a series of automated steps to test code before it goes in production. Jez Humble says the role of Continuous Delivery is, "an automated process to prove to you a change is a bad change and it should not go into production." Continuous Integration (CI) means every change is tested. Continuous Delivery (CD) automates all the way to production.

How can you tell if you have fully implemented Continuous Delivery? Siamak says that the test is if someone walks in and says, "Can you go to production right now?" can you do it without breaking a sweat?

8. Zero downtime deployments.

When you have several deployments a day, you can't pull down production to deploy. You must have safe, rolling updates without disrupting the production traffic. Kubernetes helps with blue/green deployments so that you can set up a new environment and switch to the new one without downtime.

9. A/B Testing.

How can you evaluate proposed changes, such as changing copy or the color of buttons? A/B testing delivers different versions to different customers so you can get real-world test results. Kubernetes manages routing traffic to different versions. The same version with slight modifications are possible.

10. Cross-functional collaboration.

This is shared access to environments with granular control. Kubernetes goes beyond the silos so everyone has the same set of environments, but you can grant access to different roles and allow different roles to do different things. For instance, developers may be able to push to production, while Infosec may have view access, and QA may have access to live containers, but not building or deploying. The entire team can access production, but operations is the only one who can make containers.

The growing popularity of Kubernetes is undeniable. Luckily, with these 10 capabilities, Siamak has laid out a great path for us all to follow as they continue to not only make their way into the DevOps pipeline, but in many ways enable it.

Leveraging Jenkins on Kubernetes

Leveraging Jenkins on Kubernetes

There are several ways to manage your cloud infrastructure in a DevOps environment. DevOps on its own is developed as an approach that encourages fast-flowing app development and IT teams to move from development to testing and release in a seamless way.

Jenkins is a powerful automation and CI/CD tool that can become an essential part of your Kubernetes pipeline.

There are several ways to manage your cloud infrastructure in a DevOps environment. DevOps on its own is developed as an approach that encourages fast-flowing app development and IT teams to move from development to testing and release in a seamless way.

Jenkins optimizes that flow of work through automation and the seamless integration of Continuous Integration (CI) and Continuous Delivery (CD) into the development pipeline. It’s possible to deploy these techniques using a Jenkins pod within Kubernetes which can be scaled according to the specific needs of the team.

The CI/CD Pipeline

Jenkins is well-established and synonymous with the terms CI/CD. It is the perfect tool for automating the development and deployment of apps and microservices and is currently the most popular automation tool on the market. Jenkins has more than 1,000 plugins that allow for easy integration with other systems, including Kubernetes. Not only do the plugins provide multi-system integration but the significantly enhance Jenkins’ power, making it capable of helping you build and deploy almost any project type. We cover the top 20 Jenkins plugins that you need in your life here in another post.

Setting up your own CI/CD pipeline is easy thanks to the native compatibility of Jenkins and Kubernetes. Deploying Jenkins on Kubernetes provides important benefits over a standard VM-based deployment. For example, gaining the ability to have project-specific Jenkins slaves (agents) on demand, instead of having a pool of VMs idle waiting for a job. It will use master-agent architecture to fully automate the creation and deployment of microservices—and the environment they need—for testing and deployment.

Jenkins can be deployed using Helm, kubectl* *or GUIs for deploying new pods to the cluster. Once installed, the next step is to configure the Jenkins plugin for K8s. We need to configure settings such as where an agent finds the Jenkins master, what Docker images we will use for the agents, etc. Of course, it’s also crucial to configure Jenkins to work with your CI/CD workflow, including setting the testing and deployment parameters and how the Jenkins-controlled cluster must be set up. Staging a continuous delivery environment becomes fully automated once Jenkins is up and running.

Setting Up a Pipeline in Jenkins

Getting Jenkins started is only the beginning. The next step is configuring your CI/CD pipeline within Jenkins itself. You can begin by running minikube service Jenkins and accessing Jenkins using its web UI.

You then have the option to install the necessary plugins. Depending on the pipeline you want to create, you may want to download and install suitable plugins to enable automation and better management of the pipeline. Using the Kubernetes plugin is a must.

Another plugin worth talking about is the Kubernetes Continuous Deploy plugin, which is specifically designed to handle the continuous delivery aspect of the pipeline. This plugin will handle the creation of new pods for testing as well as the transition between testing and deployment.

After all the plugins are configured, restart Jenkins. A nice feature that Jenkins offers is the ability to automate those manual changes so the next time you have to configure the CI/CD system (e.g., in the event of infrastructure migration) you don’t have to pass through the manual changes again. You simply receive an instance with the same configuration and plugins you had previously. The script install_plugins.sh embedded into the Jenkins Docker image and the Jenkins config file config.xml makes this happen.

Now you can go ahead and then create your first pipeline, assign credentials to it, and begin developing inside the pipeline itself. Remember that Jenkins doesn’t always pull code from local storage; you need to issue a push request manually the first time you configure it.

Create the first pipeline and you can optimize minikube to run your new application immediately. Manual push request is actually handy in most CI/CD workflows because now you have more control over the codes you want to push all the way through the pipeline.

Pushing Changes in Different Situations

When you open your application code and make changes to it, Jenkins will not immediately update the deployment pods. Instead, you have to commit the changes and wait for Jenkins to pull those changes (depending on how that checkout of code was configured) before additional actions can be done.

On the Jenkins UI, there is a Build Now command for running new builds. After the build is completed, you will see the changes appearing the next time you use minikube to run your app. The way Jenkins pipelines are configured makes this tool incredibly useful.

You can, for example, use Jenkins to power your multi-team development. Jenkins pipeline runs as a code, which means any user with the right credentials can commit changes and execute the processes built into the pipeline.

It is also very versatile. The pipeline and the processes in it will automatically resume should your server suddenly crash. Jenkins will never lose control of the cluster it manages, so you can use Jenkins to completely eliminate the need for manual configurations of the CI/CD environment.

A personal favorite is the way Jenkins can be used to manage multiple pipelines, and that admins can have a clear view of all pipelines in the system. Coupled with the ability to pause and resume pipelines, using Jenkins to manage developments of microservices and larger projects is very rewarding.

Another great plugin is called Pipeline and Pipeline Multibranch that helps us to visualize the CI/CD flow. It allows a JenkinsFile to be defined into the repo with all the steps we want Jenkins to execute. There is no need to do manual configurations from the GUI (which might be reserved for Administrators only) and enables the flexibility of letting the developers control the flow for a given project/branch. Since it is in Github, it is also versioned alongside any other app library.

Jenkins and Kubernetes

That brings us back to our main point: leveraging Jenkins on Kubernetes. From the way Jenkins works as a tool, it is easy to see how this automation measure complements Kubernetes perfectly. Once the plugin is configured, every time a new build/job is triggered, Jenkins will create a pod inside K8s (through an on-demand agent designed to perform that work). Once done, the pod will be destroyed, avoiding the need for having a fixed pool of agents waiting for job execution. As you can see, Kubernetes provides the robust CI/CD infrastructure every development team needs, while Jenkins significantly simplifies the management of that environment.

The combination has the ability to improve CI/CD workflows in different situations, including in larger development projects. If you take into account the bounty of Jenkins plugins available—including Kubernetes Pipeline, Credentials, and more—already available today, you know you have a powerful CI/CD tool to work with. It even comes with the ability to separate non-setup and material work in the pipeline; what’s not to love?