Shulou(Shulou.com)05/31 Report--

This article mainly introduces "Drone and Jenkins example Analysis". In daily operation, I believe many people have doubts about Drone and Jenkins example analysis problems. The editor consulted all kinds of data and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "Drone and Jenkins example Analysis". Next, please follow the editor to study!

Introduction

Jenkins has been the industry standard CI tool for many years. It contains many features, and there are nearly 1000 plug-ins in its ecosystem, which can be daunting for those who advocate simplicity. Jenkins existed before the container, but it is well suited to the container environment. But I have to say that Jenkins didn't give any special attention to containers in the past, and it didn't make much effort to make containers better, but now the emergence and development of Blue Ocean and pipeline have changed the situation a lot.

Drone is a popular open source CI tool. It is actually a native Docker, and all processes are carried out in the container. This makes Drone ideal for platforms like Kubernetes, because it's easy to start the container on Kubernetes.

Rancher container management platform can provide excellent support for both Drone and Jenkins, and users can easily and quickly create Kubernetes clusters through an automated process. I deployed the K8s 1.8 cluster on GCE with Rancher 1.6, and the simplicity of the process was amazing.

This article will deploy Drone on Kubernetes (Rancher) and compare Drone with Jenkins from the following three aspects:

1. Platform installation and management

2. Plug-in ecosystem

3. Pipeline details

Finally, I will make an overall comparison between Jenkins and Drone. In fact, usually, such a comparison does not have a clear winner. Because although the two have something in common in nature, different tools still have different core focuses.

Preparation in advance

Before we begin, we need to complete some setup work, including setting up Drone as an authorized Oauth3 application with a Github account, which can be done by referring to Drone's official technical documentation.

When setting up Drone, I encountered a problem: there is a passive relationship between Drone and source control libraries. This means that Drone notifies events by establishing a network connection with Github. The default behavior is based on the push and PR merge events. In order for Github to notify Drone correctly, the server must be open to the world. Of course, the situation may be different if there are other internal supply chain management software, but this does not apply to the example in this article. To do this, I set up my Rancher server on GCE so that it can be accessed from Github.com.

As with other Kubernetes applications, installing Drone from a container requires a series of deployment files. I adjusted the deployment files found in repo. In the configuration mapping specification file, we need to modify several values. In other words, we need to set specific Github-related values for our account. We will get the client key from the setup step and put the key in the file and the user name of the authorized user. Through Drone's key file, we can put the Github password in place.

The way Jenkins interacts with source code is very different from that of Drone. In Jenkins, each job can define its relationship to source control independently of another job. This allows users to extract source code from a variety of libraries, including Github, Gitlab, svn, and so on. So far, Drone only supports git-based development projects.

In the meantime, don't forget the Kubernetes cluster! Rancher makes it easy to start and manage Kubernetes clusters. This article uses the latest stable version of Rancher 1.6. However, the information and steps for installing Rancher 2.0 are the same as those for Rancher 1.6, so it's okay if you want to try a newer Rancher.

Task 1-install and manage

Starting Drone on Kubernetes and Rancher is as simple as copying and pasting. Start the file using the default K8s dashboard, upload it from the namespace and the configuration file in turn, and Drone will be ready to run. [you can find some of the deployment files I used here: https://github.com/appleboy/drone-on-kubernetes/tree/master/gke]. I pulled the image from the library and edited it locally. The repo belongs to the Drone contributor, including instructions on how to start GCE and AWS. All we need here is the yaml file for Kubernetes. To copy, simply edit the ConfigMap file with your specific value. An example of one of my files is as follows:

Jenkins can also be started in this way, and because it can be deployed in a Docker container, you can build a similar deployment file and start it on Kubernetes. As shown below, this file is taken from the GCE sample repo of the Jenkins CI server.

Starting Jenkins is also easy. Given the ease of use of Docker and Rancher themselves, if you want to start Jenkins, simply paste a set of deployment files into the dashboard. My preferred approach is to use the Kubernetes dashboard for all administration. You can upload Jenkins files one by one to get the server up and running.

Drone Server is managed through configuration files that are set during the startup phase. It must connect to the Github, which means you need to add an OAuth3 token to access the library, and (in this article's example) a user name and password. If you want to make changes later, you need to grant the organization access through Github, or restart the server with new credentials. This will inevitably have an impact on development work, as it means that Drone cannot handle multiple sources. As we mentioned earlier, Jenkins is better in this respect, allowing any number of source repos, but note that only one source can be used per job.

Task 2-plug-in

The configuration and management of the Drone plug-in is very simple. In fact, there is not much you need to do to successfully launch a plug-in for Drone. The ecosystem of Drone is much smaller than Jenkins, but plug-ins are available in Drone for almost all the major tools available. Most major cloud providers have plug-ins and integrate with the popular source control repo. As mentioned earlier, the Drone container can be thought of as a "first-class citizen", which means that each plug-in and task performed is a container.

Jenkins is the undisputed king of plug-ins. In most cases, there are no tasks that the Jenkins plug-in cannot accomplish. Jenkins plug-ins have a wide range of choices, with about 1000 plug-ins available, but it is sometimes difficult to determine which one is the best choice from a series of plug-ins that look similar.

Drone has docker plug-ins for building push and images, as well as various plug-ins such as AWS and K8s plug-ins for deploying clusters. Because the Drone platform has been launched for a short time, it has far fewer plug-ins than Jenkins. However, this does not affect their effectiveness and ease of use. A simple section in the drone.yml file automatically downloads, configures, and runs the selected plug-in without additional input. In addition, due to the relationship between Drone and the container, each plug-in is stored in an image and no additional items need to be added for management. If the plug-in creator completes their work, all the content will be included in the container, and users no longer need to manage any dependencies.

When I build the drone.yml file for a simple node application, adding the Docker plug-in is very simple. It only takes a few lines of code to build the image and push it to the Dockerhub repo of my choice. In the next section, you can see the section labeled docker. This section is all you need to configure and run plug-ins to build and drive Docker images.

Task 3

The final task is the foundation of any CI system. Both Drone and Jenkins are designed to build applications. Initially, Jenkins was built for java applications, but over the years, this scope has been extended to any code that can be compiled and executed. Jenkins is even good at new pipelines and cron-job. However, although it is well suited to the container ecosystem, it is still not a native container.

By contrast, this is the Jenkinsfile of the same application.

Although this example is lengthy to explain, you can see that building a Docker image may be more complex than Drone, and does not include the interaction between Jenkins and Docker. Because Jenkins is not a native Docker, the agent must be configured in advance to interact correctly with the Docker daemon. This may be confusing, but it is exactly where Drone is going. Drone is already running on Docker, and its tasks are running on the same Docker.

At this point, the study of "Drone and Jenkins example Analysis" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.